Server 2019 Network Profile, Network Location Awareness and RADIUS issues

Copper Contributor

I'm presently checking out Serve 2019 in the lab. Did a clean install of Server 2019 and installation went flawless. Set up as PDC and for now this is the only DC on the network and as of yet no workstations are joined to the domain. I did however test to confirm I can join workstations, and can do so with no issues. The issues start when attempting to connect a wireless computer to the network.

First issue is that after installation and promotion to DC, Network & Sharing Center shows the server as being "Public". Via Powershell I can switch it to Private, but can not switch to Domain. The message states it must first be "authenticated". Huh? I since discovered that if I stop/restart NLA, then it immediately shows the network profile as Domain, and Windows Defender Firewall in control panel correctly shows that as the "active" profile.  So I changed the NLA service from Automatic, to Automatic (Delayed Start) and rebooted the server. No change. Even with a delayed start it still defaulted to the Private network profile. But a quick stop/restart of NLA instantly changed it to the Domain network profile.

   Next, I have a wireless access point set up to use this Server 2019 setup as the RADIUS server. I was able to correctly configure RADIUS for the WAP in NPS using the wizard to do so. A check of the RADIUS clients as well as the secure wireless connection policies shows they are all correctly configured on the server.

Now when I try to connect to the WAP from my wireless laptop I am correctly prompted for my domain login credentials (presently using the domain administrator credentials) but it fails with an "unable to connect" error.

I've checked that UDP ports 1812 and 1813 are open on the domain profile, and they are open. However, I still can't connect. However, if I turn off the firewall for the domain only, then it connects with no issue. So I suspect this has something to do with AD DS access through the firewall. But I've not a clue what ports to check.

So in conclusion, I've identified two issues thus far with server 2019.

 - NLA for some reason must be restarted manually to get the correct "Domain" network profile.

 - Wireless access via RADIUS will not work unless the domain firewall is turned off.


6 Replies



We are seeing this across all 2019 Domain Controllers we support out in the field.  Restarting the Network Location Awareness service will "fix" RADIUS communication for a time, but inevitably the issue returns.


I had thought hat setting NLA to Automatic (Delayed Start) would solve the problem, thinking it was related to DNS Server taking a longer-than-expected time to start, but this does not appear to be the case.

I have the exact same problem on a fully updated server in August.

The default rules for Network Policy Server does not work. Even if they show port 1812 as allowed they do not work.

If I delete this rule and create a manual rule allowing port 1812 for any program radius communication works as expected.

best response confirmed by Carl1959 (Copper Contributor)

@Carl1959 Maybe a bit late but for all others having this problem:


NLA uses dns to see what kind of network it is. If DNS is not fully functional at the time NLA starts, it cannot determine the domain existence. Simple fix: make nla dependant on DNS server


start regedit

navigate to: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NlaSvc

Edit 'DependOnService

Add new line with "DNS"


This fixes the problem for me so network profile is always 'domain' after a reboot

Perfect Solution. Thank you.