Azure 間 VM レプリケーションエラーのトラブルシューティング - その他の問題

この記事では、リージョン間で Azure 仮想マシン (VM) のレプリケーションと復旧を行うときに Azure Site Recovery で一般的なエラーをトラブルシューティングする方法について説明します。サポートされる構成の詳細については、Azure VM をレプリケートするためのサポートマトリックスに関するページをご覧ください。

Azure リソースのクォータに関する問題 (エラーコード 150097)

ディザスターリカバリー (DR) リージョンとして使用するターゲットリージョンで Azure VM を作成するには、サブスクリプションが有効であることを確認してください。必要なサイズの VM を作成するには、サブスクリプションに十分なクォータが必要です。既定では、Site Recovery ではソース VM のサイズと同じターゲット VM サイズが選択されます。同じサイズを利用できない場合、Site Recovery では利用可能な最も近いサイズが自動的に選択されます。

ソース VM 構成をサポートするサイズが存在しない場合、次のメッセージが表示されます。

Replication couldn't be enabled for the virtual machine <VmName>.

考えられる原因

ターゲットリージョンの場所で VM を作成するための、サブスクリプション ID が有効になっていません。
ターゲットリージョンの場所で特定の VM サイズを作成するための、サブスクリプション ID が有効になっていないか、十分なクォータが確保されていません。
ターゲットリージョンの場所のサブスクリプション ID について、ソース VM のネットワークインターフェイスカード (NIC) の数 (2) と一致する適切なターゲットVM サイズが見つかりません。

Workaround

Azure 課金のサポートに連絡して、サブスクリプションで、必要なサイズの VM をターゲットの場所に作成できるようにします。その後、失敗した操作をやり直してください。

ターゲットの場所に容量の制約がある場合は、その場所へのレプリケーションを無効にします。次に、必要なサイズの VM を作成できるだけのクォータがサブスクリプションに確保されている別の場所へのレプリケーションを有効にします。

信頼されたルート証明書 (エラーコード 151066)

最新の信頼されたルート証明書の一部が VM にない場合、Site Recovery のレプリケーションを有効にするジョブが失敗することがあります。これらの証明書がないと、VM からの Site Recovery サービス呼び出しの認証と承認が失敗します。

レプリケーションを有効にするジョブが失敗すると、次のメッセージが表示されます。

Site Recovery configuration failed.

考えられる原因

承認と認証に必要な信頼されたルート証明書が仮想マシンに存在しません。

Workaround

ウィンドウズ
リナックス

Windows オペレーティングシステムを実行中の VM の場合、最新 Windows 更新プログラムをインストールし、すべての信頼されたルート証明書が VM に存在するようにします。組織の一般的な Windows 更新管理プロセスまたは証明書更新管理プロセスに従って、VM で最新のルート証明書と更新済み証明書失効リストを取得します。

接続されていない環境の場合は、組織の標準の Windows 更新プロセスに従って、証明書を取得してください。
VM に必要な証明書がない場合は、セキュリティ上の理由から、Site Recovery サービスへの呼び出しが失敗します。

問題が解決されたことを確認するには、VM のブラウザーから login.microsoftonline.com にアクセスします。

詳細については、「信頼されたルートおよび許可されない証明書を構成する」を参照してください。

お使いの Linux オペレーティングシステムバージョンのディストリビューターから提供されるガイダンスに従って、VM で最新の信頼されたルート証明書と最新の証明書失効リストを取得します。

Important

RedHat Linux マシンの場合は、証明書エラーを回避するために、Ca -Trust 証明書を /etc/pki/ca-trust/ に追加します。

SUSE Linux ではシンボリックリンク (symlink) を使用して証明書リストを保持しているため、次の手順に従います。

ルート ユーザーとしてサインインします。ハッシュ記号 (#) は、既定のコマンドプロンプトです。
ディレクトリを変更するには、次のコマンドを実行します。

cd /etc/ssl/certs
Symantec ルート CA 証明書が存在するかどうかを確認します。

ls VeriSign_Class_3_Public_Primary_Certification_Authority_G5.pem
- Symantec ルート CA 証明書が見つからない場合は、次のコマンドを実行してファイルをダウンロードします。エラーがないか確認し、ネットワーク障害に対する推奨アクションに従います。
  
  wget https://docs.broadcom.com/docs-and-downloads/content/dam/symantec/docs/other-resources/verisign-class-3-public-primary-certification-authority-g5-en.pem -O VeriSign_Class_3_Public_Primary_Certification_Authority_G5.pem
Baltimore ルート CA 証明書が存在するかどうかを確認します。

ls Baltimore_CyberTrust_Root.pem
- Baltimore ルート CA 証明書が見つからない場合は、次のコマンドを実行して証明書をダウンロードします。
  
  wget https://www.digicert.com/CACerts/BaltimoreCyberTrustRoot.crt.pem -O Baltimore_CyberTrust_Root.pem
DigiCert_Global_Root_CA 証明書が存在するかどうかを確認します。

ls DigiCert_Global_Root_CA.pem
- DigiCert_Global_Root_CA が見つからない場合は、次のコマンドを実行して証明書をダウンロードします。
```
wget http://www.digicert.com/CACerts/DigiCertGlobalRootCA.crt

openssl x509 -in DigiCertGlobalRootCA.crt -inform der -outform pem -out DigiCert_Global_Root_CA.pem
```
新たにダウンロードした証明書のサブジェクトハッシュを更新するには、再ハッシュスクリプトを実行します。

c_rehash

シンボリックリンクとしてのサブジェクトハッシュが証明書に対して作成されているかどうかを確認するには、次のコマンドを実行します。

ls -l | grep Baltimore

lrwxrwxrwx 1 root root   29 Jan  8 09:48 3ad48a91.0 -> Baltimore_CyberTrust_Root.pem

-rw-r--r-- 1 root root 1303 Jun  5  2014 Baltimore_CyberTrust_Root.pem

ls -l | grep VeriSign_Class_3_Public_Primary_Certification_Authority_G5

-rw-r--r-- 1 root root 1774 Jun  5  2014 VeriSign_Class_3_Public_Primary_Certification_Authority_G5.pem

lrwxrwxrwx 1 root root   62 Jan  8 09:48 facacbc6.0 -> VeriSign_Class_3_Public_Primary_Certification_Authority_G5.pem

ls -l | grep DigiCert_Global_Root

lrwxrwxrwx 1 root root   27 Jan  8 09:48 399e7759.0 -> DigiCert_Global_Root_CA.pem

-rw-r--r-- 1 root root 1380 Jun  5  2014 DigiCert_Global_Root_CA.pem

ファイル VeriSign_Class_3_Public_Primary_Certification_Authority_G5.pem のコピーを b204d74a.0 というファイル名で作成します。

cp VeriSign_Class_3_Public_Primary_Certification_Authority_G5.pem b204d74a.0
ファイル Baltimore_CyberTrust_Root.pem のコピーを 653b494a.0 というファイル名で作成します。

cp Baltimore_CyberTrust_Root.pem 653b494a.0
ファイル DigiCert_Global_Root_CA.pem のコピーを 3513523f.0 というファイル名で作成します。

cp DigiCert_Global_Root_CA.pem 3513523f.0

これらのファイルが存在するかどうかを確認します。

ls -l 653b494a.0 b204d74a.0 3513523f.0

-rw-r--r-- 1 root root 1774 Jan  8 09:52 3513523f.0

-rw-r--r-- 1 root root 1303 Jan  8 09:52 653b494a.0

-rw-r--r-- 1 root root 1774 Jan  8 09:52 b204d74a.0

送信 URL または IP 範囲 (エラーコード 151037 または 151072)

Site Recovery レプリケーションを動作させるには、VM から特定の URL への送信接続が必要です。 VM がファイアウォールの内側にあるか、ネットワークセキュリティグループ (NSG) ルールを使用して送信接続を制御している場合は、次のいずれかの問題に直面することがあります。 URL を介した送信アクセスは引き続きサポートされますが、IP 範囲の許可リストの使用はサポートされなくなりました。

考えられる原因

ドメインネームシステム (DNS) を解決できないため、Site Recovery エンドポイントとの接続を確立できません。
この問題が頻繁に発生するのは、仮想マシンをフェールオーバーして再保護を行っているときに、ディザスターリカバリー (DR) リージョンから DNS サーバーに到達できない場合です。

Workaround

カスタム DNS を使っている場合は、ディザスターリカバリーリージョンから DNS サーバーにアクセスできることを確認します。

VM がカスタム DNS 設定を使用するかどうかを確認するには、次を実行します。

[仮想マシン] を開いて、VM を選択します。
VM の [設定] に移動し、 [ネットワーク] を選択します。
[仮想ネットワーク/サブネット] で、仮想ネットワークのリソースページを開くためのリンクを選択します。
[設定] に移動して、 [DNS サーバー] を選択します。

仮想マシンから DNS サーバーにアクセスを試みます。 DNS サーバーにアクセスできない場合は、DNS サーバーをフェールオーバーするか、または DR ネットワークと DNS の間にサイトのラインを作成して、アクセスできるようにします。

Note

プライベートエンドポイントを使用する場合は、確実に VM によるプライベート DNS レコードの解決が可能であるようにします。

com-error。

問題 2:Site Recovery の構成に失敗しました (151196)

考えられる原因

Microsoft 365 認証と ID IP4 エンドポイントへの接続を確立できません。

Workaround

Azure Site Recovery では、認証のために Microsoft 365 の IP 範囲にアクセスする必要がありました。 Azure ネットワークセキュリティグループ (NSG) 規則またはファイアウォールプロキシを使用して VM での送信ネットワーク接続を制御している場合、Microsoft Entra ID へのアクセスを許可するには、Microsoft Entra サービスタグに基づく NSG 規則を必ず使用してください。 IP アドレスベースの NSG 規則はサポートしなくなりました。

問題 3:Site Recovery の構成に失敗しました (151197)

考えられる原因

Azure Site Recovery サービスのエンドポイントに対する接続を確立できません。

Workaround

VM での発信ネットワーク接続の制御に Azure ネットワークセキュリティグループ (NSG) 規則またはファイアウォールプロキシを使用している場合は、確実にサービスタグを使用してください。 Azure Site Recovery の NSG を介した IP アドレスの許可リストの使用はサポートされなくなりました。

問題 4:ネットワークトラフィックでオンプレミスのプロキシサーバーが使用されるとレプリケーションが失敗する (151072)

考えられる原因

カスタムプロキシ設定が無効であり、Mobility Service エージェントが Internet Explorer からプロキシ設定を自動検出しませんでした。

Workaround

Mobility Service エージェントは、Windows では Internet Explorer から、Linux では /etc/environment からプロキシ設定を検出します。
プロキシを Mobility Service にのみ設定する場合は、次の場所にある ProxyInfo.conf 内にプロキシの詳細を指定できます。
- Linux: /usr/local/InMage/config/
- Windows: C:\ProgramData\Microsoft Azure Site Recovery\Config
ProxyInfo.conf 内のプロキシ設定は、次の INI 形式になっている必要があります。
```
[proxy]
Address=http://1.2.3.4
Port=567
```

Note

Mobility Service エージェントは、認証されていないプロキシのみをサポートします。

詳細情報

必要な URL または必要な IP 範囲を指定するには、「Azure から Azure へのレプリケーションのネットワークについて」のガイダンスに従ってください。

COM+ または VSS (エラーコード 151025)

COM+ またはボリュームシャドウコピーサービス (VSS) エラーが発生すると、次のメッセージが表示されます。

Site Recovery extension failed to install.

考えられる原因

COM+ システムアプリケーションサービスが無効になっています。
ボリュームシャドウコピーサービスが無効になっています。

Workaround

COM+ システムアプリケーションとボリュームシャドウコピーサービスを、自動または手動スタートアップモードに設定します。

Windows の "サービス" コンソールを開きます。
COM+ システムアプリケーションとボリュームシャドウコピーサービスの [スタートアップの種類] が [無効] に設定されていないことを確認します。

サポートされていないマネージドディスクのサイズ (エラーコード 150172)

このエラーが発生すると、次のメッセージが表示されます。

Protection couldn't be enabled for the virtual machine as it has <DiskName> with size <DiskSize> that is lesser than the minimum supported size 1024 MB.

考えられる原因

ディスクが、サポートされているサイズの 1024 MB を下回っています。

Workaround

ディスクサイズがサポートされているサイズの範囲内にあることを確認し、操作を再試行してください。

Mobility Service の更新が完了し、警告が表示された (エラーコード 151083)

Site Recovery Mobility Service には多数のコンポーネントがありますが、そのうちの 1 つに、フィルタードライバーと呼ばれるものがあります。フィルタードライバーは、システムの再起動時にのみ、システムメモリ内に読み込まれます。 Mobility Service の更新にフィルタードライバーの変更が含まれている場合、マシンは更新されますが、一部の修正プログラムで再起動が必要であることを示す警告が表示されます。この警告が表示される理由は、フィルタードライバーの修正は、新しいフィルタードライバーが読み込まれたときにのみ有効になるためであり、これは再起動中にのみ発生します。

Note

これはただの警告です。既存のレプリケーションは、新しいエージェントが更新された後も引き続き機能します。再起動は、新しいフィルタードライバーの利点を活用したい任意のタイミングで実行できますが、再起動しない場合は古いフィルタードライバーが動作し続けます。

フィルタードライバーを除く、Mobility Service の更新におけるその他の機能強化や修正の利点は、再起動を必要とせずに有効になります。

レプリカマネージドディスクが存在する場合は保護が有効にならない

このエラーは、レプリカマネージドディスクが (予測されるタグなしで) ターゲットリソースグループに既に存在する場合に発生します。

考えられる原因

この問題は、仮想マシンが以前に保護されていて、レプリケーションを無効にしたときにレプリカディスクが削除されていない場合に発生する可能性があります。

問題を解決する

エラーメッセージに示されているレプリカディスクを削除し、失敗した保護ジョブを再度開始します。

インストーラーがルートディスクを検出できないため、保護の有効化に失敗した (エラーコード 151137)

このエラーは、Azure Disk Encryption (ADE) を使用して OS ディスクが暗号化されている Linux マシンで発生します。これは、エージェントバージョン 9.35 でのみ有効な問題です。

考えられる原因

インストーラーは、ルートファイルシステムをホストしているルートディスクを検出できません。

問題を解決する

この問題を解決するには、次の手順を実行します。

次のコマンドを使用して、RHEL マシンの /var/lib/waagent ディレクトリにあるエージェントファイルを検索します。

# find /var/lib/ -name Micro\*.gz

予想される出力:

/var/lib/waagent/Microsoft.Azure.RecoveryServices.SiteRecovery.LinuxRHEL7-1.0.0.9139/UnifiedAgent/Microsoft-ASR_UA_9.35.0.0_RHEL7-64_GA_30Jun2020_release.tar.gz
新しいディレクトリを作成し、ディレクトリをこの新しいディレクトリに変更します。
次のコマンドを使用して、最初の手順で見つかったエージェントファイルを抽出します。

tar -xf <Tar Ball File>
prereq_check_installer.json ファイルを開き、次の行を削除します。その後、ファイルを保存します。
```
   {
      "CheckName": "SystemDiskAvailable",
      "CheckType": "MobilityService"
   },
```
次のコマンドを使用して、インストーラーを起動します。

./install -d /usr/local/ASR -r MS -q -v Azure
インストーラーが正常に完了したら、レプリケーションの有効化ジョブを再試行します。

保護コンテナ名の長さが超過しました (エラーコード 150257)

Protection container name <protectionContainerName> is not valid.

考えられる原因

保護コンテナー名が、 protectionContainerNameMaxLength 文字の最大許容長を超えています。

問題を解決する

別の名前を選択し、操作を再試行します。

レプリケートされたサーバーでの時間の変更に対するトラブルシューティングと処理

このエラーは、変更を修正するために、ソースマシンの時間が進み、その後短時間で戻る場合に発生します。時間が非常に迅速に修正されるため、変更に気付かないことがあります。

回避策 この問題を解決するには、システム時間が偏った将来の時刻を超えるまで待ちます。もう 1 つの選択肢は、レプリケーションを無効化し、もう一度有効化することです。これは、フォワードレプリケーション (データがプライマリリージョンからセカンダリリージョンにレプリケートされる) の場合のみ実行でき、リバースレプリケーション (データがセカンダリリージョンからプライマリリージョンにレプリケートされる) には適用できません。

次のステップ

Azure VM を別の Azure リージョンにレプリケートする。

フィードバック

このページはお役に立ちましたか?

Last updated on 2025-12-09

次の方法で共有

Azure 間 VM レプリケーション エラーのトラブルシューティング - その他の問題

Azure リソースのクォータに関する問題 (エラー コード 150097)

信頼されたルート証明書 (エラー コード 151066)

送信 URL または IP 範囲 (エラー コード 151037 または 151072)

問題 2:Site Recovery の構成に失敗しました (151196)

問題 3:Site Recovery の構成に失敗しました (151197)

問題 4:ネットワーク トラフィックでオンプレミスのプロキシ サーバーが使用されるとレプリケーションが失敗する (151072)

詳細情報

COM+ または VSS (エラー コード 151025)

サポートされていないマネージド ディスクのサイズ (エラー コード 150172)

Mobility Service の更新が完了し、警告が表示された (エラー コード 151083)

レプリカ マネージド ディスクが存在する場合は保護が有効にならない

考えられる原因

問題を解決する

インストーラーがルート ディスクを検出できないため、保護の有効化に失敗した (エラー コード 151137)

考えられる原因

問題を解決する

保護コンテナ名の長さが超過しました (エラー コード 150257)

考えられる原因

問題を解決する

レプリケートされたサーバーでの時間の変更に対するトラブルシューティングと処理

次のステップ

フィードバック

その他のリソース

Azure 間 VM レプリケーションエラーのトラブルシューティング - その他の問題

Azure リソースのクォータに関する問題 (エラーコード 150097)

信頼されたルート証明書 (エラーコード 151066)

送信 URL または IP 範囲 (エラーコード 151037 または 151072)

問題 4:ネットワークトラフィックでオンプレミスのプロキシサーバーが使用されるとレプリケーションが失敗する (151072)

COM+ または VSS (エラーコード 151025)

サポートされていないマネージドディスクのサイズ (エラーコード 150172)

Mobility Service の更新が完了し、警告が表示された (エラーコード 151083)

レプリカマネージドディスクが存在する場合は保護が有効にならない

インストーラーがルートディスクを検出できないため、保護の有効化に失敗した (エラーコード 151137)

保護コンテナ名の長さが超過しました (エラーコード 150257)