Domain Controller unter Windows Server 2025 haben aktuell das Problem, dass ein falsches Netzwerkprofil geladen wird. Nach einem Neustart des Servers wird das Netzwerkprofil „Public“ geladen, obwohl es sich um einen Domain Controller handelt. Hier mal ein Screenshot direkt nach dem Start des Betriebssystems aus der GUI
Und hier einmal ein Screenshot aus der PowerShell:
Zu sehen ist, dass sich der Netzwerkadapter im Profil „Public“ befindet, eigentlich müsste hier aber das Profil „Domain Autehnticated“ geladen werden. In der GUI müsste es so aussehen:
Und in der Shell wie folgt:
Bei Windows Server 2022 gab es ein ähnliches Problem, der Fix von „damals“ (Abhängigkeiten des Dienstes „Network Location Awerness“ anpassen) hilft bei Windows Server 2025 nicht mehr.
Das einzige was aktuell zu helfen scheint, ist der Neustart des Netzwerkadapters nach dem Systemstart. Hier mal ein Beispiel:
Ich hab jetzt schon ein paar Mails zu dem Thema erhalten und konnte das Verhalten, wie man sehen kann, nachstellen.
Mir ist es aber ehrlich gesagt bei meinen ersten Tests nicht aufgefallen, dass hier das falsche Profil geladen wird, denn ich konnte keine Probleme feststellen. Daher würde mich mal interessieren, ob es bei euch mit dem falschen Netzwerkprofil zu Problemen kommt oder gekommen ist.
In der Standardeinstellung werden die Windows Firewall Regeln für Domain Controller in allen Profilen geladen. Hier mal ein Beispiel:
In meiner Umgebung konnte ich daher keine Probleme feststellen, Domain Join, GPOs, Replikation, usw funktioniert alles wie erwartet. Ich hab es daher für mich bisher als kosmetisches Problem abgetan. Ist das bei euch anders?
Die einzige Lösung, welche bei mir funktioniert, ist der Neustart des Netzwerkadapters. Dies muss aber nach jedem Systemstart durchgeführt werden, da nach jedem Neustart wieder das Public Profil geladen wird. Ich habe daher als Workaround einen geplanten Task angelegt, welcher bei Systemstart den Netzwerkadapter neu startet. Hier mal die Einstellungen:
Das kleine PowerShell Script übernimmt dann den Neustart:
$NetworkCategory = Get-NetConnectionProfile.NetworkCategory
if ($NetworkCategory -match "Public") {
Get-Netadapter | Restart-Netadapter
}
Schreibt gerne mal in die Kommentare welche Erfahrungen ihr gemacht habt.
Hi,
bei dem Versuch „Get-NetConnectionProfile.NetworkCategory“ aus dem obigen PowerShell Script auf dem 2025-Server zu verwenden, bekomme ich folgende Fehlermeldung:
Get-NetConnectionProfile.NetworkCategory : The term ‚Get-NetConnectionProfile.NetworkCategory‘ is not recognized as the name
of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify
that the path is correct and try again.
At line:1 char:1
+ Get-NetConnectionProfile.NetworkCategory
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : ObjectNotFound: (Get-NetConnectionProfile.NetworkCategory:String) [], CommandNotFoundException
+ FullyQualifiedErrorId : CommandNotFoundException
„Get-NetConnectionProfile“ selbst funktioniert natürlich.
Habe ich da was übersehen?
Habe es selbst herausgefunden – die Klammern fehlen :)
(Get-NetConnectionProfile).NetworkCategory
Diese Problematik mit dem LAN-Adapter und Domain Controller ist aus meiner Sicht so alte wie der Domainkontroller selbst.
Wirklich auffällig war dies schon bei Windows 2003 und Umgebungen (natürlich) mit nur einem Domainkontroller. Vermutlich startet einfach die Netzwerkerkennung schon bevor die AD-Dienste laufen und da sieht die NIC halt nur „irgendein“ Netzwerk und stellt auf Public oder Privat (was man halt als „Standard“ in den Lokalen Sicherheitseinstellungen voreinstellen kann. Domaine geht dort ja nicht.
Bei mind. zwei DCs im LAN trat und tritt der Effekt nicht so häufig auf. Trotzdem hin und wird. Wir haben bisher auch immer nur die Aktion mit dem Deaktivieren und Aktivieren gefahren (so wie die AD Dienste voll durchgestartet sind).
Aus meiner Sicht sollte MS hier mal generell das Prozedere überarbeiten. Am besten bei einem DC immer das Profil auf „Domain“ matchen. Was anderes macht doch eh keinen Sinn?!
Es hilft definitiv im NIC „Internetprotokoll Version 6“ sprich IPv6 kurz zu deaktivieren und danach wieder zu aktivieren.
Eventuell könnte es daher auch helfen, IPv4 gegenüber IPv6 per Richtlinie zu bevorzugen. (Kann es momentan nur nicht testen).
reg add „HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters“ /v DisabledComponents /t REG_DWORD /d 32 /f
Der Wert 32 (dezimal) bewirkt, dass IPv4 gegenüber IPv6 bevorzugt wird.
hier der aktuelle angepasste Code:
$NetworkCategory = (Get-NetConnectionProfile | Select-Object -ExpandProperty NetworkCategory)
if ($NetworkCategory -eq „Public“) {
Get-NetAdapter | Restart-NetAdapter
}
NetFix.ps1 erstellen und einfügen.
Bei mir funktionierte dein Script mit der Punknotation so nicht.
Erst nach Anpassung auf „(Get-NetConnectionProfile).NetworkCategory“ ging es.
Hallo, ich habe einen Test DC mit Server 2025 installiert.
Ich kann unter HKLM:\SYSTEM\CurrentControlSet\Services\NlaSvc\Parameters keinen neuen Eintrag hinzufügen.
Es erscheint die Fehlermeldung „Wert kann nicht erstellt werden. In die Registry kann nicht geschrieben werden“.
Ich bin als Domänen Admin angemeldet und habe dort nur Leserechte.
Ich frage mich, wie die anderen Leute, die Werte einfügen konnten.
Regedit auch explizit als Administrator gestartet?
Schau Dir den Pfad genau an. Gibt einen ähnlichen unter Services, da hat man nur Leserechte.
Meiner Meinung nach existiert dieses Problem schon seit Windows Server 2016. Fällt meistens nur auf, wenn nur ein einzelner DC existiert und der auch noch 127.0.0.1 als einzigen DNS verwendet.
Also die Problematik verfolgt uns zumindest schon seit 2012 R2.
Es war aber auch nicht immer nur auf DCs beschränkt. So sieht der Standardcheck nach Serverstarts bei uns immer auch die Kontrolle des Firewallprofiles vor.
Aber die DC Problematik ist uralt. Der NLA Neustart geht nicht mehr.
Die zu den Dienstabhängigkeiten genannten Empfehlungen können recht umfangreich sein, führen bei uns aber erfahrungsgemäß auch nicht immer zum Erfolg.
Wir setzen auf DCs, die wiederholt das Problem haben, auch auf die von Mariette genannten RegKeys. Das ist das einzige, was dauerhaft zum Erfolg führt.
Da kann man in dem Zusammenhang aber noch mehr machen.
Siehe: https://learn.microsoft.com/en-us/answers/questions/400385/network-location-awareness-not-detecting-domain-ne, den Post von Sunni Qi.
Wer es im Übrigen weiterhin manuell beheben will und aus einem Grund den Adapter nicht neustarten möchte/kann; unserer Erfahrung nach reicht es kurz TCPiP v6 auf der ETH zu de/-aktivieren. Das löst NLA ebenfalls aus und führt dann zum korrekten Profil.
Habe den Server direkt nach seinem erscheinen als Domaincontroller in der Testumgebung installiert und bin auch in dieses Problem gelaufen. NLA Neustart hilft hier nicht mehr. Ich hatte dann wirklich keine Lust, dieses Problem weiter zu untersuchen, man fragt sich wirklich, wie man diesen Server in diesem Zustand freigebenkonnte.
Gedanklich habe einen möglichen Produktiveinsatz auf mindestens 2026 verschoben.
bei mir hilft das immer
sc config nlasvc depend=NSI/RpcSs/TcpIp/Dhcp/Eventlog/DNS/NTDS
Genauso mache ich das auch immer sowie Dienst „NLA (Network Location Awareness“ auf „Automatisch (Verzögerter Start)“
New-ItemProperty -Path „HKLM:\SYSTEM\CurrentControlSet\Services\NlaSvc\Parameters“ -Name „AlwaysExpectDomainController“ -Value ”1” -PropertyType „DWORD“
Restart-Computer -Force
Ja, ist auch die IMHO einzig dauerhafte funktionierende Lösung, schon seit mind. Server 2019.
Genau, das ist die beste Lösung dieses Problem. See https://www.google.com/search?q=AlwaysExpectDomainController+server-essentials.com
Reicht der Eintrag?
Ich lese meist das auch noch diese zwei Einträge nötig sind:
Set-ItemProperty -Path „HKLM:\SYSTEM\CurrentControlSet\Services\NetLogon\Parameters“ -Name „NegativeCachePeriod“ -Value 0 -Type DWORD
Set-ItemProperty -Path „HKLM:\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters“ -Name „MaxNegativeCacheTtl“ -Value 0 -Type DWORD
Nope,
Lt. einigen engl. Blogs funktionieren diese Tricks via Registry oder Abhängigkeiten vom NLA alle nicht in Windows Server 2025. Hier scheint MS intern etwas geändert zu haben.
Kann ich leider in meiner Testumgebung bestätigen.
Es soll wohl eine Workaround geben damit der Registry-Eintrag wieder geht und zwar muss wohl einen IPv6 Adresse zugewiesen sein.
Kann ich leider aktuell nicht selber Testen.
Das hatten wir auch schon mit Windows Server 2019 und Windows Server 2022 als Domänencontroller festgestellt. Dann half in der Regel ein Neustart des Dienstes NLA auf dem betroffenen DC.