Automation Update Management から Azure Update Manager に移行する

  • [アーティクル]

適用対象: ✔️ Windows VM ✔️ Linux VM ✔️ オンプレミス環境 ✔️ Azure Arc 対応サーバー

この記事では、仮想マシンを Automation Update Management から Azure Update Manager に移行するためのガイダンスを提供します。

Azure Update Manager は、Azure、オンプレミス、マルチクラウドの各環境における Windows および Linux マシンのソフトウェア更新プログラムを管理および統括するための SaaS ソリューションを提供します。 これは Azure Automation Update Management ソリューションの進化版であり、単一のマシンに対して、または複数のマシンに対して大規模にソフトウェア更新プログラムを評価およびデプロイするための新しい機能が含まれています。

Azure Update Manager は、Azure VM 用には Microsoft Azure VM エージェントに、Arc 対応サーバー用には Azure Connected Machine Agent に依存するため、ソフトウェア更新ワークフローを管理するために AMA と MMA の両方が必要とされることはありません。 マシン上で初めて更新操作を実行すると、拡張機能がそのマシンにプッシュされ、エージェントとやり取りして不足している更新プログラムを評価し、更新プログラムをインストールします。

Note

  • Azure Automation Update Management ソリューションを使用している場合は、マシンのパッチ管理のニーズに対応するために、Azure Update Manager への移行を完了しないままマシンから MMA エージェントを削除しないことをお勧めします。 Azure Update Manager に移行せずにマシンから MMA エージェントを削除すると、そのマシンの修正プログラム適用ワークフローが中断されます。

  • Azure Automation Update Management のすべての機能は、非推奨になる日までに Azure Update Manager で利用できるようになります。

Azure portal エクスペリエンス (プレビュー)

このセクションでは、portal エクスペリエンス (プレビュー) を使って、スケジュールとマシンを Automation Update Management から Azure Update Manager に移行する方法について説明します。 最小限のクリックと自動化された方法でリソースを移動できるため、Automation Update Management ソリューション上にカスタマイズを構築していない場合は、これが最も簡単な移行方法です。

portal 移行エクスペリエンスにアクセスするには、使用できるエントリ ポイントがいくつかあります。

次のエントリ ポイントにある [今すぐ移行] ボタンを選びます。 選ぶと、スケジュールとマシンを Azure Update Manager に移行するプロセスが案内されます。 このプロセスは、最小限の労力で移行を完了できるように、ユーザー フレンドリでわかりやすく設計されています。

次のいずれかのエントリ ポイントから移行できます。

[今すぐ移行] ボタンを選ぶと、移行ブレードが開きます。 これには、マシンを含むすべてのリソースの概要と、Automation アカウントのスケジュールが表示されます。 既定では、このルートを使う場合、このブレードにアクセスした Automation アカウントが事前に選択されています。

Automation Update Management エントリ ポイントから移行する方法を示すスクリーンショット。

ここでは、Automation Update Management で有効になっており、Azure Update Manager に移行する必要がある Azure、Arc 対応サーバー、Azure 以外の Arc 対応サーバー、スケジュールの数を確認できます。 これらのリソースの詳細を確認することもできます。

移行ブレードには、移行されるリソースの概要が表示され、次に進む前に移行を見直して確認できます。 準備ができたら、移行プロセスを進めて、スケジュールとマシンを Azure Update Manager に移行できます。

Automation アカウントからすべてのリソースを移行する方法を示すスクリーンショット。

移行する必要があるリソースを確認したら、次の 3 手順のプロセスである移行プロセスに進むことができます。

  1. 前提条件

    これには、次の 2 つの手順が含まれます。

    a. Azure 以外の Arc 非対応マシンを Arc にオンボードする - これは、Arc 接続が Azure Update Manager の前提条件であるためです。 マシンの Azure Arc へのオンボードは無料です。完了すると、他の Azure マシンと同様にすべての管理サービスを利用できます。 詳細については、マシンのオンボード方法に関する Azure Arc のドキュメントを参照してください。

    b. PowerShell スクリプトをローカルにダウンロードして実行する - これは、移行を実行できるようにユーザー ID と適切なロールの割り当てを作成するために必要です。 このスクリプトを使って Automation アカウントが属するサブスクリプションのユーザー ID、Automation Update Management にオンボードされているマシン、動的クエリの一部であるスコープなどに適切な RBAC を付与することで、構成をマシンに割り当て、MRP 構成を作成し、更新ソリューションを削除することができます。 詳細については、Azure Update Manager のドキュメントを参照してください。

    移行の前提条件を示すスクリーンショット。

  2. Automation アカウントのリソースを Azure Update Manager に移行する

    移行プロセスの次の手順は、移行するマシン上で Azure Update Manager を有効にし、移行するスケジュールに対して同等のメンテナンス構成を作成することです。 [今すぐ移行] ボタンを選ぶと、MigrateToAzureUpdateManager Runbook が Automation アカウントにインポートされ、詳細ログが True に設定されます。

    Automation アカウントでワークロードを移行する方法を示すスクリーンショット。

    [開始] Runbook を選ぶと、Runbook に渡す必要があるパラメーターが表示されます。

    Runbook を起動してパラメーターを Runbook に渡す方法を示すスクリーンショット。

    フェッチするパラメーターとフェッチする必要がある場所の詳細については、「マシンとスケジュールの移行」を参照してください。 すべてのパラメーターを渡して Runbook を開始すると、マシン上で Azure Update Manager が有効になり、Azure Update Manager のメンテナンス構成の作成が開始されます。 Azure Runbook ログでスケジュールの実行と移行の状態を監視できます。

  3. Automation Update 管理からリソースをデボードする

    クリーンアップ スクリプトを実行して、Automation Update Management ソリューションからマシンをデボードし、Automation Update Management スケジュールを無効にします。

    [クリーンアップ スクリプトの実行] ボタンを選ぶと、Runbook DeboardFromAutomationUpdateManagement が Automation アカウントにインポートされ、その詳細ログは True に設定されます。

    移行後の実行方法を示すスクリーンショット。

    Runbook の [開始] を選ぶと、Runbook に渡すパラメーターの指定を求められます。 Runbook に渡されるパラメーターをフェッチする方法の詳細については、「Automation Update Management ソリューションからのデボード」を参照してください。

    Automation Update Management からデボードし、Runbook を開始する方法を示すスクリーンショット。

移行スクリプト (プレビュー)

移行 Runbook を使用すると、すべてのワークロード (マシンとスケジュール) を Automation Update Management から Azure Update Manager に自動的に移行できます。 このセクションでは、スクリプトの実行方法、バックエンドでスクリプトによって行われる内容、想定される動作、および制限事項 (該当する場合) について詳しく説明します。 このスクリプトを使用すると、1 つの Automation アカウント内のマシンとスケジュールをすべて一度に移行できます。 Automation アカウントを複数お持ちの場合は、すべての Automation アカウントに対して Runbook を実行する必要があります。

大まかに言うと、ご利用のマシンおよびスケジュールを Automation Update Management から Azure Update Manager に移行するには、次の手順に従う必要があります。

前提条件の概要

  1. 非 Azure マシンを Azure Arc にオンボードします。
  2. ユーザー ID とロールの割り当てを作成するための PowerShell スクリプトを、ご利用のシステムにローカルにダウンロードして実行します。 詳細な手順については、「ステップバイステップ ガイド」を参照してください。特定の前提条件も示されています。

手順の概要

  1. Automation Update Management から Azure Update Manager にマシンとスケジュールを移行するための移行 Automation Runbook を実行します。 詳細な手順については、「ステップバイステップ ガイド」を参照してください。
  2. クリーンアップ スクリプトを実行して、Automation Update Management かデボードします。 詳細な手順については、「ステップバイステップ ガイド」を参照してください。

サポートされていないシナリオ

  • 事前および事後タスクを含む更新スケジュールは、現時点では移行されません。
  • 非 Azure の保存されている検索クエリは移行されません。これらは手動で移行する必要があります。

制限事項と注意事項の完全な一覧については、この記事の最後のセクションを参照してください。

ステップバイステップ ガイド

上記の各手順で言及した情報について、以下で詳しく説明します。

前提条件 1: 非 Azure マシンを Arc にオンボードする

操作内容

Arc にオンボードされていないリソースは、移行 Automation Runbook によって無視されます。そのため、移行 Runbook を実行する前に、すべての非 Azure マシンを Azure Arc にオンボードすることが前提条件となります。 マシンを Azure Arc にオンボードするための手順に従ってください。

前提条件 2: PowerShell スクリプトを実行してユーザー ID とロールの割り当てを作成する

A. スクリプトを実行するための前提条件

  • PowerShell でコマンド Install-Module -Name Az -Repository PSGallery -Force を実行します。 前提条件スクリプトは Az.Modules によって異なります。 Az.Modules が存在しない場合、または更新されていない場合は、この手順が必要です。
  • この前提条件スクリプトを実行するには、マシン、スケジュール、ログ分析ワークスペース、Automation アカウントなどの Automation Update Management リソースが含まれているすべてのサブスクリプションに対して、"Microsoft.Authorization、roleAssignments、write" の各アクセス許可を持っている必要があります。 Azure ロールを割り当てる方法に関するページを参照してください。
  • Update Management のアクセス許可を取得している必要があります。

コマンドでモジュールをインストールする方法を示すスクリーンショット。

B. スクリプトを実行する

PowerShell スクリプト MigrationPrerequisiteScript をローカルにダウンロードして実行します。 このスクリプトでは、移行する Automation アカウントの AutomationAccountResourceId が入力として使用されます。

スクリプトをダウンロードして実行する方法を示すスクリーンショット。

AutomationAccountResourceId をフェッチするには、[Automation アカウント]>[プロパティ] の順に移動します。

リソース ID をフェッチする方法を示すスクリーンショット。

C: 確認

スクリプトを実行したら、Automation アカウント内にユーザー マネージド ID が作成されていることを確認します。 [Automation アカウント]>[ID]>[ユーザー割り当て]。

ユーザー マネージド ID が作成されたことを確認する方法を示すスクリーンショット。

D. スクリプトによるバックエンドでの操作内容

  1. Automation アカウント用の Az.Modules を更新する。これは、移行およびデボード スクリプトを実行するために必要です。

  2. Automation アカウントと同じサブスクリプションおよびリソース グループにユーザー ID を作成する。 ユーザー ID の名前は、AutomationAccount_aummig_umsi のようになります。

  3. Automation アカウントにユーザー ID をアタッチする。

  4. スクリプトによって、ユーザー マネージド ID には次のアクセス許可が割り当てられます: 必要とされる Update Management のアクセス許可

    1. この場合、このスクリプトを実行すると、この Automation アカウントで Automation Update Management にオンボードされているすべてのマシンをフェッチし、それぞれのサブスクリプション ID を解析して、必要な RBAC をユーザー ID に付与することができます。
    2. スクリプトでは、Automation アカウントが属するサブスクリプション上のユーザー ID に対して、適切な RBAC を付与して、MRP 構成をここで作成できるようにします。
    3. このスクリプトを実行すると、Log Analytics ワークスペースとソリューションに必要なロールを割り当てることができます。

手順 1: マシンとスケジュールの移行

この手順では、Automation Runbook を使用して、すべてのマシンとスケジュールを Automation アカウントから Azure Update Manager に移行する方法を説明します。

次の手順のようにします。

  1. Runbook ギャラリーから移行 Runbook をインポートし、発行します。 [ギャラリーの参照] から azure automation update を検索し、Migrate from Azure Automation Update Management to Azure Update Manager という名前の移行 Runbook をインポートして、この Runbook を発行します。

    Automation Update Management から移行する方法を示すスクリーンショット。

    Runbook では、PowerShell 5.1 がサポートされています。

    インポート時に Runbook が PowerShell 5.1 をサポートしていることを示すスクリーンショット。

  2. Runbook の詳細ログを True に設定します。

    詳細ログ レコードを設定する方法を示すスクリーンショット。

  3. Runbook を実行し、AutomationAccountResourceId や UserManagedServiceIdentityClientId など、必須のパラメーターを渡します。

    Runbook を実行し、必要なパラメーターを渡す方法を示すスクリーンショット。

    1. AutomationAccountResourceId は、[Automation アカウント]>[プロパティ] からフェッチできます。

      Automation アカウントのリソース ID をフェッチする方法を示すスクリーンショット。

    2. UserManagedServiceIdentityClientId は、[Automation アカウント]>[ID]>[ユーザー割り当て]>[ID]>[プロパティ]>[クライアント ID] からフェッチできます。

      クライアント ID をフェッチする方法を示すスクリーンショット。

    3. EnablePeriodicAssessmentForMachinesOnboardedToUpdateManagement を TRUE に設定すると、Automation Update Management にオンボードされているすべてのマシン上で定期評価プロパティが有効になります。

    4. MigrateUpdateSchedulesAndEnablePeriodicAssessmentonLinkedMachines を TRUE に設定すると、Automation Update Management 内のすべての更新スケジュールが Azure Update Manager に移行され、さらに、これらのスケジュールにリンクされているすべてのマシン上で定期評価プロパティが True に設定されます。

    5. Azure Update Manager のすべてのメンテナンス構成を作成する場所として ResourceGroupForMaintenanceConfigurations を指定する必要があります。 新しい名前を指定すると、すべてのメンテナンス構成を作成するためのリソース グループが作成されます。 ただし、既に存在しているリソース グループの名前を指定すると、その既存のリソース グループにすべてのメンテナンス構成が作成されます。

  4. SUC の実行状態および移行状態については、Azure Runbook ログを確認してください。

    Runbook ログを示すスクリーンショット。

バックエンドでの Runbook による操作内容

Runbook による移行では、次のタスクを実行します。

  • すべてのマシン上で定期評価を有効にします。
  • Automation アカウント内のすべてのスケジュールが Azure Update Manager に移行され、それぞれに対応して同じプロパティを持つメンテナンス構成が作成されます。

スクリプトについて

移行スクリプトの動作を次に示します。

  • 入力として取得された名前を持つリソース グループが、Automation アカウントのサブスクリプションに既に存在しているかどうかを確認します。 存在しない場合は、Cx で指定された名前を使用してリソース グループを作成します。 このリソース グループは、V2 用の MRP 構成を作成する場合に使われます。

  • スクリプトでは、事前および事後スクリプトに関連付けられた更新スケジュールは無視します。 事前および事後スクリプトの更新スケジュールについては、手動で移行します。

  • RebootOnly 設定は、Azure Update Manager では使用できません。 RebootOnly 設定が含まれるスケジュールは移行されません。

  • errored、expired、provisioningFailed、disabled の状態にある SUC をフィルターで除外し、[移行しない] としてマークし、そのような SUC は移行しないことを示すのに適切なログを出力します。

  • 構成割り当て名は、AUMMig_AAName_SUCName という形式の文字列になります。

  • Azure Resource Graph と照合して、この動的スコープがメンテナンス構成に既に割り当てられているかどうかを確認します。 割り当てられていない場合は、AUMMig_ AAName_SUCName_SomeGUID という形式の割り当て名でのみ割り当てを行います。

  • ログのセットの要約が出力ストリームに出力され、マシンと SUC の全体的な状態が示されます。

  • 詳細なログは詳細ストリームに出力されます。

  • 移行後、ソフトウェア更新プログラムの構成は、次の 4 つの移行状態のいずれかになります。

    • MigrationFailed
    • PartiallyMigrated
    • NotMigrated
    • Migrated

次の表に、各移行状態に関連付けられたシナリオを示します。

MigrationFailed PartiallyMigrated NotMigrated Migrated
ソフトウェア更新プログラムの構成に対してメンテナンス構成を作成できませんでした。 パッチ設定の適用に失敗したマシンの数がゼロではありません。 何らかのクライアント/サーバー エラー (多分内部サービス エラーのようなもの) が原因で、API からソフトウェア更新プログラムの構成を取得できませんでした。
構成割り当てに失敗したマシンの数がゼロではありません。 ソフトウェア更新プログラムの構成で、再起動の設定が再起動のみになっています。 現在、これは Azure Update Manager ではサポートされていません。
解決に失敗した、つまり、Azure Resource Graph に対するクエリの実行に失敗した動的クエリの数がゼロではありません。 ソフトウェア更新プログラムの構成に、事前および事後タスクが含まれています。 現在、Azure Update Manager で "事前および事後" はプレビュー段階にあり、当該スケジュールは移行されません。
動的スコープの構成割り当てエラーの数がゼロではありません。 ソフトウェア更新プログラムの構成で、DB のプロビジョニング状態が成功になっていません。
ソフトウェア更新プログラムの構成には、保存されている検索クエリがあります。 ソフトウェア更新プログラムの構成が DB でエラー状態になっています。
ソフトウェア更新プログラムの構成に関連付けられているスケジュールが、移行時に既に期限切れとなっています。
ソフトウェア更新プログラムの構成に関連付けられたスケジュールが無効になっています。
ソフトウェア更新プログラムの構成の移行中のハンドルされない例外があります。 パッチ設定の適用に失敗したマシンの数がゼロです。

And

構成割り当てに失敗したマシンの数がゼロです。

And

解決に失敗した、つまり、Azure Resource Graph に対するクエリの実行に失敗した動的クエリの数がゼロです。

And

動的スコープの構成割り当てエラーの数がゼロです。

And

ソフトウェア更新プログラムの構成には、保存されている検索クエリがありません。

上の表から、ソフトウェア更新プログラムの構成が特定の状態にある理由に対応するシナリオを特定するには、詳細、失敗、警告の各ログを調べて、エラー コードとエラー メッセージを取得します。

更新スケジュールの名前で検索を行えば、それに固有のログをデバッグ用に取得することもできます。

デバッグに固有のログを表示する方法を示すスクリーンショット。

手順 2: Automation Update Management ソリューションからのデボード

次の手順のようにします。

  1. Runbook ギャラリーから移行 Runbook をインポートします。 [ギャラリーの参照] から azure automation update を検索し、Deboard from Azure Automation Update Managemen という名前の移行 Runbook をインポートして、この Runbook を発行します。

    deaboard 移行 Runbook をインポートする方法を示すスクリーンショット。

    Runbook では、PowerShell 5.1 がサポートされています。

    デボード時に Runbook が PowerShell 5.1 をサポートしていることを示すスクリーンショット。

  2. Runbook の詳細ログを True に設定します。

    デボード時のログ詳細レコードの設定を示すスクリーンショット。

  3. Runbook を開始し、Automation AccountResourceId、UserManagedServiceIdentityClientId などのパラメーターを渡します。

    デボード時に Runbook を開始し、パラメーターを渡す方法を示すスクリーンショット。

    AutomationAccountResourceId は、[Automation アカウント]>[プロパティ] からフェッチできます。

    デボード時にリソース ID をフェッチする方法を示すスクリーンショット。

    UserManagedServiceIdentityClientId は、[Automation アカウント]>[ID]>[ユーザー割り当て]>[ID]>[プロパティ]>[クライアント ID] からフェッチできます。

    デボード時にクライアント ID をフェッチする方法を示すスクリーンショット。

  4. Azure Runbook ログで、マシンとスケジュールのデボードの状態を確認します。

    デボード時に Runbook がログする方法を示すスクリーンショット。

バックエンドでのデボード スクリプトによる操作内容

  • この Automation アカウントに存在するソフトウェア更新プログラムの構成すべてについて、基になるすべてのスケジュールを無効にします。 これは、部分的に V2 に移行された SUC に対して Patch-MicrosoftOMSComputers という Runbook がトリガーされないようにするために行われます。
  • V1 の Automation Update Management からデボードする Automation アカウントについて、リンクされた Log Analytics ワークスペースから更新プログラム ソリューションを削除します。
  • 無効にされたすべての SUC のログの要約に加えて、リンクされた Log Analytics ワークスペースからの更新プログラム ソリューションの削除の状態も出力ストリームに出力されます。
  • 詳細なログは詳細ストリームに出力されます。

移行プロセスについての注意事項:

  • 事前および事後タスクを含むスケジュールは、現時点では移行されません。
  • 非 Azure の保存されている検索クエリは移行されません。
  • 移行およびデボード Runbook が動作するには、Az.Modules が更新されている必要があります。
  • 前提条件スクリプトでは、Az.Modules を最新バージョンの 8.0.0 に更新します。
  • MRP スケジュールの StartTime は、ソフトウェア更新プログラムの構成の nextRunTime と同等です。
  • Log Analytics からのデータは移行されません。
  • ユーザー マネージド ID では、テナント間シナリオはサポートされていません。
  • RebootOnly 設定は、Azure Update Manager では使用できません。 RebootOnly 設定を含むスケジュールは移行されません。
  • 繰り返しの場合、Automation スケジュールでは時間単位、日単位、週単位、月単位のスケジュールに対して (1 から 100) の値をサポートしますが、Azure Update Manager のメンテナンス構成では、時間単位の場合は (6 から 35)、日単位、週単位、月単位の場合は (1 から 35) をサポートします。
    • たとえば、Automation スケジュールの繰り返しが 100 時間ごとである場合、同等のメンテナンス構成スケジュールでは、それは 100/24 = 4.16 ごととなり、最も近い値に丸められます -> メンテナンス構成の繰り返しは 4 日ということになります。
    • たとえば、Automation スケジュールの繰り返しが 1 時間ごとである場合、同等のメンテナンス構成スケジュールではそれは 6 時間ごととなります。
    • 週単位と日単位の場合も同じ規則を適用します。
      • Automation スケジュールの日単位の繰り返しの値が、たとえば、100 日である場合は、100/7 = 14.28 となり、最も近い値に丸められます -> メンテナンス構成スケジュールの繰り返しは 14 週ごとになります。
      • Automation スケジュールの週単位の繰り返しの値が、たとえば、100 週である場合、100/4.34 = 23.04 となり、最も近い値に丸められます -> メンテナンス構成スケジュールの繰り返しは 23 か月ごとになります。
      • 100 週ごとに繰り返し、かつ金曜日に実行する必要がある Automation スケジュールの場合。 メンテナンス構成に変換すると、23 か月ごと (100/4.34) になります。 ただし、Azure Update Manager では、23 か月ごとに、しかも該当する月の必ず金曜日に実行するという方法がとれないため、そのスケジュールは移行されません。
      • Automation スケジュールの繰り返しが 35 か月を超える場合、メンテナンス構成では、それは常に 35 か月の繰り返しとなります。
    • SUC では、メンテナンス期間として 30 分から 6 時間がサポートされます。 MRP では、1 時間 30 分から 4 時間の期間がサポートされます。
      • たとえば、SUC のメンテナンス期間が 30 分である場合、同等の MRP スケジュールではそれは 1 時間 30 分間になります。
      • たとえば、SUC のメンテナンス期間が 6 時間である場合、同等の MRP スケジュールではそれは 4 時間になります。
  • 移行 Runbook を複数回実行する場合 (たとえば、すべての Automation スケジュールを移行してから再びすべてのスケジュールを移行しようとした場合)、移行 Runbook は同じロジックを実行します。 SUC に新しい変更が存在する場合は、再度実行すると MRP スケジュールが更新されます。 重複した構成の割り当ては行われません。 また、スケジュールが有効になっている Automation スケジュールに対してのみ操作が行われます。 SUC は、以前に移行されている場合、次の回ではスキップされます。その基になるスケジュールが無効にされるからです。
  • 最後に、Azure Resource Graph からさらに多くのマシンを、Azure Update Manager の場合と同様に解決できます。ただし、Hybrid Runbook Worker からレポートされているかどうかを確認することはできません。これは、動的クエリと Hybrid Runbook Worker の共通部分であった Automation Update Management の場合とは異なります。

手動移行ガイダンス

さまざまな機能を移行するためのガイダンスを次の表に示します。

シナリオ番号 機能 Automation Update Management Azure Update Manager Azure portal を使用した手順 API またはスクリプトを使用した手順
1 Azure 以外のマシンのパッチ管理。 Arc 接続の有無にかかわらず実行できます。 Azure Arc は、Azure 以外のマシンの前提条件です。 1.サービス プリンシパルを作成する
2. インストール スクリプトを生成する
3. エージェントをインストールして Azure に接続する		 1.サービス プリンシパルを作成する
2.インストール スクリプトを生成する
3. エージェントをインストールして Azure に接続する
2 定期的な評価を有効にして、数時間ごとに最新の更新プログラムを自動的に確認します。 マシンは、Windows の場合は 12 時間ごと、Linux の場合は 3 時間ごとに、最新の更新プログラムを自動的に受け取ります。 定期評価は、使用しているマシンでの更新の設定です。 有効になっている場合、Update Manager はマシンの更新プログラムを 24 時間ごとにフェッチし、最新の更新状態を表示します。 1.単一のマシン
2. 大規模
3. ポリシーを使用した大規模		 1.Azure VM 用
2.Arc 対応 VM 用
3 静的更新の展開スケジュール (更新プログラム展開の対象となるマシンの静的な一覧)。 Automation Update Management には独自のスケジュールがありました。 Azure Update Manager により、スケジュールのメンテナンス構成オブジェクトが作成されます。 そのため、このオブジェクトを作成し、すべてのスケジュール設定を Automation Update Management から Azure Update Manager スケジュールにコピーする必要があります。 1.単一の VM
2. 大規模
3. ポリシーを使用した大規模		 静的スコープを作成する
4 動的更新のデプロイ スケジュール (リソース グループやタグなどを使用して実行時に動的に評価されるマシンのスコープを定義する)。 静的更新スケジュールと同じです。 静的更新スケジュールと同じです。 動的スコープを追加する 動的スコープを作成する
5 Azure Automation Update Management から VM を削除する。 手順 1、2、3 を完了したら、Azure Update 管理オブジェクトをクリーンアップする必要があります。 Update Management ソリューションを削除する
 NA
6 報告 Log Analytics クエリを使用したカスタム更新レポート。 更新データは Azure Resource Graph (ARG) に保存されます。 お客様は ARG データに対してクエリを実行して、カスタム ダッシュボードやブックなどを作成できます。 Log Analytics に保存されている古い Automation Update Management データにはアクセスできますが、ARG にデータを移行する機能はありません。 Azure Update Manager による仮想マシンへの修正プログラム適用後、ARG に保存されるデータにアクセスするための ARG クエリを記述できます。 ARG クエリを使用すると、次の手順を使用してダッシュボードとブックを作成できます。
1. Log structure of Azure Resource Graph 更新データのログ構造
2. ARG クエリのサンプル
3. ブックを作成する		 NA
7 事前および事後スクリプトを使用してワークフローをカスタマイズする。 Automation Runbook として利用できます。 事前および事後スクリプトについてはパブリック プレビューを試し、機能が一般提供に入ったら、運用ワークロード上でこの機能を使用することをお勧めします。 事前および事後イベントの管理 (プレビュー)
8 環境の更新データに基づいてアラートを作成する アラートは、Log Analytics に保存されている更新データに対して設定できます。 アラートについては非運用マシン上でパブリック プレビューを試し、機能が一般提供に入ったら、運用ワークロード上でこの機能を使用することをお勧めします。 アラートを作成する (プレビュー)

次のステップ