DirectAccess Client Troubleshooting Guide

Welcome back!  So a common request from many people working with DirectAccess is a nice step-by-step guide you can follow to troubleshoot DirectAccess client connectivity issues.  I’ve worked with quite a few customers over the years doing DirectAccess installs and have done my fair share of troubleshooting connectivity issues.  The guide I’ve presented below covers some of the top causes of DirectAccess connection issues with clients.  I don’t intend for this to cover every single issue that might exist in the world but this should eliminate 99% of the common causes of connectivity problems.

I’ve got a link right here to an offline PowerPoint you can feel free to use in your environments :

Troubleshooting DirectAccess Clients Step by Step

Tags: , , , , , , , , , , , ,

Categories: Troubleshooting DirectAccess

35 Comments on “DirectAccess Client Troubleshooting Guide”

  1. Jeremy
    February 19, 2014 at 12:25 #

    We are getting the last error code 0x34. Any ideas on this one?

    • February 19, 2014 at 12:45 #

      Hi Jeremy,

      What OS are you running on your DirectAccess clients?

      • Jeremy
        February 19, 2014 at 12:49 #

        Windows 8 and 8.1. We are in the process of upgrading to 8.1. We have had 5 cases of this within the last week, I believe they are all running 8.1, but we did have this one time before on an 8 client, we just re-imaged the machine.

      • February 19, 2014 at 13:22 #

        Hi Jeremy,

        So the 0x34 error code means the OS encountered an issue with a duplicate name. So my best guess is the OS still has a stale IP-HTTPS adapter present in the registry. First make a backup of the following registry keys on one of your DA clients :


        After you’ve backed up these keys, then delete all of the GUID values under each of the folders (the GUID values start with a squiggly bracket “{” ). Then try to reboot and see if the DA client will rebuild a new working IP-HTTPS adapter (it should).

  2. Jeremy
    February 19, 2014 at 13:31 #

    Thanks! I will test this tomorrow and let you know. Appreciate your help

    • February 19, 2014 at 13:56 #

      No worries! Just curious, what anti-virus product are you running on your Windows 8 DA clients?

      • Jeremy
        February 20, 2014 at 05:27 #

        I tried this on one of the machines this morning and it worked! Thanks! We are running System Center Endpoint Protection.

      • February 20, 2014 at 08:40 #

        Excellent! You can use this as a workaround to get your clients up and working again. Please let me know if the problem re-appears after the workaround.

      • February 27, 2014 at 20:12 #


        Are you using the multi-site capability of DirectAccess in your setup?

      • Jeremy
        February 28, 2014 at 05:03 #

        I believe there is only one Direct Access server that we are using currently, but I could be wrong as I wasn’t involved in the setup of the server.

      • Jeremy
        April 8, 2014 at 04:45 #

        Unfortunately I have run into another issue now. The problem is the same as far as it just saying “connecting”, but when I try to apply the registry fix, there is nothing under “Uninstalled”.

      • April 10, 2014 at 08:39 #

        What does the following command show?

        netsh int https sh int

      • Jeremy
        April 10, 2014 at 12:12 #

        Last error code: 0x32
        Interface Status: IPHTTPS interface administratively disabled

      • April 10, 2014 at 22:08 #

        Looks like a different error code than last time. This one usually appears if part or the entire IPv6 stack gets disabled on the client. Does the following registry key exist on the client and if so, what value do you see?


      • Jeremy
        April 11, 2014 at 07:21 #

        Yes it does. Here is the Value: 0x0000008e (142)

      • April 11, 2014 at 07:24 #

        This registry key disables part of the IPv6 stack and I’ve got a feeling it’s disabling the IP-HTTPS adapter. Can you remove this registry key and reboot? This should re-load the IP-HTTPS adapter again.

      • Jeremy
        April 11, 2014 at 08:07 #

        Awesome, that worked. Thanks again for the help!

  3. Sovan
    July 4, 2014 at 06:11 #

    We have a couple of directaccess clients both windows 7 and windows 8 Enterprise which have the Iphttps adapter state as active
    C:\Windows\system32\LogSpace\{B0F2E743-E4D1-45CC-BD90-E80F9698C798}>netsh int httpstunnel show interfaces

    Interface IPHTTPSInterface (Group Policy) Parameters
    Role : client
    URL : https://**.***.com:443/IPHTTPS
    Last Error Code : 0x0
    Interface Status : IPHTTPS interface active

    However no DirectAccess tunnels are established. No Tunnels in Main mode/quick mode.
    Iphttps adapter is receiving only link-local ip address
    Link-local IPv6 Address . . . . . : fe80::7164:741a:4d0b:13a9%49(Preferred)

    We have disabled both 6to4 and Teredo adapters. Still issue is not resolved.

    Other DA client computers using the same network are able to connect without issues to corporate network using IPhttps adapter.

    Please suggest how to correct the issue.

    • July 8, 2014 at 18:04 #

      Hi Sovan,

      Can you send me the output of this command from one of the broken DirectAccess clients?

      netsh adv sh glo


  4. Priyesh
    July 28, 2014 at 21:41 #


    I am setting Direct Access with OTP. It is working fine with windows credentials.
    The problem I am facing is that the Direct Access GPO settings are neither getting applied on Client nor on DA Server. When I run the gpupdate /force command, it shows the policy is filtered out as it is disabled.
    This is on client side.

    The following GPOs were not applied because they were filtered out
    DirectAccess Server Settings
    Filtering: Disabled (GPO)

    DirectAccess Client Settings
    Filtering: Disabled (GPO)

    I also tried enforcing the policy in GPO and changing GPO status to enabled. But in that case the policy gets filtered out because of security. Posting the output

    DirectAccess Client Settings
    Filtering: Denied (Security)

    I have tested the 11 steps mentioned in the guide. All results are fine except that of the GPO.
    I am using Windows server 2012 R2 essentials as DA server and windows 8 enterprise as DA client.

    Please suggest some solution.


    • July 30, 2014 at 16:25 #


      Are your clients and DirectAccess server located in an OU that has GPO inheritance blocked?

      • Priyesh
        July 31, 2014 at 02:27 #

        No, the GPO inheritance is not blocked on OU. The policy is linked to the OU and is enabled.

  5. August 4, 2014 at 08:29 #

    Hi! I am really sorry to steal precious time. We deploy DirectAccess on Windows Server 2012 R2 with force tunneling and Windows 7 clients with many help of you (thanks for that) and it works like a charm. But last Friday I got special requirement of a special department. They have to transmit data via sftp in passiv mode with SSL, port 21.

    Now I have the problem that every ftp client like Filezilla resolves the name of the ftp server and try to connect directly. This do not work.

    Did you ever configure sftp on DirectAccess clients?

    Thanks for help! Dietmar

    • August 6, 2014 at 10:33 #

      Hello Again Dietmar!

      I haven’t been to any customers who have asked me specifically about SFTP across DirectAccess. When the SFTP client connects, does it connect using an IPv4 address directly or does it try to resolve the hostname of the SFTP server? My best guess would be the SFTP client is trying to connect directly to the IPv4 address leading to the problem. Can the client resolve the hostname of the SFTP server if you ping the name from the command prompt? If the name resolves, it should be an IPv6 address and you might try using this IPv6 address directly in your SFTP program to see if this will connect. Hope this helps!



    • Rob J
      October 3, 2014 at 05:30 #

      I’d suggest here to put an NRPT exception on DA for the destination SFTP DNS name thus enabling the client machines with the SFTP client to transfer directly over their internet connection without tromboning off via your corp net.
      You obviously trust the organisation that you send data to over this link and any proxy/firewall will not be able to get into the SSL connection to apply any AV treatment so adds no real value to assuring the connectivity.

      Now this won’t work if you have force tunnelling on your DA service but if you don’t then you have the option to add an exception.

      Exceptions are added via the remote access management GUI configuration screen Step 3, skip the first NLS step and on the DNS step scroll to the bottom of the current Name Suffix list and enter a new item… the FQDN of the SFTP site you need to access but with no DNS server address, not specifying DNS makes the client go direct to internet for this particular DNS name… Save all the settings… gpupdate the client… check the new NRPT entry is there with “netsh name show effective” [can be abbreviated to netsh na sh ef…. always surprises me how many don’t know that netsh can have abbreviated keywords to the minimum unique characters for any given command !!]

      Now try your SFTP client and see if it can link up…..

      Good luck.. let me know if this helps at all…

  6. September 3, 2014 at 06:43 #

    Really annoying problem I havent been able to solve – we have Direct Access Deployed on a server with a single Nic behind a NAT firewall. The IP-HTTPS tunnel is created, but name resolution for anything internal doesnt work (I can ping internal resources by ip address)

    • September 5, 2014 at 09:18 #

      I’ve seen this a couple of times in the past with customers. Try creating an inbound firewall rule to allow IPv6 traffic to the DirectAccess server. I’ve seen in some cases where the automatic rule does not get enabled properly and it causes issues with DNS64 working correctly. Let me know if that solves your problem!

      • September 5, 2014 at 10:13 #

        Hi, just tried this and reboot the DA server, still no joy 😦 I can ping the ipv6 address, it just seem to want to respond to DNS queries

      • March 11, 2015 at 03:40 #

        I fixed this in the end, believe it or not, McAfee VirusScan was blocking the connection..

  7. January 20, 2015 at 00:14 #

    We use DA 2012 R2 with Windows 7 Clients with force tunneling and Smart Card login. Our Smart Cards are registerd with a certificate from A-Trust. A-Trust is an Austrian 3rd party ca. The root ca and sub ca information is available on microsoft. We use WPAD to configure the proxy information. In general our directaccess solution works well and our employees are happy.

    However, sometimes the users get an error at logintime: The domain controller certificate revocation status can not be deallocated. We doublechecked everything and are not able to find any issue. I can see that the infrastructure tunnel works fine but the user is not able to connect to intranet tunnel. The DCA icon on infobar indicates that DirectAccess is connected.

    Did you ever use 3rd party smart cards for logon to directaccess? With certutil -URL I tried to reach the CDPs and AIA from our internal PKI and A-Trust as well. Both worked fine.

    Any ideas? Thank a lot for help because it fails everytime when it is worst case of course 😉

    • March 10, 2015 at 21:35 #

      Hello Dietmar,

      Are your CDP & AIA locations from your internal PKI reachable from the Internet or just internally? If they are just internal, have you added the CDP & AIA hostname into the management server list? The OS will need to be able to validate the CRL across the infrastructure tunnel so it’s important this has been added to the management server list.

      – Tom

      • March 11, 2015 at 02:06 #

        Hi! Our CDPs and AIAs are reachable from inter- and intranet AND I added the hostnames to the management server list. But I am not able to add the thirdparty CDPs and AIAs to the management server list.

  8. Dave
    January 20, 2015 at 17:51 #

    We are getting code 0x274c – have been banging my head against this one for awhile and feeling pretty stuck. :/

    • March 10, 2015 at 21:33 #

      Hi Dave,

      This error code means :

      A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond.

      I’ve seen this one quite a few times and it’s generally caused when the TCP/443 is blocked to the DA server from the Internet. Are you able to telnet to your DA server’s external IP address on TCP/443?

      – Tom

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: