UAG SP1 DirectAccess: Connectivity Assistant v1.5

Author by Shannon Fritz

Deploying the DirectAccess Connectivity Assistant (DCA) with UAG Service Pack 1 is much easier when compared to RTM (read about it here). Rather than needing to write your own Group Policy to configure the app, the UAG wizard now walks you through the configuration and incorporates the setting right in the policy used to enable DirectAccess. All you need to do is install or deploy the client. To get started, click the Connectivity Assistant listed under Optional Settings in "Step 1".

Client Connectivity

Your first option is to decide if you should allow users to use Local Name Resolution or not. This provides users the ability to query the DNS servers configured on their network adapter instead of using the NRPT rule which would direct them to use corporate DNS servers. This may seem contrary to how DirectAccess works, and it is, but it can be usful when troubleshooting or in some cases when the NLS is offline for some reason. On the other hand, you may want to disable this so users cannot accidentlly slect this option if they are poking around. It's on by default so I tend to leave it enabled. It's important to note that the DirectAccess Connectivity Assistant does not really test the DirectAccess components, it is just testing for the Connectivity that DirectAccess is meant to provide.

Connection Verification

This second page gives you a opportunity to list some of the resources that the DCA should test against to prove that connectivity is functional or not. These resources should be things that are reachable over DirectAccess and when connecting to the local network at the corpnet. There are three tests that you can perform.
  1. FILE: Enter the full UNC path to a file on your corpnet. I like to use a txt file placed in the same location as the DCA MSI files as the share and permissions are already configured. Example: filesrv.domain.comsharedcatest.txt
  2. HTTP: Enter the FQDN of a web server on your corpnet. You can use an existing web server like a Sharepoint or anything that does not require authentication, or you could stand up a new web site.  Given the option, I like to create a new "dca" iis site much like we did for the NLS.  Note: DO NOT USE THE NLS HERE.  Remember the Network Location Server is NOT reachable over DirectAccess so it would not be a good test.  Example: http://intranet.domain.com/
  3. HTTPS: Just like the HTTP test, except this supports SSL encrypted web sites. Remember, you should be using internal resources, not a site on the Internet. Example: https://intranet.domain.com/
In v1.5 of the DCA a PING test is no longer an option.  It really should not have been in the earlier version either becuase ICMP Echo requests do not traverse the IPSec tunnels and therefore could yield a false positive about the status of "corporate connectivity".

Troubleshooting Portal

The system tray balloon that the DCA presents to the users is pretty basic and asside from showing users the status of "Corporate Connectivity", it also provides a link to the "Troubleshooting Portal".  This is just a web site, any web site, that you decide to direct users to. This can be your internal web server or a public one.  Consider creating a web page that will give the users some guidance related to DirectAccess or at least drop them on your IT Support site.

Diagnostic Logging

If you want to give your users the ability to send you some Diagnostic information without needing to know how to attach a file or run any commands from an elevated command prompt, you can enter an email address here which will provide the users with a button they can click to send you a file that includes a lot of intormation about their connection. You can also specify your own script to include in the diagnostics if you find there is something more that you want to know that might not be included in the default diagnostics analysis.  This script needs to already be on the DirectAccess client, so you will need to pre-stage the deployment of the script to the client somehow.  Otherwise leave that blank and click finish. Now you can apply these settings in the UAG wizard to save the settings into Group Policy, and then you can install the software on one of your test DirectAccess workstations.

DCA Installation

The last step is to simply install the DCA on a client machine, and you can do this using any number of software deployment options including a manual install, using SCCM or even distribute it via Active Directory.  For testing things out I'd just install it manually, but for deployment to the work force I like the last option as it allows me to easily install the DCA on all computers that are added to the security group that enabled DirectAccess as well as automatically remove the software if the computer is ever removed from the group.  Below are instructions on how to deploy the client via Group Policy.

Stage the Installer

First you need to place the .msi file on a network path that your computers can access.  I prefer to create a new share someplace that "everyone" is given read access to.  The installer for the DirectAccess Connectivity Assistant can be found on the UAG server in %ProgramFiles%Microsoft Forefront Unified Access Gatewaycommonbindadca.  Copy the MSI you find there to your file share.  This is a 32-bit application and will be used for both x86 and x64 DirectAccess clients.

Create App Deployment Policy

Becuase the client application settings are stored in the UAG DirectAccess Client policy that is manged by the UAG wizard, let's create a new policy that will be used only to install or remove the software itself.  Open up the Group Policy Management MMC, navigate to the Group Policy Objects container and create a new policy named “Deploy DCA”. Change the Scope of the Policy so it will only apply to members of the UAG DirectAccess Enabled Computers group.  This would be the same group that you set in the UAG Clients Wizard earlier. Right click the "DirectAccess Connectivity Assistant" policy you just created and select "Edit...". This will open the GPO Editor.  All of the settings we will configure here will apply only to the computer, so we can disable the user section.  Just right click the name of the policy, select Properties and check the box to Disable the User portion.

Create the Software Installation Package

Still in the GPO editor, navigate to Computer Configuration, Policies, Software Settings.  Right click Software Installation and select New > Package...  When the "Open" dialoge box appears, browse to and select the .msi file from the UNC path that you've already shared for "everyone" to read. When asked about the Deployment method select Assigned and click OK. Right click the new Package you've created and select Properties.  I like to change the name to just "DirectAccess Connectivity Assisntant" but you can call it whatever you feel is appropriate.  On the Deployment tab, check the option to "Uninstall this application when it falls out of the scope of management" which will cause the software to only be installed when this policy actually applies to the computer. You're all done!  Click OK and close the GPO Editor.  In the GPO Manager you can now link this policy at the Domain level or to any OU you feel is appropriate. To get the DCA installed you need only to add a computer to the DirectAccess Enabled Computers group and make that computer update group policy (run gpupdate or reboot it). You may need to do it twice, once to get the policy and once to get the software, but you should see an icon appear in the system tray and that’s it! Now you can use the DCA for troubleshooting. Just right click the icon in the system tray to open the Advanced Diagnostics and click the link to open and read the log file it generates.

Author

Shannon Fritz

Infrastructure Architect & Server Team Lead