「Job Director R16」は、タスクスケジューラでは物足りないが、統合運用管理ツールでは高機能すぎるというお悩みを抱えるシステム管理者にぴったりなジョブ管理ツールです。Windows Updateをシステム管理者のコントロール下に置きながら、運用を自動化することも可能です。今回は、「かつて山市良と呼ばれていたおじさんのブログ」で最近紹介された、Windows Update関連のスクリプトを、Job Directorで運用する活用例を紹介します。
Job Directorの4つの特徴、おじさんのブログテクで実証
Job Director R16は、定型業務やバッチ処理の自動運用とスケジュール管理を行うためのジョブ管理ツールです。その特徴は、GUIで業務フローを簡単に定義できること、柔軟なスケジュール設定、ジョブネットワーク（実行順序を指定した1つ以上のジョブの集まり）の実行状況の一元管理、万全なセキュリティ対策（細かなアクセス権限管理と監査に役立つログ保存機能）の4つ。
製品サイト：高機能ジョブスケジューラー「Job Director R16」
以下の製品コラムでは、「かつて山市良と呼ばれていたおじさんのブログ」の以下の記事で紹介されたWindows Update関連のスクリプトと「BOM for Windows Ver.8.0 SR1」を組み合わせた活用例を紹介しました。
BOM 8.0 SR1活用例: おじさんブログと連動－更新履歴を毎日監視
BOM 8.0 SR1活用例: おじさんブログと連動－更新を自動化し、再起動を保留
今回は、もう1つの弊社主力ソフトウェア製品である「Job Director R16」（以下、Job Director）との組み合わせで、更新エラー発生状況の把握や、再起動の遅延実行まで完全に自動化してみます。Job Directorで自動実行するスクリプトは、以下のブログ記事で紹介されている「get-wustatus.vbs」と「WUA_SearchDownloadInstallv2.vbs」の2つです。
メモ. 再起動が完了するまでがWindows Updateのインストール
メモ. Windows Update補完計画、フェーズ2
メモ. Windows Update補完計画、フェーズ2.1
今回の活用例を見ていただければ、Job Directorの4つの特徴のすべてを知っていただけるはずです。今回のジョブネットワークには、メール通知機能は含まれていませんが、BOM活用例と全く同じBOMのイベントログ監視機能とメール送信アクションを流用することで、メール通知機能を追加できます。また、Job Directorの拡張カスタムジョブとして提供される「メール送信」部品を使用して、メール通知をジョブネットワーク内に定義することもできます。
Windows Updateの実行をジョブネットワークで制御
BOMの活用例では、タスクスケジューラーと「mywinupdate.cmd」（「WUA_SearchDownloadInstallv2.vbs」を呼び出して終了コードに応じてイベントログに書き込むバッチ）を組み合わせましたが、「mywinupdate.cmd」の機能を、Job Directorのジョブネットワークに完全に置き換え、さらに再起動処理を追加します（画面1）。
画面1 Windows Update自動化のためのジョブネットワーク「WUJob」の全体
このようにJob Directorでは、ジョブネットワークの［START］と［END］の間にさまざまな部品を配置して、GUIでフローを制御することができます。各部品の細かな設定については後で説明します。
セキュリティ更新日のその日に実行を可能にするスケジュール設定
Microsoftは毎月第2火曜日（米国時間）にセキュリティ更新プログラムをリリースします。それに合わせて、ジョブネットワーク「WUJob」を実行させたいと思います。日本時間ではその翌日の水曜日ですが、それが第二水曜日になるのか、第三水曜日になるのか、月によって異なります。Job Directorであれば簡単です。例えば、セキュリティ更新日の20:00に更新を開始したいという場合、「第二火曜日」の相対「1」日、開始時間「20:00」と定義できます（画面2）。
Job Directorには、日本の祝日や休日を設定した日本版カレンダーファイルが標準で同梱されており、インポートして利用できます。会社独自のカレンダーを定義することもできます。それら1つ以上のカレンダーをベースに、毎月第五営業日、締め日3日前、実行日が日本や会社の休日と重なった場合の振り替えなど、柔軟なスケジュール設定が可能です。
画面2 Windows Updateのためのスケジュール設定。セキュリティ更新日（第二火曜日の翌日）の20:00に開始する例
Windows Update自動化のためのジョブの詳細設定
最初の「RunMyWUScript」ジョブでは、単純に「WUA_SearchDownloadInstallv2.vbs /Automate」を実行するコマンドラインを記述しています。このスクリプトは、インストールの結果と再起動の要否に応じて終了コードとして「0」、「2～5」、「102～105」を返します。また予期せぬエラーが発生したときは、そのエラーコードを返します。ジョブは既定では終了コード「0」で正常終了、それ以外は異常終了と判断するため、0以外の終了コードも正常終了とさせるため、ジョブのパラメータを調整します（画面3）。
画面3 「RunMyWUScript」ジョブで実行するコマンドラインとジョブパラメータの設定
「RunMyWUScript」ジョブの後ろには「条件分岐」部品を配置し、終了コードによって次のジョブに流します。次のジョブは、EVENTCREATEコマンドを実行して終了コードに応じたイベントログ（システムログ）を書き込んでいます。出力先のログ名、イベントID、種類（情報または警告またはエラー）、説明は、「mywinupdate.cmd」と全く同じにしています（画面4）。
画面4 終了コードに応じてイベントログにイベントを記録するジョブ
「RunMyWUScript」ジョブは、再起動が必要な場合、終了コード「102～105」を返します。その終了コードをイベントログに書き込むジョブの後ろには、サブジョブネットワーク「RebootNextMaintenanceTime」を配置しています。1つのジョブネットワークを部品として異なるジョブネットワークの中に配置するもので、ジョブネットワークの階層化や、共通のフローを再利用したい場合などに利用できます。
サブジョブネットワーク「RebootNextMaintenanceTime」では、「タイム待合」部品を配置し、再起動を開始するまでの遅延を定義し、「RebootNow」ジョブでは、イベントログに書き込んだあと（新しいイベントID「910」として）、shutdownコマンドで再起動を実行します（画面5）。この例では、セキュリティ更新日である水曜日に更新を開始し、その日のうちに更新プログラムのインストールが終わって再起動待ちになった場合、3日後の土曜日23:00に「RebootNow」ジョブを開始させることができます。
画面5 サブネットワークジョブ「RebootNextMaintenanceTime」では、土曜23:00に再起動を開始するように定義
ジョブネットワーク「WUJob」の最後は、最後にインストールされた更新プログラムと同じ日にインストールされた更新の履歴を取得する「get-wustatus.vbs」を実行しています（画面6）。更新プログラムのインストールの数日後に実行することになる場合は、Microsoft Defenderの定義の更新などで、最後にインストールされた更新日が変更になる可能性があるため、自動更新を明示的に無効にする（Sconfigで更新の設定を手動にするなど）とよいでしょう。あるいは、「If DateDiff("d",wudate,lastwudate) = 0 then」（最後の更新プログラムのインストールと同じ日）の行を、「If DateDiff("d",wudate,lastwudate) =< 7 then」（最後の更新プログラムのインストールから7日以内の場合）のように書き換えることをお勧めします。
画面6 ジョブネットワークの最後は「get-wustatus.vbs」の実行
以上が、Windows Update自動化のためのジョブネットワークの定義例です。ジョブネットワークはスケジュール実行以外に、「即時投入」で手動で実行を開始することもできます。このジョブネットワークは「即時投入」でテストを繰り返したものなので、5月のセキュリティ更新日にスケジュール実行した実際の結果を見ていただきましょう。
スケジュール実行の結果
今回、ジョブネットワーク「WUJob」の実証テストを5月のセキュリティ更新日に実施しました。テストのため、サブネットワークジョブ「RebootNextMaintenanceTime」では「タイム待合」を1日後の8:00に変更してあります。テストは2台のWindows Server 2022仮想マシンで実施しました。1台は正常にWindows Updateを完了できると期待できるもので、もう1台は必ず1つの更新プログラムが失敗するものです（回復パーティションの容量が不足している場合に発生するKB5034439《外部サイト》を回避していない環境）。
ジョブネットワークの実行状況は、トラッカで追跡することができます。画面7は、Windows Updateが正常に完了したほうのトラッカを示しています。期待通り、「RunMyWUScript」ジョブは終了コード「102」（インストール成功、再起動必要）で終了し、「SuccessRebootReq」ジョブに流れています。翌朝8:00に再起動が実施され、すべてのフローが正常に完了しています。ジョブネットワークの中のジョブで再起動を行っても、ジョブネットワークのフローがその後の「GetWUHistory」ジョブそして［END］まで追跡できている点にも注目してください。また、画面8は、ジョブネットワークの過去の履歴を示しすものですが、ジョブネットワークが実行中の場合は、現在の状態を追跡することができます。
画面7 Windows Updateが正常に終了し、再起動も完了したことをトラッカが記録している
各部品のスクリプトの詳細を開くと、「出力結果」に「WUA_SearchDownloadInstallv2.vbs」や「get-wustatus.vbs」の標準出力を確認できます。コマンドやスクリプトの実行結果の出力が記録されるのは、エラーの追跡や監査に役立つ、Job Directorの特に優れた機能の1つです。ジョブでは単純なコマンドラインやスクリプトを実行させてましたが、それはこの機能があるからです。実行結果をファイルに出力するなど面倒なことをする必要がありません。
画面8は、1つの更新プログラムが必ず失敗する方のトラッカを示しています。期待通り、「RunMyWUScript」ジョブは終了コード「103」（インストール成功（失敗あり）し、そのフローを通っています。「RunMyWUScript」ジョブのスクリプトの詳細を確認すると、エラーとなったのは、これも期待通りKB5034439であったことが分かります。KB5034439のエラーは、Windows Update Agent（WUA） APIを使用した更新の履歴（「get-wustatus.vbs」の結果）には残りませんが、「WUA_SearchDownloadInstallv2.vbs」の出力結果のほうで確認することができています。
画面8 「RunMyWUScript」ジョブの出力結果から、KB5034439のエラーを確認できる
Job Directorは、標準の部品としてメール送信の機能を持ちませんが、拡張カスタムジョブの「メール送信」部品で対応可能です。今回はBOM活用例で既に作成したイベントログ監視と組み合わせることでメール通知を行っています（画面9）。なお、BOM活用術で作成したイベントログ監視はそのまま流用できますが、今回、イベントID「910」に対応した監視を追加し、再起動の開始をメール通知しています。
画面9 BOMによるイベントログ監視で送信されたメール通知
最後に、今回のデモではセキュリティ更新日のその日に更新を開始しましたが、「第二火曜日」の相対「4または5」日のスケジュール設定をすれば、週末に開始することもできます。セキュリティ更新日のその日にこだわったわけは、現在、Windows Server 2022 Datacenter: Azure Editionでのみ利用可能なホットパッチ機能（→「Windows Server Azure Editionのホットパッチ」≪外部サイト≫）が、年内にリリースされる予定の「Windows Server 2025」からは、通常のエディションでも利用できるようになるからです（ただし、有料サービス）。ホットパッチは、3か月ごとの再起動が必要な累積更新プログラムと、その後の2か月間の再起動が不要なホットパッチによって、最新のセキュリティ対策を講じながら、長期連続稼働を可能とします。ホットパッチは短時間で完了し、即座にセキュリティ問題への対応が可能になるため、セキュリティ更新日の実行にこだわった訳です。
更新情報:
2025/04/07 本文中の「get-wustatus.ps1」は「get-wustatus.vbs」の間違いであったため訂正しました。
