Forum Discussion
Solved
When is Network Profile Issue for Domain Controllers going to be at least acknowledged?
Since the insider builds from 25398 to the latest 26227 all have the same bug where the domain controller on the builds will show the network category as Public instead of DomainAuthenticated and the only way to fix it is to disable and re-enable the NIC after each reboot.
There has been a few bug reports submitted in the feedback hub and in this community many months ago. It would be at least be nice to be acknowledged.
I did hear back from my Microsoft contact on what it exactly is that's causing it. It's an LDAP packet that's trying to get to ::1 (Loopback) over the IPv6 interface, and it's being dropped, and one thing that breaks 2025 out of the box, is turning off IPv6, or even setting it to prefer IPv4 using the proper registry keys, not turning it off in the IP stack settings in the NIC configuration. Never turn off IPv6 in the NIC configuration settings.
This condition is leading to a timeout with connection to loopback being dropped, and therefore it is causing this behavior of the domain controller taking an extended time to boot as well as have the improper NLA detection for the NIC and firewall profile.
It was first recognized in Windows Server 2019, but fixed in 2022, and it's surfaced again in 2025. They state pretty much what you line up with in a fix coming very soon, but they have to be certain before it rolls to global distribution channels.
39 Replies
MS has been aware of this problem for months and has not resolved it. They continue to push their "Cloud First" and ignore clients issues. Take a look at Microsoft lays off staff article from the AP. Maybe the reason fixes are delayed. The only simple solution has been to use a script to restart the network adapter.
Untill they fix it, I'm simpy bouncing the cards at bootup.....
Server 2025 Network Profile Wrong After Reboot
It's a bit primitive, but it works
</P>I have learnt today, 03/20/2025, that a fix for this bug is in the works. I asked if there was anything we could reference though the symptoms and workaround reported here are pretty clear - i.e. restart the net adapter. Something of a timing problem it seems. The response to my ticket was to wait until after regular patches in April 2025 and then try the promotion again which I think is what some of the other guys have alluded to here. Therefore, we may see a resolution\patch by mid to late April 25. I aim to try promoting a 2025 Domain Controller at that time to see if the patch fixed the issue. If I still see the same Network Profile behavior, then I'll reopen the ticket I had with MS. Personally, I think "Windows Server 2025", member server is pretty OK, but I would not promote any servers to be a Domain Controller until this bug is squared away.
Microsoft is a big company and sometimes the engineers handling our issues are as hamstrung as us as to what the product teams are working on, so I do not blame them but rather Microsoft's transparency. A more transparent list of known issues and documentation for infrastructure engineers would be nice so we can stop wasting our time. I do not believe I have ever seen anything like this officially from MS but perhaps someone knows a site? This ticket ultimately wasted my time and the engineer's time - good to know that there is something in the works but unfortunate we had to spend two to three weeks on it.
I did hear back from my Microsoft contact on what it exactly is that's causing it. It's an LDAP packet that's trying to get to ::1 (Loopback) over the IPv6 interface, and it's being dropped, and one thing that breaks 2025 out of the box, is turning off IPv6, or even setting it to prefer IPv4 using the proper registry keys, not turning it off in the IP stack settings in the NIC configuration. Never turn off IPv6 in the NIC configuration settings.
This condition is leading to a timeout with connection to loopback being dropped, and therefore it is causing this behavior of the domain controller taking an extended time to boot as well as have the improper NLA detection for the NIC and firewall profile.
It was first recognized in Windows Server 2019, but fixed in 2022, and it's surfaced again in 2025. They state pretty much what you line up with in a fix coming very soon, but they have to be certain before it rolls to global distribution channels.
> one thing that breaks 2025 out of the box, is turning off IPv6
It sounds like you're saying this only happens if you turn off IPv6? I've got the issue but haven't touched IPv6 or made any registry changes re. IPv4. In Network Connections, I assign an IPv4 address as the static IP and DNS server. In ipconfig /all, IPv4 shows as "Preferred" while IPv6 just has a Link-local address. Interesting that DNS shows the IPv6 address (::1) first, then the static IPv4 address.
Had the same issue with 2022 but AlwaysExpectDomainController etc. fixed it there. With 2025, I'm restarting the NIC after every reboot with a script I blogged here.
OS build: 26100.3194
And The Problem persist...
It's unbelievable how bad Microsoft support has become these days.
Here another issue where we are Fighting with Microsoft..... interesting for this who have WHfB in place....
In the threads some noted that they started support requests (SR) with Microsoft.
Who have done so?
What's your SR number?
What was the outcome?
I could try to get things moving. Not sure if the issue can be fixed.
Thanks for sharing!
Hello, I won't give a specific SR, but our escalation team leader is Tony Gaston.
This issue has been there for a while now and on Server 2025 DCs we are facing the same problems. Ofc it's nice with the workaround, but when can we expect Microsoft to fix that nice feature?
- not applicable
- Yea. That article is for folks that don't understand AD.
I have found this issue beginning in Nov 2022, even with Windows Server 2022. It rared its ugly head after that kerberos fix that November that broke the world. After that, there was a hotfix that fixed it on 2022, 2019, 2016, etc. I noticed this began again in the early vNext 2025 builds. It's still there as of the build available today, even after all the hotfixes apply after updating. Obviously the bandaid for now is restart-netadapter * - or specify your NIC name, if you're concerned about it restarting the wrong NIC, to run at startup via Task Scheduler. This really isn't a fix, but a mere stopgap to allow this to operate properly as it becomes a domain controller. Let's hope someone from MS is paying close attention and addresses this. I've tried all the registry keys, etc, and that does not work. In fact, I think 2025 completely ignores the AlwaysExpectDomainController as everyone swears is the fix. I think they still have problems. This appears to be a nasty conflict between NLA, Windows Defender Firewall, and something hanging in the OS upon the NIC initialization. Also, setting service dependencies isn't the answer either. This should work out of the box. Glad I'm not the only one having this issue.
- AlwaysExpectDomainController does not work with Server 2025.
Re-enables the Ethernet Adapter sounds like a workaround.
When can we expect a solution?
I don't understand the purpose of this forum if no one from the Program Group comments on problems that are mentioned 3-5 times?
sorry- Kinda amazed this obvious of a bug has been around so long, some basic testing you'd think would catch this.
Disabling and re-enabling the NIC resolves this issue, but upon reboot it goes back to public.
Other people have reported the same:
https://techcommunity.microsoft.com/t5/windows-server-insiders/domain-controller-showing-network-connection-as-public/m-p/3948439?search-action-id=747851316514&search-result-uid=3948439
https://techcommunity.microsoft.com/t5/windows-server-insiders/server-2025-core-adds-dc-network-profile-showing-as-quot-public/m-p/4125017?search-action-id=747851316514&search-result-uid=4125017- tyvm! looks good (or not). Will this also happen before the VM is a AD DS server (DC)?
have you disabled IPv6 or all "stock config"?
What is your external DNS in DNS forwarder on each of the DCs?
Without it the machines cannot see the internet. Test-Connection www.google.de should fail.
Agreed this should not affect the network profile (NLA). but worth looking into.I can confirm the easy fix for the issue related in your article is to simply define a local IPV6 address for the NIC. It appears windows attempts to ping the IPV6 adapter as part of it’s integrated NLA process for a Domain Controller, regardless that NLA service is purposefully shut down.
For example, set the IPV6 to this for both the IP and DNS: fd12:3456:789a:0001:0000:0000:0000:0063 /64
My adapter on the test Windows 2025 Domain Controller immediately switched from a ‘Network 2’ profile to the 'test.local' domain and persisted after reboot!
- As soon WS 2025 DC works with mslab I can look into that, to see if it's reproducible on my end.
Could you share get-netadapter, and get-netipconfiguration, please?- 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.
Wes808 my case with MS is still being reviewed. I have good news. The Microsoft engineering team was able reproduce it! That's a good sign. I figured people would start upgrading their DCs and take down their network essentially.... There's a workaround. Do a restart-netadapter * to bring the proper profile back. Set that up as a scheduled task to run at startup for now. More to come.
