This is the text of the Test Lab Guide - Demonstrate UAG SP1 RC DirectAccess Remote Management Test Lab Guide, which you can download at http://go.microsoft.com/fwlink/?LinkId=205210 

Table of Contents



I am posting the entire text of the Test Lab Guide here with the goal that the community can improve on the Test Lab Guide by adding new options, demonstrating new features, or just correct errors in the text :)  In fact, you can make any changes you like - that is the nature of a wiki. I'm looking forward to seeing how you all can make this great Test Lab Guide even better!

Introduction

Forefront Unified Access Gateway (UAG SP1 RC) provides users with the experience of being seamlessly connected to their intranet any time they have Internet access. When DirectAccess is enabled, requests for intranet resources (such as e-mail servers, shared folders, or intranet Web sites) are securely directed to the intranet, without the need for users to connect to a VPN. DirectAccess enables increased productivity for a mobile workforce by offering the same connectivity experience both inside and outside of the office. Forefront UAG SP1 RC DirectAccess extends the benefits of Windows DirectAccess across your infrastructure by enhancing availability and scalability, as well as simplifying deployments and ongoing management. For more information, see Overview of Forefront UAG DirectAccess.

About this guide

This Test Lab Guide provides step-by-step instructions for configuring Forefront UAG SP1 RC DirectAccess Remote Management in a test lab so that you can see how it works. You will set up and deploy Forefront UAG SP1 RC DirectAccess using 5 server computers, two client computers, Windows Server 2008 R2 Enterprise Edition, Windows Server 2003 Enterprise Edition SP2, and Windows 7 Ultimate Edition. The Test Lab simulates intranet, Internet, and a home networks, and demonstrates Forefront UAG SP1 RC DirectAccess in different Internet connection scenarios.
Important:
These instructions are designed for configuring a test lab using the minimum number of computers. Individual computers are needed to separate the services provided on the network, and to show clearly the required functionality. This configuration is not designed to reflect best practices, nor does it reflect a required or recommended configuration for a production network. The configuration, including IP addresses and all other configuration parameters, is designed to work only on a separate test lab network. For more information on planning and deploying DirectAccess with Forefront UAG SP1 RC, please see the Forefront UAG DirectAccess design guide and the Forefront UAG DirectAccess deployment guide
This Test Lab Guides builds on the Test Lab Guide: Demonstrate UAG SP1 RC DirectAccess. You will need to complete all the steps in that guide before you can complete the steps in this Test Lab Guide.

Overview of the test lab scenario

In this test lab scenario, Forefront UAG SP1 RC DirectAccess is deployed with:
  • One computer running Windows Server 2008 R2 Enterprise Edition (DC1), that is configured as an intranet domain controller, Domain Name System (DNS) server, Dynamic Host Configuration Protocol (DHCP) server, and an enterprise root certification authority (CA).
  • One intranet member server running Windows Server 2008 R2 Enterprise Edition (UAG1), that is configured as a Forefront UAG SP1 RC DirectAccess server.
  • One intranet member server running Windows Server 2008 R2 Enterprise Edition (APP1) that is configured as a general application server and network location server.
  • One intranet member server running Windows Server 2003 Enterprise Edition SP2 (APP3) that is configured as an IPv4 only web and file server. This server is used to highlight the NAT64/DNS64 capabilities.
  • One standalone server running Windows Server 2008 R2 (INET1) that is configured as an Internet DNS and DHCP server.
  • One standalone client computer running Windows 7 Ultimate Edition (NAT1), that is configured as a network address translator (NAT) device using Internet Connection Sharing.
  • One roaming member client computer running Windows 7 Enterprise or Ultimate (CLIENT1) that is configured as a DirectAccess client.
The test lab consists of three subnets that simulate the following:
  • A home network named Homenet (192.168.137.0/24) connected to the Internet by a NAT.
  • The Internet (131.107.0.0/24).
  • An intranet named Corpnet (10.0.0.0/24) separated from the Internet by the Forefront UAG SP1 RC DirectAccess server.
Computers on each subnet connect using either a physical or virtual hub or switch, as shown in the following figure.

Configuration component requirements

The following components are required for configuring Forefront UAG SP1 RC DirectAccess in the test lab:
  • The product disc or files for Windows Server 2008 R2 Enterprise Edition.
  • The product disc or files for Windows Server 2003 Enterprise SP2
  • The product disc or files for of Windows 7 Ultimate.
  • Four computers or virtual machines that meet the minimum hardware requirements for Windows Server 2008 R2 Enterprise; one of these computers has two network adapters installed.
  • One computer or virtual machine that meets the minimum hardware requirements for Windows Server 2003 SP2
  • Two computers or virtual machines that meet the minimum hardware requirements for Windows 7 Ultimate; one of these computers has two network adapters installed.
  • The product disc or a downloaded version of Microsoft Forefront Unified Access Gateway (UAG SP1 RC).

Steps for configuring the test lab

The following steps describe how to configure the server and client computers, in a test lab. Following these configurations you can verify DirectAccess connectivity from the Internet and Homenet subnets. In addition, you will see how you can manage DirectAccess clients from management computers on the intranet. This Test Lab Guide also highlights a new feature included in UAG SP1 RC, which allows you to limit DirectAccess client connectivity to the intranet tunnel only, which enables continuous management of DirectAccess clients without allowing users to access resources on the intranet.
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.
 
You will perform the following steps to demonstrate UAG SP1 RC DirectAccess remote management in this Test Lab Guide:

·         Step 1: Complete the Test Lab Guide: Demonstrate UAG SP1 RC DirectAccess – This Test Lab Guide builds on the configuration created after completing the steps in Test Lab Guide: Demonstrate UAG SP1 RC DirectAccess.

·         Step 2: Configure Remote Management – In this step you will create the DirectAccess client OU, create and configure a DirectAccess client GPO and refresh the remote access client configuration and enabling remote desktop connectivity to DirectAccess clients.

·         Step 3: Test Remote Management of DirectAccess Clients – After the new firewall settings are deployed to the DirectAccess client, management servers on the corporate network can initiate connections to the DirectAccess client. In this step you validate the settings and establish connections from DC1 to CLIENT1, when CLIENT1 is acting as a DirectAccess client behind NAT1.

·         Step 4: Limit DirectAccess Client to Only the Management Tunnel. In this step you will configure UAG1 to limit DirectAccess client connectivity to only the infrastructure tunnel.

·         Step 5: Snapshot the Configuration. After completing the Test Lab, take a snapshot of the working UAG SP1 RC DirectAccess NLB array so that you can return to it later to test additional scenarios.

STEP 1: Complete the Demonstrate UAG SP1 RC DirectAccess Test Lab Guide

The first step is to complete all the steps in the Test Lab Guide: Demonstrate UAG SP1 RC DirectAccess. After completing the steps in that Test Lab Guide you will have the core infrastructure required to complete this Test Lab Guide on how to configure UAG SP1 RC DirectAccess remote management.  If you have already completed the Test Lab Guide: Demonstrate UAG SP1 RC DirectAccess Test Lab Guide and saved the configuration in either a virtual machine snapshot or disk image for a physical deployment, you can restore that configuration and begin with the next step.

STEP 2: Configure Remote Management

DirectAccess uses two IPsec tunnels between DirectAccess client and server to enable communications to the corporate network. The first IPsec tunnel is the “infrastructure” tunnel. This tunnel is established after the DirectAccess client computer starts, but before the user logs on. Authentication is required for this tunnel, and both a computer certificate and the computer account in Active Directory are used to authenticate the first IPsec tunnel connection. The second tunnel (the intranet tunnel) is established after the user logs on and allows the user to access network resources. Authentication for this tunnel uses computer certificate and user (Kerberos) authentication in Active Directory.
The infrastructure tunnel provides bidirectional access to and from servers included in the management servers collection, as defined in the DirectAccess configuration wizard. These servers can connect to DirectAccess clients over the infrastructure tunnel, so that connectivity is enabled whenever the DirectAccess client computer is turned on, regardless of whether the user is logged on. The infrastructure tunnel enables remote management scenarios where administrators can apply patches, make configuration changes, and employ their full suite of configuration and management tools not only to computers on the corporate network, but to any DirectAccess client on the Internet.
You will perform the following procedures to enable several remote management scenarios:

A.      Create the DirectAccess Client Organizational Unit and Place CLIENT1 in the New OU. New firewall rules are required to enable some aspects of remote management of DirectAccess clients. Firewall rules can be configured on each client individually, but it is more efficient to use Group Policy to distribute the new firewall rules to all DirectAccess clients. Changes could be made to the DirectAccess Client GPO created by the UAG SP1 RC DirectAccess wizard, but these settings are overwritten each time the wizard is run. Therefore, you will create new GPO to support these custom settings. The new GPO is then linked to an OU that is populated with the DirectAccess client computer accounts.

B.      Create and Configure the DirectAccess GPO and Link it to the DirectAccess Client OU. The DirectAccess GPO is linked to the DirectAccess client OU. In this step you create and populate the DirectAccess client OU.

C.      Refresh the DirectAccess Client Configuration and Enable Remote Desktop Connections to CLIENT1. The DirectAccess clients need to refresh this Group Policy configuration to receive the new GPO settings. In this step the DirectAccess client refreshes it Group Policy configuration to receive the new firewall settings.

A.     Create the DirectAccess Client Organizational Unit and Place CLIENT1 in the New OU

Remote management scenarios for DirectAccess clients can happen in two ways. In the first scenario, the DirectAccess client contains one or more management agents that initiate connections to management servers on the corporate network over either the infrastructure or intranet tunnel. If the user is not logged on, the management agents can initiate connections to management servers over the infrastructure tunnel. If the user is logged on, either the infrastructure or intranet tunnel can be used by the DirectAccess client to connect to the intranet. No special firewall rules are required for the DirectAccess client to initiate connections to management servers.
In the second scenario, management servers initiate connections to the DirectAccess client. Special Windows Firewall with Advanced Security firewall rules are required to enable management servers to initiate connections to Active Directory clients when the DirectAccess client is located behind a NAT device. These firewall rules must be configured for each desired protocol used to initiate the connection to the DirectAccess client, and then each of these rules must enable Edge Traversal.
The special firewall rules can be configured on each DirectAccess client individually. However, this manual approach does not scale. A better solution is to use Active Directory Group Policy to configure and distribute the new firewall rules for the desired protocols with Edge Traversal enabled.
While it is possible to configure these rules using the GPO created by the UAG SP1 RC DirectAccess wizard, these GPO settings are overwritten each time the wizard is run and the new GPO settings deployed. A viable alternative is to create a new GPO and a new Organizational Unit for the DirectAccess clients. The new DirectAccess client GPO can be linked to the new OU to apply the firewall rules required for management servers to initiate connections to the DirectAccess clients.
Note:
DirectAccess clients using the 6to4 IPv6 transition technology to connect to the DirectAccess server do not require special firewall rules with Edge Traversal. However, since you cannot predict when any specific DirectAccess client will use any specific IPv6 transition technology at any specific point in time, you should always enable Edge Traversal on your firewall rules.
To apply the GPO settings to the DirectAccess clients, we create an Organizational Unit that will contain the DirectAccess clients. The DirectAccess GPO is linked to the new OU. The first step is to create the DirectAccess OU and place the CLIENT1 into this OU.
The following steps are carried out on DC1.
  1. At the DC1 computer or virtual machine, open the Active Directory Users and Computers console.
  2. In the left pane of the Active Directory Users and Computers console, right click on corp.contoso.com, point to New and click on Organizational Unit.
  3. In the New Object – Organizational Unit dialog box, in the Name text box, enter DirectAccess Clients. Remove the checkmark from the Protect container from accidental deletion checkbox. (Note: disabling the OU from accidental deletion is not required for DirectAccess to work, it is done as a convenience for this lab). Click OK.
  4. In the left pane of the console, click the Computers node. In the right pane, right click CLIENT1 and click Move.
  5. In the Move dialog box, click on the DirectAccess Clients OU and click OK.

B.     Create the DirectAccess GPO and Link it to the DirectAccess Client Organizational Unit

DirectAccess clients that connect to the DirectAccess server using Teredo or IP-HTTPS need special Firewall Rules to support “manage out” connections. These firewall rules are created for each protocol needed to connect from the intranet to the DirectAccess client. By default, there are no Firewall Rules that allow outbound management from management servers on the intranet, so you must create rules to allow the required protocols. The best way to deploy these Firewall Rules is by configuring them in Group Policy so that the settings are automatically deployed. In this example we will create rules that allow management computers on the corpnet to connect to DirectAccess clients on the Internet using Ping, File Services and Remote Desktop Protocol. Perform the following steps on DC1.
  1. At the DC1 computer or virtual machine, open the Group Policy Management console.
  2. In the Group Policy Management console, expand Forest: corp.contoso.com and then expand Domains. Expand corp.contoso.com and click Group Policy Objects. Right click Group Policy Objects and click New.
  3. In the New GPO dialog box, in the Name text box, enter DirectAccess Clients GPO. Click OK.
  4. Expand the Group Policy Objects node and right click DirectAccess Clients GPO. Click Edit.
  5. In the Group Policy Management Editor console, navigate to Computer Configuration\Policies\Windows Settings\Windows Firewall with Advanced Security\Windows Firewall with Advanced Security – LDAP://CN=\Inbound Rules. Right click Inbound Rules in the left pane of the console and click New Rule.
  6. On the Rule Type page, select the Predefined option. From the drop down list, select Remote Desktop. Click Next.
  7. On the Predefined Rules page, click Next.
  8. On the Action page, click Finish.
  9. Double click the rule and click the Scope tab. On the Scope tab, in the Remote IP address section, select the These IP addresses option and click Add.
  10. In the IP Address dialog box, select the This IP address or subnet option and enter 2002:836b:2:8000::/49 and click OK. In the Remote Desktop TCP-In) Properties dialog box, click OK.
  11. Right click the Inbound Rules page and click New Rule.
  12. On the Rule Type page, select the Predefined option. Select the File and Printer Sharing option. Click Next.
  13. On the Predefined Rules page, click Next.
  14. On the Action page, click Finish.
  15. Right click the Remote Desktop (TCP-in) rule and click Properties. In the Remote Desktop (TCP-In) Properties dialog box, click the Advanced tab.
  16. In the Edge Traversal frame, select the Allow edge traversal from the drop down box. Click OK.
  17. Repeat steps 9, 10 and 16 for all the inbound Firewall Rules.
  18. Close the Group Policy Management Editor console.
  19. In the left pane of the Group Policy Management console, right click the DirectAccess Clients OU and click Link an Existing GPO.
  20. In the Select GPO dialog box, select the DirectAccess Clients GPO Group Policy Object and click OK.
  21. Expand the DirectAccess Clients OU, and click on the DirectAccess Clients GPO. In the Security Filtering section in the right pane, click on the Authenticated Users entry and click Remove. Click OK in the dialog box that asks if you want to remove the delegation privilege. In the Security Filtering section, click Add. In the Select User, Computer, or Group dialog box, enter Domain Computers in the Enter the object name to select text box and click Check Names. Click OK. (Note: the reason why we use Domain Computers for security filtering is that the infrastructure tunnel uses the computer account to perform NTLMv2 authentication. Authenticated Users will not work because users do not authenticate until after they log on, and we want DirectAccess client computers to be available for management even when the DirectAccess client computer has no logged on user).
  22. In the left pane of the console, right click the Default Domain Policy GPO and click Edit.
  23. In the Group Policy Management Editor console, navigate to Computer Configuration\Policies\Windows Settings\Windows Firewall with Advanced Security\Windows Firewall with Advanced Security – LDAP://CN=\Inbound Rules. In the right pane of the console, right click on the Inbound ICMPv6 Echo Request rule you created earlier and click Properties.
  24. In the Inbound IMVPv6 Echo Request Properties dialog box, click the Advanced tab. On the Advanced tab, in the Edge Traversal frame, select the Allow edge traversal option from the drop down box. We are enabling edge traversal for this existing rule, instead of creating a new rule for the DirectAccess Clients GPO to simplify configuration. Click OK.
  25. Close the Group Policy Management Editor. Close the Group Policy Management console. Close Active Directory Users and Computers.

C.      Refresh the DirectAccess Client Configuration and Enable Remote Desktop to CLIENT1

CLIENT1 needs to receive the firewall rules configured in Group Policy. That can be done by initiating a Group Policy refresh while CLIENT1 is running as a DirectAccess client on the Internet. In addition, CLIENT1 needs to be configured to allow Remote Desktop connections before it can accept RDC connections from a management server on the corpnet. Perform the following steps on CLIENT1.
  1. Move CLIENT1 to the Homenet subnet and then start CLIENT1. If CLIENT1 is already running and is not on the Homenet subnet, shut down CLIENT1 and move it to the Homenet subnet and then start CLIENT1.
  2. Confirm that CLIENT1 can connect to resources on the Corpnet subnet. Open an elevated command prompt on CLIENT1 and enter net view \\app1. You should see a list of shares. This indicates that CLIENT1 can authenticate and establish the intranet tunnel.
  3. In the command prompt window, enter gpupdate /force and press ENTER. Wait for the command to complete and you receive a confirmation. This delivers the new Group Policy settings to CLIENT1 that enables remote management.
  4. Click Start and then right click Computer. Click Remote Settings.
  5. Click Advanced system settings in the left pane of the System window.
  6. On the Remote tab, select the Allow connections only from computers running Remote Desktop with Network Level Authentication (more secure) option. Click OK. Close the System window.
  7. Click Start and type network in the search box. Click Network and Sharing Center.
  8. In the left pane of the Network and Sharing Center window, click the Change advanced sharing settings.
  9. In the Advanced sharing settings window, select the following options: Turn on network discovery, Turn on file and printer sharing and Turn on sharing so anyone with network access can read and write files in the Public folders. Click Save Changes (Note: these options are turned on to demonstrate file share access over the management tunnel, these are not to be considered to be networking best practices).

STEP 3: Test DirectAccess Client Remote Management

The DirectAccess client is now ready for remote management using the protocols configured in the Firewall Rules that allow for Edge Traversal. Perform the following procedures on DC1. The procedures are performed on DC1 because DC1 is the only computer that is on the management servers list and therefore the only one that can connect to CLIENT1 over the infrastructure tunnel. In addition, CLIENT1 will be restarted, but you will not log on, so that DC1 will be forced to use the infrastructure tunnel to connect to CLIENT1. The intranet tunnel is only available after the user logs on to the DirectAccess client computer.
  1. At the CLIENT1 computer or virtual machine, restart the operating system and do not log on. Wait for the Press CTRL+ALT+DELETE to log on screen to appear.
  2. *Move to the DC1 computer or virtual machine. Click Start and in the Search box, enter mstsc and press ENTER.
  3. In the Remote Desktop Connection application, enter CLIENT1 in the Computer text box and click Connect.
  4. In the Windows Security dialog box, enter the credentials for CORP\User1 and click OK.
  5.  The Terminal Services client session opens and you now see the desktop on CLIENT1. Click Start and enter wf.msc in the Search box and press ENTER.
  6. In the Windows Firewall with Advanced Security console, note that the Private Profile is Active.
  7. Expand the Monitoring node in the left pane of the console and expand Security Associations. Click on the Main Mode node. In the middle pane of the console, note that the 2nd Authentication Method is all User (NTLMv2). This indicates that only the infrastructure tunnel has been established to the DirectAccess server using the computer account of the DirectAccess client. This demonstrates that you were able to remotely manage CLIENT1 from DC1 over the infrastructure tunnel only.
  8. Minimize Terminal Services Client window.
  9. On DC1, open an elevated command prompt and in the command prompt window enter ping client1 and press ENTER. You should receive ping replies from the IPv6 address of CLIENT1.
  10.  Click Start and enter \\CLIENT1 in the Search box and press ENTER. You will see a list of shared resources on CLIENT1. Double click on the Users Share and then double click on the Public folder, and then double click on Public Pictures and double click on Sample Pictures. Double click on Desert. You should see a picture of a desert.
  11. Close all open Windows on CLIENT1 and DC1, including the terminal services client window.
  12. *Move to the APP1 computer. Open an elevated command prompt. In the command prompt window, enter net view \\client1 and press ENTER. You will receive an error and will not be able to connect. The reason for this is that APP1 is not a member of the management servers group, and therefore is unable to connect to CLIENT1 over the infrastructure tunnel.

STEP 4: Limit DirectAccess Clients to Only the Management Tunnel

While seamless access to the intranet for DirectAccess clients is a compelling use case for DirectAccess users, many IT organizations find the remote management capabilities even more useful. There may be some organizations that prefer that only the infrastructure tunnel be available so that DirectAccess client are always managed, but that users cannot access resources on the intranet. UAG SP1 RC includes a new feature that allows you to configure DirectAccess clients so that they only have access to the intranet tunnel.
In this step we will demonstrate how to configure DirectAccess clients so that they have access only to the intranet tunnel so that they can be always managed:
1.       *At UAG1, click Start and then click All Programs. Click Microsoft Forefront UAG and then click Forefront UAG Management. In the User Account Control dialog box, click Yes.
2.       In the Microsoft Forefront Unified Access Gateway Management console, click DirectAccess in the left pane of the console.
3.       In the right pane of the console, in the Step 1 Clients and GPOs section, click Edit.
4.       This starts the Clients and GPOs Configuration wizard. On the Deployment Model page, select the Enable remote management of DirectAccess client only option. Confirm that there is a checkmark in the Allow only services running under the client computer account to access infrastructure servers used for remote management checkbox. This option allows system services running in the context of the local computer account to connect to infrastructure servers through the infrastructure tunnel, but does not allow processes running in the context of the logged on user account to reach infrastructure servers. In addition, because the intranet tunnel cannot be established, the user cannot reach any other server on the intranet. Click Next.
5.        On the Client Domains page, click Next.
6.       On the Policy Management page, click Next.
7.       On the Client Groups page, click Finish.
8.       In the right pane of the Microsoft Forefront Unified Access Gateway Management console, click the Apply Policy button.
9.       On the Forefront UAG DirectAccess Configuration Review page, click Apply Now. Click OK in the DirectAccess Policy Configuration dialog box after you see it report Script run completed with no errors or warning.
10.   On the Forefront UAG DirectAccess Configuration Review page, click Close.
11.   Open and elevated command prompt. In the command prompt window, enter gpupdate /force and press ENTER. Close the command prompt window when the command completes.
12.   *Go to CLIENT1. Log on as CORP\User1.  Open an elevated command prompt. In the command prompt window, enter gpupdate /force and press ENTER. Notice that the gpupdate fails, as this command is run under the user context.
13.   In the command prompt window, enter net view \\dc1 and press ENTER. You will see that you get a System Error 53 occurred. The network path was not found. Again, the connection attempt fails because the command is sent in the context of the current user.
14.   In the command prompt window, enter ping dc1 and press ENTER. You will see four responses from DC1’s ISATAP assigned IPv6 address. This indicates that DNS queries are working correctly over the infrastructure tunnel. DNS queries are sent by the DNS client service in the context of the local computer account, so CLIENT1 was able to resolve the name of DC1. The ping request was send in the context of the local user account. This request was successful because ICMPv6 communications are not sent over the IPsec tunnel, therefore there is no authentication failure.
15.   *Return to DC1. Open and elevated command prompt. In the command prompt window enter net view \\client1 and press ENTER. Notice that you can still access CLIENT1 because DC1 connects to CLIENT1 through the infrastructure tunnel.
16.   On DC1, open Event Viewer from the Administrative Tools menu. Review the entries related to CLIENT1 starting up and receiving Group Policy settings and machine authentication. This further demonstrates that CLIENT1 was able to communicate with DC1 during the startup process because of the access provided over the infrastructure tunnel.

STEP 5: Snapshot the Configuration

This completes the UAG SP1 UAG SP1 RC DirectAccess remote management test lab. To save this configuration so that you can quickly return to a working UAG SP1 RC DirectAccess remote management configuration from which you can test other DirectAccess modular 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 UAG SP1RC DirectAccess Remote Management. If your lab uses physical computers, create disk images to save the DirectAccess test lab configuration

Additional Resources

For procedures to configure the Base Configuration test lab on which this document is based, see the Test Lab Guide: Base Configuration.
For procedures required to build this Test Lab Guide, see Test Lab Guide: Demonstrate UAG SP1 RC DirectAccess.
For the design and configuration of your pilot or production deployment of DirectAccess, see the Forefront UAG SP1 RC DirectAccess design guide and the Forefront UAG SP1 RC DirectAccess deployment guide.
For information about troubleshooting DirectAccess, see the DirectAccess Troubleshooting Guide.
For information on how to troubleshoot UAG DirectAccess in a Test Lab, see Test Lab Guide: Troubleshoot UAG DirectAccess.
For a comprehensive list of UAG DirectAccess Test Lab Guides, see Test Lab Guides.
For more information about DirectAccess, see the DirectAccess Getting Started Web page and the DirectAccess TechNet Web page.