みなさん、こんにちは。ネットワールドでSA（ソリューションアーキテクト）として活動している後藤です。
「Azure MigrateでVMware仮想マシンをAzure Local に移行してみた」ということで、Microsoft Azureのサービスである「Azure Migrate」を使用して、VMware環境の仮想マシンをAzure Local環境に移行しよう！ という記事の5回目になります。
過去記事については、第4回の冒頭でリンクを張っているので、そちらでご参照ください。
これまでは、環境準備から実際の移行作業の流れと手順を紹介しました。
今回は、一連の作業の中でのTipsを紹介したいと思います。
1：最初に注意事項と免責事項
本記事で取り扱っているAzure MigrateベースのVMwareからAzure Localへの移行（Azure Migrate based VMware migration for Azure Local）は、執筆時点（2025/05末）でパブリックプレビューのサービスとなります。
執筆時点の情報になりますので、もしかしたら明日にはサービス仕様が変更されているかもしれません。最新の情報はMicrosoftの公式ドキュメントをご参照ください。
また、本記事に従って作業を行って発生した問題について、弊社は責任を負いかねますので、自己責任でお願いします。
2：静的IPアドレスの移行
VMware環境の仮想マシンに静的IPアドレスを振っていた場合、そのままIPアドレス設定を移行するためには、仮想マシン上で作業が必要になります。
Microsoftの公式ドキュメントはこちらです。
この静的IPアドレス移行は、Windows、Linuxどちらの仮想マシンでも手順が用意されています。
今回はWindows上で手動で設定する手順と実際の操作を紹介したいと思います。大規模展開用のGPOなどは公式ドキュメントはご参照ください。
2-1：事前チェック
静的IPアドレス移行を行う場合、いくつかの前提条件をクリアする必要があります。
- VMware Toolsが必須
- 仮想マシンに採番した静的IPアドレスは、Azure Local環境に設定されている論理ネットワークのIPプールの範囲内であること
- 仮想マシン上でファイルをコピーする、スクリプトを実行する、およびタスクスケジューラーを修正できる権限を持ったユーザーアカウントをもっていること
このあたりの条件が揃わないと、静的IPアドレス移行は実施できませんのでご注意ください。
2-2：スクリプト展開／実行
公式ドキュメントに掲示しているURLからモジュールをダウンロードします。
ダウンロードファイルのURLの掲示は控えますので、公式ドキュメントからダウンロードをお願いします。執筆時点（2025/06初旬）では先に掲示した公式ドキュメントの「静的IP移行パッケージについて」の項にリンクがあります（図1）。
そちらのURLから「Prepare-MigratedVM.zip」をダウンロードし、解凍後仮想マシンにコピーします。
Windows版なので、コピーするファイルは圧縮ファイル内の「Windows」フォルダ以下のものだけで問題ないです。コピー先も適当なフォルダで大丈夫です。初期設定を実行するユーザーとシステムアカウントがアクセス可能なフォルダであれば、たとえば「C:\temp」とかでOKです。ポイントはフォルダ構成を変更しない、だけです（図2）。
Prepare-MigratedVM.ps1が実際に実行するスクリプト、「StaticIPMigration」配下はPrepare-MigratedVM.ps1からコールされるスクリプト群になっています。
また、ログファイルなども「StaticIPMigration」フォルダ配下に出力されます。
配置が完了したら、Prepare-MigratedVM.ps1を「-StaticIPMigration」オプション付きで実行します。実行結果は図3のような感じになるはずです。
実行内容を見ていると、現在のIPアドレス設定を読み取ったうえで、「Set-StaticIPConfiguration」というタスクを登録しているようですね。
タスクスケジューラを参照すると、たしかに「Set-StaticIPConfiguration」というタスクが登録され、システム起動時に実行されるようになっています（図4）。
システム起動時なので、仮想マシンを再起動すると自動的に実行されます。図3はタスク登録後再起動した後の状態なのですが、実行結果が「実行中（0x41301）」になっていることがわかります。
通常、タスクスケジューラで自動実行され正常に完了したタスクは、実行結果が「0x0」になるので、はて……？ という感じですね。
2-3：スクリプトの確認と修正
タスクの中を見てみると、Set-StaticIPConfiguration.ps1を実行しているだけです（図5）。
手動で実行すると正常終了するところから、.ps1スクリプトには問題ないことがわかりました。
いろいろと実行ユーザーなどを変更するとタスクが正常に動くことから、「システムアカウントで実行すると「実行中（0x41301）」になる」ところまで切り分けられ、PowerShellのExecutionPolicy（実行ポリシー）あたりの問題ではないかとあたりがつきました。
ということで、タスクスケジューラの設定を変更します。
実行するコマンドレットを以下のように変更します（図6）。
【変更前】
powershell.exe C:\temp\StaticIPMigration\Set-StaticIPConfiguration.ps1
【変更後】
powershell.exe -ExecutionPolicy Bypass -File "C:\temp\StaticIPMigration\Set-StaticIPConfiguration.ps1"
ファイルのパスは、実際の環境に応じて変更してくください。
やっている内容としては、PowerShell実行時にExecutionPolicy（実行ポリシー）のチェックを文字通りバイパス（Bypass）するようにしています。
本設定の可否については、自社のセキュリティポリシーに基づいて判断していただけますようお願いします。
こうすることで図6のとおり実行結果が0x0となり、システム起動時にスクリプトが実行されるようになりました。
また、正常にタスクスケジューラにてシステム起動時にPowerShellスクリプトが実行されることで、Azure Localの環境で仮想マシンが起動した際に、VMware環境で取得したIPアドレスの設定に基づいて、静的IPアドレス設定を実施して、タスクスケジューラの登録を削除する、という動作が実行されます。
これにより、静的IPアドレス移行が実現します。
論理ネットワークのIPアドレスプールの範囲内に入っていれば、図7のようにプール内の途中のIPアドレスでも認識して「Azure Arc VMに割り振られたIPアドレス」として認識してくれます。
なお、本スクリプトが動くと、「StaticIPMigration」フォルダにログを出力する仕掛けになっており、ログ（タスクスケジューラが起動するスクリプトのログは「Set-StaticIPMigration-<実行日付>-<実行時間>.log」というファイル名です）が出力されない＝タスクが動いていない、と切り分けることができました。
ログの中を見ると、VMware環境にいるときは、最初のスクリプト実行時に生成されたjsonファイル（InterfaceConfigurations.json）の中を見て、ファイル生成時と同一環境であればスクリプト終了、異なる環境であればIPアドレスをjsonファイルに基づいて設定する、という動きをしているようです。
3：ゲスト管理の有効化
VMware環境から仮想マシンを移行してくると、Azure Arc VMのメリットの一つである「Azureからの管理」を実現するためのキーコンポーネントである「ゲスト管理」が無効の状態でAzure Arcのリソースが作成されます。
Azure Localで仮想マシンをAzureポータルから作成する場合は、ゲスト管理を作成時から有効にすることができますが、Azure Migrateで移行してきた仮想マシンは明示的に有効化する必要があります。
こちらのゲスト管理を有効化したいとおもいます。ゲスト管理の有効化に関するMicrosoftの公式ドキュメントはこちらです。
3-1：ゲスト管理の有効化・Azureポータルからの作業
Azureポータルから、ゲスト管理を有効化したい仮想マシンのAzure Arcページを開きます（図8）。
図8のとおり、ゲスト管理が「無効」になっています。
こちらの「構成」という項目がリンクになっているので、こちらをクリックします。
もしくは左ツリーの「設定」→「構成」でも問題ないです。
「VM拡張機能」のページに遷移します（図9）。
「ゲスト管理」の項にある「有効にする」をクリックします。
事前作業が自動的に実施されますので、そのままの状態で待機します（図10）。
自動的に画面が遷移し、自動生成されたスクリプトが表示されます（図11）。
表示されているスクリプトを仮想マシン上で実行する必要があります。
スクリプト実行後にこの画面からの作業を継続するため、この画面はそのままにしておきます。
3-2：ゲスト管理有効化のためのスクリプト実行・仮想マシンからの作業
図11の画面に表示されたスクリプトをコピーし、対象の仮想マシンに接続します。コンソール接続でもRDP接続でも構いません。
接続後、PowerShellコンソールにてコピーしたスクリプトを実行します（図12）。
比較的短時間で完了すると思います。
仮想マシン上での作業は以上ですが、情報がAzureポータルにアップされるまで若干時間がかかりますので、コーヒーでも飲みましょう。
3-3：ゲスト管理有効化処理の実行・Azureポータルからの作業
図11の画面に戻ります。
頃合い（スクリプト実行から5分程度経過）を見計らって画面下部の「ゲスト管理を有効にする」をクリックします。
クリック後、図14のようなメッセージが表示されたら仮想マシンからのアップデートがAzureに届いていないので、数分待機します。
仮想マシンからのアップデートがAzureで確認できれば、図15のように画面に遷移して有効化ジョブが実行されていることが確認でします。
図16のように「有効（Connected）」と表示されれば、ゲスト管理は有効化完了です。
4：VMware Toolsのアンインストール
Windows OSは当然のことながら、最近のLinux環境ではHyper-Vのドライバーがプリインストールであるため、移行後に追加ソフトウェアの導入は必要ありません（一部のLinuxを除く）。
今までVMware環境で動いていたということは、当然VMware Toolsがインストールされていたと思いますので、そちらをアンインストールするのが健全でしょう。
Azure Local環境でVMware Toolsをアンインストールしようとしても、インストーラーでエラーが出力されてアンインストールできません（図17）。
かといって、Azure MigrateにはVMware Toolsが必須であるため、さてどうしたものか。
結論から申し上げますと、手動でアンインストールを試みる必要がありますが、レジストリを直接操作する必要があるので、なかなかにハードルが高いものがあります。
コミュニティベースであれば強制削除用のPowerShellスクリプトがGitHubにて公開されているので、そちらを参考に削除作業を行うのも1つの手段ではあります。
Force removal of VMware Tools, Program Files, and Windows Services · GitHub
このあたりも、Azure Migrateを使用する上で考慮すべき事項の1つかもしれません。
5：仮想マシンのセキュアブート
EFI設定の仮想マシンは、基本的にはセキュアブートが有効化されていると思います（図18）。
セキュアブートが有効のまま仮想マシンの移行は可能ですが、Azure Local環境ではセキュアブートが無効となっています。そのため、起動時に赤の帯が上部に表示されます（図19）。セキュアブートが無効の時に表示される警告ですね。
手動でセキュアブートを有効化できますので、仮想マシンをシャットダウンの上設定変更してください。
6：最後に
5回に分けて、Azure Migrateを使用したVMware環境からAzure Local環境への移行について紹介してきました。
移行環境の準備でそれなりに手間はかかりますし、リソースもそこそこ必要になります。
しかしながら、MicrosoftのファーストパーティソリューションとしてAzure Local環境への移行ツールが用意されたということは、Azure Localを利用するうえで非常に強力なサポートを得たといえるでしょう。
現状維持はコストが心配、でも移行にかかるコストも心配、という皆様、一度Azure LocalとAzure Migrateによる移行を評価してみてください。本記事がその一助になれば幸いです。
では、よいAzure Localライフを！
書いた人：後藤 諭史（Satoshi GOTO）
ソリューションアーキテクト部所属。
専門はWindows Server Hyper-VやAzure LocalといったMicrosoft仮想化技術。Microsoft SDN（Hyper-V Network Virtualization）などのWindows Server ネットワーク技術も。
Microsoft オンプレ技術以外にも、エンタープライズネットワークとかMicrosoft Azureとか、運用とか。
ネットワークやハードウェアといった物理層に近いところが大好きな、昔ながらのインフラ屋さん。得意技はケーブル整線。
Microsoft MVP for Cloud and Datacenter Management（2012-2026）
Microsoft MVP for Microsoft Azure（2024-2026）
