前回の「メモ.　Windows Update補完計画、フェーズ2」では、Microsoft提供のサンプルスクリプト「WUA_SearchDownloadInstall.vbs」をカスタマイズし、「WUA_SearchDownloadInstallv2.vbs」を作成しました。今回はこの「WUA_SearchDownloadInstallv2.vbs」の応用編です。別のサンプルスクリプト（バッチファイル）と組み合わせて、Windowsのタスクスケジューラーで自動実行させてみます。

サンプルスクリプトの実行結果をイベントログに書き込むバッチ

　Windows Updateエージェント（WUA） APIのサンプルスクリプト「WUA_SearchDownloadInstall.vbs」のカスタマイズ版、「WUA_SearchDownloadInstallv2.vbs」を、Windows Updateの自動化に応用してみました。ただし、自動化にはOSの再起動までは含めません。再起動については、管理者がその要否を確認した上で手動または別の手段（再起動のためのタスクのスケジューリングなど）で行うことを前提とします。ちょっとしたデモとしてご覧ください。

　今回は、Windowsのタスクスケジューラーのタスクを利用して、サンプルスクリプト「WUA_SearchDownloadInstallv2.vbs」を実行させることにします。単純にサンプルスクリプトをタスクで実行させるのではなく、サンプルスクリプトを呼び出すバッチファイル（.batまたは.cmd）を作成し、終了コードに応じた別の処理を行わせたいと思います。別の処理としては、分かりやすいように、Windows標準のEVENTCREATEコマンドを使用してシステムイベントログにイベントを書き込むことにします。

　カスタマイズ版「WUA_SearchDownloadInstallv2.vbs」は、更新プログラムのインストールが行われなかった場合（利用可能な更新プログラムがない、またはスクリプトのパラメーター指定によって意図的に）は終了コード「0」、更新プログラムがインストールされ、再起動が不要な場合は終了コード「2～5」、再起動が必要な場合は終了コード「2＋100～5+100」（102～105）、それ以外の予期せぬエラーはそのエラーコードを終了コードとして終了するようになっています。

　次に示すバッチファイルは、これらの終了コードに応じて、「システム（System）」イベントログに、ソース「MyWindowsUpdate」からの「情報（INFORMATION）」または「警告（WARNING）」または「エラー（ERROR）」イベントを、イベントID「900～915」でサンプルスクリプトのインストール結果の説明とともに書き込みます。

mywinupdate.cmd（※エンコード: ANSIで保存すること）

　このバッチファイルを単純にタスクの「プログラムの開始」アクションで指定し、定期的に実行するようにスケジュールします（この例はデモのため、平日17:00に実行するようにしています）。このタスクのセキュリティオプションでは、「ユーザーがログオンしているかどうかにかかわらず実行する」と「最上位の特権で実行する」を選択します。あとは特別な設定は必要ありません（画面1）。


画面1　サンプルスクリプト「WUA_SearchDownloadInstallv2.vbs」を呼び出してイベントログを書き込むバッチファイルを自動実行するようにタスクを作成する

　タスクの実行時間になり、バッチファイルの実行が終了すると、サンプルスクリプトのインストール結果に基づいてシステムログにイベントが書き込まれます（画面2）


画面2　タスクの実行が終了すると、サンプルスクリプトによる更新プログラムのインストール結果がシステムログに書き込まれる

　なお、このデモを実際にやってみて気付いたことなのですが、WUA APIを使用した更新プログラムのインストールは、OS標準のWindows Update（Update Orchestrator Serviceに依存）による更新プログラムのインストールとは異なり、Windows Updateの更新の履歴に履歴として残りません（画面3）。

　この制約は、このブログの「メモ.　再起動が完了するまでがWindows Updateのインストール」で紹介したサンプルスクリプト（get-wustatus.ps1またはget-wustatus.vbs）を利用することで回避できます（画面4）。このサンプルスクリプトもまたWUA APIを使用しているのですが、WUA APIを使用した更新プログラムのインストールの履歴はもちろんのこと、OS標準のWindows Updateの履歴もすべてではありませんが取得できます。


画面3　WUA APIのサンプルスクリプトを使用した更新プログラムのインストールの履歴は、Windows Updateの更新の履歴には残らない（5/7にサンプルスクリプトでインストールされたKB5034439の履歴がない）

画面4　もう1つのサンプルスクリプト「get-wustatus.ps1」または「get-wustatus.vbs」を使用することで、最後にインストールされた更新プログラムと同じ日の履歴を取得することができる

　バッチファイルではイベントログへの書き込みを行いましたが、それ以外にも、同じバッチファイルの中にPowerShellの「Send-MailMessage」コマンドレット（外部サイト）によるメール通知（powershell.exe -Command "& {Send-MailMessage -from...}"）機能を組み込むこともできますし、タスクスケジューラーの別のタスク（「イベント時」トリガーを使用）や製品（弊社製品「BOM for Windows」の「イベントログ監視」など）でイベントログを監視して、イベントIDに基づいてまた別の処理を行わせたりすることもできます。なお、タスクスケジューラーの「電子メール送信（非推奨）」および「メッセージの表示（非推奨）」操作は、“非推奨”ではなく、既に“廃止”され機能しないことに注意してください）。

　最後に、今回紹介したバッチファイルとタスクスケジューラーのタスクはデモを目的としたもので、保留中の再起動がある状態で連続して実行されることを想定していません（やってみていません）。再起動が必要な場合は、次回のタスク実行前までに管理者が気付いて、再起動を実施することを想定しています。また、Windows Updateをスクリプトやタスクで自動化しようという場合、Windowsの自動更新設定にも注意が必要です。Windows Serverの既定では自動更新されることはありませんが（既定は「ダウンロードのみ《自動ダウンロードしインストール時に通知》」）、Windows 10/11では既定で自動更新が有効なので、Windows Updateのポリシー設定で調整しておく必要があるでしょう。