13

I am managing a small business network with a number of Windows 10 and 7 PCs. Intermittently but quite frequently users complain that they can no longer access shared folders with other co-workers. Quick troubleshooting determines that the issue is due to the infamous "Unidentified Network detected" which then applies the "Public" network profile instead of "Private" network profile, thus Homegroup/file sharing, etc. does not work. From my searching this is a common problem for many users. I do not see any proposed solutions that work.

Environment:

  • All Windows PC are connected via wired Ethernet (though they may have a Wifi NIC)
  • They are all connected to a 48 port Avaya L2 managed switch, all on the same 10.10.10.x subnet
  • The switch is connected to an Asus RTN-66U home router
  • The Asus router connects to Cable modem
  • The Asus router provides DHCP to Windows machines
  • I have configured the router with DHCP reservations for each Windows PC, i.e. PCs always get the same IP address on bootup
  • No domain controller

Problem:

Even though I have configured all Windows machines active network profiles = Private, they frequently (every couple of weeks or so) revert back to Public, which prevents file sharing etc.

Fixes attempted:

On each Windows PC I have modified the Local Group Policy Computer Configuration->Security Settings->Network List Manager Policies:

  • Unidentified Networks = Private
  • Identifiying Networks = Private

Observations:

I believe the issue is that the Windows Network Location Awareness (NLA) service is detecting a new network which causes a new Network Profile to be created which then defaults to Public (even though above I have configured the Local Group Policy to default to Private). Many of the computers show that Windows has detected a new Unidentified Networks many times, i.e. they show "Network 14", i.e. there are 14 different network profiles. I see these multiple profiles when reviewing the profiles here in the Registry: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\NetworkList\Profiles.

All 14 profiles are when the computer was actually connected to the same network described above.

I have not been able find a resource that describes exactly how NLA generates a unique identifier for a network and thus why it might detect that it has discovered a new network.

Question:

How do I keep Windows from incorrectly identifying my local network as a new network? Perhaps it would help if I knew what steps NLA follows to generate a unique identifier for a network?

  • 1
    I edited your question a bit to help focus it on asking about solving the actual problem. See XY problem. – I say Reinstate Monica Jan 8 '18 at 22:59
  • NLA identifies a network based on the MAC address of the default gateway specified for that network adapter. Is it possible your router has become inaccessible to these computers? Does the problem seem to affect multiple computers in a short window of time, or is it only one user one day, then another user at a completely different time? – I say Reinstate Monica Jan 8 '18 at 23:09
  • Perhaps look at Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\NetworkList\Signatures\Unmanaged or at least around that location in the registry - and see if the DefaultGatewayMAC and DNSSuffix match what you expect – Ross Jan 8 '18 at 23:44
  • PaulH - Check out my answer when you get a moment, this is what I've used with rather solid success in a production environment as I put in the Method 1 section but I also provided more detail with the Method 2 section of my answer. I hope you find any of these solutions as helpful as I have for this issue. – Pimp Juice IT Jan 12 '18 at 17:23
5
+150

Method 1

One way I've dealt with this issue on a critical Windows Server system in one environment I maintain was with a batch script that uses Set-NetConnectionProfile and netsh, and explicitly set each trusted NIC/adapter on the machine to private at system startup with Task Scheduler using Run whether user is logged on or not and Run with highest privileges option.

enter image description here enter image description here

Note: While the bounty note states "The solution must not cause loss of network connectivity to implement" I wanted to mention that since when this issue occurs you have a network disruption anyway, that running this script if the issue occurs randomly when the system is not rebooted that simply running this same script then will still quickly resolve the issue and get the OS machine network access back in the working and expected order.

Furthermore, you can use the Get-NetConnectionProfile to get the NIC alias names and index numbers to put into the example batch script below for your needs and/or systems.

Batch Script

@ECHO ON

::: The below PowerShell will set all the nework adapters to private rather than public and unknown as happens.
:DynamicPSScriptBuild
SET PSScript=%temp%\%~n0.ps1
IF EXIST "%PSScript%" DEL /Q /F "%PSScript%"
ECHO Set-NetConnectionProfile -InterfaceIndex 12 -NetworkCategory Private>>"%PSScript%" 
ECHO Set-NetConnectionProfile -InterfaceIndex 20 -NetworkCategory Private>>"%PSScript%" 
ECHO Set-NetConnectionProfile -InterfaceIndex 22 -NetworkCategory Private>>"%PSScript%" 
ECHO Set-NetConnectionProfile -InterfaceIndex 24 -NetworkCategory Private>>"%PSScript%"

:PowerShell
SET PowerShellDir=C:\Windows\System32\WindowsPowerShell\v1.0
CD /D "%PowerShellDir%"
Powershell -ExecutionPolicy Bypass -Command "& '%PSScript%'"

:: The below will disable and then re-enable each NIC one-by-one so the unidentfied goes away after set to "private" above
:ResetNICs
SET Array="Ethernet", "Ethernet 2", "Ethernet 3", "Ethernet 4"
FOR %%A IN (%Array%) DO (
    netsh int set int "%%~A" admin=disable
    netsh int set int "%%~A" admin=enable
)
EXIT

Below are a few other methods, with one of the many being what you have tried but I left it in there for others that come across this post in case it helps them, but these are a few ways to prevent this entirely perhaps but there are always going to be upsides and downsides to any method you choose to use so pick your poison and test accordingly.

Method 2 (Multiple Methods)

Unidentified Network - Move from Public to Private or Domain

If NLA can't determine a connections location, it names it "Unidentified" and marks the location as Public. It chooses Public because that is most secure and you wouldn’t want anything less if the connection is on the DMZ.

There are two easy ways to fix this. One uses the Local Security Policy to change the default location of unidentified networks. The second method uses a change to the network connection properties to give NLA the information it needs to properly place the location.

Using Local Security Policy

Caution: This should only be used if the computer will never have any connections on the Public LAN. Otherwise, you run the risk of having a less secure firewall profile applied to your public connection.

  1. Open "Local Security Policy".

  2. Click on "Network List Manager Policies" in the left pane. (This selection is buried in older versions of Windows.)

  3. Double-click on "Unidentified Networks" in the right pane.

  4. For computers that only exist on the private network, it is OK to set "Location type" to "private".

    enter image description here

Using Network Connection Properties

This is not about adding a gateway IP as that doesn’t work properly on a multi-homed server. Instead we will be adding a DNS suffix so that NLA can properly locate the domain controller which is how it knows to mark the location as “Domain network”.

  1. Go to Network Connections (from the Network and Sharing Center, click on "Change adapter settings".)

  2. Go to the properties of one network connection marked as "Unidentified" but on the private LAN.

  3. Go to the properties for IPv4.

  4. Click the "Advanced..." button.

  5. Select the DNS tab.

  6. Enter your domain name into the text box for "DNS suffix for this connection:".

Disable and then enable the connection to get NLA to re-identify the location. After enabling the connection, the Status should change to the domain name and Network Category to "Domain network". Depending on your setup, it is likely that you only need to "fix" one connection to get all the related connections to see the domain.

Move from Private to Public

There are two common ways to force NLA to mark a connection as public. One is to use a firewall rule to block NLA so that it has no choice but to use the default location. The other is to use the registry to disable NLA on the connection.

Using the Firewall

I haven’t tested this but the theory seems sound.

  1. Open "Windows Firewall with Advanced Security" (i.e wf.msc).

  2. Go to Outbound rules.

  3. Click on "New Rule…".

  4. Use these settings:

    • Rule Type: Custom
    • Program: Select "All programs" and then click on "Customize…". Select "Network Location Awareness" (short name is NlaSvc).
    • Protocol and Ports: Protocol type = Any.
    • Scope: Local IPs = Enter all your public IPs. Double-check for connections with multiple IPs.
    • Action: Block
    • Profile: All
  5. Once rule is enabled, disable and then enable the network connection to get NLA to re-identify the location.

Using the Registry

I have not had this work for me but my circumstance may be different from yours. Finding the correct connection number is a bit hit or miss as there are a lot more entries than you would expect.

  1. Run regedit

  2. Go to HKLM\SYSTEM\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002BE10318}

  3. Underneath you should see several keys labeled 0000, 0001, 0002 etc… Look through these and find the adapters where you want to disable NLA.

  4. For each of the adapters, add a new DWORD value named "*NdisDeviceType" and set it to 1 (make sure you get the * at the beginning of the name).

Getting Drastic

The location profiles are housed in the registry and it seems harmless to delete them and let Windows rebuild them. You will definitely want to backup the registry first and you will likely need to be connected to the server via KVM rather than remote (RDP). I will not take any responsibility if you choose this step as I am primarily putting this here for reference.

The location of the profiles is:

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

source

  • The first method looks promising. I'm unsure about the other methods that involve restarting the NLA service because that always fixes the problem anyway, making it hard to know if restarting the service was the solution, or the other action. Now I just need a machine that's doing this wrong to test on.... – I say Reinstate Monica Jan 13 '18 at 19:53
  • @TwistyImpersonator Yes, method 1 is the method I used and just have it run as startup. In this case, it's a Hyper-V virtual host server with 4 NICs and ensuring it runs as startup has thus far resolved the problem for me with that particular system. I think there was one other time it occurred due to a network switch or router reboot and rather than restarting the virtual host server I just ran the script manually and it resolved the issue. I noticed the question and posted the solution I've used and the other quoted resource that looked relevant and potentially helpful. – Pimp Juice IT Jan 13 '18 at 20:40
  • I noticed you put the bounty but I guess I didn't realize it was for your need rather than just trying to get the OP an answer. That's good to know as well. – Pimp Juice IT Jan 13 '18 at 20:42
0

I had this problem endlessly on just one specific system. It would break everything at each reboot. I tried all solutions you mentioned. After exhausting all else I resorted to disabling the "Network Location Awareness" service. From what I can tell it is not needed. This has permanently resolved my problem. The only side-effect I have noticed is that the "Network and Sharing Center" window looks funny. This service didn't exist before Windows 7 and is not useful to me at all.

Services.msc

"Network Location Awareness", Startup Type = "Disabled"

  • Hmmm, not sure this is a good idea in a domain environment...or when taking a laptop between trusted and untrusted networks. Any feedback on either of those scenarios? – I say Reinstate Monica Jan 15 '18 at 19:21
  • I'm doing this in my domain environment. Works great. If you are using your laptop in an untrusted environment you need to have other protections in place. NLA won't save you. All it could do is disable shares automatically. I would suggest not allowing any shares on laptops. – HackSlash Jan 15 '18 at 21:11
  • Without NLA, how do your systems switch between the domain and private profiles, e.g. when an employee takes a laptop home? – I say Reinstate Monica Jan 15 '18 at 21:13
  • Without NLA there are no profiles at all. What are you using these profiles for? – HackSlash Jan 15 '18 at 21:35
  • Many of the systems I manage allow inbound traffic when connected to the domain network, but such traffic is blocked when the systems leave the domain. It's how we implement defense-in-depth...ports are only opened where needed and closed everywhere else. – I say Reinstate Monica Jan 15 '18 at 21:37

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.