「Azure Update Managerでサーバー更新管理」連載シリーズは今回で最終回です。今回は、Azure Update ManagerとAzure Arcに関連するよくある“かも”知れない質問を想定してお送りします。連載シリーズ最終回恒例の目次付き。
Q. Azure Update Managerを無料で利用できる条件は？
Q. Azure Update Managerで管理されるマシン側のWindows Update設定はどうするべき？
Q. Azure Update ManagerでMicrosoft製品の更新をインストールするには？
Q. 最新の定期評価がなくてもスケジュール更新は可能？
Q. Azure Update Managerはクラスター対応更新（CAU）とともに機能しますか？
Q. 拡張機能の状態が正常にならない
Q. ハイブリッドWorkerの既定の実行ユーザーは？
Q. ホットパッチを取得するには、Azure Update Managerで管理されている必要があるの？
Q. ESUのセキュリティ更新プログラムを取得するには、Azure Update Managerが必要？
･･･
「Azure Update Managerでサーバー更新管理」連載シリーズの目次
Q. Azure Update Managerを無料で利用できる条件は？
Azure Update Managerは、AzureおよびAzure Local（旧称、Azure Stack HCI）上のVMで無料で利用でき、Azure以外のマシンはAzure Arc対応サーバーを通じて有料で利用できます。ただし、Azure Arc対応サーバーが以下に示す条件に一致する場合、Azure Update Managerを追加コストなしで利用できます。
- Azure Arc対応サーバーを通じて拡張セキュリティ更新プログラム（ESU）が有効化されている
- Azure Arc対応サーバーでMicrosoft Defendre for Serversプラン2（有料、個別またはMicrosoft Defender for Cloudプラン2に含まれる）が有効になっている
- ソフトウェアアシュアランス（SA）のあるWindows Serverライセンス、またはアクティブなサブスクリプションライセンスであるWindows Server ライセンス（Microsoft CSP経由）
- Azure Arc対応サーバーを通じてサブスクライブした従量課金制（PAYG）ライセンス
Azure Update Manager FAQ > Azure Arc で有効化される Windows Server 管理｜Azure（Microsoft Learn）
Q. Azure Update Managerで管理されるマシン側のWindows Update設定はどうするべき？
Azure Update Managerによる定期的な更新のスケジュール設定が優先されるように、Windows Server側のWindows Updateの設定は「手動（自動更新無効）」または「ダウンロードのみ」に設定してください。Windows Serverの既定のインストールでは、Windows Updateの設定は「ダウンロードのみ」です。Azure MarketplaceのWindows Serverの通常エディションの既定は「自動」です。Azure Editionイメージの既定の設定は「手動」です。
Windows ServerのWindows Updateの設定はSconfigユーティリティ（画面1）、グループポリシー、ローカルコンピューターポリシー（画面2）などで設定できます。
画面1 Windows ServerのWindows Updateの設定をSconfigユーティリティで変更する
画面2 Windows ServerのWindows Updateの設定を「自動更新を構成する」ポリシーで変更する。ダウンロードのみは「3. 自動ダウンロードしインストールを通知」に、手動にするにはこのポリシー設定を無効にする
Q． Azure Update ManagerでMicrosoft製品の更新をインストールするには？
Azure Update Managerは、既定でWindows ServerマシンのOSのみに更新プログラムを提供するように構成されています。SQL Serverなど、他のMicrosoft製品の更新プログラムを受け取るかどうかは、Windows Updateクライアント側の設定でMicrosoft Updateにオプトインされているかどうかに依存します。
Microsoft Updateへのオプトインを設定する方法の1つは、Windows Updateの詳細オプションの「その他のMicrosoft製品の更新プログラムを受け取る」*1 をオンにすることです（デスクトップエクスペリエンスの場合）。「自動更新を構成する」ポリシーの中にある「他のMicrosoft製品の更新プログラムのインストール」をチェックすることで設定することもできますが、その場合、手動（自動更新無効）の設定と同時に行うことができません。
*1 Windowsのバージョンによっては「Windowsの更新時に他のMicrosoft製品の更新プログラムも入手します」など表現が異なります
Windows Server 2025の場合は、Sconfigユーティリティの「5) 更新の設定 > 5) Microsoft Updateへのオプトイン」から設定することができますが、Windows Server 2022以前ではこの方法は利用できません。次のPowerShellのコマンドラインを使用すると、Windowsのバージョンに関係なく、Microsoft Updateへのオプトインを設定または解除（オプトアウト）できます（画面3）。
Microsoft Updateへのオプトイン
|
$ServiceManager = New-Object -ComObject Microsoft.Update.ServiceManager $ServiceManager.AddService2("7971f918-a847-4430-9279-4a52d1efe18d",7,"") |
Microsoft Updateのオプトアウト
|
$ServiceManager = New-Object -ComObject Microsoft.Update.ServiceManager $ServiceManager.RemoveService("7971f918-a847-4430-9279-4a52d1efe18d") |
画面3 Sconfigユーティリティ（Windows Server 2025のみ）またはPowerShellでMicrosoft Updateにオプトインする
Q. 最新の定期評価がなくてもスケジュール更新は可能？
可能です。Azure Update Managerの定期評価は、利用可能な最新の更新プログラムを定期的（24時間ごと）に自動で確認することで、全体のコンプライアンス状態を報告するとともに、更新状態を確認する必要があるたびに手動で評価を実行する手間を省くことができるというものです。
スケジュール設定によってトリガーされたインストールでは、定期評価に関係なく、更新プログラムの確認、ダウンロード、インストールが行われるため、定期評価が古くても、あるいは実行されていなくても、最新の更新プログラムがインストールされます。例えば、毎月第2火曜日（米国時間）の更新プログラムリリース日にスケジュール設定している場合、その月の更新プログラムのインストール状況は、次の定期評価で把握できることになります。
しかしながら、定期評価は有効にしておくことをお勧めします。最新の定期評価が利用でき、インストールから除外したい更新プログラムがある場合は、KB番号による除外設定をスケジュール開始前に行うことができます。また、定期評価を利用できない場合、1回限りの更新を実行するには、その前に手動で更新プログラムの確認を行う必要があり、手間が増えます。
Q. Azure Update Managerはクラスター対応更新（CAU）とともに機能しますか？
Windows Serverのフェールオーバークラスターでは、クラスター上の高可用性アプリケーションを停止することなく、クラスターの各ノードを更新する「クラスター対応更新（CAU）」をサポートしています。Azure Update Managerを使用してクラスターの各ノードを更新することはできますが、CAUとの統合機能はありません。そのため、CAUのように高可用性アプリケーションをノード間で移行しながら、ノードごとに更新を完了するということはできません。クラスターの更新については、クラスター対応更新（CAU）を使用することをお勧めします。
Can we configure Azure Update Manager on Hyper-v Cluster｜Q＆A（Microsoft Learn）
メモ. クラスター対応更新（CAU）ってこんな感じ
vol.84 ワークグループクラスターとクラスター対応更新（CAU）｜Windows Server 2025大特集（21）
Azure Local（旧称、Azure Stack HCI）の最新リリース（23H2以降）については、Azure Update Managerによる更新がサポートされます。バージョン22H2については、クラスター対応更新（CAU）を使用してください。
Azure Update Manager を使用して Azure Local を更新する｜Azure（Microsoft Learn）
Q. 拡張機能の状態が正常にならない
画面4は、Azure Update Managerの管理下にあり、Azure AutomationハイブリッドWorkerとして機能する、Azure VMおよびAzure Arc対応サーバーの拡張機能の正常な状態です。このように、各サービスに対応する拡張機能がインストールされ、その状態が「Provison succeeded」または「成功」でない、異常な状態（別の状態がいつまでたっても変化しない、エラー状態など）になっている場合、正常に更新できなかったり、ハイブリッドWorkerとして正常に機能しません。
画面4 Azure Update ManagerとハイブリッドWorkerの両方に対応したマシンの拡張機能の正常な状態（上がAzure VM、下がAzure Arc対応サーバー）
例えば、ハイブリッドWorkerグループからマシンを削除すると、そのマシンから拡張機能「HybridWorkerExtension」がアンインストールされますが、完全にアンインストールされる前にハイブリッドWorkerグループを再作成した場合、拡張機能が異常な状態になる場合があります。その場合は、Azure VMやAzure Arc対応サーバーの拡張機能のページから拡張機能をアンインストールし、完全に削除されたことを確認してからハイブリッドWorkerグループを再作成することで解消することがあります。それでもだめなら、すべての拡張機能をアンインストールして、すべての登録（Azure Arcへの接続など）からやり直すことで解消するかもしれません。
Q. ハイブリッドWorkerの既定の実行ユーザーは？
ハイブリッドWorkerで実行されるRunbookの実行ユーザーは、ハイブリッドWorkerグループ作成時の「ハイブリッドworkerの資格情報の使用」オプションに従います（画面5）。ハイブリッドWorkerがWindowsマシンの場合の既定の実行ユーザーはシステムアカウント（NT AUTHORITY￥SYSTEM）、Linuxマシンの場合の既定の実行ユーザーはrootになります。カスタムの資格情報を指定した場合は、そのユーザーで実行されます。
画面5 ハイブリッドWorkerで実行されるRunbookの実行ユーザーは、ハイブリッドworkerの資格情報の設定に従う
ハイブリッドWorkerがWindowsマシンの場合は、「whoami」の1行を記述したPowerShell Runbookを作成して、テストすることで確認できます（画面6、画面7）。Linuxマシンの場合は、Python Runbookで同様の出力をするPythonコード（コードの例）を記述してください。
画面6 実行アカウントを返す簡単なPowerShell Runbook
画面7 WindowsマシンのハイブリッドWorkerでRunbookを実行した結果。左がカスタム、右が既定のハイブリッドworker資格情報
Q. ホットパッチを取得するには、Azure Update Managerで管理されている必要があるの？
いいえ。Azure Update Managerでは、ホットパッチの有効化/無効化を切り替えることはできますが（Azure Arc対応サーバーのホットパッチへの登録/解除はAzure Arcで行います）、更新プログラムの管理にAzure Update Managerを使用しなければならないわけではありません。ホットパッチが利用可能な場合、Windows Updateを通じて提供されます。
Q. ESUのセキュリティ更新プログラムを取得するには、Azure Update Managerが必要？
いいえ。Azure VMおよびAzure Local上のVMで、ESUが提供されているWindows Serverバージョンを実行している場合、追加設定なしでESUの更新プログラムがWindows UpdateやWindows Server Update Services（WSUS）を通じて提供されます。もちろん、Azure Update Managerを使用して、ESUを含む更新を管理することは可能です。
Azure以外のマシンの場合、Azure Arcやその他の方法でESUをアクティブ化します。こちらにも、Azure Update Managerは直接関与しませんが、ESUの更新プログラムを含めてマシンの更新を管理することはできます。なお、Azure Arc対応サーバーを通じてESUを購入する場合、Azure Update Managerを追加コストできます（最初のQを参照）。
Q. 別のメンテナンス構成に置き換えたのに、以前の事前/事後イベントが実行され続けるのはなぜ？
事前/事後イベントのアクションを実行するイベントサブスクリプションは、メンテナンス構成に紐づき、メンテナンス構成のスケジュール設定前後に実行されます。そのメンテナンス構成がリソース（マシン）に添付されていなくても、イベントサブスクリプションを含むメンテナンス構成が存在する限り、そのイベントサブスクリプションは動作し続けます。メンテナンス構成を削除するか、メンテナンス構成からイベントサブスクリプションを削除してください。
・・・
