none
60 second *Connecting* times on DirectAccess, versus 30 seconds on UAG RRS feed

  • Question

  • Hi folks

    Weird one here.

    1.    I have around 600 Windows 7 people connecting through one Windows 2008 UAG box, Teredo OR IPHTTPS is *connected* within 25-30 seconds of an Internet connection being available.

    2.   Conversely, I have 50 or so Windows 10 people connecting through *up-to-4* Windows 2016 DA servers, ONLY using IPHTTPS (Teredo disabled), and it takes at least 55-60 seconds of an Internet connection being available before they are *Connected*.

    3.   Finally. If I point the Windows 10 clients at the old UAG setup, and if I DISABLE Teredo on these Win10 clients (So that they just use IPHTTPS), they actually connect within 25-30 seconds.

    It's pointing to behaviour via the New Direct Access setup, but the best I know it's been configured to best practises.

    On the Windows 10 Laptops the 6TO4 tunnel is already disabled via GPO, Teredo is inactive (I also disabled it on my laptop, still took 60 seconds).

    It's now becoming very noticable as more and more people get moved onto Windows 10. AlwaysOnVPN is on the horizon but it'll be months and months yet.

    Has anyone experienced this sort of behavour and been able to improve that 60 seconds until *connected*?

    Thursday, March 7, 2019 11:52 AM

All replies

  • This is not uncommon. However, it is often not related to actual DirectAccess connectivity, but how the UI reports that the DirectAccess client is connected. For example, if you have configured more than one web probe host, the client takes much longer to validate connectivity. It is recommended that a single HTTP probe be configured to ensure optimum NCSI operation. Details here:

    https://directaccess.richardhicks.com/2017/05/22/directaccess-network-connectivity-assistant-nca-configuration-guidance/

    Another lesser known issue has to do with a DNS timing issue. For example, if the client tries to resolve the web probe host URL before the client has fully established a DirectAccess connection, the query fails and is added to the negative DNS cache. The client will not attempt to resolve the name again for a period of time (5 minutes by default, IIRC). You can disable negative DNS caching using the following registry key:

    HKLM:\System\CurrentControlSet\Services\Dnscache\Parameters\MaxNegativeCacheTtl

    If it doesn't exist, create it and set a DWORD value of 0. This should improve the responsiveness of the NCSI and report a DirectAccess connection status more propmtly.


    Richard M. Hicks
    Microsoft Cloud & Datacenter MVP
    Founder and Principal Consultant - Richard M. Hicks Consulting, Inc.
    directaccess.richardicks.com

    Thursday, March 7, 2019 10:13 PM
  • Hey Richard

    Thank you for taking the time to respond. I'll test out the negative cache setting, see if that has any bearing. I hijacked an older thread last week, and the chap responded to say that his 60 second issue was potentially improved by this very ttl setting. It was some time ago so he couldnt remember clearly, but the GPO setting was indeed still in place now in 2019.

    I had some issues last week when I made a change on UAG&TMG, for a seperate issue I have to do with BSOD and fweng.sys. Well, the thing I changed (disabling NDISregistration) completely screwed the UAG Direct Access Infrastructure tunnel immediately after I applied it, so I had to back out.  700 users couldnt connect eeek.

    Point being, i think I'll have to investigate the impliactions of setting the negativeDNScache setting to *0*, just so I dont muck something else up inadvertently.

    Cheers

    Coop

    Sunday, March 10, 2019 7:22 PM