Update Management に関する問題のトラブルシューティング
重要
Log Analytics エージェントを使用した変更履歴とインベントリは、2024 年 8 月 31 日に廃止され、2025 年 2 月 1 日まで限られた範囲でサポートされます。 新しいサポート エージェントとして Azure Monitoring Agent を使用することをお勧めします。 Log Analytics を使用する変更履歴とインベントリから Azure Monitoring Agent バージョンを使用した変更履歴とインベントリへの移行については、こちらのガイダンスに従ってください。
この記事では、Update Management 機能を使用してマシンの更新プログラムを評価および管理するときに発生する可能性がある問題について説明します。 根本的な問題の特定に役立つ、Hybrid Runbook Worker エージェントのエージェント トラブルシューティング ツールがあります。 トラブルシューティング ツールの詳細については、「Windows Update エージェントの問題をトラブルシューティングする」と「Linux Update エージェントに関する問題のトラブルシューティング」を参照してください。 その他の機能のデプロイについては、「機能のデプロイに関する問題のトラブルシューティング」を参照してください。
Note
Windows マシンに Update Management をデプロイしているときに問題が発生した場合は、Windows イベント ビューアーを開き、ローカル コンピューターの [アプリケーションとサービス ログ] の下にある Operations Manager イベント ログを確認します。 イベント ID が 4502 でイベントの詳細に Microsoft.EnterpriseManagement.HealthService.AzureAutomation.HybridAgent が含まれるイベントを探します。
シナリオ: Windows Defender の更新プログラムが常に "見つからない" と表示される
問題
Windows Defender の定義更新プログラム (KB2267602) が、インストール時の評価では常に "見つからない" と表示され、Windows Update の履歴に基づく検証時には "最新" と表示されます。
原因
定義更新プログラムは 1 日に複数回公開されます。 そのため、同じ日に公開され、更新プログラム ID とバージョンが異なる KB2267602 の複数のリリースが表示される可能性があります。
Update Management の評価は、11 時間に 1 回実行されます。 この例では、午前 10 時に評価が実行され、その時点でバージョン 1.237.316.0 が利用可能でした。 Log Analytics ワークスペースで Update テーブルを検索すると、UpdateState が Needed と表示された状態で定義更新プログラム 1.237.316.0 が表示されます。 スケジュールされたデプロイが数時間後 (たとえば、午後 1 時) に実行され、その時点でバージョン 1.237.316.0 が引き続き利用可能であるか、新しいバージョンが利用可能である場合、その新しいバージョンがインストールされ、UpdateRunProgress テーブルに書き込まれるレコードにこれが反映されます。 ただし、Update テーブルでは、次の評価が実行されるまで、引き続きバージョン 1.237.316.0 が Needed と表示されます。 評価が再度実行されたときには、利用可能な新しい定義更新プログラムがない可能性があるため、Update テーブルに、定義更新プログラムのバージョン 1.237.316.0 が見つからないと表示されたり、必要に応じて利用可能な新しいバージョンが表示されたりすることはありません。 定義更新プログラムの頻度により、ログ検索で複数のバージョンが返される可能性があります。
解決方法
次のログ クエリを実行して、インストールされている定義更新プログラムが正しく報告されていることを確認します。 このクエリでは、Updates テーブルの KB2267602 の生成時刻、バージョン、更新プログラム ID が返されます。 Computer の値をマシンの完全修飾名に置き換えます。
Update
| where TimeGenerated > ago(14h) and OSType != "Linux" and (Optional == false or Classification has "Critical" or Classification has "Security") and SourceComputerId in ((
Heartbeat
| where TimeGenerated > ago(12h) and OSType =~ "Windows" and notempty(Computer)
| summarize arg_max(TimeGenerated, Solutions) by SourceComputerId
| where Solutions has "updates"
| distinct SourceComputerId))
| summarize hint.strategy=partitioned arg_max(TimeGenerated, *) by Computer, SourceComputerId, UpdateID
| where UpdateState =~ "Needed" and Approved != false and Computer == "<computerName>"
| render table
クエリからは、次のような結果が返されます。
次のログ クエリを実行して、UpdatesRunProgress テーブルの KB2267602 の生成時刻、バージョン、更新プログラム ID を取得します。 このクエリは、Update Management からインストールされたのか、Microsoft Update からマシンに自動インストールされたのかを把握するのに役立ちます。 CorrelationId の値を更新プログラムの Runbook ジョブの GUID (つまり、Patch-MicrosoftOMSComputer Runbook ジョブの MasterJOBID プロパティの値) に置き換え、SourceComputerId をマシンの GUID に置き換える必要があります。
UpdateRunProgress
| where OSType!="Linux" and CorrelationId=="<master job id>" and SourceComputerId=="<source computer id>"
| summarize arg_max(TimeGenerated, Title, InstallationStatus) by UpdateId
| project TimeGenerated, id=UpdateId, displayName=Title, InstallationStatus
クエリからは、次のような結果が返されます。
Updates テーブルのログ クエリの結果の TimeGenerated の値が、マシンに更新プログラムをインストールした時点のタイムスタンプまたは UpdateRunProgress テーブルのログ クエリの結果のタイムスタンプ (つまり、TimeGenerated 値) よりも前である場合は、次の評価を待ちます。 その後、Updates テーブルに対してログ クエリを再度実行します。 KB2267602 の更新プログラムが表示されないか、新しいバージョンで表示されます。 最新の評価の後もなお Updates テーブルに同じバージョンが Needed と表示されるにもかかわらず、それが既にインストールされている場合は、Azure サポート インシデントを開く必要があります。
シナリオ: Linux 更新プログラムが保留中として表示され、インストールされる更新プログラムが異なる
問題
Linux マシンの場合、Update Management には、[セキュリティ] と [その他] に分類される更新プログラムが表示されます。 ただし、[セキュリティ] として分類される更新プログラムのみをインストールするなど、ある更新スケジュールがマシン上で実行されるとき、インストールされる更新プログラムは、その分類に一致する前に表示された更新プログラムとは異なるものになるか、その一部になります。
原因
お使いの Linux マシンに対して保留になっている OS 更新プログラムの評価が終わると、Linux ディストリビューション ベンダーが提供する Open Vulnerability and Assessment Language (OVAL) が分類のために Update Management によって使用されます。 セキュリティの問題または脆弱性に対処する更新プログラムについて明記された OVAL ファイルに基づき、Linux 更新プログラムが [セキュリティ] か [その他] として分類されます。 ただし、更新プログラムが実行されるとき、YUM、APT、ZYPPER などの適切なパッケージ マネージャーを使用し、Linux マシン上で実行され、インストールされます。 Linux ディストリビューションのパッケージ マネージャーには、更新プログラムを分類する別のメカニズムが備わっていることがあり、その場合の結果は、Update Management によって OVAL ファイルから取得されるものと異なる可能性があります。
解決方法
Linux マシン、適用できる更新プログラム、ディストリビューションのパッケージ マネージャー別のその分類を手動で確認できます。 お使いのパッケージ マネージャーによって [セキュリティ] として分類された更新プログラムを理解するには、次のコマンドを実行します。
YUM の場合、次のコマンドから、Red Hat によって [セキュリティ] として分類される更新プログラムのゼロではない一覧が返されます。
sudo yum -q --security check-update
ZYPPER の場合、次のコマンドから、SUSE によって [セキュリティ] として分類される更新プログラムのゼロではない一覧が返されます。
sudo LANG=en_US.UTF8 zypper --non-interactive patch --category security --dry-run
APT の場合、次のコマンドから、Canonical for Ubuntu Linux ディストリビューションによって [セキュリティ] として分類される更新プログラムのゼロではない一覧が返されます。
sudo grep security /etc/apt/sources.list > /tmp/oms-update-security.list LANG=en_US.UTF8 sudo apt-get -s dist-upgrade -oDir::Etc::Sourcelist=/tmp/oms-update-security.list
この一覧から、コマンド grep ^Inst を実行し、保留中のセキュリティ更新プログラムをすべて取得します。
シナリオ: "Failed to enable the Update solution" (Update ソリューションを有効にできませんでした) というエラーが表示される
問題
Automation アカウントで Update Management ソリューションを有効にしようとすると、次のエラーが発生します。
Error details: Failed to enable the Update solution
原因
このエラーは、次の理由で発生することがあります。
Log Analytics エージェントのネットワーク ファイアウォールの要件が、正しく構成されていない可能性があります。 このような状況では、DNS URL を解決するときにエージェントが失敗する可能性があります。
Update Management のターゲット設定が正しく構成されておらず、マシンが想定どおりに更新プログラムを受信していません。
[コンプライアンス] に、マシンの状態が
Non-compliantと表示されている場合もあります。 同時に、エージェントの Desktop Analytics でエージェントがDisconnectedとして報告されます。
解決方法
ネットワーク構成に関する記事にアクセスし、Update Management を動作させるために許可する必要があるアドレスとポートを確認してください。
スコープ構成に問題がないかどうかを確認します。 スコープの構成では、Update Management 用に構成されるマシンが決定されます。 ワークスペースに表示されているマシンが Update Management に表示されない場合、スコープ構成を設定してそのマシンをターゲットにする必要があります。 スコープ構成の詳細については、「ワークスペースでのマシンの有効化」を参照してください。
「オンプレミスの Windows コンピューターから Hybrid Runbook Worker を削除する」または「オンプレミスの Linux コンピューターから Hybrid Runbook Worker を削除する」の手順に従い、worker 構成を削除します。
シナリオ: 置き換え済みの更新プログラムが Update Management で不足として示される
問題
古い更新プログラムは、置き換え済みであっても、Automation アカウントで不足として表示されます。 同じ脆弱性を修正しているより新しい更新プログラムを利用できるので、置き換え済みの更新プログラムは、インストールする必要がないものです。 Update Management では、置き換えが行われる更新プログラムを優先し、置き換え済みの更新プログラムは無視して適用しません。 関連する問題の詳細については、「更新プログラムが置き換えられている」を参照してください。
原因
置き換え済みの更新プログラムは、適用外と見なされるように、Windows Server Update Services (WSUS) では拒否されません。
解決方法
置き換え済みの更新プログラムが 100% 適用されなくなっている場合には、その更新プログラムの承認状態を WSUS で Declined に変更する必要があります。 すべての更新プログラムの承認状態を変更するには:
Automation アカウントで [Update Management] を選択して、マシンの状態を表示します。 「更新の評価を表示する」を参照してください。
置き換え済みの更新プログラムが 100 パーセント適用されないことを確認します。
コンピューターの報告先となる WSUS サーバーで、更新プログラムを拒否してください。
[コンピューター] を選択して、[コンプライアンス] 列で、準拠するための再スキャンを適用します。 VM の更新プログラムの管理に関する記事を参照してください。
置き換え済みの他の更新プログラムに対して、上記の手順を繰り返してください。
Windows Server Update Services (WSUS) の場合は、WSUS Server クリーンアップ ウィザードを使用し、置き換え済みの更新プログラムをすべて消去して、インフラストラクチャを更新します。
この手順を定期的に繰り返して表示の問題を修正し、更新プログラムの管理に使用されるディスク領域量を最小限に抑えます。
シナリオ: Update Management のポータルにマシンが表示されない
問題
マシンに次の現象が発生しています。
VM の Update Management ビューでマシンが
Not configuredと表示される。Azure Automation アカウントの Update Management ビューに自分のマシンがない。
[コンプライアンス] で
Not assessedと表示されているマシンがある。 ただし、Hybrid Runbook Worker の Azure Monitor ログにはハートビート データが表示されているが、Update Management には表示されない。
原因
この問題は、ローカル構成の問題や正しく設定されなかったスコープ構成が原因で発生する可能性があります。 考えられる具体的な原因は次のとおりです。
Hybrid Runbook Worker の再登録と再インストールが必要になる場合があります。
自分のワークスペースで定義したクォータに達していて、それ以上のデータの格納が妨げられている可能性があります。
解決方法
マシンが適切なワークスペースにレポートしていることを確認します。 この側面を確認する方法については、「Azure Monitor へのエージェント接続を確認する」を参照してください。 このワークスペースが Azure Automation アカウントにリンクされていることも確認します。 確認するには、自分の Automation アカウントに移動して、[関連リソース] の [リンクされたワークスペース] を選択します。
Automation アカウントにリンクされた Log Analytics ワークスペースにマシンが表示されることを確認します。 Log Analytics ワークスペースで、次のクエリを実行します。
Heartbeat | summarize by Computer, Solutionsクエリ結果にマシンが表示されない場合は、最近チェックインされていません。 ローカルの構成に問題がある可能性があるため、エージェントを再インストールする必要があります。
コンピューターがクエリ結果に一覧表示されている場合は、Solutions プロパティの下に updates が一覧表示されていることを確認します。 これにより、Update Management に登録されていることが確認できます。 そうでない場合は、スコープ構成に問題がないかどうかを確認します。 スコープの構成では、Update Management 用に構成されるマシンが決定されます。 対象のコンピューターのスコープ構成を構成するには、「ワークスペースでのマシンの有効化」を参照してください。
ワークスペースで、次のクエリを実行します。
Operation | where OperationCategory == 'Data Collection Status' | sort by TimeGenerated descData collection stopped due to daily limit of free data reached. Ingestion status = OverQuotaという結果が表示される場合、ワークスペースに定義されたクォータに達したため、データの保存が停止されています。 ワークスペースで [使用量と推定コスト] の [データ ボリュームの管理] に移動して、クォータを変更または削除します。問題が解決しない場合は、「Windows Hybrid Runbook Worker をデプロイする」の手順に従って、Windows 用のハイブリッド worker を再インストールしてください。 Linux の場合は、「Linux Hybrid Runbook Worker を展開する」の手順に従います。
シナリオ: サブスクリプションで Automation リソース プロバイダーを登録できない
問題
Automation アカウントで機能のデプロイを行うときに、次のエラーが発生します。
Error details: Unable to register Automation Resource Provider for subscriptions
原因
Automation リソース プロバイダーがサブスクリプションに登録されていません。
解決方法
Automation リソース プロバイダーを登録するには、Azure portal で次の手順に従います。
ポータルの下部にある Azure サービスの一覧で [すべてのサービス] を選択し、[全般] サービス グループの [サブスクリプション] を選択します。
サブスクリプションを選択します。
[設定] で、[リソース プロバイダー] を選択します。
リソース プロバイダーの一覧で、Microsoft.Automation リソース プロバイダーが登録されていることを確認します。
一覧に表示されていない場合は、「リソース プロバイダーの登録エラーの解決」の手順に従って、Microsoft.Automation プロバイダーを登録します。
シナリオ: スケジュールされた更新プログラムで一部のマシンにパッチが適用されない
問題
更新プレビューに含まれているマシンが、スケジュールされた実行中にパッチが適用されたマシンの一覧にすべて表示されないか、または動的グループの選択したスコープの VM がポータルの更新プレビューの一覧に表示されません。
更新プレビューの一覧は、選択したスコープの Azure Resource Graph クエリによって取得されたすべてのマシンで構成されます。 スコープは、システム Hybrid Runbook Worker がインストールされていて、ユーザーがアクセス許可を持っているマシンでフィルター処理されます。
原因
この問題には、次のいずれかの原因が考えられます。
動的クエリのスコープで定義されているサブスクリプションが、登録済みの Automation リソース プロバイダーに対して構成されていません。
スケジュールが実行されたときに、マシンが使用できなかったか、マシンに適切なタグがありませんでした。
選択したスコープに対する適切なアクセス権がありません。
Azure Resource Graph クエリで、予期されるマシンが取得されません。
システム Hybrid Runbook Worker がマシンにインストールされていません。
解決方法
登録済みの Automation リソース プロバイダー用に構成されていないサブスクリプション
サブスクリプションが Automation リソース プロバイダー用に構成されていない場合、そのサブスクリプション内のマシンの情報をクエリまたはフェッチすることはできません。 サブスクリプションの登録を確認するには、次の手順のようにします。
Azure portal で、Azure サービス一覧にアクセスします。
[すべてのサービス] を選択し、[全般] サービス グループで [サブスクリプション] を選択します。
デプロイのスコープで定義されているサブスクリプションを検索します。
[設定] で、[リソース プロバイダー] を選択します。
Microsoft.Automation リソース プロバイダーが登録されていることを確認します。
一覧に表示されていない場合は、「リソース プロバイダーの登録エラーの解決」の手順に従って、Microsoft.Automation プロバイダーを登録します。
スケジュールの実行時に、マシンが使用できない、またはマシンに正しくタグが付けられていない
サブスクリプションが Automation リソース プロバイダー用に構成されているのに、指定した動的グループで更新スケジュールを実行すると一部のマシンが見つからない場合は、次の手順を使用します。
Azure portal で、Automation アカウントを開き、[更新の管理] を選択します。
Update Management の履歴を調べて、更新プログラムのデプロイが実行された正確な時刻を確認します。
Update Management によって検出されない疑いのあるマシンについて、Azure Resource Graph (ARG) を使用してマシンの変更を特定します。
更新プログラムのデプロイが実行される前のある程度の期間 (1 日など) について、変更を検索します。
検索結果で、この期間内にマシンに対して行われた、削除や更新の変更などの体系的な変更を確認します。 これらの変更により、マシンの状態またはタグが変更され、更新プログラムのデプロイ時にマシンの一覧でマシンが選択されなくなった可能性があります。
必要に応じてマシンとリソースの設定を調整し、マシンの状態またはタグの問題を修正します。
更新スケジュールを再実行し、指定した動的グループでのデプロイにすべてのマシンが含まれることを確認します。
選択したスコープに対する正しくないアクセス権
Azure portal には、ユーザーが特定のスコープで書き込みアクセス権を持っているマシンのみが表示されます。 スコープに対する適切なアクセス権がない場合は、「チュートリアル: Azure portal を使用して Azure リソースへのアクセス権をユーザーに付与する」を参照してください。
Resource Graph クエリで予期されるマシンが返されない
以下の手順のようにして、クエリが正常に機能しているかどうかを確認します。
Azure portal の Resource Graph エクスプローラー ブレードで、次のように書式設定された Azure Resource Graph クエリを実行します。 Azure Resource Graph を初めて使用する場合は、このクイックスタートを参照して、Resource Graph エクスプローラーの操作方法を学習してください。 このクエリでは、Update Management で動的グループを作成したときに選択したフィルターが模倣されます。 「Update Management を利用して動的グループを使用する」を参照してください。
where (subscriptionId in~ ("<subscriptionId1>", "<subscriptionId2>") and type =~ "microsoft.compute/virtualmachines" and properties.storageProfile.osDisk.osType == "<Windows/Linux>" and resourceGroup in~ ("<resourceGroupName1>","<resourceGroupName2>") and location in~ ("<location1>","<location2>") ) | project id, location, name, tags = todynamic(tolower(tostring(tags))) | where (tags[tolower("<tagKey1>")] =~ "<tagValue1>" and tags[tolower("<tagKey2>")] =~ "<tagValue2>") // use this if "All" option selected for tags | where (tags[tolower("<tagKey1>")] =~ "<tagValue1>" or tags[tolower("<tagKey2>")] =~ "<tagValue2>") // use this if "Any" option selected for tags | project id, location, name, tags次に例を示します。
where (subscriptionId in~ ("aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e", "bbbb1b1b-cc2c-dd3d-ee4e-ffffff5f5f5f") and type =~ "microsoft.compute/virtualmachines" and properties.storageProfile.osDisk.osType == "Windows" and resourceGroup in~ ("testRG","withinvnet-2020-01-06-10-global-resources-southindia") and location in~ ("australiacentral","australiacentral2","brazilsouth") ) | project id, location, name, tags = todynamic(tolower(tostring(tags))) | where (tags[tolower("ms-resource-usage")] =~ "azure-cloud-shell" and tags[tolower("temp")] =~ "temp") | project id, location, name, tags検索しているマシンがクエリ結果に表示されるかどうかを確認します。
マシンが一覧に表示されない場合は、動的グループで選択されているフィルターに問題がある可能性があります。 必要に応じてグループの構成を調整します。
Hybrid Runbook Worker がマシンにインストールされていない
マシンは Azure Resource Graph クエリの結果には表示されますが、動的グループのプレビューにはやはり表示されません。 この場合、マシンがシステム Hybrid Runbook Worker として指定されていないため、Azure Automation や Update Management のジョブを実行できないおそれがあります。 表示されるはずのマシンがシステム Hybrid Runbook Worker として設定されていることを確認するには、次のようにします。
Azure portal で、正しく表示されないマシンの Automation アカウントに移動します。
[プロセス オートメーション] で [ハイブリッド Worker グループ] を選択します。
[システム ハイブリッド worker グループ] タブを選択します。
そのマシンにハイブリッド worker が存在することを確認します。
マシンがシステム Hybrid Runbook Worker として設定されていない場合は、次のいずれかの方法を使用して有効にする方法を確認してください。
1 台以上の Azure マシンと Azure 以外のマシン (Azure Arc 対応サーバーを含む) に対しては、お使いの Automation アカウントから。
Enable-AutomationSolution Runbook を使用した Azure VM のオンボードの自動化。
選択した Azure VM に対しては、Azure portal の [仮想マシン] ページから。 このシナリオは、Linux VM 用と Windows VM 用があります。
複数の Azure VM に対しては、Azure portal の [仮想マシン] ページからそれらを選択することで。
有効にする方法は、マシンが実行されている環境に基づいています。
プレビューに表示されないすべてのマシンに対して上記の手順を繰り返します。
シナリオ: Update Management のコンポーネントが有効になっているが、VM は構成中と表示されたままである
問題
デプロイの開始から 15 分経過しても、VM に関する次のメッセージが引き続き表示されます。
The components for the 'Update Management' solution have been enabled, and now this virtual machine is being configured. Please be patient, as this can sometimes take up to 15 minutes.
原因
このエラーは、次の理由で発生することがあります。
Automation アカウントとの通信がブロックされています。
ソース コンピューター ID が異なるが、コンピューター名が重複するものがあります。 このシナリオは、異なる複数のリソース グループ内に、ある特定のコンピューター名を持つ VM が作成され、サブスクリプションの同じロジスティック エージェント ワークスペースにレポートしている場合に発生します。
デプロイしている VM イメージの複製元が、Windows 用の Log Analytics エージェントがインストールされた状態でシステム準備 (sysprep) を使用して準備されなかった複製マシンである可能性があります。
解決方法
VM の問題を正確に特定するには、Automation アカウントにリンクされた Log Analytics ワークスペースで、次のクエリを実行します。
Update
| where Computer contains "fillInMachineName"
| project TimeGenerated, Computer, SourceComputerId, Title, UpdateState
Automation アカウントとの通信がブロックされる
ネットワークの計画に関する記事にアクセスし、Update Management を動作させるために許可する必要があるアドレスとポートを確認してください。
コンピューター名の重複
VM の名前を変更して、環境内で一意の名前となるようにします。
複製マシンからのデプロイされたイメージ
複製されたイメージを使用している場合は、異なるコンピューター名で同じソース コンピューター ID を保持します。 この場合、次のようになります。
Log Analytics ワークスペースで、
MicrosoftDefaultScopeConfig-Updatesスコープ構成の保存された検索条件から VM を削除します (表示された場合)。 保存された検索条件は、ワークスペース内の [全般] にあります。次のコマンドレットを実行します。
Remove-Item -Path "HKLM:\software\microsoft\hybridrunbookworker" -Recurse -ForceRestart-Service HealthServiceを実行して、ヘルス サービスを再起動します。 この操作により、キーが再作成され、新しい UUID が生成されます。この方法がうまくいかない場合は、まずイメージで sysprep を実行してから、Windows 向け Log Analytics エージェントをインストールします。
シナリオ: 別の Azure テナントのマシンを対象とした更新プログラムの展開を作成するときに、リンクされているサブスクリプションのエラーが発生する
問題
別の Azure テナントのマシンを対象とした更新プログラムの展開を作成しようとすると、次のエラーが発生します。
The client has permission to perform action 'Microsoft.Compute/virtualMachines/write' on scope '/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/resourceGroupName/providers/Microsoft.Automation/automationAccounts/automationAccountName/softwareUpdateConfigurations/updateDeploymentName', however the current tenant '00000000-0000-0000-0000-000000000000' is not authorized to access linked subscription '00000000-0000-0000-0000-000000000000'.
原因
このエラーは、更新プログラムの展開に含まれる別のテナントの Azure VM を持つ更新プログラムの展開を作成するときに発生します。
解決方法
次の回避策を使用して、これらの項目をスケジュールします。 スケジュールを作成するには、ForUpdateConfiguration パラメーターを指定して New-AzAutomationSchedule コマンドレットを使用します。 次に、New-AzAutomationSoftwareUpdateConfiguration コマンドレットを使用して、他のテナントのマシンを NonAzureComputer パラメーターに渡します。 次のサンプルは、その方法を示しています。
$nonAzurecomputers = @("server-01", "server-02")
$startTime = ([DateTime]::Now).AddMinutes(10)
$s = New-AzAutomationSchedule -ResourceGroupName mygroup -AutomationAccountName myaccount -Name myupdateconfig -Description test-OneTime -OneTime -StartTime $startTime -ForUpdateConfiguration
New-AzAutomationSoftwareUpdateConfiguration -ResourceGroupName $rg -AutomationAccountName $aa -Schedule $s -Windows -AzureVMResourceId $azureVMIdsW -NonAzureComputer $nonAzurecomputers -Duration (New-TimeSpan -Hours 2) -IncludedUpdateClassification Security,UpdateRollup -ExcludedKbNumber KB01,KB02 -IncludedKbNumber KB100
シナリオ: 原因不明の再起動
問題
[Reboot control]\(再起動制御\) オプションを [再起動しない] に設定しても、更新プログラムのインストール後にマシンが再起動します。
原因
Windows Update はいくつかのレジストリ キーによって変更でき、そのいずれかによって再起動の動作が変更されることがあります。
解決方法
「レジストリを編集して自動更新を構成する」と、「再起動の管理に使われるレジストリ キー」に記載されているレジストリ キーを確認して、マシンが正しく構成されていることを確認します。
シナリオ: 更新プログラムの展開で "起動できませんでした" とマシンに表示される
問題
あるマシンに Failed to start または Failed 状態が表示されます。 マシンの特定の詳細情報を表示すると、次のエラーが表示されます。
For one or more machines in schedule, UM job run resulted in either Failed or Failed to start state. Guide available at https://aka.ms/UMSucrFailed.
原因
このエラーは、次のいずれかの理由で発生することがあります。
- そのマシンはもう存在しません。
- マシンの電源が切れていて到達できません。
- マシンにネットワーク接続の問題があるため、マシン上のハイブリッド worker にアクセスできません。
- Log Analytics エージェントに対する更新があり、ソース コンピューター ID が変更されました。
- Automation アカウントで 200 個の同時ジョブの制限に達した場合、更新の実行が制限されました。 各展開は 1 つのジョブと見なされ、更新プログラムの展開内の各マシンは 1 つのジョブとカウントされます。 Automation アカウントで現在実行されている他のオートメーション ジョブや更新プログラムの展開は、すべて同時ジョブ制限の対象になります。
解決方法
REST API を使用することで、プログラミングによりさらに多くの詳細を取得できます。 ソフトウェア更新プログラムの構成マシン実行の一覧を取得する方法か、ソフトウェア更新プログラムの構成マシン実行を 1 つ ID 別に取得する方法については、「ソフトウェア更新プログラムの構成マシン実行」を参照してください。
該当する場合は、更新プログラムの展開に動的グループを使用します。 さらに、次の手順を実行できます。
- コンピューターまたはサーバーが要件を満たしていることを確認します。
- Hybrid Runbook Worker エージェントのトラブルシューティングツールを使用して、Hybrid Runbook Worker への接続を確認します。 このトラブルシューティング ツールの詳細については、更新エージェントの問題のトラブルシューティングに関する記事を参照してください。
シナリオ: 展開なしで更新プログラムがインストールされる
問題
Update Management に Windows マシンを登録すると、展開なしで更新プログラムがインストールされます。
原因
Windows では、更新プログラムは、使用可能になるとすぐに自動的にインストールされます。 この動作が原因で、更新プログラムをマシンに展開するスケジュールを設定しなかった場合、混乱が生じる可能性があります。
解決方法
レジストリ キー HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU の既定値は、4: auto download and install に設定されています。
Update Management クライアントの場合は、このキーを 3: auto download but do not auto install に設定することをお勧めします。
詳細については、自動更新の構成に関する記事を参照してください。
シナリオ:マシンが違うアカウントに既に登録されている
問題
次のエラー メッセージが表示されます。
Unable to Register Machine for Patch Management, Registration Failed with Exception System.InvalidOperationException: {"Message":"Machine is already registered to a different account."}
原因
マシンが既に Update Management 用の別のワークスペースにデプロイされています。
解決方法
- 「Update Management のポータルにマシンが表示されない」の手順に従って、マシンのレポート先が正しいワークスペースであることを確認します。
- Hybrid Runbook グループを削除することにより、マシン上のアーティファクトをクリーンアップしてから、再試行します。
シナリオ: マシンがサービスと通信できない
問題
次のいずれかのエラー メッセージが表示されます。
Unable to Register Machine for Patch Management, Registration Failed with Exception System.Net.Http.HttpRequestException: An error occurred while sending the request. ---> System.Net.WebException: The underlying connection was closed: An unexpected error occurred on a receive. ---> System.ComponentModel.Win32Exception: The client and server can't communicate, because they do not possess a common algorithm
Unable to Register Machine for Patch Management, Registration Failed with Exception Newtonsoft.Json.JsonReaderException: Error parsing positive infinity value.
The certificate presented by the service <wsid>.oms.opinsights.azure.com was not issued by a certificate authority used for Microsoft services. Contact your network administrator to see if they are running a proxy that intercepts TLS/SSL communication.
Access is denied. (Exception form HRESULT: 0x80070005(E_ACCESSDENIED))
原因
プロキシ、ゲートウェイ、またはファイアウォールがネットワーク通信をブロックしている可能性があります。
解像度
ネットワークを見直し、適切なポートとアドレスが許可されていることを確認します。 Update Management および Hybrid Runbook Worker で必要なポートとアドレスの一覧については、ネットワーク要件を参照してください。
シナリオ: 自己署名証明書を作成できない
問題
次のいずれかのエラー メッセージが表示されます。
Unable to Register Machine for Patch Management, Registration Failed with Exception AgentService.HybridRegistration. PowerShell.Certificates.CertificateCreationException: Failed to create a self-signed certificate. ---> System.UnauthorizedAccessException: Access is denied.
原因
Hybrid Runbook Worker が自己署名証明書を生成できませんでした。
解像度
C:\ProgramData\Microsoft\Crypto\RSA フォルダーへの読み取りアクセスがシステム アカウントにあることを確認してから、再試行します。
シナリオ:スケジュールされた更新が、MaintenanceWindowExceeded エラーで失敗しました
問題
更新の既定のメンテナンス時間は 120 分です。 メンテナンス期間は、最大 6 時間つまり 360 分まで増やすことができます。 エラー メッセージ For one or more machines in schedule, UM job run resulted in Maintenance Window Exceeded state. Guide available at https://aka.ms/UMSucrMwExceeded. が表示されることがあります
解決方法
正常に開始した後、更新プログラムの実行中にこれが発生した理由を理解するには、実行で影響を受けたマシンからのジョブ出力を確認します。 マシンからの特定のエラー メッセージが見つかれば、調査して対処することができます。
REST API を使用することで、プログラミングによりさらに多くの詳細を取得できます。 ソフトウェア更新プログラムの構成マシン実行の一覧を取得する方法か、ソフトウェア更新プログラムの構成マシン実行を 1 つ ID 別に取得する方法については、「ソフトウェア更新プログラムの構成マシン実行」を参照してください。
スケジュール済みの更新プログラムの展開で失敗したものがあれば編集し、メンテナンス期間を延長します。
メンテナンス期間の詳細については、更新プログラムのインストールに関する記事を参照してください。
シナリオ: マシンが "未評価" として表示され、HRESULT 例外が表示される
問題
- [コンプライアンス] に
Not assessedと表示されているマシンがあり、その下に例外メッセージが表示されます。 - ポータルに HRESULT エラー コードが表示されます。
原因
更新エージェント (Windows 上の Windows Update エージェント、Linux ディストリビューション用のパッケージ マネージャー) が正しく構成されていません。 Update Management は、必要な更新プログラム、パッチの状態、展開されたパッチの結果を提供するために、マシンの更新エージェントを利用しています。 この情報がないと、Update Management は必要なパッチやインストール済みのパッチを適切にレポートすることができません。
解決方法
マシンで更新プログラムをローカルで実行してみてください。 この操作が失敗する場合は、通常、更新エージェントの構成にエラーがあることを意味します。
この問題は、ネットワーク構成とファイアウォールの問題が原因で発生することがよくあります。 以下のチェックを使用して問題を修正します。
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 でも動作します。
シナリオ: 更新プログラムの実行で失敗状態が返される (Linux)
問題
更新プログラムの実行が開始されますが、実行中にエラーが発生します。
原因
考えられる原因:
- パッケージ マネージャーが異常です。
- 更新エージェント (Windows の場合は WUA、Linux の場合はディストリビューション固有のパッケージ マネージャー) が正しく構成されていません。
- 特定のパッケージが、クラウド ベースの修正プログラムの適用を妨げています。
- マシンにアクセスできません。
- 更新プログラムに、解決されていない依存関係がありました。
解決方法
正常に開始した後に更新プログラムの実行中にエラーが発生した場合は、実行で影響を受けたマシンからのジョブ出力を確認します。 マシンからの特定のエラー メッセージが見つかれば、調査して対処することができます。 Update Management で更新プログラムをデプロイするには、パッケージ マネージャーが正常である必要があります。
ジョブが失敗する直前に特定の修正プログラム、パッケージ、または更新プログラムが表示される場合は、次の更新プログラムのデプロイからこれらの項目を除外してみることができます。 Windows Update からログ情報を収集するには、「Windows Update のログ ファイル」を参照してください。
修正プログラムの問題を解決できない場合は、次の更新プログラムのデプロイが開始される前に、トラブルシューティングのために /var/opt/microsoft/omsagent/run/automationworker/omsupdatemgmt.log ファイルをコピーして、保存してください。
修正プログラムがインストールされない
マシンで更新プログラムがインストールされない
マシン上で直接更新プログラムを実行してみてください。 マシンで更新プログラムを適用できない場合は、トラブルシューティング ガイドで、発生する可能性のあるエラーの一覧をご覧ください。
更新プログラムがローカルで実行される場合は、Update Management からの VM の削除に関する記事のガイダンスに従って、マシン上でエージェントを削除し、再インストールしてみてください。
更新プログラムを利用できることはわかっているが、自分のマシンに利用可能として表示されない
これは、多くの場合、WSUS または Microsoft Configuration Manager から更新プログラムを取得するようにコンピューターが構成されているが、WSUS と Configuration Manager が更新プログラムを承認していない場合に発生します。
WSUS と SCCM 用にマシンが構成されているかどうかを確認するには、こちらの記事の「レジストリを編集して自動更新を構成する」セクション内のレジストリ キーに対して UseWUServer レジストリ キーを相互参照することでチェックできます。
更新プログラムは、WSUS 内で承認されていない場合、インストールされません。 次のクエリを実行して、Log Analytics 内で未承認の更新プログラムを確認できます。
Update | where UpdateState == "Needed" and ApprovalSource == "WSUS" and Approved == "False" | summarize max(TimeGenerated) by Computer, KBID, Title
インストールされると更新プログラムが表示されますが、コンピューター上で検索できない
更新プログラムは、多くの場合、他の更新プログラムによって置き換えられます。 詳細については、Windows Update のトラブルシューティング ガイドの「更新プログラムは置き換えられました」を参照してください。
Linux での更新プログラムの分類別インストール
分類 ([緊急更新プログラムとセキュリティ更新プログラム]) 別に Linux に更新プログラムを展開する場合、重要な注意事項があります。 これらの制限事項は、Update Management の概要に関するページに記載されています。
KB2267602 が常に欠落している
KB2267602 は Windows Defender の定義更新です。 これは毎日更新されます。
次のステップ
自分の問題が見つからない場合、または問題を解決できない場合は、追加のサポートを受けるために、次のいずれかのチャネルをお試しください。
- Azure フォーラムを通じて Azure エキスパートから回答を得ることができます。
- @AzureSupport (カスタマー エクスペリエンスを向上させるための Microsoft Azure の公式アカウント) に連絡する。
- Azure サポート インシデントを送信する。 その場合は、 Azure サポートのサイト に移動して、 [サポートの要求] をクリックします。