Domain Controller under Windows Server 2025 currently have the problemthat an incorrect network profile is loaded. After restarting the server, the network profile "Public" is loaded, although it is a domain controller. Here is a screenshot from the GUI directly after starting the operating system
And here is a screenshot from the PowerShell:
You can see that the network adapter is in the "Public" profile, but the "Domain Autehnticated" profile should actually be loaded here. It should look like this in the GUI:
And in the shell as follows:
There was a similar problem with Windows Server 2022, the fix from "back then" (adjust dependencies of the "Network Location Awerness" service) no longer helps with Windows Server 2025.
The only thing that currently seems to help is restarting the network adapter after system startup. Here is an example:
I have already received a few emails on the subject and, as you can see, I was able to reproduce the behavior.
To be honest, I didn't notice that the wrong profile was being loaded during my initial tests, as I didn't notice any problems. I would therefore be interested to know whether you are experiencing or have experienced problems with the wrong network profile.
By default, the Windows Firewall rules for domain controllers are loaded in all profiles. Here is an example:
In my environment I have not noticed any problems, domain join, GPOs, replication, etc. all work as expected. I have therefore so far dismissed it as a cosmetic problem. Is it different for you?
The only solution that works for me is to restart the network adapter. However, this has to be done after every system start, as the public profile is reloaded after every restart. I have therefore created a scheduled task as a workaround, which restarts the network adapter at system startup. Here are the settings:
The small PowerShell script then takes over the restart:
$NetworkCategory = Get-NetConnectionProfile.NetworkCategory
if ($NetworkCategory -match "Public") {
Get-Netadapter | Restart-Netadapter
}
Feel free to write in the comments what experiences you have had.
Hi,
When trying to use "Get-NetConnectionProfile.NetworkCategory" from the PowerShell script above on the 2025 server, I get the following error message:
Get-NetConnectionProfile.NetworkCategory : The term 'Get-NetConnectionProfile.NetworkCategory' is not recognized as the name
of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify
that the path is correct and try again.
At line:1 char:1
+ Get-NetConnectionProfile.NetworkCategory
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : ObjectNotFound: (Get-NetConnectionProfile.NetworkCategory:String) [], CommandNotFoundException
+ FullyQualifiedErrorId : CommandNotFoundException
"Get-NetConnectionProfile" itself works of course.
Have I missed something?
Found it out myself - the brackets are missing :)
(Get-NetConnectionProfile).NetworkCategory
In my opinion, this problem with the LAN adapter and domain controller is as old as the domain controller itself.
This was really noticeable with Windows 2003 and environments (of course) with only one domain controller. Presumably the network discovery starts even before the AD services are running and the NIC only sees "any" network and sets it to public or private (which can be set as the "default" in the local security settings. Domain does not work there.
With at least two DCs in the LAN, the effect did not and does not occur so frequently. Nevertheless, it happens every now and then. So far, we have only ever run the action with deactivation and activation (just as the AD services are fully started).
In my opinion, MS should generally revise the procedure here. It is best to always match the profile to "Domain" for a DC. Nothing else makes sense anyway!
It definitely helps to briefly deactivate "Internet Protocol Version 6", i.e. IPv6, in the NIC and then reactivate it.
It might therefore also help to give preference to IPv4 over IPv6 by policy. (Just can't test it at the moment).
reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters" /v DisabledComponents /t REG_DWORD /d 32 /f
The value 32 (decimal) means that IPv4 is preferred over IPv6.
Here is the current customized code:
$NetworkCategory = (Get-NetConnectionProfile | Select-Object -ExpandProperty NetworkCategory)
if ($NetworkCategory -eq "Public") {
Get-NetAdapter | Restart-NetAdapter
}
Create and insert NetFix.ps1.
Your script with the dot notation did not work for me.
Only after adjusting to "(Get-NetConnectionProfile).NetworkCategory" did it work.
Hello, I have installed a test DC with Server 2025.
I cannot add a new entry under HKLM:\SYSTEM\CurrentControlSet\Services\NlaSvc\Parameters.
The error message "Value cannot be created. Cannot write to the registry".
I am logged in as a domain admin and have read-only rights there.
I wonder how the other people were able to insert the values.
Regedit also started explicitly as administrator?
Take a close look at the path. There is a similar one under Services, where you only have read rights.
In my opinion, this problem has existed since Windows Server 2016. It is usually only noticeable if there is only a single DC and it also uses 127.0.0.1 as the only DNS.
So the problem has been haunting us since at least 2012 R2.
However, it was not always limited to DCs. For example, our standard check after server startup always includes checking the firewall profile.
But the DC problem is age-old. The NLA restart no longer works.
The recommendations given for the service dependencies can be quite extensive, but experience has shown that they do not always lead to success.
We rely on DCs that repeatedly have the problem, including the RegKeys mentioned by Mariette. That is the only thing that leads to lasting success.
But you can do even more in this context.
See: https://learn.microsoft.com/en-us/answers/questions/400385/network-location-awareness-not-detecting-domain-ne, the post by Sunni Qi.
If you still want to fix it manually and do not want to/can't restart the adapter for some reason; in our experience, it is sufficient to briefly deactivate/activate TCPiP v6 on the ETH. This also triggers NLA and then leads to the correct profile.
I installed the server as a domain controller in the test environment immediately after it appeared and also ran into this problem. NLA restart no longer helps here. I really didn't feel like investigating this problem any further, you really wonder how it was possible to release this server in this state.
I have postponed a possible productive use until at least 2026.
that always helps me
sc config nlasvc depend=NSI/RpcSs/TcpIp/Dhcp/Eventlog/DNS/NTDS
I always do the same and set the "NLA (Network Location Awareness)" service to "Automatic (delayed start)"
New-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\NlaSvc\Parameters" -Name "AlwaysExpectDomainController" -Value "1" -PropertyType "DWORD"
Restart-Computer -Force
Yes, IMHO this is also the only permanently functioning solution, since at least Server 2019.
Exactly, that is the best solution to this problem. Lake https://www.google.com/search?q=AlwaysExpectDomainController+server-essentials.com
Is the entry sufficient?
I usually read that these two entries are also necessary:
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\NetLogon\Parameters" -Name "NegativeCachePeriod" -Value 0 -Type DWORD
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters" -Name "MaxNegativeCacheTtl" -Value 0 -Type DWORD
Nope,
According to some English blogs, these tricks via registry or dependencies on the NLA all do not work in Windows Server 2025. MS seems to have changed something internally here.
Unfortunately, I can confirm this in my test environment.
There should be a workaround so that the registry entry works again, namely an IPv6 address must be assigned.
Unfortunately I can't test it myself at the moment.
We had already noticed this with Windows Server 2019 and Windows Server 2022 as domain controllers. Restarting the NLA service on the affected DC usually helped.