Windows Server 2025: Falsches Netzwerkprofil auf Domain Controller

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

Windows Server 2025: Falsches Netzwerkprofil auf Domain Controller

Und hier einmal ein Screenshot aus der PowerShell:

Windows Server 2025: Falsches Netzwerkprofil auf Domain Controller

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:

Windows Server 2025: Falsches Netzwerkprofil auf Domain Controller

Und in der Shell wie folgt:

Get-NetConnectionProfile

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:

Get-NetConnectionProfile

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:

Windows Firewall

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:

Task Scheduler
Task Scheduler
Task Scheduler

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.

18 Gedanken zu „Windows Server 2025: Falsches Netzwerkprofil auf Domain Controller“

  1. 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?!

    Antworten
  2. 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.

    Antworten
  3. 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.

    Antworten
  4. 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.

    Antworten
  5. 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.

    Antworten
  6. 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.

    Antworten
  7. 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.

    Antworten
  8. New-ItemProperty -Path „HKLM:\SYSTEM\CurrentControlSet\Services\NlaSvc\Parameters“ -Name „AlwaysExpectDomainController“ -Value ”1” -PropertyType „DWORD“
    Restart-Computer -Force

    Antworten
  9. 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.

    Antworten

Schreibe einen Kommentar