Server 2025 DC - verliert nach reboot Domänenfirewallprofil - nicht als DC erreichbar
Moin,
www.golem.de/news/windows-server-2025-domain-controller-sind-nach-neustart-nicht-mehr-erreichbar-2504-195369.html
... da bekommt doch jeder Admin 'n Würgereiz.
Es ist ja nicht so, dass man Windows Server nie oder nur selten als DC betreiben würde - und man das ja auch testen könnte seitens MS bevor man den Mist freigibt.
Es ist ein Drama sondergleichen.
TL;DR:
Workaround:
Aufgabenplanung (bei Start):
Es muss das NIC neugestartet werden, nach jedem Reboot bis MS einen Fix bereitstellt.
Gruß
www.golem.de/news/windows-server-2025-domain-controller-sind-nach-neustart-nicht-mehr-erreichbar-2504-195369.html
... da bekommt doch jeder Admin 'n Würgereiz.
Es ist ja nicht so, dass man Windows Server nie oder nur selten als DC betreiben würde - und man das ja auch testen könnte seitens MS bevor man den Mist freigibt.
Es ist ein Drama sondergleichen.
TL;DR:
Workaround:
Aufgabenplanung (bei Start):
Restart-NetAdapter *Gruß
Kommentieren
Teilen
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 672498
Url: https://administrator.de/forum/server-2025-dc-verliert-nach-reboot-domaenenfirewallprofil-nicht-als-dc-erreichbar-672498.html
Ausgedruckt am: 29.04.2025 um 12:04 Uhr
34 Kommentare
Neuester Kommentar
Wenn der Text mit folgenden Worten beginnt: Einige Administratoren haben offenbar...
dann gehe ich davon aus, dass es nur einige Administratoren betrifft und nicht jeden. Microsoft hat sein Betriebssystem ganz sicher und sehr intensiv getestet. Natürlich können sie es nicht mit jeder Netzwerk Adapter und jeder Revision des Netzwerk Adapters, mit jeder BIOS Version und allen BIOS Einstellungen testen.
Interessanter wäre es ein Muster zu erkennen bei welcher Hardware es vorkommt.
dann gehe ich davon aus, dass es nur einige Administratoren betrifft und nicht jeden. Microsoft hat sein Betriebssystem ganz sicher und sehr intensiv getestet. Natürlich können sie es nicht mit jeder Netzwerk Adapter und jeder Revision des Netzwerk Adapters, mit jeder BIOS Version und allen BIOS Einstellungen testen.
Interessanter wäre es ein Muster zu erkennen bei welcher Hardware es vorkommt.
Microsoft hat sein Betriebssystem ganz sicher und sehr intensiv getestet.
Made my day. :D
6
Du behauptest also Microsoft hat das Windows System ganz blind kompiliert, nicht hoch gefahren und getestet und gleich so veröffentlicht?
Made my day. :D
Made my day. :D
Die bauen doch laufend Fehler ein. Es wird immer unuebersichtlicher und die Tests werden reduziert.
Es ist eine Bananensoftware. Der Fehler reift beim Kunden..
Vor Server 2016 hatten sie es wirklich noch im Griff.
Es ist eine Bananensoftware. Der Fehler reift beim Kunden..
Vor Server 2016 hatten sie es wirklich noch im Griff.
2
Wer jetzt immer noch nicht gecheckt hat, dass diese ganzen Bugs Absicht sind, dem ist auch nicht mehr zu helfen ... 😋 🖖. Ich sag nur eins "Cloud Abzocke". Sie wollen euch damit alle in die Wolke zwingen um euch das Geld aus der Tasche zu ziehen ...
1
Solche Fehler sind schwer zu erkennen, es reicht schon eine unterschiedliche Bootgeschwindigkeit. Das war teilweise bei Windows 10 auch schon so. Mit NVME werden die Kisten halt immer schneller, schneller als die Netzwerkanbindung, und schon entstehen neue Fehlerbilder, die Microsoft in der Art noch nicht hatte / kannte. Ohne jetzt eine Zahl zu sehen bei wie viel % aller Rechner der Fehler erscheint, ist die Diskussion über die Testqualität von Microsoft leider sinnlos.
1
Ich bin auch schon fast soweit MS Absicht bei den ganzen Bugs zu unterstellen.
Die bekommen nicht einen Patchday ohne Fehler mehr hin.
Schön das die Bugs in Azure weniger sind. Merkt man leider in einer hybriden Umgebung.
Mich haben sie als Kunden verloren.
Die bekommen nicht einen Patchday ohne Fehler mehr hin.
Schön das die Bugs in Azure weniger sind. Merkt man leider in einer hybriden Umgebung.
Mich haben sie als Kunden verloren.
2
Ok, dann kauft man sich eben einen Ringordner, und noch einen passenden Locher dazu. Dann ist man wieder zurück auf Anfang.
Kreuzberger
Kreuzberger
MS Absicht bei den ganzen Bugs zu unterstellen.
Komisch, dass wir bei unserem Windows Cluster bei so vielen Updates keinen einzigen Fehler bemerkt haben. Meine Erfahrung widerspricht deiner Erfahrung.Du kannst Dir sicher sein, dass ein Imageverlust bei absichtlichen Fehlern on Premisses auch dem Image der Cloudpräsenz schadet. Daher sind Fehler niemals absichtlich. Dafür schreit die Konkurrenz bei jedem Microsoft Bug viel zu laut, während die Anzahl der eigenen Bugs deutlich höher ist.
Die Bugs sind ja natürlich nicht der einzige Punkt.
Dazu kommt das MS die Eierlegende Wollmilchsau sein will. Das hat noch nie funktioniert. Außerdem wird der Verein von vielen, die eben diese Produkte verkaufen quasi schon fast geheiligt.
Mir ist das immer mehr suspekt.
Und dann die ganzen Kosten die immer und immer mehr in die Höhe getrieben werden. Wann ist denn bitte Ende damit?
Dazu kommt das MS die Eierlegende Wollmilchsau sein will. Das hat noch nie funktioniert. Außerdem wird der Verein von vielen, die eben diese Produkte verkaufen quasi schon fast geheiligt.
Mir ist das immer mehr suspekt.
Und dann die ganzen Kosten die immer und immer mehr in die Höhe getrieben werden. Wann ist denn bitte Ende damit?
1
Zitat von @Spirit-of-Eli:
Die Bugs sind ja natürlich nicht der einzige Punkt.
Dazu kommt das MS die Eierlegende Wollmilchsau sein will. Das hat noch nie funktioniert. Außerdem wird der Verein von vielen, die eben diese Produkte verkaufen quasi schon fast geheiligt.
Mir ist das immer mehr suspekt.
Aber wenn Microsoft alte Kompatibilitätszöpfe abschneidet ist das auch wieder falsch, irgendeiner meckert immer.Die Bugs sind ja natürlich nicht der einzige Punkt.
Dazu kommt das MS die Eierlegende Wollmilchsau sein will. Das hat noch nie funktioniert. Außerdem wird der Verein von vielen, die eben diese Produkte verkaufen quasi schon fast geheiligt.
Mir ist das immer mehr suspekt.
Und dann die ganzen Kosten die immer und immer mehr in die Höhe getrieben werden. Wann ist denn bitte Ende damit?
Der Begriff Inflation ist dir bekannt?Zitat von @Th0mKa:
Es ist halt ein Bolide wie SAP.Zitat von @Spirit-of-Eli:
Die Bugs sind ja natürlich nicht der einzige Punkt.
Dazu kommt das MS die Eierlegende Wollmilchsau sein will. Das hat noch nie funktioniert. Außerdem wird der Verein von vielen, die eben diese Produkte verkaufen quasi schon fast geheiligt.
Mir ist das immer mehr suspekt.
Aber wenn Microsoft alte Kompatibilitätszöpfe abschneidet ist das auch wieder falsch, irgendeiner meckert immer.Die Bugs sind ja natürlich nicht der einzige Punkt.
Dazu kommt das MS die Eierlegende Wollmilchsau sein will. Das hat noch nie funktioniert. Außerdem wird der Verein von vielen, die eben diese Produkte verkaufen quasi schon fast geheiligt.
Mir ist das immer mehr suspekt.
Und dann die ganzen Kosten die immer und immer mehr in die Höhe getrieben werden. Wann ist denn bitte Ende damit?
Der Begriff Inflation ist dir bekannt?
Moin
... und doch... Den NLA-Fehler schleppt MS seit vielen Jahren mit sich rum. Und mit jeder neuen Edition verschlimmert sich das Problem eher noch. Von "ich stelle einen Dienst auf verzögert, über "ich konfiguriere eine Dienstabhängigkeit in der Registry" sind wir inwischen bei "ich muss ein PS-Script nach dem Systemstart laufen lassen"
Und bei den vielen Systemen, wo ich das schon habe konfigurieren müssen, kann ich mir echt nicht vorstellen, dass das Problem nicht auch bei MS auftritt. Die entwickeln (angeblich) monate- bis jahrelang die neue Version des BS und der Fehler tritt dort nicht auf? Glaube ich eher weniger...
Da warst Du aber schon lange nicht mehr im Supermarkt einkaufen
Gruß
... und doch... Den NLA-Fehler schleppt MS seit vielen Jahren mit sich rum. Und mit jeder neuen Edition verschlimmert sich das Problem eher noch. Von "ich stelle einen Dienst auf verzögert, über "ich konfiguriere eine Dienstabhängigkeit in der Registry" sind wir inwischen bei "ich muss ein PS-Script nach dem Systemstart laufen lassen"
Und bei den vielen Systemen, wo ich das schon habe konfigurieren müssen, kann ich mir echt nicht vorstellen, dass das Problem nicht auch bei MS auftritt. Die entwickeln (angeblich) monate- bis jahrelang die neue Version des BS und der Fehler tritt dort nicht auf? Glaube ich eher weniger...
Da warst Du aber schon lange nicht mehr im Supermarkt einkaufen
Gruß
1
Ihr seid einfach zu alt
Ihr kommt noch aus einer Zeit, da diente (eine) Software einem bestimmen Zweck, und genau diesen hat sie auch einwandfrei erfüllt.
Modern ist, dass Softwarehersteller dem Anwender Pakete (z.B. durch Updates) aufzwingt, die der Anwender vielleicht gar nicht möchte, eventuell (noch) nicht braucht, aber unbedingt zahlen soll, und durch weitere Maßnahmen schützen muss (denn durch einiges Features werden auch neue Lücken aufgerissen). Das füttert das System und Systemhäuser dahinter.
Und Microsoft hat viele "an der Leine", und ein beträchtlicher Teil davon lässt sich auch gerne führen.
Mahlzeit.
Ihr kommt noch aus einer Zeit, da diente (eine) Software einem bestimmen Zweck, und genau diesen hat sie auch einwandfrei erfüllt.
Modern ist, dass Softwarehersteller dem Anwender Pakete (z.B. durch Updates) aufzwingt, die der Anwender vielleicht gar nicht möchte, eventuell (noch) nicht braucht, aber unbedingt zahlen soll, und durch weitere Maßnahmen schützen muss (denn durch einiges Features werden auch neue Lücken aufgerissen). Das füttert das System und Systemhäuser dahinter.
Und Microsoft hat viele "an der Leine", und ein beträchtlicher Teil davon lässt sich auch gerne führen.
Mahlzeit.
Zitat von @mirdochegal:
Aufgabenplanung (bei Start):
Es muss das NIC neugestartet werden, nach jedem Reboot bis MS einen Fix bereitstellt.
Aufgabenplanung (bei Start):
Restart-NetAdapter *Ach das doch nix Neues.
Hatte ich beim Server 2019 Essentials schon, wäre mir aber bei einem "richtigen" DC noch nicht untergekommen, da es i.d.R. immer zwei geben sollte und einer bleibt idealerweise auch erreichbar.
Grüße
ToWa
Das war absichtlich überspitzt formuliert :D
Ich als gewinnbringender Betrieb würde natürlich ebenfalls schauen, wie ich Kunden an Land ziehe, mit welchen Vorteilen kann ich locken, wie kann ich die Kunden behalten bzw binden, obwohl die Konkurrenz nicht schläft usw...
Wer heutzutage nicht seine Ellenbogen raus fährt, hat schon so gut wie verloren.
Aber:
Wer heutzutage nicht seine Ellenbogen raus fährt, hat schon so gut wie verloren.
Aber:
"ich muss ein PS-Script nach dem Systemstart laufen lassen"
Was musst du da machen? Ich frage weil meine Windows Welt kommt komplett ohne Scripting zurecht...
... s.o. oder eingeschränkt:
...um die Netzwerkadpter neu zu starten
$NetworkCategory = (Get-NetConnectionProfile | Select-Object -ExpandProperty NetworkCategory)
if ($NetworkCategory -like “P*”) {
Get-NetAdapter | Restart-NetAdapter
}
Das Problem mit dem falschen FW Profil haben wir auch andauernd.
Welchen Netzwerkadapter verwendet ihr?
Wir haben hier größtenteils Mellanox ConnectX-2 im Einsatz und so einen Fehler noch nie gesehen.
Wir haben hier größtenteils Mellanox ConnectX-2 im Einsatz und so einen Fehler noch nie gesehen.
VMware und daher vmxNet Karten.
Im Falle von VMware und VMs geht es jedoch um die Netzwerktreiber, die die Windows VM (in dem Fall oben Windows Server 2025) erkennt, oder?
Vermutlich habe ich deswegen keine Probleme, weil ich den Hyper-V verwende, die VM erkennt dann einen "Microsoft Hyper-V Network Adapter" und dieser scheint das Problem nicht zu haben.
Vermutlich habe ich deswegen keine Probleme, weil ich den Hyper-V verwende, die VM erkennt dann einen "Microsoft Hyper-V Network Adapter" und dieser scheint das Problem nicht zu haben.
Die Lanze muss ich für Microsoft brechen, mit Hyper-V 2016 bisher überwiegend problemfrei über die Runden gekommen.
Vor Hyper-V 2025 habe Angst, schließlich hatte Microsoft 9 Jahre Zeit es zu vermurksen.
Proxmox + Proxmox Backup Server ist sicher die beste Lösung, finden auch viele (ehemalige) VMware Kunden.
Vor Hyper-V 2025 habe Angst, schließlich hatte Microsoft 9 Jahre Zeit es zu vermurksen.
Proxmox + Proxmox Backup Server ist sicher die beste Lösung, finden auch viele (ehemalige) VMware Kunden.
1NordicMike 16.04.2025 um 14:40:21 Uhr
Im Falle von VMware und VMs geht es jedoch um die Netzwerktreiber, die die Windows VM (in dem Fall oben Windows Server 2025) erkennt, oder?
Im Falle von VMware und VMs geht es jedoch um die Netzwerktreiber, die die Windows VM (in dem Fall oben Windows Server 2025) erkennt, oder?
Nein, das Problem ist tatsächlich das das Firewall Profil dann auf öffentlich steht.
Das lässt sich, wie schon erwähnt wurde, durch de/reaktivierung der Netzwerk Karte beheben.
Eine Zeit lang half auch den NLA Dienst durch zu starten. Der Workaround funktioniert nicht mehr.
Ich kann leider nicht sagen ob das auch mit anderen Schnittstellen passiert. Wir haben so ziemlich nur noch VSAN als Unterbau
Zitat von @NordicMike:
Vermutlich habe ich deswegen keine Probleme, weil ich den Hyper-V verwende, die VM erkennt dann einen "Microsoft Hyper-V Network Adapter" und dieser scheint das Problem nicht zu haben.
Vermutlich habe ich deswegen keine Probleme, weil ich den Hyper-V verwende, die VM erkennt dann einen "Microsoft Hyper-V Network Adapter" und dieser scheint das Problem nicht zu haben.
Doch... Wir haben meistens Hyper-V im einsatz bei den Kunden und da haben wir andauernd das Problem. Eher die Regel als die Ausnahme...
In der Praxis lässt sich das Problem ja auch bislang auf die eine oder andere Weise beherrschen. Man fragt sich nur, weshalb MS das nicht selbst mal von Haus aus geregelt bekommt.
2Man fragt sich nur, weshalb MS das nicht selbst mal von Haus aus geregelt bekommt.
Vermutlich, weil sie den Fehler genau so wenig sehen, wie bei mir.Hast Du den Microsoft Support damit konfrontiert? Die sollen mal was tun für ihr Geld
Zitat von @Hubert.N:
Doch... Wir haben meistens Hyper-V im einsatz bei den Kunden und da haben wir andauernd das Problem. Eher die Regel als die Ausnahme...
In der Praxis lässt sich das Problem ja auch bislang auf die eine oder andere Weise beherrschen. Man fragt sich nur, weshalb MS das nicht selbst mal von Haus aus geregelt bekommt.
Doch... Wir haben meistens Hyper-V im einsatz bei den Kunden und da haben wir andauernd das Problem. Eher die Regel als die Ausnahme...
In der Praxis lässt sich das Problem ja auch bislang auf die eine oder andere Weise beherrschen. Man fragt sich nur, weshalb MS das nicht selbst mal von Haus aus geregelt bekommt.
Vermutlich weils in der Regel nicht an Microsoft liegt, sondern an Netzwerk oder DNS Konfiguration.
@Th0mKa
Kreuzberger
Vermutlich weils in der Regel nicht an Microsoft liegt, sondern an Netzwerk oder DNS Konfiguration.
Also . . . auf eine genauere Erklärung wäre ich jetzt ja schon gespannt, wie sich eine DNS- oder Netzwerkkonfiguration auf einen Server 2025 auswirken soll, wenn diese reinen Neustart macht.Kreuzberger
Jetzt bin ich aber überrascht.
Das ist ja tatsächlich bekannt und ich sehe den Fehler seit Jahren bei kleineren Betrieben mit nur einem DC und wundere mich über die Lösungsansätze mit dem Restart der Netzwerkkarte.
Setzt den Dienst doch einfach in Abhängigkeit zu denen, die davor gestartet werden müssen.
sc config nlasvc depend= NSI/RpcSs/TcpIp/Dhcp/Eventlog/DNS/NTDS
Das ist ja tatsächlich bekannt und ich sehe den Fehler seit Jahren bei kleineren Betrieben mit nur einem DC und wundere mich über die Lösungsansätze mit dem Restart der Netzwerkkarte.
Setzt den Dienst doch einfach in Abhängigkeit zu denen, die davor gestartet werden müssen.
sc config nlasvc depend= NSI/RpcSs/TcpIp/Dhcp/Eventlog/DNS/NTDS
1Zitat von @Knorkator:
Setzt den Dienst doch einfach in Abhängigkeit zu denen, die davor gestartet werden müssen.
sc config nlasvc depend= NSI/RpcSs/TcpIp/Dhcp/Eventlog/DNS/NTDS
... was seit Server 2025 so eben nicht mehr geht.Setzt den Dienst doch einfach in Abhängigkeit zu denen, die davor gestartet werden müssen.
sc config nlasvc depend= NSI/RpcSs/TcpIp/Dhcp/Eventlog/DNS/NTDS
Vielleicht hat das auch was mit einem einzelnern DC zu tun. Das ergibt ja auch irgendwie Sinn. Ich werde aber z.B. einer Arztpraxis kaum zwei DCs verkaufen können. (Am besten sogar noch zwei Hardwareserver, damit es wirklich funktioniert?!)
Zitat von @Th0mKa:
Vermutlich weils in der Regel nicht an Microsoft liegt, sondern an Netzwerk oder DNS Konfiguration.
Und was soll man da verkehrt machen?? DC unter Hyper-V mit statischer IP-Adresse und sich selbst als DNS. Aso absoluter Standard. Zumindest bei einer Domäne mit einem DC wüsste ich nicht, was man da anders einstellen soll.Vermutlich weils in der Regel nicht an Microsoft liegt, sondern an Netzwerk oder DNS Konfiguration.
Zitat von @Hubert.N:
Vielleicht hat das auch was mit einem einzelnern DC zu tun. Das ergibt ja auch irgendwie Sinn. Ich werde aber z.B. einer Arztpraxis kaum zwei DCs verkaufen können. (Am besten sogar noch zwei Hardwareserver, damit es wirklich funktioniert?!)
Ah ok. Das wusste ich nicht.Zitat von @Knorkator:
Setzt den Dienst doch einfach in Abhängigkeit zu denen, die davor gestartet werden müssen.
sc config nlasvc depend= NSI/RpcSs/TcpIp/Dhcp/Eventlog/DNS/NTDS
... was seit Server 2025 so eben nicht mehr geht.Setzt den Dienst doch einfach in Abhängigkeit zu denen, die davor gestartet werden müssen.
sc config nlasvc depend= NSI/RpcSs/TcpIp/Dhcp/Eventlog/DNS/NTDS
Vielleicht hat das auch was mit einem einzelnern DC zu tun. Das ergibt ja auch irgendwie Sinn. Ich werde aber z.B. einer Arztpraxis kaum zwei DCs verkaufen können. (Am besten sogar noch zwei Hardwareserver, damit es wirklich funktioniert?!)
Die kleineren Domänen, die ich zuletzt gesehen habe, hatten noch keinen 2025er DC.
Hallo Hubert.N, kann ich so bestätigen, das Problem besteht seit Jahren, speziell bei DCs nach dem Neustart.
Österliche Grüße
(T)Rainer
Österliche Grüße
(T)Rainer
Vermutlich habe ich deswegen keine Probleme, weil ich den Hyper-V verwende, die VM erkennt dann einen "Microsoft Hyper-V Network Adapter" und dieser scheint das Problem nicht zu haben.
Das habe ich auch oft bei Windows Server 2016-2019 DC in kleinen Hyper-V Umgebungen.Oft werden diese Server genau einmal pro Monat neugestartet (Patchday) und dann haben die DC oft das öffentliche Netzwerkprofil eingestellt.
NLA neustarten hat bisher immer geholfen, ist aber nervig.
Das Problem gibt es aber schon seit unzähligen Jahren (glaube schon beim SBS 2011 war das so).
Mein Fix auf den DCs zu dem Thema sieht immer so aus
Klappt zuverlässig auch auf Server 2025.
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters]
"NegativeCachePeriod"=dword:00000000
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters]
"MaxNegativeCacheTtl "=dword:00000000
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NlaSvc\Parameters]
"AlwaysExpectDomainController"=dword:00000001 
