Network Location Awareness Doesn’t Identify Domain

One small client has a Server 2012 R2 Essentials domain controller and a few Windows 7 desktops. It’s a wired, mostly gigabit network. Some desktops, especially those that have are behind a couple switches, often have problems confirming that they are on the domain, so they come up on the Public network, which messes up RDP connections.

The problem, of course, is that the Network Location Awareness (NLA) service can’t determine that the machine is on a domain, so it falls back to Public:

Several articles suggest changing the NLA service to “Automatic (Delayed Start)”. That’s has not been enough in this environment.

At least one article suggests restarting the NLA service. That doesn’t work because the Network List Service depends on the NLA service, and the Network List Service, for some reason, can’t be stopped.

The only sure way that I have found to force the NLA service to re-detect the domain is to stop and restart the network adapter. In fact I have script a RestartNetworkAdapter.cmd on many computers to do just that:

netsh interface set interface "Ethernet" disabled
netsh interface set interface "Ethernet" enabled
pause

Using a script allows doing this even when connected remotely, but it’s awkward and you have to customize the interface name for each PC.

Digging into NLA

Today I decided to dig into this further to see if I could come up with a better solution.

Then I found this TechNet blog article on how the NLA service works. The big news to me in that article is this:  “If the Connection Specific DNS Name matches the HKEY_Local_Machine\Software\Microsoft\Windows\CurrentVersion\Group Policy\History\NetworkName registry key then the machine will attempt to contact a Domain Controller via LDAP.”

I checked that registry key and it in fact contained the correct value, let’s say “mydomain.local”.

But how/where is the Connection Specific DNS Name set? This article offers guidance:  you can set it in the adapter’s DNS properties.

Note that this can also be set in group policy:  Computer Configuration > Administrative Templates > Network  > DNS Client > Connection-specific DNS suffix. When set in group policy, it overrides the value set in this dialog, but it is not displayed in this dialog.

By the way, the Primary DNS suffix for the computer is set in System Properties when you specify the computer name. When you click the More button, you’ll see this dialog:

You can also override that in group policy: Computer Configuration  Administrative Templates > Network  DNS Client > Primary DNS suffix. The Primary DNS Suffix defaults, sensibly, to the domain name. However the TechNet article cited above wants us to match Connection-specific adapter settings, hence the update above.

I had already set a fixed IP address for the primary DNS server, pointing to the domain controller. This is critical for all kinds of domain-based stuff (group policy, etc.). However I did not have “DNS suffix for this connection” filled in. I’d already seen (using ipconfig from a command prompt) that this machine is using both IPv4 and IPv6 to talk to the domain controller. So I added the “mydomain.local” string to both IPv4 and IPv6 profiles of the adapter. Voila! After a reboot, the machine immediately came up on with a Domain profile:

Well, that worked two times out of three. But still it sometimes comes up Public. Is there anything else I can do to help it be more reliable? The only other idea I have at this point is to make the NLA service dependent on having an active network connection. Can’t hurt, right? I ran the following from an administrative command prompt:

sc qtriggerinfo NlaSvc
sc triggerinfo NlaSvc start/networkon stop/networkoff
sc qtriggerinfo NlaSvc

Three more reboots and the machine has come up as Domain each time.

However on another machine, those two changes weren’t enough. Wait, this machine still had NLA service set to Automatic. After changing it to “Automatic (Delayed Start)”, this machine also rebooted directly to the Domain profile. To set Automatic (Delayed Start) from the command line, run:

sc qc NlaSvc
sc config NlaSvc start= delayed-auto
sc qc NlaSvc

Note that the space after the equal sign (=) is intentional and required.

TL;DR

To (hopefully) fix NLA issues:

1. Set the NLA service to “Automatic (Delayed Start)” and only when the network is available:

sc config NlaSvc start= delayed-auto
sc triggerinfo NlaSvc start/networkon stop/networkoff
sc qc NlaSvc
sc qtriggerinfo NlaSvc

2. Set the Connection Specific DNS Name to match the domain controller’s local domain. Run ncpa.cpl and do this in the iPv4 and IPv6 properties of the network adapter (see screen shots above). There might be a way to script this, but it would require enumerating network adapters, so I’ll just do it manually for now. Update:  this can be set in Group Policy. See above.

Update April 14, 2018

Unfortunately, all of these settings are still not always enough to get Network Location Awareness to detect the domain profile. I still frequently find myself restarting the network adapter to get it to re-detect the location. (On some machines, it is possible to to restart only the NLA service.)

If you run a remote monitoring tool, see this post for a script that will alert you when the profile is not what you expect: Script to Check Current Firewall Profile.

Update July 5, 2018 – Network Issues?

It occurred to me that this NLA issue could be a more general issue with the client not being able to contact the domain controller. On one machine with this issue, at startup, in the System event log, I have a NETLOGON 5719 error, “This computer was not able to set up a secure session with a domain controller….” I was reminded of an issue eight years ago relating to switch configuration:  Gigabit Switch Spanning Tree Causes Slow Logon.

It helped then to set ports connected directly to computers to Fast Link on the Dell switch. Unfortunately, that option is not available in the UI of the new UniFi switch. However as suggested in this Reddit thread, I was able to change the Spanning Tree priority to 8192 to identify the UniFi switch as the root switch. Alas, that alone was not enough to solve the NLA issue; the machine still comes up as Public most of the time.

Update February 5, 2019 – Startup Script

I’m now running the following script on affected machines to restart the NLA service. Copy and paste this as RestartNLAService.cmd, then add a Scheduled Task, Trigger as a Startup task with a 1-minute delay, Conditions limited to any Network connection being available. Use at your own risk!

@echo off
REM 01/21/2019

REM Restart the NLA service to force re-detecting that computer is on a domain. 
REM Unlike restarting the network adapter, this does not completely disconnect from network.
REM Can run this from a Scheduled Task at Startup.  Run as SYSTEM, 1 minute delay, only run 
REM if "Any Connection" available.

REM %0 is the name of the batch file. 
REM ~dp gives you the drive and path of the specified argument, with trailing \.
set ScriptPath=%~dp0
REM ~nx gives you the filename and extension only.
set ScriptName=%~nx0

REM Clever approach to redirect stdout and stderr for a group of commands
REM See http://stackoverflow.com/a/13400446/550712:
> "%ScriptPath%\RestartNLAService.log" 2>&1 (
    echo ========================
    echo Current firewall profile
    echo ========================
    netsh advfirewall monitor show currentprofile
    echo =======================
    echo Restart the NLA service 
    echo =======================
    echo Stop the Network Connected Devices, Network List, and Network Location Awareness services
    net stop ncdautosetup
    net stop netprofm
    net stop nlasvc
    echo Start the NLA service
    net start nlasvc
    echo Network Connected Devices and Network List services are Manual start, so will be started if needed
    echo.
    echo ========================
    echo Updated firewall profile
    echo ========================
    netsh advfirewall monitor show currentprofile
)
type "%ScriptPath%\RestartNLAService.log"

REM Do not put a PAUSE here, since this will run from a scheduled task

Update March 10, 2020

If you need to quickly change a network adapter from Public to Private (e.g. because Public is blocked in the server’s firewall and the stupid workstation won’t change to Domain), see this post.

Update May 20, 2023

I hate to extend what is already a confusing list of options for this persistent issue, but I’ve come across a completely different solution posted by someone who seems to understand the inner workings of domain controllers and NLA. This comes courtesy of a comment in a German thread that one of the commenters on this post mentioned.

Normally I’ve experienced the NLA issue on workstations. But after setting up a new Windows Server 2022 domain controller, I found that it could not recognize itself as a DC on reboot; I had to restart the network adapter every time. This post suggests three registry modifications to adjust caching and domain detection. They immediately solved the issue on the Server 2022 machine. From the context, it sounds like it should work on a workstation as well, but I have not tested that.

https://learn.microsoft.com/en-us/answers/questions/400385/network-location-awareness-not-detecting-domain-ne

I’m reproducing the entire post here, with full credit to Microsoft vendor Sunny Qi:

Hi,

Thanks for posting in Q&A platform.

After machine reboots, before NIC adapter initializes, NLASVC would attempt detection of domain, if the detection was failed, then this information will be cached and even though NIC gets initialized, the machine still apply the cached information and hence machine detects unidentified network.

Please try to modify the following registry keys to see if the issue can be resolved:

First, disable Domain Discovery negative cache by adding the NegativeCachePeriod registry key to following subkey:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NetLogon\Parameters
Name: NegativeCachePeriod
Type: REG_DWORD
Value Data: 0 (default value: 45 seconds; set to 0 to disable caching)

If issue doesn’t resolve, furtherly disable DNS negative cache by adding the MaxNegativeCacheTtl registry key to the following subkey:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters
Name: MaxNegativeCacheTtl
Type: REG_DWORD
Value Data: 0 (default value: 5 seconds; set to 0 to disable caching)

Note: This registry key disables the Domain detection negative cache. NLA normally detect Domain multiple times at network setup (triggered by route change, IP address change etc). But if the first time detection failed with negative result (such as ERROR_NO_SUCH_DOMAIN), this negative result gets cached in netlogon, and will be reused in next time NLA domain discovery.

There is also another registry key we need add:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NlaSvc\Parameters

Add a DWORD parameter :AlwaysExpectDomainController

Set value to:1

Note: This registry key alters the behavior when NLA retries domain detection.

Best Regards,
Sunny

A couple of comments asked for further information about the AlwaysExpectDomainController value. One commenter shared, “Here’s what I got from another rep in a support request: ‘AlwaysExpectDomainController is for the device to send continuously the SRV query requesting the LDAP to the domain controller until it gets an answer.'”

To implement the above, save this as a .reg file and import. Use at your own risk!

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters]
"NegativeCachePeriod"=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters]
"MaxNegativeCacheTtl "=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NlaSvc\Parameters]
"AlwaysExpectDomainController"=dword:00000001