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.
Alan
/ September 8, 2013Hi Richard
I have been following the above post also your course on Trainsignal, I am not sure if this is the right place to ask a question. I have configured a windows 7 enterprise to work with DA issue I am having is the client connects fine to the workplace but I am having DNS resolution issue on the client. Windows8 work fine and my DA server is working fine I see all greens. Can you please help ?
Richard Hicks
/ September 10, 2013Hi Alan,
It’s difficult to provide support like this here. Troubleshooting DirectAccess connectivity issues will require more attention than I can provide here, unfortunately. I’d be happy to answer any questions you might have about DirectAccess configuration or functionality, but I’d suggest engaging Microsoft for the troubleshooting effort.
Alan
/ September 10, 2013Thanks for the answer I think I know where I have gone wrong. Can I then ask in your training video you talk about creating A record for ISATAP in DNS and also unblocking it. In many blogs I have read as a general rule ISATAP shouldn’t ‘enabled’ by unblocking it on DNS servers and adding a host record. So what is the correct way unblock or block ISATAP what are the repercussions of unblocking.
Richard Hicks
/ September 18, 2013In most deployments, ISATAP should not be deployed globally because it can have adverse side effects. Read this blog post for more information:
http://directaccess.richardhicks.com/2013/06/24/isatap-recommendations-for-directaccess-deployments/
Harry Shaw
/ October 9, 2013Richard,
I’ve been following your blog for some time now and really enjoy it! It’s helped me a couple of times now 🙂
My question is regarding where to add this ADMX file. By default we have a both Direct Access Server and Direct Access Client GPO’s. Should I make a third one for this DCA requirement specifically? It’s my understanding that I should not make a change to either one of the GPO’s created by DA. I don’t mind adding a third policy just for Win 7 DCA. What is best practice?
Richard Hicks
/ October 10, 2013The ADMX file should be placed in the C:\Windows\PolicyDefinitions folder on a domain controller. The ADML file should be placed in the C:\Windows\PolicyDefinitions\EN-US folder, again on the DC. After that you can create the GPO that contains these settings. In this article I’ve demonstrated editing the GPOs created by the DirectAccess installation wizard, which although supported probably isn’t a best practices. I recommend creating a new GPO for these settings and assigning it to the security group that includes your DirectAccess clients.
Harry Shaw
/ November 20, 2013Thank you for your reply Richard. That worked great. One other question is regarding the HTTP probe versus the PING probe. On Windows 7, we cannot get the probe to work when using HTTP. It gives us the message that the name is resolved but cannot connect 90% of the time. The other 10% it works as expected. We’ve tried using the FQDN of our sharepoint site along with the same HTTP probe our windows 8 clients use. It either fails all together or says it has resolved the name but cannot connect. I’ve even tried wide open port 80 websites internal and they still fail. Lately we have noticed that when using HTTP as the probe host, we can see the DCA will show an error after 30 seconds. HTTP has failed. Then 3-5 minutes later, the HTTP probe passes and the connection removes the red x. Any suggestions on where to start troubleshooting something like this?
Richard Hicks
/ November 23, 2013Intermittent network connectivity issues like this are always difficult to troubleshoot. I’d suggest collecting network traces on the client and probe target server and see what that shows you.
bruun
/ January 16, 2014When i try to install DCA 2.0 on a windows 7 machine it fails. Before the install begins this message appears : The update is not applicable to your computer. Have you seen this before? It’s a windows 7 Enterprise N machine, installed on a Latitude 6330. Think it has something to do with the N version of Windows. Perhaps you might know the solution?
Richard Hicks
/ January 17, 2014I have not encountered that before. I’m not certain, but I do suspect it has something to do with being Enterprise N. No idea why that would be though, assuming that it does indeed support DirectAccess? I would think it does, but perhaps I’m mistaken?
bruun
/ January 18, 2014Tested it with a Windows 7 enterprise image and dca works, when installing Windows 7 enterprise n on the same system the installation of dca fails. But directaccess works on enterprise n.
Richard Hicks
/ January 18, 2014Wow…have to assume there’s an issue with DCA running on Enterprise N then. I’ll ask around and see if I can find anything more about this.
bruun
/ January 19, 2014Version currently used :
BuildLab : 7600.win7_rtm.090713-1255
EditionID : Enterprise N
Productname : Windows 7 Enterprise N
Same applies when installing MBAM 1.0 client agent (They solved the issue in MBAM 2.0), if you are using windows 7 Enterprise N you had to change a registry key (Remove the N letter, so it appeared as if it was the ”normal” Windows 7 Enterprise) Only then you were able to install the MBAM agent. But this registry key change doesn’t work for DCA 2.0.
Didn’t see anyone else with this problem, but not to many people are using Windows 7 Enterprise N.
thiagobeier
/ May 17, 2014Hello Richard, I followed the article and from win8 (inside or outside the organization) I got success conneting and also ping DTE1 and DTE2 (inside and outside). When I’m using Windows 7 client inside it can ping DTE1 and DTE2 inside , but outside using hosts file pointing to the edge.msft.local (external name) it returns gerenal failure
screenshots at https://onedrive.live.com/redir?resid=E883A4B81CA9B210!10171&authkey=!AMg-a5plPCpTNs4&ithint=folder%2c.PNG
Regards,
Harry Shaw
/ June 9, 2014In the hosts file you still have the pound sign in front of the IP. Is that on purpose?
Łukasz B
/ August 30, 2014Hello Richard , Can You explain why not to use NLS -> “DO NOT use the network location server (NLS) for this connectivity check” ? In my scenario i want to use 2 NLS servers using NLB , and available via dns record danls.corp.domain.
Regards.
Richard Hicks
/ September 8, 2014The NLS is excluded from the NRPT on the client and is not reachable over the DirectAccess connection. If you configured the NLS to use for corporate network connectivity check it would fail.
Tariq Hamirani
/ September 2, 2014Does it have all the security updates including SP1?
Richard Hicks
/ September 8, 2014There are no service packs for the DCA. There may be some security updates available for it, and if they aren’t included in the latest download then they would be available via Windows Update.
Darren
/ September 19, 2014Does anyone know of a fix as to why the DCA displays this error message at start-up. We are about to push out the DCA to all laptops and have had this occur on 3 out of 40 machines in our early testing.
Windows title “DirectAccess Connectivity Assistant is not working as expected”
Main message “The DirectAccess Connectivity Assistant service is not running. Restart the service, or contact the site administrator.”
If I double click on C:\Program Files (x86)\DirectAccess Connectivity Assistant\DcaTray.exe the same message appears.
Any ideas what is causing it. On all other machines it works correctly. My group policy is setup correctly so it must be a local client machine issue.
Any help would be appreciated.
Richard Hicks
/ September 19, 2014Odd issue. I’ve not encountered that ever in my travels. Hopefully someone else has seen this and can offer a resolution. 🙂
Darren
/ October 16, 2014I’ve figured out the cause of the error message. The dcasvc service is not starting which causes the dcatray to give that error message. If you kill the dcatray process in task manager and then start dcasvc (net start dcasvc) and then start the dcatray.exe. DCA works ok. However, on reboot the same error appears again. After examining the registry of a working machine the omission of this key is the root cause of the error message and subsequent dcasvc service not starting.
[HKEY_USERS\S-1-5-18\Software\Classes\Local Settings\MuiCache\1A8\52C64B7E]
“@%ProgramFiles(x86)%\\DirectAccess Connectivity Assistant\\DcaSvc.exe,-3036″=”Microsoft DirectAccess Connectivity Assistant Service”
However, the 3 digit value (in the above example 1A8) changes per machine so you cannot simply add this to a .reg file and deploy to faulty machines. I will have to find a way to read the existing key and then add the missing value. Tested on 3 machines so far and it fixes it 100%. Just thought I would let you know in case others run into the same problem.
Richard Hicks
/ October 20, 2014Thanks for sharing that information Darren. 🙂
Eric M
/ September 23, 2014Hello Richard, what when i have eveything installed(i”m using windows7 professional) DCA it’s not connecting as the vpn connection is showing limited access connectivity.Can you please advise something?
Richard Hicks
/ September 23, 2014Nothing more I can tell you other than make sure that all of the parameters you’ve specified are correct. If you have connectivity over DirectAccess but the DCA still indicates otherwise, it is most likely caused by the corporate resources you defined for DCA aren’t reachable via DirectAccess.
James King
/ July 23, 2015Hi Richard,
I have followed this guide, and Direct Access will connect happily on the client when using the Internal network, as soon as i tether to my phone it no longer works. (IT is working in Windows 8 clients)
Any ideas?
James
Richard Hicks
/ July 24, 2015Hi James,
Does it work when connected to an external network other than your tethered phone?
Oskar
/ October 14, 2015Hi Richard,
really great article! I configured my computers as described and DirectAccess works well except one issue that drives me mad. Windows 2012 R2 Server für DA and Windows 7 Client. We are mapping some network-drives with GPO, while the users home-drive is mapped via the user AD-object, Register profile. When I connect over DirectAccess, the logon takes quite a Long time an at the and the home-drive is missing while the other network-drives are visible and working. I found an article describing a solution by starting the iphlpsvc service after the interactive logon-screen has started. I cannot believe this. Any ideas would be welcome.
Cheers, Oskar
Richard M. Hicks
/ October 20, 2015There are a number of challenges with supporting Windows 7 clients. This is one of them. I think this gets better in Windows 8/10, but I’m not certain. There are still some scenarios where group policy processing can cause slow logons. You might want to test with a modern client and see if anything is better.
Craig
/ November 8, 2015Me Again 🙂
I configured my DCA group policy some time ago when I only had a single Entry Point using the MS DCA Administrators guide. At that time when I looked in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RaMgmtSvc\Config\Parameters for my DTE values they had 2002 internet routable addresses. Now that I have enabled multisite when I look at the same registry entries my two DA servers (one in each Entry Point) have fd unique local addresses for their DTE values. Does this seem right?
Richard M. Hicks
/ November 9, 2015Absolutely. IPv6 addressing changes for DirectAccess when you convert to multisite, so that is expected. 🙂
Craig
/ November 9, 2015Phew! I’ll re-do my DCA GPO now.
Thanks again.