Jul 04, 2023, updated at Jul 06, 2023 (UTC)

3972

Kaputten DC (AD) reparieren

Hi,

ich suche ein paar Tips, was ich am besten mit einem kaputten Windows Server 2012R2 mache. Den hab ich geerbt und die Doku ist ähh... einigermaßen knapp... Den wollte ich upgraden. Ist ein kleines Netz, einziger DC und auf dem läuft von Telefonserverkram über Fileserver bis hin zu sonstwas alles mögliche, so ein "All-in-Wonder"-Server. Datensicherung ist getrennt in Daten und System, Daten-Datensicherung sieht erstmal ganz gut aus. Das System wird über ein Imagetool gesichert.

Da läuft ein ArcServe, das hat einen "SystemStateBackup" Job, der erzeugt irgendwie jeweils 2KB Daten. Kann man also vergessen.

Ich wollte erstmal Windows Server Backup über Server Manager Feature hinzufügen, damit ich ein Systemstate Backup machen kann, aber die Installation klappt nicht (kommt Fehler 0x800f0831). Hab dann paar der üblichen Kommandos gemacht, ich glaub, ich war bei sfc /scannow (hatte ich über Nacht laufen lassen) und konnte mich tags drauf nicht mehr mit RDP nicht mehr verbinden (nach dem Passwort kam nur ein schwarzer Bildschirm).

Dachte, der Server hängt und hab ihn gebootet. Beim reboot wurde ein chkdsk gemacht. Danach kommt irgendwas von "Windows Problem" (kann ich so schnell nicht lesen) und ein boot loop.

Gut, single DC, also BMR einspielen. Beim Start auch chkdsk und boot loop. Backup vom Vortag das gleiche. Das älteste ist so drei Wochen alt und hat das gleiche Problem. Da war das Windows Dateisystem also drei Wochen kaputt, das chkdsk macht es nur schlimmer und die Backupimages sind durchrotiert. Na Prima.
chkdsk beim boot abbrechen, Server startet. Windows Server Backup hinzufügen auch Fehler 0x800f0831. Immerhin kann man alle Benutzer, Computer usw aus dem AD sehen.

Ich habe leider keine einfache Möglichkeit für einen AD Export gefunden. Es gibt noch einen anderen Windows Server, nämlich den mit den Backups, aber da ne DC Rolle hinzuzufügen erscheint mir zu riskant, wer weiß, was das kaputte Windows dann an dem auch noch kaputt macht.

Jetzt würde ich vielleicht als Notnagel ein Samba DC aufsetzen in der Hoffnung, dass eine AD Replikation dahin klappt, dann hätte ich wenigstens die SIDs und so. Falls das nicht klappt, irgendwelche Scripte suchen, die AD User mit SID und vielleicht Gruppen exportieren kann.

Hat jemand eine bessere Idee oder Tips, was ich jetzt in dieser Sitation am besten mache?

Please also mark the comments that contributed to the solution of the article

Content-Key: 7736101239

Url: https://administrator.de/contentid/7736101239

Printed on: May 21, 2024 at 23:05 o'clock

28 Comments

Latest comment

ps: Um Zeit zu sparen, gebe ich gleich selbst schon ein paar Antworten:

1) "Ein DC ist ein DC und sonst nichts, musst halt ein paar Server und Lizenzen mehr kaufen" - Ich weiß.
2) "Ein Imagebackup macht man nicht vom DC, das reicht nicht" - Ich weiß.
3) "Backups muss man täglich kontrollieren, am besten in eine isolierte VM in einem virtuellen Testnetz mit AD Clienten recovern und alles komplett durchtesten" - Ich weiß.
4) "Arcserve ist doch Schrott, nimm lieber XYZ" - Ich weiß.
5) "Server 2012R2 ist total alt, das ist alles Schrott" - Ich weiß.
6) "Wer keine Ahnung hat und Microsoft Blog XYZ nicht gelesen hat, der sollte da gar nichts anfassen" - Ich weiß
7) "Samba ist frickeln, kaufe mehr Windows Server" - Ich weiß.

Moin,

was aus deinem Post nicht ganz klar wird: Wenn der DC über deinen Workaround bootet, laufen dann alle AD Dienste etc?
Falls ja: Zweiten DC aufsetzen, syncen lassen, Rollen migrieren.

Edit noch: Du kannst auch einen UCS aufsetzen und einen AD Takeover probieren.

Zitat von @lastcentral:

ps: Um Zeit zu sparen, gebe ich gleich selbst schon ein paar Antworten:

1) "Ein DC ist ein DC und sonst nichts, musst halt ein paar Server und Lizenzen mehr kaufen" - Ich weiß.
2) "Ein Imagebackup macht man nicht vom DC, das reicht nicht" - Ich weiß.
3) "Backups muss man täglich kontrollieren, am besten in eine isolierte VM in einem virtuellen Testnetz mit AD Clienten recovern und alles komplett durchtesten" - Ich weiß.
4) "Arcserve ist doch Schrott, nimm lieber XYZ" - Ich weiß.
5) "Server 2012R2 ist total alt, das ist alles Schrott" - Ich weiß.
6) "Wer keine Ahnung hat und Microsoft Blog XYZ nicht gelesen hat, der sollte da gar nichts anfassen" - Ich weiß
7) "Samba ist frickeln, kaufe mehr Windows Server" - Ich weiß.

Ey, nimm den Leuten doch nicht den Spaß hier

Moin,

mal ne ganz extrem blöde Frage. Du schreibst, der einzige DC hängt im Dauerloop. Der ist also praktisch nicht da. Nur für mich zum Verständnis, Deine Idee ist jetzt einen, wie auch immer gearteten, zweiten DC zu installieren, in der Annahme, dass der kaputte DC immer mal wieder kleinste AD-Partikel irgendwohin repliziert, während er selbst Achterbahn fährt?

Mag ja aber sein, dass ich wieder mal etwas falsch verstanden habe

Gruß

Moin,

eigentlich bist du ja schon am Arsch. Aber dennoch:

Besorg nen neuen Server, setze Hyper-V auf
Installier da nen DC und nen Fileserver
mach nen Image von dem alten Server und binde den in den neuen als VM ein um die Daten zu retten.

Gruß

Hi,

um wieviel User/Systeme/Software geht es denn?

Neues System parallel aufsetzen und Daten rüber kopieren. Möglichst gar nichts mit dem alten verbinden.

Wir hatten auch ewig ein legacy Systeme mitlaufen weil und weil und....
Ein "ransomware-Dienstleister" hat uns dann ratis gezeigt, dass es auch ohne geht...

Sg Dirm

Danke für eure schnellen Antworten!
Ich sammle das mal in einen Antwort-Post.

Quote from @Tezzla:
was aus deinem Post nicht ganz klar wird: Wenn der DC über deinen Workaround bootet, laufen dann alle AD Dienste etc?

Print Server fehlt (wurde aber wohl eh nicht mehr benutzt)

Falls ja: Zweiten DC aufsetzen, syncen lassen, Rollen migrieren.

OK, für einen zweiten (Windows-) DC fehlt mir die Lizenz, daher die Idee mit Samba DC.

Edit noch: Du kannst auch einen UCS aufsetzen und einen AD Takeover probieren.

Danke für den Tip, aber das liest sich da, als ob UCS zwei Nummern zu groß ist...

Quote from @Coreknabe:
mal ne ganz extrem blöde Frage. Du schreibst, der einzige DC hängt im Dauerloop. Der ist also praktisch nicht da.

wenn ich chkdsk beim Start laufen lassen, startet er nach der "Reparatur" nicht mehr.
Wenn ich chkdsk beim Start nicht laufen lasse (also Taste drücke), dann startet er (aber ich traue ihm nur soweit, wie ich den Server mit einer Hand werfen kann (0 Meter) )

Nur für mich zum Verständnis, Deine Idee ist jetzt einen, wie auch immer gearteten, zweiten DC zu installieren, in der Annahme, dass der kaputte DC immer mal wieder kleinste AD-Partikel irgendwohin repliziert, während er selbst Achterbahn fährt?

Die Hoffnung wäre, dass das AD Verzeichnis repliziert (die Annahme ist, dass es einen nichtssagenden kryptischen Fehler code gibt und nicht mal kleinste AD Partikel, sondern überhaupt nichts repliziert wird). Clienten können sich anmelden, Logon, DHCP, DNS und so sind da (läuft ja seit mindestens ca drei Wochen, vielleicht viel länger, so, ohne das es jemand gemerkt hat. Allerdings sind auto-updates an, daher müsste er ja mindestens einmal im Monat starten und hätte sich dann schon kaputt repariert. Hätte man dann wenigstens gemerkt).

("Core Knabe"

ha der ist Klasse

)

Quote from @Kraemer:
eigentlich bist du ja schon am Arsch.

Ich weiß. Die Frage ist, wie man da jetzt am besten weitermacht, insbesondere, was man vielleicht noch exportieren kann, damit die ggf. neu aufgesetzte Domain möglichst "ähnlich" ist (Beispielsweise würden gleiche User und Gruppen SID schon mal viel Arbeit sparen, weil ich dann nicht alle Dateirechte auf allen Clienten neu setzen müsste).

Besorg nen neuen Server, setze Hyper-V auf
Installier da nen DC und nen Fileserver

Für einen weiteren DC hab ich keine Lizenz, daher die Idee mit Samba (ich hab ein kleinen Proxmox-Cluster da).

mach nen Image von dem alten Server und binde den in den neuen als VM ein um die Daten zu retten.

Die Images sind ja kaputt (also das Dateisystem auf C: ), das sollte sich in einer VM ja genauso verhalten. Aber gut, wenn das läuft, was genau mach ich dann da? AD kann man ja leider nicht exportieren (jedenfalls hab ich nichts gefunden).
Also genau, Daten retten (bzw. "Wissen" a la "welche Gruppen gibt es") ist das Stichwort, da suche ich nach Tips. Was kann ich tun?

Quote from @Dirmhirn:
um wieviel User/Systeme/Software geht es denn?

5 Nutzer, 2 Server, 8 Rechner, ein paar Geräte (Drucker), die Linux Maschinen brauchen wohl nur DHCP und DNS.

Software ist schwieriger, da läuft ein Fax-irgendwas (ISDN :/), ein Telefonanlagen-irgendwas und weiß ich was noch alles...

Neues System parallel aufsetzen und Daten rüber kopieren. Möglichst gar nichts mit dem alten verbinden.

Wie kopiere ich denn AD Daten?

Wir hatten auch ewig ein legacy Systeme mitlaufen weil und weil und....

Ja, das scheint erstaunlich schwierig zu sein, unter Windows sowas zu machen.
Es gibt ja Domain-Migrations-Tools, aber die scheinen auch selbst für so kleine Netze mehrere Tage Einarbeitung zu benötigen.

Ein "ransomware-Dienstleister" hat uns dann ratis gezeigt, dass es auch ohne geht...

Ja, das ist bei Windows leider auch immer ein Problem

Hi,
der Ansatz von @Tezzla wäre doch schon optimal.
Die Lizenz wäre erstmal nebensächlich, weil es doch nur um eine temporäre Installation ginge. Auch wenn Du natürlich langfristig dafür sorgen solltest, dass da ein 2. DC läuft, und sei es es nur nebenbein irgendwo als HyperV-VM.

Wenn Du den 2. DC hinbekommst, dann die FSMO übertragen, DNS, die DNS-Clients auf diesen 2. DC/DNS umstellen. Dann den 1. DC demoten, wenn geht. Wenn das nicht geht, dann könnte man den auch später noch "hart" entfernen.
So oder so hättest Du jetzt die Ruhe, Dich um die Wiederherstellung des Servers zu kümmern.

E.

Ist der Fax/ISDN server AD integriert oder hat damit orgendwas zu tun?

Also einen alten Server auf ebay kaufen und neu machen. Wenn keine MS Lizenzen, dann mit Ubuntu oder sonstwas. Da bist du wohl schneller als mit Migration oder sonstigen Reparaturen.

Sind vll paar Wochen doppelbetrieb für die User, aber kann nur besser werden.
Für Fax und ISDN Alternative suchen bis, das alte stirbt.

Hatte früher auch eher Bedenken bei altsystemen, aber möglichst viel dokumentiert und dann neu aufsetzen. Wenns läuft, das alte Weg. Auch wenn user sagen, aber das war immer so... sie gewöhnen sich an neues.

Meine Meinung...

Sg Dirm

Wenn der DC jetzt so läuft, dann migrier das AD auf eine neue Maschine mit Boardmitteln, Rollen verschieben etc. Ob du den dann wieder mit anderen Sachen zumüllst, sei mal dahin gestellt. Solange er ordentlich funktioniert ist die Kuh dann erstmal vom Eis.

Für den Parallelbetrieb gibt es ja die Testphase. Da muss gar kein Key eingegeben werden.

N'Abend.

Fehlende Lizenzen für einen Windows Server sind hier nicht das Problem, die EVAL-Versionen laufen 180 Tage ohne Funktionseinschränkungen und lassen sich, wenn benötigt, mehrfach verlängern und/oder in eine reguläre Version konvertieren.

Spätestens bei der Promotion zum DC stellst du fest, ob das so klappen kann - wenn nicht, hast du auch nicht mehr kaputtgemacht. Versuch macht also kluch.

Viel Erfolg.

Cheers,
jsysde

Also erstmal nochmal vielen lieben Dank an euch alle!

Kurz: Es scheint alles geklappt zu haben und "die Kuh ist vom Eis"

(wie @Tezzla sagt).

Ich hatte erst Samba probiert, aber das geht so überhaupt nicht, da muss das Featurelevel irgendwie noch kleiner als Server 2012 R2 sein und da hab ich nicht weiter geguckt.

Mit der Lizenz ist ja Quatsch, ich hab ja die neue Lizenz da (wegen des nötigen Updates wegen Supportende kam ich ja überhaupt nur drauf den Server anzugucken, hatte da mit Bestandsaufnahme und der Prüfung der Backups angefangen, und man kann ja zwei VMs pro Lizenz machen, also alles prima).

Ich hab also einfach Windows Server auf das hiesige Proxmox installiert und als DC hinzugefügt. Das hat einfach nur so geklappt, gab zum Glück keine Fehler. Rollen und Features installiert, paar Verwaltungstools, DHCP, DNS, GPO, dann hochgestuft, ging alles. DNS hat er im Prinzip automatisch gemacht (ich musste noch irgendwo "ja" sagen, glaube ich), jedenfalls steht der neue jetzt zusätzlich als NS drin. Jetzt muss ich vermutlich höchstens noch irgendwie die Zonenautorität verschieben, falls überhaupt, aber auch so müsste das ja jetzt normaler Betrieb mit zwei failover DC sein. Das einzige, was ich per Hand gemacht habe, war DHCP failover einrichten.
Falls ich mich morgen aufraffen kann fahre ich mal hin, fahre den alten Server runter und gucke, ob sich Clienten anmelden können. Aber bei dem Wetter wird das nicht leicht.

Und natürlich Windows Server Sicherung nach Zeitplan hab ich eingerichtet. Da ist meines Verständnisses nach bei der Vollständigen alles dabei, was ich brauchen könnte, richtig? Ich hab dem ein extra Volume gegeben. Bei Rücksicherung könnte ich System State auswählen, damit funktioniert das, oder muss ich noch was prüfen? Durchgeführt hab ich da jetzt keine Rücksicherung.

Ja danke an alle für die Tips!

Quote from @emeriks:
Die Lizenz wäre erstmal nebensächlich, weil es doch nur um eine temporäre Installation ginge. Auch wenn Du natürlich langfristig dafür sorgen solltest, dass da ein 2. DC läuft, und sei es es nur nebenbein irgendwo als HyperV-VM.

(ja ich HONK, ich hab ja eh schon ne neue Lizenz)

Wenn Du den 2. DC hinbekommst, dann die FSMO übertragen, DNS, die DNS-Clients auf diesen 2. DC/DNS umstellen. Dann den 1. DC demoten, wenn geht. Wenn das nicht geht, dann könnte man den auch später noch "hart" entfernen.

Ich glaube, den DC hab ich hinbekommen. Ich hab die FSMO übertragen (also "Move-ADDirectoryServerOperationMasterRole -Identity “dc2” –OperationMasterRole PDCEmulator,RIDMaster,InfrastructureMaster,DomainNamingMaster,SchemaMaster" gemacht) und netdom query fsmo zeigt nur den neuen an.
Sorry für die blöde Frage, aber was muss ich mit DNS machen? Ich sehe, dass unter NS der neue auftaucht, aber im SOA steht der alte.
Was muss ich bei den Clients machen, nur die IP umstellen, falls kein DHCP?
Das werde ich mal gleich heute noch machen, sonst komm ich notfalls nicht ans Proxmox oder so, weil die keine IPs auswendig kenne, guter Tip!

So oder so hättest Du jetzt die Ruhe, Dich um die Wiederherstellung des Servers zu kümmern.

ja hoffentlich nicht am Wochenende ...

Quote from @Dirmhirn:
Ist der Fax/ISDN server AD integriert oder hat damit orgendwas zu tun?

ja, ist bestimmt integriert, gibt da persönliche Ausgangskörbe oder sowas, aber zur Not gibts ein noch so Multifunktionsgerät, FAX stell ich erstmal zurück. Gibt ja auch Dienstleister und alles, später mal schauen, genau.
Ich hoffe, da läuft sonst nichts wichtiges, was auf die Schnelle niemandem eingefallen ist ^_^ Brandmeldesoftware oder sowas wäre noch der Hammer...

Also einen alten Server auf ebay kaufen und neu machen. Wenn keine MS Lizenzen, dann mit Ubuntu oder sonstwas. Da bist du wohl schneller als mit Migration oder sonstigen Reparaturen.

Ich hab Debian 11 mit Samba 4.17 probiert, aber da geht wohl nur ein Domain Feature Level 2008, was wohl bis heute für Windows 10 und alles reichen soll, aber war mit jetzt zu viel auf einmal.

Hatte früher auch eher Bedenken bei altsystemen, aber möglichst viel dokumentiert und dann neu aufsetzen. Wenns läuft, das alte Weg. Auch wenn user sagen, aber das war immer so... sie gewöhnen sich an neues.

Ja, da erwarte ich eigentlich keine Probleme, die sind alle nett

Quote from @Tezzla:

Wenn der DC jetzt so läuft, dann migrier das AD auf eine neue Maschine mit Boardmitteln, Rollen verschieben etc. Ob du den dann wieder mit anderen Sachen zumüllst, sei mal dahin gestellt. Solange er ordentlich funktioniert ist die Kuh dann erstmal vom Eis.
Für den Parallelbetrieb gibt es ja die Testphase. Da muss gar kein Key eingegeben werden.

Ja, danke, genauso hab ich es gemacht, das hat zum Glück geklappt (hoffe ich jedenfalls). Ja und Key hab ich sogar, denn der Server sollte ja eh ersetzt werden. Da gab es jetzt also eine "große Abkürzung" / Beschleunigung :/

Quote from @jsysde:
Fehlende Lizenzen für einen Windows Server sind hier nicht das Problem, die EVAL-Versionen laufen 180 Tage ohne Funktionseinschränkungen und lassen sich, wenn benötigt, mehrfach verlängern und/oder in eine reguläre Version konvertieren.
Spätestens bei der Promotion zum DC stellst du fest, ob das so klappen kann - wenn nicht, hast du auch nicht mehr kaputtgemacht. Versuch macht also kluch.

Ja, genau so war es, es hat zum Glück geklappt (hatte erst ohne Aktivierung die Rollen übernommen, dann aktiviert) und jetzt scheint es fehlerfrei zu laufen, hoffe ich.

Ja, danke euch allen. Fühlt man sich nicht so allein

Den DNS-Clients solltest Du den alten DNS-Server komplett entfernen, weil Du diesen ja über kurz oder lang eh rausschmeißen wirst.
Ob Du das über DHCP machst oder manuell, bleibt Dir überlassen. Beachte bei DHCP, dass diese Änderung erst bei nächster Erneurung der Lease am Client ankommt. Wenn da also Standard 8 Tage als Leasedauer drin steht, dann müsstest Du bei allen standig durchlaufenden Clients bis zu 5 Tage warten, um sicherzugehen, dass diese die Lease erneuert haben. Oder Du sorgst dafür, dass alle DNS-Clients durchstarten. Oder löst auf allen ein ipconfig /renew aus.

HILFE!
Der alte Server ist gerade gestorben (reboot wegen Updates) und nichts funktioniert mehr.
Ich hab eine Workstation neu gestartet, die kriegt über DHCP vom neuen Server ne IP und DNS (neu und alt).
Hab RDP auf den neuen ("dc2") gemacht. Der hatte inzwischen wegen Updates auch neu gestartet.

Da mache ich ein "netdom query fsmo", was vor einer Stunde noch funktioniert hat, aber jetzt sagt es "Die angegebene Domäne ist nicht vorhanden, oder es konne keine Verbindung herstellt werden" (auf dem dc2 selbst kriege ich das). nslookup dc2 antwortet mit der eigenen Adresse. "ping 8.8.8.8" geht, "nslookup google.com" antwortete zweimal mit Timeout, beim dritten mal ging es.

Versuche ich sowas wie domain.msc zu starten, kriege ich "Active Directoy Domänen und Vertrauensstellungen - Die Konfigurationseinstellungen, die diese Organisation beschreiben, sind nicht verfügbar. Die angegebene Domäne ist nicht vorhanden, oder es konnte keine Verbindung herstellte werden" (sagt der neue Domain Controller).

Was soll ich jetzt am besten tun?
Ich kann den alten Server sicher wieder mit dem drei Wochen alten Backup restoren, aber da ist ja dann kein anderer Domaincontroller bekannt, dass kann ja nur ein Problem werden, oder?
HILFE!

Was mir noch aufgefallen ist:
In der Ergeignisanzeige des neuen Domaincontrollers finde ich unter anderem WARNUNG "Dieser Server ist der Besitzer der folgenden FSMO Rolle, die jedoch nicht als gültig eingestuft wird. Für die Partiion, die das FSMO enthält, wurde dieser Server seit dem letzen Neustart nicht erfolgreich mit einem beliebigen Partner repliziert. Replikationsfehler verhindern die Verifizierung dieser Rolle."
und FEHLER "Die Active Directory-Domänendienste konnten keine Verbindung mit dem globalen Katalog herstellen" mit "Fehlerwer 1355 Die angegebene Domäne ist nicht vorhanden, oder es konnte keine Verbindung herstellt werden" und "Überprüfen Sie, ob der globale Katalog in der Gesamtstruktur verfügbar ist und von diesem Domaincontroller erreicht werden kann. Zur Diagnose können Sie das HIlfsprogram "nltest" verwenden. Die "nltest" Hilfe erzählt mir was von BDC und PDC, das muss so 90er Jahre Windows sein. Dann hab ich noch DFSR Fehler (C:\Windows\SYSVOL\domain), dabei habe ich Serverrolle "DFS-Replikation" aber gar nicht installiert.

Ich konnte mich nicht als lokaler Admin anmelden (wie bei Installation angegeben und zum Hochstufen auf DC), sondern aber als Domain Admin. Ich glaube, das ist normal, es gibt nur noch den von der Domäne. Aber Einstellungen, Ethernet, Adapteroptionen ändern sagt "C:\Windows\System32\control.exe - Auf das angegebene Gerät bzw den Pfad oder die Datei kann nicht zugegriffen werden. Sie verfügen ggf. nicht über ausreichende Berechtigungen, um auf das Element zugreien zu können", wenn ich das control.exe über den explorer Doppelklicke, geht's aber. Bei Ethernet - DNS steht auf dem DC2 127.0.0.1 drin, das ist doch richtig, oder?

Ich habe nur ipv4 internet, sollte ich dann ipv6 auf dem Server erstmal lieber abschalten?

DNS funktioniert jetzt immer und schnell (da war im DNS eine Weiterleitung auf die alte IP drin, die hab ich gelöscht, und ich hab IPv6 abgeschaltet). Der Client wirkt jetzt normal (kann sich anmelden, Internet geht). Auf dem Server keine Änderung. Habe ihn nach der DNS Korrektur neu gestartet, das hat bald 10 Minuten gedauert. Ich habe die AD Fehler immer noch, auch "Alle Verzeichnisdienste am folgenden Standort, die Verzeichnispartitionen replizieren können, sind zur Zeit nicht verfügbar", DFSR Fehler und dass die FSMO Rollen nicht gültig sind.

Ich starte den kaputten Server mal mit dem daily backup von heute nacht. Da war der neue DC ja schon drin, in der Hoffnung, dass es nicht noch schlimmer wird.

Mit dem Nacht-Backup bin ich weitergekommen. Auf dem Restore zeigte netdom query fsmo, das schemamaster auf dem alten lag. Das konnte ich mit Move-ADDirectoryServerOperationMasterRole -Force -Identity dc2 SchemaMaster korrigieren. Nach einem repadmin /syncall und einer kurzen Weile zeigte repadmin /showrepl keine Fehler mehr.

Ich habe mit dcdiag /e leider schlimme Fehler. Zunächst fehlen SYSVOL und Netlogon Freigaben auf dem neuen (Network shares sind beide nicht da, Ordner C:\Windows\SYSVOL\domain ist leer).
Nach langem rumsuchen in Netz und Ereignisanzeige fand ich dann den Hinweis, dass Windows Server 2019 dann nicht mit Windows Server 2012R2 kompatibel ist, wenn dieser schon mal vin was älterem migriert wurde und den Dienst FRS statt DFSR verwendet. Der wird nicht mehr unterstützt. Das soll man mit dem Kommando "dfsrmig /getmigrationstate" rausfinden können, aber das funkioniert nicht:

c:\>dfsrmig /getmigrationstate

Es kann keine Verbindung mit dem PDC-Emulator hergestellt werden. Stellen Sie sicher, dass der
PDC erreichbar ist, und geben Sie den Befehl später erneut ein.

c:\>netdom query fsmo
Schemamaster               dc2.DOM.local
Domänennamen-Master        dc2.DOM.local
PDC                         dc2.DOM.local
RID-Pool-Manager            dc2.DOM.local
Infrastrukturmaster       dc2.DOM.local
Der Befehl wurde ausgeführt.

in "Active Directory-Benutzer und -Computer" unter "Domänencontroller", alter DC, "DFSR-LocalSettings" gibt es aber "Domain System Volume". Dabei habe ich auch über "BurFlags" gelesen. Das ist ja furtchbar. Ich habe unter C:\Windows\debug geguckt und finde keine NTFRS_*. LOG files. Daher hoffe ich, dass ich DFSR habe und keine Migration machen muss.

Für DFSR kann man ein Attribut msDFSR-Options setzen, dessen lange Beschreibung wiedermal typisch überhaupt nichts aussagt ("Das Attribut ms-DFSR-Options ist Teil der DFS-Replikationsdienstunterstützung.").

Ich habe dann AD-Gesamtstrukturwiederherstellung – Ausführen einer autoritativen Synchronisierung von DFSR-replizierten SYSVOL bzw SYSVOL Replikation nach Replikationsfehler wieder anstoßen abgearbeitet und bekam auf dem alten ein

Der DFS-Replikationsdienst hat erkannt, dass wenigstens eine Verbindung für Replikationsgruppe Domain System Volume konfiguriert ist. 
 
Weitere Informationen: 
Replikationsgruppen-ID: E30C8666-79DC-43D3-AEEB-9DC7252A94F6 
Mitglieds-ID: 2884F283-8ADB-4D85-A2D1-5432FA4B9884

und auf dem neuen ein

Der DFS-Replikationsdienst hat SYSVOL im lokalen Pfad "C:\Windows\SYSVOL\domain" initialisiert und  wartet darauf, die erste Replikation auszuführen. Der replizierte Ordner bleibt  im ersten Synchronisierungsstatus, bis er mit seinem Partner DC1.DOM.local repliziert  wurde. Wenn der Server zu einem Domänencontroller heraufgestuft wurde, führt der Domänencontroller keine Ankündigung durch und dient als  Domänencontroller, bis dieses Problem behoben wurde. Dies kann darauf  zurückzuführen sein, dass der angegebene Partner sich selbst in einem  ersten Synchronisierungsstatus befindet. Eine weitere mögliche Ursache  ist, dass auf diesem Server oder beim Synchronisierungspartner  Zugriffsverletzungen aufgetreten sind. Wenn dieses Ereignis bei der Migration  von SYSVOL aus dem Dateireplikationsdienst (FRS) zur DFS-Replikation aufgetreten ist, werden die Änderungen nicht nach außen repliziert, bis dieses  Problem behoben wurde. Dies kann dazu führen, dass der SYSVOL-Ordner auf diesem Server nicht mehr mit anderen Domänencontrollern synchron ist.    
  
Weitere Informationen:  
Name des replizierten Ordners: SYSVOL Share 
ID des replizierten Ordners: 36AD4534-4695-47CF-8694-2CDE82B6569C 
Replikationsgruppenname: Domain System Volume 
Replikationsgruppen-ID: E30C8666-79DC-43D3-AEEB-9DC7252A94F6 
Mitglieds-ID: 432C7204-F828-464E-AA39-96DCBDC794A3 

und SYSVOL/domain ist nach wie vor leer.

Was kann ich tun?

Jetzt hatte ich den neuen nochmal gestartet, und jetzt gibt es die DNS Fehler wieder, beispielsweise sagt dcdiag:

      Starting test: Replications
         [Replications Check,DC2] Bei einer kürzlich ausgeführten Replikation ist ein Fehler aufgetreten:
            Von DC1 nach DC2
            Namenskontext: DC=ForestDnsZones,DC=DOM,DC=local
            Beim Replizieren ist ein Fehler aufgetreten (8524):
            Ein DSA-Vorgang kann aufgrund eines DNS-Aufruffehlers nicht fortgesetzt werden.
            Auftreten des Fehlers: 2023-07-07 21:54:38.
            Letzter erfolgreicher Vorgang: 2023-07-07 21:34:17.
            Seit dem letzten erfolgreichen Vorgang sind 1 Fehler aufgetreten.
            Der GUID-basierte DNS-Name 1b990fcb-1494-478b-b2c3-e15162766a79._msdcs.DOM.local
            ist auf mindestens einem DNS-Server nicht registriert.

Aber der Name kann aufgelöst werden:

PS C:\Windows\system32> nslookup
Standardserver:  localhost
Address:  127.0.0.1

> 1b990fcb-1494-478b-b2c3-e15162766a79._msdcs.DOM.local
Server:  localhost
Address:  127.0.0.1

Name:    DC1.DOM.local
Address:  192.168.101.10
Aliases:  1b990fcb-1494-478b-b2c3-e15162766a79._msdcs.DOM.local

und während ich das geschrieben habe, hat sich das VON ALLEIN wieder komplett geändert:

      Starting test: Replications
         ......................... DC2 hat den Test Replications bestanden.

Was ist denn da los?!

Hi,
wieso zu Geier erlaubt man, dass ein Server - gar ein DC - WSUS-Updates allein automatisch installiert und dann auch noch automatisch bootet?! Selbst schuld, sorry. Für sowas habe ich kein Verständnis.

Schemamaster ist unkititisch und nicht für die beschriebenen Probleme relevant.
Streng genommen braucht man für das Anmelden der Clients und Benutzer überhaupt keine der FSMO. Einzig der Gobal Catalog ist wichtig, wenn sich ein Benutzer zum ersten Mal an einem bestimmten Client anmeldet. (wenn er noch nie an diesem Client angemeldet war, kein lokales Profil vorhanden ist)
Ist der neue DC auch Global Catalog? Wenn nein --> aktivieren!

Dass der neue DC beim Neustart lange gebraucht hat, ist nicht ungewöhnlich, weil er zu diesem Zeiotpunkt der einzige laufende (startende) DC war, wenn ich das richtig verstanden habe. --> Inseleffekt

Der neue DC sollte sich selbst als 1. DNS-Server eingetragen haben. Und den alten DC/DNS würde ich ihm entfernen, weil dieser nicht mehr zuverlässig läuft.
Dann dem alten DC den neuen DC/DNS als 1. DNS-Server eintragen, sich selbst als 2.

Ich würde schnellstens einen dritten DC promoten (irgendwo als VM) und dann den alten DC demoten.
Dem 3. DC den 2. als 1. DNS-Server eintragen und sich selbst als 2.

E.

Zitat von @emeriks:
wieso zu Geier erlaubt man, dass ein Server - gar ein DC - WSUS-Updates allein automatisch installiert und dann auch noch automatisch bootet?! Selbst schuld, sorry. Für sowas habe ich kein Verständnis.

Das kann ich nicht beantworten. Wende Dich doch bitte direkt an BSI, LSI Bayern (Punkt 2.3.4) oder Fefe ("Wieviel Zeit habt ihr für das Einspielen der Patches? 24h. Nach initialer Verfügbarkeit des Patches. Nicht nachdem ihr ihn zuerst wahrnehmt"), die können das sicher besser erklären.

Schemamaster ist unkititisch und nicht für die beschriebenen Probleme relevant.
Streng genommen braucht man für das Anmelden der Clients und Benutzer überhaupt keine der FSMO. Einzig der Gobal Catalog ist wichtig, wenn sich ein Benutzer zum ersten Mal an einem bestimmten Client anmeldet. (wenn er noch nie an diesem Client angemeldet war, kein lokales Profil vorhanden ist)
Ist der neue DC auch Global Catalog? Wenn nein --> aktivieren!

Ja, ist er.

Dass der neue DC beim Neustart lange gebraucht hat, ist nicht ungewöhnlich, weil er zu diesem Zeiotpunkt der einzige laufende (startende) DC war, wenn ich das richtig verstanden habe. --> Inseleffekt
Der neue DC sollte sich selbst als 1. DNS-Server eingetragen haben. Und den alten DC/DNS würde ich ihm entfernen, weil dieser nicht mehr zuverlässig läuft.
Dann dem alten DC den neuen DC/DNS als 1. DNS-Server eintragen, sich selbst als 2.

Ja, das hab ich. DNS funktioniert augenscheinlich.

Ich würde schnellstens einen dritten DC promoten (irgendwo als VM) und dann den alten DC demoten.
Dem 3. DC den 2. als 1. DNS-Server eintragen und sich selbst als 2.

Der würde doch auch an der fehlenden SYSVOL Replikation hängen bleiben :/

Ich habe die Force-Sync-Anleitung nochmal gemacht, und zwar gaaanz langsam. In der Ereignisanzeige finde ich dann:

Der DFS-Replikationsdienst hat die Replikation für den replizierten Ordner unter dem lokalen Pfad "C:\Windows\SYSVOL\domain" beendet.   
 
Weitere Informationen: 
Fehler: 9003 (Die Replikationsgruppe ist ungültig.) 
Weiterer Kontext des Fehlers:   
Name des replizierten Ordners: SYSVOL Share 

Ich habe C:\Windows\debug\Dfsr00020.log gefunden mit folgenden Meldungen:

20230712 18:33:45.817 6776 SCFS  1479 [WARN] ServiceConfig::ProcessAdPollConfigEvents [CLUSTER] (Ignored) Skip processing cluster cleanup because VCO list was not valid. This step will be retried at next poll.
20230712 18:33:46.024 8924 CSMG  5699 [ERROR] ContentSetManager::CheckContentRoot Failed. The database contains stale content. csId:{36AD4534-4695-47CF-8694-2CDE82B6569C} csName:SYSVOL Share rootPath:C:\Windows\SYSVOL\domain state:Normal ptr:0000002156D51400 csInfoHistoryGuid:{C581690E-618F-46AF-B0A6-48794C666F42}
20230712 18:33:46.025 8924 CSMG  8424 [ERROR] ContentSetManager::Initialize Failed to initialize ContentSetManager csId:{36AD4534-4695-47CF-8694-2CDE82B6569C} csName:SYSVOL Share rootPath:C:\Windows\SYSVOL\domain state:Normal ptr:0000002156D51400 csInfoHistoryGuid:{C581690E-618F-46AF-B0A6-48794C666F42} Error:
+	[Error:9003(0x232b) ContentSetManager::CheckContentRoot contentsetmanager.cpp:5758 8924 C Die Replikationsgruppe ist ungültig.]
+	[Error:9003(0x232b) ContentSetManager::CheckContentRoot contentsetmanager.cpp:5702 8924 C Die Replikationsgruppe ist ungültig.]
20230712 18:33:46.131 12052 JRWP   464 [WARN] JournalWrapTask::Process (Ignored) Unable to recover content set. Root record not found. csId:{36AD4534-4695-47CF-8694-2CDE82B6569C} csRootUid:{36AD4534-4695-47CF-8694-2CDE82B6569C}-v1 volId:{787E479B-EEDE-11EB-8297-806E6F6E6963} volPath:\\.\C:
20230712 18:34:46.027 12052 CSMG  5699 [ERROR] ContentSetManager::CheckContentRoot Failed. The database contains stale content. csId:{36AD4534-4695-47CF-8694-2CDE82B6569C} csName:SYSVOL Share rootPath:C:\Windows\SYSVOL\domain state:Normal ptr:0000002156D51400 csInfoHistoryGuid:{C581690E-618F-46AF-B0A6-48794C666F42}
20230712 18:34:46.027 12052 CSMG  8424 [ERROR] ContentSetManager::Initialize Failed to initialize ContentSetManager csId:{36AD4534-4695-47CF-8694-2CDE82B6569C} csName:SYSVOL Share rootPath:C:\Windows\SYSVOL\domain state:Normal ptr:0000002156D51400 csInfoHistoryGuid:{C581690E-618F-46AF-B0A6-48794C666F42} Error:
+	[Error:9003(0x232b) ContentSetManager::CheckContentRoot contentsetmanager.cpp:5758 12052 C Die Replikationsgruppe ist ungültig.]
+	[Error:9003(0x232b) ContentSetManager::CheckContentRoot contentsetmanager.cpp:5702 12052 C Die Replikationsgruppe ist ungültig.]
20230712 18:36:46.028 12052 CSMG  5699 [ERROR] ContentSetManager::CheckContentRoot Failed. The database contains stale content. csId:{36AD4534-4695-47CF-8694-2CDE82B6569C} csName:SYSVOL Share rootPath:C:\Windows\SYSVOL\domain state:Normal ptr:0000002156D51400 csInfoHistoryGuid:{C581690E-618F-46AF-B0A6-48794C666F42}
20230712 18:36:46.028 12052 CSMG  8424 [ERROR] ContentSetManager::Initialize Failed to initialize ContentSetManager csId:{36AD4534-4695-47CF-8694-2CDE82B6569C} csName:SYSVOL Share rootPath:C:\Windows\SYSVOL\domain state:Normal ptr:0000002156D51400 csInfoHistoryGuid:{C581690E-618F-46AF-B0A6-48794C666F42} Error:
+	[Error:9003(0x232b) ContentSetManager::CheckContentRoot contentsetmanager.cpp:5758 12052 C Die Replikationsgruppe ist ungültig.]
+	[Error:9003(0x232b) ContentSetManager::CheckContentRoot contentsetmanager.cpp:5702 12052 C Die Replikationsgruppe ist ungültig.]
2

Ich habe nach den Meldungen gegoogelt, aber nichts passendes gefunden.

Wie mache ich jetzt am besten weiter?

Ich habe über einen Link in einem Microsoft-Artikel "Import the SYSVOL Folder Structure" in einem langen Artikel gefunden, das erscheint mir sehr alt.
How to rebuild the SYSVOL tree and its content in a domain ist recht neu (02/23/2023), inhaltlich aber wohl uralt (beschreibt nur FRS, nicht DFSR). Leider finde ich nichts zu DFS replizierten SYSVOL.

Das Problem ist, dass der neue DC nicht aktiv wird:

   Server wird getestet: DC2
      Starting test: Advertising
         Achtung: Bei dem Versuch, DC2 zu erreichen, wurden von DsGetDcName Informationen für \\OLDDC.DOM.local
         zurückgegeben.
         DER SERVER REAGIERT NICHT oder GILT ALS UNGEEIGNET.
         ......................... Der Test Advertising für DC2 ist fehlgeschlagen.
...
      Starting test: NetLogons
         Die Verbindung mit der NETLOGON-Freigabe kann nicht hergestellt werden. (\\DC2\netlogon)
         [DC2] Bei einem Vorgang vom Typ "net use" oder "LsaPolicy" ist der Fehler 67 aufgetreten,  
         Der Netzwerkname wurde nicht gefunden..
         ......................... Der Test NetLogons für DC2 ist fehlgeschlagen.
      Starting test: ObjectsReplicated
         ......................... DC2 hat den Test ObjectsReplicated bestanden.
      Starting test: Replications
         [Replikationsüberprüfung, DC2] Fehler bei DsReplicaGetInfo(PENDING_OPS, NULL): 0x2105
         "Der Replikationszugriff wurde verweigert."  
         ......................... Der Test Replications für DC2 ist fehlgeschlagen.
...
      Starting test: Services
            Der Dienst NTDS auf DC2 konnte nicht geöffnet werden. Fehler: 0x5 "Zugriff verweigert"  
         ......................... Der Test Services für DC2 ist fehlgeschlagen.

Ich bin für jeden Tip dankbar!

Kannst du einmal ein aktuelles Bild von deinen DNS Settings skizzieren? Wer macht was und hat nun was als DNS Server bzw Weiterleitung wo eingetragen?

Hast du einen der DCs umbenannt?

VG

Bzgl. SYSVOL
Du solltest dieses als erstes mal vom alten DC als Dateikopie sichern. Am besten mit Robocopy incl. Berechtigungen.
Egal wohin, Hauptsache auf einen anderen Server. Das könnte z.B. eine extra Freigabe auf dem neuen DC sein.
Damit hättest Du das NETLOGON-, sofern bei Euch da was drin ist, und das Policies-Verzeichnis als Kopie gesichert.

"gilt als ungeeignet"
Dass der neue DC so gemeldet wird ist im Sinne des von Dir Beschriebenen richtig. Ein DC betrachtet sich selbst als nicht voll funktionstüchtig, solange er nicht min. einmal das SYSVOL erfolgreich repliziert und danach automatisch die Freigaben "SYSVOL" und "NETLOGON" erstellt hat. (Diese Freigaben sollte man auf keinen Fall manuell erstellen!)

Die NTFRS-Einstellung blockiert absichtlich die Installation von Windows Server-Replikat-DCs
Der neue DC hat welche Server-Version?
Hat der alte DC das SYSVOL noch für NtFRS eingerichtet oder schon für DFS-R? Falls noch NtFRS, dann muss der neue DC entweder < Win2016 sein oder auf dem alten DC vor dem Promoten eines weiteren DC auf DFS-R umgestellt werden. Die Migrationsschritte dafür sind im o.g. Artikel verlinkt.

Danke erstmal für eure neuen Antworten!

Zitat von @Tezzla:
Kannst du einmal ein aktuelles Bild von deinen DNS Settings skizzieren? Wer macht was und hat nun was als DNS Server bzw Weiterleitung wo eingetragen?

Es gibt eine Forward- und eine Reversezone. Da stand vorher der (einzige) DC-alt (2012R2) drin. Ich hatte dann dc2 (neu) statisch hinzugefügt, den dc2 die entsprechende IP statisch konfiguriert und sicherheitshalber auch eine DHCP lease reserviert (die nicht benutzt wird, der dc2 hat statische IP Konfiguration).
Dann hatte ich auf dc2 Windows Server 2019 Standard installiert und DC Rolle hinzugefügt. Da bin ich gefragt worden, ob er DNS Authorisierung machen soll und das habe ich gemacht.
Jetzt haben beide (dc-alt und dc2) die beiden Zonen. Beide antworten auf Requests beider Zonen.
Im Netzadapter sind bei dc-alt statische IP und die eigene IP als bevorzugter und die IP des neuen dc2 als alternativer DNS Server eingetragen. Im neuen ist nur bevorzugt mit 127.0.0.1 eingetragen. Bei beiden ist nur IPv4 an (IPv6 ist nicht angehakt).
nslookup auf beiden Servern funktioniert für "nslookup DC dc2", umgekehrt, mit IP von alt und neu, und Reverse-Lookup der IP (ja, ich habe alle 16 nslookup Aufrufe gemacht). Auf Clienten das gleiche. Internetnamen werden auch aufgelöst (auf den Servern und dem Clienten). Auf einem Linux-Clienten kriege ich mit "dig soa DOM.loc @dc" von alt und neu Antwort. Der einzige Unterschied ist, dass SOA beim alten der alte und beim neuen der neue ist. Es sind beide als NS eingetragen, IPs stimmen, Client löst alles auf.
Ich habe testweise auf dem alten Zone Seriennummer Inkrement gemacht, dann sicherheitshalber ein repadmin /syncall und repadmin /showrepl (beide melden Erfolg) und dann mit "dig soa" sowohl vom alten als auch vom neuen die neue, inkrementierte Seriennummer bekommen.
Der alte hat als Weiterleitung die IP der Firewall drin (da ist ein DNS resolver drauf), der neue hat keine Weiterleitung (nur Stammhinweise).
Beim Abarbeiten von Testschritten aus dem Internet gab es auch öfter, dass man kryptische _msdcs... Namen mit nslookup auflösen sollte, die haben auch alle geklappt.

dcdiag /test:dns bestehen beide Server "DOM.loc hat den Test DNS bestanden.". Beide melden "Warning: Failed to delete the test record dcdiag-test-record". Der neue meldet zusätzlich "PTR record query for the 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa failed on the DNS server 2001:503:ba3e::2:30" für augenscheinlich jeden Stammhinweise-Server. Das ist m.E. korrekt, denn "2001:503:ba3e::2:30" kann nicht erreicht werden, weil es kein IPv6 gibt (auf den Servern und auch auf der Firewall nicht aktiv). Auflösung von Internetnamen geht, über localhost und über externe IPv4 IPs (8.8.8.8) (also "nslookup administrator.de 127.0.0.1" usw).

Kann ich noch was testen?

Hast du einen der DCs umbenannt?

Nein, ich versuche, einen neuen (dc2) hinzuzufügen (gab vorher nur einen), weil der alte DC kaputt ist (beim Reboot möchte chkdsk laufen, wenn ich das nicht Überspringe, ist es nicht mehr bootfähig).
Leider klappt die initiale Replikation von SYSVOL und netlogon nicht, daher wird der neue nicht richtig aktiv und ich kann den alten nicht runterstufen (also ich hab es nicht mal probiert).

Zitat von @emeriks:

Bzgl. SYSVOL
Du solltest dieses als erstes mal vom alten DC als Dateikopie sichern. Am besten mit Robocopy incl. Berechtigungen.

OK, das habe ich gemacht (und habe auch ältere Stände).
In Netlogon (also sysvol/scripts) liegen nur mini Batchfiles, die ein paar Laufwerke mappen.
Im Policies liegen einige Dateien (33,7 KB, 23 Dateien, 59 Ordner).
Gibt hier nur ca. 5 User und 10 Computer (aber terabyteweise Daten).

Egal wohin, Hauptsache auf einen anderen Server. Das könnte z.B. eine extra Freigabe auf dem neuen DC sein.
Damit hättest Du das NETLOGON-, sofern bei Euch da was drin ist, und das Policies-Verzeichnis als Kopie gesichert.

Ja, danke, das habe ich.
Aber der neue DC möchte unbedingt eine initiale DFS Replikation machen und man darf die SYSVOL Dateien ja nicht selbst kopieren oder auch nur die Shares anlegen.

"gilt als ungeeignet"
Dass der neue DC so gemeldet wird ist im Sinne des von Dir Beschriebenen richtig. Ein DC betrachtet sich selbst als nicht voll funktionstüchtig, solange er nicht min. einmal das SYSVOL erfolgreich repliziert und danach automatisch die Freigaben "SYSVOL" und "NETLOGON" erstellt hat. (Diese Freigaben sollte man auf keinen Fall manuell erstellen!)

Ja danke, das habe ich auch gelesen. Ich glaube, genau an dem Punkt hänge ich. Auf dem alten wird das SYSVOL nicht "gesendet" (der Fehler "Der DFS-Replikationsdienst hat die Replikation für den replizierten Ordner unter dem lokalen Pfad "C:\Windows\SYSVOL\domain" beendet." kommt alle 8 Stunden), daher kann der neue nichts "empfangen" und wartet und wartet.

Hier komme ich leider nicht weiter.

Die NTFRS-Einstellung blockiert absichtlich die Installation von Windows Server-Replikat-DCs
Der neue DC hat welche Server-Version?
Hat der alte DC das SYSVOL noch für NtFRS eingerichtet oder schon für DFS-R? Falls noch NtFRS, dann muss der neue DC entweder < Win2016 sein oder auf dem alten DC vor dem Promoten eines weiteren DC auf DFS-R umgestellt werden. Die Migrationsschritte dafür sind im o.g. Artikel verlinkt.

Der Fehler "Der DFS-Replikationsdienst hat die Replikation für den replizierten Ordner unter dem lokalen Pfad "C:\Windows\SYSVOL\domain" beendet" steht in der Ereignisanzeige unter "Anwendungs- und Dienstprotokoll", "DFS-Replikation". Das kann meines Verständnisses nach nur DFS-R sein. Die Debug Log Datei heißt "Dfsr00020.log". Das in den Anleitungen beschriebene "DFSRMIG.EXE /GetMigrationState" meldet, dass er keine Verbindung zum Emulator herstellen kann. Nach den Texten hat Windows 2012 unter Umständen einen FRS Emulator (nämlich nach einem Update von Server älter 2008), den man dann mit DFSRMIG zu DFS migrieren kann. Meines Verständnisses nach ist das bei meinem aber nicht der Fall, ich glaube, ich habe kein FRS, sondern ein kaputtes DFS-R.

Der alte ist 2012R2, der neue 2019.

In Ermangelung einer besseren Idee habe ich heute den Tag damit verbracht, das SYSVOL vom Dateisystem C: auf D: zu verschieben. Dazu gibt es eine ausführliche Anleitung von Microsoft. Ich habe jeden Schritt sorgfältig dokumentiert und geprüft und es hat von Anfang an alles perfekt geklappt. Im allerletzten Schritt sollte man dann DFSR neustarten und auf Ereignis-IDs im Eventlog schauen "Event IDs 4604 and 6018, which indicate success.". Alle genannten kamen, bis auf diese beiden. Es kam aber auch kein Fehler mehr. Ich sollte auch die SYSVOL Share mit "net share" prüfen, die fehlt auch. Es gibt ein paar Tips zu falsch gesetzten Rechten, die habe ich gepüft, da ist nichts falsches zu finden. in C:\WINDOWS\DEBUG\dfsr00012.log stehen Fehler wie beispielsweise "Config::DsDcInfo::QueryDcInfo Failed to DsGetDcName(). computerName:<null> domainName:<null> siteName:<null> Error:1355".

Rückgängig machen kann ich es auch nicht, weil ADSI Edit jetzt nicht mehr aufgeht: jetzt gibt's die Domain nicht mehr. Inzwischen meldet auch dcdiag Bildschirmseitenweise Fehler, alles kaputt. Nur DNS scheint richtig, die notwendigen Namen werden aufgelöst.

Ich glaube, nun habe ich zwei Domain Controller, die auf eine Replikation warten.

Und das ganze wegen ein paar Kilobyte GPO.

Ich habe immer noch keine Idee, wie ich weitermachen könnte. Hat jemand einen Tipp?

OHH MEIN GOTT ICH GLAUB ICH HABS!

Nachdem alles kaputt aussah, machte ich vor der erneuten Backup-Rücksicherung noch mal einen anderen Versuch. Die oben beschriebene Anleitung sagt ziemlich zu Anfang im Schritt "Change the SYSVOL Netlogon Parameters", dann man "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters" den Key "SysvolReady" auf "0" setzen soll. Ziemlich zu Ende, in Schritt "Change the SYSVOL Netlogon Parameters" soll man den gleichen Key wieder auf "0" setzen. Hab ich gemacht, weil es da so steht. Dann war alles kaputt.

Nun habe ich folgendes gemacht: ich habe wieder die Dienste dfsr und netlogon gestoppt und zwar auf allen beiden DCs. Dann habe ich entgegen der Anleitung HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters" den Key "SysvolReady" auf "1" gesetzt. Dann habe ich die Anleitung "Durchführen einer autoritativen Synchronisierung der DFSR-replizierten Sysvol-Replikation (z. B. D4 für FRS)" (also den zweiten Teil") durchgeführt (das mit dem D4 und FRS ist Quark, da geht es in DFS, nicht um FRS, so richtig liebevoll sind die Microsoft-Artikel jetzt leider auch nicht).

Dies führte insgesamt dazu, dass der alte Domaincontroller seinem eigenen SYSVOL wieder "geglaubt" hat (ich bin mir recht sicher, dass das durch "SysvolReady" gesteuert wird, andeutungsweise hier). Durch die "gleichzeitig" erzwungene autoritative Synchronisierung hat er das dann an den neuen übertragen. Der hat damit endlich seine initiale Synchronisierung bekommen (steht auch in der Ereignisanzeige) und ist ENDLICH "Advertising"!

Ich habe einen Clienten neu gestartet, kann ich anmelden und "echo %LOGONSERVER%" nennt mir jetzt den neuen Domain Controller!

dcdiag meldet jetzt alle Tests bestanden bis auf "SystemLog", der zwei Fehler mit Zeitstempel vor der erzwungenen autoritativen Synchronisierung zeigt und der Warnung "Für den Zeitraum der letzten 24 Stunden seit Freigabe des SYSVOL sind Warnungen oder Fehlerereignisse vorhanden. Fehler bei der SYSVOL-Replikation können Probleme mit der Gruppenrichtlinie zur Folge haben.". Das ist hier sicher OK, denn es geht ja erst seit einer halben Stunde

Puhh bin ich froh, ich glaube, ich habe es geschafft!
(hoffentlich freue ich mich nicht wieder zu früh!)

German solved Question Windows Server

Hotly discussed

Windows zero-day vulnerability CVE-2024-30051firefly

VMware Desktop Hypervisor Pro Apps now available free for personal usehempel