Microsoft Direct Access issues on a specific Windows 7 client “Network Location Behaviour : Never use Direct Access settings”

By |2017-12-08T10:48:00+00:00December 23rd, 2010|Windows|0 Comments

We were working on an issue recently where one single machine was unable to connect to any resources via direct access.

The first thing we checked was the Direct Access Connectivity Assistant logs and found the below errors.

“RED: Corporate connectivity is not working. Windows is unable to resolve corporate network names.  Please contact your administrator if this problem persists. 18/11/2010 11:35:40 (UTC)

Probes List
FAIL        FILE: DC.domain.comsysvoldomain.compoliciespolicydefinitionsdesktop.admx
FAIL        HTTP:
FAIL        PING:

C:Windowssystem32LogSpace{C892E78B-EA58-4990-86D8-E3E82C7A1D12}>netsh dns show state

Name Resolution Policy Table Options

Query Failure Behavior                : Always fall back to LLMNR and NetBIOS
                                        if the name does not exist in DNS or
                                        if the DNS servers are unreachable
                                        when on a private network

Query Resolution Behavior             : Resolve only IPv6 addresses for names

Network Location Behavior             : Never use Direct Access settings

Machine Location                      : Outside corporate network

Direct Access Settings                : Configured and Disabled

DNSSEC Settings                       : Not Configured”

The first thing that jumped out at us was that the DNS “Network location Behaviour” was set to “Never use Direct Access Setting” so this was the reason that all the probes failed as DNS could not resolve them.

After doing some research we came across the following MS article “” which told us that if the following REGKEY “HKLMSoftwarePoliciesMicrosoftWindows NTDNSClientEnableDAForAllNetworks was set to 2 , then this would force the machine to “Never use Direct Access settings”.

After checking the machines registry we could see that the value was actually set to 2 therefore forcing the machine not to use DA setting, so what we did was change this value to 0 and gave the machine a reboot and everything sprung back into life Smile

Leave A Comment

like what you see? 

Sign-up to our newsletter and never miss out on the latest blogs, events and tech news from the world of risual
Give it a try, you can unsubscribe anytime.