On domain controllers running Windows Server 2025, an issue occurs where the server incorrectly identifies the network as Public instead of Domain after a reboot. If some of your Windows Defender Firewall rules are applied to a network profile (location), it may cause issues with the server’s network availability.
The issue of the network type changing to the incorrect one after a restart is an old bug that has been encountered in domain controllers and member servers running Windows Server versions 2019 and 2022. Restarting the Network Location Awareness service (NlaSvc) was enough to automatically switch back to the Domain network profile in these versions of Windows Server. It is also possible to configure the startup delay for the NlaSvc service or implement a registry option that changes the behavior of the NLA service when it attempts to re-establish the domain connection.
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\NlaSvc\Parameters" -Name "AlwaysExpectDomainController" -Value 1 -Type DWORD
However, Network Location Awareness is disabled by default in Windows Server 2025.
To ensure that a Windows Server 2025 host correctly detects the network type, simply re-enable the network adapter after the computer reboots. If you have access to the server console (iLO or equivalent), you can disable and re-enable the network adapter via the ‘Network Connections’ control panel (ncpa.cpl).
If you only have RDP or PowerShell Remoting access to the DC, it’s possible to restart the network adapters using the PowerShell command:
Get-NetAdapter -Physical | Where-Object { $_.Status -eq "Up" } | Restart-NetAdapter
After this, the network will be correctly identified as a domain network (DomainAuthenticated).
Get-NetConnectionProfile
The issue with resetting the network type on Windows Server domain controllers is related to the DNS server settings. If the server uses itself as the DNS server, it may not respond quickly enough to DNS queries during startup (before the DNS server service is fully initialized) to determine the correct network status. That is why the secure Public profile will be assigned as the network type.
Therefore, ensure that the secondary DNS on the domain controllers points to the addresses of the other domain controllers, and avoid rebooting them all at once by spacing out scheduled reboots.
Alternatively, you can create a workaround using a simple PowerShell script in the Task Scheduler. It should wait for the DNS service to start and then restart the network adapter (run the task as SYSTEM):
Program/script: powershell.exe
Add arguments (optional): -ExecutionPolicy Bypass -NonInteractive -WindowStyle Hidden -command "do {$status = (Get-Service dns)} until ($status.Status -eq 'Running'); Get-NetAdapter -Physical | Restart-NetAdapter"
In order to apply this script to all DCs, you can deploy a scheduler task to the Domain Controllers OU via GPO.
1 comment
⚙️ If you are using Windows Server hosts in a domain network, you may experience an issue where the network profile type switches from ‘Domain’ to ‘Private’ after rebooting. This can cause problems with server or service availability if custom domain-based firewall rules are applied to a host and the network type has been reset to the wrong one
⚠️ The root cause is typically that, during boot, the host does not receive a timely response from the DNS server configured on its network adapter. This is particularly common on domain controllers, where the preferred DNS server is usually set to either the controller’s own IP address or the loopback address (127.0.0.1).
👉 Best practice: on a DC, configure another DC as the Preferred DNS server, and set the local DC as the Alternate DNS. Also, avoid rebooting all DCs at the same time 😊.
Alternatively, there are some workarounds:
🔹 In Windows Server 2016/2019/2022, the issue could be mitigated by configuring a delayed start for the NlaSvc (Network Location Awareness) service so that it starts after DNS.
🔹 In Windows Server 2025, NlaSvc is disabled by default, so a workaround is to add a PowerShell script to startup that waits for the DNS service to run and then restarts the network adapter: