Azure Update Managerのメンテナンス構成には、事前イベント/事後イベントとしてカスタムタスクを自動実行できる「イベント（メンテナンスイベント）」オプションがあります。そのカスタムタスクの呼び出す方法の1つに、Webhookがあります。そして、前回（vol.117）学んだAzure Automate Hybrid Runbook Worker（ハイブリッドWorker）は、Webhookを使用して外部からトリガーすることができます。これらの連携により、更新プログラムのインストール（必要に応じて再起動）の前後に、カスタム管理タスクを実行するように構成してみます。
Azureで実行するか、ハイブリッドWorkerで実行するか
米国時間第2火曜日にリリースされるWindowsの毎月のセキュリティ更新プログラムは、通常、インストールを完了するために再起動が必要です。Windows Serverの一部のバージョン/エディションで利用可能になったホットパッチ*1は、その回数を抑制できますが、少なくとも3か月に一度は再起動が必要です。
*1 ホットパッチが有効なWindows Server 2025 Datacenterのマシンが1台ありますが、これについては以下を参照してください。
ITニュース. Windows Server 2025 Datacenter/Standardのホットパッチは7月に正式提供開始
vol.71 Azureだけだったホットパッチ機能、オンプレやAzure以外でも利用可能に（体感ビデオ付）｜Windows Server 2025大特集（8）
常時稼働が前提であることが多いサーバーは、更新を完了するために、突然、再起動されては困る場合がほとんどでしょう。アプリケーションやサービスへのクライアントアクセスが途中であったり、再起動前に適切な手順を踏んで終了し、逆にOSの起動後に適切な手順を踏んで開始しなければならない業務システムもあります。メンテナンス構成の事前イベント（Pre Maintenance Event、メンテナンス前のイベント）/事後イベント（Post Maintenance Event、メンテナンス後のイベント）を使用すると次のようなことが実現でき、事前/事後に必要な一連の管理タスクと更新プログラムのインストール（および再起動）を自動化することができます（画面1）。
- メンテナンス実施の前後に更新対象のVMを起動/停止する
- データ回復用にボリュームのスナップショットを取得する
- メンテナンス開始/終了をメールで通知する
- メンテナンス実施の前後にアプリケーションやサービスを安全に停止/開始する
画面1 メンテナンス構成には事前イベント/事後イベントを追加でき、メンテナンス期間の前後にカスタム管理タスクを自動実行できる
今回は、これらの管理タスクの実装に、Azure AutomationのRunbookを利用します。更新対象のマシンがAzure VMの場合、RunbookはAzure（既定）で実行することができます。一方、実行したい管理タスクを更新対象のマシン側またはそのマシン（VM）を実行しているホストで実行する必要がある場合は、ローカルOSやローカルリソースにアクセスできるハイブリッドWorkerで実行する必要があります。後者の目的のために、前回、Azure VMおよびAzure以外の場所（オンプレミスや他社クラウド）にあるマシンに一対一で対応する、複数のハイブリッドWorkerグループを用意しました（画面2）。AzureでRunbookを実行する例については、次回紹介します。
画面2 Azure VMやAzure以外のマシンに一対一で対応するハイブリッドWorkerグループ。詳しくは前回を参照
事前イベント/事後イベント用のRunbookを作成する
前回、ハイブリッドWorkerでRunbookを実行すると、ローカルOSやローカルリソースに管理者権限（Windowsの場合はNT AUTHORITY¥SYSTEM、Linuxの場合はroot）またはRunbookに事前に設定した資格情報の権限でカスタムスクリプトを実行できることを示しました。今回は例として、事前イベント/事後イベントのそれぞれに対応した次のWindows PowerShell 5.1用Runbookを作成、発行しました（画面3）。スクリプトは簡単なもので、ホスト名とOSビルドを出力し（画面4、画面5）、OSビルドをC:ドライブのルートに「preosbuild.txt」または「postosbuild.txt」にも出力します。ファイルへの出力は、マシン側での動作確認のためのものです。
PowerShell Runbook pretaskjob（プレーンテキストで表示）
$ret = hostname
Write-Output ("Host name: $ret")
$ret = (Get-WmiObject Win32_OperatingSystem).Caption
Write-Output ("OS name: $ret")
$ret = (Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion").CurrentBuild + "." +(Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion").UBR
Write-Output ("OS build: $ret")
$ret |Out-File -FilePath C:\preosbuild.txt
Write-Output ("Host name: $ret")
$ret = (Get-WmiObject Win32_OperatingSystem).Caption
Write-Output ("OS name: $ret")
$ret = (Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion").CurrentBuild + "." +(Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion").UBR
Write-Output ("OS build: $ret")
$ret |Out-File -FilePath C:\preosbuild.txt
PowerShell Runbook posttaskjob（プレーンテキストで表示）
$ret = hostname
Write-Output ("Host name: $ret")
$ret = (Get-WmiObject Win32_OperatingSystem).Caption
Write-Output ("OS name: $ret")
$ret = (Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion").CurrentBuild + "." +(Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion").UBR
Write-Output ("OS build: $ret")
$ret |Out-File -FilePath C:\postosbuild.txt
Write-Output ("Host name: $ret")
$ret = (Get-WmiObject Win32_OperatingSystem).Caption
Write-Output ("OS name: $ret")
$ret = (Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion").CurrentBuild + "." +(Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion").UBR
Write-Output ("OS build: $ret")
$ret |Out-File -FilePath C:\postosbuild.txt
画面3 事後イベント用のRunbookのPowerShellスクリプトを作成し、テスト後、発行する
画面4 発行したRunbookを、ハイブリッドWorkerグループを選択して実行する
画面5 ハイブリッドWorkerグループに含まれる単一のハイブリッドWorkerでRunbookのスクリプトが実行され、その出力を確認する。マシン側にはC:ドライブのルートにOSビルドが書き込まれたテキストファイルが出力される
RunbookにWebhookを追加する
Azure Update Managerのメンテナンス構成のイベント（メンテナンスイベント）オプションは、この機能はAzure Event Gridと呼ばれるフルマネージドの発行/サブスクライブメッセージ配信サービスを利用します。Azure Event Gridは、Webhookを含む複数のイベントハンドラーをネイティブでサポート（前出の画面1）しています。
Azure AutomationのRunbookにはWebhookを追加することができ、外部から実行をトリガーすることが可能です。Webhookを追加するには、Runbookの「リソース > Webhook」ページを開き、「＋Webhookの追加」をクリックします。「Webhookの追加」では、「Webhook/新しいWebhookを作成します」をクリックして、「新しいWebhookの作成」でWebhookに名前を設定し、自動生成されたWebhook URLをクリップボードにコピーします（画面6）。このWebhook URLにはセキュリティトークンが含まれており、URL自身がパスワード的に機能します。このURLは「OK」をクリックすると二度と表示することができないため、コピーして安全に保管してください。
画面6 新しいWebhookを作成し、Webhook URLをコピーして控えておく
「OK」をクリックして「Webhookの追加」に戻り、「パラメーターと実行設定/実行設定を変更する（既定: Azure）」をクリックして、パラメーター（今回のRunbookでは不要）と実行対象を指定します。実行対象として「ハイブリッドWorker」を選択し、このRunbookを実行するマシンを含むハイブリッドWorkerグループを選択します（画面7）。
画面7 Runbookの実行対象として、ハイブリッドWorkerグループを指定する
「OK」をクリックして「Webhookの追加」に戻り、「作成」をクリックします。このようにして、事前/事後用のRunbookそれぞれについて、Runbookを実行させたいマシンを含むハイブリッドWorkerグループを指定したWebhookを追加しておきます。
Azure Update Managerのメンテナンス構成にイベントを追加する
メンテナンス構成作成時の「イベント」タブまたは「メンテナンス構成（プレビュー）」で編集可能なメンテナンス構成の「設定 > イベント」ページで、「＋イベントサブスクリプション」をクリックし、イベントサブスクリプションの名前（例: RunPreEvent、RunPostEvent）とシステムトピック名（例: PrePostEvent）を設定します。イベントサブスクリプションの名前はイベントごとの名前、システムトピック名は次に作成するイベントサブスクリプションでも使用される名前で、複数のイベントサブスクリプションをまとめるものと考えればよいでしょう。
イベントの種類として「メンテナンス前のイベント（Pre Maintenance Event）」または「メンテナンス後のイベント（Post Maintenance Event）」を選択し、エンドポイントとしてイベントハンドラー「Webhook」と、エンドポイントとして控えておいたWebhook URLを入力します（画面8）。事前イベントはメンテナンス期間開始の少なくとも30分前に開始され、タスクは期間開始の10分前までに終了する必要があります。事後イベントはメンテナンス（更新プログラムのインストール、必要に応じて再起動）が完了した直後、メンテナンス期間内またはメンテナンス期間が終了した場合はその後に実行されます。事前イベントを含むメンテナンス構成では、最初のスケジュール日時が40分以上先であることが求められることに注意してください。
画面8 メンテナンス構成のイベントサブスクリプションで、事前または事後イベントでWebhookをトリガーするように設定する
なお、Runbookは1台のマシンで実行されるため、事前/事後イベントの両方を設定する場合は、そのマシン専用のメンテナンス構成を作成して添付します。事前イベントだけの場合は、複数台のマシンに添付するメンテナンス構成に、複数の事前イベント（複数のWebhookの呼び出し）を設定することができるでしょう。
事前/事後イベントで管理タスクが自動実行されることを確認する
今回は簡単なRunbookにしましたが、それは検証が目的だからです。同様に、検証のため1台のマシンに、定義の更新のみを6時間ごとに繰り返し確認/インストールする、事前/事後イベントを含むメンテナンス構成を作成して添付しました。すると6時間ごと（スケジュール日時の約30分前）に事前イベントが呼び出され、インストールの有無に関係なく（定義の更新のみを対象としているため）、完了後に事後イベントが呼び出されていることを確認できます。また、マシンのC:ドライブのルートにファイルが出力されていることも確認できます（画面9）。
画面9 Azure Update Managerのメンテナンス前後に、事前イベント/事後イベントのRunbookが実行されている
※今回の検証のために添付したメンテナンス構成を対象のマシンから解除した後も、事前/事後タスクの実行は継続されました。おそらく、イベントサブスクリプションを含むメンテナンス構成が存在する限り、リソースの添付の有無に関係なく、メンテナンス構成のスケジュール設定に従って、Azure Event Gridがサブスクリプションをトリガーしているからと思われます。メンテナンスからイベントサブスクリプションを削除したところ、事前/事後タスクの呼び出しは無くなりました。
