Forum Discussion
When is Network Profile Issue for Domain Controllers going to be at least 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.
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 https://www.mcbsys.com/blog/2025/03/server-2025-domain-controller-not-on-domain/.
Thank you Mark Berry. It's good to hear that workaround still applies.
At everyone I would need your SR numbers here or DM for escalation I am in Microsoft HQ this week and really like to address this reproducible issue. Would like help finding the common ground as it's not only IPv6 given your reports.
Thanks for your DMs.
Please also attach ouputs of
ipconfig /all > c:\ipconfig.txt
Get-ComputerInfo | output-file c:\computerinfo.txt
Msinfo32 > Export as Msinfo32.txt
Winget Export - o c:\software.xml
IPU or fresh install
Which iso file and filename (to determine LCU)
Ran sysprep?
Thanks! The more datapoints we have the better.
Thank you JamfSlayer for finding this solution.
There are several articles from Microsoft that IPv6 is actively used as loopback and for same subnet fe80 communication.
Here's a blogpost from my end in regards to IPv6.
Will backlink this thread BLOG: CVE-2024-38063 - Disabling IPv6 binding = fix - or not? | Microsoft Community Hub
