手順 3: マルチサイト展開を計画する

  • [アーティクル]

適用対象: Windows Server 2022、Windows Server 2019、Windows Server 2016

マルチサイト インフラストラクチャを計画した後、追加の証明書の要件、クライアント コンピューターでエントリ ポイントを選択する方法、展開で割り当てられる IPv6 アドレスを計画します。

以下のセクションで、詳細な計画の情報を提供します。

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

エントリ ポイントを構成するときに、特定の ConnectTo アドレスを使用して各エントリ ポイントを構成します。 各エントリ ポイントの IP-HTTPS 証明書は、ConnectTo アドレスと一致している必要があります。 証明書を取得するときは、次の点に注意してください。

  • マルチサイト展開で自己署名証明書を使用することはできません。

  • CRL がすぐに使用できるように、パブリック CA を使用することをお勧めします。

  • サブジェクト フィールドに、リモート アクセス サーバーの外部アダプターの IPv4 アドレス (ConnectTo アドレスが DNS 名ではなく IP アドレスとして指定されている場合)、または IP-HTTPS URL の FQDN を指定します。

  • 証明書の共通名は、IP-HTTPS Web サイトの名前と一致している必要があります。 ConnectTo DNS 名と一致するワイルドカード URL の使用もサポートされています。

  • IP-HTTPS 証明書では、サブジェクト名にワイルドカードを使用できます。 すべてのエントリ ポイントに同じワイルドカード証明書を使用できます。

  • [拡張キー使用法] フィールドに、サーバー認証オブジェクト識別子 (OID) を使用します。

  • マルチサイト展開で Windows 7 を実行するクライアント コンピュータをサポートする場合は、[CRL 配布ポイント] フィールドに、インターネットに接続されている DirectAccess クライアントがアクセスできる CRL 配布ポイントを指定します。 これは、Windows 8 を実行するクライアントには必要ありません (これらのクライアントの IP-HTTPS では、CRL 失効の確認が既定で無効になっています)。

  • IP-HTTPS 証明書には秘密キーが必要です。

  • IP-HTTPS 証明書は、ユーザーではなく、コンピューターの個人用ストアに直接インポートする必要があります。

3.2 ネットワーク ロケーション サーバーを計画する

ネットワーク ロケーション サーバー Web サイトは、リモート アクセス サーバーまたは組織内の別のサーバーでホストできます。 ネットワーク ロケーション サーバーをリモート アクセス サーバーでホストする場合、リモート アクセスを展開すると、Web サイトが自動的に作成されます。 ネットワーク ロケーション サーバーを Windows オペレーティング システムを実行する組織内の別のサーバーでホストする場合、Web サイトを作成するために、インターネット インフォメーション サービス (IIS) がインストールされていることを確認する必要があります。

3.2.1 ネットワーク ロケーション サーバーの証明書の要件

ネットワーク ロケーション サーバー Web サイトが、証明書の展開に関する次の要件を満たしていることを確認します。

  • HTTPS サーバー証明書が必要。

  • ネットワーク ロケーション サーバーがリモート アクセス サーバー上にあり、単一のリモート アクセス サーバーを展開したときに自己署名証明書の使用を選択した場合、内部 CA が発行した証明書を使用するように単一サーバーの展開を再構成する必要があります。

  • DirectAccess クライアント コンピューターがネットワーク ロケーション サーバー Web サイトへのサーバー証明書を発行した CA を信頼している。

  • 内部ネットワーク上の DirectAccess クライアント コンピューターが、ネットワーク ロケーション サーバー Web サイトの名前を解決できる。

  • ネットワーク ロケーション サーバー Web サイトが、内部ネットワーク上のコンピューターに対して高可用性を提供している。

  • ネットワーク ロケーション サーバーは、インターネット上の DirectAccess クライアント コンピューターにアクセス不能である。

  • サーバー証明書が、証明書失効リスト (CRL) と照合されチェックされる。

  • ネットワーク ロケーション サーバーがリモート アクセス サーバーでホストされる場合、ワイルドカード証明書はサポートされない。

ネットワーク ロケーション サーバーに使用する Web サイト証明書を取得する場合、次の点に注意してください。

  1. サブジェクト フィールドに、ネットワーク ロケーション サーバーのイントラネット インターフェイスの IP アドレスまたはネットワーク ロケーション URL の FQDN のいずれかを指定します。 ネットワーク ロケーション サーバーがリモート アクセス サーバーでホストされる場合、IP アドレスは指定しないでください。 これは、ネットワーク ロケーション サーバーがすべてのエントリ ポイントで同じサブジェクト名を使用する必要があり、一方ですべてのエントリ ポイントが同じ IP アドレスを持つわけではないためです。

  2. 拡張キー使用法フィールドに、サーバー認証 OID を使用します。

  3. [CRL 配布ポイント] フィールドには、イントラネットに接続されている DirectAccess クライアントがアクセスできる CRL 配布ポイントを使用します。

3.2.2 ネットワーク ロケーション サーバーの DNS

ネットワーク ロケーション サーバーをリモート アクセス サーバーでホストする場合、展開内のすべてのエントリ ポイントについて、ネットワーク ロケーション サーバー Web サイトの DNS エントリを追加する必要があります。 次のことを考慮してください。

  • マルチサイト展開の最初のネットワーク ロケーション サーバー証明書のサブジェクト名は、すべてのエントリ ポイントのネットワーク ロケーション サーバー URL として使用されるため、サブジェクト名とネットワーク ロケーション サーバー URL を、展開内の最初のリモート アクセス サーバーのコンピューター名と同じにすることはできません。 これは、ネットワーク ロケーション サーバー専用の FQDN である必要があります。

  • ネットワーク ロケーション サーバーのトラフィックによって提供されるサービスは、DNS を使用してエントリ ポイント間で分散されます。したがって、エントリ ポイントの内部 IP アドレスが構成された、URL が同じ DNS エントリがエントリ ポイントごとに存在する必要があります。

  • すべてのエントリ ポイントに、(ネットワーク ロケーション サーバー URL と一致する) 同じサブジェクト名を持つネットワーク ロケーション サーバー証明書を構成する必要があります。

  • エントリ ポイントを追加する前に、エントリ ポイントのネットワーク ロケーション サーバー インフラストラクチャ (DNS および証明書の設定) を作成する必要があります。

3.3 すべてのリモート アクセス サーバーの IPsec ルート証明書を計画する

マルチサイト展開で IPsec クライアント認証を計画する場合、次の点に注意してください。

  1. 単一のリモート アクセス サーバーをセットアップするとき、コンピューター認証に組み込み Kerberos プロキシを使用することを選択した場合、内部 CA が発行したコンピューター証明書を使用するように設定を変更する必要があります。これは、マルチサイト展開では Kerberos プロキシがサポートされないためです。

  2. 自己署名証明書を使用した場合、内部 CA が発行した証明書を使用するように単一サーバー展開を再構成する必要があります。

  3. クライアント認証時に IPsec 認証を成功させるために、すべてのリモート アクセス サーバーが、拡張キー使用法のクライアント認証 OID と共に、IPsec ルートまたは中間 CA が発行した証明書を所持している必要があります。

  4. マルチサイト展開のすべてのリモート アクセス サーバーに、同じ IPsec ルートまたは中間証明書をインストールする必要があります。

3.4 グローバル サーバー負荷分散を計画する

マルチサイト展開では、グローバル サーバーロード バランサーを追加で構成できます。 グローバル サーバー ロード バランサーは、エントリ ポイント間でトラフィックの負荷を分散させることができるため、展開で大規模な地理的分布に対応する場合に、組織で役立つ場合があります。 DirectAccess クライアントに、最も近いエントリ ポイントのエントリ ポイント情報を提供するように、グローバル サーバー ロード バランサーを構成できます。 このプロセスは次のようになります。

  1. Windows 10 または Windows 8 を実行するクライアント コンピューターには、エントリ ポイントにそれぞれ関連付けられているグローバル サーバー ロード バランサーの IP アドレスの一覧があります。

  2. Windows 10 または Windows 8 クライアント コンピューターは、パブリック DNS 内のグローバル サーバー ロード バランサーの FQDN を IP アドレスに解決しようとします。 解決された IP アドレスがエントリ ポイントのグローバル サーバー ロード バランサーの IP アドレスとしてリストされている場合、クライアント コンピューターは自動的にそのエントリ ポイントを選択し、その IP-HTTPS URL (ConnectTo アドレス)、またはその Teredo サーバーの IP アドレスに接続します。 クライアント コンピューターは、グローバル サーバー ロード バランサーの IP アドレスには接続しようとしないため、グローバル サーバー ロード バランサーの IP アドレスは、エントリ ポイントの ConnectTo アドレスまたは Teredo サーバー アドレスと同じである必要はありません。

  3. クライアント コンピューターが Web プロキシの背後にあり、DNS 解決を使用できない場合、またはグローバル サーバー ロード バランサーの FQDN が、構成されているグローバル サーバー ロード バランサーの IP アドレスに解決されない場合、すべてのエントリ ポイントの IP-HTTPS URL への HTTPS プローブを使用して、エントリ ポイントが自動的に選択されます。 クライアントは、最初に応答するサーバーに接続します。

リモート アクセスをサポートするグローバル サーバー負荷分散デバイスの一覧については、「Microsoft のサーバーおよびクラウド プラットフォーム」の「パートナーを見つける」ページを参照してください。

3.5 DirectAccess クライアントのエントリ ポイント選択を計画する

マルチサイト展開を構成する場合、Windows 10 および Windows 8 クライアント コンピューターには、展開内のすべてのエントリ ポイントに接続するため、および選択アルゴリズムに基づいて 1 つのエントリ ポイントに自動的に接続するために必要な情報が既定で構成されます。 また、Windows 10 および Windows 8 クライアント コンピューターが接続先のエントリ ポイントを手動で選択できるように、展開を構成することもできます。 Windows 10 または Windows 8 クライアント コンピューターが米国のエントリ ポイントに現在接続されていて、自動エントリ ポイント選択が有効になっている場合、米国のエントリ ポイントに到達できなくなると、数分後にクライアント コンピューターは、ヨーロッパのエントリ ポイントを介して接続しようとします。 自動エントリ ポイント選択を使用することをお勧めします。ただし、手動エントリ ポイント選択を許可すると、エンド ユーザーは、現在のネットワークの状態に基づいて別のエントリ ポイントに接続できます。 たとえば、コンピューターが米国のエントリ ポイントに接続されていて、内部ネットワークへの接続が予想よりも著しく遅くなる場合などです。 このような状況では、エンド ユーザーはヨーロッパのエントリ ポイントへの接続を手動で選択して、内部ネットワークへの接続を向上させることができます。

注意

エンド ユーザーがエントリ ポイントを手動で選択した後、クライアント コンピューターは自動エントリ ポイント選択には戻りません。 つまり、手動で選択したエントリ ポイントに到達できなくなった場合、エンド ユーザーは、自動エントリ ポイント選択に戻すか、別のエントリ ポイントを手動で選択する必要があります。

Windows 7 クライアント コンピューターには、マルチサイト展開の 1 つのエントリ ポイントに接続するために必要な情報が構成されます。 これらは、複数のエントリ ポイントの情報を同時に保存できません。 たとえば、Windows 7 クライアント コンピューターは、米国のエントリ ポイントに接続するように構成できますが、その場合、ヨーロッパのエントリ ポイントに接続するように構成できません。 米国のエントリ ポイントに到達できない場合、Windows 7 クライアント コンピューターは、そのエントリ ポイントが到達可能になるまで、内部ネットワークへの接続を失うことになります。 エンド ユーザーは、ヨーロッパのエントリ ポイントに接続試行するための変更を行うことができません。

3.6 プレフィックスとルーティングを計画する

内部 IPv6 プレフィックス

単一のリモート アクセス サーバーの展開中に、内部ネットワークの IPv6 プレフィックスを計画した場合、マルチサイト展開では次のことに注意してください。

  1. 単一サーバーのリモート アクセス展開を構成したときにすべての Active Directory サイトを含めた場合、リモート アクセス管理コンソールで、内部ネットワークの IPv6 プレフィックスを既に定義しています。

  2. マルチサイト展開用に追加の Active Directory サイトを作成する場合、追加のサイト用の新しい IPv6 プレフィックスを計画し、リモート アクセスでそれらのプレフィックスを定義する必要があります。 IPv6 プレフィックスは、IPv6 が企業の内部ネットワークに展開されている場合に、リモート アクセス管理コンソールまたは PowerShell コマンドレットを使用してのみ構成できます。

DirectAccess クライアント コンピューターの IPv6 プレフィックス (IP-HTTPS プレフィックス)

  1. IPv6 が企業の内部ネットワークに展開されている場合、展開の追加エントリ ポイントで DirectAccess クライアント コンピューターに割り当てる IPv6 プレフィックスを計画する必要があります。

  2. 各エントリ ポイントで DirectAccess クライアント コンピューターに割り当てる IPv6 プレフィックスが一意であること、および IPv6 プレフィックスに重複がないことを確認します。

  3. IPv6 が企業ネットワークに展開されていない場合、エントリ ポイントを追加すると、各エントリ ポイントの IP-HTTPS プレフィックスが自動的に選択されます。

VPN クライアントの IPv6 プレフィックス

単一のリモート アクセス サーバーで VPN を展開した場合、次の点に注意してください。

  1. 企業ネットワークへの VPN クライアントの IPv6 接続を許可する場合のみ、IPv6 VPN プレフィックスをエントリ ポイントに追加する必要があります。

  2. VPN プレフィックスは、IPv6 が企業の内部ネットワークに展開されている場合、および VPN がエントリ ポイントで有効になっている場合に、リモート アクセス管理コンソールまたは PowerShell コマンドレットを使用してのみ、エントリ ポイントに対して構成できます。

  3. VPN プレフィックスは、各エントリ ポイントで一意である必要があります。また、他の VPN または IP-HTTPS プレフィックスと重複させることはできません。

  4. IPv6 が企業ネットワークに展開されていない場合、エントリ ポイントに接続する VPN クライアントには IPv6 アドレスは割り当てられません。

ルーティング

マルチサイト展開では、Teredo と IP-HTTPS を使用して対称ルーティングが実施されます。 IPv6 が企業ネットワークに展開されている場合、次の点に注意してください。

  1. 各エントリ ポイントの Teredo および IP-HTTPS プレフィックスは、企業ネットワークをまたがり、関連付けられているリモート アクセス サーバーにルーティングできる必要があります。

  2. ルートは、企業ネットワークのルーティング インフラストラクチャで構成する必要があります。

  3. エントリ ポイントごとに、内部ネットワークに 1 から 3 つのルートが必要です。

    1. IP-HTTPS プレフィックス - このプレフィックスは、[エントリ ポイントの追加] ウィザードで管理者が選択します。

    2. VPN IPv6 プレフィックス (省略可能)。 このプレフィックスは、エントリ ポイントに対して VPN を有効にした後で選択できます。

    3. Teredo プレフィックス (省略可能)。 このプレフィックスは、外部アダプターで 2 つの連続するパブリック IPv4 アドレスがリモート アクセス サーバーに構成されている場合にのみ関連します。 このプレフィックスは、アドレス ペアの最初のパブリック IPv4 アドレスに基づきます。 たとえば、外部アドレスが以下の場合:

      1. www.xxx.yyy.zzz

      2. www.xxx.yyy.zzz+1

      構成する Teredo プレフィックスは 2001:0:WWXX:YYZZ::/64 です。ここで WWXX:YYZZ は、IPv4 アドレス www.xxx.yyy.zzz の 16 進数表現です。

      次のスクリプトを使用して Teredo プレフィックスを計算できます。

      $TeredoIPv4 = (Get-NetTeredoConfiguration).ServerName # Use for a Remote Access server that is already configured
$TeredoIPv4 = "20.0.0.1" # Use for an IPv4 address

    [Byte[]] $TeredoServerAddressBytes = `
    [System.Net.IPAddress]::Parse("2001::").GetAddressBytes()[0..3] + `
    [System.Net.IPAddress]::Parse($TeredoIPv4).GetAddressBytes() + `
    [System.Net.IPAddress]::Parse("::").GetAddressBytes()[0..7]

Write-Host "The server's Teredo prefix is $([System.Net.IPAddress]$TeredoServerAddressBytes)/64"

    4. 上記のすべてのルートは、リモート アクセス サーバーの内部アダプターの IPv6 アドレス (または負荷分散されたエントリ ポイントの内部仮想 IP (VIP) アドレス) にルーティングする必要があります。

注意

IPv6 が企業ネットワークに展開され、リモート アクセス サーバーの管理が DirectAccess 経由でリモートで実行される場合、トラフィックが内部ネットワークに転送されるようにするために、他のすべてのエントリ ポイントの Teredo および IP-HTTPS プレフィックスのルートを、各リモート アクセス サーバーに追加する必要があります。

Active Directory サイト固有の IPv6 プレフィックス

Windows 10 または Windows 8 を実行するクライアント コンピューターがエントリ ポイントに接続されると、クライアント コンピューターは、エントリ ポイントの Active Directory サイトにただちに関連付けられ、そのエントリ ポイントに関連付けられた IPv6 プレフィックスが構成されます。 クライアント コンピューターがこれらの IPv6 プレフィックスを使用してリソースに接続するために、優先順位があります。エントリ ポイントに接続するとき、クライアント コンピューターには、IPv6 プレフィックス ポリシー テーブルで高い優先順位が動的に構成されます。

組織で、サイト固有の IPv6 プレフィックスがある Active Directory トポロジを使用する場合 (たとえば、内部リソース FQDN app.corp.com が、北アメリカとヨーロッパの両方で、場所ごとにサイト固有の IP アドレスを使用してホストされる場合)、これは、リモート アクセス コンソールを使用した場合には既定では構成されず、サイト固有の IPv6 プレフィックスは、各エントリ ポイントに対して構成されません。 このオプション シナリオを実現したい場合は、クライアント コンピューターが特定のエントリ ポイントに接続するときに優先させる特定の IPv6 プレフィックスを、各エントリ ポイントに構成する必要があります。 この操作は次のように行います。

  1. Windows 10 または Windows 8 クライアント コンピューターに対して使用する GPO ごとに、Set-DAEntryPointTableItem PowerShell コマンドレットを実行します。

  2. コマンドレットの EntryPointRange パラメーターには、サイト固有の IPv6 プレフィックスを設定します。 たとえば、サイト固有のプレフィックス 2001:db8:1:1::/64 と 2001:db:1:2::/64 を、Europe という名前のエントリ ポイントに追加するには、以下を実行します。

    $entryPointName = "Europe"
$prefixesToAdd = @("2001:db8:1:1::/64", "2001:db8:1:2::/64")
$clientGpos = (Get-DAClient).GpoName
$clientGpos | % { Get-DAEntryPointTableItem -EntryPointName $entryPointName -PolicyStore $_ | %{ Set-DAEntryPointTableItem -PolicyStore $_.PolicyStore -EntryPointName $_.EntryPointName -EntryPointRange ($_.EntryPointRange) + $prefixesToAdd}}

  3. EntryPointRange パラメーターを変更するとき、IPsec トンネル エンドポイントに属する既存の 128 ビット プレフィックスと DNS64 アドレスを削除しないようにしてください。

3.7 マルチサイト リモート アクセスが展開されている場合に IPv6 への移行を計画する

多くの組織では、企業ネットワークで IPv4 プロトコルを使用しています。 使用可能な IPv4 プレフィックスの不足により、多くの組織は IPv4 専用ネットワークから IPv6 専用ネットワークに移行しようとしています。

この移行は、多くの場合、次の 2 つの段階で実行します。

  1. IPv4 専用企業ネットワークから IPv6+IPv4 企業ネットワークへ。

  2. IPv6+IPv4 企業ネットワークから IPv6 専用企業ネットワークへ。

各部分で、移行は段階的に実行できます。 各段階で、ネットワークの 1 つのサブネットのみを新しいネットワーク構成に変更できます。 そのため、たとえば、エントリ ポイントの一部が IPv4 専用サブネットに属し、他のエントリ ポイントが IPv6+IPv4 サブネットに属するというハイブリッド展開をサポートするために、DirectAccess マルチサイト展開が必要です。 また、移行プロセス中の構成の変更により、DirectAccess を介したクライアント接続が切断されないようにする必要があります。

IPv4 専用企業ネットワークから IPv6+IPv4 企業ネットワークに移行する

IPv4 専用企業ネットワークに IPv6 アドレスを追加する場合、既に展開されている DirectAccess サーバーに IPv6 アドレスを追加したい場合があります。 また、IPv4 と IPv6 の両方のアドレスを持つ、負荷分散クラスターへのエントリ ポイントまたはノードを、DirectAccess 展開に追加したい場合もあります。

リモート アクセスを使用すると、IPv4 と IPv6 の両方のアドレスを持つサーバーを、元は IPv4 アドレスしか構成されていなかった展開に追加できます。 これらのサーバーは IPv4 専用サーバーとして追加され、その IPv6 アドレスは DirectAccess では無視されます。そのため、組織は、これらの新しいサーバーでネイティブの IPv6 接続の利点を活用できません。

展開を IPv6+IPv4 展開に移行し、ネイティブの IPv6 機能を活用するには、DirectAccess を再インストールする必要があります。 再インストールの最中にクライアント接続を維持するには、「デュアル DirectAccess 展開を使用して IPv4 専用展開から IPv6 専用展開に移行する」を参照してください。

注意

IPv4 専用ネットワークと同様に、IPv4+IPv6 混合ネットワークでは、クライアントの DNS 要求の解決に使用される DNS サーバーのアドレスは、企業 DNS ではなく、リモート アクセス サーバー自体に展開される DNS64 で構成する必要があります。

IPv6+IPv4 企業ネットワークから IPv6 専用企業ネットワークに移行する

DirectAccess では、展開内の最初のリモート アクセス サーバーが最初に IPv4 と IPv6 の両方のアドレスを持っていた場合、または IPv6 アドレスのみ持っていた場合に限り、IPv6 専用エントリ ポイントを追加できます。 したがって、DirectAccess を再インストールせずに、1 つの手順で IPv4 専用ネットワークから IPv6 専用ネットワークに移行することはできません。 IPv4 専用ネットワークから IPv6 専用ネットワークに直接移行するには、「デュアル DirectAccess 展開を使用して IPv4 専用展開から IPv6 専用展開に移行する」を参照してください。

IPv4 専用展開から IPv6+IPv4 展開への移行が完了した後、IPv6 専用ネットワークに移行できます。 移行中および移行後は、次の点に注意してください。

  • IPv4 専用バックエンド サーバーが企業ネットワークに残っている場合、それらのサーバーは、IPv6 専用エントリ ポイントを介して接続するクライアントには到達できません。

  • IPv6 専用エントリ ポイントを IPv4+IPv6 展開に追加する場合、新しいサーバーでは DNS64 と NAT64 は有効になりません。 これらのエントリ ポイントに接続するクライアントは、企業 DNS サーバーを使用するように自動的に構成されます。

  • 展開されたサーバーから IPv4 アドレスを削除する必要がある場合、DirectAccess 展開からサーバーを削除し、その IPv4 企業ネットワーク アドレスを削除し、展開にサーバーを再度追加する必要があります。

企業ネットワークへのクライアント接続をサポートするために、企業 DNS がネットワーク ロケーション サーバーを IPv6 アドレスに解決できるか確認する必要があります。 追加の IPv4 アドレスも設定できますが、必須ではありません。

デュアル DirectAccess 展開を使用して IPv4 専用展開から IPv6 専用展開に移行する

DirectAccess 展開を再インストールせずに、IPv4 専用企業ネットワークから IPv6 専用企業ネットワークに移行することはできません。 移行中にクライアント接続を維持するために、別の DirectAccess 展開を使用できます。 最初の移行段階 (IPv4 専用ネットワークから IPv4+IPv6 ネットワークへのアップグレード) が完了し、IPv6 専用企業ネットワークへの将来の移行に備える場合、またはネイティブの IPv6 接続の利点を活用する場合、デュアル展開が必要です。 デュアル展開については、次の一般的な手順で説明します。

  1. 2 番目の DirectAccess 展開をインストールします。 新しいサーバーに DirectAccess をインストールすること、または最初の展開からサーバーを削除し、それらのサーバーを 2 番目の展開用に使用することができます。

    注意

    現在の DirectAccess 展開と横並びに追加の DirectAccess 展開をインストールする場合、2 つのエントリ ポイントが同じクライアント プレフィックスを共有していないことを確認してください。

    作業の開始ウィザードまたはコマンドレット Install-RemoteAccess を使用して DirectAccess をインストールすると、リモート アクセスにより、展開内の最初のエントリ ポイントのクライアント プレフィックスは、既定値である <IPv6 subnet_prefix>:1000::/64 に自動的に設定されます。 必要に応じて、このプレフィックスは変更してください。

  2. 最初の展開から選択したクライアント セキュリティ グループを削除します。

  3. 2 番目の展開にクライアント セキュリティ グループを追加します。

    重要

    プロセス中にクライアントの接続を維持するには、最初の展開からセキュリティ グループを削除した直後に、2 番目の展開にそれらのセキュリティ グループを追加する必要があります。 これにより、クライアントは 2 または 0 個の DirectAccess GPO で更新されなくなります。 クライアントは、クライアント GPO を取得して更新した後、2 番目の展開の使用を開始します。

  4. 省略可能: 最初の展開から DirectAccess エントリ ポイントを削除し、2 番目の展開でそれらのサーバーを新しいエントリ ポイントとして追加します。

移行が完了したら、最初の DirectAccess 展開をアンインストールできます。 アンインストール時に、次の問題が発生する可能性があります。

  • モバイル コンピューター上のクライアントのみをサポートするように展開が構成されている場合、WMI フィルターは削除されます。 2 番目の展開のクライアント セキュリティ グループにデスクトップ コンピューターが含まれる場合、DirectAccess クライアント GPO により、デスクトップ コンピューターがフィルター処理され、それらのコンピューターで問題が発生する可能性があります。 モバイル コンピューターのフィルターが必要な場合は、「GPO の WMI フィルターを作成する」の手順に従いフィルターを再作成してください。

  • 両方の展開が最初に同じ Active Directory ドメインで作成された場合、localhost を指す DNS プローブ エントリは削除され、クライアント接続の問題が発生する可能性があります。 たとえば、クライアントは Teredo ではなく IP-HTTPS を使用して接続する場合や、DirectAccess マルチサイト エントリ ポイントを切り替える場合があります。 この場合、企業 DNS に次の DNS エントリを追加する必要があります。

    • ゾーン: ドメイン名

    • 名前: directaccess-corpConnectivityHost

    • IP アドレス: ::1

    • 種類: AAAA