Windows 7 DCA with Server 2012 DirectAccess

Anyone who has worked with UAG DirectAccess is probably familiar with the DirectAccess Connectivity Assistant (DCA), a small systray tool that installs onto the Windows 7 clients. This tool is very useful for generating log files in case you need to troubleshoot a DA connection, and it’s just a nice reference for users to be able to see whether or not their DirectAccess connection is working. In the UAG interface, there was a nice, easy way in the wizards for you to configure the DCA so that it knew what to look for in your environment and therefore report back to the user whether or not it was working properly based upon whether or not it could see those things which you defined.

In Server 2012 DirectAccess, there is no way to configure the Windows 7 DCA from inside the configuration wizards. Instead, Server 2012 DirectAccess focuses more on the Windows 8 clients, and the new version of DCA, now called NCA, which is built into Windows 8. During the Server 2012 DA wizards you define the same sort of criteria, basically telling the NCA tool what to look for, but when you are finished with these wizards and your settings are populated to the GPOs, these settings only apply to the NCA inside Windows 8. If you setup a Server 2012 DirectAccess environment, add a Windows 7 client to it, and install the DCA onto that client, it will not be configured. In this case the DCA can still be used to generate log files, but since it is not configured properly with a probe to go looking for, it will always show a status of “Not Working” with a red X.

So, by running through the Server 2012 DA wizards we have the NCA in Windows 8 working properly, but how do we get DCA in Windows 7 also configured? We basically just need to give it the same configuration settings as our NCA, but we have to do it manually, by hand, by way of a GPO.

Note: When you are sending Windows 7 clients through Server 2012 DirectAccess, you should be using DCA version 2.0 on your client machines.

Get your Active Directory ready for this new GPO

The settings for DCA are not part of Group Policy by default. You need to give one of your Domain Controllers the file that contains the settings so that when you go to configure your GPO, the settings you are looking for will exist. When you download the DCA 2.0 from Microsoft, here, it comes with a couple of files other than the installer itself. Log into a Domain Controller and do the following:

  1. Copy DirectAccess_Connectivity_Assistant_2_0_GP.admx into C:\Windows\PolicyDefinitions
  2. Copy DirectAccess_Connectivity_Assistant_2_0_GP.adml into C:\Windows\PolicyDefinitions\en-US

Create the GPO

Now let’s go ahead and create a new GPO for these settings. I try not to touch the existing DirectAccess Clients GPO which contains all of the existing DirectAccess connectivity settings, because this GPO is managed by the DirectAccess server’s wizard and any changes you make in here could potentially be overwritten by the wizard. After you create your GPO and link it wherever you would like, I recommend setting Security Filtering on that GPO (just like the DA Clients GPO does) so that it only applies to your Windows 7 DirectAccess client computers, since these are the only guys who are going to need or care about these settings.

Configure the GPO

Right-click on the GPO and “Edit”. Here are the items that we want to configure:

  1. Computer Configuration | Policies | Administrative Templates | DirectAccess Connectivity Assistant | Support Email – Enable this setting and enter a valid email address here. Chances are that nobody will ever actually use this feature to email from the DCA tool, but if you want DCA to be able to generate log files, this setting must be populated.
  2. Computer Configuration | Policies | Administrative Templates | DirectAccess Connectivity Assistant | DirectAccess Dynamic Tunnel Endpoints (DTEs) – Enable this setting and click the Show… button to input your DTEs. You should have two DTEs to input here, and you can find this information from the DirectAccess server itself.
    1. To find the DTEs, log into your DirectAccess server and open an elevated PowerShell prompt. Then run the following command: Get-Item –Path HKLM:\\SYSTEM\CurrentControlSet\Services\RaMgmtSvc\Config\Parameters
    2. In the output of this command, you will see entries listed for DTE1 and DTE2
    3. Back to the GPO screen, you want to input these two DTE settings by using PING:<DTE_Address> (as shown below)

  1. Computer Configuration | Policies | Administrative Templates | DirectAccess Connectivity Assistant | Corporate Resources – Enable this setting and click Show… On this screen we are going to define a probe that the DCA tool is going to simply go out and look for. If it can see the probe, it reports successfully connected. If it cannot see the probe, it reports that there is a problem. You can do either a PING probe where it simply pings a server, or you can do an HTTP probe which validates that it can get to a particular website. Note: It is a common mistake to input your NLS server address here. Do not do this. The NLS website is NOT visible from a DirectAccess connected computer by design, and so the DCA would always report that it was not working. Here are a couple of sample values that you could put into this setting. You only need one, but you can have more than one if you so choose:
    2. HTTP:

That’s it! Those are the important settings for making the DCA work correctly on a Windows 7 computer that is connecting in through a Server 2012 DirectAccess environment. There is one more setting in that GPO that we occasionally set, but is optional. If you enable this setting, it basically allows the users to be able to turn off DirectAccess by right-clicking on the DCA and choosing a new option called “Prefer Local DNS Names”. If you enable this setting and the user clicks on it, it will temporarily disable the NRPT on their computer, which will cause name resolution requests to stop going through the DirectAccess tunnels. There aren’t many good use-case scenarios where this option would actually be feasible, and so it is quite rare that I see it used in the wild. However, if this option sounds appealing to you, here it is:

  1. Computer Configuration | Policies | Administrative Templates | DirectAccess Connectivity Assistant | LocalNamesOn – You simply enable this option if you want the users to have this capability.

Jordan Krause
Microsoft MVP | Enterprise Security