Updated February 11, 2019: I was able to resolve the issue by setting the Cisco switch port configurations to an Edge Port. I’ve updated the post with the final solution.
I was struggling to identify an issue where Windows Server would boot with an Unidentified, Public, or Private rather than the appropriate Domain network type. This caused the Windows Firewall to kick in blocking my RDP access. Restarting the Network Location Awareness service or cycling one of the Network Adapters would resolve the issue. But the root cause was a mystery until just recently…
While I was researching my issue I determined there were numerous reasons why Windows Server 2012, 2012 R2, 2016, and 2019 will fail to properly identify a network. Here’s a few scenarios:
- When multiple Network Interface Cards are present and one or more do not have a Default Gateway specified. For example, when dedicated NICs are used for an iSCSI network.
- When Windows Server NIC Teaming is configured as switch independent. If the team consists of more than 1 Active adapter, Windows Server will fail to identify the network type as “Domain”.
In my case, I was using Windows Server 2016 NIC Teaming configured with two Active adapters using the Switch Independent mode for my Management Network (on separate Cisco Nexus switches). I also have two more NICs configured for iSCSI without a Default Gateway assigned. After the server would reboot, the network identified as “Public network” or “Private network” when it should have been identified as a “Domain network”. I found all sorts of potential solutions from delaying the start up of the Network Location Awareness service (NLA), adding a Default Gateway to the iSCSI adapters, disabling all unnecessary protocols on the iSCSI NICs, and editing Group Policy. But none of these were the solution.
As indicated, there are numerous reasons why the Network Location Awareness service could fail to properly identify a Domain Network. Naturally, there’s numerous solutions as well. I’m not really sure which is the “correct” solution, but I’m going to list all of the “fixes” I came across during my research including the final solution.
Delaying the Startup of the Network Location Awareness service
Change the Network Location Awareness service Startup type from Automatic to Automatic (Delayed Start). Reboot the machine to test.
Change the Network Location of an adapter using PowerShell
This method forces a network to identify as “Domain network”. I couldn’t get this to work properly but numerous threads throughout popular tech forums indicate this could resolve the issue.
- Launch PowerShell as Administrator.
- Type the following command to list the Network Connection Profile and note the InterfaceIndex number.
Get-NetConnectionProfile
- Run the following command replacing ? with the InterfaceIndex number to force the network to identify as “Domain network”.
Set-NetConnectionProfile -InterfaceIndex ? -NetworkCategory Domain
- Run the following command again to verify the change has been made.
Get-NetConnectionProfile
Modify the NetworkName and PolicyOverdue settings in the Registry
This method appears to add a piece of missing information to the Registry. In my case the NetworkName value was empty. I set the NetworkName to the domain name, changed PolicyOverdue to 1, and then restarted the NLA service. But I still have no luck.
- Launch regedit.exe.
- Browse to HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Group Policy\History.
- Set NetworkName REG_SZ to your domain name.
- Set PolicyOverdue REG_DWORD to “1”.
- Restart the Network Location Awareness service.
Change Switch Port to an Edge Port
This is the solution that worked for me. Once I updated both ports, the server always identified the network type as “Domain” after a reboot.
spanning-tree port type edge
If you’re using a Switch Defendant mode for NIC Teaming, this change must be made to both the port configuration as well as the team configuration.