17

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?

4
  • 1
    I edited your question a bit to help focus it on asking about solving the actual problem. See XY problem. Jan 8, 2018 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? Jan 8, 2018 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, 2018 at 23:44
  • @PaulH .... Did you ever get a chance to test with the answer I provided below? Jun 2, 2020 at 3:41

2 Answers 2

7
+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

7
  • 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.... Jan 13, 2018 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. Jan 13, 2018 at 20:40
  • I have the same issue when creating a hyper-v virtual switch of "internal" type for communication between gest and host. It creates a host vEthernet adapter that I set with a local non-routable IP. It gets identified as "unidentified" possibly because there is no DNS. Your "Using Local Security Policy" solution was the only thing that worked though it's a bit insecure incase it someday decides to "unidentified" my public LAN adapters. I could not find any other way to force the INTERNAL adapter to identify or private. No profile in registry. Method 1 would work but the index can change
    – eng3
    Mar 24 at 2:39
  • @eng3 If you can name or label the adapter and know it will not change, you could identify it's index based on some other more "static" property (maybe the mac address?). You could test, research, adjustment, and then implement the logic to do it this way—dynamically get index value from other property that will not change. Nowadays, I would scheduled a PowerShell script rather than the batch logic to build and execute PowerShell the way I wrote this in 2018. Mar 24 at 16:33
  • I gave up and set the default for unidentified to private. Not ideal but for a server that never moves, I guess it should be ok. I didn't think about setting a name, I'll see if that works
    – eng3
    Mar 25 at 17:09
1

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"

8
  • 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? Jan 15, 2018 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, 2018 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? Jan 15, 2018 at 21:13
  • Without NLA there are no profiles at all. What are you using these profiles for?
    – HackSlash
    Jan 15, 2018 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. Jan 15, 2018 at 21:37

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .