Azure Migrate でオンプレミス サーバーをクラウド移行しようとしたら、「オンプレミス アプライアンスを構成してください」「DRInstaller.ps1 が途中で止まる」といったメッセージに阻まれて作業が進まない……そんなケースは珍しくありません。本記事では、ディスカバリーまでは完了しているのに移行フェーズでつまずいた管理者の方向けに、「オンプレミス アプライアンス」の正体と、DRInstaller.ps1 実行時の典型的なエラーと解決策を、実務レベルの観点から詳しく解説します。
Azure Migrate の移行フェーズでよくあるつまずき
Azure Migrate は大きく「ディスカバリー」「アセスメント」「移行 (Migrate)」の三つのフェーズに分かれています。ディスカバリーとアセスメントまでは順調に完了して、「いよいよ移行だ」と思って Azure Portal で「移行」ウィザードを開くと、次のようなメッセージに遭遇することがあります。
「オンプレミス アプライアンスを構成してください」
すでにディスカバリー用の Azure Migrate アプライアンスは構成しているはずなのに、なぜまた「アプライアンス」が必要なのか？ ここを理解していないと、画面とにらめっこしたまま時間だけが過ぎてしまいます。
結論から言うと、Azure Migrate ではオンプレミス側に「アプライアンス」が 2 種類必要です。ディスカバリー用アプライアンスとは別に、レプリケーション用アプライアンスを新たに構成しないと、移行フェーズに進めません。
オンプレミス アプライアンスが 2 種類必要になる理由
ディスカバリー用アプライアンスの役割
まずおさらいとして、すでに構成済みであることが多い ディスカバリー用アプライアンスの役割を整理しておきます。
- オンプレミスのサーバーや VM（VMware/Hyper-V/物理）の情報収集
- CPU、メモリ、ディスク、ネットワーク使用状況などのパフォーマンス データ収集
- 収集した情報を Azure Migrate プロジェクトに送信し、アセスメントで利用できるようにする
ディスカバリー用アプライアンスは、あくまで「棚卸し」と「見積もり」のためのコンポーネントです。ここまでは、移行対象サーバーに対してエージェントやレプリケーションの設定は行われません。
レプリケーション用アプライアンスの役割
実際にオンプレミス サーバーを Azure 上に移行する際には、継続的にディスクをレプリケーションする役割が必要になります。それを担うのが レプリケーション用アプライアンス（DRA：Deployment and Replication Appliance） です。
レプリケーション用アプライアンスは、主に次のような機能を持ちます。
- 対象サーバー上にエージェント（Mobility Agent など）をプッシュ インストール
- レプリケーション セットアップ（レプリケーション ポリシー、ターゲット リソースなど）の構成
- 変更ブロックの収集・転送を通じた継続的レプリケーション
- Azure との状態同期・ヘルス モニタリング
そのため、ディスカバリー用アプライアンスとは目的も処理もまったく異なります。移行フェーズに入るときに「オンプレミス アプライアンスを構成してください」と表示されるのは、「レプリケーション用アプライアンスがまだ構成されていない」ことを指していると理解してください。
ディスカバリー用とレプリケーション用の違いまとめ
| 項目 | ディスカバリー用アプライアンス | レプリケーション用アプライアンス |
|---|---|---|
| 目的 | サーバー情報・性能情報の収集 | ディスク レプリケーションと移行実行 |
| フェーズ | ディスカバリー／アセスメント | 移行 (Migrate) |
| 主な処理 | インベントリ収集、パフォーマンス メトリック送信 | エージェント配布、レプリケーション、フェールオーバー |
| 設定画面 | Azure Migrate > サーバーの評価 | Azure Migrate > サーバーの移行 |
| 典型的なトラブル | インベントリが取得されない、認証エラー | DRInstaller.ps1 が途中で止まる、URL Rewrite が入らない |
Azure Portal からレプリケーション用アプライアンスを構成する手順
「オンプレミス アプライアンスを構成してください」という表示に対して、具体的に何を行えばよいかを手順として整理します。
- Azure Portal で Azure Migrate プロジェクトを開く。
- 「サーバーの移行」ブレードを選択する。
- 画面内のガイドに従い、「レプリケーション アプライアンスのダウンロード」を選択する。
- ダウンロードした zip（例：
DRAppliance.zipのような名前）をオンプレミスの作業サーバー上に展開する。 - 展開先フォルダー（例：
C:\dr\DRAppliance）を作業フォルダーにし、管理者権限の PowerShell でDRInstaller.ps1を実行する。
ここまで進めば、レプリケーション用アプライアンス構成のスタートラインに立てます。ところが、この DRInstaller.ps1 実行中にトラブルが起こりやすいのが実情です。以下では、代表的な 2 つのパターンを詳しく解説します。
DRInstaller.ps1 が「Installing the IIS URL Rewrite Module 2…」で止まる問題
症状の概要
レプリケーション アプライアンスを構成するために DRInstaller.ps1 を実行すると、次のログ行で処理が停止し、先へ進まなくなることがあります。
Installing the IIS URL Rewrite Module 2...しばらく待っても終わらず、PowerShell ウィンドウにもエラーが表示されないため、「止まっているのか、時間がかかっているだけなのか」判断が難しいケースです。多くの場合、URL Rewrite Module 2 のインストールが正常に完了していないことが根本原因です。
まず確認すべきポイント
| チェック項目 | 確認内容 | 優先度 |
|---|---|---|
| 実行権限 | PowerShell を「管理者として実行」しているか | 高 |
| ウイルス対策ソフト | MSI インストーラの実行がブロックされていないか | 中 |
| ネットワーク | 必要なインストーラーがインターネット／社内リポジトリから取得できるか | 中 |
| ログ | %ProgramData%\Microsoft Azure\Logs にエラーが出ていないか | 中 |
管理者権限の PowerShell で再実行する
Windows では、IIS 関連コンポーネントや URL Rewrite Module のインストールには管理者権限が必須です。まずは次の手順で実行権限を確認・修正します。
- PowerShell のショートカットを右クリックする。
- 「管理者として実行」を選択する。
- 次のようにフォルダーを移動してからスクリプトを再実行する。
cd C:\dr\DRAppliance .\DRInstaller.ps1
管理者権限で実行していない場合、URL Rewrite Module のインストールがバックグラウンドで失敗しても、表向きのログに反映されず「固まっているように見える」という事象が起こりがちです。
URL Rewrite Module 2 を手動インストールする
何度試しても Installing the IIS URL Rewrite Module 2... から進まない場合は、URL Rewrite Module 2 を手動で先にインストールしてしまう方法が有効です。
- Microsoft の公式配布ページから
rewrite_amd64.msiなどの URL Rewrite Module 2 インストーラーを取得する。 - アプライアンスを構成するサーバー上で MSI を実行し、ウィザードに従ってインストールする。
- インストール完了後、再度管理者権限の PowerShell で
DRInstaller.ps1を実行する。
URL Rewrite Module 2 がすでにインストール済みであれば、DRInstaller.ps1 は該当ステップをスキップし、次の処理に進みます。この方法で、インタラクティブな MSI 実行が必要な環境や、プロキシ環境でのダウンロード失敗などを回避できます。
ウイルス対策ソフトによるブロックを疑う
企業環境では、ウイルス対策ソフトや EDR 製品が「見慣れないインストーラー」や「スクリプトからの MSI 実行」をブロックしているケースも多くあります。次のような対策を検討してください。
- アプライアンス構成中のみリアルタイムスキャンを一時停止する。
- DRInstaller.ps1 の配置フォルダーや MSI ファイルを除外パスに追加する。
- ログ（クライアント側／管理コンソール側）でブロックイベントが発生していないか確認する。
一時停止する場合は、作業完了後に必ず元の設定へ戻すことを忘れないようにしましょう。
ログから詳細エラーを特定する
上記を試しても改善しない場合は、%ProgramData%\Microsoft Azure\Logs 配下に出力されるログを確認します。具体的には次のような情報に注目します。
- 特定の DLL のロードに失敗していないか
- URL Rewrite Module のセットアップ ログにエラー コードが記録されていないか
- タイムアウトやアクセス拒否（Access Denied）のメッセージがないか
これらの情報から、権限不足なのか、MSI の破損なのか、ネットワーク経由の取得に失敗しているのかを切り分けていきます。
「Extracting DRA Installer」で止まる／PushInstallAgentSetup.msi が見つからない問題
症状の概要
URL Rewrite Module 2 のインストールを無事突破できても、次に次のステップで止まるケースがあります。
Extracting DRA Installer...同時に、ログには 「PushInstallAgentSetup.msi が見つからない」「必要なファイルが存在しない」といったメッセージが記録されていることがあります。これは、多くの場合 作業ディレクトリやパッケージ展開に問題があるパターンです。
正しい作業ディレクトリから実行する
DRInstaller.ps1 は、スクリプトと同じフォルダーに存在するファイルを相対パスで参照します。そのため、C:\dr\DRAppliance とは別のパスから次のように実行していると、必要な MSI や CAB ファイルを見つけられず失敗します。
# これは NG になり得る例
PS C:\Users\Administrator> C:\dr\DRAppliance\DRInstaller.ps1正しい実行方法は次の通りです。
cd C:\dr\DRAppliance
.\DRInstaller.ps1特に、RDP で接続してエクスプローラーからパスをコピペしていると、この「作業ディレクトリの違い」に気付きにくくなります。実行前に必ず現在のディレクトリを確認する習慣をつけておきましょう。
アプライアンス パッケージの完全性を確認する
正しいディレクトリから実行していても PushInstallAgentSetup.msi が見つからないと記録される場合は、パッケージが完全に展開されていない・途中で破損している可能性があります。
代表的なフォルダー構成のイメージは次の通りです。
C:\dr\DRAppliance
├─ DRInstaller.ps1
├─ PushInstallAgentSetup.msi
├─ *.cab
├─ *.json
└─ その他セットアップに必要なファイル特に PushInstallAgentSetup.msi が存在しない場合は、次の手順で再度パッケージを取得してください。
- Azure Portal の「サーバーの移行」画面から、アプライアンス パッケージを再ダウンロードする。
- ダウンロードした zip を新しいフォルダー（例：
C:\dr\DRAppliance_new）に展開する。 - 展開直後のフォルダー内容を確認し、
PushInstallAgentSetup.msiや CAB ファイルが揃っていることをチェックする。 - 管理者権限の PowerShell で、そのフォルダーに移動して
DRInstaller.ps1を実行する。
再ダウンロード時の注意点
- プロキシ環境や回線品質の問題で zip ファイルが途中で切れている可能性があります。サイズを確認し、複数回ダウンロードして比較すると安心です。
- 展開時にウイルス対策ソフトが一部のファイルを隔離してしまうこともあります。ログや隔離リストを確認し、必要に応じて一時的に除外設定を行います。
- 古い zip と新しい zip を同じフォルダーに展開するとファイルが混ざることがあります。必ず空のフォルダーに展開してください。
ログとイベント ビューアーで二次トラブルを確認する
ファイル構成を整えてもまだエラーが出る場合は、別の要因が隠れていることがあります。次の場所を確認して、ヒントになりそうなエラーを洗い出しましょう。
%ProgramData%\Microsoft Azure\Logs配下の最新ログ- イベント ビューアーの「Applications and Services Logs」配下
- アプリケーション イベント ログ（MSI ログや .NET エラーが記録されていることがある）
たとえば、MSI のタイムアウト、IIS のセットアップ失敗、アクセス権限の不足などが記録されていれば、そこから原因を絞り込んでいくことができます。
トラブルシューティング時の共通チェックポイント
ここまで紹介した 2 つの代表的なトラブルだけでなく、DRInstaller.ps1 を用いたアプライアンス構成では、共通して確認しておくべきポイントがいくつかあります。まとめとして表形式で整理します。
| 項目 | チェック内容 |
|---|---|
| 実行権限 | PowerShell を管理者権限で起動しているか |
| 作業ディレクトリ | DRInstaller.ps1 と同じフォルダーに移動して実行しているか |
| ネットワーク | アプライアンスが 80/443 ポートで Azure へ通信できるか（FW やプロキシ設定を含む） |
| ウイルス対策 | インストーラや MSI ファイルの書き込み／展開をブロックしていないか |
| パッケージ | アプライアンス パッケージ（zip）が完全にダウンロード・展開されているか |
| ログ | %ProgramData%\Microsoft Azure\Logs の最新ログにエラーが出ていないか |
これらを一つ一つ確認していくことで、多くの場合はスクリプトが正常終了し、レプリケーション用アプライアンス構成まで到達できます。
レプリケーション用アプライアンス構成後に確認しておきたいこと
DRInstaller.ps1 が正常に完了すると、オンプレミスのレプリケーション用アプライアンスと Azure Migrate プロジェクトが同期され、Azure Portal 上で「移行」ウィザードにて対象サーバーを選択できるようになります。ここで、次のポイントも忘れずに確認しておきましょう。
- Azure Portal 上でアプライアンスの接続状態が「接続済み」になっているか
- レプリケーション対象として表示されるサーバーの一覧が、ディスカバリー結果と整合しているか
- 試験的に 1 台だけレプリケーションを有効にし、レプリケーション ヘルスが「正常」になるか
本番サーバーをいきなり大量に移行対象にするのではなく、まずはテスト用サーバーで動作確認するのが安全です。DRInstaller.ps1 のトラブルが解消されても、その後のレプリケーションやフェールオーバーで別の問題が発生する可能性はあります。小さく試してから本番へ、という流れを徹底すると、トラブル時の影響範囲を最小限に抑えられます。
実務で役立つベスト プラクティスと Tips
アプライアンス用サーバー選定のポイント
レプリケーション用アプライアンスをどのサーバーに配置するかは、移行プロジェクト全体の安定性にも影響します。次のポイントを考慮するとよいでしょう。
- 移行対象サーバーと同一ネットワーク（同一セグメント）または十分に帯域のあるセグメントに配置する。
- CPU とディスク I/O に余裕のあるサーバーを選ぶ（レプリケーションの圧縮・暗号化処理が走るため）。
- OS はサポートされている Windows Server バージョンを使用する。
- 本番サーバーと兼用せず、できれば専用 VM として用意する。
変更管理・監査の観点からの注意点
企業の運用ルールによっては、サーバーへの新規コンポーネント追加やスクリプト実行に申請が必要なケースがあります。Azure Migrate のアプライアンス構成では、IIS、URL Rewrite Module、各種エージェントなど複数コンポーネントがインストールされるため、事前に次のような情報を整理しておくとスムーズです。
- アプライアンスがインストールするコンポーネントの一覧（IIS、URL Rewrite、エージェントなど）
- 利用するポート（80/443 など）と外向き通信先（Azure 側）の概要
- アプライアンスの役割（移行のための一時的なレプリケーション基盤であること）
あらかじめ関係者と共有しておくことで、「知らないコンポーネントが勝手に入った」といった誤解を防ぎ、セキュリティ チームや運用チームとの連携もスムーズになります。
トラブル発生時の情報共有テンプレートを用意する
DRInstaller.ps1 のトラブルは、環境依存の要因が絡み合うことも多く、ベンダーや社内チームにエスカレーションするケースも出てきます。その際、次のような情報をテンプレートとしてまとめておくと、調査が格段に速くなります。
| 項目 | 記入例 |
|---|---|
| 実行サーバー OS | Windows Server 20xx Datacenter |
| 実行ユーザー | ローカル Administrators グループ所属アカウント |
| PowerShell 実行方法 | 管理者として実行 / 実行ポリシー (RemoteSigned など) |
| エラー発生箇所 | Installing the IIS URL Rewrite Module 2… で停止 |
| ログの抜粋 | 該当箇所のログ数行＋エラーコード |
| ウイルス対策ソフト | 製品名、バージョン、除外設定の有無 |
このような情報が揃っていれば、原因の当たりを付けやすくなり、「まずは情報をください」というやり取りを減らすことができます。
まとめ：ディスカバリーは終わっているのに移行できない、を卒業しよう
本記事では、Azure Migrate の移行フェーズで頻出する次の 3 つのポイントについて解説しました。
- オンプレミス アプライアンスは「ディスカバリー用」と「レプリケーション用」の 2 種類が必要であり、移行フェーズで求められているのは後者であること。
- DRInstaller.ps1 実行中に 「Installing the IIS URL Rewrite Module 2…」で止まる場合は、管理者権限、URL Rewrite の手動インストール、ウイルス対策ソフトの影響を疑うこと。
- 「Extracting DRA Installer」で止まる／PushInstallAgentSetup.msi が見つからない場合は、作業ディレクトリとパッケージの完全性を最優先で確認すること。
特に、作業ディレクトリと管理者権限、ウイルス対策ソフトの 3 点を丁寧に確認するだけで、かなりの割合のトラブルは解消できます。一方で、ログの確認やネットワーク要件の洗い出しなど、「地味だが重要」な作業を疎かにすると、原因の切り分けに時間を取られてしまいます。
Azure Migrate は、適切にアプライアンスを構成できれば非常に強力な移行プラットフォームです。本記事の内容を踏まえ、「ディスカバリーまではできたのに、移行で止まる」状態から卒業し、計画的かつ安全なサーバー移行を実現していただければ幸いです。
コメント