[English]Kleiner Nachtrag zu einem Thema, was hier einige Tage liegen geblieben ist. Microsoft hat bereits zum 11. April 2025 ein neues Problem bei Windows Server 2025 in Verbindung mit Active Directory Domain Controllern (DC) bestätigt. Nach einem Neustart des Server-Betriebssystems ist der DC nicht mehr erreichbar. Hintergrund sind wohl falsch zugeordnete Profile der Windows Firewall nach jedem Neustart.
Microsoft hat dazu zum 11. April 2025 im Release Health-Statusbereich von Windows Server 2025 unter den Known Issues den Supportbeitrag Domain controllers manage network traffic incorrectly after restarting eingestellt.
Probleme mit DCs nach Neustart
Dort heißt es, dass Windows Server 2025-Domänencontroller (z. B. Server, die die Active Directory-Domänencontrollerrolle hosten) den Netzwerkverkehr nach einem Neustart möglicherweise nicht korrekt verwalten. Dies hat zur Folge, dass Windows Server 2025-Domänencontroller möglicherweise nicht im Domänennetzwerk erreichbar sind. Oder die DCs sind fälschlicherweise über Ports und Protokolle erreichbar, die andernfalls durch das Domänen-Firewall-Profil verhindert werden sollten.
Ursache: Falsches Firewall-Profil für die DC
Microsoft schreibt, dass dieses Problem daraus resultiert, dass Domänencontroller (DCs) bei einem Neustart keine Domänen-Firewall-Profil verwenden. Stattdessen wird das Standard-Firewall-Profil verwendet. Die unmittelbar Folge ist, dass Anwendungen oder Dienste, die auf dem Domänencontroller oder auf Remotegeräten ausgeführt werden, fehlschlagen oder im Domänennetzwerk unerreichbar bleiben können.
Die Microsoft-Entwickler arbeiten an einer Lösung und wollen diese irgendwann durch ein Update korrigieren. Betroffene Administratoren müssen bei jedem Neustart des Windows Server 2025, der als DC arbeitet, den nachfolgenden Workaround ausführen.
Workaround: Netzwerkadapter neu starten
Microsoft hat einen temporären Workaround für Betroffene vorgeschlagen. Administratoren können das erwartete Verhalten durch einen Neustart der Netzwerkadapter wiederherstellen. Dies kann auf verschiedene Weise manuell, z. B. mit dem folgenden Befehl über PowerShell durchgeführt werden:
Restart-NetAdapter *
Das Problem ist, dass der Fehler bei jedem Neustart des als Domänencontroller fungierenden Windows Server 2025 erneut auftritt. Microsoft schlägt vor, den Workaround zum Neustart der Netzwerkadapter als geplante Aufgabe zu erstellen, die den Netzwerkadapter jedes Mal neu startet, wenn der Domänencontroller neu gestartet wird.
Schlimmer als russisches Roulette die Patches bei Winzigweich. Ich darf mich jetzt wieder vermehrt um Windows kümmern, da noch ein Kollege gekündigt hat. Freue mich gar nicht drauf mich wieder um die Patches für Windows zu kümmern.
naja, bei DCs auf Win Server 2016 und 2019 gehört das schon lange zum Standard, dass der DC (wenn kein zweiter im Netzwerk ist) nach einem Neustart nicht erreichbar ist.
meistens hilft (jedenfalls im Server 2016/2019):
– sc config nlasvc depend=DNS
– DNS-Suffix im Adapter hinterlegen
Wird wohl im 2025 jetzt gleich sein.
Das ist keine Lösung, sondern Pfusch. Einen Workaround hat Günter bereits in seinem Beitrag gepostet (seitens Microsoft).
Der sogenannte „Server-Standard seit 2016“ ist schlichtweg ein mitgeschleppter Bug, der endlich gefixt gehört.
Man könnte auch einen Mini-DC aufsetzen, der ständig im Hintergrund läuft… hauptsache das Domänen-Netzwerk fällt nicht völlig aus.
@Anonym, du hast leider keine Ahnung, warum es passiert und warum es keine Lösung gibt.
das Firewall Profil Domäne kann nur validiert werden, wenn ein DC das Computerkonto authentifizieren kann.
das Netzwerk startet, das AD auch, der IP Stack ist aufgrund der kleineren Load schneller, jetzt würde die NLA gerne wissen wie das mit der Firewall ist und findet keinen DC der das Konto authentifiziert.
simples Keine Arme keine Kekse Problem.
die Alternative ist identische FW Regeln im Public Network Profile.
oder restart der NIC, nachdem Start des AD.
du brauchst keinen „MiniDC“ was soll das sein? das ist ein Server mit AD Datenbank, kleiner geht’s nicht.
Mann, Mann, Mann …
Auch beim Server 2022 ist das Problem eine race condition zwischen den Diensten Network Location Awareness und DNS Server. Meist wird NLA vor DNS Server gestartet und kann dann die Network Location nicht richtig bestimmen. Der DNS-Suffix hat für mich das Problem noch nie gelöst. Nur das Hinzufügen der Abhängigkeit hat das Problem bei mir immer gelöst. Der Workaround, NLA nach einiger Zeit neuzustarten (den ich aus anderen Gründen schon nicht mag), funktioniert beim Server 2022 nicht mehr, da NLA von Diensten abhängt, die sich nicht beenden lassen.
Da gibt es aber eine Möglichkeit mit „taskkill“ und der PID vom NLA , die man im Taskmanager herausfinden kann. Dann werden die Abhängigkeiten nicht geprüft und alles läuft wieder. [Meine ich; ohne Gewähr, weil bisher nur 1x machen müssen; das Gedächtnis ist nicht so gut]
Mache ich auch schon seit Jahren so – wenn die Abhängigkeit beim Start gesetzt ist läuft es ohne Probleme.
NLA Neustart war der 1. Versuch das Problem zu lösen damals.
Das Problem besteht bei Server 2025 seit Beginn. Die „alten“ Lösungen funktionieren hier aber alle nicht, da NLA unter Windows Server 2025 nicht mehr genutzt wird.
Der Neustart des Adapters ist die einzige Möglichkeit, unabhängig ob es einen zweiten DC gibt oder nicht.
Bei Windows Server 2012 R2 bis 2022 ist das mit der Firewall nur, wenn es der erste DC im Netzwerk ist. Ist bereits einer noch normal vorhanden (reicht sogar Site-2-Site VPN), dann wird die richtige Richtlinie bei der Firewall für den neu gestarteten DC genommen und es läuft.
So wie ich das nun verstehe, ist es bei 2025 nun immer der Fall, egal ob ein anderer bereits gestartet ist. Also doch noch Mal schlimmer :-/
Falsches Firewallprofil ist Standard bei DC´s. Server 2016, 2019 usw.
Ich kann an dieser Stelle nur auf mein PS hinweisen, das täglich (mindestens vor dem Einspielen) von Updates einen Zwilling von DC und weiteren kritischen Systemen in einem isolierten vLAN in einer HyperV (Cluster-) Umgebung hochzieht.
Automatisiert ohne Mehrarbeit für den Admin. Dort können kritische Updates in Ruhe aufgespielt und getestet werden, bevor man diese auf produktive Systeme loslässt.
https://blog.jakobs.systems/micro/20241016-hyperv-backups-faq/
Und gleichzeitig hat man so auch Gewissheit, dass der Restore aus dem Backup funktioniert ;-)
Hi!
2 Maschinen mit identer SID im gleichem Netz, das ist nicht nur nicht supported, sondern ein Rezept für viele Probleme.
Die richtige Lösung nach Microsoft ist ganz klar:
– mehr als einen DC betreiben
– DC sollte keine VM sein (das ist aber mehr wegen der Sicherheit ein Problem)
– keine zweite Rolle auf einem DC betreiben, idealerweise sollte der DC nur DC machen.
lg
2 DCs sind die richtige Lösung, wobei einer der DCs auch eine VM sein darf, der andere aber physisch bleiben sollte. So ist durch den physischen DC sichergestellt das beim Hochfahren der VM Hosts, die ggf. auch Mitglieder der Domain sind, die Domain auch verfügbar ist.
Weil ein VM Host der selber den DC als VM hostet würde logischerweise keinen DC finden wenn dieser VM DC der einzige DC im Netzwerk ist.
Bei Windows Server 2025 helfen für dieses Problem leider keine 2 oder mehr DCs. Wer nicht zwingend den Netzwerkadapter neu starten möchte, kann auch nur das NetAdapterBinding für „ms_tcpip6“ deaktivieren und wieder aktivieren.
Der Hyper-V Host hat ohne erreichbare Domäne erstmal gar keine Probleme? Es gibt keinen Hyper-V Dienst, der von der Domäne abhängig ist. Die DC VM(s) werden alle einen Autostart haben und sollte es da klemmen, wird es einen lokalen Admin und/oder (hoffentlich) einen Break Glass Account geben. Mit hoher Wahrscheinlichkeit wird man sich (leider) auch „per“ Cached Credentials und dem Domain User anmelden können.
Sicherheitstechnisch spricht das administrative Tiering dagegen. DCs – die Tier 0 sind – sollten nicht auf Hyper-V- bzw. Virtualisierungs-Hosts betrieben werden, die Tier 1 oder Tier 2 Systeme bereitstellen. Entweder ich habe dann eine dedizierte Tier 0 Hyper-V- / Virtualisierungs-Umgebung oder ich betreibe meine DCs tatsächlich direkt auf eigener Hardware.
(Im KMU – und desto näher wir dem K kommen – wird man hier sicherlich Kompromisse machen müssen. Es sollte aber jedem bewusst sein warum (es eigentlich Sche*ße ist).)
Das Problem den VMs ist ein ganz anderes, aber sehr starkes. Eine VM kann via Host relativ leicht gehackt werden. Jeder Domain Controller der gehackt wurde, kann die gesamte Organisation übernehmen.
Ein DC auf Hardware kann via Bitlocker geschützt werden, was es ohne Kennwort von einem Domain Admin deutlich schwerer macht.
Und natürlich sollte man den Hypervisor Host, egal ob Hyper-V, VMware, Proxmox, was auch immer .. nicht an die Domain binden. Bzw. wenn dann an eine eigene Management-Domain binden.
lies die Paper. VMs werden verschlüsselt.
nur weil das k(aum)einer macht, heißt es nicht, das das nur für Blech gilt
Das Problem ist hier der Host nicht die VM, es ist egal ob die VM verschlüsselt ist.
DCs vertrauen einander uneingeschränkt. Einen DC von vielen unter Kontrolle zu haben reicht.
Danke, Du hast somit offenbart, dass Deine (HyperV) HVs offensichtlich im gleichen AD stecken wie Deine Gäste. Keine weiteren Fragen…
VM, gemeint Festplatte/Disk.
eine verschlüsselte Disk ist auch als virtuelle Platte eine verschlüsselte Disk und schützt den Zugriff auf das System.
egal ob Virtuell oder Physikalisch. das ist der Sinn der Festplatten Verschlüsselung vor AUCH IN DER virtuellen Umgebung.
ein Umhängen der Disk in „mein“ System wäre zu einfach.
ich wiederhole mich: deswegen werden Festplatten verschlüsselt auch in der virtuellen Umgebung.
Ihr spinnt doch völlig.
2 DCs, davon einer in Hardware?
Dann muss ich mindestens eine Serverhardware für > 1.000 € mehr kaufen und mindestens eine 2. Windows Server Standard für nochmal 1.000 € mehr.
Das sind Mehrkosten von 2.000 € alleine für Hard- und Software, und da ist der Einrichtungsaufwand noch nicht mit abgegolten.
Und das nur, weil Microsoft ihre Produkte nicht in den Griff bekommt?
Wer nicht so blöd ist mit HyperV zu virtualisieren (warum sollte das Produkt auch besser sein als der restliche Kram von Microsoft), der nimmt Proxmox und kann die Startreihenfolge der Maschinen selbst festlegen.
Und wenn was nicht läuft, wird ein Snapshot vom Vortag zurückgespielt. Lasst mich raten: Darf man auch nicht.
Wenn das bei dir / deinen Kunden so passt, freu dich des Lebens und mach. Evtl. kannst du dir aber auch vorstellen, dass es Kunden mit ganz anderen Anforderungen ans „Active Directory“ / an die IT gibt, wo dein Konzept ganz und gar nicht passt.
WICHTIG: Alle anderen spinnen und sind blöd.
P.S.: Einen oder zwei physikalische DCs zu haben, kann im Fall der Fälle schnell mehr Geld einsparen, als es (inkl. Einrichtungsaufwand (der durch bspw. PowerShell/Automatisierung nahezu 0 ist)) kostet.
Es kommt auf das Konzept an. Bei kleineren Unternehmen macht es Sinn einen physischen DC zu haben. Muss man aber nicht. Man kann auch alle DCs virtuell betreiben.
Wie gesagt es kommt auf das Konzept an.
In unserem Konzern mit 170 Standorten existiert an jeden Standort 1 DC. Zudem sind im RZ mehrere DCs. Und ALLE DCs sind virtualisiert!
Wir sind seit längerer Zeit dabei die Standort VMware Hosts und deren VMs aufzulösen. Und ALLES zentral ins RZ zu verlagern. Das RZ ist doppelt ausgelegt.
Dafür dürfte ein(++) alter (Mini-)PC (hinter der USV!) ggf. mit einer gebrauchten Lizenz langen auf dem ausschließlich ein zusätzlicher DC als Backup läuft.
Weiß nicht, wie es momentan ist, aber vor paar Jahren war Hyper-V von der Performance her führend!
Und Proxmox bringe ich, nach mehreren privaten Tests vor einigen Jahren, ausschließlich mit Instabilität/Inkompatibilität und unfreundlichen Mitarbeitern im Hilfeforum in Verbindung…
Da habe ich genau gegenteilige Erfahrungen gemacht.
Proxmox super stabil und schnell.
HyperV nicht zu Gebrauchen. Für die private VM vielleicht, aber nicht als Dauerläufer im Produktivbetrieb.
Das Proxmox Forum ist doch traumhaft. Fähige Menschen mit freundlichen Antworten.
Ich hab hingegen noch nie irgend etwas brauchbares in Microsoft Foren gefunden.
Nur fehlende Lösungen, Falschaussagen und Vertröstungen.
Hyper-V würde ich produktiv tatsächlich auch nicht (mehr) verwenden, insbesondere weil da, trotz gegenteiliger Versprechen, hin und wieder, selbst bei monatlichen Standard-Popel-Updates, Neustarts des Hosts fällig sind; oder zumindest früher waren; da gehe ich mit. Die Performance Infos stammen auch tatsächlich nicht von mir direkt, sondern von externen Tests aus dem Internet. Hyper-V Core(!) war da ein paar Prozent vor allen anderen Lösungen, weil anscheinend extrem hardwarenah umgesetzt und, Microsoft typisch, auf unterstützer Hardware super kompatibel – allerdings auf meinem kleinen Testsytem tatsächlich absolut unbrauchbar!
Proxmox hatte ich auch nur auf dem ausprobiert, welches ehrlich gesagt nicht wirklich für solche Aufgaben bestimmt ist, aber zumindest grundsätzlich kompatibel dazu sein sollte. Da hatte ich ständig Abstürze/Freezes von VMs, was vermutlich auf die Fehl- oder Nichterkennung von CPU-Fähigkeiten zurückzuführen war. Mehrere Tage alles Mögliche ohne Erfolg getestet. Ein (Debian-)Paket als einzig verbliebene Lösung für die korrekte CPU Initialisierung konnte ich aber auch nicht testen – dessen Installation wollte 6-700MB freimachen (== Proxmox deinstallieren :D).
Fähige Menschen im Proxmox Forum? Ja, mag sein. Ich bezog mich damit allerdings mehr auf die Proxmox Mitarbeiter, die ich als extrem anstrengend und nicht sehr hilfsbereit wahrgenommen habe. Häufiger habe ich dort Aussagen gelesen wie „Na lies halt die Dokumentation“ wo ich mir dann mehrfach dachte: „Ja, toll – habe ich gerade! Das was da steht funktioniert aber nicht…“ weil veraltet oder ungenau.
Und über die Microsoft Foren brauchen wir nicht zu reden… Wenn ich Microsoft Kram suche und dorthin verlinkt wird taucht in der Regel ein „Hallo, ich bin xyz (kein Microsoft Mitarbeiter) und Microsoft Supertoll ausgezeichnet“. Fast immer will ich dann laut schreien: „Wenn du nichtmal das Drecksproblem verstehst, warum hältst du dich dann, verdammt noch mal, nicht einfach raus! Verpiss dich!“ xD
Edit: Hyper-V hat halt noch den Vorteil, dass es kostenlos ist
Du hast mich allerdings auf die Idee gebracht Proxmox nochmal anzuschauen. Danke! :)
Die Motivation den DC mehrfach zu betreiben steigt mit jedem Rechner/User und Dienst der davon abhängt.
Man kann übrigens natürlich, einen DC auch mit Linux betreiben, ganz ohne Lizenzkosten.
Muß er auch nicht, denn VM Hosts gehören nicht in eine Domäne, zumindest nicht in die Hauptdomäne!
Maximal kann man dafür eine eigene Domäne machen, ohne Vertrauensstellung zur Hauptdomäne.
Und es ist best practice 2 DCs zu betreiben.
Mein neuer Vorgesetzter wollte den physischen 2. DC UNBEDINGT virtualisieren – ROFL. Wahrscheinlich will er Spaß, wenn die Updates der virtuellen Umgebung mal nicht so funktionieren. Ich lasse ihm den Spaß. Es hängt ja auch nur das NAC mitunter vom AD ab, und die VPN-Einwahl, und und und :-)
ich bin froh nur kleine Umgebungen managen zu müssen.
Da hängt nahezu gar nichts vom AD ab.
> Maschinen mit identer SID im gleichem Netz,
Blödsinn! Hast Du genau hingeschaut? Ist Dir das Konzept vLAN bekannt? Offensichtlich nicht!
DC nur auf Baremetal… ich musste gerade lachen!
Ein DC klonen ist ein Desaster mit Ansage, sollte man auf keinen Fall machen!
Wo ist das Problem einen oder auch merere DC zu restoren / zu klonen und in einem _isolierten_ VLAN (oder einem private vSwitch) gegen den aktuellen Patchday zu testen?
Unterm Strich hat das nur Vorteile. Ich bin mir im Klaren, dass mein Backup funktioniert und wie der Restore läuft und ebenfalls kann ich meine (kritischen) Workloads so vorab mit den aktuellen Updates testen.
Desto öfter ich meine Restoreprozesse durchlebe und die Doku ggfs. anpasse, desto entspannter bin ich im Ernstfall, wenn es halt wirklich drauf ankommt. Da können die wenigsten Stress gebrauchen, der dann schon beim ersten Schritt auftritt, da man gar nicht weiß, ob das Backup überhaupt funktional ist. ;)
> Ein DC klonen ist ein Desaster mit Ansage, sollte man auf keinen Fall machen!
Warum machst Du dann noch Backups oder ziehst Images, wenn klonen angeblich so ein Teufelszeug sein soll..
Du schreibst Bullshit!
Wenn man Klonen und Backup gleichsetzt, sollte man vielleicht nicht so laut Bullshit schreien.
nicht wundern, das ist bei Tomas nix neues – er hat immer Recht 😅
Spiegelbild unserer Zeit, was nicht ins eigene Weltbild passt, wird weggeschrien.
Ich muss gestehen, mir ist dieses Problem noch nie untergekommen. Weder beim 2016er noch jetzt bei 2022. Das Problem kam nur, als ich mal testweise den NLA Dienst deaktiviert habe und dann schnell gemerkt habe, dass das keine so gute Idee ist. Für den 2025er kann ich nicht sprechen, aber es wundert mich, dass hier einige von Problemen seit Server 2016 sprechen. Mir war dieses Fehlerbild, bevor ich mit dem NLA Dienst rumgespielt habe, komplett neu.
Das „Problem“ ist schon min. 5 Jahre alt und kommt durch den NLASvc.
Mit dem NLASvc hat die „Network Location Awareness“ nicht nur in Windows Workstations Einzug gehalten, sondern auch bei den Server Ablegern (gleicher Kern). Wie der Name des Dienstes schon sagt, soll der Server dynamisch darüber entscheiden können, in welcher Umgebung er sich gerade befindet (Domain, Privat, Public). Davon leitet der Windows Defender die drei bekannten Umgebungen und daran hängen die Firewall-Regeln. Was für Workstations ggf. sinnvoll erscheint (z.B. im Hotel sollen Samba-Shares hinter TCP 445 vielleicht nicht sichtbar sein), ist für Server jedoch totale Banane. Ein Server oder eine VM vollzieht i.d.R. kein Roaming zwischen Umgebungen (…). Zur Mitigierung des Problems gibt es neben Frickeleien an Adapter-DNS-Suffixen noch deutlich bessere Möglichkeiten das „Problem“ in den Griff zu bekommen, gerade im Hinblick auf Automatisierung. Wenn ich über das Osterwochenende Zeit finde meine interne FAQ aufzuarbeiten und ins Netz zu stellen, werde ich das hier zur Verlinkung vorschlagen.
Gab es sowas nicht auch schon unter 2012 r2 und auch auf nicht DCs?
Ich erinnere mich das ich mal ein PS Skript in der Aufgabenplanung hinterlegt hab, das nach Neustart geprüft hat ob die aktiven Netzwerkadapter dem Domainetzwerk zugeordnet sind und wenn nicht wurden diese Adapter neu gestartet.
schön, noch ein todo fürs Autostart…
Microsoft, es geht immer weiter bergab mit euch…
Der Bug ist so alt wie der NlaSvc-Service selbst und betrifft alles an Server und Client OS das da ist. Seit Jahren. Witzig das der mal wieder explizit so erwähnt wird im Jahr 2025. :D
Das nichtmal ein DC weiss in welche Domaine er gehört finde ich persönlich an Peinlichkeit nicht zu übertreffen. =)
Eine Weile half bei meinen Umgebungen die ganzen zwischengespeicherte Profile in der Registry manuell zu cleanen. Allerdings funktioniert das irgendwie auch nicht mehr. Keine Ahnung was die an dem Zeug rumbasteln.
– Mit DHCP hilft eine ipconfig /renew (auch mit User-Credentials möglich)
– Mit fixen IP hilft aktivieren/deaktivieren des Netzadapters als zuverlässig(st)e Variante
– Das Binding an den DNS Dienst half dagegen nicht immer
Ebenfalls recht zuverlässig ist es, wenn ausschliesslich ein einziger Netzadapter verfügbar ist und der vor allem in den ganzen Auflistungen an erster Stelle erscheint. Ist aber schwierig zu erreichen weil auch die deaktivierten und versteckten zählen. Treiberupdate von z.B. VMXnet 3 (gab mal ein Update) hat wieder alles über Bord geworfen.
um das Chaos in der registry mit den versteckten netzwerk Einträgen zu beheben „reicht“ es, sämtliches in dem Hive von der Wurzel aus zu löschen. Das System baut das dann wieder neu auf. Echt faszinierend.
Natürlich ändern sich dabei die Adapter Namen. Aber dafür hat man ja seine Scripte…falls irgendwas tatsächlich einen speziellen Namen braucht(Vorsicht Falle. Manche Hardware meldet sich mit 16 Bit Chat. Zb
Intel sein „(R)“…)
übrigens:
das Klonen der Rechner hilft nicht
die registry Einträge des alten Interfaces bleiben erhalten.
(Auch Microsoft unterliegt der irrigen Annahme, das es ja keine 2 Netzwerkkarten mit derselben MAC Adresse geben darf, weil ja in der Ethernet spec verboten und das Netzwerk eh nicht funktionieren würde…)
kopiert man das Image zurück, dann erkennt Windows die alte Karte wieder und nimmt diese Einträge, was man nicht immer will.
Da hilft nur die radikal kur über Netsh oder sogar direktem löschen des kompletten Hives in der registry.
Nur braucht es schon Mut, weil MS ja nicht alles dokumentiert, aber der Wiederaufbau funktioniert.
zwei Rechner mit der selben SID gibt m.W. nur bei WSUS echte Probleme, da WSUS die Updates nur auf den ersten der Rechner ein spielt, findet er den zweiten, dann sieht er in seiner Datenbank an der SID, dass er den ja schon gepatcht hat…
warum auch sollte er prüfen, es ist ja klar verboten die SID zu kopieren… Beim normalen Betrieb spielt die SID im Netz keine Rolle. Wären ja auch ein riesen Sicherheits Loch.
> zwei Rechner mit der selben SID gibt m.W. nur bei WSUS echte Probleme,
NEEEEEEEIIIIIIIIIIIN! !1!11
Dem WSUS ist die SID des Computers total egal. vollkommen Pumpe
das Problem des WSUS ist die SUSID, eingeführt mit Windows 2000 SP2 und den ersten SUS Dienst.
diese wird selbst bei sysprep nicht resettet.
den Registry Wert muss man manuell löschen
und JAAAAAAAAAA, die SID ist im normalen Betrieb relevant, wenn lokale Konten und Berechtigungen zum Einsatz kommen
https://learn.microsoft.com/de-de/sysinternals/downloads/newsid
Das Problem besteht nicht erst seit kurzem – es ist seit geraum Zeit bekannt: https://www.frankysweb.de/en/windows-server-2025-wrong-network-profile-on-domain-controller/
Der Artikel ist von November 24.
Man merkt halt: Microsoft ist von einer Softwarefirma zu einer Bananenfarm geworden, wo die Produkte grün geerntet/ausgeliefert werden und beim Kunden ausreifen dürfen.
Ist doch eh wurscht, wie verbuggt die MS Systeme sind. Sie werden weiterhin gekauft und verwendet. Die müssten sich ja in Redmond schon dumm und dämlich lachen über ihre Kundschaft. Egal wie kapital es MS versenkt, es hat absolut keine Konsequenz für MS.
So sieht es aus. Egal was Microsoft verbockt (Cloudausfall, Abfluss von Azure Key, etc.) es wird einfach ohne größere Nachfragen akzeptiert…. Ist halt so und wir brauchen das alles von Microsoft. Softwarequalität, da dreht sich mein verstorbener Software Engineering Prof im Grab rum, einfach nur verheerend. Die Qualität ist aber nicht nur bei Microsoft so schlecht, da gibt’s noch so paar andere.
super interessante, kompetente Beiträge. Danke für.
Aber irgendwie ist das doch Bastelei, wie vor 40 Jahren, oder?
Schon damals gab es Henne und Ei Probleme, aber die waren irgendwann gelöst, auch wenn man nicht die Hälfte des Jahresumsatzes an einen Hersteller überweisen musste.
Kann es sein, das Microsoft als Organisation eine Größe erreicht hat, die nicht mehr beherrschbar ist?
Im der BWL gibt es so Regeln dass Unternehmen doch nur begrenzt wachsen können. und Microsoft diese Grenze erreicht hat?
Naja, sehr gross sind die schon lange. Die könnten es schon richtig machen, wenn sie den wollten. Die Frage ist halt immer, was hat Priortität. Solange es kein Sicherheitsproblem ist, wird da gar nix gehen sondern die Prio liegt auf Neuentwicklungen.
Ich will nicht wissen wie viele Admin-Scripts in ungeschützten Ordner lagern welche den Netzadapter deaktivieren/aktivieren. Indirekt wäre es sicher ein Sicherheitsproblem.
ich habe gerade einen dejavu.
immer wenn ein Kollege einen Rechner händisch aufgesetzt hatte kam man nicht mit der Fernwartung drauf.
Irgendwann wurde klar, dass der Kollege „Public“ und „private“ auf seine eigene Art interpretierte und die Kisten auf Public liefer.
da besondere Dienste explizit freigeschaltet wurde, lief alles.
Die Fernwartung aber nicht
könnte vielleicht der Kollege einen Cousin bei Microsoft haben, dem dieser Gedankenfehler auch unterlaufen ist?
Die Nomenklatur an dieser Stelle ist fehlerträchtig gewählt. Das sich zeigt ja auch daran, dass MS da so einen riesige Beschreibung machen muss (die natürlich niemand ließt, ist doch klar was Public bedeutet…)
Ist nur Spekulation, aber wenn der DC wegen Ladens des (falschen) Standard-Firewallprofils nicht erreichbar ist, könnte es helfen, in diesem die entsprechenden Einstellungen manuell zu setzen. Dann sollte er trotzdem erreichbar bleiben und ggf. funktioniert es dann sogar, dass er sich beim nächsten GPO Lauf (std. 90min?) die korrekten Infos (von sich selbst) abholen kann.
Ich kann es nicht testen und bitte mit Vorsicht genießen, aber Bing sagt dazu:
______________________________
Gute Frage! Wenn du die Firewall auf einem Windows Server mit Domain Controller selbst konfigurieren möchtest, um den Abruf von Gruppenrichtlinienobjekten (GPOs) zu ermöglichen, müssen bestimmte Ports geöffnet sein. Hier sind einige wichtige Ports, die für die Kommunikation erforderlich sind:
TCP 135 – RPC-Endpunktzuordnung
TCP/UDP 389 – LDAP (Lightweight Directory Access Protocol)
TCP 636 – LDAP über SSL
TCP 3268 – Globaler Katalog (GC)
TCP 3269 – Globaler Katalog über SSL
TCP/UDP 53 – DNS (Domain Name System)
TCP/UDP 88 – Kerberos-Authentifizierung
TCP 445 – SMB (Server Message Block) für Datei- und Druckdienste
TCP/UDP 1025-5000 – Dynamische Ports für RPC-Kommunikation
TCP/UDP 49152-65535 – Dynamische Ports für neuere Windows-Versionen
Diese Ports sind essenziell für die Kommunikation zwischen Domain Controllern und Clients, insbesondere für die Anwendung von Gruppenrichtlinien.
______________________________
Alternative dazu könnte ein Festlegen in den lokalen Gruppenrichtlinien sein oder ein Export der Domain Regeln und Import/Überschreiben ins Standardprofil.
______________________________
Bei Franky gibt es noch den Tipp:
Andreas
26. January 2025 at 11:07
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
https://www.frankysweb.de/en/windows-server-2025-wrong-network-profile-on-domain-controller/
Gibt auch noch weitere Tipps dort…
du f***st dich gerade ins Knie, nur um den reset der Netzwerkkarte zu umgehen, der nur in einem Single DC Konzept relevant ist.
und willst akzeptieren, das ein DC mit Public Firewall Profil agiert.
Desweiteren wird der DC deine Richtlinie nicht nach 90 Minuten übernehmen.
der internal eines DC ist bei 5 Minuten und dann stellt er fest, das die Version der Richtlinie identisch ist zum letzten Lauf, ergo kein Auftrag zur Verarbeitung.
jetzt machst du entweder immer ein gpupdate /force oder zwingst ihn das nur für die Komponente der Registry zu tun.
Das das im Vergleich zu reset-nic totaler Irrsinn ist, leuchtet ein, oder?
BTW, wer hausintern IPv6 aktiv hat ist selber Schuld. ABSCHALTEN! auf Domänenebene (disabledcomponents).
ROFL
Ich mache garnichts außer, dass ich versuche zu helfen mal davon abgesehen, dass der Server aufgrund des Fehlers sowie „Öffentlich“ unterwegs ist, was sicherheitstechnisch aufs Gleiche rauskommt und deshalb irrelevant ist – man könnte damit aber wenigstens weiterarbeiten…
Ein Stück weiter unten hatte ich zusätzlich geschrieben, dass man dafür ggf. auch lokale Richtlinien, als Kopie der GPOs verwenden könnte, gedacht als, falls die Verarbeitung der GPOs und somit die Erkennung des Domänenprofils aufgrund der eigenen Nichterreichbarkeit des Servers nicht funktioniert (bietet sich bei dem Problem ja an) dann wäre der nächste funktionierende(!) Abruf der Erste – würde also funktionieren, oder man mit einem Export der Domänenprofil-Einstellungen die Öffentlichen überschreiben könnte, wodurch dieselbe Sicherheit wie beim Domänenprofil gegeben wäre, auch wenn der Fehler auftritt; so war mein Kommentar eigentlich von Anfang an gemeint. Das würde den Fehler sogar irrelevant machen! Dann hätte man zusätzlich auch in Zukunft Ruhe ohne ständig den Netzwerkadapter unnötigerweise mit einem Skript und geplanten Aufgaben de-/aktivieren zu müssen, denn es ist ja auch nicht das erste Mal, dass so ein Fehler auftritt; es gibt mehrere Meldungen zu älteren Servern mit demselben Thema und unter Windows 7 hatte ich schon vor 10-15 Jahren das Problem, allerdings war es da die Verwechslung von „Privat“ und „Öffentlich“. Viel Spaß übrigens wenn während der Deaktivierung Daten übertragen werden, die dann fehlerhaft beim Ziel ankommen und weitere Probleme verursachen…
Noch weiter unten in meinem Beitrag, in dem von Frankysweb kopierten Abschnitt, ist auch ein Hinweis auf „disabledcomponents“ vorhanden. Dieses schaltet IPv6 nicht ab sondern deaktiviert nur die meisten Funktionen davon! Auch hier viel Spaß damit, wenn man das, insbesondere auf Windows Servern, vollständig deaktiviert oder falls du Post vom Anwalt bekommst, weil das jemand falsch verstanden und durch die (vollständige) Deaktivierung Probleme bekommen hat.
Und die Idee das auf Domänenebe zu deaktiveren, wo doch die Domäne mit dem Problem nicht erreichbar ist… Bombe!
255 / FF schaltet ipv6 zuverlässig ab. es gibt außer Direct Access und bis zur 1709 das MS Heimnetz keine Funktionalität, die nicht v4 kann.
selbst das BSI empfiehlt das deaktivieren von ipv6, wenn es nicht vollständig 100% durchkonfiguriert ist.
keiner benötigt intern v6, ausser ein paar Firmen mit mehr als 60.000 Endpunkten.
was denkst du, warum MS Direct Access zu legacy erklärt hat und wieder SSL v4 VPN macht? keiner macht v6 und aktives falsch konfiguriertes v6 macht mehr Fehler und Schattennetze und stellt damit ein Risiko dar, plus DSGVO Probleme, weil du mit v6 eindeutig immer persönlich identifizierbar bist
ergo Disabledcomponents = 255/FF
Lern lesen!
[ Achtung, wichtig: Das ist nur für fortgeschrittene Nutzer gedacht! ;) ] https://learn.microsoft.com/de-de/troubleshoot/windows-server/networking/configure-ipv6-in-windows
Aber wahrscheinlich lügt Microsoft im Bezug auf die Funktionen von Windows…
Außerdem ist nirgends, bis auf in den zwei kleinen Sätzen aus dem externen Beitrag, von IPv6 die Rede und das sogar nur in direktem Zusammenhang mit deinem vergötterten „DisabledComponents“, was so wie beschrieben auch nur deshalb funktionieren kann, weil eben nichts vollständig deaktiviert wird… Und noch ein Tipp: STRG+F „Direct Access“.
Meine bescheidene Ansicht dazu: Microsoft hat DirectAccess schon vor langer Zeit mit der Einführung von Always-On-VPN als überflüssigen Schrott deklariert, weil es eine hochkomplexe, inkompatible und proprietäre Frickellösung ist – ich war schon bei Einrichtungen davon dabei – mit dem einzigen Vorteil der automatischen Verbindung von unterstützten(!) Clients ins Firmennetzwerk.
Abgesehen davon: Was kümmert mich, was das BSI schreibt? Wenn am Router IPv6 inaktiv ist, können die Endgeräte soviel IPv6 funken wie sie wollen – es geht sowieso nichts nach draußen! Zu „vollständig 100% ([sic!] bisschen redundant, oder? xD) konfiguriert“: IPv6 ist weitestgehend konfigurationsfrei! Vielleicht setzt du dich mal selbst ausführlich damit auseinander!? Oder kaufst eine ComputerBILD oder schreibst dich vielleicht für einen Grundkurs in Computernetzwerken an der Volkshochschule ein. :P
Datenschutz mag ich übrigens auch sehr gerne! Die meisten Standard-Betriebssysteme sind, bis auf ein paar Linux Distributionen, inklusive Windows seit Vista und sogar Android seit Ice Cream Sandwich (v4) in deren Grundkonfiguration, zumindest im Bezug auf die reine IPv6 Netzwerk- bzw. Internetverbindung, absolut DSGVO konform einsetzbar und gerade bei Windows würde ich das, im Bezug auf den Datenschutz, eher etwas weiter hinten einreihen…
Stichwort müssen: „internal“ ist dir schon ein Begriff, oder?
dein Problem ist, das „wenn ipv6 auf dem Router deaktiviert ist“. das ist dein Kommunikationsloch im Regelwerk, wenn es vergessen wurde.
Direct Access ist keine hochkomplexe Frickellösung, sonst wäre es nicht im SBS2008 für Anfänger drin gewesen „on click“
der Vorwurf proprietär ist dumm, da das für jeden anderen VPN Anbieter gilt.
du bist ganz schön beleidigend, für jemanden der sich so weit aus dem Fenster lehnt, ohne Gegengewicht.
wieso sollte das Netzwerk nicht erreichbar sein?
das Netzwerk ist immer erreichbar, durch ein simples Reset der NIC.
ihr macht riesige Fässer auf mit Bastellösungen, anstatt es einfach zu halten …
Aus den Infos bei Franky und weiteren aus dem weiten Internet habe ich das Script aus dem folgenden Artikel erstellt. Das läuft hier in reichlich Umgebungen mit Windows Server 2025 Domain Controllern: https://jans.cloud/2025/03/unidentified-network-public-firewall-profile-bei-windows-server-2025-domain-controller/#bei-mehreren-domain-controllern
HTH
Cool danke! Brauche ich zwar nicht – hilft aber vielleicht Anderen! :)
Du könntest noch ergänzen/kommentieren, was die Befehle exakt machen.
Die DNS-Cache-Befehle könnten grundsätzlich bei allen Windows Servern sinnvoll sein; insbesondere in Umgebungen bei denen die Anwender die Art der Netzwerkverbindung wechseln (LAN, WLAN, Mobilnetz; Homeoffice usw.) um immer anständig mit der aktuellen IP adressiert zu werden.
Was mir gestern noch nach Absenden des Kommentars noch eingefallen ist:
Ich hatte vor einigen Jahren schomal erarbeitet, dass die DNS-Warnungen von ‚dcpromo‘ umgangen werden können, wenn man bei DCs als primären DNS einen anderen DC und zusätzlich als Sekundären die Loopback Adresse einträgt (Oder ungekehrt oder so ähnlich – ist schon eine Weile her…). Das deckt sich teilweise mit einer von den bei ‚frankysweb‘ Lösungen und hätte das Problem möglicherweise von Anfang an nicht auftreten lassen.
Wir tragen die Loopback-Adresse auf DCs immer als 2. oder 3. DNS-Adresse ein. So kommt der DC auf jeden Fall schneller hoch, wenn es Probleme mit dem LAN-Interface gibt.
Ich tu mir diesen Irrsinn aus MS Updates, Oracle und Co einfach nicht mehr an. Gerne kann auch Fortinet und Co hinzugefügt werden. Habt Spaß mit den Updates. /zyn
Kann ich verstehen! Macht aber halt auch Spaß… :) …trotz Burnout(!?) :D
PS IT ist immer Irrsinn (und Lebenszeitverschwendung) – unabhängig von den genannten Herstellern/Produkten xD