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.
Used the following for reference: Network location awareness not detecting domain network from offsite location - Microsoft Q&A
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NetLogon\Parameters
Name: NegativeCachePeriod
Type: REG_DWORD
Value Data: 0 (default value: 45 seconds; set to 0 to disable caching)HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters
Name: MaxNegativeCacheTtl
Type: REG_DWORD
Value Data: 0 (default value: 5 seconds; set to 0 to disable caching)HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NlaSvc\Parameters
Add a DWORD parameter :AlwaysExpectDomainController
Set value to:1
After reboot - Get-NetConnectionProfile returns DomainAuthenticatedWhile that may work for some to get it working, the consensus is the "bandaid" is to restart the NIC after bootup. Unfortunately, neither of these are considered fixes for an out of the box product, that's broken... out of the box. I did hear back from my Microsoft team, and it has been escalated again. They expect a fix in the coming months (an actual fix)
It's now the END of February - and still no fix?
RidiculousIt's not a secret that MS 2025 has been a problem for plenty of administrators, the NLA not being the only issue. The only possible way to have some reliability is to keep an older DC around in case of an unexpected reboot. MS new administration from the CEO down are turning out to be a disaster, more concerned with the cloud's money machine than with their software clients.
When will they start paying attention again? Who knows.
Any plans from MS to fix that for Server 2022 and 2025?
Eleanor_LittleMicrosoft
Thank you everyone for reporting this issue! A fix for it is in the works and should be coming soon. In the meantime, resetting the network adaptor by running "restart-netadapter *" OR "Restart-Service NlaSvc -Force" via PowerShell or CMD Prompt is a workaround.
I appreciate a functional workaround, but this issue has been present (particularly for single DCs) for many years now. Previously, the solution was restarting the "Network Location Awareness" service.
One of Microsoft's biggest and oldest server features should not be broken out of the box for this long!
Fix is "in the works"? Wow, just wow! ! I mean, this issue has been reported ever since Server 2022 has been released (Google "AlwaysExpectDomainController" to get a clue, perhaps), lots of people opened a case with MS to no avails as usual. In fact, MS has done nothing but making the problem even worse by making the restart of nlasvc impossible / broken even in 2022 somewhere mid-2023 (the Services console does not work, the PS command you suggest does not work if you bothered to test, the only way to restart the process is to forcefully kill the process).
In addition, MS has broken the known registry workarounds floating around the internet in Server 2025.
Now you come with restarting network adapters hack. Sheeesh. Get your act together, seriously.
🤯
Hi Eleanor, I have a case open with the product team, and it has been escalated, but would you mind telling them to add this little issue to that bug list, it's not present on that list. Thanks in advance!
- Eleanor_Little
Unfortunately, I can't ask for your case to be updated or provide issue details about your case to the product team on your behalf. You will want to update and provide information yourself about the issue if you are experiencing it in your open case.
Issue still persists after JAN CU KB5050009.
After reboot, repadmin /replsum shows error 1908 (could not find the DC for this domain) with its primary replication partner.
Workaround with the following PS:
Restart-NetAdapter -Name "adapter"
Restart-Service -Name "netlogon"
We are also having the same issue. Any explanation as to why Microsoft went to production with such an obvious and impactful defect?
We are also having the same issue. Any explanation as to why Microsoft went to production with such an obvious and impactful defect?
Yes, the Microsoft's incompetence. The same that we see in Windows 11.
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.
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
Don’t expect a resolution of this problem before next year as MS has posted a notice with the November 12 updates as follows:
IMPORTANT Because of minimal operations during the Western holidays and the upcoming new year, there won’t be a non-security preview release for the month of December 2024. There will be a monthly security release for December 2024. Normal monthly servicing for both security and non-security preview releases will resume in January 2025.
Let's hope January will bring much needed fixes for all the WS 2025 issues.
