Domain Controller under Windows Server 2025 currently have the problemthat an incorrect network profile is loaded. After restarting the server, the network profile "Public" is loaded, although it is a domain controller. Here is a screenshot from the GUI directly after starting the operating system
And here is a screenshot from the PowerShell:
You can see that the network adapter is in the "Public" profile, but the "Domain Autehnticated" profile should actually be loaded here. It should look like this in the GUI:
And in the shell as follows:
There was a similar problem with Windows Server 2022, the fix from "back then" (adjust dependencies of the "Network Location Awerness" service) no longer helps with Windows Server 2025.
The only thing that currently seems to help is restarting the network adapter after system startup. Here is an example:
I have already received a few emails on the subject and, as you can see, I was able to reproduce the behavior.
To be honest, I didn't notice that the wrong profile was being loaded during my initial tests, as I didn't notice any problems. I would therefore be interested to know whether you are experiencing or have experienced problems with the wrong network profile.
By default, the Windows Firewall rules for domain controllers are loaded in all profiles. Here is an example:
In my environment I have not noticed any problems, domain join, GPOs, replication, etc. all work as expected. I have therefore so far dismissed it as a cosmetic problem. Is it different for you?
The only solution that works for me is to restart the network adapter. However, this has to be done after every system start, as the public profile is reloaded after every restart. I have therefore created a scheduled task as a workaround, which restarts the network adapter at system startup. Here are the settings:
The small PowerShell script then takes over the restart:
$NetworkCategory = Get-NetConnectionProfile.NetworkCategory
if ($NetworkCategory -match "Public") {
Get-Netadapter | Restart-Netadapter
}
Feel free to write in the comments what experiences you have had.
What worked for a production server so far
Setting IPv6 to a fixed address incl. DNS which is set to ::1 (localhost), no gateway (as network is a ipv4 only network)
Setting following Regkeys
eg add „HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters“ /v DisabledComponents /t REG_DWORD /d 32 /f
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
Set-ItemProperty -Path „HKLM:\SYSTEM\CurrentControlSet\Services\NlaSvc\Parameters“ -Name „AlwaysExpectDomainController“ -Value 1 -Type DWORD
No scheduled task or whatsoever, after reboot domain profile active.
Seems that the main thing here is setting IPv6
„Get-Netadapter | Restart-NetAdapter“ worked for me fine. Since the latest January update it still works that it sets the network profile correct, but my server loses its IPv4 address (ipconfig /all).
Anyone else experiencing this issue?
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.