自動化された Runbook スクリプトを使用した移行
適用対象: ✔️ Windows VM ✔️ Linux VM ✔️ オンプレミス環境 ✔️ Azure Arc 対応サーバー
この記事では、移行 Runbook を使用して、すべてのワークロード (マシンとスケジュール) を Automation Update Management から Azure Update Manager に自動的に移行する方法について詳しく説明します。
以下のセクションでは、スクリプトを実行する方法、スクリプトによってバックエンドで実行される内容、想定される動作、制限 (該当する場合) について詳しく説明します。 このスクリプトを使用すると、1 つの Automation アカウント内のマシンとスケジュールをすべて一度に移行できます。 Automation アカウントを複数お持ちの場合は、すべての Automation アカウントに対して Runbook を実行する必要があります。
大まかに言うと、ご利用のマシンおよびスケジュールを Automation Update Management から Azure Update Manager に移行するには、次の手順に従う必要があります。
サポートされていないシナリオ
- 非 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 と AutomationAccountAzureEnvironment を入力として受け取ります。 AutomationAccountAzureEnvironment で受け入れられる値は、Automation アカウントが属するクラウドを示す AzureCloud、AzureUSGovernment、AzureChina です。
AutomationAccountResourceId をフェッチするには、[Automation アカウント]>[プロパティ] の順に移動します。
C: 確認
スクリプトを実行したら、Automation アカウント内にユーザー マネージド ID が作成されていることを確認します。 [Automation アカウント]>[ID]>[ユーザー割り当て]。
D. スクリプトによるバックエンドでの操作内容
Automation アカウント用の Az.Modules を更新する。これは、移行およびデボード スクリプトを実行するために必要です。
Automation アカウントが属する Azure クラウド環境を格納する AutomationAccountAzureEnvironment という Automation 変数を作成します。
Automation アカウントと同じサブスクリプションおよびリソース グループにユーザー ID を作成する。 ユーザー ID の名前は、AutomationAccount_aummig_umsi のようになります。
Automation アカウントにユーザー ID をアタッチする。
スクリプトによって、ユーザー マネージド ID には次のアクセス許可が割り当てられます: 必要とされる Update Management のアクセス許可
- この場合、このスクリプトを実行すると、この Automation アカウントで Automation Update Management にオンボードされているすべてのマシンをフェッチし、それぞれのサブスクリプション ID を解析して、必要な RBAC をユーザー ID に付与することができます。
- スクリプトでは、Automation アカウントが属するサブスクリプション上のユーザー ID に対して、適切な RBAC を付与して、MRP 構成をここで作成できるようにします。
- このスクリプトを実行すると、Log Analytics ワークスペースとソリューションに必要なロールを割り当てることができます。
Microsoft.Maintenance および Microsoft.EventGrid リソース プロバイダーへの必要なサブスクリプションの登録。
手順 1: マシンとスケジュールの移行
この手順では、Automation Runbook を使用して、すべてのマシンとスケジュールを Automation アカウントから Azure Update Manager に移行する方法を説明します。
次の手順のようにします。
Runbook ギャラリーから移行 Runbook をインポートし、発行します。 [ギャラリーの参照] から azure automation update を検索し、Migrate from Azure Automation Update Management to Azure Update Manager という名前の移行 Runbook をインポートして、この Runbook を発行します。
Runbook では、PowerShell 5.1 がサポートされています。
Runbook の詳細ログを True に設定します。
Runbook を実行し、AutomationAccountResourceId や UserManagedServiceIdentityClientId など、必須のパラメーターを渡します。
AutomationAccountResourceId は、[Automation アカウント]>[プロパティ] からフェッチできます。
UserManagedServiceIdentityClientId は、[Automation アカウント]>[ID]>[ユーザー割り当て]>[ID]>[プロパティ]>[クライアント ID] からフェッチできます。
EnablePeriodicAssessmentForMachinesOnboardedToUpdateManagement を TRUE に設定すると、Automation Update Management にオンボードされているすべてのマシン上で定期評価プロパティが有効になります。
MigrateUpdateSchedulesAndEnablePeriodicAssessmentonLinkedMachines を TRUE に設定すると、Automation Update Management 内のすべての更新スケジュールが Azure Update Manager に移行され、さらに、これらのスケジュールにリンクされているすべてのマシン上で定期評価プロパティが True に設定されます。
Azure Update Manager のすべてのメンテナンス構成を作成する場所として ResourceGroupForMaintenanceConfigurations を指定する必要があります。 新しい名前を指定すると、すべてのメンテナンス構成を作成するためのリソース グループが作成されます。 ただし、既に存在しているリソース グループの名前を指定すると、その既存のリソース グループにすべてのメンテナンス構成が作成されます。
SUC の実行状態および移行状態については、Azure Runbook ログを確認してください。
バックエンドでの Runbook による操作内容
Runbook による移行では、次のタスクを実行します。
- すべてのマシン上で定期評価を有効にします。
- Automation アカウント内のすべてのスケジュールが Azure Update Manager に移行され、それぞれに対応して同じプロパティを持つメンテナンス構成が作成されます。
スクリプトについて
移行スクリプトの動作を次に示します。
入力として取得された名前を持つリソース グループが、Automation アカウントのサブスクリプションに既に存在しているかどうかを確認します。 存在しない場合は、顧客が指定した名前を使ってリソース グループを作成します。 このリソース グループは、V2 用の MRP 構成を作成する場合に使われます。
RebootOnly 設定は、Azure Update Manager では使用できません。 RebootOnly 設定が含まれるスケジュールは移行されません。
errored、expired、provisioningFailed、disabled の状態にある SUC をフィルターで除外し、[移行しない] としてマークし、そのような SUC は移行しないことを示すのに適切なログを出力します。
構成割り当て名は、AUMMig_AAName_SUCName という形式の文字列になります。
Azure Resource Graph と照合して、この動的スコープがメンテナンス構成に既に割り当てられているかどうかを確認します。 割り当てられていない場合は、AUMMig_ AAName_SUCName_SomeGUID という形式の割り当て名でのみ割り当てを行います。
事前または事後のタスクが構成されているスケジュールの場合、スクリプトは、メンテナンス前およびメンテナンス後イベント用の事前または事後タスクと Event Grid サブスクリプションに、Runbook 用の Automation Webhook を作成します。 詳細については、Azure Update Manager での事前と事後のしくみに関する記事を参照してください
ログのセットの要約が出力ストリームに出力され、マシンと SUC の全体的な状態が示されます。
詳細なログは詳細ストリームに出力されます。
移行後、ソフトウェア更新プログラムの構成は、次の 4 つの移行状態のいずれかになります。
- MigrationFailed
- PartiallyMigrated
- NotMigrated
- Migrated
次の表に、各移行状態に関連付けられたシナリオを示します。
| MigrationFailed | PartiallyMigrated | NotMigrated | Migrated |
|---|---|---|---|
| ソフトウェア更新プログラムの構成に対してメンテナンス構成を作成できませんでした。 | パッチ設定の適用に失敗したマシンの数がゼロではありません。 | 何らかのクライアント/サーバー エラー (多分内部サービス エラーのようなもの) が原因で、API からソフトウェア更新プログラムの構成を取得できませんでした。 | |
| 構成割り当てに失敗したマシンの数がゼロではありません。 | ソフトウェア更新プログラムの構成で、再起動の設定が再起動のみになっています。 現在、これは Azure Update Manager ではサポートされていません。 | ||
| 解決に失敗した、つまり、Azure Resource Graph に対するクエリの実行に失敗した動的クエリの数がゼロではありません。 | |||
| 動的スコープの構成割り当てエラーの数がゼロではありません。 | ソフトウェア更新プログラムの構成で、DB のプロビジョニング状態が成功になっていません。 | ||
| ソフトウェア更新プログラムの構成には、保存されている検索クエリがあります。 | ソフトウェア更新プログラムの構成が DB でエラー状態になっています。 | ||
| ソフトウェア更新プログラム構成には、正常に移行されていない事前または事後のタスクがあります。 | ソフトウェア更新プログラムの構成に関連付けられているスケジュールが、移行時に既に期限切れとなっています。 | ||
| ソフトウェア更新プログラムの構成に関連付けられたスケジュールが無効になっています。 | |||
| ソフトウェア更新プログラムの構成の移行中のハンドルされない例外があります。 | パッチ設定の適用に失敗したマシンの数がゼロです。 And 構成割り当てに失敗したマシンの数がゼロです。 And 解決に失敗した、つまり、Azure Resource Graph に対するクエリの実行に失敗した動的クエリの数がゼロです。 And 動的スコープの構成割り当てエラーの数がゼロです。 And ソフトウェア更新プログラムの構成には、保存されている検索クエリがありません。 |
上の表から、ソフトウェア更新プログラムの構成が特定の状態にある理由に対応するシナリオを特定するには、詳細、失敗、警告の各ログを調べて、エラー コードとエラー メッセージを取得します。
更新スケジュールの名前で検索を行えば、それに固有のログをデバッグ用に取得することもできます。
手順 2: Automation Update Management ソリューションからのデボード
次の手順のようにします。
Runbook ギャラリーから移行 Runbook をインポートします。 [ギャラリーの参照] から azure automation update を検索し、Deboard from Azure Automation Update Managemen という名前の移行 Runbook をインポートして、この Runbook を発行します。
Runbook では、PowerShell 5.1 がサポートされています。
Runbook の詳細ログを True に設定します。
Runbook を開始し、Automation AccountResourceId、UserManagedServiceIdentityClientId などのパラメーターを渡します。
AutomationAccountResourceId は、[Automation アカウント]>[プロパティ] からフェッチできます。
UserManagedServiceIdentityClientId は、[Automation アカウント]>[ID]>[ユーザー割り当て]>[ID]>[プロパティ]>[クライアント ID] からフェッチできます。
Azure Runbook ログで、マシンとスケジュールのデボードの状態を確認します。
バックエンドでのデボード スクリプトによる操作内容
- この Automation アカウントに存在するソフトウェア更新プログラムの構成すべてについて、基になるすべてのスケジュールを無効にします。 これは、部分的に V2 に移行された SUC に対して Patch-MicrosoftOMSComputers という Runbook がトリガーされないようにするために行われます。
- V1 の Automation Update Management からデボードする Automation アカウントについて、リンクされた Log Analytics ワークスペースから更新プログラム ソリューションを削除します。
- 無効にされたすべての SUC のログの要約に加えて、リンクされた Log Analytics ワークスペースからの更新プログラム ソリューションの削除の状態も出力ストリームに出力されます。
- 詳細なログは詳細ストリームに出力されます。