Azure Migrate アプライアンスのトラブルシューティング

この記事は、Azure Migrate アプライアンスをデプロイし、そのアプライアンスを使用してオンプレミスのサーバーを検出する際の問題のトラブルシューティングに役立ちます。

サポート対象

アプライアンスのサポート要件を確認します。

アプライアンス設定時に "無効な OVF マニフェスト エントリ" エラーが発生する

OVA テンプレートを使用してアプライアンスを設定しているときに、"指定されたマニフェスト ファイルが無効です: 無効な OVF マニフェストのエントリ" というエラーが表示されます。

Remediation

1. Azure Migrate アプライアンスの OVA ファイルが正常にダウンロードされていることを、そのハッシュ値をチェックして確認します。 詳細情報 を参照してください。 ハッシュ値が一致しない場合は、OVA ファイルをもう一度ダウンロードしてデプロイを再試行してください。
2. それでもデプロイが失敗する場合で、VMware vSphere クライアントを使って OVF ファイルをデプロイしている場合は、vSphere Web クライアントでデプロイしてみてください。 展開がそれでも失敗する場合は、別の Web ブラウザーをお試しください。
3. vSphere Web クライアントを使用しており、vCenter Server 6.5 または 6.7 にそれをデプロイしようとしている場合は、ESXi ホストに直接 OVA をデプロイしてみてください。
   • Web クライアント (https://<ホスト IP アドレス>/ui) を使って (vCenter Server ではなく) ESXi ホストに直接接続します。
   • [ホーム]>[インベントリ] で、[ファイル]>[Deploy OVF template]\(OVF テンプレートのデプロイ\) を選択します。 OVA を参照して、デプロイを完了する。
4. それでもデプロイが失敗する場合は、Azure Migrate のサポートにお問い合わせください。

前提条件の設定中に接続チェックが失敗する

アプライアンスの接続チェックでエラーが発生します。

Remediation

1. アプライアンスから必要な URL に接続できることを確認します。
2. これらの URL へのアクセスをブロックしているプロキシまたはファイアウォールがあるかどうかを確認します。 許可リストを作成する必要がある場合は、すべての URL を含めるようにします。
3. オンプレミスでプロキシ サーバーが構成されている場合は、同じ手順で [プロキシの設定] を選択して、プロキシの詳細を正しく入力します。 プロキシ認可資格情報が必要な場合は、それを入力します。
4. サーバーがこれまでにレプリケーション アプライアンスの設定に使用されていないこと、またはモビリティ サービス エージェントがサーバーにインストールされていることを確認します。

前提条件の設定中に aka.ms URL の接続チェックが失敗する

アプライアンスで aka.ms URL の接続チェック時にエラーが発生します。

Remediation

1. インターネットに接続でき、URL-aka.ms/* を許可リストに追加していることを確認して、最新バージョンのサービスをダウンロードします。
2. この URL へのアクセスをブロックしているプロキシまたはファイアウォールがあるかどうかを確認します。 構成マネージャーの前提条件の手順でプロキシの詳細を正しく指定していることを確認します。
3. アプライアンス構成マネージャーに戻り、前提条件を再実行して自動更新を開始します。
4. 再試行しても問題が解決しない場合は、latestcomponents.json ファイルをこの Web サイトからダウンロードして、障害が発生しているサービスの最新バージョンを確認します。 それらをファイル内のダウンロード リンクから手動で更新します。

アプライアンスのプライベート エンドポイント接続を有効にしてあり、この URL へのインターネット経由でのアクセスを許可したくない場合は、自動更新を無効にします (aka.ms リンクはこのサービスに必要であるため)。

Note

自動更新サービスを無効にすると、アプライアンスで実行されているサービスに最新の更新プログラムが自動で適用されなくなります。 この状況を回避するには、アプライアンス サービスを手動で更新します。

自動更新チェックが前提条件の設定中に失敗する

アプライアンスでの自動更新チェックでエラーが発生します。

Remediation

1. 必要な URL の許可リストを作成し、プロキシやファイアウォール設定によってこれらがブロックされていないことを確認します。
2. アプライアンス コンポーネントの更新が失敗する場合は、前提条件を再実行するか、アプライアンス サービスを手動で更新します。

時刻同期チェックが前提条件の設定中に失敗する

時刻の同期に関するエラーは、サーバー クロックが現在の時刻と同期しておらず、5 分以上ずれている可能性があることを示します。

Remediation

• コントロール パネルから日付と時刻の設定をチェックして、アプライアンス サーバーの時刻がインターネット時刻と同期していることを確認します。
• 次の手順に従って、アプライアンス サーバーのクロック時刻を現在の時刻に合わせて変更することもできます。
  1. サーバーで管理者用のコマンド プロンプトを開きます。
  2. タイム ゾーンを確認するには、w32tm /tz を実行します。
  3. 時刻を同期するには、w32tm /resync を実行します。

VMware アプライアンスで前提条件の設定中に VDDK チェックが失敗する

アプライアンスにインストールされている必要な VDDK キットをアプライアンスが見つけることができなかったため、Virtual Disk Development Kit (VDDK) チェックは失敗しました。 この問題によって、進行中のレプリケーションでエラーが発生する可能性があります。

Remediation

1. VDDK 6.7 をダウンロードしてあり、そのファイルをアプライアンス サーバー上の C:\Program Files\VMware\VMware Virtual Disk Development Kit にコピーしてあることを確認します。
2. アプライアンスで他のバージョンの VDDK を使用しているソフトウェアやアプリケーションが他にないか確認します。

アプライアンスの登録中にプロジェクト キー関連のエラーが発生する

プロジェクトからコピーされた Azure Migrate プロジェクト キーを使用して、アプライアンスを登録しようとすると問題が発生します。

Remediation

1. プロジェクトから正しいキーをコピーしたことを確認します。 プロジェクトの [Azure Migrate: Discovery and assessment] カードで、[検出] を選択します。 次に、手順 1 で [既存のアプライアンスの管理] を選択します。 ドロップダウン メニューから、以前にキーを生成したアプライアンス名を選択します。 対応するキーをコピーします。
2. 適切なクラウドの種類 (パブリック、US Gov) およびアプライアンスの種類 (VMware、Hyper-V、物理、またはその他) のアプライアンスにキーを貼り付けていることを確認します。 アプライアンス構成マネージャーの上部で、クラウドとシナリオの種類を確認します。

アプライアンス登録時に "Azure Migrate プロジェクトに接続できませんでした" エラーが発生する

Azure ユーザー アカウントを使用して正常にサインインした後、アプライアンスの登録手順が失敗し、"Azure Migrate プロジェクトに接続できませんでした。 エラーの詳細を確認し、[再試行] をクリックして修復手順に従ってください" というメッセージが表示されます。

この問題は、アプライアンス構成マネージャーからのサインインに使用された Azure ユーザー アカウントが、ポータルで Azure Migrate プロジェクト キーの生成に使用されたユーザー アカウントと異なる場合に発生します。

Remediation

2 つのオプションがあります。

• アプライアンスの登録を完了するには、ポータルで Azure Migrate プロジェクト キーを生成したのと同じ Azure ユーザー アカウントを使用します。
• アプライアンスの登録に使用されている他の Azure ユーザー アカウントに、必要なロールとアクセス許可を割り当てることもできます。

アプライアンスの登録中に "Microsoft Entra の操作が失敗しました。状態は Forbidden です" というエラーが発生する

Microsoft Entra ID の特権が不足しているために登録を完了できず、"Microsoft Entra の操作が失敗しました。状態は Forbidden です" というエラーが表示されます。

Remediation

Azure の Microsoft Entra アプリケーションを作成および管理するために必要なアクセス許可があることを確認します。 アプリケーション開発者ロール、またはユーザーがアプリケーションを登録できることがテナント レベルで許可されているユーザー ロールが必要です。

アプライアンスの登録中に "Key Vault へのアクセスが許可されていません" エラーが発生する

"{KeyVaultName}" に対する Azure Key Vault の作成または更新操作が、エラー "{KeyVaultErrorMessage}" のため失敗しました。

この問題は通常、アプライアンスの登録に使用された Azure ユーザー アカウントが、ポータル上で Azure Migrate プロジェクト キーを生成するために (つまり、キー コンテナーが作成されたときに) 使用されたアカウントと異なる場合に発生します。

Remediation

1. アプライアンス上で現在サインインしているユーザー アカウントに、エラー メッセージに記載されているキー コンテナーに対する必要なアクセス許可があることを確認します。 ユーザー アカウントには、この Web サイトに記載されているアクセス許可が必要です。
2. キー コンテナーに移動し、ユーザー アカウントに、キー コンテナーのアクセス ポリシーで割り当てられているすべてのキー、シークレット、証明書のアクセス許可を持つアクセス ポリシーがあることを確認します。 詳細情報。
3. アプライアンスのプライベート エンドポイント接続を有効にした場合は、アプライアンスがキー コンテナーを作成したのと同じ仮想ネットワークでホストされていること、またはプライベート リンクを経由でキー コンテナーが作成された Azure 仮想ネットワークに接続されていることを確認します。 キー コンテナー プライベート リンクがアプライアンスから解決可能であることを確認してください。 [Azure Migrate: Discovery and assessment]>[プロパティ] にアクセスして、Azure Migrate キー作成中に作成したキー コンテナーなどのリソースのプライベート エンドポイントの詳細を確認します。 詳細情報 を参照してください。
4. 必要なアクセス許可と接続がある場合は、しばらくしてからアプライアンスで登録を再試行してください。

検証中に vCenter Server と接続できない

この接続エラーを受け取る場合、vCenter Server <サーバー名>.com:9443 に接続できない可能性があります。 エラーの詳細では、https://\*servername*.com:9443/sdk でリッスンしているエンドポイントで、メッセージを受け入れることができるものがないことが示されています。

Remediation

• 最新バージョンのアプライアンスを実行しているかどうかを確認します。 そうでない場合は、アプライアンスを最新バージョンにアップグレードします。

• 最新バージョンでも引き続き問題が発生する場合は、指定された vCenter Server 名をアプライアンスで解決できないか、または指定されたポートが間違っている可能性があります。 ポートが指定されていない場合、コレクターでは既定でポート番号 443 への接続が試みられます。

  1. アプライアンスから <サーバー名>.com に対して ping を実行します。
  2. ステップ 1 が失敗する場合は、IP アドレスを使用して vCenter サーバーへの接続を試みます。
  3. 正しいポート番号を識別して vCenter サーバーに接続します。
  4. vCenter サーバーが起動されて実行中であることを確認します。

サーバー資格情報 (ドメイン) が VMware アプライアンスで検証に失敗する

ソフトウェア インベントリとエージェントレス依存関係分析を実行するために VMware アプライアンスで追加されたドメイン資格情報で "検証に失敗しました" が表示されます。

Remediation

1. 正しいドメイン名と資格情報を指定したことを確認します。
2. 資格情報を検証するために、アプライアンスからドメインに到達可能であることを確認します。 アプライアンスに通信経路の問題があるか、アプライアンス サーバーからドメイン名を解決できない可能性があります。
3. [編集] を選択して、ドメイン名または資格情報を更新します。 [資格情報の再検証] を選択して、しばらくしてから資格情報を再度検証します。

検証中に Hyper-V ホストまたはクラスターに接続すると "アクセスが拒否されました" エラーが発生する

"アクセスが拒否されました" エラーのため、追加された Hyper-V ホストまたはクラスターを検証できません。

Remediation

1. Hyper-V ホストの前提条件がすべて満たされていることを確認します。
2. 手動で、またはプロビジョニング PowerShell スクリプトを使用して、Hyper-V ホストを準備する方法については、この Web サイトの手順を確認してください。

検証中に "サーバーは WS-Management Identify 操作をサポートしていません" エラーが発生する

Hyper-V クラスターをアプライアンス上で検証できず、"The server does not support WS-Management Identify operations. Skip the TestConnection part of the request and try again" (サーバーは WS-Management Identify 操作をサポートしていません。要求の TestConnection の部分をスキップして、再試行してください) のエラーが表示されます。

Remediation

このエラーは、通常、アプライアンスでプロキシ構成を指定している場合に発生します。 ノードの FQDN を指定した場合でも、アプライアンスでは、クラスター ノードの短い名前を使用してクラスターに接続されます。 クラスターノードの短い名前をアプライアンスのバイパス プロキシの一覧に追加すると、この問題は解決されて、Hyper-V クラスターの検証が成功します。

Hyper-V アプライアンスでの検証中に "ホストまたはクラスターに接続できない" エラーが発生する

エラー "サーバー名を解決できないため、ホストまたはクラスターに接続できません。 WinRM エラー コード: 0x803381B9" は、アプライアンス用の Azure DNS サービスで、指定されたクラスターまたはホスト名を解決できない場合に発生する可能性があります。

この問題は通常、DNS で解決できないホストの IP アドレスを追加した場合に発生します。 クラスター内のホストについても、このエラーが表示されることがあります。 これは、アプライアンスはクラスターに接続できますが、クラスターから FQDN ではないホスト名が返されることを示します。

Remediation

このエラーを解決するには、IP アドレスとホスト名のマッピングを追加することでアプライアンス上の hosts ファイルを更新します。

1. 管理者としてメモ帳を開きます。
2. C:\Windows\System32\Drivers\etc\hosts ファイルを開きます。
3. IP アドレスとホスト名を 1 行で追加します。 このエラーが見られるホストまたはクラスターごとに繰り返します。
4. hosts ファイルを保存して閉じます。
5. アプライアンス管理アプリを使用して、アプライアンスからホストに接続できるかどうかを確認します。 30 分後、これらのホストの最新情報が Azure portal に表示されるようになるはずです。

物理サーバーの検証中に "サーバーに接続できない" エラーが発生する

Remediation

• アプライアンスからターゲット サーバーへの接続があることを確認します。
• Linux サーバーの場合は、次の手順に従ってパスワード ベースの認証が有効になっていることを確認します。
  1. Linux サーバーにサインインし、コマンド vi /etc/ssh/sshd_config を使用して SSH 構成ファイルを開きます。
  2. PasswordAuthentication オプションを yes に設定します。 ファイルを保存します。
  3. service sshd restart を実行して SSH サービスを再起動します。
• Windows サーバーの場合は、リモート WMI 呼び出しを許可するため、ポート 5985 が開かれていることを確認します。
• GCP Linux サーバーを検出中で、ルート ユーザーを使用している場合は、次のコマンドを使用して、ルート ログインの既定の設定を変更します。
  1. Linux サーバーにサインインし、コマンド vi /etc/ssh/sshd_config を使用して SSH 構成ファイルを開きます。
  2. PermitRootLogin オプションを yes に設定します。
  3. service sshd restart を実行して SSH サービスを再起動します。

検証中にサーバーに対して "BIOS GUID をフェッチできませんでした" エラーが発生する

アプライアンスで物理サーバーの検証が失敗し、"BIOS GUID をフェッチできませんでした" というエラー メッセージが表示されます。

Remediation

Linux サーバー

検証が失敗しているターゲット サーバーに接続します。 次のコマンドを実行して、サーバーの BIOS GUID が返されるかどうかを確認します。

cat /sys/class/dmi/id/product_uuid
dmidecode | grep -i uuid | awk '{print $2}'

このコマンドをアプライアンス サーバーのコマンド プロンプトから実行することもできます。次のコマンドを使用してターゲットの Linux サーバーとの SSH 接続を作成してください。

ssh <username>@<servername>

Oracle などの一部の Linux マシンには、tty オプションが既定で有効になっている必要がある構成値があり、これによってエラーが発生する可能性があります。 このような場合は、/etc/sudoers ファイルで "!" 文字を追加することで、この設定を無効にできます。 また、/etc/sudoers/ ファイルの末尾に以下を追加して、ファイル内の他の構成でこれをオーバーライドできないようにすることもできます。

• Defaults !visiblepw
• Defaults !requiretty

Windows サーバー

検証に失敗しているターゲット サーバーに対して、アプライアンス サーバーから PowerShell で次のコードを実行して、サーバーの BIOS GUID が返されるかどうかを確認します。

[CmdletBinding()]
Param(
  [Parameter(Mandatory=$True,Position=1)]
   [string]$Hostname
)
$HostNS = "root\cimv2"
$error.Clear()

$Cred = Get-Credential
$Session = New-CimSession -Credential $Cred -ComputerName $Hostname

if ($Session -eq $null -or $Session.TestConnection() -eq $false)
{
    Write-Host "Connection failed with $Hostname due to $error"
    exit -1
}

Write-Host "Connection established with $Hostname"
#Get-WmiObject -Query "select uuid from Win32_ComputerSystemProduct" 

$HostIntance = $Session.QueryInstances($HostNS, "WQL", "Select UUID from Win32_ComputerSystemProduct")
$HostIntance | fl *

前のコードを実行する場合は、ターゲット サーバーのホスト名を指定する必要があります。 それには、IP アドレス/FQDN/ホスト名を指定できます。 その後、サーバーに接続するための資格情報を入力するよう求められます。

検証中のサーバーで "適切な認証方法が見つかりませんでした" エラーが発生する

物理アプライアンスを使用して Linux サーバーを検証しようとすると、"適切な認証方法が見つかりません" というエラーが表示されます。

Remediation

次の手順に従って、Linux サーバーでパスワードベースの認証が有効になっていることを確認します。

1. Linux サーバーにサインインします。 コマンド vi /etc/ssh/sshd_config を使用して SSH 構成ファイルを開きます。
2. PasswordAuthentication オプションを yes に設定します。 ファイルを保存します。
3. service sshd restart を実行して SSH サービスを再起動します。

検証中に物理サーバーに接続すると "アクセスが拒否されました" エラーが発生する

物理アプライアンスを介して Windows サーバーを検証しようとすると、エラー "WS-Management サービスは要求を処理できません。 WMI サービスはアクセス拒否エラーを返しました" が表示されます。

Remediation

• このエラーが発生した場合は、アプライアンス構成マネージャーで指定されたユーザー アカウント (ドメイン/ローカル) が、リモート管理ユーザー、パフォーマンス モニター ユーザー、パフォーマンス ログ ユーザーの各グループに追加されていることを確認してください。

• リモート管理ユーザー グループが存在しない場合は、ユーザー アカウントをグループ WinRMRemoteWMIUsers_ に追加します。

• 目的のサーバーのコマンド プロンプトで次のコマンドを実行すれば、WS-Management プロトコルがそのサーバーで有効になっているかどうかを確認することもできます: winrm qc

• 問題が解決しない場合は、ユーザー アカウントに CIMV2 名前空間とサブ名前空間に対するアクセス許可があることを、WMI コントロールパネルで確認してください。 アクセスを設定するには、次の手順に従ってください。

  1. アプライアンスで検証に失敗しているサーバーにアクセスします。
  2. スタート メニューで [ファイル名を指定して実行] を検索して選択します。 [ファイル名を指定して実行] ダイアログで、[名前] テキスト ボックスに「wmimgmt.msc」と入力し、Enter を選択します。
  3. wmimgmt コンソールが開き、左側のペインに [WMI コントロール (ローカル)] が表示されます。 それを右クリックして、メニューから [プロパティ] を選択します。
  4. [WMI コントロール (ローカル) のプロパティ] ダイアログで、[セキュリティ] タブを選択します。
  5. [セキュリティ] タブで、名前空間ツリーの [Root] フォルダーを展開し、cimv2 名前空間を選択します。
  6. [セキュリティ] を選択して [セキュリティ ROOT\CIMV2] ダイアログを開きます。
  7. [グループ名またはユーザー名] セクションで、[追加] をクリックして、[ユーザー、コンピューター、サービス アカウントまたはグループの選択] ダイアログを開きます。
  8. ユーザー アカウントを検索して選択し、[OK] を選択して [セキュリティ ROOT\CIMV2] ダイアログに戻ります。
  9. [グループ名またはユーザー名] セクションで、先ほど追加したユーザー アカウントを選択します。 次のアクセス許可が与えられていることを確認します。
     
     • アカウントの有効化
       
     • リモートの有効化
  10. [適用] を選択して、ユーザー アカウントに設定されたアクセス許可を有効にします。

• ドメイン/ワークグループ以外のサーバーのローカル ユーザー アカウントにも同じ手順が適用されます。 場合によっては、コマンドが標準ユーザーとして実行される際に UAC フィルター処理によって一部の WMI プロパティがブロックされる可能性があります。そのため、ローカル管理者アカウントを使用するか UAC を無効にして、ローカル ユーザー アカウントがフィルター処理されず、代わりに完全な管理者になるようにすることができます。

• リモート UAC を制御するレジストリ エントリを変更してリモート UAC を無効にするのは推奨されませんが、ワークグループで必要になる場合があります。 レジストリ エントリは HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\system\LocalAccountTokenFilterPolicy です。 このエントリの値がゼロ (0) のとき、リモート UAC アクセス トークンのフィルター処理が有効です。 値が 1 のとき、リモート UAC は無効です。

アプライアンスが切断されている

ポータルからいくつかの VMware サーバーでレプリケーションを有効にしようとすると、"アプライアンスが切断されている" というエラー メッセージが表示されます。

このエラーは、アプライアンスがシャットダウン状態にある場合、またはアプライアンスの DRA サービスが Azure と通信できない場合に発生する可能性があります。

Remediation

1. アプライアンス構成マネージャーにアクセスし、前提条件を再実行すると、[アプライアンス サービスを表示] に DRA サービスの状態が表示されます。

2. サービスが実行されていない場合は、コマンド プロンプトから、次のコマンドを使用してサービスを停止してから再起動します。

   net stop dra
   net start dra
   

次のステップ

• VMware、Hyper-V、または物理サーバー用にアプライアンスを設定します。
• VMware VM、Hyper-V VM、または物理サーバーを移行する方法を学習します。