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:

NLA 1

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.

NLA 2

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:

NLA 5

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:

NLA 3

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

NLA 4

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 see 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.

57 thoughts on “Network Location Awareness Doesn’t Identify Domain

  1. sach

    For me the fix was to un-select IPv6 and it changed automatically to domain network.

  2. Mark Berry Post author

    @sach, how/where did you “un-select IPv6”? Interesting theory that IPv6 could be inhibiting NLA in some cases. Bear in mind that turning off IPv6 is not always a good idea, especially on servers, and if you do decide to do it, it requires registry changes. MSKB 929852 has some details.

  3. Chris Mason

    Found that the above was also not 100% reliable (Did not want to rely on script).
    Have found that adding the following seemed to help in my case from an Elevated Command Prompt:

    sc config NlaSvc depend= NSI/RpcSs/TcpIP/Dhcp/Eventlog/Netlogon

    The change from default is to add a requirement to wait for the Netlogon service to be running.
    The other dependencies are default but as the command erases all previous entries these are added first to preserve them.

  4. Mark Berry Post author

    @Chris Mason, thanks, interesting idea. I would have thought that making NlaSvc depend on having a network connection would be enough (using triggerinfo), but a Netlogon dependency may take it a step further, requiring that a secure channel to the domain controller but open.

    For reference, to check the service dependencies and triggers:

    sc qc NlaSvc
    sc qtriggerinfo NlaSvc

    By the way, on a machine where I’m pretty sure I set up the network trigger, its gone now. I wonder if these customizations are erased when one applies a Windows 10 “feature update” (e.g. I just updated 1909 to 2004).

  5. Zombie

    This a great effort,

    I fight this issue since almost 1 year
    We have tried all the solution on the web > with no luck !!
    Is there any possible solution or update for this nightmare.

  6. Nevada Tech

    Hello all, my final fix was to add Netlogon, DNS, and NTDS as a dependency to NLA. There should be some others there by default – NSI/RpcSs/TcpIp/Dhcp/Eventlog.

    To get to there, on a new 2019 server with AD and DNS services, I tied with no luck
    * setting IPv4 prefixpolices high than IPv6
    * add domain suffix to connection and use suffix to register connection
    * setting the DNS to itself instead of 127.0.0.1
    * adding just the Netlogon dependency
    * changing NLA to auto-delayed service startup

    Hopefully, like everyone else here, my hours spent will help someone else. It’s insane this has been happening on a server OS for years.

Leave a Reply

Your email address will not be published. Required fields are marked *

Notify me of followup comments via e-mail. You can also subscribe without commenting.

This site uses Akismet to reduce spam. Learn how your comment data is processed.