Network location awareness not detecting domain network from offsite location

Oryisi Robert 56

The issue occurred after we started migrating our offsite workstations to Win 10. After joining computers to domain, computers show unidentified network connection instead of domain network connection. Computer is located at offsite location and was migrating to Win 10. NLA is working normally when it was still Win 7 workstation.

Registry workaround was applied and computer was able to detect Domain network connection, but there are times when connection will be set to unidentified network. NLA service startup has been set to Automatic (Delayed Start).

Thanks in advance.

Brian Hymer 0 Reputation points

2023-05-09T17:22:42.8866667+00:00

Thanks Sunny - I'm jazzed about trying these registry keys...

My curiosity is how do the group policy "Network List Manager Policies" affect the "DomainAuthenticated" network location/category/connection? If I set "Unidentified" or "Identifying" Networks to a Location type of "Private" in group policy, will that keep them from switching to "DomainAuthenticated"? I hope not - what I am really trying to do is keep them from defaulting to "Public"... 😝
Roudnev, Alexei P 1st Lt 0 Reputation points

2023-10-11T00:57:28.1+00:00
We had simular story 1 week ago. One of our VMware hosts got deadlock on datastore and it made necessary to restart one host, and HA system did not restart DC controller.

The whole AD system went dark in 30 minutes and stay dark until we was able to restart this DC.

Investigation shows that

NLA detects network status by NETLOGON

NETLOGON tries THE ONLY DC (one which went down)

when system tried it for 10 - 30 minutes NLA decided to switch profile which activated firewall and disconnected all services except established ones.

no LOG messages, NOTHING - NLA do not write events, do not write LOG file. It was done quietly and cowardly :)

Fortunately, one of our engineers had similar issue some time ago (not exactly this but NLA service killed his server without warning). So we track it down to NLA. And it was not easy as system is not documented, do not write logs, and behaves differently in 2022 vs older servers. To make things fanny, it decided that DOMAIN CONTROLLERS are not ON DOMAIN NETWORK.

This is extremely dangerous. We are not Windows shop so we was able to login bypassing AD, use Linux DNS instead of AD DNS (which went down together with DHCP, notice - on ALL DC at once!!) and restore service, and we had syslog events in central location. SO we recovered the events. But if you are windows shop and you have it in your network, ok, you are fully doomed.

How NLA determine where to login, why it do not write events into event log, and why it is not documented? And how can we make sure that NLA try all DC and if it is DC itself it do not make it 'I am on public network' when it did not moved?
Deleted

This comment has been deleted due to a violation of our Code of Conduct. The comment was manually reported or identified through automated detection before action was taken. Please refer to our Code of Conduct for more information.

Accepted answer

Sunny Qi 10,896 Reputation points Microsoft Vendor

2021-05-19T04:39:14.717+00:00

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

----------

If the Answer is helpful, please click "Accept Answer" and upvote it.

Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.
Please sign in to rate this answer.

17 people found this answer helpful.
Oryisi Robert 56 Reputation points

2021-05-19T07:26:50.393+00:00

Thanks for your response Sunny. Actually we have applied the first two options before I posted this question. It worked for a while, and then the connection was detected to unidentified network again. I have tried to add the 3rd registry key as you recommended, it works now. I will keep monitoring and keep you posted. Thank you for your support.

Jt 1 Reputation point

2021-07-01T13:41:41.683+00:00

Is this still working for you? I'm having the same issue.

EDIT: I've rolled out all three registry keys above to a small subset of my users with success so far. None of them have experienced the issue again. And most importantly none of them seem to have any new issues despite the complete lack of documentation on AlwaysExpectDomainController.

Shane 6 Reputation points

2021-09-27T16:27:55.303+00:00

Thank you so much for this solution! I have been trying to resolve this frustrating issue on multiple computers in multiple domains, and it's especially difficult with remote users using a VPN connection to the domain. I have talked to many experts who say this is an issue with Windows Firewall and that specifying a DNS suffix will work, but this solution (I just added all 3 registry keys the first try) finally worked.

For anyone else looking at this problem, this should be especially helpful for VPN users and remote workers because this directly addresses the issue of no domain connection at logon.

Ronald Rossi 1 Reputation point

2022-02-17T15:48:48.807+00:00

Sunny Qi
You have answered a question that has been plaguing servers for over a decade
I thank you so much
Never have heard of the key AlwaysExpectDomainController
Cannot wait to try it out
Thanks again
Ron

02/21/23

FWIW been using all 3 keys on all servers and this has worked all year

never needed it for a PC

John Peachey 1 Reputation point

2022-08-10T08:17:56.5+00:00

Thanks Sunny, I am another person who is extremely grateful for a working solution after nearly 2 days of trying to get to the bottom of it.

Tyron Thomas 0 Reputation points

2023-02-21T00:06:36.6933333+00:00

I have run into this issue before where the NIC of a 2012r2 server (physical box) serving as both the Domain Controller and Hyper-V Host, would not set the network to Domain after a reboot, but rather Private or Public. In that situation was not able to resolve until I moved the DC off that physical server to a VM and the only thing remaining on the physical server was Hyper-V and DHCP.

Years later have run into the same issue on another (smaller) network due to having to run multiple services on a single physical server (WinServ2019, DC, Hyper-V, DHCP). I knew I shouldn't be running the Domain Controller on the Hyper-V host due to past experience, but had limited hardware at the time. Setting the 3rd reg key setting mentioned above for "AlwaysExpectDomainController" seemed to do the trick. Did not set the other 2 reg keys. But did change the startup setting on the service: Network Location Awareness (NLASvc) to "Autostart (Delayed)" due to other articles I read. Not sure it played a part in the resolution, but left the service set that way since my BDC was also already that way.

I'm a firm believer Hyper-V is playing a big part in my situation. Most likely due to sharing the single NIC on the physical computer for both connecting to the physical network and connecting all my VM's.

robertECEO 1 Reputation point

2023-08-22T22:56:20.29+00:00

I added these registry keys. Does one have to restart all of the services involved to get the correct DomainAuthenticated profiles. The machine in question is a domain controller.

Ronald Rossi 1 Reputation point

2023-09-27T17:46:33.0366667+00:00

This is the answer bar none

We use this in our SOP of Server builds have never had a server pick the wrong network since

I would highly recommend everyone use these keys in your next build and finally get correct NLA

If you want to be sure go here and delete all unnecessary profiles on Servers

HKLM\Software\Microsoft\Windows NT\CurrentVersion\NetworkList\Profiles

HKLM\Software\Microsoft\Windows NT\CurrentVersion\NetworkList\Signatures\managed

HKLM\Software\Microsoft\Windows NT\CurrentVersion\NetworkList\Signatures\Unmanaged

Jens-Peter Vraa Jensen 1 Reputation point

2024-03-29T18:48:57.6+00:00

NegativeCachePeriod solved it immediately for me (Win 2019 single DC)
Sign in to comment

4 additional answers

UnluckyJelly 21 Reputation points

2021-07-29T21:29:16.19+00:00

Question for Sunny,

Is is possible to have more details on what the registry key : AlwaysExpectDomainController = 1 is changing in the Nlasvc behavoir ? I have not found any other reference to this key other than your reference to it.

thanks.
Please sign in to rate this answer.

4 people found this answer helpful.
Jt 1 Reputation point

2021-07-30T20:05:09.363+00:00

Hey I had the exact same question. 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.

Shane 6 Reputation points

2022-02-18T23:37:37.193+00:00

I have tried this on my own computer, as well as several clients' machines, and I don't know the answer exactly but here is my experience. When I join a new network for the first time, it takes slightly longer (only a few seconds) to detect the network type and prompt me to select Private vs. Public. So I think there is a timeout for how long Windows will try to contact the Domain Controller before it gives up and assumes there isn't one.

The experience to my end users seems minimal, but has helped immensely for the machines that constantly had issues detecting the DC even when I had the domain name manually appended in the DNS settings.
Sign in to comment
Patrick LOUBET 6 Reputation points

2021-12-14T09:07:53.577+00:00

Omg ! The only exact answer, among a thousand posts, to a question driving me crazy until we switched to Global Protect VPN.
Thanks a lot Sunny.
Isn't there a way for you Microsoft guys to widely publish that info ? I am sure a lot of IT admins around the world are getting bald with this :-)
Best regards
Please sign in to rate this answer.

1 person found this answer helpful.
Shane 6 Reputation points

2022-02-18T23:38:45.4+00:00

I came back to this recently after googling this issue, and at the very least this thread is now one of the first few Google results. Make sure to upvote Sunny's answer, if MS never makes this a knowledge article at least this will be a top search result.
Sign in to comment
Dave Patrick 426K Reputation points MVP

2021-05-19T02:26:38.303+00:00

Computer is located at offsite location

How are you connecting to the domain? When NLA starts to detect the network location, the machine will contact a domain controller via port 389. If this detection is successful, it will get the domain firewall profile (allowing for correct ports) and we cannot change the network location profile.
If the domain was not found or process failed, NLA will let you to determine which firewall profile will be used, private or public.

--please don't forget to Accept as answer if the reply is helpful--
Please sign in to rate this answer.
dej 1 Reputation point

2021-11-04T14:20:56.037+00:00

is this UDP or TCP 389

Shane 6 Reputation points

2022-02-18T23:33:54.443+00:00

Late answer, but in my case: This primarily affects users connecting to the domain via SSL VPN connections. So there may be several minutes (or hours) between the time they log onto Windows and when they connect to the domain.

This SSL VPN client creates a virtual NIC that shows as "disconnected" before the connection, so I would have assumed that connecting to the VPN causes that virtual NIC to "connect" and would go through the same NLA process as connecting a physical LAN cable. But in a small but not insignificant number of cases, the network connection will hang at "identifying network"

So it is not detected as a domain network, AND Windows never prompts the user to select the network type either. (This is in my experience anyway, I'm not the original poster)

Sunny Qi's answer above helped me, but my supervisor also does not like the idea of having to set registry keys to assume a domain network since all of our users are remote and usually aren't connected to the domain. Another solution I have found for this is to restart the NLA and Network List Service in Services (which usually also requires me to stop the process first, which is annoying). This can be done on an as-needed basis.

robertECEO 1 Reputation point

2023-09-27T17:10:58.93+00:00

"NlaSvc", "NetProfM" | stop-service

Applied the above reg keys.

Still have win2019 domain controllers that cant detect themselves!
Sign in to comment
Roudnev, Alexei P 1st Lt 0 Reputation points

2023-10-13T02:11:14.7166667+00:00

MY question is how LNA got the list of DC, and why it tries only one of dozen's DC? And it do it exactly on all systems. Moreover, it decided that system is on PUBLIC network even when it runs on DC itself.
Please sign in to rate this answer.
Ronald Rossi 1 Reputation point

2023-10-13T13:30:44.12+00:00

Roudnev, Alexei P 1st Lt

Install those 3 registry keys on your DC's and you will never have an issue with NLA again

We actually use that on all the servers now just as SOP

Do not need on PC's, if NLA is an issue on a PC you have another network problem

This has been a PITA for 15 years or so?

Personally never understood HOW a DC can pick another network? but what do I know?
Sign in to comment