手順 1: DirectAccess インフラストラクチャを計画する

2023-10-05
適用対象: ✅ Windows Server 2025, ✅ Windows Server 2022, ✅ Windows Server 2019, ✅ Windows Server 2016, ✅ Windows 11, ✅ Windows 10

基本的なリモートアクセスの展開を計画する際の最初の手順は、展開に必要なインフラストラクチャを計画することです。このトピックでは、インフラストラクチャの計画手順を説明します。

タスク	説明
ネットワークのトポロジと設定を計画する	リモートアクセスサーバーの配置場所 (エッジか、ネットワークアドレス変換 (NAT) デバイスまたはファイアウォールの内側) を決定し、IP アドレス指定およびルーティングを計画します。
ファイアウォールの要件を計画する	エッジファイアウォール経由のリモートアクセスの許可を計画します。
証明書の要件を計画する	リモートアクセスでは、クライアント認証に Kerberos または証明書を使用できます。この基本的なリモートアクセスの展開では、Kerberos が自動的に構成され、リモートアクセスサーバーによって自動的に発行される自己署名証明書を使用して、認証が実行されます。
DNS の要件を計画する	リモートアクセスサーバー、インフラストラクチャサーバー、ローカルでの名前解決オプション、およびクライアント接続に関する DNS 設定を計画します。
Active Directory を計画する	ドメインコントローラーと Active Directory の要件を計画します。
グループポリシーオブジェクトを計画する	組織で必要な GPO とその GPO の作成または編集方法を決定します。

計画タスクは特定の順序で実行する必要はありません。

ネットワークのトポロジと設定を計画する

ネットワークアダプターと IP アドレス指定を計画する

使用するネットワークアダプターのトポロジを決定します。リモートアクセスは次のいずれかを使ってセットアップできます。
- 2 つのネットワークアダプターを使用: エッジで、1 つのネットワークアダプターをインターネットに接続し、もう 1 つを内部ネットワークに接続します。または、NAT、ファイアウォール、ルーターデバイスの背後で、1 つのネットワークアダプターを境界ネットワークに接続し、もう 1 つを内部ネットワークに接続します。
- NAT デバイスの背後で 1 つのネットワークアダプターを使用: リモートアクセスサーバーを NAT デバイスの背後にインストールし、1 つのネットワークアダプターを内部ネットワークに接続します。
IP アドレス指定の要件を特定します。

DirectAccess は、IPv6 と IPsec を組み合わせて、DirectAccess クライアントコンピューターと企業内部ネットワークとの間にセキュリティで保護された接続を確立します。ただし、DirectAccess は、IPv6 インターネットへの接続または内部ネットワーク上でのネイティブ IPv6 サポートを必ずしも必要とはしません。その代わりに、IPv6 移行テクノロジを自動的に構成、使用して、IPv4 インターネット上 (6to4、Teredo、IP-HTTPS) および IPv4 専用イントラネット上 (NAT64 または ISATAP) で IPv6 トラフィックをトンネリングします。このような移行テクノロジの概要については、次のリソースを参照してください。
- IPv6 移行テクノロジ
- IP-HTTPS Tunneling Protocol Specification (IP-HTTPS トンネリングプロトコルの仕様)

次の表に従って、必要なアダプターとアドレス指定を構成します。 NAT デバイスの背後で 1 つのネットワークアダプターを使用する展開の場合は、"内部ネットワークアダプター" 列だけを使って IP アドレスを構成してください。

IP アドレスの種類	外部ネットワークアダプター	内部ネットワークアダプター	ルーティングの要件
IPv4 イントラネットおよび IPv4 インターネット	次を構成します。 - 適切なサブネットマスクを持つ 1 つの静的パブリック IPv4 アドレス。 - インターネットファイアウォールまたはローカルのインターネットサービスプロバイダー (ISP) ルーターのデフォルトゲートウェイの IPv4 アドレス。	次を構成します。 - 適切なサブネットマスクを持つ IPv4 イントラネットアドレス。 - イントラネット名前空間の接続固有の DNS サフィックス。 DNS サーバーは内部インターフェイスにも構成する必要があります。 - イントラネットインターフェイスにはデフォルトゲートウェイを構成しないでください。	内部 IPv4 ネットワーク上のすべてのサブネットに到達できるようにリモートアクセスサーバーを構成するには、次のようにします。 1. イントラネット上のすべての場所の IPv4 アドレス空間を一覧表示します。 2. route add -p または netsh interface ipv4 add route コマンドを使用して、IPv4 アドレス空間を静的ルートとしてリモートアクセスサーバーの IPv4 ルーティングテーブルに追加します。
IPv6 インターネットおよび IPv6 イントラネット	次を構成します。 - ISP によって提供される自動構成されたアドレス構成を使用します。 - route print コマンドを使用して、ISP ルーターを指す既定の IPv6 ルートが IPv6 ルーティングテーブルにあることを確認します。 - ISP およびイントラネットルーターで、RFC 4191 に記述されている既定のルーター基本設定が使用されているかどうか、およびローカルのイントラネットルーターより高度な既定の基本設定が使用されているかどうかを確認します。どちらについても使用している場合は、既定のルートに他の構成は必要ありません。 ISP ルーターの高度な基本設定によって、リモートアクセスサーバーの既定の IPv6 アクティブルートが IPv6 インターネットを示すことが保証されます。リモートアクセスサーバーは IPv6 ルーターであるため、ネィティブ IPv6 インフラストラクチャがある場合は、インターネットインターフェイスからイントラネット上のドメインコントローラーに到達することもできます。この場合、リモートアクセスサーバーのインターネット接続インターフェイスの IPv6 アドレスへの接続を防ぐ境界ネットワークのドメインコントローラーに、パケットフィルターを追加します。	次を構成します。 - 既定の基本設定レベルを使用していない場合は、netsh interface ipv6 set InterfaceIndex ignoredefaultroutes=enabled コマンドを使用してイントラネットインターフェイスを構成します。このコマンドを実行すると、イントラネットルーターを示す既定のルートがそれ以上 IPv6 ルーティングテーブルに追加されないことが保証されます。イントラネットインターフェイスの InterfaceIndex は、netsh interface show interface コマンドの表示で確認できます。	IPv6 イントラネットがある場合、IPv6 のすべての場所に到達できるようにリモートアクセスサーバーを構成するには、次のようにします。 1. イントラネット上のすべての場所の IPv6 アドレス空間を一覧表示します。 2. netsh interface ipv6 add route コマンドを使用して、リモートアクセスサーバーの IPv6 ルーティングテーブルに IPv6 アドレス空間を静的ルートとして追加します。
IPv6 インターネットおよび IPv4 イントラネット	リモートアクセスサーバーは、IPv4 インターネット上の 6to4 リレーへの Microsoft 6to4 Adapter インターフェイスを使って、既定の IPv6 ルートトラフィックを転送します。 IPv4 インターネット上に Microsoft 6to4 リレーの IPv4 アドレス用リモートアクセスサーバーを構成するには (企業ネットワークにネイティブ IPv6 が展開されていないときに使用)、netsh interface ipv6 6to4 set relay name=192.88.99.1 state=enabled コマンドを使用できます。

注意

パブリック IPv4 アドレスが割り当てられている DirectAccess クライアントは、6to4 移行テクノロジを使ってイントラネットに接続します。 6to4 を使って DirectAccess サーバーに接続できない DirectAccess クライアントは、IP-HTTPS を使用します。
ネイティブ IPv6 クライアントコンピューターは、ネイティブ IPv6 経由でリモートアクセスサーバーに接続できます。移行テクノロジを必要としません。

ファイアウォールの要件を計画する

エッジファイアウォールの背後に設置されたリモートアクセスサーバーが IPv4 インターネット上にあるときは、リモートアクセストラフィックについて次の例外が必要になります。

6to4 トラフィックの IP プロトコル 41 の受信および送信します。
IP-HTTPS の伝送制御プロトコル (TCP) 宛先ポート 443 と TCP 発信元ポート 443 が送信されます。
1 つのネットワークアダプターを使ってリモートアクセスを展開し、ネットワークロケーションサーバーをリモートアクセスサーバーにインストールする場合は、TCP ポート 62000 も除外する必要があります。

リモートアクセスサーバーが IPv6 インターネット上にあるときは、リモートアクセストラフィックについて次の例外が必要になります。

IP プロトコル 50
UDP 宛先ポート 500 の受信と、UDP 発信元ポート 500 の送信。

追加のファイアウォールを使用する場合は、次の内部ネットワークファイアウォール例外をリモートアクセストラフィックに適用します。

ISATAP-プロトコル 41 の受信と送信
すべての IPv4/IPv6 トラフィックに対する TCP/UDP

証明書の要件を計画する

IPsec の証明書の要件には、DirectAccess クライアントコンピューターとリモートアクセスサーバーとの間で IPsec 接続を確立するときにクライアントによって使用されるコンピューター証明書と、DirectAccess クライアントとの IPsec 接続を確立するためにリモートアクセスサーバーによって使用されるコンピューター証明書が含まれます。 Windows Server 2012 の DirectAccess では、これらの IPsec 証明書の使用は必須ではありません。 DirectAccess の有効化ウィザードでは、証明書を要求せずに IPsec 認証を実行する Kerberos プロキシとして機能するようにリモートアクセスサーバーを構成します。

IP-HTTPS server: リモートアクセスを構成すると、リモートアクセスサーバーは IP-HTTPS Web リスナーとして動作するように自動的に構成されます。 IP-HTTPS サイトは Web サイト証明書を要求します。また、クライアントコンピューターは、その証明書の証明書失効リスト (CRL) サイトに接続できる必要があります。 DirectAccess の有効化ウィザードでは、SSTP VPN 証明書の使用を試みます。 SSTP が構成されていない場合は、IP-HTTPS の証明書がコンピューターの個人用ストアにあるかどうを確認します。どれも使用できない場合は、自己署名証明書を自動的に作成します。
ネットワークロケーションサーバー: ネットワークロケーションサーバーは、クライアントコンピューターが企業ネットワーク内に配置されているかどうかを検出するために使用される Web サイトです。ネットワークロケーションサーバーには、web サイトの証明書が必要です。 DirectAccess クライアントは、その証明書の CRL サイトに接続できる必要があります。 DirectAccess の有効化ウィザードでは、ネットワークロケーションサーバーの証明書がコンピューターの個人用ストアにあるかどうかが確認されます。ない場合は、自己署名証明書が自動的に作成されます。

これらの各要素の認定要件を次の表にまとめます。

IPsec 認証	IP-HTTPS サーバー	ネットワークロケーションサーバー
認証に Kerberos プロキシを使用しない場合は、IPsec 認証用にリモートアクセスサーバーとクライアントに対してコンピューター証明書を発行するために内部 CA が必要になります。	パブリック CA: CRL 配布ポイントを外部から使用できるようにするため、パブリック CA を使用して IP-HTTPS 証明書を発行することをお勧めします。	内部 CA: 内部 CA を使用して、ネットワークロケーションサーバーの Web サイト証明書を発行できます。 CRL 配布ポイントが内部ネットワークからいつでも利用できることを確認してください。
	内部 CA: 内部 CA を使用して IP-HTTPS 証明書を発行できます。ただし、CRL 配布ポイントを外部から使用できるようにする必要があります。	自己署名証明書: ネットワークロケーションサーバー Web サイトに自己署名証明書を使用できます。ただし、マルチサイト展開では自己署名証明書を使用できません。
	自己署名証明書: IP-HTTPS サーバーに自己署名証明書を使用できます。ただし、CRL 配布ポイントを外部から使用できるようにする必要があります。自己署名証明書はマルチサイト展開で使用できません。

IP-HTTPS の証明書を計画する

リモートアクセスサーバーは IP-HTTPS リスナーとして動作します。HTTPS Web サイト証明書をサーバーに手動でインストールする必要があります。計画時には次のことに注意します。

CRL がすぐに使用できるように、パブリック CA を使用することをお勧めします。
サブジェクトフィールドに、リモートアクセスサーバーのインターネットアダプターの IPv4 アドレスまたは IP-HTTPS URL (ConnectTo アドレス) の FQDN のいずれかを指定します。リモートアクセスサーバーが NAT デバイスの内側に存在する場合は、NAT デバイスのパブリック名またはアドレスを指定する必要があります。
証明書の共通名は、IP-HTTPS サイトの名前と一致している必要があります。
拡張キー使用法フィールドに、サーバー認証オブジェクト識別子 (OID) を使用します。
[CRL 配布ポイント] フィールドに、インターネットに接続している DirectAccess クライアントがアクセスできる CRL 配布ポイントを指定します。
IP-HTTPS 証明書には秘密キーが必要です。
IP-HTTPS 証明書は、個人用ストアに直接インポートする必要があります。
IP-HTTPS 証明書の名前にはワイルドカードを含めることができます。

ネットワークロケーションサーバーの Web サイト証明書を計画する

ネットワークロケーションサーバー Web サイトを計画するには、次の点に注意してください。

サブジェクトフィールドに、ネットワークロケーションサーバーのイントラネットインターフェイスの IP アドレスまたはネットワークロケーション URL の FQDN のいずれかを指定します。
拡張キー使用法フィールドに、サーバー認証 OID を使用します。
CRL 配布ポイントフィールドに、イントラネットに接続している DirectAccess クライアントがアクセスできる CRL 配布ポイントを指定します。この CRL 配布ポイントは、内部ネットワークの外側からアクセスできないようにしてください。
後でマルチサイトまたはクラスタ展開の構成を予定している場合は、証明書の名前がリモートアクセスサーバーの内部名と一致していてはなりません。

注意

IP-HTTPS とネットワークロケーションサーバーの証明書にサブジェクト名があることを確認してください。証明書にサブジェクト名がなく、代替名がある場合は、リモートアクセスウィザードで受け付けられません。

DNS の要件を計画する

リモートアクセスの展開では、次に対して DNS が必要です。

DirectAccess クライアント要求: 内部ネットワークに配置されていない DirectAccess クライアントコンピューターからの要求を解決するためには、DNS が使用されます。 DirectAccess クライアントは、インターネット上に配置されているか、または企業ネットワーク上に配置されているかを判断するために、DirectAccess ネットワークロケーションサーバーへの接続を試行します。接続に成功した場合、クライアントはイントラネット上にあると判断され、DirectAccess は使用されません。クライアント要求は、クライアントコンピューターのネットワークアダプター上で構成された DNS サーバーを使って解決されます。接続に失敗した場合、クライアントはインターネット上にあると見なされます。 DirectAccess クライアントは名前解決ポリシーテーブル (NRPT) を使って、名前の要求を解決するときに使用する DNS サーバーを判断します。クライアントが名前解決に DirectAccess DNS64 または代替の内部 DNS サーバーを使用するように指定することができます。名前解決の実行時、NRPT が DirectAccess クライアントによって使用されて、要求の処理方法が特定されます。クライアントは、FQDN、または https://internal などの単一ラベル名を要求します。単一ラベル名が要求の場合は、DNS サフィックスが追加されて FQDN になります。 DNS クエリが NRPT 内のエントリに一致し、そのエントリに対して DNS4 またはイントラネット DNS サーバーが指定されている場合、そのクエリは指定されたサーバーを使って名前解決のために送信されます。一致するエントリはあっても DNS サーバーが指定されていない場合は、除外規則を意味しているので、通常の名前解決が適用されます。

リモートアクセス管理コンソールで NRPT に新しいサフィックスを追加するとき、そのサフィックスの既定の DNS サーバーを自動的に検出するには、[検出] をクリックします。自動検出のしくみは次のとおりです。
1. 企業ネットワークが IPv4 ベースまたは IPv4 と IPv6 の組み合わせである場合、既定のアドレスはリモートアクセスサーバー上の内部アダプター DNS64 アドレスです。
2. 企業ネットワークが IPv6 ベースである場合、既定のアドレスは、企業ネットワーク内の DNS サーバーの IPv6 アドレスです。
インフラストラクチャサーバー
1. ネットワークロケーションサーバー: DirectAccess クライアントは、内部ネットワークに配置されているかどうかを判断するために、ネットワークロケーションサーバーへの接続を試みます。内部ネットワーク上のクライアントは、ネットワークロケーションサーバーの名前を解決できる必要がありますが、インターネットに配置されているときは名前を解決できないようにする必要があります。このような処理が行われるように、既定では、ネットワークロケーションサーバーの FQDN が除外規則として NRPT に追加されます。また、リモートアクセスを構成する場合、次の規則が自動的に作成されます。
  1. ルートドメインまたはリモートアクセスサーバーのドメイン名の DNS サフィックス規則、およびリモートアクセスサーバー上に構成されたイントラネット DNS サーバーに対応する IPv6 アドレス。たとえば、リモートアクセスサーバーが corp.contoso.com ドメインのメンバーである場合、corp.contoso.com DNS サフィックスについて規則が作成されます。
  2. ネットワークロケーションサーバーの FQDN の除外規則。たとえば、ネットワークロケーションサーバーの URL が https://nls.corp.contoso.com の場合、FQDN nls.corp.contoso.com に対して除外規則が作成されます。
  IP-HTTPS サーバー: リモートアクセスサーバーは IP-HTTPS リスナーとして動作し、そのサーバー証明書を使用して IP-HTTPS クライアントに対する認証を行います。 IP-HTTPS 名は、パブリック DNS サーバーを使って DirectAccess クライアントによって解決できる必要があります。
  
  接続検証方法: リモートアクセスは、DirectAccess クライアントコンピューターが内部ネットワークへの接続を確認するために使用する既定の Web プローブを作成します。プローブが想定どおりに動作するように、次の名前を DNS 内に手動で登録する必要があります。
  1. directaccess-webprobehost は、リモートアクセスサーバーの内部 IPv4 アドレスに、または IPv6 のみの環境では IPv6 アドレスに解決されます。
  2. directaccess-corpconnectivityhost は localhost (ループバック) アドレスに解決されます。 A レコードと AAAA レコードが作成されます。A レコードは 127.0.0.1 の値を持ち、AAAA レコードは NAT64 プレフィックスと最後の 32 ビットが 127.0.0.1 で構成される値を持ちます。 NAT64 プレフィックスは、コマンドレット get-netnattransitionconfiguration を実行して取得できます。
    
    注意
    
    これは IPv4 専用環境でのみ有効です。 IPv4+IPv6、または IPv6 専用環境では、AAAA レコードのみをループバック IP アドレス ::1 で作成する必要があります。
  HTTP または PING 経由で他の Web アドレスを使用して、追加の接続検証方法を作成できます。接続検証方法ごとに、DNS エントリが存在している必要があります。

DNS サーバーの要件

DirectAccess クライアントの場合は、Windows Server 2003、Windows Server 2008、Windows Server 2008 R2、Windows Server 2012 を実行する DNS サーバー、または IPv6 がサポートされている任意の DNS サーバーを使用する必要があります。

Active Directory を計画する

リモートアクセスでは、次のように Active Directory と Active Directory グループポリシーオブジェクトが使用されます。

認証: Active Directory を認証に使用します。イントラネットトンネルでは、内部リソースにアクセスするユーザーに対して Kerberos 認証を使用します。
グループポリシーオブジェクト: リモートアクセスは、リモートアクセスサーバー、クライアント、および内部アプリケーションサーバーに適用されるグループポリシーオブジェクトに構成設定を収集します。
セキュリティグループ: リモートアクセスは、セキュリティグループを使用して、DirectAccess クライアントコンピューターとリモートアクセスサーバーを集合化および識別します。グループポリシーは必要なセキュリティグループに適用されます。
拡張 IPsec ポリシー: リモートアクセスは、クライアントとリモートアクセスサーバー間で IPsec 認証と暗号化を使用できます。 IPsec 認証と暗号化を、指定した内部アプリケーションサーバーまで拡張できます。

Active Directory の要件

リモートアクセスの展開用に Active Directory を計画するときは、次のことが必要です。

Windows Server 2012、Windows Server 2008 R2、Windows Server 2008、Windows Server 2003 のいずれかのオペレーティングシステムに、少なくとも 1 つのドメインコントローラーがインストールされていること。

ドメインコントローラーが境界ネットワーク上にある場合は (したがってリモートアクセスサーバーのインターネット接続ネットワークアダプターからアクセスできる)、インターネットアダプターの IP アドレスへの接続を禁止するため、ドメインコントローラー上でパケットフィルターを追加してリモートアクセスサーバーがアクセスできないようにします。
リモートアクセスサーバーはドメインメンバーである必要があります。
DirectAccess クライアントは、ドメインメンバーである必要があります。クライアントは次に所属することができます。
- リモートアクセスサーバーと同じフォレスト内の任意のドメイン。
- リモートアクセスサーバードメインと双方向の信頼関係がある任意のドメイン。
- リモートアクセスドメインが所属するフォレストと双方向の信頼関係があるフォレスト内の任意のドメイン。

注意

リモートアクセスサーバーはドメインコントローラーにできません。
リモートアクセス用に使用される Active Directory ドメインコントローラーは、リモートアクセスサーバーの外部インターネットアダプター (アダプターは Windows ファイアウォールのドメインプロファイルにあってはいけません) からアクセスできてはいけません。

グループポリシーオブジェクトを計画する

リモートアクセスの構成時に構成された DirectAccess 設定はグループポリシーオブジェクト (GPO) に収集されます。次に示すとおり、DirectAccess の設定は 3 つの異なる GPO に読み込まれて配布されます。

DirectAccess クライアント GPO: この GPO には、クライアントの設定が含まれます (IPv6 移行テクノロジの設定、NRPT エントリ、セキュリティが強化された Windows ファイアウォールの接続セキュリティの規則など)。この GPO は、クライアントコンピューターに対して指定されたセキュリティグループに適用されます。
DirectAccess サーバー GPO: この GPO には、展開でリモートアクセスサーバーとして構成されたサーバーに適用される DirectAccess 構成設定が格納されます。また、セキュリティが強化された Windows ファイアウォールの接続セキュリティの規則も含まれます。
アプリケーションサーバー GPO: この GPO には、オプションで DirectAccess クライアントからの認証と暗号化を拡張する、選択したアプリケーションサーバーの設定が格納されます。認証と暗号化を拡張しない場合、この GPO は使用されません。

GPO は DirectAccess の有効化ウィザードによって自動的に作成され、各 GPO に既定名が指定されます。

注意事項

DirectAccess コマンドレットを実行する前に、すべてのリモートアクセスグループポリシーオブジェクトをバックアップするには、リモートアクセス構成のバックアップと復元に関する記事の手順に従います。

GPO は 2 つの方法で構成できます。

自動: 自動的に作成されることを指定できます。各 GPO には既定の名前が指定されます。
手動: Active Directory 管理者によって事前に定義されている GPO を使用できます。

特定の GPO を使用するように DirectAccess をいったん構成してしまうと、別の GPO の使用を構成できなくなることに注意してください。

自動的に作成された GPO

自動的に作成された GPO を使用するときは、次の点に注意してください。

自動的に作成された GPO は、次に示すように、場所とリンク先のパラメーターに基づいて適用されます。

DirectAccess サーバー GPO の場合、場所とリンクのパラメーターはどちらも、リモートアクセスサーバーを含むドメインを示します。
クライアント GPO が作成されると、場所は GPO の作成先となる単一ドメインに設定されます。 GPO 名は各ドメインで検索され、存在する場合は DirectAccess の設定が読み込まれます。リンク先は GPO が作成されたドメインのルートに設定されます。 GPO はクライアントコンピューターまたはアプリケーションサーバーを含むドメインごとに作成され、その個々のドメインのルートにリンクされます。

自動で作成された GPO を使用しているときに DirectAccess の設定を適用する場合、リモートアクセスサーバー管理者は次のアクセス許可が必要になります。

各ドメインの GPO 作成アクセス許可。
選択したすべてのクライアントドメインルートのリンクアクセス許可。
サーバー GPO ドメインルートのリンクアクセス許可。
セキュリティの作成、編集、削除、および変更のアクセス許可が GPO には必要です。
リモートアクセス管理者が、必要なドメインごとに GPO 読み取りアクセス許可を持つことが推奨されます。これによって、GPO の作成時に、重複する名前の GPO が存在しないことをリモートアクセスが確認できるようになります。

GPO をリンクするための正しいアクセス許可がない場合は、警告が表示されることに注意してください。リモートアクセスの操作は続行されますが、リンク処理は行われません。この警告が表示された場合は、後でアクセス許可が設定されても、リンクは自動的には作成されません。代わりに、管理者がリンクを手動で作成する必要があります。

手動で作成された GPO

手動で作成された GPO を使用するときは、次の点に注意してください。

GPO はリモートアクセスセットアップウィザードを実行する前に存在している必要があります。
手動で作成された GPO を使用しているとき DirectAccess の設定を適用する場合、リモートアクセス管理者はそれらの GPO に対する完全な GPO アクセス許可 (セキュリティの編集、削除、および変更) が必要になります。
手動で作成された GPO を使用しているときは、GPO へのリンクがドメイン全体で検索されます。 GPO がドメイン内でリンクされていない場合は、ドメインルート内にリンクが自動的に作成されます。リンクを作成するために必要なアクセス許可がない場合は、警告が表示されます。

GPO をリンクするための正しいアクセス許可がない場合は、警告が表示されることに注意してください。リモートアクセスの操作は続行されますが、リンク処理は行われません。この警告が表示された場合は、後でアクセス許可を追加しても、リンクは自動的には作成されません。代わりに、管理者がリンクを手動で作成する必要があります。

削除された GPO からの回復

リモートアクセスサーバー、クライアント、またはアプリケーションサーバーの GPO が誤って削除され、バックアップも使用できない場合は、構成設定を削除し、再構成する必要があります。バックアップを使用できる場合は、バックアップから GPO を復元できます。

リモートアクセス管理に、次のエラーメッセージが表示されます: GPO (GPO 名) が見つかりません。構成設定を削除するには、次の手順に従います。

PowerShell コマンドレット Uninstall-remoteaccess を実行します。
リモートアクセス管理を再度開きます。
GPO が見つからないというエラーメッセージが表示されます。 [構成設定の削除] をクリックします。完了すると、サーバーが未構成の状態に復元されます。