サーバー管理の深淵：VBScriptによるターミナルセッションへの緊急アナウンス自動化
インフラ運用の現場において、最新の自動化ツールが導入されていようとも、最後の一線で頼りになるのはWindows Script Host (WSH) である。特に、レガシーなWindows Server環境において、全ログインユーザーに対して即座に注意喚起を行う必要がある場合、重厚な管理エージェントを介するよりも、WMIと`msg.exe`を直結させたVBScriptによる直接制御こそが、最も低レイテンシで確実な解となる。
今回は、単なるコマンド発行に留まらない、メモリ管理とプロセス実行の機微を極めたスクリプト設計術を伝授する。
1. アーキテクチャの核心：WMIとmsg.exeの協調
多くのエンジニアが躓くのは、WMIから取得したセッションIDを`msg.exe`に渡す際の「非同期実行の制御」と「リソースリーク」だ。WMIの `Win32_LoggedOnUser` や `Win32_SessionConnectInfo` を利用する場合、不用意なオブジェクト生成はメモリの断片化を招く。
我々が目指すべきは、オブジェクトのライフサイクルを最小単位で管理し、外部プロセス実行時のオーバーヘッドを極限まで削ぎ落とした実装である。
2. 極限の設計：通知スクリプトの全貌
以下のスクリプトは、単なるループ処理ではない。`WshShell.Run` のウィンドウ非表示オプションと、戻り値のハンドリングを組み込んだ、堅牢な運用コードである。
‘ ==============================================================================
‘ Script Name: NotifyAllUsers.vbs
‘ Description: ログオン中セッションをWMIで走査し、msg.exeで緊急通知を送る
‘ Author: Chief Architect
‘ ==============================================================================
Option Explicit
Dim strComputer, objWMIService, colItems, objItem
Dim objShell, strMsg, strCommand
Dim intSessionID
‘ 通知メッセージの定義
strMsg = “【緊急メンテナンス通知】10分後にサーバーを再起動します。作業を保存してください。”
strComputer = “.”
‘ オブジェクトの事前生成（メモリの再利用性を高める）
Set objShell = CreateObject(“WScript.Shell”)
Set objWMIService = GetObject(“winmgmts:\\” & strComputer & “\root\cimv2”)
‘ Win32_LogonSessionを走査し、対話型セッションのみを抽出
‘ フィルタリングをWQL側で行うことで、実行時のCPU負荷を低減する
Set colItems = objWMIService.ExecQuery(“SELECT FROM Win32_LogonSession WHERE LogonType = 2”)
For Each objItem In colItems
‘ セッションIDの取得
intSessionID = objItem.LogonId
‘ msg.exe にパラメータを渡して実行
‘ /SERVER:%COMPUTERNAME% は自ホスト指定、 /TIME は秒単位の表示時間
strCommand = “msg.exe /SERVER:” & strComputer & ” /TIME:60 ” & strMsg
‘ ウィンドウを非表示(0)、完了を待機しない(False)で実行
‘ 大規模環境では同期実行させると全体の処理が止まるため、非同期が鉄則
objShell.Run strCommand, 0, False
Next
‘ オブジェクトの明示的解放（VBScriptのGCを待たないプロの作法）
Set colItems = Nothing
Set objWMIService = Nothing
Set objShell = Nothing
WScript.Echo “通知コマンドの全発行が完了しました。”
3. チーフアーキテクトからの深掘り：実装の急所
このスクリプトを単に動かすのではなく、運用環境で「武器」にするために理解すべき3つのポイントがある。
A. LogonTypeの選別
`Win32_LogonSession` において、`LogonType = 2` を指定している理由は明確だ。これは「Interactive（対話型）」ログオンのみを対象とするためである。サービスアカウントやバックグラウンドプロセスを誤って対象外にすることで、無駄なエラーログの出力を抑制し、通知の精度を向上させている。
B. オブジェクトの「明示的解放」の真意
VBScriptのエンジンは、スクリプト終了時にメモリを解放するが、大規模な監視基盤の一部として本スクリプトを定期実行（タスクスケジューラ等）させる場合、`Nothing` による解放を怠ると、Handleリークを誘発する。特にWMIのオブジェクトはメモリを食う。使い終わった瞬間にスコープから外すのが、長期間稼働させるスクリプトの鉄則だ。
C. msg.exeの限界と拡張性
`msg.exe` は非常に強力だが、Windows 10/11のHomeエディションなど、一部の環境ではデフォルトで無効化されている場合がある。もし、より厳密な制御が必要な場合は、`WMI` の `Win32_Process` を直接叩いて自前の通知アプリをキックするか、Windows APIの `WTSSendMessage` を `DynamicWrapperX` 等で呼び出すアプローチへ移行せよ。
結びとして
技術がどれほど進化しても、サーバーの深淵で起きていることを見通す力は、こうした泥臭いスクリプトの積み重ねに宿る。このコードをベースに、貴殿の環境に最適化された「究極の自動化」を構築してほしい。
システム管理とは、魔法を使うことではない。制御可能な範囲を、徹底的に自動化することに他ならないのだから。
