次の方法で共有

Azure ネットワーク接続のトラブルシューティング

  • [アーティクル]

Azure ネットワーク接続 (ANC) では、環境を定期的にチェックし、すべての要件が満たされており、正常な状態であることを確認します。 チェックが失敗した場合は、Microsoft Intune管理センターにエラー メッセージが表示されます。 このガイドには、チェックが失敗する原因となる可能性がある問題のトラブルシューティングに関する詳細な手順がいくつか含まれています。

Active Directory ドメイン参加

プロビジョニングされたクラウド PC は、指定されたドメインに自動的に参加します。 ドメイン参加プロセスをテストするために、Windows 365 正常性チェックが実行されるたびに、定義された組織単位 (OU) に "CPC-Hth" のような名前のドメイン コンピューター オブジェクトが作成されます。 これらのコンピューター オブジェクトは、正常性のチェックが完了すると無効になります。 Active Directory ドメイン参加エラーは、さまざまな理由で発生する可能性があります。 ドメイン参加に失敗した場合は、次のことを確認してください。

  • ドメイン参加ユーザーに、指定されたドメインに参加するのに十分なアクセス許可がある。
  • ドメイン参加ユーザーは、指定された組織単位 (OU) に書き込むことができる。
  • ドメイン参加ユーザーは、参加できるコンピューターの数について制限されていない。 たとえば、ユーザーあたりのデフォルトの最大結合数は 10 であり、この最大値はクラウド PC プロビジョニングに影響を与える可能性があります。
  • 使用されているサブネットがドメイン コントローラーに到達できる。
  • クラウド PC vNet/サブネットに接続されている VM (仮想マシン) 上のドメイン参加資格情報を使用して、Add-Computer をテストします。
  • 組織内の物理コンピューターと同様に、ドメイン参加エラーのトラブルシューティングを行う。
  • インターネット上で解決できるドメイン名 (contoso.com など) がある場合は、お使いの DNS サーバーが内部として構成されていることを確認する。 パブリック ドメイン名ではなく、Active Directory ドメイン DNS レコードを解決できることも確認してください。

デバイス同期のMicrosoft Entra

プロビジョニング中にモバイル デバイス管理 (MDM) 登録を行う前に、クラウド PC にMicrosoft Entra ID オブジェクトが存在する必要があります。 このチェックは、組織のコンピューター アカウントがタイムリーにMicrosoft Entra IDに同期されていることを確認することを目的としています。

Microsoft Entra コンピューター オブジェクトがMicrosoft Entra IDにすばやく表示されていることを確認します。 30 分以内 (長くても 60 分) が推奨されます。 コンピューター オブジェクトが 90 分以内にMicrosoft Entra IDに到着しない場合、プロビジョニングは失敗します。

プロビジョニングが失敗した場合は、次のことを確認してください。

  • Microsoft Entra IDの同期期間の構成は適切に設定されます。 ID チームと相談し、ディレクトリの同期が十分に高速であることを確認してください。
  • Microsoft Entra IDはアクティブで正常です。
  • Microsoft Entra Connect が正常に実行されており、同期サーバーに問題はありません。
  • クラウド PC に指定されている OU に対して、手動で Add-Computer を実行する。 そのコンピューター オブジェクトがMicrosoft Entra IDに表示されるまでにかかる時間。

Azure サブネットの IP アドレス範囲の使用

ANC セットアップの一環として、クラウド PC が接続するサブネットを指定する必要があります。 クラウド PC ごとに、プロビジョニングによって仮想 NIC が作成され、このサブネットからの IP アドレスが使用されます。

プロビジョニングするクラウド PC の数に対して十分な IP アドレス割り当てが使用可能であることを確認します。 また、プロビジョニング エラーや発生する可能性のあるディザスター リカバリーに十分なアドレス空間を計画します。

このチェックが失敗した場合は、次の点を確認してください。

  • Azure Virtual Networkでサブネットを確認します。 使用可能なアドレス空間が十分にある必要があります。
  • 3 回のプロビジョニング再試行を処理するのに十分なアドレスがあることを確認します。それぞれが数時間使用されるネットワーク アドレスに保持される可能性があります。
  • 未使用の vNIC を削除します。 クラウド PC 用の専用サブネットを使用して、他のサービスが IP アドレスの割り当てを消費していないことを確認することをお勧めします。
  • サブネットを展開して、より多くのアドレスを使用できるようにします。 デバイスが接続されている場合は、この操作を完了できません。

プロビジョニングの試行中に、リソース グループ レベル以上で適用できる CanNotDelete ロックを考慮することが重要です。 これらのロックが存在する場合、プロセスで作成されたネットワーク インターフェイスは自動的に削除されません。 自動的に削除されない場合は、再試行する前に vNIC を手動で削除する必要があります。

プロビジョニングの試行中に、リソース グループ レベル以上の既存のロックを考慮することが重要です。 これらのロックが存在する場合、プロセスで作成されたネットワーク インターフェイスは自動的に削除されません。 これが発生した場合は、再試行する前に vNIC を手動で削除する必要があります。

Azure テナントの準備

チェック時に、指定された Azure サブスクリプションが有効で正常であることをチェックします。 有効で正常でない場合、プロビジョニング中にクラウド PC を vNet に接続し直すことはできません。 課金の問題などの問題により、サブスクリプションが無効になる場合があります。

多くの組織では Azure ポリシーを使用して、リソースが特定のリージョンとサービスにのみプロビジョニングされていることを確認します。 Azure ポリシーでクラウド PC サービスとサポートされているリージョンが考慮されていることを確認する必要があります。

Azure portal にサインインし、Azure サブスクリプションが有効になっていること、使用可能であること、および正常であることを確認してください。

また、Azure portal にアクセスしてポリシーを表示します。 リソースの作成をブロックしているポリシーがないことを確認します。

Azure 仮想ネットワークの変換準備

ANC の作成時に、サポートされていないリージョンにある vNet の使用をブロックします。 サポートされているリージョンの一覧については、要件に関するページを参照してください。

このチェックが失敗した場合は、指定された vNet が、サポートされているリージョンの一覧のリージョンにあることを確認してください。

DNS で Active Directory ドメインを解決できる

Windows 365 でドメイン参加を正常に実行するには、指定された vNet に接続されているクラウド PC が内部 DNS 名を解決できる必要があります。

このテストでは、指定されたドメイン名の解決を試みます。 たとえば、contoso.com や contoso.local です。 このテストが失敗した場合は、次のことを確認してください。

  • Azure vNet 内の DNS サーバーが、ドメイン名を正常に解決できる内部 DNS サーバーに正しく構成されている。
  • 指定された DNS サーバーにクラウド PC が到達できるように、サブネットまたは vNet が適切にルーティングされている。
  • 宣言されたサブネット内のクラウド PC または仮想マシンにより DNS サーバー上で NSLOOKUP を実行でき、内部名で応答する。

指定されたドメイン名での標準の DNS ルックアップに加えて、_ldap._tcp.yourDomain.com レコードの存在も確認します。 このレコードは、提供された DNS サーバーが Active Directory ドメイン コントローラーであることを示しています。 レコードは、AD ドメイン DNS が到達可能であることを確認するための信頼できる方法です。 これらのレコードに、Azure ネットワーク接続で提供されている vNet を介してアクセスできることを確認します。

エンドポイント接続

プロビジョニング中に、Microsoft の一般公開されている複数のサービスにクラウド PC を接続する必要があります。 これらのサービスには、Microsoft Intune、Microsoft Entra ID、Azure Virtual Desktop が含まれます。

クラウド PC で使用されるサブネットから 、必要なすべてのパブリック エンドポイント に到達できることを確認する必要があります。

このテストが失敗した場合は、次のことを確認してください。

  • Azure Virtual Network のトラブルシューティング ツールを使用して、指定された vNet またはサブネットがドキュメントに一覧表示されているサービス エンドポイントに到達できることを確かめる。
  • 指定された DNS サーバーで外部サービスを正しく解決できる。
  • クラウド PC のサブネットとインターネットの間にプロキシがない。
  • 必要なトラフィックをブロックする可能性のあるファイアウォール規則 (物理、仮想、または Windows 内) がない。
  • クラウド PC に対して宣言されている同じサブネット上の VM からエンドポイントをテストすることを検討する。

Azure CloudShell を使用していない場合は、無制限スクリプトを許可するように PowerShell 実行ポリシーが構成されていることを確認してください。 グループ ポリシーを使用して実行ポリシーを設定する場合は、ANC で定義された組織単位 (OU) を対象とするグループ ポリシーオ ブジェクト (GPO) が、Unrestricted スクリプトを許可するように構成されていることを確認してください。 詳細については、Set-ExecutionPolicy を参照してください。

環境と構成の準備が整いました

このチェックは、お客様の責任となるインフラストラクチャに関連する可能性のある多くのインフラストラクチャ関連の問題に使用されます。 内部サービスのタイムアウトなどのエラーや、チェックの実行中にお客様が Azure リソースを削除または変更したことによって発生したエラーが含まれる場合があります。

このエラーが発生した場合は、チェックを再試行することをお勧めします。 それでも解決しない場合は、サポートにお問い合わせください。

ファースト パーティ アプリのアクセス許可

ANC の作成時に、ウィザードによって、リソース グループとサブスクリプションに対する特定のレベルのアクセス許可が付与されます。 これらのアクセス許可により、サービスはクラウド PC をスムーズにプロビジョニングできます。

このようなアクセス許可を保持している Azure 管理者は、これらのアクセス許可を表示および変更できます。

これらのアクセス許可のいずれかが取り消された場合、このチェックは失敗します。 Windows 365 アプリケーション サービス プリンシパルに次のアクセス許可が付与されていることを確認してください。

サブスクリプションのロールの割り当ては、クラウド PC サービス プリンシパルに付与されます。

また、アクセス許可が クラシック サブスクリプション管理者ロール または "ロール (クラシック)" として付与されていないことを確認します。 このロールでは不十分です。 これは、前に示した Azure ロールベースのアクセス制御組み込みロールのいずれかである必要があります。

次の手順

ANC 正常性チェックについて学習する。