About Us

Hello Fellow DirectAccess seekers!

Tom Daniels

Tom Daniels

My name is Tom Daniels and I’m a Premier Field Engineer for Microsoft.  I’ve been working with DirectAccess since it shipped with Windows 2008 R2 although the demand was much less at first.  My main areas of technical specialty include Active Directory, PKI, VPN, DirectAccess, TMG, and UAG.  I work in the field with different customers each week with a big focus these days on DirectAccess and PKI.  After visiting so many customers and getting a lot of first hand knowledge in DirectAccess, I felt a public facing website dedicated to DirectAccess would greatly benefit all the other millions of folks out there who might be interested in the technology.  Low and behold, I finally registered DirectAccessGuide.com and will be enrolling the assistance of a couple of fellow DirectAccess field engineers to share their wealth of knowledge in the coming weeks.

Please let us know if there are any specific DirectAccess topics not included on this site you’d like to see added in the future!

69 Comments on “About Us”

  1. Alberto
    December 12, 2013 at 13:04 #

    Hi Tom,
    Are you available for consulting services with implementing Direct Access?
    Thank you,


  2. Matt
    January 21, 2014 at 17:33 #

    Massive respect to someone willing to take the time to help others with this.. !

  3. Ben
    February 3, 2014 at 09:05 #


    This is really useful. Thank you. Keep up the good work

  4. February 20, 2014 at 06:56 #

    Tom, quick question. We are deploying DirectAccess (2012R2) behind a NAT firewall, therefore IP-HTTPS is the connectivity protocol client will be using. The performance over IP-HTTPS is very poor, almost to the point of it not being usable……

    Is this to be expected? When reading up on DirectAccess (on TechNet) there is a number of articles stating the performance overheads of IP-HTTPS have been removed since 2008R2.

    • February 20, 2014 at 07:26 #

      The very poor IP-HTTPS performance is defiantly not expected. How is your DirectAccess server configured (VM or physical server)? Are you doing any type of SSL offloading in front of the DirectAccess server? How many DirectAccess clients are connected to the server?

      We did make a big change to DirectAccess in Windows 2012 or higher in regards to IP-HTTPS. When Windows 8 or above clients connect, they use null encryption for the SSL tunnel. This causes less resource usage on the DirectAccess server. What OS are you running on your DirectAccess clients?

      • Øystein Hansen
        April 16, 2015 at 05:41 #

        First of all. Thank you for all the great info on this site!

        I’m sorry to re-open this subject, but I’m just about to give up on DirectAccess.

        My lab:

        XenServer 6.5 running two VM’s (Windows Server 2012 R2 as DC and a Windows Server 2012 R2 as DA-server) DC has 2GB of RAM and a dualcore vcpu setup, DA has 4GB of RAM and a quadcore vcpu setup (4 sockets with one core each)
        Both servers has all the latest updates.

        These two VM’s share a dedicated physical NIC on the XenServer host.

        The DA-server is behind a NAT-device, so option 3 (behind NAT with one NIC) is chosen. In this scenario I understand that IP-HTTPS is the only available transitiontechnology. I’ve run through the Getting Started Wizard and verfied that everything is ok. The IP-HTTPS certificate is from a trusted third party to aliviate the CRL-issue and i have forwarded port 443 to the server in question.

        The client (Windows 8.1 Enterprise and is the only client used to connect) has all the latest updates and I have verified that NRPT with its exemptions and GPO settings are correct. The client connects like a champ and the troubleshootingtool is a happy camper with everything in the green.
        I do use roaming profiles, but there is no folder redirection and the profiles are brand new. I have also verfied that my server offers NULL-cipher.

        Logon is ok and I am able to reach resources on my LAN.

        Here’s my problem: Regardless of ISP used to connect to the DA-sever I always get a slow link detection on the client and I’m really lucky to reach 125kB/s transferspeeds.
        It averages on about 35-70kB/s wich in real life will render the client useless.
        I have tried another client as well to check if there was a hardwareissue.
        Same result. Painfully slow.

        The DA-server sits on a WAN-link that offers 50Mbit/s download and 10Mbit/s upload.
        In theory I could reach transferspeeds up to 1,25 MB/s with a 10Mbit/s upload.
        I understand that some performance is lost due to encryption, but this is extreme.

        Do you have any suggestions on what I can do to speed things up?
        Where to start the troubleshootingprocess. I’m running out of options.
        Can my ISP have something to do with this?
        Any pointers that can lead me in the right direction are greatly appreciated.


      • April 22, 2015 at 22:50 #

        Hello Oystein,

        I’ve run across some customers who’ve run into performance problems with their DirectAccess setup like the one you describe. I’ll clear the myth that IP-HTTPS is slowing down the connection. What you will need to do is break the technology down into smaller pieces to troubleshoot. My first suggestion would be to test the speed of DirectAccess while connected on your internal network. To test the speed, you will need to fool a DirectAccess client into thinking it’s sitting externally even though it’s on your inside network. To accomplish this task, edit the hosts file on the DirectAccess client to add a bad IP for the NLS name used in your install. Then add a second entry in the hosts file for your external DNS name for the IP-HTTPs certificate and point this at your internal IP of the DirectAccess server. What this does is make your client think it’s sitting outside and it will attempt to connect via IP-HTTPS to your DirectAccess server directly on your LAN. Then test copying some big files to see if you still have performance problems. If not, then there’s something on your Internet pipe that’s slowing down or metering the traffic and it’s time to involve your network team/ISP to dig in further.

        Let me know what you find with this troubleshooting!



  5. aaron swiren
    February 28, 2014 at 12:54 #

    I’ve been trying to set up my own 2012R2 DirectAccess server for a couple weeks now and I keep running into a problem asking me to publish IPV6 routes to the network adapter. Can you offer any advice on how to resolve this one? Thanks!

    • March 3, 2014 at 18:24 #

      Hi Aaron,

      Can you reply back with the exact text you are seeing regarding the missing IPv6 routes?

      • aaron swiren
        March 4, 2014 at 06:18 #


        The error we’re getting is the following:


        DirectAccess clients cannot connect to all resources on the corporate network.


        Routes required to send packets to the corporate network have not been published on adapter NICTeam1. These routes are required for remote clients to reach the corporate network.


        Publish the IPv6 routes on the network adapter that connects the server to the corporate network.



      • March 4, 2014 at 09:08 #

        Hi Aaron,

        What does the following command show for the forwarding & advertising?

        netsh int ipv6 sh int “NicTeam1”

      • aaron swiren
        March 4, 2014 at 09:13 #

        Forwarding is enabled.
        Advertising is disabled.

      • June 3, 2014 at 19:03 #

        I too have the same issue, here is the netsh result:
        (note two nics, LAN and WAN)

        Interface LAN Parameters
        IfLuid : ethernet_10
        IfIndex : 12
        State : connected
        Metric : 10
        Link MTU : 1500 bytes
        Reachable Time : 37500 ms
        Base Reachable Time : 30000 ms
        Retransmission Interval : 1000 ms
        DAD Transmits : 1
        Site Prefix Length : 64
        Site Id : 1
        Forwarding : enabled
        Advertising : disabled
        Neighbor Discovery : enabled
        Neighbor Unreachability Detection : enabled
        Router Discovery : enabled
        Managed Address Configuration : disabled
        Other Stateful Configuration : disabled
        Weak Host Sends : enabled
        Weak Host Receives : disabled
        Use Automatic Metric : enabled
        Ignore Default Routes : disabled
        Advertised Router Lifetime : 1800 seconds
        Advertise Default Route : disabled
        Current Hop Limit : 0
        Force ARPND Wake up patterns : disabled
        Directed MAC Wake up patterns : disabled
        ECN capability : application

        Any further insight would be very much appreciated. Thanks!

  6. March 3, 2014 at 08:18 #

    Hi, yes that is what I expected. Our DirectAccess servers are physical machines. In terms of SSL offloading (I am not sure but I will certainly check). As the DirectAccess is currently in our pre-prod environment I have only had 5 clients connected at once. Again yes I had read about the Null’ing of the SSL for 2012. The clients are Windows 8.1 We actually have a call open with Microsoft, are you able to see this ticket? In all honesty we are seriously close to buying a couple of Cisco appliances………

  7. March 3, 2014 at 08:24 #

    Hi Tom, we are a Microsoft Gold partner and have a current case open with Microsoft to resolve our DirectAccess issues. Is there anyway we can escalate the call to you or another PFE?

    • March 5, 2014 at 10:07 #


      I sent you an email asking for the case number. Reply back when you get a chance and I’ll take a look.


  8. Scott Walker
    March 4, 2014 at 19:08 #

    Hi Tom,

    I have a single Direct Access server (2012 R2) which is on the same LAN as my resource servers however I have multiple branch offices. In this scenario, what is the best strategy for NLS? If a VPN fails between a branch office and my server infrastructure, I don’t want clients in that branch office to assume they aren’t connected to the domain because they can’t reach the Network Location Server. I can place network location servers in each branch (they all have domain controllers), but I’m not sure how that would work in regard to the Direct Access configuration.

    • March 5, 2014 at 10:25 #

      Hi Scott,

      It’s excellent that you are reviewing the NLS strategy for your environment! Many customers will simply just use the DirectAccess server or a single internal HTTPS web server as their NLS location. We highly recommend the NLS location be configured as something that is highly available. If you have an internal load balancer, this is a great candidate to host the NLS site. The website just needs to respond to HTTPS with a HTTP 200 OK code. It doesn’t matter much what the actual website contains as long as it doesn’t come back with an error or authentication prompt.

      Most of my customers who design this with some planning normally use a load balancer to both serve the traffic and host the HTTPS content. This removes any server dependency. You just need to make sure the SSL certificate doesn’t expire (have a good tracking system in place for your certificates). The only downside with this design is if your WAN links to remote offices are unreliable, then remote DirectAccess clients may think they are not connected to the internal network and initiate DirectAccess. Some of my customers actually prefer this behavior as their remote offices don’t have servers anymore and most of their applications are centralized in their data centers.

      It’s possible to push out different NLS locations based on AD site and override the NLS location for clients outside of your hub location. The group policy setting is located at :

      Computer Configuration -> Administrative Templates -> Network -> Network Connectivity Status Indicator -> Specify domain location determination URL

      If you do push out a separate set of GPOs to your DirectAccess clients, be sure it’s enforced so the stock NLS location in the DirectAccess Clients GPO doesn’t overwrite this setting.

      Please let me know if I can help answer any more questions!

      • Scott Walker
        March 25, 2014 at 10:57 #

        Thank you for the extremely helpful information! I was confused because when the option is selected to use the DA server for NLS, the URL https:///insideoutside is used. I wasn’t sure about the purpose of the insideoutside virtual directory. For my NLS deployment, I ended up configuring DNS with a host record for servers in each site, and using netmask ordering. I then ran into the issue of netmask ordering configured by default for the first 3 octets in an address while my headquarters site is on a /16 subnet. After overcoming that hurdle, all is good. With exception to a domain controller at each site, all servers live at the datacenter and all resources are accessed via terminal services farm/RD Gateway. The main reason for deploying DA in my environment is to facilitate storage of encryption keys on a domain controller from Bitlocker to go while users are working in the field. By the way, the Direct Access Planning and Deployment book is fantastic!

        Lastly, I’d like to point out that my environment is entirely IPv4 and for the life of me I could not establish a DA connection from any client, regardless of OS. I tried putting the DA server on the Edge and that didn’t help either. What did the trick was enabling isatap on a domain controller by adding an entry in the hosts file (did not want isatap on my entire network). This allowed the DA client to authenticate with the domain controller, although I’m not sure why this was necessary with the NAT64 and DNS64 services.

  9. Matt
    March 10, 2014 at 15:40 #

    Hey Tom, this is one of the best DirectAccess resources on the Internet.

    It may be worthwhile documenting an issue I came across with force tunnel mode on which I couldn’t find documented anywhere on the Internet.

    The DirectAccess status was never reported correctly on Win8.1 clients (I can email more details if you drop me an email with your address). Running the powershell cmd Get-DirectAccessStatus would show “InternetConnectivityDown”, however “netsh interface httpstunnel show interfaces” should show the connection up. Access to corporate resources would work too, so just the status was wrong.

    Issue was that dns.msftncsi.com was resolving to a 6to4 DNS entry, not the actual IPv6 entry of fd3e:4f5a:5b81::1. We needed to setup an internal DNS zone for msftncsi.com and manually create the AAAA record.

    • March 18, 2014 at 08:11 #

      Thanks for the info Matt! I’ve been meaning to write up a post-install best practices check-list for DirectAccess clients and the forced tunneling section would defiantly include this information! I’m on holiday this week but I’ll look to get this added to the site in the next couple of weeks. Thanks for reading!

      • Matt
        April 23, 2014 at 19:27 #

        Hey Tom,

        Something we found today which others may be having an issue with too…

        We found that after a computer resumes from sleep, it tries to contact some corporate resources immediately. The DA tunnel is not up yet and the DNS lookup returns no result.

        That DNS lookup is then cached and after the DA tunnel comes up, there is still no result returned. Doing an ipconfig /flushdns fixes the issue, but we can’t ask users to do that all the time.

        To fix the issue we added the regsitry key below. After rebooting the system it fixed the issue instantly. As soon as the tunnel is up, we can connect to resources instead of having to wait for the DNS cache to clear itself.
        By adding the registry entry HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services \DNSCache\Parameters
        MaxNegativeCacheTtl = DWORD 0

  10. Ade
    March 19, 2014 at 05:43 #

    Could someone give me a definitive answer on whether we can run DA (on a virtual 2012 Datacentre server) behind TMG 2010 (physical box on 2008 R2). Our consultants say not and have configured our current DA setup as Edge, and exposed us directly to the internet (as required to make it work in this config). I would rather run DA behind my TMG firewall, but they say its not possible? Yet, I see lots of articles indicating that it is? Note that we are not running UAG, just TMG 2010 Enterprise. Thanks in advance. Great site by the way – I’ve found more useful info on here than anywhere else!

  11. KayouMT
    March 24, 2014 at 07:35 #

    Hi everyone. I’m happy to discover that this site exists. I’m learning for MCTS 70-642 exam. I believe I will learn a lot on DirectAcccess here. I’m using 2008R2 and Win7 VMs on VmWare. I did deploy DirectAccess at least 10 times. At every trial, I struggled a lot for troubleshooting ; and sometimes it did not work.

    I did use very good labs ; but, often, they are too long and too confusing :

    – The lab in the MS Press book “Self-Paced-Training-Exam-70-642-Infrastructure”.

    I’m tryning to find a quick and short lab for making work the most basic functionnalities of DirectAccess ; with, only, the following components :

    – AD corporate domain with the following computers joined to it : DC1, DA-SERVER, WIN7-MEMBER-SERVER, 2008R2-MEMBER-SERVER.

    – NLS and AD CS are deployed on Domain Controller (DC1).

    – Computer certificates are auto-enrolled on all computers.

    – Web Server certificate is deployed on DC1 only (for NLS).

    – 6to4 must be the only tunnelling protocol used on clients. Setting public Ipv4 addresses must automatically activate 6to4.

    – IP-HTTPS certificates or settings are not configured.

    – CRLs are note configured (for AD, it is not necessary).

    Could DirectAccess work with that limited infrastructure ?

    • March 27, 2014 at 17:48 #

      It’s possible to get this working if you follow the lab guide very closely. The setup for DirectAccess using Windows 2008 R2 is much more complex than newer Windows 2012 deployments. This is due to the requirement of having IPv6 internally when you use Windows 2008 R2.

      All of my customer DirectAccess deployments have been using Windows 2012 or Windows 2012 R2 since it now includes NAT64 & DNS64 natively in the operating system. This removes the requirement for IPv6 internally and will work fine with a network only running IPv4 (which is most of the world right now).

      There’s a great updated lab setup guide for Windows 2012 DirectAccess you might want to review here :


      I hope this information helps and good luck on your studies!

  12. kayoumt
    March 27, 2014 at 18:28 #

    Thank you for your answer. The problem is I’m preparing for 70-642 exam and that exam is on 2008R2. So far I do not have issues on IPv6 setting. I think the tough and overkill part of DirectAccess on 2008R2 is setting Certificates and CRLs for the public part of the network.

  13. AndrejK
    March 30, 2014 at 09:56 #

    I’m intalling DA in multi forest environment. I have three separated forests with two-way trust.I can add computer accounts from two of them, on one, I get this error when I run ADD-DAClient:

    I’m confused, why can’t DA find security group? If I add security group throu GUI, I can browse security group from AD, but when I click finish, result is the same?

    any ideas, what I can check?

    VERBOSE: Retrieving server GPO details…
    VERBOSE: Opening the server GPO…
    VERBOSE: Validating security group (XXX\u_dacomps) in the domain…
    Add-DAClient : Security group XXX\u_dacomps cannot be found.
    At line:1 char:1
    + Add-DAClient -SecurityGroupNameList XXX\u_dacomps -v
    + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo : ResourceExists: (XXX\u_dacomps:root/Microsoft/…ess/
    nt], CimException
    + FullyQualifiedErrorId : HRESULT 800700ea,Add-DAClient

    Add-DAClient : The operation failed. All of the specified security groups are invalid.
    At line:1 char:1
    + Add-DAClient -SecurityGroupNameList XXX\u_dacomps -v
    + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo : InvalidArgument: (SecurityGroupNameList:root/Microsoft/…ess/PS
    ], CimException
    + FullyQualifiedErrorId : HRESULT 80070057,Add-DAClient

    kind regards,


    • April 10, 2014 at 22:09 #

      Hi Andrej,

      What type of security groups (Local, Global, or Universal) are these in each of the domains?

      – Tom

      • AndrejK
        April 15, 2014 at 04:09 #


        it is universal security group in each domain



      • Aaron
        June 18, 2014 at 12:31 #

        I have the same issue. Does it matter if your pre-2000 domain name is different that your normal domain name?

      • June 20, 2014 at 18:38 #

        Hi Aaron,

        This shouldn’t matter. Do you also have multiple forests and trying to add groups from other forests?

  14. Scott Walker
    April 10, 2014 at 20:02 #

    Hi Tom,

    In my deployment I have a network interface configured with a public IP address connected directly to the internet. While the interface has the public profile applied, I feel that I’ve created a significant vulnerability in my network. If I try to access the server via SMB from any internet connected computer (specifically a PC that is unrelated to the corporate network in any way), I can do so if I have the right credentials. Seems like those ports (135, 445) should be closed for anyone not connected by way of direct access. What can I do to secure that publicly accessible interface? I’ve searched and I can’t find documentation on this anywhere.

    • April 10, 2014 at 22:03 #

      Hi Scott,

      The Windows Firewall should be loading the public profile on your external NIC and not allow any traffic through besides what’s absolutely needed for DirectAccess. It’s possible this has been changed from the default of “Block” on incoming traffic. I would check the properties of the public profile in the Windows firewall on the DirectAccess server to see what’s configured for incoming traffic blocking behavior. Since is server is directly exposed, be sure you get this configured to block all traffic!

      Besides relying on the Windows firewall, you can go to the external NIC and uncheck file & print sharing, client for Microsoft networks, and Link Layer Topology Discovery. I would also recommend disabling NetBIOS over TCP/IP on the external NIC.

      Another option is you can host the server behind a Firewall in your network. You also have the option of using NAT to the DirectAccess server that way it’s not directly sitting on your Internet network and you have the advantage of a second hardware firewall. This is probably the most popular configuration for most of my clients since they do not want to use public IPs on any servers directly.

      Hope this helps!

      • Scott Walker
        April 11, 2014 at 10:04 #

        Hi Tom,

        This is a fresh install of windows dedicated to the purpose of Direct Access. I have not manually modified any firewall rules so not sure why the open ports. My main reason for connecting directly to the WAN is to take advantage of Teredo. I went ahead and modified the external NIC and unchecked per your recommendation. All is good now and I’m secure. Thank you Tom!


  15. May 12, 2014 at 18:05 #

    I am having the same problem as aaron swiren. You started to help him but never replied to his last post, which is exactly where I am at.

    • May 13, 2014 at 11:54 #

      Hi Brayan,

      Can you send me the exact text from the error message? Thanks!

  16. May 13, 2014 at 15:29 #

    DirectAccess clients cannot connect to all resources on the corporate network.

    Routes required to send packets to the corporate network have not been published on adapter Ethernet. These routes are required for remote clients to reach the corporate network.

    Publish the IPv6 routes on the network adapter that connects the server to the corporate network.

    I’ve made many searches and the only time I’ve come close is the dialog between you and aaron swiren. Too bad you never provided him with a solution, at least not here. Please help me as soon as you can. Thank you in advance.

    • May 15, 2014 at 18:44 #

      Run the following command in an elevated PowerShell window on the DirectAccess server :

      netsh int ipv6 set int Ethernet advertise=enabled

      • May 15, 2014 at 20:19 #

        Now I have two errors with my Network Adapters. The new error is:

        The network adapters are either disconnected or disabled.

        1. The specified network adapters are not enabled.
        2. The specified network adapters are not connected.

        1. Enable the network adapters using ncpa.cpl
        2. Verify network connectivity on the network adapters.

        It is obvious that I am not well versed in IPv6. But what I can determine from this experience is that perhaps I should have enabled an IPv6 DHCP Scope. None of the guides that I followed suggested anything about setting up IPv6 on the server. I configuration consists of only one Network Adapter and it is enabled. The only thing is that it is using the link-local address for IPv6 with no setting for subnet prefix nor default gateway. The only setting is the DNS is not set for Automatic. Instead it has a setting for Preferred DNS of ::1, which I take it to mean the server itself.

        So what settings for IPv6 am I actually missing in my single NIC configuration?

  17. May 14, 2014 at 02:25 #

    Please note that we are using IPv4 for both Intranet and Internet connections. DA server is also a single NIC Windows Server 2012 Essentials R2.

    VPN works fine.

    The clients can also connect via DA. Once connected via DA I can only see the server’s resouces via \\servername but not via \\ The same with ping. When I ping with \\servername the responses are in IPv6.

    It almost seems like the connection is not being assigned an IPv4 address or IPv4 traffic is not being processed.

    Please Help!!!!!!!!!

    • matt
      May 14, 2014 at 16:49 #

      You have direct access working properly. Hostnames are supposed to resolve to ipv6 addresses and resources are not accessible via ipv4 addresses.

    • May 15, 2014 at 18:45 #

      Hello Brayan,

      This is expected behavior since the DirectAccess server acts as a NAT endpoint. You will need to access internal resources using their DNS name. Trying to use the IPv4 address directly will not work across DirectAccess.

  18. May 14, 2014 at 16:54 #

    Then what the Network Adapters error?

  19. Derrick
    June 4, 2014 at 06:12 #

    I cannot find a fix/solution for Error Code 0x643 (IPHTTPS interface creation failure. I see a hot fix for Windows 8 clients but not Windows 7. Could you start a thread on Error code 0x643

  20. MK
    July 11, 2014 at 02:55 #

    One user is facing strange issue with direct access , he is able to connect to directaccess and able to access all resource but issue is his direct access connectivity assistant probe says unable to reach to website we are probing and it reports DA is not working correctly , If I try to probe that website directly from box by typing in Internet explorer we see it can reach web server. Looks like some issue with DA probing that website.

    Any help appreciated.

    • July 11, 2014 at 09:13 #

      Hi MK,

      What OS is running on the DirectAccess client?



      • Pat
        November 14, 2014 at 07:13 #

        Greetings Tom,

        I’m have the same problem as MK on a few of my clients. They are all running Windows 7 Ent.


  21. Scptt Walker
    August 22, 2014 at 11:03 #

    I know I’ve seen this issue discussed before but I can’t find the solution. When connected to a remote LAN that issues IPv6 addresses to clients (mobile hotspots and various home networks), connectivity to DirectAccess does not work. The only workaround I’ve been able to find is to disable the IPv6 stack on the workstation in this case. Is there a more desirable way to remediate this issue? My DirectAccess server is connected directly to the WAN with Teredo enabled.

    • August 22, 2014 at 15:28 #

      Hi Scott,

      I’ve seen this before with some deployments and generally recommend setting the DisabledComponents registry key to a value of 0x10 (in hex) via a group policy for your DirectAccess clients. This solves the problem of them grabbing routable IPv6 addresses from their ISP that cause issues with your DirectAccess deployment. Best part is you do NOT need to uncheck IPv6 off the NIC checkbox for this setting. You can see the following KB for more information about the registry value :


  22. Daniel Badila
    September 2, 2014 at 06:06 #

    Hi Tom, I have 0x274c error code at netsh int https show int. DA client is a windows 8.1ent

    • September 5, 2014 at 09:15 #

      Hi Daniel,

      This IP-HTTPS error code translates to :

      “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 error code before with clients when the TCP/443 traffic was being blocked between the DirectAccess client and the DirectAccess server. Check to see if you have any firewalls or filtering devices that are not allowing TCP/443 to the DirectAccess server.

  23. Derrick
    September 2, 2014 at 10:54 #

    Will setting DisabledComponents to 0x10 have an effect on Configuration Manager 2012? Will the clients still be able to report and receive applications?

    • September 5, 2014 at 09:16 #

      Hi Derrick,

      By setting the DisabledComponents it will disable any non-tunnel IPv6 addressing on a Windows computer. This does not break DirectAccess so you should be find setting this value on your DirectAccess clients.

  24. Thuso
    September 11, 2014 at 12:05 #

    We have two weeks straight now working with Microsoft to resolve my directaccess error. We only using IPHTTPS transition. The server and client traces (etl files) sent to Microsoft. Only Server 2012 and Windows 8, when we started i had two nics one on the DMZ we removed the DMZ connection though to eliminate any doubts. Now with one NIC NAtted on a cisco ASA, i removed the use of public ssl to simplify the directaccess configs. After making it that simple my clients cannot access the local domain resources, cannot ping domain fqdn or any server by name. no access to shared folders. Iphttps interface is operational and i can ping DA server with its IPv6. Nslookup with server as DA server gives me all internal server IPv6 addresses. rdp using the ipv6 on any server works, why can’t i ping fqdn domain name or access shared folders. Doing an RDP to DA server i can view my remote connection on the Remote Client Status. Please assist me accessing the internal resources, my client connection on the troubleshooting wizard is connecting only.

    • September 26, 2014 at 18:43 #

      Hello Thuso,

      Can you reply with the output of this command from one of your DirectAccess clients?

      netsh na sh po

  25. Tracy
    September 18, 2014 at 12:06 #

    Great site! I just deployed DA 2012 to our users and am running into an issue that I cannot find any information on. Things are working great, users can get to internal server resources just fine, but cannot reach internal website. One in particular is our SharePoint server, it is only setup for internal use, so the website is different than our .local network.
    The website name is ex. my.spapps.com and our internal network is contosco.com. I have the correct IPv6 address for the server in DNS. Any help would be great.

    • September 26, 2014 at 18:44 #

      Hi Tracy,

      Can you send me the output of the following command from one of your DirectAccess clients?

      netsh na sh po

  26. November 6, 2014 at 14:58 #

    Might consider checking out the DirectAccess in AWS whitepaper:


    Click the partners tab to see the paper

    • November 6, 2014 at 15:18 #

      Hi Scott,

      Very interesting paper! I’ve got a couple of questions looking through the document.

      First there was no mention of the client OS requirement near the beginning. If you plan to use the Kerberos proxy function of DirectAccess, this does require Windows 8 Enterprise or higher. Windows 7 will not work as a DirectAccess client in the configuration listed in the document. Based on experience, I still do many installs where customers have Windows 7 as their DirectAccess clients. Based on experience the Kerberos proxy works well for a very small install but if you start to have a lot of DirectAccess clients, it doesn’t scale well and we highly recommend using client-side certificates for IPsec. This could be easily added by enabling auto-enrollment of certificates in the AD/PKI environment in the cloud so ping me if you have any questions.

      Secondly, how are you deploying the IP-HTTPS certificate? If this is being deployed by the CA in the cloud, are you publishing a Internet accessible CRL? If not, then again Windows 7 clients will fail to connect due to a CDP lookup failure. It’s also possible this could fail on Windows 8 DirectAccess client machines if a customer enables strong CRL checking.

      For the offline domain join, we only support this for Windows 8 DirectAccess clients as Windows 7 offline domain join does not import any GPOs or certificates needed for DirectAccess connectivity.

      Overall looks like a great document so let me know if I can help answer any more questions!

      – Tom

  27. Scott Roberts
    November 6, 2014 at 15:30 #

    Yes, this is targeted at the Single Nic Topology and focused on Window 8+. I did include IPsec machine certificate auto-enroll in the automation, so it’s there but not really used too much. I also set the ACL’s to enable this through automation. I was just keeping this first one small and containable. I’ll consider the update to clarify the client OS version. I was the Lead PM for DA back in MS, but now I’ve over in AWS.

    Using Offline Domain Join Win8 functions to handle the certs. Doesn’t work for Windows 7 the same way. And agree that not handling the strong CRL checking in this simple doc. I’m happy to collab on a version that works for Windows 7 feel free to email me offline (you can get my email from the site setting right?)

  28. Scott
    January 26, 2015 at 08:26 #

    Hi Tom,

    In my deployment, I have multiple internal subnets/VLANs. For purposes of accessing resources from DA clients –> internal LAN I have created persistent routes on the DirectAccess server. However, I’m having trouble with the ability to manage out from a workstation/server that’s not on the subnet that’s directly connected to the LAN interface of the DirectAccess server. ISATAP also seems to only work for clients that are on the same broadcast domain. My L3 switch that handles routing between VLANs does not route IPv6. Do you have any ideas?

  29. April 1, 2015 at 02:09 #

    Hi Tom,

    First off, thanks for building this site; it’s a great resource to all.

    I am currently taking another whack at setting up DA on Server 2012 R2 in my lab environment and I am having a hard time figuring out this problem with IP-HTTPS. The Remote Management Operational Status page indicates IP-HTTPS is ‘Not working properly’, cause is “The Listener service has been stopped, or is not configured’.. it’s a little hard to troubleshoot when there are no error codes and my logs look fine.

    When I do a netsh interface httpstunnel show interface, I see the interface status as active and no error code. I had some suspicions of some other service(s) binding to port 443–IP Helper (which I believe actually is the listener), and the KDC Proxy Server service were the only two services that I found would close port 443 when I shut them down (both trigger other critical errors in DA when stopped though)

    My lab enviroment is native IPv6 with the IPv4 stack disabled. For internet access, I have virtual routers and a standalone DNS server configured for NAT64/DNS64, however I do not intend my DA clients to connect from IPv4 space at this time.

    I’ve created some PSR recordings of what I did–if you don’t mind taking a look at them, that would be great:



    Also on a side not, I would be interested in learning a bit more about your role as a PFE..

    • April 4, 2015 at 03:41 #

      Okay after a couple days of banging my head against the wall, I figured out what my problem is. As much as people say IPv6 must be enabled for DirectAccess to work and how no one should ever disable it, so should it be said that DA will not work if IPv4 is disabled. Since the focus of my lab was to have a completely native IPv6 environment, I ran the Disable-NetAdapterBinding cmdlet to disable the IPv4 stack on all my lab systems. Once I enabled IPv4 on my DA server, the above mentioned error disappeared.

      Would you happen to know anything about the way forward for DA in a completely IPv6 network?

  30. Øystein Hansen
    April 24, 2015 at 06:28 #

    Hi Tom,

    Thank you for your reply.

    Thanks to your tips i finally figured it out!
    I fooled my client to think it was outside the LAN but the result was the same.
    It HAD to be somewhere in my network.

    It actually turns out that the networkdriver that comes with XenTools was the culprit.
    Uninstalled the PV networkdriver, and I got close to max transferspeeds (over 1 Mb/s)

    Thanks again for pointing me in the right direction!
    Hope this can helps others that uses XenServer to run their labs.




  1. How To Fix 0x274c Ip Https Errors - Windows Vista, Windows 7 & 8 - October 22, 2014

    […] The DirectAccess Guide | About Us – The very poor IP-HTTPS performance is defiantly not expected. How is your DirectAccess server configured (VM or physical server)? Are you doing any type of …… […]

Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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: