Notice: This website is an unofficial Microsoft Knowledge Base (hereinafter KB) archive and is intended to provide a reliable access to deleted content from Microsoft KB. All KB articles are owned by Microsoft Corporation. Read full disclaimer for more details.

e2e: Direct Access single server setup with mixed IPv4 and IPv6 environment


View products that this article applies to.

Notice

This article is one in a series of articles on end-to-end configuring and troubleshooting of DirectAccess. For a complete list of the series, see End-to-end configuring and troubleshooting DirectAccess .

↑ Back to the top


Summary

This guide provides step-by-step instructions for configuring DirectAccess in a single server deployment with mixed IPv4 and IPv6 resources in a test lab to demonstrate functionality of the deployment experience. You will set up and deploy DirectAccess based on the Windows Server 2012 Base Configuration by using five server computers and two client computers. The resulting test lab simulates an intranet, the Internet, and a home network, and demonstrates DirectAccess in different Internet connection scenarios.

Important The following instructions are for configuring a Remote Access test lab that uses the minimum number of computers. Individual computers are needed to separate the services that are provided on the network and to clearly show the desired functionality. This configuration is neither designed to reflect best practices nor does it reflect a desired or recommended configuration for a production network. The configuration, including IP addresses and all other configuration parameters, is designed only to work on a separate test lab network.Attempting to adapt this Remote Access test lab configuration to a pilot or production deployment can result in configuration or functionality issues.

↑ Back to the top


Deployment information

Overview
In this test lab, Remote Access is deployed with the following topology:
  • One computer that is running Windows Server 2012 named DC1 that is configured as an intranet domain controller, a Domain Name System (DNS) server, and a Dynamic Host Configuration Protocol (DHCP) server.
  • One intranet member server that is running Windows Server 2012 named EDGE1 that is configured as a DirectAccess server.
  • One intranet member server that is running Windows Server 2012 named APP1 that is configured as a general application server and web server. APP1 is configured as an enterprise root certification authority (CA) and as the Network Location Server (NLS) for DirectAccess.
  • One intranet member server that is running Windows Server 2008 R2 named APP2 that is configured as a general application server and a web server. APP2 is an IPv4-only intranet resource that is used to demonstrate NAT64 and DNS64 capabilities.
  • One stand-alone server that is running Windows Server 2012 named INET1 that is configured as an Internet DHCP server, a DNS server, and a web server.
  • One roaming member client computer that is running Windows 8 named CLIENT1 that is configured as a DirectAccess client.
  • One stand-alone client computer that is running Windows 8 named NAT1 that is configured as a network address translation (NAT) device using Internet Connection Sharing.
The Remote Access test lab consists of three subnets that simulate the following:
  • The Internet (131.107.0.0/24).
  • An intranet named Corpnet (10.0.0.0/24), (2001:db8:1::/64), separated from the Internet by EDGE1.
  • A home network named Homenet (192.168.137.0/24) connected to the Internet subnet by using a NAT device.
Computers on each subnet connect by using a hub or switch. See the following figure:
Deployment
This test lab demonstrates a single server DirectAccess deployment in which intranet resources are a mix of IPv4 and IPv6.

Hardware and software requirements
The following are required components of the test lab:
  • The product disc or files for Windows Server 2012
  • The product disc or files for Windows 8
  • The product disc or files for Windows Server 2008 R2
  • Six computers or virtual machines that meet the minimum hardware requirements for Windows Server 2012
  • One computer or virtual machine that meets the hardware requirements for Windows Server 2008 R2

Known issues
The following are known issues when you configure a Single Server DirectAccess lab with Windows Server 2012:
  • Migration of a DirectAccess configuration from one Windows Server 2012 server to another is not supported in this release, and causes the Remote Access Management console to stop responding and close unexpectedly. To work around this issue, do the following:
    1. Start Registry Editor.
    2. In Registry Editor, locate and then click the following registry subkey:HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Ramgmtsvc\Config\Parameters
    3. Delete the DaConfigured DWORD value.
    4. From a command prompt, run gpupdate /force on the new DirectAccess server.
  • Management from a non-domain-joined computer through RSAT is not possible unless the destination server account is added to the non-domain-joined computer's list of WinRM TrustedHosts.
    • To add the target DirectAccess server to the non-domain-joined computer's list of WinRM TrustedHosts, run the following command:
      set-item wsman:\localhost\client\trustedhosts "<computerName>" -force 
  • In this release, the Remote Access wizard will always link DirectAccess Group Policy Objects (GPOs) to the domain root, even if the GPOs were previously linked to another container in Active Directory. If you want to link the GPOs to an OU for deployment, remove the domain root link and then relink the GPO to the desired OU after the wizard is finished. Alternately, you can remove linking permissions to the domain root for the DirectAccess administrator before configuring DirectAccess.

Steps for Configuring the Remote Access Test Lab
There are six steps to follow when you set up a Remote Access express setup test lab based on the Windows Server 2012 Base Configuration test lab.
  1. Set up the Base Configuration test lab:

    The DirectAccess Single Server test lab requires the Test Lab Guide: Windows Server 2012 Base Configuration with Optional mini-module: Homenet subnet and Optional mini-module: Basic PKI as its starting point.
  2. Configure DC1:

    DC1 is already configured as a domain controller with Active Directory, and is the DNS and DHCP server for the intranet subnet. For the single server DirectAccess test lab, DC1 must be configured to have a static IPv6 address. A security group will be added to Active Directory for DirectAccess client computers.
  3. Configure APP1:

    APP1 is already a member server that is configured with IIS and also acts as a file server and enterprise root certification authority (CA). For the Remote Access express setup test lab, APP1 must be configured to have a static IPv6 address.
  4. Configure APP2:

    APP2 is configured as a web and file server to demonstrate an IPv4-only intranet resource.
  5. Configure EDGE1:

    EDGE1 is already a member server. For the single server DirectAccess test lab, EDGE1 must be configured as a Remote Access server that has a static IPv6 address.
  6. Configure CLIENT1:

    CLIENT1 is already a domain member client computer that is running Windows 8. For the Remote Access express setup test lab, CLIENT1 will be used to test and demonstrate remote access operation.
Note You must be logged on as a member of the Domain Admins group or as a member of the Administrators group on each computer to complete the tasks described in this guide. If you cannot complete a task while you are logged on with an account that is a member of the Administrators group, try performing the task while you are logged on with an account that is a member of the Domain Admins group.

↑ Back to the top


Deployment methods

This guide provides steps for configuring the computers of the Windows Server 2012 Base Configuration test lab, configuring Remote Access in Windows Server 2012, and demonstrating remote client connectivity. The following sections provide details about how to perform these tasks.
Step 1: Set up the Base Configuration Test Lab
Set up the Base Configuration test lab for both the Corpnet and Internet subnets by using the procedures in the "Steps for Configuring the Corpnet Subnet" and "Steps for Configuring the Internet Subnet" sections of the Test Lab Guide: Windows Server 2012 Base Configuration.

Set up the Homenet subnet by using the procedures in the Optional mini-module: Homenet subnet.

Deploy a basic certificate infrastructure by using the procedure in the Optional mini-module: Basic PKI.

Step 2: Configure DC1
DC1 configuration for the DirectAccess single server deployment test lab consists of the following procedures:
  • Configure an IPv6 address on DC1.
  • Create a security group for DirectAccess client computers.
  • Create a network location server DNS record.
  • Create ICMPv4 and ICMPv6 echo request firewall rules in domain Group Policy.
The following sections explain these procedures in detail.

Configure an IPv6 address on DC1

The Windows Server 2012 Base Configuration test lab does not include IPv6 address configuration. In this step, add IPv6 address configuration to support a DirectAccess deployment.
To configure an IPv6 address on DC1
  1. In Server Manager, click Local Server in the console tree. Scroll to the top of the details pane, and then click the link next to Ethernet.
  2. In Network Connections, right-click Ethernet, and then click Properties.
  3. Click Internet Protocol Version 6 (TCP/IPv6), and then click Properties.
  4. Click Use the following IPv6 address. In IPv6 address, type 2001:db8:1::1. In Subnet prefix length, type 64. In Default gateway, type 2001:db8:1::2. Click Use the following DNS server addresses, and in Preferred DNS server, type 2001:db8:1::1, and then click OK.
  5. Click Internet Protocol Version 4 (TCP/IPv4), and then click Properties.
  6. In Default gateway, type 10.0.0.2, and then click OK.
  7. Close the Ethernet Properties dialog box.
  8. Close the Network Connections window.
Demo: Configure an IPv6 address on DC1


Note The following Windows PowerShell cmdlet or cmdlets perform the same function as the previous procedure. Enter each cmdlet on a single line, even though they may appear word-wrapped across several lines here because of formatting constraints. Be aware that the "Ethernet" interface name may be different on your computer. Use ipconfig /all to list out the interfaces.
New-NetIPAddress -InterfaceAlias "Ethernet" -IPv6Address 2001:db8:1::1 -PrefixLength 64
Set-DnsClientServerAddress -InterfaceAlias "Ethernet" -ServerAddresses 2001:db8:1::1
New-NetRoute -DestinationPrefix 2001:db8:1::/64 -InterfaceAlias "Ethernet" -NextHop 2001:db8:1::2 -AddressFamily IPv6
New-NetRoute -DestinationPrefix 10.0.0.0/24 -InterfaceAlias "Ethernet" -NextHop 10.0.0.2 -AddressFamily IPv4

Step 3: Create a security group for DirectAccess client computers
When DirectAccess is configured, it automatically creates GPOs that contain DirectAccess settings, and these are applied to DirectAccess clients and servers. By default, the Getting Started Wizard applies the client GPO to mobile computers only, in the Domain Computers security group. The procedures in this lab do not use the default setting, but instead create an alternate security group for DirectAccess clients.

To create a DirectAccess client security group

  1. On DC1, from the Start screen, click Active Directory Administrative Center.
  2. In the console tree, click the arrow to expand corp (local), and then click Users.
  3. In the Tasks pane, click New, and then click Group.
  4. In the Create Group dialog box, type DirectAccessClients for Group name.
  5. Scroll down to access the Members section of the Create Group dialog box, and then click Add.
  6. Click Object Types, select Computers, and then click OK.
  7. Type CLIENT1, and then click OK.
  8. Click OK to close the Create Group dialog box.
  9. Exit the Active Directory Administrative Center.


Note The following Windows PowerShell cmdlet or cmdlets perform the same function as the previous procedure. Enter each cmdlet on a single line, even though they may appear word-wrapped across several lines here because of formatting constraints.
New-ADGroup -GroupScope global -Name DirectAccessClients 
Add-ADGroupMember -Identity DirectAccessClients -Members CLIENT1$

Step 4: Create a network location server DNS record
A DNS record is required to resolve the name of the network location server, which will be located on the APP1 server.

To create the network location server DNS record

  1. Click Start, and then click DNS.
  2. Expand DC1, Forward Lookup Zones, and then select corp.contoso.com.
  3. Right-click corp.contoso.com, and then click New Host (A or AAAA).
  4. Under Name, type NLS, and under IP address, type 10.0.0.3.
  5. Click Add Host, click OK, and then click Done.
  6. Close the DNS Manager console.
Demo: Create a network location server DNS record.mp4


Note The following Windows PowerShell cmdlet or cmdlets perform the same function as the previous procedure. Enter each cmdlet on a single line, even though they may appear word-wrapped across several lines here because of formatting constraints.
Add-DnsServerResourceRecordA -Name NLS -ZoneName corp.contoso.com -IPv4Address 10.0.0.3 

Step 5: Create ICMPv4 and ICMPv6 echo request firewall rules in domain Group Policy
ICMPv4 and ICMPv6 echo requests inbound and outbound are required for Teredo support. DirectAccess clients use Teredo as their IPv6 transition technology to connect to the DirectAccess server over the IPv4 Internet when they are assigned a private (RFC 1918) IP address and are located behind a NAT device or firewall that allows outbound UDP port 3544. In addition, enabling ping facilitates connectivity testing between participants in the DirectAccess solution.

To create ICMPv4 and ICMPv6 firewall rules

  1. From the Start screen, click Group Policy Management.
  2. In the console tree, expand Forest: corp.contoso.com\Domains\corp.contoso.com.
  3. Select Group Policy Objects.
  4. In the details pane, right-click Default Domain Policy, and then click Edit.
  5. In the console tree of the Group Policy Management Editor, expand Computer Configuration\Policies\Windows Settings\Security Settings\Windows Firewall with Advanced Security\Windows Firewall with Advanced Security-LDAP://CN=...
  6. In the console tree, select Inbound Rules, right-click Inbound Rules, and then click New Rule.
  7. In the New Inbound Rule Wizard, on the Rule Type page, click Custom, and then click Next.
  8. On the Program page, click Next.
  9. On the Protocols and Ports page, in Protocol type, click ICMPv4, and then click Customize.
  10. On the Customize ICMP Settings dialog box, click Specific ICMP types, select Echo Request, click OK, and then click Next.
  11. Click Next three times.
  12. On the Name page, in Name, type Inbound ICMPv4 Echo Requests, and then click Finish.
  13. In the console tree, right-click Inbound Rules, and then click New Rule.
  14. On the Rule Type page, click Custom, and then click Next.
  15. On the Program page, click Next.
  16. On the Protocols and Ports page, in Protocol type, click ICMPv6, and then click Customize.
  17. On the Customize ICMP Settings dialog box, click Specific ICMP types, select Echo Request, click OK, and then click Next.
  18. Click Next three times.
  19. On the Name page, in Name, type Inbound ICMPv6 Echo Requests, and then click Finish.
  20. Confirm that the rules that you created appear in the Inbound Rules node. Close the Group Policy Management Editor, and close Group Policy Management console.
Demo: Create ICMPv4 and ICMPv6 Firewall Rules


Note The following Windows PowerShell cmdlet or cmdlets perform the same function as the previous procedure. Enter each cmdlet on a single line, even though they may appear word-wrapped across several lines here because of formatting constraints. Be aware that these commands are required on each corpnet computer, and do not configure Group Policy settings:
Set-NetFirewallRule -DisplayName "File and Printer Sharing (Echo Request - ICMPv4-In)" -Enabled True -Direction Inbound -Action Allow 
Set-NetFirewallRule -DisplayName "File and Printer Sharing (Echo Request - ICMPv6-In)" -Enabled True -Direction Inbound -Action Allow

Step 6: Configure APP1
APP1 configuration for the DirectAccess single server deployment test lab consists of the following procedures:
  • Configure an IPv6 address on APP1.
  • Configure permissions of the Web Server certificate template.
  • Obtain an additional certificate for APP1.
  • Configure the HTTPS security binding.
The following sections explain these procedures in detail.

Configure an IPv6 address on APP1

The Windows Server 2012 Base Configuration test lab does not include IPv6 address configuration. In this step, add IPv6 address configuration to support a DirectAccess deployment.
To configure an IPv6 address on APP1
  1. In Server Manager, click Local Server in the console tree. Scroll to the top of the details pane, and then click the link next to Ethernet.
  2. In Network Connections, right-click Ethernet, and then click Properties.
  3. Click Internet Protocol Version 6 (TCP/IPv6), and then click Properties.
  4. Click Use the following IPv6 address. In IPv6 address, type 2001:db8:1::3. In Subnet prefix length, type 64. In Default gateway, type 2001:db8:1::2. Click Use the following DNS server addresses, and in Preferred DNS server, type 2001:db8:1::1. Click OK.
  5. Click Internet Protocol Version 4 (TCP/IPv4), and then click Properties.
  6. In Default gateway, type 10.0.0.2, and then click OK.
  7. Close the Ethernet Properties dialog box.
  8. Close the Network Connections window.
Demo: Configure an IPv6 address on APP1


Note The following Windows PowerShell cmdlet or cmdlets perform the same function as the previous procedure. Enter each cmdlet on a single line, even though they may appear word-wrapped across several lines here because of formatting constraints. Be aware that the "Ethernet" interface name may be different on your computer. Use ipconfig /all to list out the interfaces.
New-NetIPAddress -InterfaceAlias "Ethernet" -IPv6Address 2001:db8:1::3 -PrefixLength 64
Set-DnsClientServerAddress -InterfaceAlias "Ethernet" -ServerAddresses 2001:db8:1::1
New-NetRoute -DestinationPrefix 2001:db8:1::/64 -InterfaceAlias "Ethernet" -NextHop 2001:db8:1::2 -AddressFamily IPv6
New-NetRoute -DestinationPrefix 10.0.0.0/24 -InterfaceAlias "Ethernet" -NextHop 10.0.0.2 -AddressFamily IPv4

Configure permissions of the Web Server certificate template

Next, configure permissions on the Web Server certificate template so that requesting computers can specify the subject name of a certificate.
To configure permissions of the Web Server certificate template
  1. On APP1, from the Start screen, click Certification Authority.
  2. In the details pane, expand corp-APP1-CA.
  3. Right-click Certificate Templates, and then click Manage.
  4. In the Certificate Templates console, right-click the Web Server template, and then click Properties.
  5. Click the Security tab, and then click Authenticated Users.
  6. In Permissions for Authenticated Users, click Enroll under Allow, and then click OK.

    Note The Authenticated Users group is configured here for simplicity in the test lab. In a real deployment, you would specify the name of a security group that contains the computer accounts of the computers in your organization that can request custom certificates. This includes the DirectAccess server and network location server.
  7. Close the Certificate Templates console.
Demo: Configure permissions of the Web Server certificate template

Obtain an additional certificate on APP1

Obtain an additional certificate for APP1 with a customized subject and alternative name for network location.
To obtain an additional certificate for APP1
  1. From the Start screen, type mmc, and then press Enter.
  2. Click File, and then click Add/Remove Snap-in.
  3. Click Certificates, click Add, select Computer account, click Next, select Local computer, click Finish, and then click OK.
  4. In the console tree of the Certificates snap-in, open Certificates (Local Computer)\Personal\Certificates.
  5. Right-click Certificates, point to All Tasks, and then click Request New Certificate.
  6. Click Next two times.
  7. On the Request Certificates page, click Web Server, and then click More information is required to enroll for this certificate.
  8. On the Subject tab of the Certificate Properties dialog box, in Subject name, for Type, select Common Name.
  9. In Value, type nls.corp.contoso.com, and then click Add.
  10. Click OK, click Enroll, and then click Finish.
  11. In the details pane of the Certificates snap-in, verify that a new certificate with the name nls.corp.contoso.com was enrolled with Intended Purposes of Server Authentication.
  12. Close the console window. If you are prompted to save settings, click No.
Demo: Obtain an Additional Certificate on APP1

Configure the HTTPS security binding

Next, configure the HTTPS security binding so that APP1 can act as the network location server.
To configure the HTTPS security binding
  1. From the Start screen, click Internet Information Services (IIS) Manager.
  2. In the console tree of Internet Information Services (IIS) Manager, open APP1/Sites, and then click Default Web site.
  3. In the Actions pane, click Bindings.
  4. In the Site Bindings dialog box, click Add.
  5. In the Add Site Binding dialog box, in the Type list, click https. In SSL Certificate, click the certificate with the name nls.corp.contoso.com. Click OK,and then click Close.
  6. Close the Internet Information Services (IIS) Manager console.
Demo: Configuring HTTPS Security Binding on APP1


Step 7: Install and Configure APP2
APP2 is a Windows Server 2008 R2 Enterprise Edition computer that acts as an IPv4-only host and is used to demonstrate DirectAccess connectivity to IPv4-only resources using the DNS64 and NAT64 features. APP2 hosts both HTTP and SMB resources that the DirectAccess client computer will be able to access from the simulated Internet. The NAT64/DNS64 feature set enables organizations to deploy DirectAccess without requiring them to upgrade network resources to native IPv6 or even IPv6 capable.

APP2 configuration for the DirectAccess single server test lab consists of the following procedures:
  • Create a shared folder on APP2.
  • Install IIS web services.
The following sections explain these procedures in detail.

Create a shared folder on APP2

The first step is to create a share folder on APP2. APP2 will be used to demonstrate HTTP connectivity over the DirectAccess connection to an IPv4-only host.
  1. On APP2, open Windows Explorer.
  2. Browse to the C: drive.
  3. Right click the blank of the window, point to New, and click Folder.
  4. Type Files and press Enter.
  5. Right click Files and choose Properties.
  6. On the Files Properties dialog box, on the Sharing tab, click Share…. Add Everyone for Read permission, and then click Share.
  7. Double click the Files folder.
  8. Right click the blank of the window, point to New, and then click Text Document.
  9. Double click the New Text Document.txt file.
  10. In the New Text Document.txt – Notepad window, enter This is a text document on APP2, an IPv4 only server.
  11. Close Notepad. On the Notepad dialog box, click Yes to save the changes.
  12. Close Windows Explorer.

Install IIS web services on APP2

Then, configure APP2 as a web server.
  1. On APP2, open Server Manager.
  2. Click Roles, and then click Add Roles.
  3. In Add Roles Wizard window, click Next.
  4. Choose Web Server (IIS), and then click Next.
  5. Click Next twice and then click Install.
Demo: Install and configure APP2

Step 8: Configure EDGE1
EDGE1 configuration for the DirectAccess single server deployment test lab consists of the following procedures:
  • Configure an IPv6 address on EDGE1.
  • Provision EDGE1 with a certificate for IP-HTTPS.
  • Install the Remote Access role on EDGE1.
  • Configure DirectAccess on EDGE1.
  • Confirm Group Policy settings.
  • Confirm IPv6 settings.
The following sections explain these procedures in detail.

Configure an IPv6 address on EDGE1

The Windows Server 2012 Base Configuration test lab does not include IPv6 address configuration. In this step, add IPv6 address configuration to EDGE1 to support a DirectAccess deployment.
To configure an IPv6 address on EDGE1
  1. In Server Manager, click Local Server in the console tree. Scroll to the top of the details pane, and then click the link next to Corpnet.
  2. In Network Connections, right-click Corpnet, and then click Properties.
  3. Click Internet Protocol Version 6 (TCP/IPv6), and then click Properties.
  4. Click Use the following IPv6 address. In IPv6 address, type 2001:db8:1::2. In Subnet prefix length, type 64. Click Use the following DNS server addresses, and in Preferred DNS server, type 2001:db8:1::1. Click OK.
  5. Close the Corpnet Properties dialog box.
  6. Close the Network Connections window.
Demo: Configure an IPv6 Address on EDGE1


Note The following Windows PowerShell cmdlet or cmdlets perform the same function as the previous procedure. Enter each cmdlet on a single line, even though they may appear word-wrapped across several lines here because of formatting constraints. Be aware that the "Ethernet" interface name may be different on your computer. Use ipconfig /all to list out the interfaces.
New-NetIPAddress -InterfaceAlias Corpnet -IPv6Address 2001:db8:1::2 -PrefixLength 64
Set-DnsClientServerAddress -InterfaceAlias Corpnet -ServerAddresses 2001:db8:1::1

Provision EDGE1 with a certificate for IP-HTTPS

A certificate is required to authenticate the IP-HTTPS listener when clients connect over HTTPS.
Prepare a certificate template
  1. On App1, from the Start screen, type mmc, and then press Enter.
  2. Click File, and then click Add/Remove Snap-in.
  3. Click Certificate Templates, click Add, and then click OK.
  4. Click Certificate Templates in the left panel. In the detail panel, right click the Computer template and click Duplicate Template.
  5. Click the Subject Name tab, and then click Supply in the request option. Click OK.
  6. Click the General tab, and then type Template for DA under Template display name.
  7. Click OK.
  8. In the MMC window, click File, and then click Add/Remove Snap-in.
  9. Click Certification Authority, click Add, click Local computer: (the computer this console is running on), click Finish, and then click OK.
  10. Expand corp-APP1-CA, right click Certificate Template, select New, click Certificate Template to Issue.
  11. Select Template for DA, and click OK.
Demo: Prepare a certificate template
To install an IP-HTTPS certificate on EDGE1
  1. On EDGE1, from the Start screen, type mmc, and then press Enter.
  2. Click File, and then click Add/Remove Snap-in.
  3. Click Certificates, click Add, click Computer account, click Next, select Local computer, click Finish, and then click OK.
  4. In the console tree of the Certificates snap-in, open Certificates (Local Computer)\Personal\Certificates.
  5. Right-click Certificates, point to All Tasks, and then click Request New Certificate.
  6. Click Next two times.
  7. On the Request Certificates page, click Template for DA, and then click More information is required to enroll for this certificate.
  8. On the Subject tab of the Certificate Properties dialog box, in Subject name, for Type, select Common Name.
  9. In Value, type edge1.contoso.com, and then click Add.
  10. In the Alternative name area, under Type, select DNS.
  11. In Value, type edge1.contoso.com, and then click Add.
  12. On the General tab, under Friendly name, type IP-HTTPS Certificate.
  13. Click OK, click Enroll, and then click Finish.
  14. In the details pane of the Certificates snap-in, verify that a new certificate with the name edge1.contoso.com was enrolled with Intended Purposes of Server Authentication, Client Authentication.
  15. Close the console window. If you are prompted to save settings, click No.
Note If you cannot see the Template for DA template, check the following items:
  • Check whether the user account has permission to enroll the Template for DA template.
  • Check whether the certificate template has successfully been added to CA.
Demo: Install an IP-HTTPS certificate on EDGE1

Install the Remote Access server role on EDGE1

The Remote Access server role in Windows Server 2012 combines the DirectAccess feature and the RRAS role service into a new unified server role. This new Remote Access server role allows for centralized administration, configuration, and monitoring of both DirectAccess and VPN-based remote access services. Use the following procedure to install the Remote Access role on EDGE1.
To install the Remote Access server role on EDGE1
  1. In the Dashboard console of Server Manager, under Configure this local server, click Add roles and features.
  2. Click Next three times to reach the server role selection screen.
  3. In the Select Server Roles dialog box, select Remote Access, click Add Features when you are prompted, and then click Next.
  4. Click Next five times to accept the default settings for features, remote access role services, and web server role services.
  5. On the Confirmation screen, click Install.
  6. Wait for the feature installations to complete, and then click Close.
video


Note The following Windows PowerShell cmdlet or cmdlets perform the same function as the previous procedure. Enter each cmdlet on a single line, even though they may appear word-wrapped across several lines here because of formatting constraints.
Install-WindowsFeature RemoteAccess -IncludeManagementTools 

Configure DirectAccess on EDGE1

Configure DirectAccess in a single server deployment by using the Remote Access Setup Wizard.
To configure DirectAccess on EDGE1
  1. From the Start screen, click Remote Access Management.
  2. In the Remote Access Management console, click Run the Remote Access Setup Wizard.
  3. In the Configure Remote Access wizard, click Deploy DirectAccess only.
  4. Under "Step 1 Remote Clients," click Configure.
  5. Select Deploy full DirectAccess for client access and remote management, and then click Next.
  6. On the Select Groups screen, click Add, type DirectAccessClients, click OK, and then click Next.
  7. On the Network Connectivity Assistant screen, next to DirectAccess connection name, type Contoso DirectAccess Connection. Click Finish.
  8. Under "Step 2 DirectAccess Server," click Configure.
  9. Verify that Edge is selected as the network topology. Type edge1.contoso.com as the public name to which remote access clients will connect. Click Next.
  10. On the Network Adapters screen, wait for the wizard to populate the Internet and Corpnet interfaces. Verify that CN=edge1.contoso.com is the certificate automatically selected to authenticate IP-HTTPS connections. Click Next.
  11. On the Prefix Configuration screen, click Next.
  12. On the Authentication screen, select Use computer certificates, and then click Browse.
  13. Select corp-APP1-CA, click OK, and then click Finish.
  14. Under "Step 3 Infrastructure Servers," click Configure.
  15. For the URL of the network location server, type https://nls.corp.contoso.com, and then click Validate.
  16. After connectivity to the NLS URL on APP1 is validated successfully, click Next.
  17. Click Next two times to accept default settings for DNS and Management, and then click Finish.
  18. At the bottom of the Remote Access Setup screen, click Finish.
  19. In the Remote Access Review dialog box, click Apply.
  20. After the Remote Access Setup Wizard is finished, click Close.
  21. In the console tree of the Remote Access Management console, select Operations Status. Wait until the status of all monitors displays "Working." In the Tasks pane under Monitoring, click Refresh periodically to update the display.
Demo: Configure Direct Access on EDGE1


Note In this release of Windows Server 2012, the status of Network adapters may be yellow instead of green. To make sure that the status of Network adapters is displayed as "Working," open an elevated command prompt, type the following command, and then press Enter:
netsh interface ipv6 add route 2001:db8:1::/48 publish=yes interface = "Corpnet" 

Confirm Group Policy settings

The DirectAccess wizard configures GPOs and settings that are automatically deployed by using Active Directory for the Remote Access server and the DirectAccess clients.

To examine Group Policy settings created by the DirectAccess wizard

  1. On EDGE1, from the Start screen, click Group Policy Management.
  2. Expand Forest: corp.contoso.com, expand Domains, expand corp.contoso.com, and then expand Group Policy Objects.
  3. The Remote Access Setup wizard creates two new GPOs. DirectAccess Client Settings is applied to members of the DirectAccessClients security group. DirectAccess Server Settings is applied to the EDGE1 DirectAccess server. Confirm that the correct security filtering is performed for each of these GPOs by clicking the GPO and then viewing the entries in the Security Filtering section on the Scope tab in the details pane of the console.
  4. From the Start screen, type wf.msc, and then press Enter.
  5. In the Windows Firewall with Advanced Security console, notice that the Domain Profile is Active and the Public Profile is Active. Make sure that the Windows Firewall is enabled and both the domain and public profiles are active. If the Windows Firewall is disabled, or if domain or public profiles are disabled, then DirectAccess will not function correctly.
  6. In the Windows Firewall with Advanced Security console tree, click the Connection Security Rules node. The details pane of the console will display two connection security rules: DirectAccess Policy-DaServerToCorp, and DirectAccess Policy-DaServerToInfra. The first rule is used to establish the intranet tunnel and the second rule is for the infrastructure tunnel. Both rules are delivered to EDGE1 by using Group Policy.
  7. Close the Windows Firewall with Advanced Security console.
Demo: Confirm Group Policy Settings

Confirm IPv6 settings

  1. On EDGE1, from the desktop taskbar, right-click Windows PowerShell, and then click Run as administrator.
  2. In the Windows PowerShell window, type Get-NetIPAddress and press Enter.
  3. The output displays information related to the EDGE1 networking configuration. There are several sections of interest:
    • The 6TO4 Adapter section shows information that includes the Global IPv6 address that is used by EDGE1 on its external interface.
    • The IPHTTPSInterface section shows information about the IP-HTTPS interface.
  4. To see information about the Teredo interface on EDGE1, type netsh interface Teredo show state and press Enter. The output should include an entry State: online.
Demo: Confirm IPv6 Settings

Step 9: Connect Client1 to Corpnet Subnet and Update Group Policy
To receive the DirectAccess settings, CLIENT1 must update its Group Policy settings while connected to the Corpnet subnet.

To update Group Policy on CLIENT1 and apply DirectAccess settings

  1. Connect CLIENT1 to the Corpnet subnet.
  2. Restart the CLIENT1 computer to update Group Policy and security group membership while connected to the Corpnet subnet. After restarting, log on as CORP\User1.
  3. From the Start screen, type PowerShell, right-click Windows PowerShell, and then click Run as administrator.
  4. Type Get-DnsClientNrptPolicy and press Enter. The Name Resolution Policy Table (NRPT) entries for DirectAccess are displayed. Notice that the NLS server exemption is displayed as NLS.corp.contoso.com. This is the alias used for the APP1 server. All other name resolution for corp.contoso.com will use the internal IPv6 address of the EDGE1 server (2001:db8::1::2) when outside the corporate network.
  5. Type Get-NCSIPolicyConfiguration and press Enter. The network connectivity status indicator settings deployed by the wizard are displayed. Notice that the value of DomainLocationDeterminationURL is https://nls.corp.contoso.com. Whenever this network location server URL can be accessed, the client will verify that it is inside the corporate network, and NRPT settings will not be applied.
  6. Type Get-DAConnectionStatus and press Enter. Because the client can reach the network location server URL, the status will be displayed as ConnectedLocally.
Demo: Connect Client1 to Corpnet Subnet and Update Group Policy

After you connect the client computer to the Corpnet Subnet and restart it, watch the following demo video:

Step 10: Connect CLIENT1 to the Internet subnet and test remote access
To test remote access connectivity from the Internet, move the CLIENT1 connection to the Internet subnet.

To test remote access from the Internet

  1. Connect CLIENT1 to the Internet subnet. After the network determination process is complete, the network icon should indicate Internet access.
  2. In the PowerShell window, type Get-DAConnectionStatus and press Enter. The status should be displayed as ConnectedRemotely.
  3. Click the network icon in the System Notification Area. Be aware that Contoso DirectAccess Connection is listed as Connected. This is the connection name we provided in the DirectAccess wizard.
  4. Right-click Contoso DirectAccess Connection and then click Properties. Be aware that Status is displayed as Connected.
  5. From the PowerShell prompt, type ping inet1.isp.example.com and press Enter to verify Internet name resolution and connectivity. You should receive four replies from 131.107.0.1.
  6. Type ping app1.corp.contoso.com and press Enter to verify corporate intranet name resolution and connectivity. Because APP1 is an IPv6 enabled intranet resource, the ICMP response is from the IPv6 address of APP1 (2001:db8:1::3).
  7. Type ping app2.corp.contoso.com and press Enter to verify name resolution and connectivity to the intranet Windows Server 2003 file server. Note the format of the IPv6 address returned. Because APP2 is an IPv4-only intranet resource, the dynamically created NAT64 address of APP2 is returned. The dynamically created prefix assigned by DirectAccess for NAT64 will be in the form fdxx:xxxx:xxxx:7777::/96.
  8. Click the Internet Explorer icon to start it. Verify that you can access the website on http://inet1.isp.example.com. This site is running on the INET1 Internet server, and validates Internet connectivity outside DirectAccess.
  9. Verify that you can access the website on http://app1.corp.contoso.com. This site is running on the APP1 server, and validates DirectAccess connectivity to an internal IPv6 web server.
  10. Verify that you can access the website on http://app2.corp.contoso.com. You should see the default "Under Construction" IIS webpage, validating DirectAccess connectivity to an internal IPv4-only web server.
  11. From the desktop taskbar, click the Windows Explorer icon.
  12. In the address bar, type \\app1\Files, and then press Enter.
  13. You should see a folder window with the contents of the Files shared folder.
  14. In the Files shared folder window, double-click the Example.txt file. You should see the contents of the Example.txt file.
  15. Close the Example - Notepad window.
  16. In the Windows Explorer address bar, type \\app2\Files, and then press Enter.
  17. In the Files shared folder window, double-click the New Text Document.txt file. You should see the contents of the document shared on the IPv4-only server.
  18. Close the New Text Document - Notepad and the Files shared folder windows.
  19. From the PowerShell window, type Get-NetIPAddress and then press Enter to examine the client's IPv6 configuration.
  20. Type Get-NetTeredoState and press Enter to examine the Teredo configuration. Notice that the Teredo server name is edge1.contoso.com, the externally resolvable DNS name of the EDGE1 server.
  21. Type Get-NetIPHTTPSConfiguration and press Enter. Examine the settings applied by Group Policy to direct the client to https://edge1.contoso.com:443/IPHTTPS.
  22. Type wf.msc and then press Enter to start the Windows Firewall with Advanced Security console. Expand Monitoring, then Security Associations to examine the IPsec SAs established. Notice that the authentication methods that are used are Computer Kerberos and User Kerberos, and also Computer certificate and User Kerberos.
  23. Select Connection Security Rules in the console tree. Examine the rules used to provide DirectAccess connectivity.
  24. Close the Windows Firewall with Advanced Security console.
Demo: Connect CLIENT1 to the Internet subnet and test remote access

After you connect the client computer to the Internet subnet, watch the following demo video:

Step 11: Connect CLIENT1 to the Homenet subnet and test remote access
To test remote access connectivity from a simulated home network behind NAT, move the CLIENT1 connection to the Homenet subnet.

To test remote access from the home network

  1. Connect CLIENT1 to the Homenet subnet. As soon as the network determination process is complete, the network icon should indicate Internet access.
  2. In the PowerShell window, type Get-DAConnectionStatus and press Enter. The status is displayed as ConnectedRemotely.
  3. Click the network icon in the System Notification Area. Be aware that Contoso DirectAccess Connection is listed as Connected. Right-click Contoso DirectAccess Connection and then click Properties. Be aware that Status is listed as Connected.
  4. Type ping app1.corp.contoso.com and press Enter to verify corporate intranet name resolution and connectivity to an internal IPv6 resource.
  5. Type ping app2.corp.contoso.com and press Enter to verify corporate intranet name resolution and connectivity to an internal IPv4 resource.
  6. Click the Internet Explorer icon to start Internet Explorer. Verify that you can access the websites on http://inet1.isp.example.com, http://app1.corp.contoso.com, and http://app2.corp.contoso.com.
  7. From the desktop taskbar, click the Windows Explorer icon.
  8. Verify that you can access the shared files in \\APP1\Files and \\APP2\Files.
  9. Close the Windows Explorer window.
  10. In the PowerShell window, type Get-NetIPAddress and then press Enter to examine the client's IPv6 configuration.
  11. Type Get-NetTeredoState and press Enter to examine the Teredo configuration. Notice that the Teredo state is listed as qualified.
  12. Type ipconfig and press Enter. Be aware that in this deployment behind a NAT, the DirectAccess client is connecting through the Teredo tunnel adapter.
Demo: Connect CLIENT1 to the Homenet subnet and test remote access:

After you connect the client computer to the Homenet subnet, see the following demo video.

Step 12: Monitor the client connection on the EDGE1 DirectAccess server
The Remote Access Management Console in Windows Server 2012 provides remote client status monitoring functionality for both DirectAccess and VPN connections.

To monitor the client connection on EGDE1

  1. From the Start screen, click Remote Access Management.
  2. In the Remote Access Management console, select Dashboard.
  3. Examine the data that is collected under Remote Client Status.
  4. In the Remote Access Management console, select Remote Client Status.
  5. Double-click the CLIENT1 connection to display the detailed remote client statistics dialog box.
Demo: Monitor the client connection on EGDE1

Optional: Snapshot the Configuration
This finishes the DirectAccess simplified deployment in an IPv4-only environment test lab. To save this configuration so that you can quickly return to a working Remote Access configuration from which you can test other Remote Access modular test lab guides (TLGs), TLG extensions, or for your own experimentation and learning, do the following:

1. On all physical computers or virtual machines in the test lab, close all windows and then perform a graceful shutdown.

2. If your lab is based on virtual machines, save a snapshot of each virtual machine and name the snapshots DirectAccess mixed IPv4 and IPv6. If your lab uses physical computers, create disk images to save the DirectAccess simplified IPv4-only test lab configuration.

↑ Back to the top


Keywords: kbexpertiseadvanced, kbsurveynew, kbinfo, kbhowto, kb

↑ Back to the top

Article Info
Article ID : 3022362
Revision : 1
Created on : 1/7/2017
Published on : 11/9/2015
Exists online : False
Views : 378