
Domain Controller sind zwar bekannterweise Rudeltiere, werden allerdings hier und da gerne mal als Einzelgänger gehalten. 🙁 In diesem Fall ist die Chance recht hoch, dass der einzelne Domain Controller* bootet und sein Netzwerk als „Unidentified network“ / „Nicht identifiziertes Netzwerk“ bzw. „Öffentlich“ / „Public“ erkennt. Das ist nahezu immer unschön und kontraproduktiv. 🙂
Update 17.04.2025: In den „Windows Server 2025 known issues and notifications“ taucht das Verhalten jetzt als Bug auf: Windows Server 2025 known issues and notifications | Microsoft Learn
Windows Server 2025 domain controllers (such as servers hosting the Active Directory domain controller role) might not manage network traffic correctly following a restart. As a result, Windows Server 2025 domain controllers may not be accessible on the domain network, or are incorrectly accessible over ports and protocols which should otherwise be prevented by the domain firewall profile.
This issue results from domain controllers failing to use domain firewall profiles whenever they’re restarted. Instead, the standard firewall profile is used. Resulting from this, applications or services running on the domain controller or on remote devices may fail, or remain unreachable on the domain network.
*) In the wild sind mir mittlerweile auch Umgebungen mit mehreren Domain Controllern und dem gleichen Problem untergekommen, dass nach Reboot eines einzelnen Windows Server 2025 Domain Controller, das Netzwerk als „Unidentified network“ bzw. „Nicht identifiziertes Netzwerk“ erkannt wird. Nach ein wenig Recherche, habe ich in der Microsoft Tech Community den am 21.03.2025 geupdateten Post gefunden: When is Network Profile Issue for Domain Controllers going to be at least acknowledged? | Microsoft Community Hub
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.
Um dieses Malheur zu korrigieren werden drei Registry Keys und ein kleines PowerShell Script benötigt, welches mit kurzer Verzögerung beim Systemstart des einzelnen Domain Controllers startet. Fangen wir mit den drei Registry Keys („AlwaysExpectDomainController„, „MaxNegativeCacheTtl“ und „NegativeCachePeriod„) an:
New-ItemProperty -Path "Registry::HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NlaSvc\Parameters" `
-Name "AlwaysExpectDomainController" `
-PropertyType Dword `
-Value 1 `
-Force
New-ItemProperty -Path "Registry::HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters" `
-Name "MaxNegativeCacheTtl" `
-PropertyType Dword `
-Value 0 `
-Force
New-ItemProperty -Path "Registry::HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters" `
-Name "NegativeCachePeriod" `
-PropertyType Dword `
-Value 0 `
-Force
Als nächsten wird natürlich das PowerShell Script „ReEnable-Ms_TcpIp6.ps1“ benötigt, dass beim Systemstart ausgeführt wird. Das Script geht her und nimmt sich die Netzwerkadapter* den Netzwerkadapter und deaktiviert das „ms_tcpip6“ Binding um es anschließend wieder zu aktivieren.
[string]$LogPath = "C:\Logs"
[string]$LogFile = Get-Date -UFormat "%Y%m%d%H%M%S-ReEnable-Ms_TcpIp6_log.txt"
[string]$LogFilePath = Join-Path -Path $LogPath `
-ChildPath $LogFile
[int]$i = 0
[int]$maxLoop = 7
if(-not (Test-Path -Path $LogPath -PathType Container)){
New-Item -Path $LogPath `
-ItemType Directory
Add-Content -Path $LogFilePath `
-Value "$(Get-Date -UFormat "[%Y%m%d%H%M%S]") - Created log path directory `"$LogPath`""
}
while(($NCProf = (Get-NetConnectionProfile).NetworkCategory) -ne "DomainAuthenticated" -and $i -lt $maxLoop){
$i++
Add-Content -Path $LogFilePath `
-Value "$(Get-Date -UFormat "[%Y%m%d%H%M%S]") - Loop $($i)/$($maxLoop): (Detected profile: $NCProf)"
Get-NetConnectionProfile |
ForEach-Object {
Disable-NetAdapterBinding -Name $_.InterfaceAlias `
-ComponentID ms_tcpip6
Start-Sleep -Seconds 5
Enable-NetAdapterBinding -Name $_.InterfaceAlias `
-ComponentID ms_tcpip6
}
Start-Sleep -Seconds 5
}
Add-Content -Path $LogFilePath `
-Value "$(Get-Date -UFormat "[%Y%m%d%H%M%S]") - Finished $($i)/$($maxLoop): (Detected profile: $NCProf)"
- Get-NetConnectionProfile (NetConnection) | Microsoft Learn
- Disable-NetAdapterBinding (NetAdapter) | Microsoft Learn
- Enable-NetAdapterBinding (NetAdapter) | Microsoft Learn
Zum Schluss muss das Script nur noch in einen Task mit dem Trigger „At Startup“ geplant werden. Für die Ausführung des Tasks bietet sich „SYSTEM“ an. Als Action sollte „Start program“ genutzt werden:
Program / script: C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
Add arguments (optional): -ExecutionPolicy Bypass -NoLogo -NoProfile -File C:\<Pfad zum Script>\ReEnable-Ms_TcpIp6.ps1
Schaut man einmal in das Logfile, sieht man, dass es grob drei Anläufe braucht, bis der Domain Controller soweit ist und sein eigenes Netzwerk als „DomainAuthenticated“ erkennt.
[20250418140721] – Created log path directory „C:\Logs“
[20250418140722] – Loop 1/7: (Detected profile: Public)
[20250418140743] – Loop 2/7: (Detected profile: Public)
[20250418140753] – Loop 3/7: (Detected profile: Public)
[20250418140813] – Finished 3/7: (Detected profile: DomainAuthenticated)
Et voila! Aus dem „Unidentified network“ wurde ein erkanntes Domänen Netzwerk:



*) Ja, korrekt. Das Script sucht theoretisch nach mehreren Netzwerkadaptern. An dieser Stelle ein kleines ABER zum Thema „Multihomed Domain Controller„:

Schreibe einen Kommentar