Installing and Configuring DirectAccess Connectivity Assistant 2.0 on Windows 7 Clients

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 create a new Group Policy Object (GPO) for your Windows 7 DCA 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 complete, right-click WMI Filters in the Group Policy Management Console and choose New.


Provide a descriptive name for the new WMI filter and click Add. Enter the following WMI query and click Ok.

select * from Win32_OperatingSystem where Version like "6.1%"


Finally, edit the Security Filtering for this GPO by removing Authenticated Users and adding the DirectAccess client security group. In addition, link the GPO to the WMI filter for Windows 7 clients. Once complete, link the GPO to the domain.


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


Windows Server 2012 DirectAccess Session at TechEd 2013

Are you planning to attend Microsoft TechEd this year? If so, I’m happy to announce that I’ll be delivering a session entitled “The Future Is Now! Next Generation Remote Access Today with Windows Server 2012 DirectAccess”. I’ll be presenting at both TechEd North America in New Orleans, LA, and at TechEd Europe in Madrid, Spain. Looking forward to seeing you there!

Microsoft TechEd North America 2013

Microsoft TechEd Europe 2013

DirectAccess and NAT

One of the more common barriers to adoption for DirectAccess in Windows Server 2008 R2 and Forefront Unified Access Gateway (UAG) 2010 is the strict requirement for two consecutive public IPv4 addresses to be assigned to the external network interface of the DirectAccess server. Many small and mid-sized businesses have only a single public IPv4 address, or have a very small range of public IPv4 addresses that are already in use. For large organizations, corporate security policies often dictate that Windows-based systems cannot be internet facing, and many object to having a domain-joined Windows system exposed directly to the Internet. Further complicating matters is the fact that deploying a Window Server 2008 R2 or Forefront UAG 2010 DirectAccess server behind a border router or edge firewall performing Network Address Translation (NAT) is explicitly not supported.

Beginning with Windows Server 2012, deploying the DirectAccess server behind a border router or edge firewall performing NAT is now fully supported. No longer is there a requirement to have public IPv4 addresses assigned to the DirectAccess server’s external network interface. In fact, DirectAccess in Windows Server 2012 can be deployed with a single network adapter, allowing the DirectAccess server to be completely isolated in a perimeter or DMZ network.

Windows Server 2012 DirectAccess Network Topology

Be advised that deploying a Windows Server 2012 DirectAccess server behind a NAT device will result in all DirectAccess client communication being delivered to the server exclusively using the IP-HTTPS IPv6 transition protocol. If you are using Windows 8 clients, there’s nothing to worry about in terms of performance and scalability because Windows 8 clients leverage NULL encryption for IP-HTTPS traffic. However, Windows 7 clients cannot utilize NULL encryption and will instead encrypt all DirectAccess client communication using SSL/TLS. DirectAccess communication is already encrypted using IPsec, so this presents a problem. Double encryption places high demands on the DirectAccess server’s CPU and memory and will significantly impact performance on the client and the server. It will also impede the scalability of the solution by dramatically reducing the number of DirectAccess clients supported on a single DirectAccess server.

So, if you’re planning to deploy a Windows Server 2012 DirectAccess server behind a NAT, and you are also planning to support a lot of Windows 7 clients, please proceed cautiously. Monitor the DirectAccess server performance closely during your pilot and, if at all possible, offload SSL/TLS off box using F5 BIG-IP Local Traffic Manager (LTM) or equivalent device.

Windows Server 2012 DirectAccess Video Training Course Now Available

I’m pleased to announce that my Windows Server 2012 DirectAccess video training course is now available from TrainSignal! The course covers planning, installing, and configuring DirectAccess in Windows Server 2012 in a variety of different deployment scenarios. Here’s the course outline:

Lesson 1 – Introduction
Lesson 2 – DirectAccess Overview
Lesson 3 – Planning for DirectAccess
Lesson 4 – Configuring DirectAccess (Simplified Deployment)
Lesson 5 – Configuring DirectAccess (Complex Deployment)
Lesson 6 – Configuring DirectAccess (Multi-site Deployment)
Lesson 7 – Enabling Support for Windows 7 DirectAccess Clients
Lesson 8 – Enabling High Availability with Network Load Balancing
Lesson 9 – DirectAccess Monitoring and Reporting
Lesson 10 – DirectAccess Troubleshooting
Lesson 11 – Enabling Legacy Remote Access VPN

Special thanks goes to my friend and fellow MVP Jordan Krause who served as the technical reviewer for this series and provided valuable input and feedback during the production of the course. Before you implement DirectAccess with Windows Server 2012, be sure to sign up for a subscription at and not only will you receive this great DirectAccess training course, you’ll have access to the entire TrainSignal library of content for just $49.00 per month!

TrainSignal Windows Server 2012 DirectAcess Video Training Course

DirectAccess Clients and TPM

I’ve been frustrated recently with a number of articles and blog posts I’ve seen indicating Windows 8 DirectAccess clients connecting to a Windows Server 2012 DirectAccess server require a Trusted Platform Module (TPM) and the use of smart cards for authentication. This is a myth, and nothing could be further from the truth. TPM and smart cards are indeed supported (TPM with Windows 8, smart cards with Windows 7 and Windows 8 DirectAccess clients) but they are not explicitly required. For the posts I’ve seen I have asked the authors to correct their statements, and to their credit some of them have. Others, unfortunately, have not. I’m not sure if they are simply misinformed or if they are deliberately misleading their readers to downplay DirectAccess in an effort to sell another VPN solution. Regardless, I am compelled to set the record straight here. So, to be perfectly clear:

TPM is NOT a requirement for DirectAccess clients.

There you have it. Now go out and deploy DirectAccess today!

Windows Server 2012 DirectAccess IP-HTTPS and Windows 7 Clients

With Windows Server 2008 R2, IP-HTTPS used standard SSL cipher suites to encrypt sessions. However, those sessions are already encrypted using IPsec, which is needlessly redundant. The protocol overhead for this double encryption placed an extreme burden on the DirectAccess server in terms of CPU utilization and memory consumption. Throughput and performance suffered greatly in large deployments. To address this issue, Microsoft included two new SSL cipher suites in Windows Server 2012 and Windows 8 that use NULL encryption. IP-HTTPS sessions are fully authenticated, but encrypted only once using IPsec. This significantly reduced resource demand on the DirectAccess gateway and improves performance greatly. Unfortunately, only Windows 8 clients can take advantage of this new IP-HTTPS functionality in Windows Server 2012 DirectAccess. When Windows 7 clients establish an IP-HTTPS session with a Windows Server 2012 DirectAccess gateway they will still request the use of fully encrypted cipher suites, as shown here:

Windows 7 IP-HTTPS Client Hello

Windows 7 DirectAccess IPHTTPS Cipher Suites

Windows 8 IP-HTTPS Client Hello

Windows 8 DirectAccess IPHTTPS Cipher Suites

Windows 8.1 IP-HTTPS Client Hello

Windows 8.1 DirectAccess SSL Cipher Suites

So, if you want to take advantage of the IP-HTTPS performance improvements in Windows Server 2012 DirectAccess, be sure to use Windows 8 clients!

Update: Recently with the help of the folks at F5, I developed a solution to emulate Windows 8 client behavior for Windows 7 DirectAccess clients using the F5 BIG-IP Local Traffic Manager (LTM). Using this technique allows you to *effectively* offload SSL for Windows 7 DirectAccess clients. Fore more details click here.

%d bloggers like this: