Forum Discussion
Server 2025 Core ADDS DC, Network Profile Showing as "Public" and not as "DomainAuthenticated"
OS: Windows Server 20225 Standard Core (no GUI), build 26085.1
Role: ADDS, DNS
ForestMode: Windows2025Forest
DomainMode: Windows2025Domain
Platform: Hyper-V guest
When standing up a clean Windows Server 2025 using server core and configuring it as a domain controller, the network category (profile) always shows as "public."
A clean load of Windows Server 2022 with server core as a domain controller has the same behavior. However, in Server 2022, the fix is to add DNS as a required service to the nlasvc (Network Location Awareness) service. Once that is done, the network category reflects "DomainAuthenticed" and persists between reboots.
In Server 2025, the nlasvc service does not have the same requiredservices as Windows Server 2022, and it does not start automatically. Even after configuring the nlasvc service the same way it is in Server 2022 and adding DNS as a required service, the network category still reflects "public." The only way to get the network category to properly reflect the "DomainAuthenticated" status is to disable and reenable the network adapter after each reboot.
This is not listed in the official Microsoft Windows Server 2025 known issues:
https://learn.microsoft.com/en-us/windows/release-health/status-windows-server-2025
Microsoft clearly has no interest in fixing this. They only seem to be interested in what affects their cloud services or for what that they can charge a monthly subscription for.
Or maybe they are not even aware of this bug due to their incompetence and ineptitude.
General available and the issue persist....
Build: 26100.2314
unbelievable!!!!!
Yea, we thought we were onto something with the IPv6 thing, but that is yet another bandaid. The ultimate bandaid is just to have a scheduled task that runs at system startup to execute a restart-netadapter * from an elevated powershell prompt as local system, that'll do it, for now... Yea, it sucks, having to wait an additional 2 minutes for the system to be in a state where you can access it, but that's the only way right now.
Hi JamfSlayer
How do you realize the Schedule Task, I have try several ways (bat, PS), but the Task just loop and never end, it stay in "running" status... if I run this Files manually work like a sham.... I do not understood where the Problem are.
Br
Mela
I'm having the same issue and it's unacceptable.
I've spent the day hardening a new AD for a customer and, after applying Dec CU, the DC is not seen as a DC anymore... because the network card is staying in public zone even after a restart/disable/enable of the network card.
How can MS stay so silent about this?
I'm going to open a case tomorrow, but I fear I'm not going to have any success about it.
If I have to re-create this AD, it's going to be a waste of time.
Thanks MS... I usually defend you when my customers are criticizing but this time, I'm going to have to agree with them.
Christophe, don’t expect a resolution of this problem before the January updates as they are under minimal operations mode due to the Western holidays and the upcoming new year. This has been the latest pattern exhibited by MS in support of non-cloud software. I agree with you post.
They (MS) did give me an update before I went on vacation that they would continue to troubleshoot this over the holiday season. Hopefully we'll see something soon.
If everyone could go into Feedback Hub in the settings of 2025, and explain this. Strength in numbers. I also have an open case with them that they have escalated to the product team. I have had this case open even since the pre-release. They took lots of captures, and logs, in both the failed states and after restarting the NIC. They thought my scheduled task to restart the NIC at boot up was clever. Yea, it works, but it's not clean and native and they understand this is not a true workaround or fix. There is light at the end of the tunnel as they were able to reproduce this issue in their lab.
The correct fix to this is adding a key to the registry:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NlaSvc\Parameters
Add a DWORD parameter : AlwaysExpectDomainController
Set value to: 1- This is an issue that exists for a while now in previous versions, and still not fixed from MS...
https://techcommunity.microsoft.com/t5/windows-server-for-it-pro/windows-server-2022-unable-to-restart-network-location-awareness/td-p/2722898 I just came across this problem and my solution was to make a ps script that disables and re-enables the Ethernet Adapter. Then I scheduled a task delayed by 1 min at startup, so that at least I don't have to do it manually every time I reboot.
- AlwaysExpectDomainController does not work with Server 2025.
Re-enables the Ethernet Adapter sounds like a workaround.
When can we expect a solution?Stefan_Voigt this is still a problem, even on the latest build of Server 2025. I have tried every suggestion, and the only thing that works is a scheduled task that does restart-netadapter * - that is not a solution. Microsoft needs to really focus on this. It's only when it becomes a DC that it does this. I really really really hope they don't let this bug roll into RTM, I've been following it since early vNext, and it's still lingering.
Unbelievable this is still an issue in the final build 26100.1742. I upgraded 2022 DCs in two different domains to 2025 and all of them have the public firewall profile set unless/until I disable/re-enable the nic.
- We have upgraded some DCs and ran into this issue. Came here trying to find a solution....
So it looks like M$ has known about this earlier this year, I don't understand why it persists on new builds. I was under the impression it was a new issue, but nope. They've know for over 6 months and still haven't fixed. Ridiculous.- Update: The only solution we have found is disabling and re-enabling the NIC.
I don't understand why we are scripting this on an issue that Microsoft was aware of over 6 months ago...
Again, what percentage of DCs do sysadmins want set to public? I'm still confused why anyone would want that in the first place.
- Microsoft, this is ridiculous...
We are rolling out new DCs with latest build and STILL having this problem.
I don't understand why a bug that was reported back in April is still happening. When is this going to be fixed?
Also, why is this even a default option? Are people taking their servers on strolls to public networks? I don't understand why it would default to this in the first place... The production release of the ISO still has this problem. Microsoft has escalated with their engineers, however, it still went RTM with this issue when you make it a DC. Any other server, probably fine to deploy, especially Hyper-V with all the good stuff that brings, like GPU pools, but don't make it a domain controller, unless you put that "bandaid" mentioned above in place.
