When DirectAccess first appeared as a feature in Windows Server 2008 R2, one of the challenges was determining quickly and easily if a DirectAccess client had successfully established remote network connectivity, and more importantly if that connection was unsuccessful or had dropped for any reason. To address this issue, Microsoft released the DirectAccess Connectivity Assistant (DCA) version 1.0, first introduced in February of 2010 as part of the Windows Optimized Desktop Toolkit. It has been updated a number of times since its initial release, and in Windows 8 the DCA functionality is now part of the base operating system. The DCA is helpful from a diagnostic and troubleshooting perspective, as it provides an intuitive visual indicator for DirectAccess connectivity status. More importantly, the DCA is required to support One-Time Passwords (OTP).
As of this writing, the latest version of the DCA is version 2.0, which can be downloaded here. DCA 1.0 and 1.5 are both supported with Windows Server 2012 DirectAccess, unless you need to provide support for OTP, which of course will require DCA 2.0. It is possible to perform an in-place upgrade from DCA 1.5, but if you’ve deployed DCA 1.0 you’ll have to uninstall prior to installing DCA 2.0. It’s important to understand that DCA 2.0 is explicitly NOT supported with Windows Server 2008 R2 DirectAccess or Server 2008R2/Forefront UAG DirectAccess. In addition, the DCA 2.0 MSI installation package can be deployed automatically using Active Directory Group Policy, System Center Configuration Manager, or any other third-party software distribution tool.
To install and configure DCA 2.0 on your Windows 7 DirectAccess clients, download DCA 2.0 and extract all of the files, then run the either the 32 bit or 64 bit version of the MSI on the client, depending on your operating system. The settings for the DCA are managed exclusively with group policy, so once you’ve installed DCA 2.0 on the client, log on to a domain controller and copy the file DirectAccess_Connectivity_Assistant_2_0_GP.admx to the C:\Windows\PolicyDefinitions folder. In addition, copy the file DirectAccess_Connectivity_Assistant_2_0_GP.adml to the C:\Windows\PolicyDefinitions\en-US folder. Next open the Group Policy Management Console and locate the Group Policy Object (GPO) for your DirectAccess client settings. Right-click the GPO and choose Edit.
In the Group Policy Management Editor expand Computer Configuration, Policies, and Administrative Templates and then highlight DirectAccess Connectivity Assistant. Double-click Support Email, select the option to enable the setting and enter an e-mail address. This setting is optional, but is required if you want to allow your remote DirectAccess users to e-mail client logs to a helpdesk administrator.
Click Next Setting to configure the DirectAccess Dynamic Tunnel Endpoints (DTEs). Select the option to enable the setting, then click the Show button. To ensure that you are using the correct DTEs, I suggest collecting this information from the registry of the DirectAccess server by opening an elevated PowerShell prompt on the DirectAccess server and issuing the following command…
Get-Item –Path HKLM:\\SYSTEM\CurrentControlSet\Services\RaMgmtSvc\Config\Parameters
…and note the entries for DTE1 and DTE2. Copy these addresses to the GPO setting using the syntax PING:<DTE_IPv6_Address>.
Click Next Setting to configure LocalNamesOn. This setting is optional, and when enabled will allow the DirectAccess client to use local name resolution, which effectively disables DirectAccess connectivity on the client side.
Click Next Setting to configure Corporate Resources. Select the option to enable the setting and click Show. This setting enables a health check from the DirectAccess client to this resource to determine if the DirectAccess tunnels are up and that corporate network access connectivity is indeed working correctly. You can use ping, UNC file path, or an HTTP URL. I prefer to use the HTTP method as it seems to be the most reliable. Any internal web server will work, but keep in mind that if it is unavailable for any reason the DCA will indicate that network connectivity is not available when in fact it is working correctly. For that reason I’d suggest selecting a highly available (load balanced) internal web server if possible. DO NOT use the network location server (NLS) for this connectivity check. The syntax for this setting is HTTP:<internal_webserver_URL>. It is also recommended that you use the server’s FQDN when configuring this setting. You can also specify an IPv6 address, but an IPv4 address will not work.
Click Next Setting to configure the Admin Script Location. This setting is optional and used only if you want to run a custom script on the Windows 7 DirectAccess client to gather additional information used for troubleshooting.
Once you’ve completed the DCA group policy settings, refresh group policy configuration on the client by issuing a gpupdate /force command from an elevated command prompt. The DCA should now indicate that corporate network connectivity is working correctly.