Shannon Fritz, and up and comer in the world of UAG DirectAccess found a very interesting issue with the UAG Management Console and loading of the DirectAccess interface. It turns out that if the UAG server has a NetBIOS name that is longer than the allowed 15 characters, the DirectAccess configuration interface won’t open.

Here’s a screenshot from the TechNet forums of what Shannon saw:

The Product Group is now aware of this issue, and we’ll make plans to update documentation to warn against using NetBIOS names longer than 15 characters.

You should also check out Shannon’s blog over at:

http://blog.concurrency.com/infrastructure/uag-cannot-load-the-directaccess-view-0

for more information on what he found.

HTH,

Tom

Tom Shinder
tomsh@microsoft.com
Knowledge Engineer, Microsoft DAIP iX/Forefront iX 
UAG Direct Access/Anywhere Access Group (AAG)
The “Edge Man” blog (DA all the time): http://blogs.technet.com/tomshinder/default.aspx
Follow me on Twitter: http://twitter.com/tshinder
Facebook: http://www.facebook.com/tshinder

Hey folks – since the TLGs are typically put up only in the download center, it makes discoverability of some of the cool content inside of them hard when it comes to search engines. Therefore, I’m going to post the full text of the TLGs on the Edge Man blog. However, I recommend that you download the Word .doc version of the TLGs when you actually put together your Test Lab using the Test Lab Guides.

For a downloadable version of the Test Lab Guide – Demonstrate UAG SP1 RC DirectAccess with Secure Socket Tunneling Protocol (SSTP) and Remote Desktop Gateway (RDG) check out:

http://go.microsoft.com/fwlink/?LinkId=206505

==================================================

Introduction

DirectAccess is a new feature in the Windows 7 and Windows Server 2008 R2 operating systems that gives users the experience of being seamlessly connected to their intranet any time they have Internet access. With DirectAccess enabled, requests for intranet resources (such as e-mail servers, shared folders, or intranet Web sites) are securely directed to the intranet, without requiring users to connect to a VPN. DirectAccess provides increased productivity for a mobile workforce by offering the same connectivity experience both inside and outside the office.

Forefront Unified Access Gateway (UAG) SP1 RC extends the value of the Windows DirectAccess solution by adding features that meet the requirements of many enterprise deployments:

• Support for arrays of up to 8 UAG DirectAccess servers where configuration is done once on an array master and is automatically deployed to all other members of the array
• Support for Network Load Balancing, which enables the UAG DirectAccess SP1 RC array to be highly available without requiring the use of an external hardware load balancer
• Support for IPv4-only networks, network segments, or server or application resources with the help of NAT64/DNS64 IPv6/IPv4 transition technologies.

To learn more about UAG DirectAccess, see the following resources:

· Forefront UAG DirectAccess Design Guide

· Forefront UAG DirectAccess Deployment Guide

UAG SP1 RC supports hosting multiple roles on a single UAG server or UAG array. For example, you might want to host both the DirectAccess server and SSTP VPN server roles on the same server or array. Windows 7 clients that are configured DirectAccess clients will automatically use DirectAccess to connect to intranet resources. Windows 7 clients that are not domain members, or who are not configured as DirectAccess clients can use SSTP to connect to the intranet using a network level VPN connection. Windows 7, Windows Vista and Windows XP clients can connect to Remote Desktop and RemoteApps through a UAG server that is configured to host the Remote Desktop Gateway role. In this guide, we demonstrate how a UAG server can support the combined, DirectAccess, SSTP and Remote Desktop Gateway server roles.

In this guide

This guide provides step-by-step instructions for configuring UAG DirectAccess SP1 RC with SSTP and Remote Desktop Gateway in a test lab so that you can see how it works. You will set up and deploy UAG DirectAccess SP1 RC using five server computers, two client computers, Windows Server 2008 R2 Enterprise edition, and Windows 7 Ultimate Edition. The Test Lab simulates intranet, Internet, and a home networks, and demonstrates a co-located Forefront UAG DirectAccess and SSTP VPN server role deployment. The starting point for this paper is the Test Lab Guide: Demonstrate UAG SP1 RC DirectAccess .

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, please see the Forefront UAG DirectAccess design guide and the Forefront UAG DirectAccess deployment guide

Overview of the test lab scenario

In this test lab scenario, Forefront UAG DirectAccess SP1 RC 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, SSTP VPN and Remote Desktop Gateway 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 SP2 (APP3) that is configured as an IPv4 only web and file server. This server is used to highlight the UAG’s NAT64/DNS64 capabilities.
• One standalone server running Windows Server 2008 R2 Enterprise Edition (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 domain member client computer running Windows 7 Ultimate Edition (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 subnet by NAT1.
• The Internet subnet (131.107.0.0/24).
• The Corpnet subnet (10.0.0.0/24) separated from the Internet by the Forefront UAG 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 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.
• Five computers or virtual machines that meet the minimum hardware requirements for Windows Server 2008 R2 Enterprise; two of these computers has two network adapters installed (UAG1).
• 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 (NAT1).
• The product disc or a downloaded version of Microsoft Forefront Unified Access Gateway (UAG) SP1 RC.

This Test Lab Guide demonstrates a combined UAG SP1 RC DirectAccess and SSTP deployment.

Important

The following instructions are 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 clearly show the desired functionality. It is important to remember that 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 test lab configuration to a pilot or production deployment can result in configuration or functionality issues. To ensure proper configuration and operation of UAG DirectAccess and SSTP, please refer to the Forefront UAG DirectAccess Deployment Guide for the steps to configure the UAG DirectAccess server and supporting infrastructure servers.

Steps for configuring the test lab

The following sections describe how to configure UAG1 as a DirectAccess, SSTP VPN and Remote Desktop Gateway server. After UAG1 is configured, this guide provides steps for demonstrating the DirectAccess, SSTP VPN and Remote Desktop Server functionality for CLIENT1 when it is connected to the Homenet subnet.

Note

You must be logged on as a member of the Domain Admins group or 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. For all tasks described in this document you can use the CONTOSO\User1 account created when you went through the steps in the UAG DirectAccess Test Lab Guide: Demonstrate UAG SP1 RC DirectAccess.

The following procedures are performed to enable and allow you to test the UAG SP1 RC DCA:

· Step 1: Complete the Demonstrate UAG SP1 RC DirectAccess with SSTP Test Lab Guide – The first step is to complete all the steps in the Test Lab Guide: Demonstrate Forefront UAG SP1 RC DirectAccess with Secure Socket Tunneling Protocol (SSTP).

· Step 2: Install and Configure the RDS Session Host on APP1. In order to test UAG1 publishing of Remote Desktops and RemoteApps we need an RDS Session Host server on the corpnet subnet. In this step you will install the RDS Session Host Role on APP1.

· Step 3: Generate the RemoteApp Configuration File on APP1. You will publish a RemoteApp on UAG1. In order to publish the RemoteApp, you need to generate a RemoteApp configuration file on APP1. In this step you will generate the RemoteApp configuration file and copy it to UAG1.

· Step 4: Publish Remote Desktops on UAG1. To publish Remote Desktops you need to add the Remote Desktops Application to the portal. In this step you will add the Remote Desktop applications to the UAG1 portal page.

· Step 5: Publish RemoteApps on UAG1. To publish RemoteApps you need to add the RemoteApps application to the portal. In this step you will add the RemoteApps application to the portal page.

· Step 6: Test DirectAccess, SSTP and Remote Desktop Connectivity from CLIENT1. After the portal configuration is completed, you can test connectivity to resources through the UAG portal. In this step you will confirm DirectAccess and SSTP connectivity, and test Remote Desktop and RemoteApp connectivity through the portal.

· Step 7: Snapshot the configuration. After completing the Test Lab, take a snapshot of the working UAG DirectAccess, SSTP and Remote Desktop Gateway Test Lab so that you can return to it later to test additional scenarios.

Note

You will notice that there are several steps that begin with an asterisk (*). The * indicates that the step requires that you move to a computer or virtual machine that is different from the computer or virtual machine you were at when you completed the previous step.

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

The first step is to complete all the steps in the Test Lab Guide: Demonstrate Forefront UAG SP1 RC DirectAccess with Secure Socket Tunneling Protocol (SSTP). 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 DirectAccess with SSTP and RDG. If you have already completed the steps in that Test Lab Guide and saved a snapshot or disk image of the Test Lab, you can restore the snapshot or image and begin with the next step.

STEP 2: Install and Configure the RDS Session Host on APP1

In order to test UAG1 publishing of Remote Desktops and RemoteApps we need an RDS Session Host server on the corpnet subnet. In this step you will install and configure the RDS Session Host Role on APP1.

Install the RDS Session Host on APP1:

1. At the APP1 computer or virtual machine, log on as CORP\User1. Open the Server Manager. In the left pane of the Server Manager console, click the Roles node. In the right pane of the console, click Add Roles.
2. On the Before You Begin page, click Next.
3. On the Select Server Roles page, select Remote Desktop Services and click Next.
4. On the Introduction to Remote Desktop Services page, click Next.
5. On the Role Services page, select Remote Desktop Session Host and click Next.
6. On the Application Compatibility page, click Next.
7. On the Authentication Method page, select Require Network Level Authentication and click Next.
8. On the Licensing Mode page, select Configure later and click Next.
9. On the User Groups page, confirm Administrators is in the User or User Groups list and click Next.
10. On the Client Experience page, put a checkmark in the Audio and video playback, Audio recording redirection, and Desktop composition (provides the user interface elements of Windows Aero) checkboxes and click Next.
11. On the Confirmation page, click Install. When you see the message Restart Pending, click Close. In the Add Roles Wizard dialog box, click Yes. The machine will restart to complete installation. Log on as CORP\User1. After you log on the installation will continue. On the Results page, click Close.

Configure the RDS Session Host on APP1:

1. Click Start and point to Administrative Tools. Point to Remote Desktop Services and click Remote Desktop Session Host Configuration.
2. In the Remote Desktop Session Host Configuration console, in the right pane of the console, right click RDP-Tcp and click Properties.
3. In the RDP-Tcp Properties dialog box, on the General tab, click the Select button. In the Windows Security dialog box, click APP1.corp.contoso.com and click OK. In the RDP-Tcp Properties dialog box, click OK.
4. Close the Remote Desktop Session Host Configuration console.

STEP 3: Generate the RemoteApp Configuration File on APP1

You will publish a RemoteApp on UAG1. In order to publish the RemoteApp, you need to generate a RemoteApp configuration file on APP1. In this step you will generate the RemoteApp configuration file and copy it to UAG1.

1. Click Start and point to Administrative Tools. Point to Remote Desktop Services and click RemoteApp Manager.
2. In the RemoteApp Manager console, in the Actions pane, click Add RemoteApp Program.
3. On the Welcome to the RemoteApp Wizard page, click Next.
4. On the Choose programs to add to the RemoteApp Programs list page, select WordPad and click Next.
5. On the Review Settings page, click Finish.
6. In the Actions pane, click Export RemoteApp Settings.
7. In the Export RemoteApp Settings dialog box, select Export the RemoteApp Programs list and settings to a file and click OK.
8. In the Save As dialog box, in the File name text box, enter WordPadRemoteApp and save the file to the C:\Files folder. In the RemoteApp Manager dialog box click OK. Close the RemoteApp Manager console.
9. *Log on to the UAG1 computer or virtual machine as CORP\User1. Click Start and in the Search box enter \\APP1\Files and press ENTER. Copy the WordPadRemoteApp.tspub file to the desktop on UAG1. Close the Windows Explorer window.

STEP 4: Publish Remote Desktops on UAG1

To publish Remote Desktops you need to add the Remote Desktops Application to the portal. In this step you will add the Remote Desktop application to the UAG1 portal page.

1. At the UAG1 computer or virtual machine, 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 left pane of the Microsoft forefront Unified Access Gateway Management console, expand HTTPS Connections and click on HTTPSTrunk. In the right pane of the console, in the Applications section, click Add.
3. On the Welcome to the Add Application Wizard page, click Next.
4. On the Step 1 – Select Application page, select the Terminal Services (TS)/Remote Desktop Services (RDS) option. From the drop down box, select Remote Desktop (Predefined). Click Next.
5. On the Step 2 – Configuration Application page, in the Application name text box, enter Predefined Remote Desktop. Click Next.
6. On the Step 3 – Select Endpoint Policies page, from the Access policy drop down list, select Always. We select Always in this lab because the default policy requires that the client system have antivirus software installed in order to launch the application. CLIENT1 does not have antivirus software installed, so we need to select the Always option for the Test lab. Click Next.
7. On the Step 4 – Configure Server Settings page, in the UAG SP1 RC Session Host (IP address or FQDN) text box, enter app1.corp.contoso.com. Click Next.
8. On the Step 5 – Configure Client Settings page, accept the default settings and click Next.
9. On the Step 6 – Portal Link page, accept the default settings and click Next.
10. On the Step 7 – Authorization page, accept the default settings and click Next.
11. On the Completing the Add Application Wizard page, click Finish.

STEP 5: Publish RemoteApps on UAG1

To publish RemoteApps you need to add the RemoteApps application to the portal. In this step you will add the RemoteApps application to the portal page.

1. In the right pane of the Microsoft Forefront Unified Access Gateway Management console, in the Applications section, click the Add button.
2. On the Welcome to the Add Application Wizard page, click Next.
3. On the Step 1 – Select Application page, select the Terminal Services (TS)/Remote Desktop Services (RDS) option. From the drop down box, select RemoteApp. Click Next.
4. On the Step 2 – Configuration Application page, in the Application name text box, enter Remote WordPad. Click Next.
5. On the Step 3 – Select Endpoint Policies page, from the Access policy drop down box, select Always. Click Next.
6. On the Step 4 – Import RemoteApp Programs page, click the Browse button. Navigate to the Desktop and open the WordPadRemoteApp.tspub file. In the UAG SP1 RC Session Host (IP address or FQDN) text box, confirm that it says APP1.corp.contoso.com. Click Next.
7. On the Step 5 – Select Publishing Type page, in the Available RemoteApps section, select
   WordPad and click the right-pointing double-arrow. This moves the WordPad application to the Published RemoteApps section. Click Next.
8. On the Step – 6 Configure Client Settings page, accept the default settings and click Next.
9. On the Step – 7 Portal Link page, accept the default settings and click Next.
10. On the Step 8 – Authorization page, accept the default settings and click Next.
11. On the Completing the Add Application Wizard page, click Finish.
12. Click the File menu and click Activate.
13. On the Activate Configuration page, click the Activate button.
14. Click Finish on the Activation completed successfully page.

STEP 6: Test DirectAccess, SSTP and Remote Desktop Connectivity from CLIENT1

After the portal configuration is completed, you can test connectivity to resources through the UAG portal. In this step you will confirm DirectAccess and SSTP connectivity, and then test Remote Desktop and RemoteApp connectivity through the portal.

Confirm DirectAccess Connectivity to the Corpnet subnet:

1. *Move the CLIENT1 computer or virtual machine to the Homenet subnet. Log on to CLIENT1 as CORP\User1.
2. Open an elevated command prompt. In the command prompt window, enter ping dc1 and press ENTER. You should see four responses from DC1. This indicates that the IPv6 transition technology that connects CLIENT1 to UAG1 is working correctly.
3. In the command prompt window, enter net view \\dc1 and press ENTER. You should see a list of shares on DC1. This indicates that the infrastructure tunnel is working correctly.
4. In the command prompt window, enter net view \\app1 and press ENTER. You should see a list of shares on APP1. This indicates that the intranet tunnel is working correctly.
5. You have demonstrated that DirectAccess connectivity is successful over both the intranet and infrastructure tunnels. Close the command prompt window.

Confirm SSTP Connectivity to the Corpnet subnet:

1. On the CLIENT1 computer or virtual machine, open Internet Explorer. In Internet Explorer, in the address bar, enter https://uag1.contoso.com and press ENTER. Click the information bar that informs you that the Website wants to run the following add-on: Microsoft Remote Desktop Services Web Access Con…” from “Microsoft Corporation:… click Run Add-on. In the Internet Explorer – Security Warning dialog box that asks Do you want to run this ActiveX control? click Run.
2. Enter the username and password for CORP\User1 in the Application and Network Access Portal page. If the page times out and you see a message that says The logon process cannot be completed. User credentials were not submitted within the time limit, click the Back link and log on as CORP\User1.
3. In the right pane of the portal page, click SSTP VPN. After you see the balloon in the system notification area that says that network connectivity is started, open an elevated command prompt.
4. In the command prompt window, enter ping APP3 and press ENTER. You should see four responses from the IPv4 address of APP3. This indicates that DirectAccess has been disabled and the IPv4 SSTP connection to the Corpnet subnet is active. Close the elevated command prompt window.
5. Right click the Remote Network Access icon in the system notification area and click Disconnect remote Network Access command. You will see a balloon in the system notification area that says that the connection is ended.

Confirm Remote Desktop Connectivity to the Corpnet subnet:

1. In the right pane of the portal page, click the Predefined Remote Desktop link. If the Message from webpage dialog box appears, click OK. If the Information bar appears saying that the website wants to run Remote Desktop Services ActiveX Client, click the information bar and click Run Add-on. In the Internet Explorer – Security Warning dialog box, click Run.
2. Click the Predefined Remote Desktop link in the right pane of the portal page. In the Remote Desktop Connection dialog box, click Connect. In the Windows Security dialog box, enter credentials for CORP\User1. .
3. The Desktop now appears in the RDC client window. Close the RDC window. In the Remote Desktop Connection dialog box, click OK.

Confirm RemoteApp Connectivity to the Corpnet subnet:

1. In the right pane of the portal, click the WordPad link.
2. In the RemoteApp dialog box, click Connect.
3. In the Document – WordPad window, enter This is a RemoteApp document. Click the Save icon in the Title Bar, and save the document to the desktop with the name My RemoteApp Doc. Close the WordPad window.
4. Click the Log Off button in the upper right corner of the portal page. Close Internet Explorer.

STEP 7: Snapshot the Configuration

This completes the UAG SP1 RC DirectAccess with SSTP and Remote Desktop Gateway test lab. To save this configuration so that you can quickly return to a working UAG SP1 RC DirectAccess with SSTP and Remote Desktop Gateway 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 TLG UAG DirectAccess SP1RC SSTP+RDG. If your lab uses physical computers, create disk images to save the DirectAccess test lab configuration.

Additional Resources

For more information on UAG and SSTP, see Setting up Remote Network Access.

For more information on UAG and Remote Desktop Gateway, see Remote Desktop Services publishing solution guide.

For procedures to configure the Base Configuration test lab on which this document is based, see the Test Lab Guide: Base Configuration.

For procedures to configure UAG SP1 RC DirectAccess on which this document is based, see the Test Lab Guide: Demonstrate Forefront UAG SP1 RC DirectAccess.

For procedures to configure UAG SP1 RC DirectAccess on which this document is based, see Test Lab Guide: Demonstrate Forefront UAG SP1 RC DirectAccess with Secure Socket Tunneling Protocol (SSTP)

For a comprehensive list of Test Lab Guides, please see Test Lab Guides.

For a list of UAG DirectAccess related Test Lab Guides, please see UAG DirectAccess Test Lab Guide Portal Page

For the design and configuration of your pilot or production deployment of DirectAccess, see the Forefront UAG DirectAccess design guide and the Forefront UAG DirectAccess deployment guide.

For information about troubleshooting DirectAccess, see the DirectAccess Troubleshooting Guide.

For information on troubleshooting UAG DirectAccess in a Test Lab, see Test Lab Guide: Troubleshooting UAG DirectAccess.

For more information about DirectAccess, see the DirectAccess Getting Started Web page and the DirectAccess TechNet Web page.

==================================================

Tom Shinder
tomsh@microsoft.com
Knowledge Engineer, Microsoft DAIP iX/Forefront iX 
UAG Direct Access/Anywhere Access Group (AAG)
The “Edge Man” blog (DA all the time): http://blogs.technet.com/tomshinder/default.aspx
Follow me on Twitter: http://twitter.com/tshinder
Facebook: http://www.facebook.com/tshinder

OK folks, this is the last TLG for a week or two. Yes, I still have a couple of important ones that need to be done (TLGs that demonstrate how UAG DirectAccess works with BranchCache [very cool!] and  a Pilot Deployment Test Lab Guide where the UAG DirectAccess server belongs to a different forest than the computers and users).

So what is this Test Lab Guide? Nothing other than the Test Lab Guide: Demonstrate UAG SP1 RC DirectAccess with Secure Socket Tunneling Protocol (SSTP) and Remote Desktop Gateway (RDG). For a while I wondered if it was worth the effort to do this one, because I don’t know of many people who are using the RDG feature included with the UAG server. But then I thought about it and realized that maybe no one is using the RDG feature because no one is writing about it   For this reason (and also because I wanted to see if it actually worked), I decided to move forward on this Test Lab Guide.

The good news is that it works! Indeed, the combined DirectAccess, SSTP and Remote Desktop Gateway deployment works a treat. I don’t know why I didn’t think of this earlier, not only for writing a Test Lab Guide, but for deploying myself in my home office (actually, my wife Deb Shinder did the live deployment after she tested the Test Lab Guide for me).

The RDG setup also supports down-level clients such as XP and Vista, which helps in those occasional situations when I don’t have a worked laptop and have to borrow one (like when I’m on the road and my laptop dies and I get a “loaner” that is running XP SP2). Accessing the Remote Desktop works great, and also the RemoteApp feature is even more useful – since I can use that together with my DirectAccess client configuration when I need access to an app that’s not installed on my laptop.

I hope you like this Test Lab Guide and find it useful. As always, if you have any questions or problems with this Test Lab Guide, let me know! Send me a note to the email address in my sig line and I’ll get back to you as soon as I can.

HTH,

Tom

Tom Shinder
tomsh@microsoft.com
Knowledge Engineer, Microsoft DAIP iX/Forefront iX 
UAG Direct Access/Anywhere Access Group (AAG)
The “Edge Man” blog (DA all the time): http://blogs.technet.com/tomshinder/default.aspx
Follow me on Twitter: http://twitter.com/tshinder
Facebook: http://www.facebook.com/tshinder

Hey folks – since the TLGs are typically put up only in the download center, it makes discoverability of some of the cool content inside of them hard when it comes to search engines. Therefore, I’m going to post the full text of the TLGs on the Edge Man blog. However, I recommend that you download the Word .doc version of the TLGs when you actually put together your Test Lab using the Test Lab Guides.

For a downloadable version of the Test Lab Guide – Demonstrate UAG SP1 RC DirectAccess with SSTP check out:

http://go.microsoft.com/fwlink/?LinkId=206283

==================================================

Introduction

DirectAccess is a new feature in the Windows 7 and Windows Server 2008 R2 operating systems that gives users the experience of being seamlessly connected to their intranet any time they have Internet access. With DirectAccess enabled, requests for intranet resources (such as e-mail servers, shared folders, or intranet Web sites) are securely directed to the intranet, without requiring users to connect to a VPN. DirectAccess provides increased productivity for a mobile workforce by offering the same connectivity experience both inside and outside the office.

Forefront Unified Access Gateway (UAG) SP1 RC extends the value of the Windows DirectAccess solution by adding features that meet the requirements of many enterprise deployments:

• Support for arrays of up to 8 UAG DirectAccess servers where configuration is done once on an array master and is automatically deployed to all other members of the array
• Support for Network Load Balancing, which enables the UAG DirectAccess SP1 RC array to be highly available without requiring the use of an external hardware load balancer
• Support for IPv4-only networks, network segments, or server or application resources with the help of NAT64/DNS64 IPv6/IPv4 transition technologies.

To learn more about UAG DirectAccess, see the following resources:

· Forefront UAG DirectAccess Design Guide

· Forefront UAG DirectAccess Deployment Guide

UAG SP1 RC supports hosting multiple roles on a single UAG server or UAG array. For example, you might want to host both the DirectAccess server and SSTP VPN server roles on the same server or array. Windows 7 clients that are configured DirectAccess clients will automatically use DirectAccess to connect to intranet resources. Windows 7 clients that are not domain members, or who are not configured as DirectAccess clients can use SSTP to connect to the intranet using a network level VPN connection. In addition, DirectAccess clients hosting applications that are not compatible with DirectAccess can connect to the SSTP VPN when they need to use the non-compatible application.

Note

Non-Windows 7 operating systems (such as Windows Vista, Windows XP) can use the UAG Network Connector to connect to the intranet using a network level SSL VPN connection. However, you cannot host the Network Connector application on the same server or array that is also hosting DirectAccess. To support network level VPN connectivity for non-Windows 7 clients, you will need to deploy a second UAG server or array.

In this guide

This guide provides step-by-step instructions for configuring UAG DirectAccess SP1 RC with SSTP in a test lab so that you can see how it works. You will set up and deploy UAG DirectAccess SP1 RC using five server computers, two client computers, Windows Server 2008 R2 Enterprise edition, and Windows 7 Ultimate Edition. The Test Lab simulates intranet, Internet, and a home networks, and demonstrates a co-located Forefront UAG DirectAccess and SSTP VPN server role deployment. The starting point for this paper is the Test Lab Guide: Demonstrate UAG SP1 RC DirectAccess .

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, please see the Forefront UAG DirectAccess design guide and the Forefront UAG DirectAccess deployment guide

Overview of the test lab scenario

In this test lab scenario, Forefront UAG DirectAccess SP1 RC 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 and SSTP VPN 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 SP2 (APP3) that is configured as an IPv4 only web and file server. This server is used to highlight the UAG’s NAT64/DNS64 capabilities.
• One standalone server running Windows Server 2008 R2 Enterprise Edition (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 domain member client computer running Windows 7 Ultimate Edition (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 subnet by NAT1.
• The Internet subnet (131.107.0.0/24).
• The Corpnet subnet (10.0.0.0/24) separated from the Internet by the Forefront UAG 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 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.
• Five computers or virtual machines that meet the minimum hardware requirements for Windows Server 2008 R2 Enterprise; two 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 (NAT1).
• The product disc or a downloaded version of Microsoft Forefront Unified Access Gateway (UAG) SP1 RC.

This Test Lab Guide demonstrates a combined UAG SP1 RC DirectAccess and SSTP deployment.

Important

The following instructions are 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 clearly show the desired functionality. It is important to remember that 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 test lab configuration to a pilot or production deployment can result in configuration or functionality issues. To ensure proper configuration and operation of UAG DirectAccess and SSTP, please refer to the Forefront UAG DirectAccess Deployment Guide for the steps to configure the UAG DirectAccess server and supporting infrastructure servers.

Steps for configuring the test lab

The following sections describe how to configure UAG1 as both a DirectAccess and SSTP VPN server. After UAG1 is configured, this guide provides steps for demonstrating the DirectAccess and SSTP VPN functionality for CLIENT1 when it is connected to the Homenet subnet.

Note

You must be logged on as a member of the Domain Admins group or 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. For all tasks described in this document you can use the CONTOSO\User1 account created when you went through the steps in the UAG DirectAccess Test Lab Guide: Demonstrate UAG SP1 RC DirectAccess.

The following procedures are performed to enable and allow you to test the UAG SP1 RC DCA:

· 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.

· Step 2: Create the HTTPS Trunk. UAG uses the concept of “trunk” as the primary listener for incoming SSL connections to a UAG portal page. In this step you will create an SSL Trunk that can be used to create a portal page that includes the SSTP VPN application.

· Step 3: Configure the Remote Network Access Settings. The SSTP application requires configuration of a number of settings before it can be deployed. In this step you will configure these settings.

· Step 4: Add the SSTP Remote Network Access Application to the Trunk. In order for users to access the SSTP VPN application, that application must be added to a trunk. In this step you will add the SSTP application to the HTTPS trunk.

· Step 5: Activate the Configuration and View Activation in the Activation Monitor. You need to activate the configuration after adding the SSTP VPN application to the trunk. In this step you will activate the configuration and view the activation process in the Activation Monitor.

· Step 6: Test DirectAccess and SSTP Connectivity. After activation is complete, you are ready to test both DirectAccess and SSTP connectivity. In this step you will confirm DirectAccess connectivity and then start an SSTP VPN connection through the portal.

· Step 7: Snapshot the configuration. After completing the Test Lab, take a snapshot of the working UAG DirectAccess with SSTP Test Lab so that you can return to it later to test additional scenarios.

Note

You will notice that there are several steps that begin with an asterisk (*). The * indicates that the step requires that you move to a computer or virtual machine that is different from the computer or virtual machine you were at when you completed the previous step.

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 the UAG DirectAccess DCA. If you have already completed the steps in that Test Lab Guide and saved a snapshot or disk image of the Test Lab, you can restore the snapshot or image and begin with the next step.

STEP 2: Create the HTTPS Trunk

UAG uses the concept of “trunk” as the primary listener for incoming SSL connections to a UAG portal page. In this step you will create an SSL Trunk that can be used to create a portal page that includes the SSTP VPN application.

1. At the UAG1 computer or virtual machine, log on as CORP\User1. Click Start and then click All Programs. Click Microsoft Forefront UAG and then click Forefront UAG Management.
2. In the right pane of the console, click Allow remote access to the UAG server via an HTTPS trunk.
3. On the Welcome to the Create Trunk Wizard page, click Next.
4. On the Step 1 – Select Trunk Type page, select the Portal trunk option and click Next.
5. On the Step 2 – Setting the Trunk page, in the Trunk name text box, enter HTTPSTrunk. In the Public host name text box, enter uag1.contoso.com. In the External Web Site section, confirm that the IP address is 131.107.0.2. Confirm that the HTTP port is 80 and confirm that the HTTPS port is 443. Click Next.
6. On the Step 3 – Authentication page, click the Add button. In the Authentication and Authorization Servers dialog box, click the Add button.
7. In the Add Authentication Server dialog box, in the Server type drop down list, confirm that Active Directory is selected. In the Server Name text box, enter dc1.corp.contoso.com. In the Connection Settings section, select Use local Active Directory forest authentication. In the Search Settings section, click the ellipses (…) button. In the Search Root (Base DN) dialog box, confirm that the Select Base DN entry is CN=Users,DC=corp,DC=contoso,DC=com. Click OK. In the Server access section, in the User (domain\user) text box, enter CORP\User1. In the Password text box, enter User1’s password. Click OK.
8. In the Authentication and Authorization Servers dialog box, click Select. On the Step 3 – Authentication page, confirm that User selects from a server list is selected and that there is a checkmark in the Show server names checkbox. Click Next.
9. On the Step 4 – Certificate page, confirm that uag1.contoso.com appears in the Server certificate drop down list. Click Next.
10. On the Step – 5 Endpoint Security page, select the Use Forefront UAG access policies option and click Next.
11. On the Step 6 – Endpoint Policies page, in the Nonprivileged access policy dropdown box, select Always. Note that we select Always in this Test Lab because the default access policy requires that clients have antivirus software installed. In this Test Lab CLIENT1 does not have antivirus software installed so we need to change from the default Nonprivileged access policy to one that will allow a system without antivirus software to access the portal. Click Next.
12. On the Completing the Create Trunk Wizard page, click Finish.
13. In the Trunk Configuration section, click the Configure button. On the Advanced Trunk Configuration [HTTPSTrunk] page, click the Session tab. In the Default Sessions Settings section, in the Inactive session timeout (seconds) text box, enter 1800. In the Trigger automatic logoff after text box, enter 1440. Click OK.
14. Click the File menu and click Activate. On the Activate Configuration page, click the Activate button. Click Finish when the activation completes.

STEP 3: Configure the Remote Network Access Settings

The SSTP application requires configuration of a number of settings before it can be deployed. In this step you will configure these settings.

1. In the Microsoft Forefront Unified Access Gateway Management console, click the Admin menu and point to Remote Network Access. Click on SSL Network Tunneling (SSTP)… .
2. In the SSL Network Tunneling Configuration dialog box, on the General tab, put a checkmark in the Enable remote client VPN access checkbox. In the Maximum VPN Client connections text box, enter 10. In the SSL Tunneling VPN Trunk section, from the Trunk drop down list, select HTTPSTrunk. Confirm that is says uag1.contoso.com in the Public host name box.
3. Click the Protocols tab. Confirm that there is a checkmark in the Secure Socket Tunneling Protocol (SSTP). Note that while there are checkboxes for Point-to-Point Tunneling Protocol (PPTP) and Layer Two Tunneling Protocol (L2TP)/IPsec, they are not functional. UAG SP1 does not support PPTP or L2TP/IPsec network level VPN protocols.
4. Click the IP Address Assignment tab. Select the Assign address using DHCP. Note that you can use this option only when you have a single server deployment. If you have a UAG array and want to enable SSTP support, you will need to assign a static address pool to each of the servers in the array and the addresses used in each pool must be different on each server.
5. Click on the User Groups tab. On this tab you can limit SSTP access on a per group basis to selected assets on the intranet. In this test lab we will not enable this feature. Click OK.

STEP 4: Add the SSTP Remote Network Access Application to the Trunk

In order for users to access the SSTP VPN application, that application must be added to a trunk. In this step you will add the SSTP application to the HTTPS trunk.

1. In the right pane of the console, in the Applications section, click the Add button.
2. On the Welcome to the Add Application Wizard page, click Next.
3. On the Step – 1 page, select the Client/server and legacy option. From the drop down list, select Remote Network Access. Click Next.
4. On the Step 2 – Configure Application page, in the Application name text box, enter SSTP VPN. Click Next.
5. On the Step 3 – Select Endpoint Policies page, in the Access policy drop down box, select Always. The reason we select this option in the Test Lab is that the default setting requires the client to have antivirus software installed, and in this Test Lab CLIENT1 does not have antivirus software installed. Click Next.
6. On the Step 4 – Configure Server Settings page, make no changes and accept the default values. Click Next.
7. On the Step 5 – Portal Link page, make no changes and click Next.
8. On the Step 6 – Authorization page, confirm that there is a checkmark in the Authorize all users checkbox and click Next.
9. On the Completing the Add Application Wizard page, click Finish.

STEP 5: Activate the Configuration and View Activation in the Activation Monitor

You need to activate the configuration after adding the SSTP VPN application to the trunk. In this step you will activate the configuration and view the activation process in the Activation Monitor.

1. Click Start and then click All Programs. Click Microsoft Forefront UAG and then click Forefront UAG Activation Monitor. In the Use Account Control dialog box, click Yes. It may take a minute or two for the Activation Monitor to open. Maximize the Activation Monitor after it opens, and then minimize the window.
2. In the Microsoft Forefront Unified Access Gateway Management console, click the File menu and then click Activate. In the Activate Configuration dialog box, click the Activate button.
3. Maximize the Forefront Unified Access Gateway Activation Monitor. Click the UAG1 node in the left pane of the console. Notice in the right pane that it tells you the time when the activation started. Click the Options button. In the Autorefresh Interval (sec) text box, enter 10 and then click OK.
4. When the activation completes, scroll through the output in the right pane. This provides you information about what happened during the activation process. At the bottom of the output, you should see Activation completed successfully. Minimize the Forefront Unified Access Gateway Activation Monitor console.
5. In the Activate Configuration dialog box, click Finish.

STEP 6: Test DirectAccess and SSTP Connectivity

After activation is complete, you are ready to test both DirectAccess and SSTP connectivity. In this step you will confirm DirectAccess connectivity and then start an SSTP VPN connection through the portal.

1. *Move the CLIENT1 computer to Homenet subnet and then log on as CORP\User1.
2. Open an elevated command prompt. In the command prompt window enter ipconfig and press ENTER. You should see an IPv6 address assigned to Tunnel adapter Teredo Tunneling Pseudo-Interface. In the command prompt window, enter ping dc1 and press ENTER. You should see four responses from the ISATAP address assigned to DC1. In the command prompt window, enter net view \\dc1 and press ENTER. You should see a list of shares on DC1. This indicates that the infrastructure tunnel is working properly over DirectAccess.
3. In the command prompt window, enter ping app1 and press ENTER. You should see four responses from the ISATAP address assigned to APP1. This indicates that name resolution is working correctly. At the command prompt window, enter net view \\app1 and press ENTER. You should see a list of shares on APP1. This indicates that the intranet tunnel is working correctly over DirectAccess.
4. In the command prompt window, enter netsh namespace show effectivepolicy and press ENTER. You should see that the Name Resolution Policy Table is active and it shows that there are two entries in the NRPT.
5. Open Internet Explorer. In the address bar, enter https://uag1.contoso.com and press ENTER. Endpoint components will be downloaded to CLIENT1. In the information bar in Internet Explorer, click the This website want to install the following add-on…” and then click Install This Add-on for All Users on This Computer. Click Yes in the User Account Control dialog box. In the Forefront UAG endpoint components dialog box, put a checkmark in the do not show this message again checkbox and click Yes. You will see Downloading Endpoint Component Manager on the web page with a progress bar. In the Security Alert dialog box, put a checkmark in the Trust this site checkbox and then select the Always option. Click Trust. The web page will now say Checking for device compliance.
6. The Application and Network Access Portal page should now appear. If you see a mobile log on page, close Internet Explorer and open it again and go to https://uag1.contoso.com. In the User name text box, enter CORP\User1 and in the Password text box, enter User1’s password. Click Log On.
7. The Application and Network Access Portal now appears. You can see an entry for SSTP VPN in both the left and right panes of the console. Click the SSTP VPN link in the right pane of the console. A new web page window will open. That web page will disappear and you will see an icon with a balloon that says Forefront UAG Remote network Access Connection started. Right click on the icon and click Show Status. In the Portal Activity dialog box, in the Active Connections section, you will see the URL that CLIENT1 is connect to and the time that Remote Network Access started. In the Launched Applications section, you will see the application is SSTP VPN. Click Hide.
8. Return to the elevated command prompt window. In the command prompt window, enter ipconfig and press ENTER. You will see an IPv4 address assigned to PPP adapter UAGSSTPVPN. You will also see an ISATAP address assigned based on the PPP adapter’s IPv4 address; this enables CLIENT1 to communicate with IPv6 only servers on the intranet through the SSTP VPN connection.
9. In the command prompt window, enter ping dc1 and press ENTER. You will see four responses from the IPv6 ISATAP address of DC1. In the command prompt window, enter ping app1 and press ENTER. You will see four responses from the IPv6 ISATAP addresses assigned to APP1. In the command prompt window, enter ping app3 and press ENTER. In this case you see four responses from the IPv4 address assigned to APP3. Remember, APP3 is an IPv4 only resource. In the command prompt window, enter netsh namespace show effectivepolicy. You should see the output say Note: DirectAccess settings would be turned off when computer is inside corporate network. The reason for this is that when the SSTP connection was established, CLIENT1 was able to resolve the name of the Network Location Server (nls.corp.contoso.com), which causes the NRPT to disable itself.
10. Click Start and then in the Search box enter wf.msc and press ENTER. In the Windows Firewall with Advanced Security console, navigate to the Monitoring\Security Associations\Main Mode node in the left pane of the console. Note that there are no security associations, indicating that DirectAccess has been disabled. Click the top node, Windows Firewall with Advanced Security on Local Computer. In the right pane you will see that Domain Profile is Active – this is the reason why DirectAccess is disabled, as the DirectAccess related Connection Security Rules that establish the DirectAccess IPsec tunnels are not available when the Domain Profile is active on the DirectAccess client computer.
11. Right click the Remote Network Access icon in the System Notification Area. Click Disconnect Remote Network Access. In the Windows Firewall with Advanced Security console, click Refresh in the right pane. Notice that the Domain Profile is no longer active and the current profile is Public Profile is Active. Network Location Awareness determined that CLIENT1 was no longer connected to the intranet and changed the Firewall Profile settings. Navigate to the Monitoring\Security Associations\Main Mode node in the left pane of the console. You will see a Main Mode security association, indicating that the DirectAccess intranet tunnel has come up automatically.
12. Return to the elevated command prompt. In the command prompt window, enter ping APP3 and press ENTER. Notice that this time there are four responses from an IPv6 address. This IPv6 address is generated by the NAT64 feature in UAG.
13. Close the command prompt window. Close the Windows Firewall with Advanced Security console. Close Internet Explorer. Click Yes in the SSL Application Tunneling dialog box.

STEP 7: Snapshot the Configuration

This completes the UAG SP1 RC DirectAccess with SSTP test lab. To save this configuration so that you can quickly return to a working UAG SP1 RC DirectAccess Connectivity Assistant 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 TLG UAG DirectAccess SP1RC SSTP. If your lab uses physical computers, create disk images to save the DirectAccess test lab configuration.

Additional Resources

For more information on UAG and SSTP, see Setting up Remote Network Access.

For procedures to configure the Base Configuration test lab on which this document is based, see the Test Lab Guide: Base Configuration.

For procedures to configure UAG SP1 RC DirectAccess on which this document is based, see the Test Lab Guide: Demonstrate Forefront UAG SP1 RC DirectAccess.

For a comprehensive list of Test Lab Guides, please see Test Lab Guides.

For a list of UAG DirectAccess related Test Lab Guides, please see UAG DirectAccess Test Lab Guide Portal Page

For the design and configuration of your pilot or production deployment of DirectAccess, see the Forefront UAG DirectAccess design guide and the Forefront UAG DirectAccess deployment guide.

For information about troubleshooting DirectAccess, see the DirectAccess Troubleshooting Guide.

For information on troubleshooting UAG DirectAccess in a Test Lab, see Test Lab Guide: Troubleshooting UAG DirectAccess.

For more information about DirectAccess, see the DirectAccess Getting Started Web page and the DirectAccess TechNet Web page.

==================================================

Tom Shinder
tomsh@microsoft.com
Knowledge Engineer, Microsoft DAIP iX/Forefront iX 
UAG Direct Access/Anywhere Access Group (AAG)
The “Edge Man” blog (DA all the time): http://blogs.technet.com/tomshinder/default.aspx
Follow me on Twitter: http://twitter.com/tshinder
Facebook: http://www.facebook.com/tshinder

I am happy to tell you that today I’ve released the Test Lab Guide: Demonstrate UAG SP1 RC DirectAccess with Secure Socket Tunneling (SSTP) Test Lab Guide. This is one that I was looking forward to doing because this is such an important deployment model.

As you might know, a single UAG server or UAG array can support all of the roles that are supported by UAG (with the exception that a UAG server or array that acts in the DirectAccess role cannot also host the Network Connector). In general, I recommend that you use different UAG servers or array based on their functional roles:

• One server or array should be dedicated to SSL VPN (portal or reverse web proxy) services
• One server or array should be dedicated to DirectAccess and SSTP (and maybe Remote Desktop Gateway)

This is not a hard and fast rule, and I certainly wouldn’t fault anyone for taking a different approach. But I’ve found that if you separate the services provided on the server or array in this manner, it’s easier to “size” your deployment, given the high processing requirements for the DirectAccess server deployment.

Having SSTP on the DirectAccess server makes it easy to have a “fall back” solution for any applications that don’t work with DirectAccess. While we haven’t seen too many of them, there are still a few and SSTP makes it easy to access the corporate network for DirectAccess client when they need to use these applications. In addition, you may have Windows 7 clients that are not domain members, and thus can’t be DirectAccess clients. Or you might even have domain member Windows 7 computers, but these aren’t configured for DirectAccess. These non-DirectAccess clients can easily connect to the corporate network using the Secure Socket Tunneling Protocol (SSTP), which is firewall and NAT friendly, so that users can connect using SSTP from almost anywhere.

In this Test Lab Guide you will build out a co-located DirectAccess and SSTP server and then test the deployment. You’ll configure the UAG server as both a DirectAccess and SSTP VPN server and then test DirectAccess and SSTP VPN connectivity, and look at several key areas to confirm connectivity and what normal connectivity looks like in these scenarios.

I hope you like the Test Lab Guide: Demonstrate UAG SP1 RC DirectAccess with Secure Socket Tunneling (SSTP) Test Lab Guide. As always, if you have any questions on this Test Lab Guide, or have suggestions for improvements or if you find errors, then please let me know! Just write to the email address in my sig line and I’ll get back to you as soon as I can.

HTH,

Tom

Tom Shinder
tomsh@microsoft.com
Knowledge Engineer, Microsoft DAIP iX/Forefront iX 
UAG Direct Access/Anywhere Access Group (AAG)
The “Edge Man” blog (DA all the time): http://blogs.technet.com/tomshinder/default.aspx
Follow me on Twitter: http://twitter.com/tshinder
Facebook: http://www.facebook.com/tshinder

Hey folks – since the TLGs are typically put up only in the download center, it makes discoverability of some of the cool content inside of them hard when it comes to search engines. Therefore, I’m going to post the full text of the TLGs on the Edge Man blog. However, I recommend that you download the Word .doc version of the TLGs when you actually put together your Test Lab using the Test Lab Guides.

For a downloadable version of the Test Lab Guide – Demonstrate UAG SP1 RC DirectAccess Connectivity Assistant check out:

http://go.microsoft.com/fwlink/?LinkId=205738

==================================================

Introduction

DirectAccess is a new feature in the Windows 7 and Windows Server 2008 R2 operating systems that gives users the experience of being seamlessly connected to their intranet any time they have Internet access. With DirectAccess enabled, requests for intranet resources (such as e-mail servers, shared folders, or intranet Web sites) are securely directed to the intranet, without requiring users to connect to a VPN. DirectAccess provides increased productivity for a mobile workforce by offering the same connectivity experience both inside and outside the office.

Forefront Unified Access Gateway (UAG) SP1 RC extends the value of the Windows DirectAccess solution by adding features that meet the requirements of many enterprise deployments:

• Support for arrays of up to 8 UAG DirectAccess servers where configuration is done once on an array master and is automatically deployed to all other members of the array
• Support for Network Load Balancing, which enables the UAG DirectAccess SP1 RC array to be highly available without requiring the use of an external hardware load balancer
• Support for IPv4-only networks, network segments, or server or application resources with the help of NAT64/DNS64 IPv6/IPv4 transition technologies.

To learn more about UAG DirectAccess, see the following resources:

· Forefront UAG DirectAccess Design Guide

· Forefront UAG DirectAccess Deployment Guide

The Microsoft DirectAccess Connectivity Assistant (DCA) supports a DirectAccess client computer that is running Windows 7 by clearly indicating the state of DirectAccess connectivity to corporate network resources. It provides easy access to troubleshooting information and makes it simple to create and send log files to support personnel.

Without the DCA, when a user’s Internet connection (for example, http://www.bing.com) appears to be available, but corporate network resources are not accessible, there is no way that the user can verify if the problem is caused by DirectAccess not working correctly. This can result in user frustration and increased Help Desk support calls. The DCA clearly indicates the operational status of DirectAccess by using an icon in the notification area and informational messages. This helps the user identify the problem area and helps direct troubleshooting efforts.

If DirectAccess is not working correctly, the DCA clearly indicates the status by changing the icon in the notification area and by sending informational messages that provide more detail about the failure. The DCA provides the user with easy access to an extranet URL. For example, this URL might point to a Web site that hosts support information for the organization’s user community. The user can easily send diagnostic log files to the DirectAccess support staff. The log files can contain the default information. The UAG SP1 RC DCA includes comprehensive advanced diagnostics built-in. The administrator can also include a script in the DCA configuration that creates additional diagnostic information that is included in the log files sent to the support team.

In this guide

This guide provides step-by-step instructions for configuring UAG DirectAccess SP1 RC with the DirectAccess Connectivity Assistant in a test lab so that you can see how it works. You will set up and deploy UAG DirectAccess SP1 RC using five server computers, two client computers, Windows Server 2008 R2 Enterprise edition, and Windows 7 Ultimate Edition. The Test Lab simulates intranet, Internet, and a home networks, and demonstrates the Forefront UAG DirectAccess Connectivity Assistant. The starting point for this paper is the Test Lab Guide: Demonstrate UAG SP1 RC DirectAccess .

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, please see the Forefront UAG DirectAccess design guide and the Forefront UAG DirectAccess deployment guide

Overview of the test lab scenario

In this test lab scenario, Forefront UAG DirectAccess SP1 RC 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 DirectAccess SP1 RC 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 SP2 (APP3) that is configured as an IPv4 only web and file server. This server is used to highlight the UAG’s NAT64/DNS64 capabilities.
• One standalone server running Windows Server 2008 R2 Enterprise Edition (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 domain member client computer running Windows 7 Ultimate Edition (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 subnet by NAT1.
• The Internet subnet (131.107.0.0/24).
• The Corpnet subnet (10.0.0.0/24) separated from the Internet by the Forefront UAG 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 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.
• Five computers or virtual machines that meet the minimum hardware requirements for Windows Server 2008 R2 Enterprise; two 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 (NAT1).
• The product disc or a downloaded version of Microsoft Forefront Unified Access Gateway (UAG) SP1 RC.

This Test Lab Guide demonstrates the UAG DirectAccess SP1 RC DirectAccess Connectivity Assistant.

For more information about the different modes of NAP, see Stages of a NAP Deployment.

Important

The following instructions are 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 clearly show the desired functionality. It is important to remember that 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 test lab configuration to a pilot or production deployment can result in configuration or functionality issues. To ensure proper configuration and operation of UAG DirectAccess , please refer to the Forefront UAG DirectAccess Deployment Guide for the steps to configure the UAG DirectAccess server and supporting infrastructure servers.

Steps for configuring the test lab

The following sections describe how to configure UAG1, DC1 and CLIENT1 for UAG SP1 RC and the DCA. After UAG1, DC1 and CLIENT1 are configured, this guide provides steps for demonstrating the DCA functionality for CLIENT1 when it is connected to the Homenet subnet.

Note

You must be logged on as a member of the Domain Admins group or 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. For all tasks described in this document you can use the CONTOSO\User1 account created when you went through the steps in the UAG DirectAccess Test Lab Guide: Demonstrate UAG SP1 RC DirectAccess.

The following procedures are performed to enable and allow you to test the UAG SP1 RC DCA:

· 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.

· Step 2: Configure INET1 with a Help.txt file. The DCA can provide DirectAccess users information about a web site they can go to in order to get help with DirectAccess related problems. In this step you will configure a web page that CLIENT1 can reach to get that help.

· Step 3: Install and Configure the Web Server Role on DC1. The DCA uses a number of connectivity verifiers to determine intranet connectivity over the DirectAccess IPsec tunnels. In this step you will configure DC1 as a web server so that the DCA can use HTTPS to DC1 for a connectivity verifier.

· Step 4: Run the UAG DirectAccess DCA Configuration Wizard on UAG1. UAG SP1 RC includes a new integrated DCA wizard that automatically configures and deploys GPO settings that enable the DCA. In this step you will run the UAG SP1 RC DCA wizard.

· Step 5: Update Group Policy on CLIENT1 and Test DCA Functionality. The new DCA settings are deploy via the DirectAccess clients GPO. In this step you will update Group Policy on CLIENT1 and then test some of the DCA features.

· Step 6: Snapshot the configuration. After completing the Test Lab, take a snapshot of the working UAG DirectAccess with NAP Test Lab so that you can return to it later to test additional scenarios.

Note

You will notice that there are several steps that begin with an asterisk (*). The * indicates that the step requires that you move to a computer or virtual machine that is different from the computer or virtual machine you were at when you completed the previous step.

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 the UAG DirectAccess DCA. If you have already completed the steps in that Test Lab Guide and saved a snapshot or disk image of the Test Lab, you can restore the snapshot or image and begin with the next step.

STEP 2: Configure INET1 with the Help.txt File

The DCA can expose to DirectAccess users a link to a location where they can find help. This location is configured in the UAG DirectAccess DCA wizard. In this step you will configure a Help.txt file that CLIENT1 will connect to when acting as a DirectAccess client.

1. *At the INET1 computer or virtual machine, log on as Administrator. Click the Start button, click the Windows Explorer icon in the Task Bar.
2. In Windows Explorer, navigate to C:\inetpub\wwwroot. In the right pane of the Windows Explorer windows, right click in an empty area, point to New and click Text Document.
3. Rename New Text Document to help and press ENTER to save the new name.
4. Double click on the help text document. In the help – Notepad window enter This is the place to get help with your DirectAccess problems.
5. Close the help – Notepad window. In the Notepad dialog box, click Save.
6. Close the Windows Explorer window.

STEP 3: Install and Configure the Web Server Role on DC1

The UAG DCA uses connectivity verifiers to determine DirectAccess connectivity to the intranet over the DirectAccess tunnels. Connectivity verifiers can use HTTP, HTTPS and SMB to assess the current connectivity status to the intranet over the DirectAccess IPsec tunnels. In this step you install the web server role on DC1 and then bind a certificate to the web site so that the DCA can establish an SSL session with DC1 to determine intranet connectivity.

1. *At the DC1 computer or virtual machine, log on as User1.
2. Open the Server Manager console if it does not open automatically. In the left pane of the Server Manager console, click Roles. In the right pane of the console, click the Add Roles link.
3. On the Before You Begin page, click Next. On the Select Server Roles page, select Web Server (IIS) and click Next. On the Introduction to Web Server (IIS) page, click Next.
4. On the Select Role Services page, click Next. On the Confirm Installation Selections page, click Install. On the Installation Results page, click Close.
5. Click Start and point to Administrative Tools. Click Internet Information Services (IIS) Manager.
6. In the left pane of the Internet Information Services (IIS) Manager, navigate to DC1 (CORP\User1)\Sites\Default Web Site. In the Actions pane, click Bindings.
7. In the Site Bindings dialog box, click Add. In the Add Site Binding dialog box, from the Type drop down box, select https. From the SSL certificate drop down box, select DC1.corp.contoso.com. Click OK. In the Site Bindings dialog box, click Close.
8. Close the Internet Information Services (IIS) Manager console.

STEP 4: Run the UAG DirectAccess DCA Configuration Wizard on UAG1

UAG SP1 RC includes a new wizard that enables you to configure the DCA so that you don’t have to manually configure Group Policy to support the DCA. In this step you will run the DCA wizard so that it will automatically provision Group Policy to configure the DCA on DirectAccess clients.

1. *At the UAG1 computer or virtual machine log on as User1. 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 left pane of the console, click DirectAccess. In the right pane of the console, in the Step 1 Clients and GPOs section, click the Client Connectivity Assistant link.
3. In the Client Connectivity Assistant Configuration wizard, on the Client Connectivity page, select the Yes, configure application settings option. Confirm that there is a checkmark in the Allow users to use local name resolution instead of sending requests through corporate DNS servers. Click Next.
4. On the Connection Verification page, click Add. In the Connectivity Verifier Details dialog box, select File from the Connectivity method drop down box. In the Verification server name, IP address or URL text box, enter \\APP1\Files\example.txt. Click the Validate Connectivity button. You should see a Validation dialog box informing you that A connection to the connectivity verifier was established. Click OK and then click OK again.
5. Click Add. In the Connectivity Verifier Details dialog box, select the HTTP option from the Connectivity method drop down list. In the Verification server name, IP address, or URL text box, enter http://app1.corp.contoso.com. Click the Validate Connectivity button. You should see a Validation dialog box informing you that A connection to the connectivity verifier was established. Click OK and then click OK again.
6. Click Add. In the Connectivity Verifier Details dialog box, select the HTTPS option from the Connectivity method drop down list. In the Verification server name, IP address, or URL text box, enter http://dc1.corp.contoso.com. Click the Validate Connectivity button. You should see a Validation dialog box informing you that A connection to the connectivity verifier was established. Click OK and then click OK again.
7. On the Connection Verification page, click Next.
8. On the Troubleshooting Portal page, select the This site (URL): option. In the text box below that option, enter http://inet1.isp.example.com/help.txt. In the Friendly name for URL link: text box, enter DirectAccess Help Center. Click Next.
9. On the Diagnostic Logging page, in the Send client log files to text box, enter user1@corp.contoso.com. Click Finish.
10. In the right pane of the console, click the Apply Policy button. On the Forefront UAG DirectAccess Configuration Review page, click Apply Now. In the DirectAccess Policy Configuration dialog box, click OK. Click Close on the Forefront UAG DirectAccess Configuration Review page.
11. Open an elevated command prompt. In the command prompt window, enter gpupdate /force and press ENTER. Close the command prompt window.
12. In the right pane of the console, click the Activate button. In the Activate Configuration dialog box, click Activate. Click Finish when the activation is complete. Close the UAG management console.

STEP 5: Update Group Policy, Install the DCA and Test DCA Functionality on CLIENT1

In this step you will update Group Policy on CLIENT1 so that it receives the new DCA related settings. Then you will install the DCA client software and finally test DCA functionality when CLIENT1 is located on the Homenet subnet.

Update Group Policy on CLIENT1:

1. *Connect CLIENT1 to the Corpnet subnet. Wait until the network icon in the notification area of the desktop displays a yellow caution sign.
2. Click Start, click All Programs, click Accessories, right-click Command Prompt, and then click Run as administrator. Click Yes at the User Account Control prompt.
3. In the command prompt window, enter gpupdate /force and press ENTER. Wait for the command to complete and then close the command prompt window.

Install the DCA software on CLIENT1:

1. On CLIENT1, insert the UAG SP1 RC DVD into the computer or mount the UAG SP1 RC .iso file on the virtual machine. In the AutoPlay dialog box, click Open folder to view files.
2. Navigate to the UAG\Microsoft Forefront Unified Access Gateway\common\bin\da\dca folder. Double click on the Microsoft_DirectAccess_Connectivity_Assistant file.
3. In the Microsoft DirectAccess Connectivity Assistant Setup wizard, on the MICROSOFT PRE-RELEASE SOFTWARE LICENSE TERMS page, put a checkmark in the I accept the terms in the License Agreement checkbox and click Install. In the user Account Control dialog box, click Yes. On the Completed the Microsoft DirectAccess Connectivity Assistant Setup Wizard page, click Finish.
4. You should now see the DCA icon in the system notification area.

Test DCA Functionality on CLIENT1:

1. Move CLIENT1 to the Homenet subnet and wait for the network icon in the system notification area to stop spinning. Right click the Taskbar and click Properties. In the Taskbar and Start Menu Properties dialog box, in the Nofication Area section, click Customize. On the Nofication Area Icons page, put a checkmark in the Always show all icons and notifications on the taskbar and click OK. Click OK in the Taskbar and Start Menu Properties dialog box.
2. At this point you might notice a red “x” on the DCA icon. Open an elevated command prompt on CLIENT1. In the command prompt window enter net view \\dc1 and press ENTER. You should see a list of shares on DC1. In the command prompt window, enter net view \\app1 and press ENTER. If you receive a network path was not found error, then in the command prompt window enter ipconfig /flushdns and press ENTER. After that command completes, enter in the command prompt windows net view \\app1 and press ENTER. You should see a list of share on APP1. You should also see the red “x” disappear from the DCA icon.
3. *Move to the APP1 computer or virtual machine. Open Windows Explorer and navigate to the C:\Files folder. Right click the Example file and click Rename. Rename the file to Example1 and press ENTER to save the file with the new name. Notice that a new empty file is created with the same name.
4. *Move to the DC1 computer or virtual machine. Click Start and point to Administrative Tools. Click Internet Information Services (IIS) Manager. In the Internet Information Services (IIS) Manager console, in the left pane, click DC1 (CORP\User1). In the Actions pane, click Stop.
5. *Move to the CLIENT1 computer or virtual machine and wait a few moments. You will notice that the DCA icon now has a red “x” on it. Right click the DCA icon and click Advanced Diagnostics.
6. Notice under Advanced Log File that is says generating logs while it creates the log files. When it says Open logs directory click the Open logs directory link. Double click DcaDefaultLog.
7. On the DirectAccess Connectivity Assistant Logs web page, note in the Probes List section a line that reads FAIL – The server name resolved successfully, but failed to access HTTP: https://dc1.corp.contoso.com. Note that the other two connectivity verifiers that you configured show as PASS. Also note that there is a connectivity verifier that you didn’t configure – a ping test to the UAG DirectAccess server itself (PASS – PING: 2002:836b:3::836b:3). Scroll through the rest of the page to view the detailed information collected by the DCA client software. Close Internet Explorer. Close Windows Explorer.
8. In the DCA dialog box, notice that the entry you make in the wizard DirectAccess Help Center appears, and under that is the URL you configured for the Help page. Click the http://inet1.isp.example.com link. You should see the help page that reads This is the place to get help with your DirectAccess problems. Close Internet Explorer. Note the Email Logs button. If there were an email client application installed on CLIENT1, you could click that button and it would automatically email the log files to user1@corp.contoso.com, as you configure in the DCA wizard. Click Close in the Microsoft DirectAccess Connectivity Assistant dialog box. Close all open windows on CLIENT1.
9. *Move to the DC1 computer or virtual machine. In the Internet Information Services (IIS) Manager console, in the Actions pane, click Start. Close all open windows on DC1.

It is important to note that the DCA icon may show a red “x” even when there is connectivity to the intranet. The red “x” appears when any of the connectivity verifiers is unavailable to the DirectAccess client. It is recommended that you specify a diverse set of resources for your connectivity verifiers. This diversity helps ensure that a failure to access a resource is an unambiguous indication of a problem with DirectAccess rather than a problem with another component.

For example, if all of the specified resources are behind a network address translating application layer gateway (NAT64), the failure of DCA to access the test resources might indicate a failure of the NAT64 rather than a failure of DirectAccess. Instead, identify one resource behind the NAT64, another behind an ISATAP gateway, and so on. Also note that you must not use the Network Location Server as a connectivity verifier, since the name of the Network Location Server cannot be resolved by the DirectAccess client.

STEP 6: Snapshot the Configuration

This completes the UAG SP1 RC DirectAccess Connectivity Assistant test lab. To save this configuration so that you can quickly return to a working UAG SP1 RC DirectAccess Connectivity Assistant 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 TLG UAG DirectAccess SP1RC DCA. 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 to configure UAG SP1 RC DirectAccess on which this document is based, see the Test Lab Guide: Demonstrate Forefront UAG SP1 RC DirectAccess.

For a comprehensive list of UAG DirectAccess Test Lab Guides, please see Test Lab Guides.

For the design and configuration of your pilot or production deployment of DirectAccess, see the Forefront UAG DirectAccess design guide and the Forefront UAG DirectAccess deployment guide.

For information about troubleshooting DirectAccess, see the DirectAccess Troubleshooting Guide.

For information on troubleshooting UAG DirectAccess in a Test Lab, see Test Lab Guide: Troubleshooting UAG DirectAccess.

For more information about DirectAccess, see the DirectAccess Getting Started Web page and the DirectAccess TechNet Web page.

==================================================

Tom Shinder
tomsh@microsoft.com
Knowledge Engineer, Microsoft DAIP iX/Forefront iX 
UAG Direct Access/Anywhere Access Group (AAG)
The “Edge Man” blog (DA all the time): http://blogs.technet.com/tomshinder/default.aspx
Follow me on Twitter: http://twitter.com/tshinder
Facebook: http://www.facebook.com/tshinder

Yay! Another Test Lab Guide hits the download center today.

Today’s Test Lab Guide is the Test Lab Guide: Demonstrate UAG DirectAccess Connectivity Assistant. In this Test Lab Guide you’ll go over the installation and configuration of the DirectAccess Connectivity Assistant (known as the DCA). The DCA allows DirectAccess users to receive information about the status of their DirectAccess connections and also includes advanced diagnostic tools that make it simple for the user to create comprehensive troubleshooting logs that can be emailed to the UAG DirectAccess administrator with a single click.

I hope you like the Test Lab Guide: Demonstrate UAG DirectAccess Connectivity Assistant. Let me know what you think of it! If there are additional scenarios you’d like to see covered in this Test Lab Guide, or if there are areas that you think need clarification or enhancement, let me know. Just send me a note to the email address in my sig line and I’ll get right back to you.

HTH,

Tom

Tom Shinder
tomsh@microsoft.com
Knowledge Engineer, Microsoft DAIP iX/Forefront iX 
UAG Direct Access/Anywhere Access Group (AAG)
The “Edge Man” blog (DA all the time): http://blogs.technet.com/tomshinder/default.aspx
Follow me on Twitter: http://twitter.com/tshinder
Facebook: http://www.facebook.com/tshinder

Jason Jones, one of our ace Forefront MVPs, has put together a great blog post on DirectAccess application compatibility.

If you’re in the process of planning a UAG DirectAccess rollout, you might want to check out this list.

Forefront UAG DirectAccess: Application Compatibility Table

HTH,

Tom

Tom Shinder
tomsh@microsoft.com
Knowledge Engineer, Microsoft DAIP iX/SCD iX
UAG Direct Access/Anywhere Access Group (AAG)
The “Edge Man” blog (DA all the time): http://blogs.technet.com/tomshinder/default.aspx
Follow me on Twitter: http://twitter.com/tshinder
Facebook: http://www.facebook.com/tshinder

Just wanted to give all you Edge Man Blog followers a heads-up on the new Test Lab Guides Blog.

Test Lab Guides are definitely catching on internally at Microsoft and we are expecting a flood of them coming to you in the next few months. In addition, I’ve been hearing from a number of you that you want to create your own Test Lab Guide extensions for the TechNet wiki – rock on!

My esteemed and accomplished colleague Joe Davies and I will maintain the Test Lab Guides blog and you can use it as a central place to hear news and views about Test Lab Guides.

Remember, with Test Lab Guides, you Make Something of IT!

HTH,

Tom

Tom Shinder
tomsh@microsoft.com
Knowledge Engineer, Microsoft DAIP iX/SCD iX
UAG Direct Access/Anywhere Access Group (AAG)
The “Edge Man” blog (DA all the time): http://blogs.technet.com/tomshinder/default.aspx
Follow me on Twitter: http://twitter.com/tshinder
Facebook: http://www.facebook.com/tshinder

Hey folks – since the TLGs are typically put up only in the download center, it makes discoverability of some of the cool content inside of them hard when it comes to search engines. Therefore, I’m going to post the full text of the TLGs on the Edge Man blog. However, I recommend that you download the Word .doc version of the TLGs when you actually put together your Test Lab using the Test Lab Guides.

For a downloadable version of the Test Lab Guide – Demonstrate UAG SP1 RC DirectAccess Force Tunneling check out:

http://go.microsoft.com/fwlink/?LinkId=205354

==================================================

Introduction

Forefront Unified Access Gateway (UAG) 2010 SP1 RC DirectAccess 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.

IT professionals can benefit from UAG 2010 SP1 RC DirectAccess in many ways:

· Improved Manageability of Remote Users. Without DirectAccess, IT professionals can only manage mobile computers when users connect to a VPN or physically enter the office. With DirectAccess, IT professionals can manage mobile computers by updating Group Policy settings and distributing software updates any time the mobile computer has Internet connectivity, even if the user is not logged on. This flexibility allows IT professionals to manage remote computers on a regular basis and ensures that mobile users stay up-to-date with security and system health policies.

· Secure and Flexible Network Infrastructure. Taking advantage of technologies such as Internet Protocol version 6 (IPv6) and Internet Protocol security (IPsec), DirectAccess provides secure and flexible network infrastructure for enterprises. Below is a list of DirectAccess security and performance capabilities:

Authentication. DirectAccess authenticates the computer, enabling the computer to connect to the intranet before the user logs on. DirectAccess can also authenticate the user and supports two-factor authentication using smart cards.

Encryption. DirectAccess uses IPsec to provide encryption for communications across the Internet.

Access to IPv4-only intranet resources. UAG SP1 RC DirectAccess extends the value of Windows DirectAccess with NAT64/DNS64, an IPv6/IPv4 protocol transition technology that enables DirectAccess client connectivity to IPv4-only resources on the intranet.

· High availability and array configuration. UAG DirectAccess extends the value of Windows DirectAccess by adding integrated support for Network Load Balancing and array configuration, which work together to enable a highly available DirectAccess deployment.

· IT Simplification and Cost Reduction. By default, DirectAccess separates intranet from Internet traffic, which reduces unnecessary traffic on the intranet by sending only traffic destined for the intranet through the DirectAccess server. Optionally, IT can configure DirectAccess clients to send all traffic through the DirectAccess server, which is referred to as Force Tunneling.

The following figure shows a DirectAccess client on the Internet.

In this guide

This paper contains instructions for configuring and demonstrating UAG SP1 RC DirectAccess using six server computers and two client computers. The starting point for this paper is a Test Lab based on the Test Lab Guide: Demonstrate UAG SP1 RC DirectAccess. The resulting DirectAccess test lab simulates an intranet, the Internet, and a home network and demonstrates DirectAccess functionality in different Internet connection scenarios when DirectAccess Force Tunneling is enabled.

Force tunneling is used when you want all traffic, both intranet and Internet, to go through the UAG DirectAccess server. The default setting for UAG DirectAccess is split tunneling. When Force Tunneling is enabled, all traffic must go through the DirectAccess tunnels. For a DirectAccess client to reach the Internet, the client must be configured to use a web proxy server, or to use the NAT64/DNS64 service on the UAG DirectAccess server to route connections to the Internet (sometimes referred to “bouncing” the connections off the UAG DirectAccess server to the Internet). This guide provides step by step instructions that allow you to demonstrate how to use both methods of Internet access for Force Tunneling enabled DirectAccess clients.

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 address assignment 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 for your production network, please see the Forefront UAG DirectAccess design guide and the Forefront UAG DirectAccess deployment guide

Overview of the Test Lab scenario

In this test lab scenario, Forefront UAG 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 SP2 Enterprise Edition (APP3), that is configured as a IPv4 only web and file server. This server is used to highlight the NAT64/DNS64 capabilities.
• One intranet member server running Windows Server 2008 R2 Enterprise Edition (TMG1), that is configured as a web proxy server for DirectAccess clients. Threat Management Gateway 2010 will be installed on TMG1 to provide web proxy services.
• One standalone server running Windows Server 2008 R2 Enterprise Edition (INET1), that is configured as an Internet DNS and DHCP server. INET1 will also be configured to provide Internet access to the live Internet.
• One standalone client computer running Windows 7 (NAT1), that is configured as a network address translator (NAT) device using Internet Connection Sharing (ICS).
• One roaming member client computer running Windows 7 Enterprise or Ultimate (CLIENT1) that is configured as a DirectAccess client.

The test lab consists of four subnets that simulate the following:

• A home network named Homenet (192.168.137.0/24) connected to the Internet subnet by NAT1.
• The Internet subnet (131.107.0.0/24).
• An intranet subnet named Corpnet (10.0.0.0/24) separated from the Internet subnet by the Forefront UAG DirectAccess server.
• A “live” network connection that provides a path to your actual Internet gateway. INET1 will be connected to the Internet subnet and the “live” network connection so you can test actual Internet access when CLIENT1 is acting as a DirectAccess client.

Computers on each subnet connect using either a physical or virtual hub or switch, as shown in the following figure.

This guide provides step by step instructions on how to build a test lab that will enable you to test the new UAG SP1 RC Force Tunneling configuration feature. Force Tunneling forces DirectAccess clients to always use the DirectAccess tunnels for any kind of communication, including both intranet and Internet communications. When you configure DirectAccess clients to use Force Tunneling, you can enable one of two methods of Internet access for the DirectAccess client.

These methods include:

· Web proxy – You can configure the force tunneling DirectAccess clients on the Internet to use a web proxy on your intranet to gain Internet access. When using the web proxy option, the DirectAccess clients are limited to using web proxy supported protocols when connecting to Internet resources, which typically are HTTP and HTTPS.

· UAG NAT64/DNS64 – If you need your force tunneling DirectAccess clients to access Internet using protocols other than those supported by a web proxy, and you configure them to use the UAG server’s NAT64/DNS64 service to route the connections through the UAG server to the Internet. You can put a web proxy or other web content filtering device in front of the UAG DirectAccess server if you want to control site access and perform malware filtering.

Note that the default configuration for DirectAccess clients is split tunneling. When split tunneling is enabled, connections to the intranet are forwarded through the DirectAccess IPsec tunnels and connections to the Internet are made through the client’s existing Internet connection. Force Tunneling represents a departure from the default configuration.

Configuration component requirements

The following components are required for configuring Forefront UAG 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.
• Six computers or virtual machines that meet the minimum hardware requirements for Windows Server 2008 R2 Enterprise; three of these computers have two network adapters installed (UAG1, TMG1, INET1.
• 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 (NAT1).
• The product disc or a downloaded (.iso) version of Microsoft Forefront Unified Access Gateway (UAG) SP1 RC.
• The product disc or downloaded (.iso) version of Microsoft Forefront Threat Management Gateway 2010 Standard Edition.

Steps for configuring the test lab

The following steps describe how to configure the server and client computers, and configure the Forefront UAG DirectAccess server, in a test lab. Following these configurations you can verify DirectAccess connectivity from the Internet and Homenet subnets, and show how Force Tunneling DirectAccess clients connect to the Internet using both Internet access models (web proxy and NAT64/DNS64).

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.

· Step 1: Complete the UAG SP1 RC DirectAccess Test Lab Guide. The UAG SP1 RC Test Lab Guide provides step by step instructions on how to create a working DirectAccess solution. The steps in this Test Lab Guide build on the steps in the UAG SP1 RC Test Lab Guide.

· Step 2: Configure INET1 for Internet Access. INET1 is currently configured with a single network adapter that is connected to the Internet subnet. In this step you will add a second network adapter and connect that adapter to a “live” network that provides a path to the actual Internet. You will then install and configure RRAS on INET1 so that it can act as a NAT router for live Internet connections from UAG1 and TMG1.

· Step 3: Install and Configure TMG1. When force tunneling is enabled for DirectAccess clients, you can provide DirectAccess clients access to the Internet through a web proxy server. In this step you will install the operating system on TMG1 and then install Forefront Threat Management Gateway 2010 on TMG1 so that TMG1 can provide web proxy services to CLIENT1.

· Step 4: Configure the Default Gateway on UAG1 and DC1. UAG1 requires a path to the Internet. In this step you will configure UAG1 to use INET1 as its default gateway to provide that path. DC1 requires a path to the Internet to provide Internet name resolution. In this step you will configure DC1 to use TMG1 as its default gateway to provide that path.

· Step 5: Configure UAG1 for Force Tunneling and Web Proxy Access to the Internet. In this step you will configure UAG1 to require DirectAccess client Force Tunneling and enable Internet access for DirectAccess clients through the TMG web proxy on TMG1.

· Step 6: Update CLIENT1 and Test Proxy Access to the Internet. In this step you will update the Group Policy configuration on CLIENT1 and test its ability to reach the Internet through the web proxy on TMG1.

· Step 7: Configure UAG1 for Force Tunneling and NAT64/DNS64 Internet Access. In this step you will configure UAG1 to require DirectAccess client Force Tunneling and enable Internet access for DirectAccess clients through UAG1 by taking advantage of the UAG NAT64/DNS64 feature.

· Step 8: Update CLIENT1 and Test NAT64/DNS64 Access to the Internet. In this step you will update the Group Policy configuration on CLIENT1 and test its ability to reach the Internet through the NAT64/DNS64 service on UAG1.

· Step 9: Snapshot the Configuration – At the completion of the lab, snapshot the configuration so that you can later return to a working UAG DirectAccess Test Lab.

Note

You will notice that there are several steps that begin with an asterisk (*). The * indicates that the step requires that you move to a computer or virtual machine that is different from the computer or virtual machine you were at when you completed the previous step within the same section.

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

This Test Lab Guide uses the UAG SP1 RC DirectAccess Test Lab Guide as a starting place. Please complete the steps in Test Lab Guide: Demonstrate UAG SP1 RC DirectAccess before proceeding with the remainder of the steps in this guide. If you have already completed the steps in the UAG SP1 RC DirectAccess Test Lab Guide and have saved a disk image or a virtual machine snapshot of the working DirectAccess configuration, then you can restore the configuration and proceed to the next step.

STEP 2: Configure INET1 for Internet Access

In order to demonstrate a Force Tunneling DirectAccess client’s ability to access the Internet, you need a gateway to the live Internet. The Corpnet subnet, the Internet subnet, and the Homenet subnets you created when you completed the Base Configuration are isolated from the live network. In order to provide actual Internet access for CLIENT1 when acting as a DirectAccess client, you need to provide an Internet gateway that UAG1 and TMG1 can use to reach the Internet. INET1 will be this Internet gateway.

You will perform the following operations to configure INET1:

A. Add and Configure a Second Network Adapter on INET1. INET1 is currently connected to the Internet subnet. The first step is to add a second network adapter to INET1 and connect that adapter to a “live” network that provides access to the Internet.

B. Install the Routing and Remote Access Service. In this step you will install the Routing and Remote Access Service on INET1 so that it can provide NAT-based access to the Internet for UAG1 and TMG1.

C. Configure INET1 as a NAT server. In this step you will configure the Routing and Remote Access service so that INET1 can act as a NAT server.

A. Add and Configure a Second Network Adapter on INET1

The first step is to install a second network adapter on INET1. This adapter must be connected to your live network and be assigned IP addressing information that enables it to reach the Internet through your existing Internet gateway. If your live network is configured to provide addressing information through DHCP, you can configure this second network adapter to use DHCP. If your network doesn’t provide IP addressing information that would enable Internet access automatically, then you will need to manually configure the IP addressing information on the second adapter to provide INET1 Internet access. In both cases, make sure that the IP addressing information provided includes a DNS server that can resolve Internet host names so that you can test Internet connectivity from INET1.

After the second adapter is installed and configured, test Internet connectivity on INET1. To test Internet connectivity, open a command prompt on INET1 and enter ping www.arin.net and press ENTER. You should receive four responses to your ping request. You can then close the command prompt window.

B. Install the Routing and Remote Access Services on INET1

Now that you have installed the second network adapter on INET1, you are ready to install the Routing and Remote Access service. Perform the following steps to install the Routing and Remote Access Service on INET1:

1. Log on to the INET1 computer or virtual machine as Administrator. Open Server Manager if it does not open automatically. In Server Manager, in the left pane of the console, click Roles. In the right pane of the console, click Add Roles.
2. On the Before You Begin page, click Next.
3. On the Select Server Roles page, select Network Policy and Access Services and then click Next.
4. On the Network Policy and Access Services page, click Next.
5. On the Role Services page, select Routing and Remote Access Services and then click Next.
6. On the Confirmation page, click Install.
7. On the Results page, click Close.

C. Configure INET1 as a NAT Server

You are now ready to configure INET1 as a NAT server. Perform the following steps to configure INET1 as a NAT server:

1. At INET1, click Start, point to Administrative Tools and click Routing and Remote Access.
2. In the left pane of the Routing and Remote Access console, right click on INET1 and click Configure and Enable Routing and Remote Access.
3. On the Welcome to the Routing and Remote Access Server Setup Wizard page, click Next.
4. On the Configuration page, select the Network address translation (NAT) option and click Next.
5. On the NAT Internet Connection page, confirm that the Use this public interface to connect to the Internet is selected. From the Network Interfaces list, select the adapter that represents the interface connected to the live network. Click Next.
6. On the Completing the Routing and Remote Access Server Setup Wizard, click Finish.
7. Close the Routing and Remote Access console.

STEP 3: Install and Configure TMG1

When Force Tunneling is enabled for DirectAccess clients, they cannot access the Internet the Internet directly as split tunneling is disabled. There are two methods available that provide DirectAccess clients Internet access when Force Tunneling is enabled: Internet access through a web proxy device, or Internet access through the UAG DirectAccess server’s NAT64/DNS64 service. When Internet access is enabled through a web proxy, only HTTP and HTTPS Internet access is enabled.

In this step you will perform the following procedures:

A. Install the Operating System on TMG1. TMG1 is a new computer that is in first introduced in this Test Lab Guide. There you need to start by installing the operating system on the TMG1 computer or virtual machine. TMG1 must have two network adapters installed prior to installing the operating system.

B. Configure TCP/IP Properties on TMG1. After installation of the operating system is complete, the next step is to configure the IP addressing settings on the internal and external interfaces of TMG1.

C. Rename TMG1 and Join TMG1 to the CORP Domain. As a security best practice, the TMG firewall should be configured as a domain member. In this step you will rename the computer or virtual machine to TMG1 and join it to the CORP domain.

D. Install Forefront Threat Management Gateway (TMG) 2010 Standard Edition. After the operating system is installed and IP addressing is assigned, and the machine renamed and joined to the domain, the next step is to install the Threat Management Gateway 2010 software.

E. Configure the TMG Firewall for Internet Access. By default, the TMG firewall does not allow traffic to pass through it. In this step you will configure the TMG firewall to allow Internet traffic outbound.

A. Install the Operating System on TMG1

Perform the following steps to install the operating system on the TMG1 computer or virtual machine:

1. Start the installation of Windows Server 2008 R2.
2. Follow the instructions to complete the installation, specifying Windows Server 2008 R2 Enterprise Edition (full installation) and a strong password for the local Administrator account. Log on using the local Administrator account.
3. Connect TMG1 to a network that has Internet access and run Windows Update to install the latest updates for Windows Server 2008 R2.
4. After the updates installation is complete, connect one network adapter to the Corpnet subnet and the other to the Internet subnet.

B. Configure TCP/IP Properties on TMG1

Perform the following steps to configure the TCP/IP Properties on the adapters installed on TMG1:

1. Log on to the TMG1 computer or virtual machine as Administrator. At the TMG1 computer or virtual machine, in Initial Configuration Tasks, click Configure networking.
2. In Network Connections, right click the network connection that is connected to the Corpnet subnet, and then click Rename.
3. Enter Corpnet and then press ENTER.
4. Right click the Corpnet interface and click Properties.
5. Click Internet Protocol Version 4 (TCP/IPv4) and then click Properties.
6. Select Use the following IP address. In IP address, enter 10.0.0.10. In Subnet mask, enter 255.255.255.0.
7. Select Use the following DNS server addresses. In the Preferred DNS server, enter 10.0.0.1.
8. Click the Advanced button and then click the DNS tab.
9. In DNS suffix for this connection, enter corp.contoso.com and click OK twice, and then click Close.
10. In the Network Connections window, right click the network connection that is connected to the Internet subnet and click Rename.
11. Enter Internet and press ENTER.
12. Right click Internet and click Properties.
13. Click Internet Protocol Version 4 (TCP/IPv4) and click Properties.
14. Confirm that obtain an IP address automatically is selected. Then select the use the following DNS server addresses option. In the Preferred DNS server text box, enter 10.0.0.1. Click OK and then click Close.
15. Close the Network Connections window.

C. Rename TMG1 and Join TMG1 to the CORP Domain

Perform the following steps to rename the TMG1 computer or virtual machine and join it to the CORP domain:

1. At the TMG1 computer or virtual machine, in the Initial Configuration Tasks window, click Provide computer name and domain.
2. In the System Properties dialog box, on the Computer Name tab, click the Change button.
3. In the Computer Name/Domain Change dialog box, in the Computer name text box, enter TMG1. In the Member of frame, select the Domain option and enter corp.contoso.com in the text box. Click OK.
4. In the Windows Security dialog box, enter User1 in the User name text box, and then enter User1’s password in the Password text box. Click OK.
5. In the Computer Name/Domain Changes dialog box that welcomes you to the corp.contoso.com domain, click OK.
6. In the Computer Name/Domain Changes dialog box that informs you that you must restart your computer, click OK.
7. In the System Properties dialog box, click Close.
8. In the Microsoft Windows dialog box, click Restart Now.
9. Log on as CORP\User1.

D. Install Forefront Threat Management Gateway (TMG) 2010 Standard Edition

TMG1 will act as a web proxy server to support Internet access for Force Tunneling enabled DirectAccess clients. Perform the following steps to install Threat Management Gateway (TMG) 2010, which will provide web proxy services to CLIENT1:

1. At the TMG1 computer or virtual machine, insert the Threat Management Gateway 2010 Standard Edition DVD into the DVD tray or mount the .iso file into the virtual machine’s virtual DVD drive.
2. In the AutoPlay dialog box, click Run Splash.hta.
3. On the Forefront Threat Management Gateway 2010 Standard splash page, click Run Preparation Tool. Click Yes in the User Account Control dialog box.
4. On the Welcome to the Preparation Tool for Microsoft Forefront Threat Management Gateway (TMG) page, click Next.
5. On the License Agreement page, put a checkmark in the I accept the terms of the License Agreements checkbox and click Next.
6. On the Installation Type page, select the Forefront TMG services and Management option and click Next.
7. On the Preparation Complete page, confirm that there is a checkmark in the Launch Forefront TMG Installation Wizard checkbox and click Finish. In the User Account Control dialog box, click Yes.
8. On the Welcome to the Installation Wizard for Forefront TMG Standard page, click Next.
9. On the License Agreement page, select I accept the terms in the license agreement option and click Next.
10. On the Customer Information page, click Next.
11. On the Installation Path page, click Next.
12. On the Define Internal Network page, click Add. In the Addresses dialog box, click Add Adapter. In the Select Network Adapters dialog box, put a checkmark in the Corpnet checkbox and then click OK. In the Addresses dialog box, click OK.
13. On the Define Internal Network page, confirm that in the Internal Network Address Ranges (from-to) section that says 10.0.0.0-10.0.0.255. Click Next.
14. On the Services Warning page, click Next.
15. On the Ready to Install the Program page, click Install.
16. On the Installation Wizard Completed page, put a checkmark in the Launch Forefront TMG Management when the wizard closes checkbox and click Finish.
17. Internet Explorer opens to display the Protect the Forefront TMG Computer page. On the Welcome to Internet Explorer 8 page, click Next. On the Turn on Suggested Sites page, select No, don’t turn on and click Next. On the Choose your settings page, select use express settings and click Finish. Close the Internet Explorer Window.

E. Configure the TMG Firewall for Internet Access

By default, the TMG firewall does not pass any traffic. In this step you will configure the TMG firewall with important initial configuration settings and then create a firewall rule that allows outbound traffic. Perform the following steps to configure the firewall and create the firewall rule:

1. In the Getting Started Wizard dialog box, click Configure network settings.
2. On the Welcome to the Network Setup Wizard page, click Next.
3. On the Network Template Selection page, confirm that Edge firewall is selected and click Next.
4. On the Local Area Network (LAN) Settings page, from the Network adapter connected to the LAN drop down list, select Corpnet. Click Next.
5. On the Internet Settings page, confirm that Internet appears in the Network adapter connected to the Internet drop down list. Click Next.
6. On the Completing the Network Setup Wizard page, click Finish.
7. In the Getting Started Wizard dialog box, click Configure System Settings.
8. On the Welcome to the System Configuration Wizard page, click Next.
9. On the Host Identification page, click Next.
10. On the Completing the System Configuration Wizard page, click Finish.
11. In the Getting Started Wizard dialog box, click Define deployment options.
12. On the Welcome to the Deployment Wizard page, click Next.
13. On the Microsoft Update Setup page, select Use the Microsoft Update service to check for updates (recommended) option and click Next.
14. On the Forefront TMG Protection Features Settings page, click Next.
15. On the NIS Signature Update Settings page, click Next.
16. On the Customer Feedback page, click Next.
17. On the Microsoft Telemetry Reporting Service page, select Advanced and click Next.
18. On the Completing the Deployment Wizard page, click Finish. Note: if the wizard appears to hang up and does not respond after several minutes, close the wizard. This will also close the TMG console. Restart the wizard by opening the TMG console again from the Start menu. You will see the Getting Started Wizard dialog box again. Click Define deployment options and run through the wizard again. When you complete the wizard, it will take you to the Getting Started Wizard dialog box again, and there will be a green checkmark to the left of each of the steps. Remove the checkmark from the Run the Web Access checkbox and click Close.
19. In the left pane of the Forefront TMG console, expand Forefront TMG (TMG1) and then click Firewall Policy.
20. In the right pane of the console, click the Tasks tab. On the Tasks tab, click Create Access Rule.
21. On the Welcome to the New Access Rule Wizard page, in the Access rule name text box, enter All Open. Click Next.
22. On the Rule Action page, select Allow and click Next.
23. On the Protocols page, from the This rule applies to drop down list, select All outbound traffic. Click Next.
24. On the Malware Inspection page, select Enable malware inspection for this rule and click Next.
25. On the Access Rule Sources page, click Add. In the Add Network Entities dialog box, click Networks, then double click Internal. Click Close. Click Next.
26. On the Access Rule Destinations page, click Add. In the Add Network Entities dialog box, click Networks, then double click External. Click Close. Click Next.
27. On the User Sets page, click Next.
28. On the Completing the New Access Rule Wizard page, click Finish.
29. In the middle pane of the console, click the Apply button.
30. In the Configuration Change Description dialog box, click Apply.
31. In the Saving Configuration Changes dialog box, click OK.

STEP 4: Configure the Default Gateway on UAG1 and DC1

When DirectAccess clients are configured for Internet access using the UAG NAT64/DNS64 services, the UAG server must be able to forward the connections to the Internet. This requires that UAG1 be configured with a default gateway that provides a route to the Internet. The default gateway for UAG1 is the Internet subnet interface on INET1. DC1 needs a gateway to the Internet in order to resolve Internet host names for the UAG server’s DNS64 service and for the web proxy service on TMG1. DC1 will use TMG1 as its gateway to the Internet.

The following operations are performed to configure UAG1 and DC1:

A. Configure the Default Gateway on UAG1. In this step you will configure UAG1 to use the Internet subnet interface on INET1 as its default gateway.

B. Configure the Default Gateway on DC1. In this step you will configure DC1 to use the Corpnet subnet interface on TMG1 as its default gateway.

A. Configure the Default Gateway on UAG1

Perform the following steps to configure the default gateway on UAG1:

1. At the UAG1 computer or virtual machine, click Start and enter View network connections in the Search box and press ENTER.
2. In the Network Connections window, right click on Internet and click Properties.
3. In the Internet Properties dialog box, click Internet Protocol Version 4 (TCP/IPv4) and click Properties.
4. In the Internet Protocol Version 4 (TCP/IPv4) Properties dialog box, in the Default gateway text box, enter 131.107.0.1. Click OK, then click Close.
5. Close the Network Connections window.

B. Configure the Default Gateway on DC1

Perform the following steps to configure the default gateway on DC1:

1. Log on to the DC1 computer or virtual machine as User1. Click Start and enter View network connections in the Search box and press ENTER.
2. In the Network Connections window, right click on Local Area Connection and click Properties.
3. In the Internet Properties dialog box, click Internet Protocol Version 4 (TCP/IPv4) and click Properties.
4. In the Internet Protocol Version 4 (TCP/IPv4) Properties dialog box, in the Default gateway text box, enter 10.0.0.10. Click OK, then click Close.
5. Close the Network Connections window.
6. Open a command prompt window. In the command prompt window, enter nslookup www.microsoft.com and press ENTER. You should see the IP addresses that resolve to this name, as well as several aliases. If the request times out, repeat the nslookup command. Close the command prompt window.
7. *Move to the UAG1 computer or virtual machine. Open a command prompt and enter nslookup www.microsoft.com and press ENTER. You should see the IP address and name that resolves to this name, as well as several aliases. Note that the record is returned as non-authoritative, since it was retrieved from the DNS cache on DC1. Close the command prompt window.

STEP 5: Configure UAG1 for Force Tunneling and Web Proxy Access to the Internet

When DirectAccess clients are configured to use Force Tunneling, they are not able to reach the Internet except through the DirectAccess tunnel. There are two methods available for providing the Force Tunneling DirectAccess client access to the Internet: web proxy and NAT64/DNS64. In this step you will configure Force Tunneling on the UAG DirectAccess server so that Internet access is provided by the web proxy on TMG1. Perform the following steps to configure Force Tunneling and web proxy Internet access:

1. At the UAG1 computer or virtual machine, click Start and then click All Programs. Click Microsoft Forefront UAG and then click Forefront UAG Management. Click OK in the User Account Control dialog box.
2. In the left pane of the Microsoft Forefront Unified Access Gateway Management console, click DirectAccess.
3. In the right pane of the console, In the Step 2 DirectAccess Server section, click the Force Tunneling link.
4. In the Force Tunneling Configuration wizard, on the Connectivity Method page, select Use force tunneling. Send Internet requests from DirectAccess clients through the UAG DirectAccess server. Click Next.
5. On the Force Tunneling page, select Route requests directly to a corporate Web Proxy server. In the Server name text box, enter TMG1.corp.contoso.com. In the Port text box, enter 8080. Click the Validate Connectivity button. You should see a green checkmark and Validation successful. Click Finish.
6. Click the Apply Policy button at the bottom of the right pane.
7. On the Forefront UAG DirectAccess Configuration Review page, click Apply Now.
8. In the DirectAccess Policy Configuration dialog box, click OK after you see Script run completed with no error or warnings.
9. On the Forefront UAG DirectAccess Configuration Review page, click Close.
10. Open an elevated command prompt. In the command prompt window, enter gpupdate /force and press ENTER. Wait for the command to complete and then close the command prompt window.
11. Click the Activate button at the bottom of the right pane.
12. On the Activate Configuration page, click Activate.
13. On the Activate Configuration page, click Finish.

STEP 6: Update CLIENT1 and Test Proxy Access to the Internet

In this step you will update the Group Policy settings on CLIENT1 so that it uses Force Tunneling when acting as a DirectAccess client. You will then move CLIENT1 to the Homenet subnet to test the force tunneling configuration. After CLIENT1 connects to the Internet, you will review the log file entries on TMG1 to prove that the Internet connection was make through the web proxy.

The following operations configure CLIENT1:

A. Update Group Policy on CLIENT1. CLIENT1 needs updated Group Policy to enable Force Tunneling. In this step you will update Group Policy on CLIENT1.

B. Test Internet Access from CLIENT1 when Connected to Homenet. In this step you will move CLIENT1 to the Homenet subnet and test DirectAccess and Internet connectivity using Force Tunneling.

C. View CLIENT1 Internet Activity in TMG1 Log Files. In this step you will review the log file on TMG1 to confirm that CLIENT1 accessed the Internet through the TMG1 web proxy.

A. Update Group Policy on CLIENT1

Perform the following steps to update Group Policy on CLIENT1:

1. Connect CLIENT1 to the Corpnet subnet and log on to CLIENT1 as User1. At the CLIENT1 computer or virtual machine, open an elevated command prompt. In the command prompt window, enter gpupdate /force and press ENTER. You will notice that User Policy will update correctly, but you will get an error that says machine policy cannot be updated. This is an expected error.
2. In the command prompt window, enter netsh namespace show policy and press ENTER. You should see an entry Settings for . That section should have a line for DirectAccess (Proxy Settings): TMG1.corp.contoso.com:8080. This demonstrates that the new Group Policy settings were applied to CLIENT1. This entry tells CLIENT1 to connect to all sites over the DirectAccess tunnel using the proxy, with the exception of the other entries in the NRPT.
3. Close the command prompt window.

B. Test Internet Access from CLIENT1 when Connected to Homenet

In this step, you will connect CLIENT1 to the Homenet subnet and test Internet access across the DirectAccess tunnel through the web proxy on TMG1. Perform the following steps to test Internet access from the CLIENT1 DirectAccess client:

1. Move CLIENT1 from the Corpnet subnet to the Homenet subnet. Open an elevated command prompt. In the command prompt window enter ipconfig /all. You should see an entry for Tunnel adapter iphttpsinterface and an IPv6 address associated with that interface. CLIENT1 does not use Teredo because Force Tunneling requires the DirectAccess client to use IP-HTTPS.
2. In the command prompt window, enter netsh interface httpstunnel show interfaces and press ENTER. You should see that the Interface Status is IPHTTPS interface active.
3. In the command prompt window, enter ping app1 and press ENTER. You should see four responses from APP1.
4. In the command prompt window, enter net view \\APP1 and press ENTER. You should see a list of shares. This indicates that User1 was able to authenticate with the UAG DirectAccess server and user Kerberos authentication.
5. In the command prompt window, enter ping www.microsoft.com. You will receive an error that the host could not be found. The reason for this is that CLIENT1 only has access to the web proxy for names outside of the corp.contoso.com domain. The web proxy resolves names on behalf of the client, which enables the client to connect to web sites through the web proxy. Close the command prompt window.
6. Open Internet Explorer. In the address bar, enter www.microsoft.com and press ENTER. You should see the home page on the www.microsoft.com web site. Click several links on the page. Try to visit other web sites you are interested in. You should be able to connect to all web sites. Close the Internet Explorer window.

C. View CLIENT1 Internet Activity in TMG1 Log Files

To demonstrate that the web connections were made over the web proxy on TMG1, we will look at the log file on the TMG1 computer or virtual machine. Perform the following steps to view the log file:

1. *Move to the TMG1 computer or virtual machine. Click Start and click All Programs. Click Microsoft Forefront TMG and click Forefront TMG Management. In the User Account Control dialog box, click Yes.
2. In the Forefront TMG console, in the left pane, click the Logs & Reports node. In the right pane of the console, click the Tasks tab. Click the Edit Filter link.
3. In the Edit Filter dialog box, click the Log Time entry. In the Condition drop down list, select Last Hour. Click the Update button.
4. From the Filter by drop down list, select Client IP. From the Condition drop down list, select Equals. In the Value text box, enter 10.0.0.2. When DirectAccess clients connect to an IPv4 proxy like TMG, NAT64/DNS64 on the UAG DirectAccess server is used, and all connections from the DirectAccess clients will appear to source from the internal IPv4 address on the UAG DirectAccess server. Click Add To List. Click Start Query.
5. In the lower left side of the TMG console, wait until it says (Query is done). After the query is done, look in the Destination IP column and click on lines that include a public IP address. After clicking on one of those lines, look in the lower pane that contains details of the connection. On the Request line you will see the URL that CLIENT1 connected to over the TMG web proxy service. This demonstrates that CLIENT1 used the TMG web proxy to reach the Internet and did not connect directly to any Internet resources because when Force Tunneling is enabled, split tunnel is disabled. Click on several of these lines to see various URLs that have been visited.
6. Close the Forefront TMG console.

STEP 7: Configure UAG1 for Force Tunneling and NAT64/DNS64 Internet Access

The second method DirectAccess clients configured for Force Tunneling can use to access the Internet is by using the NAT64/DNS64 service. When you use the UAG NAT64/DNS64 service, the connection is routed to the Internet by the UAG DirectAccess server. Perform the following steps to configure Force Tunneling to enable DirectAccess client access to the Internet through the NAT64/DNS64 services:

1. *Go to the UAG1 computer or virtual machine. Confirm that the UAG console is open. If it is not open, open the UAG console from the Start menu. Click on the DirectAccess node in the left pane of the console.
2. In the Step 2 DirectAccess Server section in the right pane, click Force Tunnel (On).
3. In the Force Tunneling Configuration wizard, on the Connectivity Method page, confirm that the Use force tunneling. Send Internet requests from DirectAccess clients through the UAG DirectAccess server option is selected. Click Next.
4. On the Force Tunneling page, select Resolve and route requests using UAG DirectAccess DNS64 and NAT64. Click Validate Connectivity. You should see a green checkmark with the text Validation successful next to it. Click Finish.
5. At the bottom of the right pane of the console, click Apply Policy.
6. On the Forefront UAG DirectAccess Configuration Review page, click Apply Now.
7. In the DirectAccess Policy Configuration dialog box, click OK after you see Script run completed with no errors or warnings.
8. On the Forefront UAG DirectAccess Configuration Review page, click Close.
9. Open and elevated command prompt. In the command prompt window, enter gpupdate /force and press ENTER. Wait for the command to complete and then close the command prompt window.
10. At the bottom of the right pane of the console, click Activate.
11. In the Activate Configuration dialog box, click Next.
12. Click Finish in the Activate Configuration dialog box.

STEP 8: Update CLIENT1 and Test NAT64/DNS64 Access to the Internet

In this step you will update the Group Policy settings on CLIENT1 so that it uses Force Tunneling when acting as a DirectAccess client. After CLIENT1 connects to the Internet, you will review the log file entries on TMG1 to prove that the Internet connection was make through the web proxy.

The following operations configure CLIENT1:

A. Update Group Policy on CLIENT1. CLIENT1 is currently connected to the Homenet subnet. You will update Group Policy over the DirectAccess connection.

B. Test Internet Access from CLIENT1 when Connected to Homenet. In this step you will test Internet access from CLIENT1 through the UAG NAT64/DNS64 services.

C. View CLIENT1 Internet Activity in UAG1 TMG Log Files. In this step you will view the TMG log files on UAG1 to demonstrate that Internet connectivity is provided through UAG1.

D. Update Group Policy on CLIENT1

Perform the following steps to update Group Policy on CLIENT1:

1. While still located on the Homenet subnet, at the CLIENT1 computer or virtual machine, open an elevated command prompt. In the command prompt window, enter gpupdate /force and press ENTER. You will notice that User Policy will update correctly, but you will get an error that says machine policy cannot be updated. This is an expected error.
2. In the command prompt window, enter netsh namespace show policy and press ENTER. You should see an entry Settings for . That section should have a line for DirectAccess (Proxy Settings): Bypass Proxy. This demonstrates that the new Group Policy settings were applied to CLIENT1. This entry tells CLIENT1 to connect to all sites over the DirectAccess tunnel using the UAG DirectAccess server.
3. Close the command prompt window.

E. Test Internet Access from CLIENT1 when Connected to Homenet

Perform the following steps to test Internet access from CLIENT1 to the Internet:

1. Move CLIENT1 from the Corpnet subnet to the Homenet subnet. Open an elevated command prompt. In the command prompt window enter ipconfig /all. You should see an entry for Tunnel adapter iphttpsinterface and an IPv6 address associated with that interface. CLIENT1 does not use Teredo because Force Tunneling requires the DirectAccess client to use IP-HTTPS.
2. In the command prompt window, enter netsh interface httpstunnel show interfaces and press ENTER. You should see that the Interface Status is IPHTTPS interface active.
3. In the command prompt window, enter ping app1 and press ENTER. You should see four responses from APP1.
4. In the command prompt window, enter net view \\APP1 and press ENTER. You should see a list of shares. This indicates that User1 was able to authenticate with the UAG DirectAccess server and user Kerberos authentication because connections to APP1 must be made through the intranet tunnel.
5. In the command prompt window, enter ping www.microsoft.com and press ENTER. You will see that the UAG DirectAccess server resolves the name for the client by generating a false IPv6 address, but the ping attempts fail because www.microsoft.com servers do not allow ping requests. In the command prompt window, enter ping www.facebook.com and press ENTER. You should see four responses from an IPv6 address. Note that this is not the actual IPv6 address of the site; it is the IPv6 address generated by the NAT64 service on the UAG DirectAccess server. Close the command prompt window.
6. Open Internet Explorer. In the address bar, enter www.microsoft.com and press ENTER. You should see the home page on the www.microsoft.com web site. Click several links on the page. Try to visit other web sites you are interested in. You should be able to connect to all web sites. Close Internet Explorer.

F. View CLIENT1 Internet Activity in UAG TMG Log Files

Perform the following steps to view the TMG log file on the UAG1 machine:

1. *Move to the UAG1 computer or virtual machine. Click Start and click All Programs. Click Microsoft Forefront TMG and click Forefront TMG Management. In the User Account Control dialog box, click Yes.
2. In the Forefront TMG console, in the left pane, click the Logs & Reports node. In the right pane of the console, click the Tasks tab. Click the Edit Filter link.
3. In the Edit Filter dialog box, click the Log Time entry. In the Condition drop down list, select Last Hour. Click the Update button.
4. From the Filter by drop down list, select Rule. From the Condition drop down list, select Equals. In the Value drop down list, select DirectAccess Allow NATPT. Click Add To List. Click Start Query.
5. In the lower left side of the TMG console, wait until it says (Query is done). After the query is done, scroll through the list of entries. In the Protocol column you’ll see the protocols you used to access the Internet sites. In the Client IP column, you’ll see the IP-HTTPS IPv6 address assigned to the CLIENT1. You will some entries in the Protocol column for BranchCache – Retrieval Protocol. These entries actually represent the HTTP connections CLIENT1 made through the UAG1 NAT64/DNS64 services.

1. Close the Forefront TMG console

STEP 9: Snapshot the Configuration

This completes the DirectAccess test lab. To save this configuration so that you can quickly return to a working DirectAccess 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 TLG UAG DirectAccess SP1RC FT. If your lab uses physical computers, create disk images to save the DirectAccess test lab configuration.

Additional Resources

For procedures to configure the Test Lab Guide: Demonstrate UAG SP1 RC DirectAccess on which this document is based, see the 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 DirectAccess design guide and the Forefront UAG DirectAccess deployment guide.

For information about troubleshooting DirectAccess, see the DirectAccess Troubleshooting Guide.

For information about troubleshooting DirectAccess in a Test Lab, see the Test Lab Guide: Troubleshoot UAG DirectAccess.

For a comprehensive list of UAG DirectAccess Test Lab Guides, see the TechNet wiki Test Lab Guide clearinghouse at Test Lab Guides.

For more information about DirectAccess, see the DirectAccess Getting Started Web page and the DirectAccess TechNet Web page.

==================================================

Tom Shinder
tomsh@microsoft.com
Knowledge Engineer, Microsoft DAIP iX/SCD iX
UAG Direct Access/Anywhere Access Group (AAG)
The “Edge Man” blog (DA all the time): http://blogs.technet.com/tomshinder/default.aspx
Follow me on Twitter: http://twitter.com/tshinder
Facebook: http://www.facebook.com/tshinder

I’m happy to announce the release of the latest UAG DirectAccess Test Lab Guide – Test Lab Guide: Demonstrate Forefront UAG SP1 RC DirectAccess Force Tunneling, which you can download now at http://go.microsoft.com/fwlink/?LinkId=205454

I found this Test Guide to be especially interesting to put together. If you haven’t heard of Force Tunneling – here’s a little background.

By default, when you configure DirectAccess clients (both Windows DirectAccess and UAG DirectAccess), connections to the intranet are sent through the DirectAccess IPsec tunnels. Connections to Internet resources are sent directly to the Internet servers. This means there are two active paths: one path (the DirectAccess IPsec tunnels) carries traffic to and from the intranet, and a second path, for everything else (including Internet access). If this seems familiar to you, then you’re probably right – this configuration is sometimes referred to as “split tunneling”.

Now, split tunneling has a bit of a history behind it and like all issues that have a history, there are many people who might carry the historical baggage with them. Split tunneling had been considered in the past to be a potential security issue for remote access VPN client connections, and that’s where the idea of split tunneling got it’s checkered reputation. Because of this, many firms will not allow split tunneling. However, this attitude is slowly changing, as we’ve found that about half of enterprises now allow split tunneling for their remote access VPN client connections.

For more information on split tunneling issues, check out my articles:

Why Split Tunneling is not a Security Issue with DirectAccess
http://blogs.technet.com/b/tomshinder/archive/2010/03/02/why-split-tunneling-is-not-a-security-issue-with-directaccess.aspx

More on DirectAccess Split Tunneling and Force Tunneling
http://blogs.technet.com/b/tomshinder/archive/2010/03/30/more-on-directaccess-split-tunneling-and-force-tunneling.aspx

Although we don’t consider split tunneling to introduce security issues when compared to non-split tunneling configurations, many organizations still do. For that reason, we’ve made it possible to disable split tunneling for DirectAccess clients, using a configuration that we refer to as “Force Tunneling”. When Force Tunneling is enabled, all traffic is sent over the DirectAccess IPsec tunnels, so that both intranet bound and Internet bound traffic is sent over the DirectAccess tunnels. While this will exact a performance toll on the DirectAccess server, it does enable you to force all traffic over the DirectAccess connections.

So what happens to the Internet bound traffic after it goes over the DirectAccess tunnels? UAG SP1 provides you two options:

• DirectAccess clients can be configured to use a web proxy (which limits them to HTTP and HTTPS when connecting to the Internet)
• DirectAccess clients can be configured to “bounce” Internet connections off the UAG DirectAccess server by taking advantage of the UAG NAT64/DNS64 service. This option enables the DirectAccess clients to use any protocol to connect to the Internet

In the Test Lab Guide I go over both of these configuration options. When testing access through a web proxy, you’ll be using TMG 2010 as the web proxy provider.

I hope you like this Test Lab Guide! Let me know if there’s anything that you think I should add to it, or if there are some other configuration options you’d like to have included to make it more comprehensive. If you have problems with this Test Lab Guide, or any other Test Lab Guide, let me know! Just write to the email address in my sig line and I’ll get right back to you.

HTH,

Tom

Tom Shinder
tomsh@microsoft.com
Knowledge Engineer, Microsoft DAIP iX/SCD iX
UAG Direct Access/Anywhere Access Group (AAG)
The “Edge Man” blog (DA all the time): http://blogs.technet.com/tomshinder/default.aspx
Follow me on Twitter: http://twitter.com/tshinder
Facebook: http://www.facebook.com/tshinder

Hey folks – since the TLGs are typically put up only in the download center, it makes discoverability of some of the cool content inside of them hard when it comes to search engines. Therefore, I’m going to post the full text of the TLGs on the Edge Man blog. However, I recommend that you download the Word .doc version of the TLGs when you actually put together your Test Lab using the Test Lab Guides.

For a downloadable version of the Test Lab Guide – Demonstrate UAG SP1 RC DirectAccess with NAP check out:

http://go.microsoft.com/fwlink/?LinkId=205354

==================================================

Introduction

DirectAccess is a new feature in the Windows 7 and Windows Server 2008 R2 operating systems that gives users the experience of being seamlessly connected to their intranet any time they have Internet access. With DirectAccess enabled, requests for intranet resources (such as e-mail servers, shared folders, or intranet Web sites) are securely directed to the intranet, without requiring users to connect to a VPN. DirectAccess provides increased productivity for a mobile workforce by offering the same connectivity experience both inside and outside the office.

Forefront Unified Access Gateway (UAG) SP1 RC extends the value of the Windows DirectAccess solution by adding features that meet the requirements of many enterprise deployments:

• Support for arrays of up to 8 UAG DirectAccess servers where configuration is done once on an array master and is automatically deployed to all other members of the array
• Support for Network Load Balancing, which enables the UAG DirectAccess SP1 RC array to be highly available without requiring the use of an external hardware load balancer
• Support for IPv4-only networks, network segments, or server or application resources with the help of NAT64/DNS64 IPv6/IPv4 transition technologies.

Network Access Protection (NAP), built into Windows Server 2008 R2 and Windows 7, enforces health requirements by monitoring and assessing the health of client computers when they attempt to connect or communicate on a network. Client computers that are not in compliance with system health requirements can be provided with restricted network access until their configuration is updated and brought into compliance.

Combining DirectAccess with NAP allows you to verify that DirectAccess client computers meet your system health requirements before allowing access to the intranet.

To learn more about UAG DirectAccess, see the following resources:

· Forefront UAG DirectAccess Design Guide

· Forefront UAG DirectAccess Deployment Guide

To learn more about NAP, see the Network Access Protection Product Information Web site.

UAG DirectAccess SP1 RC enables you to deploy DirectAccess and NAP in two different ways. You can deploy a NAP infrastructure on your intranet that can be used by all systems on your network where the NAP infrastructure components are installed on one or more servers on your intranet. This option was available prior to UAG DirectAccess SP1 RC. A new option available with UAG DirectAccess SP1 RC is the ability to host the NAP server (Network Policy Server) and the Health Registration Authority on the UAG servers themselves. This option is useful if you don’t already have an established NAP deployment and want to focus your NAP design on DirectAccess clients only. We will enable the new NAP option in this Test Lab Guide.

In this guide

This guide provides step-by-step instructions for configuring UAG DirectAccess SP1 RC with NAP in a test lab so that you can see how it works. You will set up and deploy UAG DirectAccess SP1 RC using five server computers, two client computers, Windows Server 2008 R2 Enterprise edition, and Windows 7 Ultimate Edition. The Test Lab simulates intranet, Internet, and a home networks, and demonstrates Forefront UAG DirectAccess with NAP. The starting point for this paper is the Test Lab Guide: Demonstrate UAG SP1 RC DirectAccess .

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, please see the Forefront UAG DirectAccess design guide and the Forefront UAG DirectAccess deployment guide

Overview of the test lab scenario

In this test lab scenario, Forefront UAG DirectAccess SP1 RC 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 DirectAccess SP1 RC 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 SP2 (APP3) that is configured as an IPv4 only web and file server. This server is used to highlight the UAG’s NAT64/DNS64 capabilities.
• One standalone server running Windows Server 2008 R2 Enterprise Edition (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 domain member client computer running Windows 7 Ultimate Edition (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 subnet by NAT1.
• The Internet subnet (131.107.0.0/24).
• The Corpnet subnet (10.0.0.0/24) separated from the Internet by the Forefront UAG 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 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.
• Five computers or virtual machines that meet the minimum hardware requirements for Windows Server 2008 R2 Enterprise; two 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 (NAT1).
• The product disc or a downloaded version of Microsoft Forefront Unified Access Gateway (UAG) SP1 RC.
• Access to a live network where CLIENT1 can be temporarily attached to download Microsoft Security Essentials and update the antimalware signatures.

This Test Lab Guide demonstrates UAG DirectAccess SP1 RC with NAP in full enforcement mode where the UAG DirectAccess SP1 RC server requires health certificates for authentication to access resources through the intranet tunnel. Noncompliant UAG DirectAccess SP1 RC clients cannot access the intranet and cannot use their computer certificate for authentication of the intranet tunnel.

For more information about the different modes of NAP, see Stages of a NAP Deployment.

Important

The following instructions are 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 clearly show the desired functionality. It is important to remember that 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 test lab configuration to a pilot or production deployment can result in configuration or functionality issues. To ensure proper configuration and operation of UAG DirectAccess with NAP for your pilot or production DirectAccess deployment, use the information in Planning Forefront UAG DirectAccess with Network Access Protection (NAP) for your planning and design decisions and Forefront UAG DirectAccess Deployment Guide for the steps to configure the UAG DirectAccess server and supporting infrastructure servers.

Steps for configuring the test lab

The following sections describe how to configure UAG1, APP1 and CLIENT1 for UAG DirectAccess SP1 RC with NAP. After UAG1, APP1 and CLIENT1 are configured, this guide provides steps for demonstrating NAP functionality for CLIENT1 when it is connected to the Homenet subnet.

Note

You must be logged on as a member of the Domain Admins group or 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. For all tasks described in this document you can use the CONTOSO\User1 account created when you went through the steps in the UAG DirectAccess Test Lab Guide: Demonstrate UAG SP1 RC DirectAccess.

The following procedures are performed to enable and allow you to test each of them:

· 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.

· STEP 2: Install the CA Server Role on APP1. In this step you will install a subordinate Certification Authority on APP1 so that it will be able to create health certificates for DirectAccess NAP clients.

· STEP 3: Configure the Subordinate CA and CA Permissions on APP1. In this step you will configure the subordinate CA on APP1 so that it will automatically grant certificates when requested by the UAG1, which is configured as a Health Registration Authority. You will also configure permissions on the CA to enable UAG1 to issue and manage certificates, manage the CA and request certificates.

· STEP 4: Configure UAG1 as an NPS Server and NAP health Registration Authority (HRA). In this step you will reconfigure the DirectAccess settings on UAG1 to support NAP policy enforcement for DirectAccess clients. After you complete this step, UAG1 will be configured as a Network Policy Server that provides NAP server functionality, as well as a Health Registration Server (HRA).

· STEP 5: Verify NAP Configuration on CLIENT1. In this step you will confirm that CLIENT1 received the Group Policy settings required for NAP clients and confirm that CLIENT1 received a health certificate from UAG1.

· STEP 6: Install Microsoft Security Essentials on CLIENT1. In this step you will connect CLIENT1 to a live portion or your network so that it can download and install Microsoft Security Essentials.

· STEP 7: Confirm that CLIENT1 Passes NAP Evaluation. In this step you will move CLIENT1 to the Homenet subnet and confirm that CLIENT1 can pass NAP evaluation and access resources on the intranet through the intranet tunnel.

· STEP 8: Confirm that CLIENT1 cannot access the Intranet Tunnel when NAP Non-Compliant. In this step you will confirm that when CLIENT1 does not meet health requirements it will not be able to connect to resources through the DirectAccess intranet tunnel.

· Step 9: Snapshot the configuration. After completing the Test Lab, take a snapshot of the working UAG DirectAccess with NAP Test Lab so that you can return to it later to test additional scenarios.

Note

You will notice that there are several steps that begin with an asterisk (*). The * indicates that the step requires that you move to a computer or virtual machine that is different from the computer or virtual machine you were at when you completed the previous step.

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 DirectAccess with NAP. If you have already completed the steps in that Test Lab Guide and saved a snapshot or disk image of the Test Lab, you can restore the snapshot or image and begin with the next step.

STEP 2: Install the CA Server Role on APP1

In this step you will install a subordinate Certification Authority on APP1 so that it will be able to create health certificates requested by the Health Registration Authority (HRA) on UAG1 for DirectAccess NAP clients.

1. *At the APP1 computer or virtual machine, in Server Manager, under Roles Summary, click Add Roles, and then click Next.
2. On the Select Server Roles page, select the Active Directory Certificate Services check box, and click Next.
3. On the Introduction to Active Directory Certificate Services page, click Next.
4. On the Select Role Services page, verify that the Certification Authority check box is selected, and then click Next.
5. On the Specify Setup Type page, click Standalone, and then click Next.
6. On the Specify CA Type page, click Subordinate CA, and then click Next.
7. On the Set Up Private Key page, click Create a new private key, and then click Next.
8. On the Configure Cryptography for CA page, click Next.
9. On the Configure CA Name page, under Common name for this CA, enter corp-APP1-SubCA, and then click Next.
10. On the Request Certificate from a Parent CA page, choose Send a certificate request to a parent CA, and then click Browse.
11. In the Select Certification Authority dialog box, click corp-DC1-CA, and then click OK.
12. Verify that DC1.corp.contoso.com\corp-DC1-CA is displayed next to Parent CA, and then click Next.
13. Click Next to accept the default database settings, and then click Install.
14. Verify that all installations were successful, and then click Close

STEP 3: Configure the Subordinate CA and CA Permissions on APP1

In this step you will configure the subordinate CA on APP1 so that it will automatically grant certificates when requested by UAG1. You will also configure permissions on the CA to enable UAG1 to issue and manage certificates, manage the CA and request certificates.

1. On the APP1 computer or virtual machine, click Start, type certsrv.msc, and then press ENTER.
2. In the Certification Authority console tree, right-click corp-APP1-SubCA, and then click Properties.
3. Click the Policy Module tab, and then click Properties.
4. Choose Follow the settings in the certificate template, if applicable. Otherwise, automatically issue the certificate, and then click OK.
5. When you are prompted that AD CS must be restarted, click OK twice.
6. In the console tree, right-click corp-APP1-SubCA, point to All Tasks, and then click Stop Service.
7. Right-click corp-APP1-SubCA, point to All Tasks, and then click Start Service

8. In the console tree of the Certification Authority snap-in, right-click corp-APP1-SubCA, and then click Properties.

9. Click the Security tab, and then click Add.

10. Click Object Types, select Computers, and then click OK.

11. Type DC1, and then click OK.

12. Click DC1, select the Issue and Manage Certificates, Manage CA, and Request Certificates check boxes under Allow, and then click OK.

13. Close the Certification Authority console

STEP 4: Configure UAG1 as a NPS Server and NAP Health Registration Authority (HRA)

In this step you will reconfigure the DirectAccess settings on UAG1 to support NAP policy enforcement for DirectAccess clients. After you complete this step, UAG1 will be configured as a Network Policy Server that provides NAP server functionality, as well as a Health Registration Server (HRA). In addition the Connection Security Rule on the UAG DirectAccess server that controls access to the intranet tunnel will require DirectAccess clients to present a health certificate to successfully authenticate.

1. *At the UAG1 computer or virtual machine, click Start and then click All Programs. Click Microsoft Forefront UAG and then click Forefront UAG Management.
2. In the User Account Control dialog box, click Yes.
3. In the Microsoft forefront Unified Access Gateway Management console, click the DirectAccess node in the left pane.
4. In the right pane of the console, in the Step 2 DirectAccess Server section, click the Network Access Protection link.
5. This starts the Network Access Protection Configuration wizard. On the NAP Enforcement page, put a checkmark in the Use NAP to verify DirectAccess client computers are compliant with network health policies checkbox, and then select the Enforcement mode. Only compliant DirectAccess client can connect option. Click Next.
6. On the HRA and NPS page, select the The NPS and HRA roles are installed on this UAG server (UAG configures settings automatically) option. Put a checkmark in the Use Autoremediation to automatically update non-compliant computers checkbox. In the Clients can link to this URL for troubleshooting compliance issues (optional) text box, enter http://www.contoso.com/troubleshooting.txt. Click Next.
7. On the NAP Certification Authority page, click the Add button. In the Add a CA Server dialog box, click the Browse button. In the Select a CA server dialog box, click APP1.corp.contoso.com\corp-APP1-SubCA, and then click OK. In the Add a CA Server dialog box, click OK. Click Finish.
8. In the right pane of the console, click Apply Policy.
9. On the Forefront UAG DirectAccess Configuration Review page, click Apply Now.
10. In the DirectAccess Policy Configuration dialog box, click OK after you see it say Script run completed with no errors or warnings.
11. On the Forefront UAG DirectAccess Configuration Review page, click Close.
12. Open an elevated command prompt. In the Command Prompt window, enter gpupdate /force and press ENTER. Close the Command Prompt window after the command completes.
13. In the right pane of the console, click Activate.
14. In the Activate Configuration dialog box, click Activate. Click Finish when Activation completed successfully.

STEP 5: Verify NAP Configuration on CLIENT1

In this step you will confirm that CLIENT1 received the Group Policy settings required for NAP clients and confirm that CLIENT1 received a health certificate from DC1.

1. *Connect CLIENT1 to the Corpnet subnet. Wait until the network icon in the notification area of the desktop displays a yellow caution sign.
2. Click Start, click All Programs, click Accessories, right-click Command Prompt, and then click Run as administrator. Click Yes at the User Account Control prompt.
3. In the command prompt window, run the gpupdate /target:computer command.
4. In the command prompt window, run the netsh nap client show grouppolicy command.
5. In Enforcement clients, IPsec Relying Party should be set to Enabled.
6. In Trusted server group configuration, URL should be set to https://uag1.contoso.com/domainhra/hcsrvext.dll.

STEP 6: Install Microsoft Security Essentials on CLIENT1

The UAG SP1 RC DirectAccess wizard has configured the SHV on the NAP server to use the default settings. One of these settings is to require that that a healthy client have an anti-virus application installed and that it is up to date. In this step you will connect CLIENT1 to a live portion or your network so that it can download and install Microsoft Security Essentials.

1. Move CLIENT1 to a live portion of your network and assign CLIENT1 a valid IP address that enables it to access the Internet to download Microsoft Security Essentials.
2. Open Internet Explorer and browse to https://www.microsoft.com/security_essentials. On the Security Essentials web site, click Download Now.
3. Close Internet Explorer after the download is complete.
4. Double click on the mssefullinstall-amd64fre-en-us-vista-win7 file that you downloaded.
5. In the User Account Control dialog box, click Yes.
6. On the Welcome to the Microsoft Security Essentials 1.0 Installation Wizard page, click Next.
7. On the Microsoft Security Essentials License Agreement page, click I accept.
8. On the ready to install Microsoft Security Essentials page, click Install.
9. On the Completing the Microsoft Security Essentials Installation Wizard page, click Finish.
10. In the Microsoft Security Essentials window, click the Update button.
11. After the update is complete, close the Microsoft Security Essentials window.

STEP 7: Confirm that CLIENT1 Passes NAP Evaluation

In this step you will move CLIENT1 to a Homenet subnet and confirm that CLIENT1 can pass NAP evaluation and access resources on the intranet through the intranet tunnel.

1. Move CLIENT1 to the Homenet subnet.
2. Open an elevated command prompt. In the Command Prompt window, enter napstat and press ENTER. You will see a balloon that says Network Access Protection You have full network access. Close the Command Prompt window.
3. Click Start, enter mmc in the Search box and press ENTER. In the User Account Control dialog box, click Yes.
4. In the Console window, click File and click Add/Remove Snap-in.
5. In the Add or Remove Snap-ins dialog box, click Certificates and click Add.
6. In the Certificates dialog box, select Computer account and click Next.
7. In the Select Computer dialog box, select Local computer and click Finish.
8. In the Add or Remove Snap-ins dialog box, click OK.
9. In the left pane of the console window, navigate to Certificates (Local Computer)\Personal\Certificates. In the middle pane of the console, notice that there is a certificate issued by corp-APP1-SubCA. Double click on that certificate.
10. In the Certificate dialog box, on the General tab, note that in the This certificate is intended for the following purposes(s): section that one of the intended purposes is System Health Authentication. This indicates that CLIENT1 has passed NAP inspection and should now have access to the intranet tunnel.
11. In the Certificate dialog box, click OK. Minimize the Console1 window.
12. Click Start and in the Search box, enter \\app3\files and press ENTER.
13. Double click on the Example file. You can now read the contents of that file. This confirms that you have access to the Corpnet subnet over the intranet tunnel, since APP1 is not a member of the infrastructure servers group. Close the Windows Explorer window that shows the contents of the Files share. Close the Notepad window.
14. Click Start and then enter wf.msc in the Search box and press ENTER.
15. In the middle pane of the console, note that the Private Profile is Active. DirectAccess clients will only establish their DirectAccess tunnels to the DirectAccess server when either the Public or Private Profiles are active.
16. In the right pane of the console, click Properties. In the Windows Firewall with Advanced Security dialog box, click the down arrow next to Firewall state and click Off. Click OK. You will see two balloons appear in the system notification area. One will ask that you turn on the Windows Firewall and the second will inform you that network access may be limited. Note in the middle pane that it says Windows Firewall is off. Click Refresh in the right pane. NAP auto-remediation automatically enabled the Windows Firewall after it was turned off.
17. In the left pane of the console, navigate to Windows Firewall with Advanced Security\Monitoring\Security Associations\Main Mode. Notice the Main Mode entry that has User (Kerberos V5) as the second authentication method. This indicates that the user was able to access the intranet tunnel since the intranet tunnel requires user authentication. In addition, when NAP is enabled for DirectAccess clients, the computer certificate used to authenticate the intranet tunnel is the Health Certificate, indicating that the computer was able to pass NAP inspection.
18. Minimize the Windows Firewall with Advanced Security window.

STEP 8: Confirm that CLIENT1 cannot access the Intranet Tunnel when NAP Non-Compliant

In this step you will confirm that when CLIENT1 does not meet health requirements it will not be able to connect to resources through the DirectAccess intranet tunnel. In the test lab, DC1 is accessible through the infrastructure tunnel and APP1 is accessible through the intranet tunnel. When the UAG DirectAccess NAP client fails validation, it can only access resources available through the infrastructure tunnel.

1. On CLIENT1, click Start and then in the Search box, enter services.msc and press ENTER.
2. In the right pane of the Services console, double click on Microsoft Antimalware Service.
3. In the Microsoft Antimalware Service Properties (Local Computer) dialog box, click the Stop button. Click OK and then minimize the Services console.
4. Notice that a Network Access Protection Network access might be limited balloon appears. This indicates that CLIENT1 no longer passes NAP inspection. In the Microsoft Security Essentials dialog box, click the Close control button (the “x” in the upper right) to close the dialog box.
5. Restore the console window that has the Certificates snap in installed. Right click the middle pane and click Refresh. Notice that the health certificate no longer appears. When the client does not pass NAP inspection, the certificate is removed from the machine’s computer store.
6. Restore the Windows Firewall with Advanced Security console and click Refresh in the right pane of the console. Notice that the Main Mode security association using Kerberos V5 as the 2^nd Authentication Method is no longer there. This indicates that the client is no longer able to establish the intranet tunnel because it cannot provide a health certificate for computer authentication.
7. Click Start and enter \\app1\files in the Search box and press ENTER. After a few moments you will see a Network Error dialog box indicating that Windows cannot access the share. This is consistent with the fact that CLIENT1 needs access to the intranet tunnel to access APP1 and the fact that the intranet tunnel is not available because CLIENT1 current does not pass NAP inspection. Click Cancel in the Network Error dialog box.
8. Click Start and enter \\dc1\files in the Search box and press ENTER. In this case the Files share is available. The reason for this is that access to servers in the infrastructure servers list is accessible over the infrastructure tunnel.
9. Restore the Services console and right click Microsoft Antimalware Service and click Start.
10. Click Start and enter \\app1\files in the Search box and press ENTER. You can now access APP1 over the intranet tunnel because CLIENT1 is able to pass NAP inspection.
11. Close all open windows on CLIENT1 and do not save the changes to any of the mmc consoles.

STEP 9: Snapshot the Configuration

This completes the UAG SP1 RC DirectAccess with NAP test lab. To save this configuration so that you can quickly return to a working UAG SP1 RC DirectAccess with NAP 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 TLG UAG DirectAccess SP1RC NAP. 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 to configure UAG SP1 RC DirectAccess on which this document is based, see the Test Lab Guide: Demonstrate Forefront UAG SP1 RC DirectAccess.

For a comprehensive list of UAG DirectAccess Test Lab Guides, please see Test Lab Guides.

For the design and configuration of your pilot or production deployment of DirectAccess, see the Forefront UAG DirectAccess design guide and the Forefront UAG DirectAccess deployment guide.

For information about troubleshooting DirectAccess, see the DirectAccess Troubleshooting Guide.

For information on troubleshooting UAG DirectAccess in a Test Lab, see Test Lab Guide: Troubleshooting UAG DirectAccess.

For more information about DirectAccess, see the DirectAccess Getting Started Web page and the DirectAccess TechNet Web page.

==================================================

Tom Shinder
tomsh@microsoft.com
Knowledge Engineer, Microsoft DAIP iX/SCD iX
UAG Direct Access/Anywhere Access Group (AAG)
The “Edge Man” blog (DA all the time): http://blogs.technet.com/tomshinder/default.aspx
Follow me on Twitter: http://twitter.com/tshinder
Facebook: http://www.facebook.com/tshinder

The march of the Test Lab Guides continues!

Today I’m offering up to you a Test Lab Guide I think you’re really going to like – the Test Lab Guide – Demonstrate UAG SP1 RC DirectAccess with NAP. In this Test Lab Guide, we change up the NAP settings by putting the Network Policy Server (NPS) and Health Registration Authority (HRA) on the UAG DirectAccess server itself. This is in contrast to how we did it in the previous Test Lab Guide for NAP (Test Lab Guide: Demonstrate UAG DirectAccess and NAP), where we set up the NPS server and the HRA server on DC1. The ability to put the NPS and HRA servers on the UAG server itself is new with UAG SP1.

Why would you want to put the NPS and HRA servers on the UAG server or the servers in the UAG DirectAccess array?

Some reasons why you might want to do this include:

• You don’t have a NAP infrastructure yet, and you want a quick and easy way to test NAP
• You don’t have a NAP infrastructure yet, but you are planning on deploying NAP for DirectAccess clients, so putting the NPS and HRA servers on the UAG array members seems like a smart way of doing things.
• You want to deploy NAP for your UAG DirectAccess clients, but you don’t have a lot of time to learn about NAP, so you need a quick and easy way to get NAP deployed
• You want to deploy NAP for both DirectAccess clients and internal clients, but you haven’t put together the NAP solution yet, but you’d like to easily deploy NAP for your UAG DirectAccess pilot deployment

Of course, there might be other reasons why you’d like to put the NPS and HRA servers on the UAG DirectAccess server or array members. And, you might find that you like NAP so much that after you’ve deployed it for your DirectAccess clients, you’ll want to create a larger deployment. That option is still available to you.

I hope you like the Test Lab Guide – Demonstrate UAG SP1 RC DirectAccess with NAP!

Let me know if there is anything I can do to improve it – or if there are other features or configuration options regarding DirectAccess and NAP that you’ll want to see in the RTM version of the document. Also, if you want any questions or need help with the TLG, just let me know! Write to me at the address in my sig line and I’ll get right back to you.

HTH,

Tom

Tom Shinder
tomsh@microsoft.com
Knowledge Engineer, Microsoft DAIP iX/SCD iX
UAG Direct Access/Anywhere Access Group (AAG)
The “Edge Man” blog (DA all the time): http://blogs.technet.com/tomshinder/default.aspx
Follow me on Twitter: http://twitter.com/tshinder
Facebook: http://www.facebook.com/tshinder