UPDATE: My guide for Configuring DirectAccess with UAG Service Pack 1 has been released!
Read it here.
The use and function of DirectAccess is intended to be completly transparent to the end user, so by design, a user should not know or even care if they are using DirectAccess vs. being on the local corporate LAN. This is great when things are working as expected, but what happens when something is wrong? The only way to diagnose problems is to run a series of lengthy commands and decipher the meaning of their output, and as any tecnician call tell you it is hardly worth the effort to try to get most users to type "ipconfig /all" and read back the output let alone trying to get them to type something longer like "netsh dnsclient show state".
This is where the
DirectAccess Conectivity Assistant (DCA) comes into play. The DCA is a fairly simple utility that can give an end user some insight to the status of "Corporate Connectivity" as well as position Helpdesk personel to more easily diagnose a situation. Notice I said "Corporate Connectivity" and not "DirectAccess". This is because the DCA does not directly test DirectAccess itself, rather it tests connecivity to some predefined corporate resources and simply reports on the status of those tests. If the tests are sucessful then "corporate connectivity" is reported as good but if one of those tests fails then it's reported to have problems.
These connectivity tests must be successful regardless of the location of the subject workstation, be it inside the corporate network or outside and on the Internet; if they are using DirectAccess it should be successful in both locations (Note: This means do not use the NLS in a test). The DCA also generates a really detailed logfile that can be easily delivered to technical support personnel for in-depth analysis without the end user needing to do much more than right click an icon in the system tray.
When a user left clicks the icon (perhaps out of curiosity) they will see a very simple status indicating if "Corporate Connectivity" is working or not. They also see a link at the bottom that you can name and define the target to take the user to any web site you wish, perhaps for troubleshooting tips or other help.

If you tell the user to right click the icon and select Advanced Diagnostics the DCA will generate a comprehensive log file and give the user a button to click to email that log right to you!

You can read more about the DCA at
Jason's Closer to the Edge blog.
So how do you deploy the DCA?
I find the best way to install the DCA is by using a Group Policy that is filtered against security group membership, similar to the way DirectAccess itself is enabled on a computer. Besides that, the DirectAccess Connectivity Assistant is completely configured by Group Policy so you are going to make a policy anyway. You might as well use it to deploy the application as well since you won't want the policy to apply unless the application exists anyway. So there will be two parts rolled into one policy:
- Software Deployment
- DCA Configuration
To get started,
grab the zip file from Microsoft Download Center. It contains the MSI files needed to install the software and the Admin Templates for configuring it in AD Group Policy.
Before getting into the settings you'll want to load up the Administrative Template that configures the DCA. There are two ways you can do this. One way, which is the quickest, is to copy the AMDX file to %systemroot%PolicyDefinitions on your domain controller, and copy the ADML file to %systemroot%PolicyDefinitionsen-US. You can do this on one or all of your DC's, it doesn't matter except that only the DC's that have these files can edit the policy (the settings will still be enforced, you just can't change them). Another way is to copy the files into Active Directory
which you can read about here but that's a bit outside the scope of this post. There are a few caveats to this option (like only ADMX templates work this way and once you have templates in AD the local templates are ignored) but the advantage of putting them into AD is that you only have to copy them once into one place and then all 2008 and newer DC's will be able to edit the settings.
Create the Policy
Open up the Group Policy Management MMC, navigate to the Group Policy Objects container and create a new policy named "DirectAccess Connectivity Assistant". Remember, we will be using this policy to deploy the software as well as configure it. All of the settings we will configure are applied to the computer section so we can disable the user section.
Right click the "DirectAccess Connectivity Assistant" policy you just created and select "Edit...". This will open the GPO Editor. From the top of the list on the left, right click on "DirectAccess Connectivity Assistant" and select Properties. Fromt the General tab, check the box to "Disable User Configuration settings".

Click OK and you're ready to begin.
Software Deployment
To deploy an application through Active Directory you must place the MSI files in a network location someplace. Since this software policy will be assigned to computers, you'll want to make sure that, at the very least, that share location has given the "Domain Computers" group Read access. You can also use "Authenticated Users" or "Everyone" but generally that's wider rights than is needed.
You should already have the GPO editor open so navigate to Computer Configuration > Policies > Software Settings > Software Installations. Right click and add a New > Package...

You'll need to select the MSI file to be distributed in this policy. Browse to the full UNC path of the share and select "Microsoft_DirectAccess_Connectivity_Assistant_x86.msi" (we'll add the x64 one in just a moment) and click Open. When asked about the Deployment method select Assigned and click OK.

Now right click the new package and select Properties.

From here I like to rename the package to "DirectAccess Connectivity Assistant x86". On the Deployment tab select "Uninstall this application when it falls out of the scope of management" which will cause the software to only be installed when this policy applies to the computer. Click the Advanced button and uncheck the option for "Make this 32-bit X86 Application available to Win64 machines" and click OK. That's it, click OK.

Now do the same thing for the x64 MSI file, except this time there is nothing to do on the Advanced button since it will only be available to Win64 machines. When you are done you should have two packages, one for x86 and one for x64 so each platform will get it's native application. Now we can configure the application.
DCA Configuration
You should still have the same policy open the the GPO Editor. Navigate to Computer Configuration > Policies > Administrative Templates > DirectAccess Connectivity Assistant. If you do not see DCA listed under the Templates then you have not loaded the ADMX template and you'll need to do that first. If all of your domain controllers are Windows 2003 (or you are trying to edit it from an XP machine), then you'll need to open run the editor from another machine running Windows 7 or 2008 so you can read the ADMX files.
All of the options in this template are fairly straight forward, except for perhaps the "DTEs". Regardless, I'll go through each one.

First, the items that users will see in the DCA User Interface...
- PortalName: The text used in the link on the popup window and the title under Advance Diagnostics.
- Corporate Portal Site: The target of the link on the popup window and the URL show in Advanced Diagnostics.
- Support Email: Used to pre-populate the To: field of the email when sending the generated log files from Advanced Diagnostics. If you leave this blank the Email Logs button will be disabled.

And now the "behind the scenes" settings...
- Corporate Resources: There are three kinds of tests that the DCA can perform to validate that connectivity to corporate resources is functioning: PING, HTTP and FILE tests. You can do as many or as few of the tests as you wish. I prefer to do at least one of each type.
- PING: Enter the FQDN of a server on your corpnet that will respond to ping. A Domain Controller is a good candicate or just ping your domain name and one of any of your DC's should respond to it.
Example: PING:domain.com
- HTTP: Enter the FQDN of a web server on your corpnet. You can stand up web site much like we did for the NLS or use an existing web server.
Example: HTTP:http://intranet.domain.com/
- 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: FILE:filesrv.domain.comsharedcatest.txt

You can leave "LocalNamesOn" and "Admin Script" set as Not Configured and you are done in here. You can close the GPO Editor.
Apply the Policy
Let's make sure that this policy can only be applied to computers that actually use DirectAccess. From the GPO Manager, select the "DirectAccess Connectivity Assistant" policy that we just configured and change the Security Filtering to apply only to the "DirectAccess Enabled Computers" group that you used in the
DirectAccess Clients Wizard.

Now you can link this policy at the Domain level or to any OU you feel is appropriate. To install the DCA just 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.