Azure Update Manager に関する問題のトラブルシューティング
この記事では、Azure Update Manager をデプロイまたは使用するときに発生する可能性があるエラー、その解決方法、スケジュールされた修正プログラムの既知の問題と制限について説明します。
一般的なトラブルシューティング
次のトラブルシューティング手順は、Windows および Linux マシンのパッチ拡張機能に関連する Azure 仮想マシン (VM) に適用されます。
Azure Linux VM
Microsoft Azure 仮想マシン エージェント (VM エージェント) が実行されているかどうかを確認するには、マシンで適切なアクションをトリガーし、自動パッチ要求のシーケンス番号を確認するには、/var/log/waagent.log のエージェント ログで詳細を確認します。 すべてのオートパッチ要求には、マシン上で一意のシーケンス番号が関連付けられています。 2021-01-20T16:57:00.607529Z INFO ExtHandler のようなログを探します。
拡張機能のパッケージ ディレクトリは /var/lib/waagent/Microsoft.CPlat.Core.Edp.LinuxPatchExtension-<version> です。 /status サブフォルダーには、<sequence number>.status ファイルがあります。 これには、1 つのオートパッチ要求中に実行されたアクションと状態の簡単な説明が含まれています。 また、更新プログラムの適用中に発生したエラーの短い一覧も含まれています。
拡張機能によって実行されたすべてのアクションに関連するログを確認するには、/var/log/azure/Microsoft.CPlat.Core.LinuxPatchExtension/ で詳細をチェックします。 これには、次の 2 つの目的のログ ファイルが含まれています。
<seq number>.core.log: パッチ アクションに関連する情報が含まれています。 この情報には、マシンに評価およびインストールされたパッチと、プロセスで発生した問題が含まれます。<Date and Time>_<Handler action>.ext.log: パッチ アクションの上にラッパーがあります。このラッパーは、拡張機能を管理し、特定のパッチ操作を呼び出すために使用されます。 このログには、ラッパーに関する情報が含まれています。 オートパッチの場合、ログ<Date and Time>_Enable.ext.logには、特定のパッチ操作が呼び出されたかどうかの情報が記録されます。
Azure Windows VM
VM エージェントが実行され、マシンで適切なアクションがトリガーされたことを確認し、オートパッチ要求のシーケンス番号を確認するには、C:\WindowsAzure\Logs\AggregateStatus のエージェント ログで詳細を確認します。 拡張機能のパッケージ ディレクトリは C:\Packages\Plugins\Microsoft.CPlat.Core.WindowsPatchExtension<version> です。
拡張機能によって実行されたすべてのアクションに関連するログを確認するには、C:\WindowsAzure\Logs\Plugins\Microsoft.CPlat.Core.WindowsPatchExtension<version> で詳細をチェックします。 これには、次の 2 つの目的のログ ファイルが含まれています。
WindowsUpdateExtension.log: パッチ アクションに関連する情報が含まれています。 この情報には、マシンに評価およびインストールされたパッチと、プロセスで発生した問題が含まれます。CommandExecution.log: パッチ アクションの上にラッパーがあります。このラッパーは、拡張機能を管理し、特定のパッチ操作を呼び出すために使用されます。 このログには、ラッパーに関する情報が含まれています。 オートパッチの場合、ログには、特定のパッチ操作が呼び出されたかどうかの情報が記録されます。
特殊な VM、移行後の VM、復元後の VM の作成中に定期的な評価ポリシーが使用されるとき、定期的な評価が正しく設定されません
原因
現行の変更ポリシーの設計に起因し、特殊な VM、移行後の VM、復元後の VM の作成中に定期的な評価が正しく設定されません。 作成後、ポリシーによって、コンプライアンス ダッシュボードにこれらのリソースが非準拠として表示されます。
解決方法
作成後に修復タスクを実行し、新しく作成されたリソースを修復します。 詳細については、「Azure Policy を使って準拠していないリソースを修復する」を参照してください。
ギャラリー イメージと暗号化されたディスクを使用したイメージの場合、ポリシー修復タスクが失敗する
問題点
仮想マシン モードでギャラリー イメージへの参照がある VM の修復エラーがあります。 これは、ギャラリー イメージに対する読み取りアクセス許可が必要であり、現在は仮想マシン共同作成者ロールの一部ではないためです。
原因
仮想マシン共同作成者ロールに十分なアクセス許可がありません。
解決方法
- すべての新しい割り当てについて、修復のためにポリシーの割り当て中に作成されたマネージド ID に共同作成者ロールを提供するように最近の変更が導入されました。 今後、これはすべての新しい割り当てのために割り当てられます。
- 以前の割り当てで、修復タスクに失敗する場合は、マネージド ID に共同作成者ロールを手動で割り当てることをお勧めします。そのためには、「定義されたロールを使用してマネージド ID にアクセス許可を付与する」で一覧表示されている手順に従います
- また、リンクされたリソース (ギャラリー イメージまたはディスク) が別のリソース グループまたはサブスクリプションにある場合に共同作成者ロールが機能しないシナリオでは、「定義されたロールを使用してマネージド ID にアクセス許可を付与する」の手順に従って、マネージド ID にスコープに対する適切なロールとアクセス許可を手動で指定して修復が妨げられないようします。
Arc 対応サーバーの定期的な評価を生成できない
問題点
Arc 対応サーバーがオンボードされているサブスクリプションで評価データが生成されていない。
解決方法
定期的な評価データを期待通り定期的に生成するために、Arc サーバー サブスクリプションが Microsoft.Compute リソース プロバイダーに登録されていることを確認します。 詳細情報
VM が別のサブスクリプションに移動されたときにメンテナンス構成が適用されない
問題点
VM が別のサブスクリプションに移動された際に、VM に関連付けられているスケジュールされたメンテナンス構成が実行されていない。
解決方法
VM を別のリソース グループまたはサブスクリプションに移動すると、VM に対するスケジュールされたパッチの適用は機能しなくなります。現在、このシナリオはシステムでサポートされていません。 移動された VM の以前の関連付けを削除し、新しい関連付けを作成して、移動された VM をメンテナンス構成に含めることができます。
パッチ オーケストレーション オプションを自動更新から手動更新に変更できない
問題点
Azure マシンには AutomaticByOS/Windows 自動更新としてパッチ オーケストレーション オプションがあり、[更新設定の変更] を使用してパッチ オーケストレーションを手動更新に変更することができません。
解決方法
パッチのインストールを Azure で調整しない場合、またはカスタム パッチ ソリューションを使用していない場合は、パッチ オーケストレーション オプションを [カスタマー マネージド スケジュール] (プレビュー) またはAutomaticByPlatform と ByPassPlatformSafetyChecksOnUserSchedule に変更し、スケジュール/メンテナンス構成をマシンに関連付けないようにすることができます。 この設定により、明示的に変更するまで、マシンで修正プログラムの適用が実行されなくなります。 詳細については、「ユーザー シナリオ」のシナリオ 2 をご覧ください。
マシンに "Not assessed" (評価が行われていません) と表示され、HRESULT 例外が表示される
問題点
- [コンプライアンス] に
Not assessedと表示されているマシンがあり、その下に例外メッセージが表示されます。 - ポータルに
HRESULTエラー コードが表示されます。
原因
更新エージェント (Windows 上の Windows Update エージェントおよび Linux ディストリビューション用のパッケージ マネージャー) が正しく構成されていません。 Update Manager は、必要な更新プログラム、パッチの状態、展開されたパッチの結果を提供するために、マシンの更新エージェントを利用しています。 この情報がないと、Update Manager は必要なパッチやインストール済みのパッチを適切にレポートすることができません。
解決方法
マシンで更新プログラムをローカルで実行してみてください。 この操作が失敗する場合は、通常、更新エージェントの構成にエラーがあることを意味します。
この問題は、ネットワーク構成とファイアウォールの問題が原因で発生することがよくあります。 以下のチェックを使用して問題を修正します。
Linux の場合は、適切なドキュメントを確認して、パッケージ リポジトリのネットワーク エンドポイントにアクセスできることを確認します。
Windows の場合は、「イントラネット エンドポイントから更新プログラムがダウンロードされない (WSUS/SCCM)」に記載されているエージェントの構成をご確認ください。
- マシンが Windows Update 用に構成されている場合は、「HTTP/プロキシに関する問題」で説明されているエンドポイントに到達できることを確認してください。
- マシンが Windows Server Update Services (WSUS) 用に構成されている場合は、WUServer レジストリ キーによって構成された WSUS サーバーにアクセスできることを確認してください。
HRESULT エラー コードが表示される場合は、赤で表示された例外をダブルクリックして、例外メッセージ全体を確認します。 考えられる解決策または推奨される対策については、次の表を参照してください。
| 例外 | 解決策または対策 |
|---|---|
Exception from HRESULT: 0x……C |
Windows Update エラー コード一覧で該当するエラー コードを検索して、例外の原因に関する追加情報を確認します。 |
0x8024402C0x8024401C0x8024402F |
ネットワーク接続の問題が発生したことを示します。 マシンが Update Management にネットワーク接続されていることを確認します。 必要なポートとアドレスの一覧については、「ネットワークの計画」セクションをご覧ください。 |
0x8024001E |
サービスまたはシステムがシャットダウン中のため、更新操作が完了しませんでした。 |
0x8024002E |
Windows Update サービスが無効です。 |
0x8024402C |
WSUS サーバーを使用している場合は、レジストリ キー HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate の下の WUServer と WUStatusServer のレジストリ値で正しい WSUS サーバーが指定されていることを確認します。 |
0x80072EE2 |
ネットワーク接続の問題、または構成された WSUS サーバーとの通信に問題があります。 WSUS 設定を確認し、サービスがクライアントからアクセス可能であることを確認します。 |
The service cannot be started, either because it is disabled or because it has no enabled devices associated with it. (Exception from HRESULT: 0x80070422) |
Windows Update サービス (wuauserv) が実行されており、無効になっていないことを確認します。 |
0x80070005 |
アクセス拒否エラーは、次に示すいずれかの原因により発生する可能性があります。 - 感染したコンピューター。 - Windows Update の設定が正しく構成されていない。 - %WinDir%\SoftwareDistribution フォルダーのファイル アクセス許可エラー。- システム ドライブ (ドライブ C) のディスク領域不足。 |
| その他の一般的な例外 | 可能な解決策についてインターネットで検索を行い、最寄りの IT サポートと連携します。 |
%Windir%\Windowsupdate.log ファイルを確認すると、考えられる原因を特定するのにも役立ちます。 ログの読み方の詳細については、Windowsupdate.log ファイルの解釈に関する記事をご覧ください。
Windows Update トラブルシューティング ツールをダウンロードして実行し、マシン上の Windows Update に問題がないか確認することもできます。
Note
Windows Update トラブルシューティングツールのドキュメントに、Windows クライアントでの使用向けであると記載されていますが、Windows Server でも動作します。
パッチ適用をスケジュールに関する既知の問題
- 同時または競合スケジュールの場合、トリガーされるスケジュールは 1 つだけです。 他のスケジュールは、スケジュールが完了するとトリガーされます。
- マシンが新しく作成されると、Azure VM の場合、スケジュール トリガーが 15 分遅延する可能性があります。
- バージョン 1.0.0 プレビューでのポリシー定義 "Azure Update Manager を使用して定期的な更新をスケジュールする" では、リソースが正常に修復されます。 ただし、常に非準拠として表示されます。 存在条件の現在の値は、常に false と評価されるプレースホルダーです。
スケジュールされたパッチが 'ShutdownOrUnresponsive' というエラーで失敗する
問題点
スケジュールされたパッチによって VM 上にパッチがインストールされず、'ShutdownOrUnresponsive' というエラーが表示される。
解決方法
8 時間以内に削除され、同じリソース ID で再作成されたマシン上でスケジュールがトリガーされると、既知の制限により、ShutdownOrUnresponsive エラーで失敗することがあります。
シャットダウン マシンにパッチを適用できない
問題点
シャットダウン状態のマシンにはパッチが適用されません。 また、マシンが関連するメンテナンス構成やスケジュールを失っていることが判明する場合があります。
原因
マシンがシャットダウン状態です。
解決方法
スケジュールされた更新の少なくとも 15 分前にマシンの電源をオンのままにします。 詳細については、「シャットダウンされたマシン」をご覧ください。
更新プログラムの実行に失敗し、メンテナンス期間を超えたプロパティは、時間が残っていても true を示す
問題点
更新履歴で更新プログラムのデプロイを表示すると、実行に十分な時間が残っていても、メンテナンス期間を超えて失敗したプロパティは true と表示されます。 この場合は、次のいずれかの問題が考えられます。
- 更新プログラムが表示されていない。
- 1 つ以上の更新プログラムが保留中の状態になっている。
- 再起動の状態は必須ですが、再起動設定が
IfRequiredまたはAlwaysの場合でも再起動が試行されなかった。
原因
更新プログラムのデプロイ中に、複数の手順でメンテナンス期間の使用率がチェックされます。 いつでも再起動できるよう、10 分間のメンテナンス期間が予約されています。 デプロイが不足している更新プログラムの一覧を取得するか、更新プログラムをダウンロードまたはインストールする前に (Windows Service Pack の更新プログラムを除く)、再起動に 15 分 + 10 分 (つまり、メンテナンス期間に残り 25 分) があるかどうかを確認します。
Windows Service Pack の更新プログラムの場合は、デプロイは再起動のために 20 分と 10 分 (つまり 30 分) を確認します。 デプロイに十分な時間が残っていない場合、更新プログラムのスキャン/ダウンロード/インストールはスキップされます。 その後、デプロイの実行では、再起動が必要かどうかと、メンテナンス期間が 10 分が残っているかどうかを確認します。 存在する場合、デプロイによって再起動がトリガーされます。 それ以外の場合、再起動はスキップされます。
このような場合、状態は [失敗] に更新され、[メンテナンス期間超過] プロパティが true に更新されます。 残り時間が 25 分未満の場合、更新プログラムはスキャンされず、インストールは試行されません。
詳細については、デプロイ実行のエラー メッセージに記載されているファイル パスのログをご確認ください。
解決方法
オンデマンド更新プログラムのデプロイをトリガーする際に最大期間の時間範囲を長く設定すると、問題を回避するのに役立ちます。
次のステップ
- Update Manager の詳細については、「概要」をご覧ください。
- すべてのマシンからログに記録された結果を表示するには、Update Manager からのログと結果のクエリに関する記事をご覧ください。