Update Management の概要
注意事項
この記事では、サービス終了 (EOL) 状態になった Linux ディストリビューションである CentOS について説明します。 適宜、使用と計画を検討してください。 詳細については、「CentOS のサポート終了に関するガイダンス」を参照してください。
重要
Automation Update Management は 2024 年 8 月 31 日に廃止されました。Azure Update Manager を使用することをお勧めします。 詳しくは、「Automation Update Management から Azure Update Manager への移行」のガイダンスに従ってください。
重要
Azure Log Analytics エージェント (別名 Microsoft Monitoring Agent (MMA)) は、2024 年 8 月に廃止されました。 Azure Automation Update Management ソリューションは、このエージェントに依存しており、Azure Monitoring Agent (AMA) では動作しないため、Azure Log Analytics エージェントが廃止されると問題が発生する可能性があります。 そのため、Azure Automation Update Management ソリューションを使用している場合は、ソフトウェア更新プログラムのニーズを満たすために、Azure Update Manager に移行することをお勧めします。 Azure Automation Update Management ソリューションのすべての機能は、提供終了日までに Azure Update Manager 上で利用できるようになります。
Azure Automation の Update Management を使用して、Azure での Windows および Linux 仮想マシン、オンプレミス環境やその他のクラウド環境での物理マシンまたは VM に対するオペレーティング システムの更新プログラムを管理できます。 利用可能な更新プログラムの状態をすばやく評価し、Update Management に報告しているマシンに必要な更新プログラムをインストールするプロセスを管理できます。
サービス プロバイダーは、Azure Lighthouse に複数の顧客テナントをオンボードしている場合があります。 Update Management を使用して、同じ Microsoft Entra テナントの複数のサブスクリプションのマシンまたは Azure Lighthouse を使用している複数のテナントに対する更新プログラムのデプロイの評価とスケジュールを実行できます。
Microsoft では、全体的な更新管理戦略の一部として考慮する必要がある、Azure VM または Azure Virtual machines スケール セットに対する更新プログラムの管理に役立つその他の機能を提供しています。
毎月リリースされる "重要な" 更新プログラムとセキュリティ更新プログラムによってセキュリティ コンプライアンスを維持するために Azure 仮想マシンの自動的な評価と更新に関心がある場合は、「VM ゲストの自動パッチ適用」を参照してください。 これは、お使いの Azure VM を (可用性セット内の VM を含めて) オフピーク時間中に自動更新するための代替更新管理ソリューションであり、これらの VM に対する更新プログラムの展開を Azure Automation の Update Management から管理するものとは別のソリューションです。
Azure 仮想マシン スケール セットを管理する場合は、スケール セット内のすべてのインスタンスの OS ディスクを安全かつ自動的にアップグレードするために、OS イメージの自動アップグレードを実行する方法を参照してください。
Update Management をデプロイしてマシンを管理できるようにする前に、次のセクションの情報を理解しておいてださい。
Update Management について
次の図に、接続されたすべての Windows Server と Linux サーバーに対する、Update Management によるセキュリティ更新プログラムの評価と適用の実行方法を示します。
Update Management では Azure Monitor ログと連携して、割り当てられている Azure と Azure 以外のマシンから収集された更新プログラムの評価と更新プログラムのデプロイの結果が、ログ データとして保存されます。 このデータを収集するために、Automation アカウントと Log Analytics ワークスペースがリンクされ、マシン上にこのワークスペースに報告するように構成された Windows および Linux 用の Log Analytics エージェントが必要です。
Update Management では、ワークスペースに接続されている System Center Operations Manager 管理グループのエージェントからのシステムの更新に関する情報の収集がサポートされています。 1 つのマシンを複数の Log Analytics ワークスペースに Update Management 用に登録すること (マルチホームとも言われます) は、サポートされていません。
次の表に、Update Management でサポートされている接続先ソースの概要を示します。
| 接続先ソース | サポートされています | 説明 |
|---|---|---|
| Windows | はい | Update Management によって、Log Analytics エージェントを使用して Windows マシンからシステムの更新プログラムと、必要な更新プログラムのインストールに関する情報が収集されます。 マシンは、Microsoft Update または Windows Server Update Services (WSUS) に報告する必要があります。 |
| Linux | はい | Update Management によって、Log Analytics エージェントを使用して Linux マシンからシステムの更新プログラムと、サポートされているディストリビューションに関する必要な更新プログラムのインストールに関する情報が収集されます。 マシンは、ローカルまたはリモートのリポジトリに報告する必要があります。 |
| Operations Manager 管理グループ | はい | Update Management によって、接続されている管理グループ内のエージェントからソフトウェアの更新に関する情報が収集されます。 Operations Manager エージェントから Azure Monitor ログへの直接接続は必要ありません。 ログ データは、管理グループから Log Analytics ワークスペースに転送されます。 |
Update Management に割り当てられたマシンによって、同期するように構成されているソースに基づいて、各自の最新の状態が報告されます。 Windows マシンは、Windows Server Update Services または Microsoft Update に報告するように構成する必要があり、Linux マシンは、ローカルまたはパブリックのリポジトリに報告するように構成する必要があります。 Update Management と Microsoft Configuration Manager を使用することもできます。詳しくは、「Update Management と Microsoft Configuration Manager の統合」をご覧ください。
Windows マシン上の Windows Update Agent (WUA) が WSUS に報告するように構成されている場合は、WSUS の Microsoft Update との最後の同期のタイミングによっては、Microsoft Update で示されるものと結果が一致しないことがあります。 この動作は、パブリック リポジトリではなくローカル リポジトリに報告するように構成されている Linux マシンにも当てはまります。 Windows マシンでは、コンプライアンス スキャンは既定で 12 時間ごとに実行されます。 Linux マシンでは、コンプライアンス スキャンは既定で 1 時間ごとに実行されます。 Log Analytics エージェントを再起動した場合、コンプライアンス スキャンは 15 分以内に開始されます。 マシンで更新プログラムのコンプライアンスのためのスキャンが完了すると、エージェントによって情報が Azure Monitor ログに一括転送されます。
スケジュールされたデプロイを作成することで、更新が必要なマシンへのソフトウェア更新プログラムのデプロイとインストールを実行できます。 Windows マシンの場合、"オプション" に分類されている更新プログラムはデプロイの範囲に含まれません。 デプロイの範囲には、必須の更新プログラムのみが含まれています。
スケジュールされたデプロイでは、適用可能な更新プログラムを受け取るターゲット マシンが定義されます。 これを行うには、特定のマシンを明示的に指定するか、特定のマシン セットのログ検索 (または指定された条件に基づいて動的に Azure VM を選択する Azure クエリ) に基づくコンピューター グループを選択します。 これらのグループは、Update Management を有効にするために構成を受け取るコンピューターのターゲット設定を制御するために使用されるスコープ構成とは異なります。 これにより、更新プログラムのコンプライアンスを実行および報告したり、承認された必要な更新プログラムをインストールしたりできなくなります。
デプロイを定義するときに、更新プログラムをインストールできる期間を承認および設定するスケジュールも指定します。 この期間は、メンテナンス期間と呼ばれます。 再起動が必要な場合、適切な再起動オプションを選択していれば、再起動のために 10 分間のメンテナンス期間が予約されます。 パッチ適用に予想よりも時間がかかり、メンテナンス期間の残りが 10 分を切った場合、再起動は行われません。
更新プログラム パッケージのデプロイがスケジュールされた後、Linux マシンで更新プログラムが評価用に表示されるまでに 2 時間から 3 時間かかります。 Windows マシンの場合、更新プログラムがリリースされてから評価用に表示されるまで 12 時間から 15 時間かかります。 更新プログラムのインストールの前後に、更新プログラムのコンプライアスのためのスキャンが実行され、ログ データの結果がワークスペースに転送されます。
更新プログラムは、Azure Automation の Runbook によってインストールされます。 これらの Runbook は表示できません。また、これらは構成不要です。 更新プログラムのデプロイを作成すると、対象に含めたマシンに対して、指定した時間にマスター更新 Runbook を開始するスケジュールが作成されます。 マスター Runbook によって、Windows 上で Windows Update エージェントを使用して必要な更新プログラムのインストールを開始する子 Runbook が各エージェントで開始されます。サポートされている Linux ディストリビューションでは該当するコマンドが実行されます。
更新プログラムのデプロイで指定された日時に、ターゲット マシンでデプロイが並列で実行されます。 まず、スキャンが実行され、その更新プログラムが依然として必須であることが確認されてからインストールされます。 WSUS クライアント マシンの場合、更新プログラムが WSUS で承認されていないと、更新プログラムのデプロイは失敗します。
制限
Update Management に適用される制限は次のとおりです。
| リソース | 制限 | メモ |
|---|---|---|
| 更新プログラムの展開ごとのマシンの数 | 1000 | |
| 更新プログラムのデプロイごとの動的グループの数 | 500 |
アクセス許可
更新プログラムのデプロイを作成および管理するには、特定のアクセス許可が必要です。 これらのアクセス許可の詳細については、Update Management へのロールベースのアクセスに関するページをご覧ください。
Update Management コンポーネント
Update Management では、このセクションで説明されているリソースが使用されます。 Update Management を有効にすると、これらのリソースが Automation アカウントに自動的に追加されます。
Hybrid Runbook Worker のグループ
Update Management を有効にすると、Log Analytics ワークスペースに直接接続されているすべての Windows マシンは、Update Management をサポートする runbook をサポートするために、自動的にシステム Hybrid Runbook Worker として構成されます。
Update Management で管理されている各 Windows マシンは、Automation アカウントの [システム ハイブリッド worker グループ] として、[ハイブリッド worker グループ] ペインに表示されます。 グループでは、Hostname FQDN_GUID の名前付け規則が使用されます。 アカウントの Runbook でこれらのグループを対象として指定することはできません。 指定しようとすると、失敗します。 これらのグループは、Update Management のみをサポートすることを目的としています。 Hybrid Runbook Worker として構成されている Windows マシンの一覧を表示する方法の詳細については、「Hybrid Runbook Workers の表示」を参照してください。
Update Management と Hybrid Runbook Worker グループ メンバーシップの両方に同じアカウントを使用すると、Windows マシンを Automation アカウント内のユーザー Hybrid Runbook Worker グループに追加して Automation Runbook をサポートできます。 この機能は、Hybrid Runbook Worker のバージョン 7.2.12024.0 で追加されました。
外部依存関係
Azure Automation Update Management は、ソフトウェア更新プログラムを配信するために、以下の外部依存関係に依存しています。
- ソフトウェア更新プログラム パッケージと、Windows ベースのマシンでのソフトウェア更新プログラムの適用性スキャンのために、Windows Server Update Services (WSUS) または Microsoft Update が必要です。
- マシンが WSUS サーバーまたは Microsoft Update に接続できるように、Windows ベースのマシン上に Windows Update エージェント (WUA) クライアントが必要です。
- Linux ベースのマシンで OS 更新プログラムを取得してインストールするための、ローカルまたはリモートのリポジトリ。
管理パック
次の管理パックが、Update Management によって管理されるマシンにインストールされます。 Operations Manager 管理グループが Log Analytics ワークスペースに接続されている場合、管理パックは Operations Manager 管理グループにインストールされます。 これらの管理パックを構成または管理する必要はありません。
- Microsoft System Center Advisor 更新プログラム評価インテリジェンス パック (Microsoft.IntelligencePacks.UpdateAssessment)
- Microsoft.IntelligencePack.UpdateAssessment.Configuration (Microsoft.IntelligencePack.UpdateAssessment.Configuration)
- 更新プログラムのデプロイ MP
Note
Log Analytics ワークスペースに接続される Operations Manager 1807 または 2019 管理グループに、ログ データを収集するように構成されたエージェントがある場合は、Microsoft.IntelligencePacks.AzureAutomation.HybridAgent.Init 規則内で IsAutoRegistrationEnabled パラメーターをオーバーライドして True に設定する必要があります。
管理パックの更新プログラムの詳細については、Azure Monitor ログへの Operations Manager の接続に関する記事を参照してください。
Note
Log Analytics エージェントを使用して Update Management でマシンを完全に管理するには、Windows 用の Log Analytics エージェント、または Linux 用 Log Analytics エージェントに更新する必要があります。 エージェントを更新する方法については、Operations Manager エージェントのアップグレード方法に関する記事を参照してください。 Operations Manager を使用する環境では、System Center Operations Manager 2012 R2 UR 14 以降を実行している必要があります。
データ収集の頻度
Update Management では、次のルールを使用して、管理対象のマシンのデータのスキャンが行われます。 管理対象のマシンの更新されたデータがダッシュボードに表示されるまでに、30 分から 6 時間かかる可能性があります。
各 Windows マシン - Update Management では、各マシンで 1 日に 2 回スキャンが行われます。
各 Linux マシン - Update Management では 1 時間ごとにスキャンが行われます。
Update Management を使用しているマシンでの Azure Monitor ログによる平均データ使用量は、1 か月あたり約 25 MB です。 この値は概数にすぎず、環境によって異なることがあります。 正確な使用量を把握するために、環境を監視することをお勧めします。 Azure Monitor ログのデータ使用状況の分析の詳細については、Azure Monitor ログの価格詳細に関する記事を参照してください。
更新プログラムの分類
次の表では、Update Management が Windows 更新プログラムでサポートされる分類が定義されています。
| 分類 | 説明 |
|---|---|
| 緊急更新プログラム | セキュリティに関連しない重大なバグを修正する、特定の問題に対する更新プログラムです。 |
| セキュリティ更新プログラム | 製品固有のセキュリティに関連する問題に対する更新プログラムです。 |
| 更新プログラムのロールアップ | 容易な展開のためにパッケージにまとめられた修正プログラムの累積セットです。 |
| Feature Pack | 製品リリース外で配布される製品の新機能です。 |
| Service Pack | アプリケーションに適用される修正プログラムの累積セットです。 |
| 定義の更新 | ウイルスまたは他の定義ファイルに対する更新プログラムです。 |
| ツール | 1 つまたは複数のタスクを完了するのに役立つユーティリティまたは機能です。 |
| 更新プログラム | 現在インストールされているアプリケーションまたはファイルに対する更新プログラムです。 |
次の表では、Linux 更新プログラムでサポートされる分類が定義されています。
| 分類 | 説明 |
|---|---|
| 緊急更新プログラムとセキュリティ更新プログラム | 特定の問題または製品固有のセキュリティに関連する問題に対する更新プログラムです。 |
| 他の更新プログラム | 本質的に重要ではない、またはセキュリティ更新プログラムではない、他のすべての更新プログラムです。 |
Note
Linux マシン用の更新プログラムの分類は、サポートされている Azure パブリック クラウド リージョンで使用される場合にのみ利用できます。 次の国内クラウド リージョンで Update Management を使用する場合、Linux の更新プログラムの分類はありません。
- Azure US Government
- 中国の 21Vianet
更新プログラムは、分類される代わりに、[他の更新プログラム] カテゴリ内で報告されます。
Update Management では、サポートされているディストリビューションによって発行されたデータが使用されます。具体的には、リリースされた OVAL (Open Vulnerability and Assessment Language) ファイルです。 インターネット アクセスはこれらの国内クラウドから制限されているため、Update Management によるファイルへのアクセスはできません。
Linux 更新プログラムの分類のロジック
評価のために、Update Management は更新プログラムをセキュリティ、クリティカル、その他の 3 つのカテゴリに分類します。 更新プログラムのこの分類は、次の 2 つのソースからのデータに従います。
- Open Vulnerability and Assessment Language(OVAL) ファイルは、更新プログラムが修正するセキュリティの問題または脆弱性に関するデータを含む Linux ディストリビューション ベンダーによって提供されます。
- YUM、APT、ZYPPER などのマシン上のパッケージ マネージャー。
修正プログラムを適用する場合、Update Management は更新プログラムを 2 つのカテゴリ (クリティカルとセキュリティ、その他) に分類します。 この更新プログラムの分類は、YUM、APT、ZYPPER などのパッケージ マネージャーからのデータのみに基づいています。
CentOS - 他のディストリビューションとは異なり、CentOS にはパッケージ マネージャーから利用できる分類データはありません。 CentOS マシン上で、次のコマンドに対してセキュリティ データを返すように構成されている場合、Update Management は分類に基づいてパッチを適用できます。
sudo yum -q --security check-update
Note
CentOS 上でネイティブ分類データを使用できるようにするためのサポートされている方法は現在ありません。 現時点では、顧客がこの機能を自分で使用可能にした場合には、できる範囲内のサポートのみを提供しています。
Redhat - Red Hat Enterprise バージョン 6 の更新プログラムを分類するには、YUM セキュリティ プラグインをインストールする必要があります。 Red Hat Enterprise Linux 7 では、プラグインは既に YUM 自体の一部であるため、何もインストールする必要はありません。 詳しくは、次の Red Hat のナレッジ記事をご覧ください。
Configuration Manager と Azure Update Management を統合する
PC、サーバー、モバイル デバイスを管理するために Microsoft Configuration Manager に投資してきたお客様は、Configuration Manager の強みと成熟度を活用してソフトウェア更新プログラムを管理できます。 Update Management を Configuration Manager と統合する方法については、「Configuration Manager と Azure Update Management を統合する」をご覧ください。
Windows でのサードパーティの更新プログラム
Update Management では、ローカルで構成された更新リポジトリに依存して、サポートされている Windows システム (WSUS または Windows Update) を更新します。 System Center Updates Publisher などのツールを使用すると、WSUS を使用してカスタム更新プログラムをインポートして発行することができます。 このシナリオでは、サードパーティ製ソフトウェアで Configuration Manager を更新リポジトリとして使用するマシンに、Update Management で更新プログラムを適用できます。 Updates Publisher を構成する方法については、「Install Updates Publisher」(Updates Publisher のインストール) を参照してください。
Windows Log Analytics エージェントを最新バージョンに更新する
Update Management が機能するには Log Analytics エージェントが必要です。 セキュリティの脆弱性を軽減し、バグ修正の恩恵を受けるために、Windows Log Analytics エージェント (Windows Microsoft Monitoring Agent (MMA) とも呼ばれます) を最新バージョンに更新することをお勧めします。 10.20.18053 (バンドル) および 1.0.18053.0 (拡張機能) より前のバージョンの Log Analytics エージェントでは、以前の証明書処理方法が使用されるため推奨されません。 以前の Windows Log Analytics エージェントは Azure に接続できなくなり、それらの Update Management は機能しなくなります。
次の手順に従って、Log Analytics エージェントを最新バージョンに更新する必要があります:
マシンの Log Analytics エージェントの現在のバージョンを確認します。インストール パス C:\ProgramFiles\Microsoft Monitoring Agent\Agent に移動し、HealthService.exe を右クリックして [プロパティ] を確認します。 [詳細] タブの [製品バージョン] フィールドには、Log Analytics エージェントのバージョン番号が表示されます。
Log Analytics エージェントのバージョンが 10.20.18053 (バンドル) および 1.0.18053.0 (拡張機能) より前である場合は、これらのガイドラインに従って、最新バージョンの Windows Log Analytics エージェントにアップグレードします。
Note
アップグレード プロセス中に、更新管理スケジュールが失敗する可能性があります。 計画されたスケジュールがない場合は、必ずこれを行います。
次のステップ
Update Management を有効にして使用する前に、「Update Management のデプロイを計画する」を確認します。
Update Management についてよく寄せられる質問については、「Azure Automation についてよく寄せられる質問」でご確認ください。