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.
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
Anyone know how to hard code the server to domain network only. I am not worried about a server leaving my server room and landing up on a public wifi. This is a nightmare when dealing with Hyper-V.
Andy, I feel your pain. The constant fiddling to try to keep computers on the domain is annoying. If the main problem is that the Private and Public firewall profiles are blocking necessary services (RDP, SQL, whatever) when the computer does not know it is on the Domain, I guess you could change the Private and Public profiles to allow the necessary services. Maybe this is why some admins just disable Windows Firewall and rely on perimeter firewalls, but I’d rather not do that.
Hi Mark. I work at an NHS trust and have exactly the same issue you write about here. Have tested around 5000 pcs so far and have 650 that are displaying “identifiying network” continuously. While it doesn’t stop the majority of our systems RDP and AD are disabled. We still have not found a permanent fix for this although I seriously think there is a DNS server issue going on. I would love to hear from you if you ever find the fix for this. We use a mixture of win 7 and 10. Regards paul
@Paul, wow that’s a lot of PCs! I still have no solution. Let us know if you find one! Have you tried opening a Microsoft support case?
I would love our server and network team to take ownership of it but you know the score. There’s nothing ever wrong with the network or servers!!!! I will let you know if we find a fix.
For Intel network adapters you can try to set “Wait for link” to ON.
PT, thanks for the suggestion. I have one machine that always has this problem. I suspect it has to do with distance from the main switch and maybe a cheap dumb switch or two in the run. Unfortunately, changing Wait for link from “Auto detect” to “On” did not help. Here for reference is the page describing “Advanced Settings for Intel® Ethernet Adapters”: https://www.intel.com/content/www/us/en/support/articles/000005593/network-and-i-o/ethernet-products.html .
I also have this problem. I’ve spent the last 2 months trying different remedies, and still haven’t found a solution. There is only one DC in this environment now (the 2008 DC was decommissioned), and with the NIC profile set to public or private, domain functions are not being performed.
Even with the firewall completely off, and delayed start for NLA on, it hasn’t made a difference.
Hello, I had the same problem until a few days ago until I finally came up with the solution.
It would simply be enough for the computer to PING TO THE DOMAIN (ping mydomain.int) every time it boots until the answer is correct and then restart the NLASVC (Network Location Awareness) service.
This can be done by GPO with a startup script, or with a program in the start menu or with a scheduled task… as preferred.
my script is a cmd file
@echo OFF
:REPEAT
timeout /t 2 /nobreak
ping -n 1 -w 1000 MYDOMAIN.INT
IF %ERRORLEVEL% == 0 goto RESTARTNLA
@echo. %date%-%time% MYDOMAIN.INT is offline >> c:\PingLog.txt
goto REPEAT
:RESTARTNLA
@echo. %date%-%time% MYDOMAIN.INT is online >> c:\PingLog.txt
sc config netprofm start= disabled
sc stop netprofm
timeout /t 10 /nobreak
sc config nlasvc start= disabled
sc stop nlasvc
timeout /t 10 /nobreak
sc config netprofm start= demand
sc config nlasvc start= auto
sc start netprofm
I hope it’s helpful.
Thank you Luis. I’m curious, how often do you find that the domain is not pingable when the client starts up, and for how long? (as shown in your PingLog.txt file) It doesn’t make sense to me that the domain, i.e. the domain controller, would not be pingable as soon as the network card is active. Although I guess by pinging “mydomain.local” instead of an IP address, that is also confirming that DNS is resolving from the domain…
Same problem here. All the servers are showing unidentified network unless restart the NLA. Is there any hotfix from Microsoft on this?
Salih – I’m not aware of a fix. The problem seems widespread and has gone on for years. I’ve scheduled an automated task to run after startup (after a 1-minute delay, I believe) that restarts the NLA service. Usually that is enough to get the machine back on the domain.
I’ve implemented this script at my NHS trust for the past 2 weeks.
First reports are looking very promissing, gone from 700 machines down to 40, but checking the pcs that are still affected shoes they are on domain firewall profile so think the reporting tool I use is getting the info before the script completes.
Thankyou everyone for their contributions,
Regards
Paul
Paul – here’s the script I use to check the firewall profile:
https://www.mcbsys.com/blog/2016/09/script-to-check-current-firewall-profile/
I’ve copied the script that I’m using to the end of the article. Output is saved to a text file in the script folder for debugging. It includes commands to print the current firewall profile before and after restarting the NLA service.
Actually, this issue is happening because of the switch port. Set Spanning Tree to fastmode (or Edge Port) for the port you are using or if it is a nic team set it for each port individually and then also for the entire nic team.
Ref# https://social.technet.microsoft.com/Forums/Azure/en-US/665e9d4f-aa00-4183-af00-b369f6bf321f/nic-teaming-unidentified-network?forum=winserver8setup
@Salih, I reviewed the Spanning Tree issue near the end of the article, under “Update July 5, 2018 – Network Issues.” Unfortunately, even if that is related, UniFi switches don’t seem to have a Fast or Edge setting per port; you can only identify the (R)STP priority for the whole switch, or disable it altogether.
I just found this thread that indicates it may be possible to disable spanning tree by port:
https://community.ubnt.com/t5/EdgeSwitch/STP-enabled-or-disabled/td-p/2037061
That might work on a UniFi switch too, though it would require custom config changes to make it persistent.
Also, I was seeing this on a virtual server running on the same Hyper-V switch as the virtual domain controller. I don’t see a spanning tree option on the Hyper-V Virtual Switch Manager…
My problem was on a 2019 DC with NIC teaming enabled ,found that by running the following in a power shell script, that disables and then enables IPv6 works. I used task scheduler to run at startup with 1 min delay running at highest privilege. I also checked the option to run only when any network connection is available under Conditions tab. Just disabling IVp6 does not work, wondering if setting static IPv6 would help, will try on my next server
Disable-NetAdapterBinding -Name “*” -ComponentID ms_tcpip6
Enable-NetAdapterBinding -Name “*” -ComponentID ms_tcpip6
We also had a similiar issue.
We tried all of the above without any success. One colleague notified us that the Direct Access certificate expired over the Weekend.
We generated a new certificate and this resolved the issue.
PS: I am new to the firm I do not know why clients are connecting from internal LAN with the certificate.
So if anyone has tried everything, check your Direct Access Server if the certifcate has not expired…
Thanks for the help posted here. It save me a lot of time, but it still took over a week for me to stumble across something that stopped our 2016 server AD DC from using Public Profile.
In our case it was a unnecesary setting (for an DC) that I found buried in System properties. If you go to the Settings for computer name , click change (ignore the ominous warning about changing Domain Controller names which actually contradicts the setting to be changed), Click the more button, and there appears the culprit, at least in our case, “Change primary DNS suffix when domain membership changes”. Ours was checked. I unchecked and rebooted (3 times so far) and now it recognizes the domain profile.
STP, not sure how you did that; when I checked a DC, the button to change the computer name is grayed out. But it sounds like your goal was different. Here I want to make sure that domain-joined desktops NEVER use a Public or Private profile but rather always the Domain profile.
None of the fixes I found online worked for my situation. I have Windows Server 2019 Data Center with NIC Teaming on Hyper-V host. Installed a Hyper-V VM also Server 2019 Data Center and made it a domain controller. Found that it would not show mydomain.local in network connections, it would always show as Private. Restarting NLASVC would make it domain but every restart it would go back to Private. The only thing that worked for me was to make DNS and NTDS a dependency for NLASVC using below command and now every restart shows mydomain.local.
run
sc config nlasvc depend=NSI/RpcSs/TcpIp/Dhcp/Eventlog/DNS/NTDSfrom CMD (use sc.exe if you’re running it in PowerShell).If you want to double-check the existing dependencies before adding DNS and NTDS, use
sc qc nlasvcFor me it was OWEN’s suggestion of the expired Direct Access certificate (thanks OWEN!). DA clients use both the AD connection and the web probe host on the DA server to check if they are on the local network – if the cert has expired that test fails so it thinks it’s not connected locally…
@Mike P – in your Application event log, do you have Microsoft-Windows-CertificateServicesClient-AutoEnrollment warning 64 for that certificate (before you fixed it)? I don’t use Direct Access, but I do monitor that event on other certs and take it as an “early warning” of expiration. “Certificate for local system with Thumbprint f5 ad 0b aa 1a d5 6c d1 20 72 5b 1c 42 6c 30 ad 92 ef 21 b0 is about to expire or already expired.” The only downside to monitoring these events is that the warnings start appearing at 90% of the certificate’s lifetime, so 20-year certs expiring in 2020 started throwing warnings in 2018. More useful on certificates with shorter lifespans.
@Mark Berry – yes, there were EventID 64 entries in the Application log, plus I’ve now also found in the Applications and Services Logs->Microsoft->Windows->CertificateServicesClient-Lifecycle-System->Operational log multiple Event 1003 ‘A certificate is about to expire. Please refer to the “Details” section for more information.’ followed by a 1002 ‘A certificate has expired. Please refer to the “Details” section for more information.’ when it expired last week. It’s a 2 year cert so started warning early Feb.
Hi,
Same problem here on my VMs on my Hyper-V Host all running 2012R2. Nothing worked to fix that permanently.
Best solution I found is to run a scheduled task at boot on every VM with 1 min delay and repeat every 15 mins that runs that powershell line :
if (Get-NetConnectionProfile -NetworkCategory DomainAuthenticated) {exit} else {(net stop netprofm) -and (net stop nlasvc) -and (net start nlasvc)}
It tests if the network type is domain, if not it restarts both the network list and network location awareness services. Workaround is working perfectly for me.
Hi just wanted to add in this is the best coverage I’ve seen of this issue so far.
I have a bunch of 2012/2016 Hyper-V VMs in a lab which keep resetting to non-domain connections. I’ve run through all the same troubleshooting steps and now am going to have to go to the dependencies (or run script to restart service on start) thing.
What a PITA that Microsoft haven’t covered this properly.
Cody, glad you’re finding this thread useful.
Has anyone tested disabling spanning tree in their switch at the port level? I wonder if the faster negotiation would allow the network to resolve in time to detect the domain the first time.
I have this problem reproduced both on the physical server and on the vmware virtual machine with clean installed windows server 2019. Only the use of the sc config command helps me permanently. Seems to be bug WS 2019 (1809).
One thing that seems to work: Walk over to the server after it’s already booted up. Unplug the network cable for about 5 seconds. Plug it back in.
Annoying, for sure, but a lot easier than Googling this every few months and finding that the issue is still not universally resolved.
I tried all the above. Nothing worked, but while I was testing, I had to remove a seconary IP from the interface. I noticed that if I add or remove a second IP, the interfaces refreshes as a domain interface. So I made a batch script :
netsh int ip add “interface name” some-secondary-ip-addres some-netmask
TIMEOUT 10
netsh int ip delete “interface name” some-secondary-ip-addres some-netmask
I then added a task schedule for it at startup
this works for my particular instance of this problem.
For what it’s worth, On a brand new server 2019 VM in HyperV, on a hyperv host that no other vm was having this issue, we resolved this issue by removing the vm nic competely from the vm in hyperv settings, and adding a new one, then re-setting the static ip and dns. Seems to have done the trick.
We also had NLA set to auto-delayed, so unsure if that played a part or not, but did nothing to help the issue before we replaced the vm nic.
I am having the same issue, but with a twist. I am unable to reset my NLASVC, because it will also restart Network List Service (netprofm), which will always get stuck in stopping. I am then forced to restart my server. If i try to stop Netprofm by PID, I will get an “access Denied” error 98% of the time.
Hey guys,
In the meatime I found another solution that seems to work way better !
Just put your NLASVC service in delayed startup and tada your problem is fixed :)
Work for me with the script I put above running behind to act like a failsafe and everything is fine now. For the info, I had the issue on 10 of the 150 serveurs I manage and these 2 solutions (delayed mode + script) has been working like a charm for a few weeks now :)
I’ve been fighting this issue for years and a combination of items from this page seem to have fixed it…at least on one new WS 2019 Standard VM running on WS 2019 Standard Hyper-V. As a recap (for me as much as anyone else!), these are the steps that I used on this server to get it to be able to reboot unattended without a panicked phone call a while later:
1) Enter the full domain name for the “DNS suffix for this connection” in the Ethernet adapter’s IPv4 properties, Advanced, DNS tab.
2) Set the NLA service dependent on having an active network connection and set to delayed start:
In an administrative command prompt:
sc triggerinfo NlaSvc start/networkon stop/networkoffsc config NlaSvc start= delayed-auto3)And the one that really made it work for me (Thank You Arnel!) was adding dependencies for DNS and NTDS:
In an administrative command prompt:
sc config nlasvc depend=NSI/RpcSs/TcpIp/Dhcp/Eventlog/DNS/NTDSI have restarted this AD DC 4 times now and it has found [its own] domain every time now, whereas before it NEVER found it without disabling/enabling the Ethernet adapter. (Stopping and restarting the NLA wasn’t an option on this machine because the Network List service wouldn’t stop.)
Thanks again!
@BobR, thanks for that summary! I should point out that DNS Server and Active Directory Domain Services (NTDS) only apply to some servers and never to client machines. Don’t make NlaSvc dependent on them if they’re not there! To check:
sc qc dnsandsc qc ntds.Alas, I’m still battling this on some Windows 10 clients. Even after the changes in BobR’s steps 1 and 2, the script fails because the Network List Service (netprofm) “could not be stopped” or “could not be controlled in its present state.” And then when I think all is lost, sometimes the adapter flips to domain joined on its own. Like NlaSvc has to take a leisurely stroll across the office, knock on the server, confirm it’s there, then agree to be domain joined.
@Mark Berry, good point about the DC! I was fighting this one in particular this time and wasn’t thinking past it. Good catch. I should also note that in my step #1, I always uncheck IPv6 on servers and workstations. So, that’s why I only included IPv4. (IMHO, there is no need for IPv6 on a small- to medium-sized network, and it adds complication when testing stuff.)
Anyway, thanks again.
@Mark Berry, BTW, about your Win10 clients…is the DC at the same site as the clients? And obviously your local DC is their DNS server handed out by DHCP (or hard coded).
One other thing to check – I read this somewhere – not sure where at this point – make sure your domain and forest functional levels are raised as high as your environment will support.
Bob, thanks for the reminder about DNS server. Yes, hard-coded. Supposed to be set by the Server Essentials connector, but it reminded me I should deploy my script to check the DNS server every hour, as sometimes that seems to change itself back to DHCP.
Hi again! I’m just following up on what I’ve been doing with this lately. An associate of mine and I had been manually running the following two commands when NLA doesn’t find the domain at startup (and sometimes NLA will not shutdown to restart):
sc queryex nlasvc (get PID#)
taskkill /f /pid PID#
This works every time (in my experience, at least) to kill the NLA service…which automatically restarts immediately and almost always finds the domain.
I finally sat down to try to automate this task. Getting the PID out of the first command to put in the second command was the trick…and a lot easier to do than I expected. The following in a batch file, run perhaps 10 minutes after restart (or every 10 minutes for that matter) should help cure some NLA ills:
for /F “tokens=1,2,3,4,5” %%A in (‘”sc queryex nlasvc |find “PID””‘) DO (
taskkill /f /pid %%C
)
Credit where credit due: thanks to https://stackoverflow.com/questions/19442819/cmd-exe-get-second-column-output-to-variable for the help in getting the PID number and feeding it into the second command.
Good luck,
BobR
Very interesting, thanks Bob!
I read one post, on another site, that said to enter the Server’s IP Address as a DHCP entry? I guess that means set a reserved address in the Pool. In non technical terms, I am thinking a few things
a. The address was issued my the domain (maybe NLA, of which I know nothing gives that a big tick), and
b. delaying the start of when the server get’s its IP address – DHCP has to be loaded first. It well may be a timing issue that this resolves? The most common comment is, restart NLA, it joins the domain.
My problem is Trend Worry Free Business Security, no Trend installed, NLA works a treat. I will say that again for those in disbelief, NLA works a treat.
Install Trend on the Server and NLA goes into Unidentified Network mode and joins Public, five minutes after booting, something figures to out and goes OMG, I am a domain after all. In the five minutes of terror, Trend is the ultimate security protection platform, because on Public, domain ports I need open are closed, totally secure!!!
I have not tried the above solution and don’t see why I should, Trend need to sort this out, but no doubt NLA has a touch of the Dark Lord in the code. I bet there are many 2019 Servers working with Trend. My version is Essentials, that is all I need, maybe Trend is going, ahhh Essentials, kill it know. Essentials is a virus ;)))
I’m only using Microsoft’s Windows Defender, not Trend, and still have problems on clients. The 2016 Essential server itself always knows it’s on a domain.
Hi
Thanks for this blog. I am having an issue for one of my clients, the issue only occurs when connected via VPN. I dont think its the same issue where the network profile is incorrect. All other services work such as internet, mapped drives applications etc.. when connected to VPN. The issue we are having is with Outlook 2013 connectivity with Office365. Users get we are unable to connect you right now. Restarting the NLA service helps the majority of the time. I have set a scheduled task that restarts the NLA service upon a successful network connection / profile change. Sometime it may fail due to not being able to restart the dependent services, but majority of time this is working for me on Windows 7.
Very Informative. Thank you.
@ZAHEER IQBAL
We have problems with detecting domain network over VPN due to
https://appuals.com/fix-multiple-tap-win32-adapter-oas-and-tap-windows-adapter-v9-connections/
VPN is Juniper Pulse Secure, TAP adapter was installed by third party software and not used for VPN.
After uninstall TAP software, detection is OK.
Office 365 in VPN can be Windows bug – system proxy autodetection (winhttp)
Occurs in situation, when default routing is to VPN (no direct internet for system during VPN) and system need autodetect internal proxy to access internet.
https://www.zdnet.com/article/new-windows-10-bug-hits-home-working-outlook-o365-teams-cant-access-internet/
You can easily check system internet access state – move mouse over network icon.
Maybe you would like to consider the following blogpost in German.
https://www.msxfaq.de/netzwerk/grundlagen/network_location_awareness.htm
It helped me out. Thanks.
@Andreas, sehr interresant, vielen Dank! Very interesting, thank you! There is some good background in that article about how the NLASVC works, which event log to check, etc. Also the explanation of LDAP failure is news to me. He says the problem is mostly on servers, but in my single-server environments, for me it is mostly on clients.
Did the article lead you to any new solutions or was it more just background information?
Here is an English translation (I haven’t checked it for accuracy):
https://translate.googleusercontent.com/translate_c?depth=1&hl=en&prev=search&pto=aue&rurl=translate.google.com&sl=de&sp=nmt4&u=https://www.msxfaq.de/netzwerk/grundlagen/network_location_awareness.htm
Thanks Mark. Mainly it was a minor problem about NLA, network detection and internet access of some W9X-clients that lead me to your excellent Blog and the cited informations.
In my particular case it was from
https://www.sevecek.com/EnglishPages/Lists/Posts/Post.aspx?ID=72How to force network profile redetection with NLA and Windows Firewall
“In order to detect Domain network profile correctly, the NLA service must be able to issue LDAP UDP ping against the PDC of the domain and if such a machine is not yet accessible for any reason, it falls back to Public network profile“
## Zusätzlich macht der Client auch noch eine HTTP-Anfrage auf einen Server zu machen um zu prüfen, ob er in das Internet kommt. Der Client prüft dabei auch noch, ob der Inhalt überein stimmt. Probieren Sie es doch einfach mal aus. ##
that helped me out. Regards.
I have removed the hyperlink from the site you reference because that web server is using an out-of-date TLS protocol. I was unable to open the link in Firefox, but I did see it in Internet Explorer 11.
Translating the German: “In addition, the client also queries a server via HTTP to determine whether it can reach the Internet. The client further checks whether the content matches. Try it yourself.” (It does not specify which server or content.)
I could see how some packet tracing could help when trying to determine exactly why NLA is failing to detect the domain. Of course, one still has to find a solution, such as enabling PortFast / FastLink (if that option is available on your switch), setting the service to delayed start, restarting NLA after a minute, etc. It’s a pity Microsoft doesn’t just fix this functionality e.g. by re-testing for domain connectivity every few seconds for the first five minutes.