英語で読む

次の方法で共有


依存関係の視覚化に関するトラブルシューティング

この記事は、エージェントベースおよびエージェントレスの依存関係分析 ("VMware サーバーでのみ使用できます") に関する問題のトラブルシューティングに役立ちます。 Azure Migrate でサポートされている依存関係の視覚化の種類の詳細については、こちらをご覧ください。

エージェントレスの依存関係分析を使って 1 時間を超える依存関係を視覚化する

エージェントレスの依存関係の分析では、最大 30 日間、マップ内で依存関係を視覚化したりエクスポートしたりできます。

エージェントレスの依存関係分析を使って 10 台を超えるサーバーの依存関係を視覚化する

Azure Migrate には、一度に多数のサーバーのネットワーク接続を視覚化し、プロセスとサーバーによってフィルター処理するために使用できる Power BI テンプレートが用意されています。 多数のサーバーの依存関係をまとめて視覚化する方法の詳細については、こちらをご覧ください。

依存関係のエクスポートの CSV にエージェントレスの依存関係分析に関する "不明なプロセス" が表示される

エージェントレスの依存関係の分析では、プロセス名はベストエフォートでキャプチャされます。 特定のシナリオでは、依存元と依存先のサーバー名および依存先のポートがキャプチャされますが、依存関係の両端でプロセス名を特定することができません。 このような場合、プロセスは "不明なプロセス" とマークされます。

"403: この要求は、この操作を実行する権限がない" というエラーが発生したため、依存関係データを CSV 形式でエクスポートできない

Azure Migrate プロジェクトにプライベート エンドポイント接続がある場合、プライベート ネットワークを介して Azure 仮想ネットワークに接続されているクライアントから依存関係データをエクスポートする要求を開始する必要があります。 このエラーを解決するには、オンプレミス ネットワークまたはアプライアンス サーバーで Azure portal を開き、エクスポートを再度試してください。

依存関係分析エラーをエクスポートする

[通知のエクスポート] を選ぶことで、エージェントレス依存関係分析のすべてのエラーと修復をポータルからエクスポートできます。 エクスポートした CSV ファイルには、エラーが発生したタイムスタンプや、依存関係データの検証または検出でエラーが発生したかどうかなどの追加情報も含まれています。

[通知のエクスポート] 画面のスクリーンショット。

エージェントレス依存関係分析の一般的なエラー

Azure Migrate ではエージェントレスの依存関係分析がサポートされており、これには Azure Migrate: Discovery and Assessment を使用します。 エージェントレスの依存関係分析の要件については、こちらをご覧ください。

VMware VM の場合、エージェントレスの依存関係分析は、VMware API を使用して vCenter Server 経由でサーバーに接続することで実行されます。 Hyper-V VM と物理サーバーの場合、エージェントレスの依存関係分析は、ポート 5985 (HTTP) で PowerShell リモート処理を使用して Windows サーバーに直接接続し、ポート 22 (TCP) で SSH 接続を使用して Linux サーバーに直接接続することで実行されます。

次の表は、VMware API を使用して依存関係データを収集する場合またはサーバーに直接接続する場合に発生するすべてのエラーの概要を示しています。

注意

ソフトウェア インベントリでも同じエラーが発生する可能性があります。これは、必要なデータを収集するために、エージェントレスの依存関係分析と同じ方法に従うからです。

Error 原因 操作
60001: 物理サーバーに接続できない サーバーに接続するための前提条件が満たされていないか、サーバーへの接続でプロキシ設定などのネットワークの問題が発生しています。 - サーバーが前提条件とポートのアクセス要件を満たしていることを確認してください。
- リモート マシン (検出されたサーバー) の IP アドレスを Azure Migrate アプライアンスの WinRM TrustedHosts リストに追加し、操作を再試行します。 これは、サーバー上のリモート受信接続を許可するためのものです - Windows: WinRM ポート 5985 (HTTP) と Linux: SSH ポート 22 (TCP)
- アプライアンスでサーバーに接続するための正しい認証方法が選択されていることを確認します。
- 問題の発生が続く場合は、アプライアンス マシン ID (アプライアンス構成マネージャーのフッターにあります) を記入して、Microsoft サポート ケースを提出してください。
60002: サーバーの資格情報が正しくない サーバーに接続できません。 アプライアンスで間違った資格情報が指定されているか、以前に指定した資格情報の有効期限が切れています。 - アプライアンスでサーバーの正しい資格情報が記入されていることを確認します。 これを確認するには、これらの資格情報を使用してサーバーへの接続を試行します。
- 追加された資格情報が正しくないか有効期限が切れている場合は、アプライアンスで資格情報を編集し、追加されたサーバーを再検証してください。 検証に成功した場合、問題は解決されています。
- 問題の発生が続く場合は、アプライアンス マシン ID (アプライアンス構成マネージャーのフッターにあります) を記入して、Microsoft サポート ケースを提出してください。
60005: SSH オペレーション タイムアウト ネットワーク待機時間の問題か、サーバー上の最新の更新プログラムがないため、操作に予想以上の時間がかかっています。 - 問題が発生しているサーバーに最新のカーネルと OS の更新プログラムがインストールされていることを確認してください。
- アプライアンスとサーバーの間のネットワークに遅延が無いことを確認してください。 待機時間の問題を回避するために、アプライアンスとソース サーバーを同じドメインに配置することをお勧めします。
- 問題が発生しているサーバーにアプライアンスから接続し、こちらに記載されているコマンドを実行して、null 値 または空のデータが返されるかどうかを確認してください。
- 問題の発生が続く場合は、アプライアンス マシン ID (アプライアンス構成マネージャーのフッターにあります) を記入して、Microsoft サポート ケースを提出してください。
9000: サーバー上の VMware ツールの状態を検出できません。 VMware ツールがサーバーにインストールされていないか、インストールされているバージョンが破損している可能性があります。 バージョン 10.2.1 より後の VMware ツールが確実にサーバーにインストールされ、実行されているようにします。
9001: VMware ツールがサーバーにインストールされていません。 VMware ツールがサーバーにインストールされていないか、インストールされているバージョンが破損している可能性があります。 バージョン 10.2.1 より後の VMware ツールが確実にサーバーにインストールされ、実行されているようにします。
9002: VMware ツールがサーバーで実行されていません。 VMware ツールがサーバーにインストールされていないか、インストールされているバージョンが破損している可能性があります。 バージョン 10.2.0 より後の VMware ツールが確実にサーバーにインストールされ、実行されているようにします。
9003: サーバーで実行されているオペレーション システムの種類はサポートされていません。 サーバーで実行されているオペレーティング システムが Windows または Linux ではありません。 サポートされている OS の種類は Windows と Linux だけです。 サーバーで確かに Windows または Linux OS が実行されている場合は、vCenter Server で指定されているオペレーティング システムの種類を確認してください。
9004: サーバーが実行中の状態ではありません。 サーバーは電源オフの状態です。 サーバーが実行中の状態であることを確認してください。
9005: サーバーで実行されているオペレーション システムの種類はサポートされていません。 サーバーで実行されているオペレーティング システムが Windows または Linux ではありません。 サポートされている OS の種類は Windows と Linux だけです。 <FetchedParameter> オペレーティング システムは現在サポートされていません。
9006: サーバーから検出メタデータ ファイルをダウンロードするために必要な URL が空です。 この問題は、アプライアンス上の検出エージェントが想定どおりに動作していないことが原因で一時的に発生する可能性があります。 この問題は通常、24 時間以内に次のサイクルで自動的に解決されます。 問題が解決しない場合は、Microsoft サポート ケースを送信してください。
9007: スクリプトを実行してメタデータを収集するプロセスがサーバーに見つかりません。 この問題は、アプライアンス上の検出エージェントが想定どおりに動作していないことが原因で一時的に発生する可能性があります。 この問題は通常、24 時間以内に次のサイクルで自動的に解決されます。 問題が解決しない場合は、Microsoft サポート ケースを送信してください。
9008: メタデータを収集するためにサーバーで実行されているプロセスの状態を取得できません。 この問題は、内部エラーが原因で一時的に発生する場合があります。 この問題は通常、24 時間以内に次のサイクルで自動的に解決されます。 問題が解決しない場合は、Microsoft サポート ケースを送信してください。
9009: Windows ユーザー アカウント制御 (UAC) によって、サーバー上の検出操作の実行が妨げられています。 Windows UAC の設定により、インストールされているアプリケーションをサーバーから検出することが制限されています。 影響を受けているサーバーのコントロール パネルで、[ユーザー アカウント制御] 設定のレベルを下げてください。
9010: サーバーの電源がオフになっています。 サーバーは電源オフの状態です。 サーバーが電源オンの状態になるようにしてください。
9011: サーバー上で、検出されたメタデータを含むファイルが見つかりません。 この問題は、内部エラーが原因で一時的に発生する場合があります。 この問題は通常、24 時間以内に次のサイクルで自動的に解決されます。 問題が解決しない場合は、Microsoft サポート ケースを送信してください。
9012: サーバー上で、検出されたメタデータを含むファイルが空です。 この問題は、内部エラーが原因で一時的に発生する場合があります。 この問題は通常、24 時間以内に次のサイクルで自動的に解決されます。 問題が解決しない場合は、Microsoft サポート ケースを送信してください。
9013: サーバーにログインするたびに、新しい一時ユーザー プロファイルが作成されます。 サーバーにログインするたびに、新しい一時ユーザー プロファイルが作成されます。 Microsoft サポート ケースを送信して、この問題のトラブルシューティングの支援を受けてください。
9014: ESXi ホストで発生したエラーが原因で、検出されたメタデータを含むファイルを取得できません。 エラー コード: %ErrorCode、詳細: %ErrorMessage ESXi ホスト <HostName> でエラーが発生しました。 エラー コード: %ErrorCode、詳細: %ErrorMessage。 サーバーが実行されている ESXi ホストでポート 443 が開いていることを確認してください。

この問題の修復方法については、こちらをご覧ください。
9015: サーバー検出で指定された vCenter Server ユーザー アカウントでゲスト操作権限が有効になっていません。 ゲスト操作に必要な権限が vCenter Server ユーザー アカウントで有効になっていません。 サーバーとやりとりし、必要なデータをプルするには、vCenter Server ユーザー アカウントで、[Virtual Machines]\(仮想マシン\)>[Guest Operations]\(ゲスト操作\) の権限が有効になっているようにします。

必要な権限を持つ vCenter Server アカウントを設定する方法の詳細については、こちらをご覧ください。
9016: サーバー上のゲスト操作エージェントが古くなっているため、メタデータを検出できません。 VMware ツールがサーバーにインストールされていないか、インストールされているバージョンが最新ではありません。 VMware ツールがサーバーにインストールされ、最新の状態で実行されているようにします。 VMware ツールのバージョンは、バージョン 10.2.1 以降である必要があります。
9017: サーバー上で、検出されたメタデータを含むファイルが見つかりません。 これは、内部エラーが原因で一時的に発生している問題の可能性があります。 Microsoft サポート ケースを送信して、この問題のトラブルシューティングの支援を受けてください。
9018: PowerShell がサーバーにインストールされていません。 PowerShell がサーバー上に見つかりません。 PowerShell バージョン 2.0 以降がサーバーにインストールされていることを確認してください。

この問題の修復方法については、こちらをご覧ください。
9019: サーバーでのゲスト操作エラーが原因でメタデータを検出できません。 サーバーで VMware ゲスト操作が失敗しました。 この問題は、サーバーで次の資格情報を試行したときに発生しました: <FriendlyNameOfCredentials>。 アプライアンス上のサーバー資格情報が有効であり、資格情報のユーザー名がユーザー プリンシパル名 (UPN) 形式であることを確認してください。 (考えられる原因の中で、Azure Migrate によって試行された資格情報のフレンドリ名を見つけます)。
9020: サーバー上で、検出されたメタデータを含めるために必要なファイルを作成できません。 アプライアンス上で指定された資格情報に関連付けられているロールまたはオンプレミスのグループ ポリシーによって、必要なフォルダー内でのファイル作成が制限されています。 この問題は、サーバーで次の資格情報を試行したときに発生しました: <FriendlyNameOfCredentials>。 1. アプライアンスで指定された資格情報に、サーバーのフォルダー <フォルダー パス/フォルダー名> でのファイル作成アクセス許可があるかどうかを確認します。
2. アプライアンス上で指定された資格情報に必要なアクセス許可がない場合は、別の資格情報セットを指定するか、既存のものを編集します。 (考えられる原因の中で、Azure Migrate によって試行された資格情報のフレンドリ名を見つけます)。
9021: サーバー上で、検出されたメタデータを含めるために必要なファイルを正しいパスで作成できません。 VMware ツールから、ファイルを作成するためのファイル パスが正しくないことが報告されています。 バージョン 10.2.0 より後の VMware ツールが確実にサーバーにインストールされ、実行されているようにします。
9022: Get-WmiObject コマンドレットをサーバーで実行するためのアクセスが拒否されました。 アプライアンス上で指定された資格情報に関連付けられているロールまたはオンプレミスのグループ ポリシーによって、WMI オブジェクトへのアクセスが制限されています。 この問題は、サーバーで次の資格情報を試行したときに発生しました: <FriendlyNameOfCredentials>。 1. アプライアンス上で指定された資格情報に、ファイル作成管理者権限があり、WMI が有効になっているかどうかを調べます。
2. アプライアンス上で指定された資格情報に必要なアクセス許可がない場合は、別の資格情報セットを指定するか、既存のものを編集します。 (考えられる原因の中で、Azure Migrate によって試行された資格情報のフレンドリ名を見つけます)。

この問題の修復方法については、こちらをご覧ください。
9023: %SystemRoot% 環境変数の値が空のため、PowerShell を実行できません。 サーバーで %SystemRoot% 環境変数の値が空です。 1. 影響を受けているサーバーで echo %systemroot% コマンドを実行して、この環境変数が空の値を返しているか調べます。
2. 問題が解決しない場合は、Microsoft サポート ケースを送信してください。
9024: %TEMP% 環境変数の値が空のため、検出を実行できません。 サーバーの %TEMP% 環境変数の値が空です。 1. 影響を受けているサーバーで echo %temp% コマンドを実行して、この環境変数が空の値を返しているか調べます。
2. 問題が解決しない場合は、Microsoft サポート ケースをお送りください。
9025: サーバー上の PowerShell が破損しているため、検出を実行できません。 サーバー上の PowerShell が破損しています。 影響を受けているサーバーで PowerShell を再インストールして、実行されていることをご確認ください。
9026: サーバーでゲスト操作を実行できません。 サーバーの現在の状態では、ゲスト操作の実行は許可されていません。 1. 影響を受けているサーバーが確実に稼働中であるようにします。
2. 問題が解決しない場合は、Microsoft サポート ケースをお送りください。
9027: サーバー上でゲスト操作エージェントが実行されていないため、メタデータを検出できません。 サーバー上のゲスト操作エージェントにアクセスできません。 バージョン 10.2.0 より後の VMware ツールが確実にサーバーにインストールされ、実行されているようにします。
9028: サーバー上のストレージが足りないため、検出されたメタデータを含めるために必要なファイルを作成できません。 サーバー ディスクに十分なストレージ スペースがありません。 影響を受けているサーバーのディスク ストレージに十分なスペースを確保してください。
9029: アプライアンス上で指定された資格情報に、PowerShell を実行するためのアクセス許可がありません。 アプライアンス上の資格情報に、PowerShell を実行するためのアクセス許可がありません。 この問題は、サーバーで次の資格情報を試行したときに発生しました: <FriendlyNameOfCredentials>。 1. アプライアンス上の資格情報で確実にサーバー上の PowerShell にアクセスできるようにします。
2. アプライアンス上の資格情報に必要なアクセス権がない場合は、別の資格情報セットを指定するか、既存のものを編集します。 (考えられる原因の中で、Azure Migrate によって試行された資格情報のフレンドリ名を見つけます)。
9030: サーバーがホストされている ESXi ホストが切断状態であるため、検出されたメタデータを収集できません。 サーバーが存在している ESXi ホストは切断状態です。 サーバーを実行している ESXi ホストが接続状態であるか確認してください。
9031: サーバーがホストされている ESXi ホストが応答していないため、検出されたメタデータを収集できません。 サーバーが存在している ESXi ホストは無効な状態です。 サーバーを実行している ESXi ホストが実行中で接続済みの状態であることを確認してください。
9032: 内部エラーが原因で検出できません。 この問題は内部エラーが原因で発生しました。 こちらの Web サイトの手順に従って、問題を修復してください。 問題が解決しない場合は、Microsoft サポート ケースを開いてください。
9033: サーバーに対してアプライアンス上で指定された資格情報のユーザー名に無効な文字が含まれているため、検出できません。 アプライアンス上の資格情報のユーザー名に無効な文字が含まれています。 この問題は、サーバーで次の資格情報を試行したときに発生しました: <FriendlyNameOfCredentials>。 アプライアンス上の資格情報のユーザー名に無効な文字が含まれないようにします。 アプライアンス構成マネージャーに戻って、資格情報を編集できます。 (考えられる原因の中で、Azure Migrate によって試行された資格情報のフレンドリ名を見つけます)。
9034: サーバーに対してアプライアンス上で指定された資格情報のユーザー名が UPN 形式でないため、検出できません。 アプライアンス上の資格情報に、UPN 形式のユーザー名が含まれません。 この問題は、サーバーで次の資格情報を試行したときに発生しました: <FriendlyNameOfCredentials>。 アプライアンス上の資格情報に、確実に UPN 形式のユーザー名が含まれるようにします。 アプライアンス構成マネージャーに戻って、資格情報を編集できます。 (考えられる原因の中で、Azure Migrate によって試行された資格情報のフレンドリ名を見つけます)。
9035: PowerShell の言語モードが正しく設定されていないため、検出できません。 PowerShell の言語モードが全言語に設定されていません。 PowerShell の言語モードが確実に全言語に設定されているようにします。
9036: サーバーに対してアプライアンス上で指定された資格情報のユーザー名が UPN 形式でないため、検出できません。 アプライアンス上の資格情報に、UPN 形式のユーザー名が含まれません。 この問題は、サーバーで次の資格情報を試行したときに発生しました: <FriendlyNameOfCredentials>。 アプライアンス上の資格情報に、確実に UPN 形式のユーザー名が含まれるようにします。 アプライアンス構成マネージャーに戻って、資格情報を編集できます。 (考えられる原因の中で、Azure Migrate によって試行された資格情報のフレンドリ名を見つけます)。
9037: サーバーからの応答時間が長いため、メタデータ収集が一時的に中断しています。 サーバーの応答に時間がかかりすぎています。 この問題は通常、24 時間以内に次のサイクルで自動的に解決されます。 問題が解決しない場合は、Microsoft サポート ケースを送信してください。
10000: サーバーで実行されているオペレーション システムの種類はサポートされていません。 サーバーで実行されているオペレーティング システムが Windows または Linux ではありません。 サポートされている OS の種類は Windows と Linux だけです。 <GuestOSName> オペレーティング システムは現在サポートされていません。
10001: サーバー上で、検出メタデータを収集するために必要なスクリプトが見つかりません。 検出を実行するために必要なスクリプトが、想定される場所から削除または除去された可能性があります。 Microsoft サポート ケースを送信して、この問題のトラブルシューティングの支援を受けてください。
10002: サーバーで検出操作がタイムアウトになりました。 この問題は、アプライアンス上の検出エージェントが想定どおりに動作していないことが原因で一時的に発生するおそれがあります。 この問題は通常、24 時間以内に次のサイクルで自動的に解決されます。 解決しない場合は、こちらの Web サイトの手順に従って問題を修復してください。 問題が解決しない場合は、Microsoft サポート ケースを開いてください。
10003: 検出操作を実行するプロセスがエラーで終了しました。 検出操作を実行するプロセスが、エラーのため突然終了しました。 この問題は通常、24 時間以内に次のサイクルで自動的に解決されます。 問題が解決しない場合は、Microsoft サポート ケースを送信してください。
10004: サーバー OS の種類に対する資格情報がアプライアンス上で指定されていません。 サーバー OS の種類に対する資格情報がアプライアンス上で追加されませんでした。 1. 影響を受けているサーバーの OS の種類に対する資格情報をアプライアンス上で追加するようにします。
2. 複数のサーバー資格情報をアプライアンスで追加できるようになりました。
10005: サーバーに対して、アプライアンス上で指定された資格情報が無効です。 アプライアンス上で指定された資格情報が無効です。 この問題は、サーバーで次の資格情報を試行したときに発生しました: <FriendlyNameOfCredentials>。 1. アプライアンス上で指定された資格情報が有効であること、この資格情報を使用してサーバーにアクセスできることを確認します。
2. 複数のサーバー資格情報をアプライアンスで追加できるようになりました。
3. アプライアンス構成マネージャーに戻り、別の資格情報のセットを指定するか、既存のものを編集します。 (考えられる原因の中で、Azure Migrate によって試行された資格情報のフレンドリ名を見つけます)。

この問題の修復方法については、こちらをご覧ください。
10006: サーバーで実行されているオペレーション システムの種類はサポートされていません。 サーバーで実行されているオペレーティング システムが Windows または Linux ではありません。 サポートされている OS の種類は Windows と Linux だけです。 <GuestOSName> オペレーティング システムは現在サポートされていません。
10007: サーバーからの検出されたメタデータを処理できません。 検出されたメタデータを含むファイルの内容を解析しているときエラーが発生しました。 Microsoft サポート ケースを送信して、この問題のトラブルシューティングの支援を受けてください。
10008: 検出されたメタデータを含めるために必要なファイルをサーバーに作成できません。 アプライアンスで指定された資格情報に関連付けられているロールまたはオンプレミスのグループ ポリシーによって、必要なフォルダーでのファイル作成が制限されています。 この問題は、サーバーで次の資格情報を試行したときに発生しました: <FriendlyNameOfCredentials>。 1. アプライアンスで指定された資格情報に、サーバーのフォルダー <フォルダー パス/フォルダー名> でのファイル作成アクセス許可があるかどうかを確認します。
2. アプライアンス上で指定された資格情報に必要なアクセス許可がない場合は、別の資格情報セットを指定するか、既存のものを編集します。 (考えられる原因の中で、Azure Migrate によって試行された資格情報のフレンドリ名を見つけます)。
10009: 検出されたメタデータをサーバー上のファイルに書き込めません。 アプライアンスで指定された資格情報に関連付けられているロール、またはオンプレミスのグループ ポリシーによって、サーバー上のファイルへの書き込みが制限されています。 この問題は、サーバーで次の資格情報を試行したときに発生しました: <FriendlyNameOfCredentials>。 1. アプライアンスで指定された資格情報に、サーバーのフォルダー <フォルダー パス/フォルダー名> でのファイル書き込みアクセス許可があるかどうかを確認します。
2. アプライアンス上で指定された資格情報に必要なアクセス許可がない場合は、別の資格情報セットを指定するか、既存のものを編集します。 (考えられる原因の中で、Azure Migrate によって試行された資格情報のフレンドリ名を見つけます)。
10010: メタデータを収集するために必要なコマンド %CommandName; がサーバー上で見つからないため、検出できません。 コマンド %CommandName; を含むパッケージがサーバーにインストールされていません。 コマンド %CommandName; を含むパッケージがサーバーにインストールされているようにします。
10011: アプライアンス上で指定された資格情報が、対話型セッションのログインとログアウトに使用されました。 対話型のログインとログアウトにより、使用されているアカウントのプロファイルでレジストリ キーが強制的にアンロードされます。 この条件により、キーを後で使用することができなくなります。 こちらの Web サイトに記載されている解決方法を使用してください。
10012: サーバーに対する資格情報が、アプライアンス上で指定されていません。 サーバーに対して資格情報が指定されていないか、アプライアンス上で指定したドメイン資格情報のドメイン名が正しくありません。 このエラーの原因の詳細については、こちらをご覧ください。 1. サーバーに対してアプライアンス上で資格情報が指定され、資格情報を使用してサーバーにアクセスできることを確認します。
2. サーバー向けの複数の資格情報をアプライアンスで追加できるようになりました。 アプライアンス構成マネージャーに戻り、サーバーの資格情報を指定します。

エラー 970: DependencyMapInsufficientPrivilegesException

原因

このエラーは通常、必要な権限を持つ資格情報をアプライアンス上で指定していない場合に、Linux サーバーで表示されます。

Remediation

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

  • root ユーザー アカウントを指定したことを確認します。
  • アカウントに /bin/netstat および /bin/ls のファイルに対して次のアクセス許可があることを確認します。
    • CAP_DAC_READ_SEARCH
    • CAP_SYS_PTRACE

アプライアンス上で指定されたユーザー アカウントに必要な権限があるかを調べるには:

  1. このエラーが発生したサーバーに、エラー メッセージに示されているのと同じユーザー アカウントでログインします。

  2. Azure Shellsh で、次のコマンドを実行します。 エージェントレスの依存関係分析に必要な権限がない場合、エラーが発生します。

    ps -o pid,cmd | grep -v ]$
    netstat -atnp | awk '{print $4,$5,$7}'
    
  3. 次のコマンドを実行して、/bin/netstat および /bin/ls の各ファイルに対して必要なアクセス許可を設定します。

    sudo setcap CAP_DAC_READ_SEARCH,CAP_SYS_PTRACE=ep /bin/ls
    sudo setcap CAP_DAC_READ_SEARCH,CAP_SYS_PTRACE=ep /bin/netstat
    
  4. 上記のコマンドによってユーザー アカウントに必要なアクセス許可が割り当てられたかどうかを検証できます。

    getcap /usr/bin/ls
    getcap /usr/bin/netstat
    
  5. 手順 2 で指定したコマンドを再実行して、正常な出力を取得します。

エラー 9014: HTTPGetRequestToRetrieveFileFailed

原因

この問題は、アプライアンス内の VMware 検出エージェントが、依存関係データを含む出力ファイルを、サーバー ファイル システムから、サーバーがホストされている ESXi ホストを経由してダウンロードしようとしたときに発生します。

Remediation

  • アプライアンスからポート 443 上の ESXi ホスト "(名前はエラー メッセージに示されている)" (依存関係データをプルするために ESXi ホストで開く必要がある) への TCP 接続をテストできます。 アプライアンス サーバーで PowerShell を開き、次のコマンドを実行します。

    Test -NetConnection -ComputeName <Ip address of the ESXi host> -Port 443
    
  • コマンドから正常な接続が返された場合は、Azure Migrate プロジェクト>Discovery and Assessment>[概要]>[管理]>[アプライアンス] に移動し、アプライアンス名を選択して、[Refresh services]\(サービスの更新\)を選択します。

エラー 9018: PowerShellNotFound

原因

このエラーは通常、Windows Server 2008 以前を実行しているサーバーで表示されます。

Remediation

サーバー上のこの場所に Windows PowerShell 5.1 をインストールします。 WMF 5.1 のインストールおよび構成に関する記事の手順に従って、Windows Server に PowerShell をインストールします。

必要な PowerShell バージョンをインストールしたら、こちらの Web サイトの手順に従って、エラーが解決したかどうかを検証してください。

エラー 9022: GetWMIObjectAccessDenied

Remediation

アプライアンスで指定されたユーザー アカウントが WMI 名前空間および副名前空間にアクセスできることを確認します。 アクセスを設定するには:

  1. このエラーを報告しているサーバーに移動します。
  2. スタート メニューで [ファイル名を指定して実行] を検索して選択します。 [ファイル名を指定して実行] ダイアログで、[名前] テキスト ボックスに「wmimgmt.msc」と入力し、Enter を選択します。
  3. wmimgmt コンソールが開き、左側のペインに [WMI コントロール (ローカル)] が表示されます。 それを右クリックして、メニューから [プロパティ] を選択します。
  4. [WMI コントロール (ローカル) のプロパティ] ダイアログで、[セキュリティ] タブを選択します。
  5. [セキュリティ] タブで、[セキュリティ] を選択して [セキュリティ Root] ダイアログを開きます。
  6. [詳細設定] を選択して、[Root のセキュリティの詳細設定] ダイアログを開きます。
  7. [追加] を選択して、[Root のアクセス許可エントリ] ダイアログを開きます。
  8. [プリンシパルの選択] をクリックして、[Select Users, Computers, Service Accounts, or Groups]\(ユーザー、コンピューター、サービス アカウントまたはグループの選択\) ダイアログを開きます。
  9. WMI へのアクセス権を付与するユーザー名またはグループを選択して、[OK] を選択します。
  10. 実行アクセス許可を付与し、[適用先] ドロップダウン リストで [この名前空間と副名前空間] を選択します。
  11. [適用] を選択して設定を保存し、すべてのダイアログを閉じます。

必要なアクセス権を取得したら、こちらの Web サイトの手順に従って、エラーが解決したかどうかを検証してください。

エラー 9032: InvalidRequest

原因

この問題には複数の理由が考えられます。 理由の 1 つは、アプライアンス構成マネージャーで指定されたユーザー名 (サーバー資格情報) に無効な XML 文字が含まれている場合です。 無効な文字があると、SOAP 要求の解析中にエラーが発生します。

Remediation

  • サーバー資格情報のユーザー名に無効な XML 文字が含まれておらず、username@domain.com 形式であることをご確認ください。 この形式は、一般に UPN 形式と呼ばれています。
  • アプライアンス上の資格情報を編集したら、こちらの Web サイトの手順に従って、エラーが解決したかどうかを検証してください。

エラー 10002: ScriptExecutionTimedOutOnVm

原因

  • このエラーは、サーバーが遅いか応答がなく、依存関係データをプルするために実行されたスクリプトがタイムアウトし始めると発生します。
  • このエラーが検出エージェントによってサーバー上で検出されると、その後は、応答しないサーバーが過負荷にならないように、サーバー上のエージェントレスの依存関係分析はアプライアンスによって試行されません。
  • サーバーの問題を確認し、検出サービスを再起動するまで、エラーが表示され続けます。

Remediation

  1. このエラーが発生しているサーバーにログインします。

  2. PowerShell で次のコマンドを実行します。

    Get-WMIObject win32_operatingsystem;
    Get-WindowsFeature  | Where-Object {$_.InstallState -eq 'Installed' -or ($_.InstallState -eq $null -and $_.Installed -eq 'True')};
    Get-WmiObject Win32_Process;
    netstat -ano -p tcp | select -Skip 4;
    
  3. コマンドの結果が数秒で出力された場合は、Azure Migrate プロジェクト>Discovery and Assessment>[概要]>[管理]>[アプライアンス] に移動し、アプライアンス名を選択し、[Refresh services]\(サービスの更新\) を選択して検出サービスを再開します。

  4. コマンドから出力が返されずにタイムアウトする場合は、次のことを行う必要があります。

    • サーバー上の CPU またはメモリを大きく消費しているプロセスがどれかを見つけ出す。
    • さらに多くのコアまたはメモリをそのサーバーに提供して、コマンドを再実行してみる。

エラー 10005: GuestCredentialNotValid

Remediation

  • アプライアンス構成マネージャーで [Revalidate credentials]\(資格情報の再検証\) を選択して、資格情報 "(エラーに表示されるフレンドリ名)" が確実に有効であるようにします。
  • アプライアンスに指定されたのと同じ資格情報を使用して、影響を受けているサーバーに確実にログインできようにします。
  • そのサーバーに対して、(サーバーがドメインに参加している場合は同じドメインの) 別のユーザー アカウントを、管理者アカウントの代わりに使用してみることができます。
  • この問題は、グローバル カタログ <-> ドメイン コントローラー間の通信が切断されているときに発生する可能性があります。 この問題を調べるには、ドメイン コントローラーで新しいユーザー アカウントを作成し、同じものをアプライアンスに指定します。 また、ドメイン コントローラーの再起動が必要になる場合もあります。
  • 修復手順を行ったら、こちらの Web サイトの手順に従って、エラーが解決したかどうかを検証してください。

エラー 10012: CredentialNotProvided

原因

このエラーは、ドメイン名が正しくないドメイン資格情報をアプライアンス構成マネージャーで指定したときに発生します。 たとえば、ユーザー名が user@abc.com のドメイン資格情報を指定したが、ドメイン名を def.com と指定した場合、サーバーが def.com に接続されていると、これらの資格情報は試行されず、このエラー メッセージが表示されます。

Remediation

  • アプライアンス構成マネージャーにアクセスしてサーバー資格情報を追加するか、原因で説明されているように、既存のものを編集します。
  • 修復手順を行ったら、こちらの Web サイトの手順に従って、エラーが解決したかどうかを検証してください。

エラー 9014: HTTPGetRequestToRetrieveFileFailed/ 975: MaxLimitExceededForDepMap /976: AutoenableDisabledForDepMap

修復

  1. アプライアンスを実行しているサーバーで、レジストリ エディターを開きます。

  2. HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\AzureAppliance に移動します (スペースのないフォルダーを使用してください)。

  3. "String" の型と値が "false" のレジストリ キー DepMapAutoEnable を追加します。

    レジストリ キーを示すスクリーンショット。

  4. プロジェクト内の 1 つ以上の検出されたサーバーの依存関係分析を手動で有効にしていることを確認します。

  5. アプライアンス サーバーを再起動します。 1 時間待ってから、問題が解決されているかどうかを確認します。

軽減策の検証

上記のエラーの軽減手順を使用したら、アプライアンス サーバーからいくつかの PowerCLI コマンドを実行して、軽減策が機能したかどうかを検証してください。 コマンドが成功した場合は、問題が解決されたことを意味します。 そうでない場合は、もう一度確認して修復手順に従ってください。

VMware VM (VMware パイプを使用) の場合

  1. 次のコマンドを実行して、PowerCLI をアプライアンス サーバーで設定します。

    Install-Module -Name VMware.PowerCLI -AllowClobber
    Set-PowerCLIConfiguration -InvalidCertificateAction Ignore
    
  2. コマンドに vCenter Server の IP アドレスを、プロンプトに資格情報を入力して、アプライアンスから vCenter Server に接続します。

    Connect-VIServer -Server <IPAddress of vCenter Server>
    
  3. サーバー名とサーバー資格情報をアプライアンス上で指定したように指定して、アプライアンスからターゲット サーバーに接続します。

    $vm = get-VM <VMName>
    $credential = Get-Credential
    
  4. エージェントレスの依存関係分析の場合は、次のコマンドを実行して、正常に出力されることを確認します。

    • Windows サーバーの場合:

      Invoke-VMScript -VM $vm -ScriptText "powershell.exe 'Get-WmiObject Win32_Process'" -GuestCredential $credential
      
      Invoke-VMScript -VM $vm -ScriptText "powershell.exe 'netstat -ano -p tcp'" -GuestCredential $credential
      
    • Linux サーバーの場合:

      Invoke-VMScript -VM $vm -ScriptText "ps -o pid,cmd | grep -v ]$" -GuestCredential $credential
      
      Invoke-VMScript -VM $vm -ScriptText "netstat -atnp | awk '{print $4,$5,$7}'" -GuestCredential $credential
      

Hyper-V VM と物理サーバー (直接接続パイプを使用) の場合

Windows サーバーの場合:

  1. 以下のコマンドを実行して Windows サーバーに接続します:

    $Server = New-PSSession –ComputerName <IPAddress of Server> -Credential <user_name>
    

    プロンプトにサーバーの資格情報を入力します。

  2. エージェントレスの依存関係分析の場合は、次のコマンドを実行して、正常に出力されることを確認します。

    Invoke-Command -Session $Server -ScriptBlock {Get-WmiObject Win32_Process}
    Invoke-Command -Session $Server -ScriptBlock {netstat -ano -p tcp}
    

Linux サーバーの場合:

  1. OpenSSH クライアントをインストールする
    Add-WindowsCapability -Online -Name OpenSSH.Client~~~~0.0.1.0
    
  2. OpenSSH サーバーをインストールする
    Add-WindowsCapability -Online -Name OpenSSH.Server~~~~0.0.1.0
    
  3. OpenSSH サーバーを起動して構成する
    Start-Service sshd
    Set-Service -Name sshd -StartupType 'Automatic'
    
  4. OpenSSH サーバーに接続する
    ssh username@servername
    
  5. エージェントレスの依存関係分析の場合は、次のコマンドを実行して、正常に出力されることを確認します。
    ps -o pid,cmd | grep -v ]$
    netstat -atnp | awk '{print $4,$5,$7}'
    

軽減策が効いたことを確認したら、Azure Migrate プロジェクト>Discovery and Assessment>[概要]>[管理]>[アプライアンス] に移動し、アプライアンス名を選択し、[Refresh services]\(サービスの更新\) を選択して検出サイクルを開始します。

Azure Migrate でワークスペースをエージェントベースの依存関係分析のために構成しようとしたときに自分の Log Analytics ワークスペースが一覧にない

現在、Azure Migrate では、米国東部、東南アジア、および西ヨーロッパの各リージョンで OMS ワークスペースの作成がサポートされています。 ワークスペースがその他のリージョンの Azure Migrate の外部で作成されている場合、現在、プロジェクトに関連付けることはできません。

Azure Government でのエージェントベースの依存関係の視覚化

エージェントベースの依存関係の分析は、Azure Government ではサポートされません。 エージェントレスの依存関係分析を使用してください、これは、"VMware サーバーでのみ使用できます"。

エージェントベースの依存関係がエージェント インストール後に表示されない

オンプレミスの VM に依存関係視覚化エージェントをインストールした後、Azure Migrate によって、依存関係がポータルに表示されるまで 15 分から 30 分かかります。 30 分以上待っている場合は、Microsoft Monitoring Agent (MMA) が Log Analytics ワークスペースに接続できることを確認してください。

Windows VM の場合:

  1. コントロール パネルで MMA を開始します。

  2. [Microsoft Monitoring Agent のプロパティ]>[Azure Log Analytics (OMS)] で、ワークスペースの [状態] が緑色になっていることを確認します。

  3. 状態が緑色でない場合は、ワークスペースを削除して、再度 MMA に追加してみてください。

    MMA 状態を示すスクリーンショット。

Linux VM の場合、MMA と依存関係エージェントのインストールに関するすべてのコマンドが正常に実行されたことを確認します。 詳細については、こちらの Web サイトのトラブルシューティング ガイドを参照してください。

エージェントベースの依存関係分析でサポートされているオペレーティング システム

  • MMS エージェント: サポートされている Windows および Linux オペレーティング システム。
  • 依存関係エージェント: サポートされている Windows および Linux オペレーティング システム。

エージェントベースの依存関係分析を使って 1 時間を超える依存関係を視覚化する

エージェント ベースの依存関係分析を使用する場合、Azure Migrate では、過去 1 か月間の特定の日付に戻ることができますが、依存関係を視覚化できる期間は最大 1 時間です。 たとえば、依存関係マップにある期間機能を使用して、昨日の依存関係を表示することが可能ですが、1 時間の期間のみ表示できます。 Azure Monitor ログを使用すると、より長期間にわたって依存関係データのクエリを実行できます。

エージェントベースの依存関係分析を使って 10 台を超えるサーバーの依存関係を視覚化する

Azure Migrate では、エージェント ベースの依存関係の分析を使用すると、最大 10 個の VM を含むグループの依存関係を視覚化できます。 それより大きいグループの場合は、VM をそれより小さいグループに分割して、依存関係を視覚化してください。

エージェントベースの依存関係分析でサーバーに "エージェントのインストール" が表示される

依存関係の視覚化が有効になっているサーバーを Azure に移行した後、サーバーで、次の動作が原因で、[依存関係の表示] ではなく、[エージェントのインストール] アクションが表示される場合があります。

  • Azure に移行した後、オンプレミスのサーバーはオフになり、同等の VM が Azure で起動されます。 これらのサーバーは、別々の MAC アドレスを取得します。
  • ユーザーがオンプレミスの IP アドレスを保持するかどうかにより、サーバーは異なる IP アドレスも取得する場合があります。
  • MAC と IP アドレスの両方がオンプレミスと異なる場合、Azure Migrate ではオンプレミスのサーバーと Service Map 依存関係データの関連付けは行われません。 この場合に、依存関係の表示ではなく、エージェントのインストール オプションが表示されます。
  • Azure へのテスト移行の後、オンプレミスのサーバーは想定どおりにオンの状態が維持されます。 Azure にスピン アップされる同等のサーバーでは、異なる MAC アドレスが取得されます。異なる IP アドレスが取得されることもあります。 これらのサーバーから送信される Azure Monitor ログ トラフィックをブロックする場合を除き、Azure Migrate では、オンプレミスのサーバーと Service Map 依存関係データの関連付けは行われません。 この場合に、依存関係の表示ではなく、エージェントのインストール オプションが表示されます。

ネットワーク トラフィックをキャプチャする

ネットワーク トラフィック ログを収集するには:

  1. Azure portal にサインインします。
  2. F12 キーを選択して開発者ツールを起動します。 必要な場合は、[ナビゲーション時にエントリをクリア] の設定をオフにします。
  3. [ネットワーク] タブを選択し、ネットワーク トラフィックのキャプチャを開始します。
    • Chrome では、[Preserve log]\(ログの保持\) を選択します。 自動で記録が開始されるはずです。 赤い円は、トラフィックがキャプチャされていることを示しています。 赤い円が表示されない場合は、黒い円を選択して開始します。
    • Microsoft Edge または Internet Explorer では、自動で記録が開始されるはずです。 開始されない場合は、緑色の再生ボタンを選択します。
  4. エラーを再現してみます。
  5. 記録中にエラーが発生したら、記録を停止し、記録されたアクティビティのコピーを保存します。
    • Chrome では、右クリックして [Save as HAR with content]\(内容を HAR ファイルに保存する\) を選択します。 この操作により、ログが圧縮されて HTTP Archive (har) ファイルとしてエクスポートされます。
    • Microsoft Edge または Internet Explorer で、[キャプチャしたトラフィックのエクスポート] オプションを選択します。 この操作により、ログが圧縮されてエクスポートされます。
  6. [コンソール] タブを選択し、いずれかの警告またはエラーを確認します。 コンソール ログを保存するには次の操作を行います。
    • Chrome では、コンソール ログのどこかを右クリックします。 [名前を付けて保存] を選択し、ログをエクスポートして zip 圧縮します。
    • Microsoft Edge または Internet Explorer では、エラーを右クリックして [すべてコピー] を選択します。
  7. 開発者ツールを閉じます。

次のステップ

評価を作成するかカスタマイズします。