12
Prüfen bzw. Abgleichen der AD "Konsistenz"
Hey,
Vorwort:
wir haben eine 2016er Domäne und waren nun seit Ende 2023 bis heute damit beschäftigt irgendwie einen DC auf 2019 bzw. 2022 an laufen zu bekommen. (siehe auch Anmeldung an neuem DC schlägt fehl )
Damals war bereits die Vermutung dass es am fehlenden PasswortContainer CN=Password Settings Container lag. Allerdings war damals bei MS nicht genau beschrieben was zu tun ist, damit dieser nachträglich angelegt werden kann und meine Kenntnise für ADSI reichen nicht aus.
Nun habe ich mir mal wieder die Zeit genommen das Problem nochmal anzugehen bzw. wollte das Problem genau dokumentieren damit wir Hilfe bei echten AD-Experten hätten suchen können.
Netterweise hat MS seine ursprüngliche Anleitung nun (Januar 2025) detailierter gestaltet und ich war in der Lage den Container neu anzulegen.
Nun sieht es so aus als hätten wir das Problem beheben können, der neue DC 2022 läuft!
So und nun zu meiner eigentlichen Frage:
Gibt es irgendwelche Möglichkeiten zu prüfen ob die AD-Struktur auch tatsächlich "konsistent" ist. Sprich ob unsere Struktur der einer neuen 2016er Domäne entspricht?
Den üblichen eingebauten Tools schien nicht aufgefallen zu sein, dass der Container fehlt...
Unsere Domäne ist schon weit über 20 Jahre alt und vielleicht gibt es ja noch mehr versteckte Fehler...
Grüße
Vorwort:
wir haben eine 2016er Domäne und waren nun seit Ende 2023 bis heute damit beschäftigt irgendwie einen DC auf 2019 bzw. 2022 an laufen zu bekommen. (siehe auch Anmeldung an neuem DC schlägt fehl )
Damals war bereits die Vermutung dass es am fehlenden PasswortContainer CN=Password Settings Container lag. Allerdings war damals bei MS nicht genau beschrieben was zu tun ist, damit dieser nachträglich angelegt werden kann und meine Kenntnise für ADSI reichen nicht aus.
Nun habe ich mir mal wieder die Zeit genommen das Problem nochmal anzugehen bzw. wollte das Problem genau dokumentieren damit wir Hilfe bei echten AD-Experten hätten suchen können.
Netterweise hat MS seine ursprüngliche Anleitung nun (Januar 2025) detailierter gestaltet und ich war in der Lage den Container neu anzulegen.
Nun sieht es so aus als hätten wir das Problem beheben können, der neue DC 2022 läuft!
So und nun zu meiner eigentlichen Frage:
Gibt es irgendwelche Möglichkeiten zu prüfen ob die AD-Struktur auch tatsächlich "konsistent" ist. Sprich ob unsere Struktur der einer neuen 2016er Domäne entspricht?
Den üblichen eingebauten Tools schien nicht aufgefallen zu sein, dass der Container fehlt...
Unsere Domäne ist schon weit über 20 Jahre alt und vielleicht gibt es ja noch mehr versteckte Fehler...
Grüße
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: 671617
Url: https://administrator.de/forum/pruefen-bzw-abgleichen-der-ad-konsistenz-671617.html
Ausgedruckt am: 29.03.2025 um 02:03 Uhr
12 Kommentare
Neuester Kommentar
Hallo,
was war denn die Basis damals, SBS?
was war denn die Basis damals, SBS?
Also die 2008er Domäne war auf jeden Fall kein SBS. Ob die davor kann ich nicht mehr nachvollziehen fürchte ich.
dcdiag, repladmin und mit ntdsutil die laichen löschen.
In der NTDS.dit etwas "defektes" wieder konsistent zu bekommen klappt i.d. Regel nur mit recovery oder neuinstallation. Wobei es Tools geben soll die das können.
Fehler dahingehend werden i.d. Regel im Ereignislog protokolliert.
Es sollte immer ein DC auf eigenem Blech mit den vm's mitlaufen.
In der NTDS.dit etwas "defektes" wieder konsistent zu bekommen klappt i.d. Regel nur mit recovery oder neuinstallation. Wobei es Tools geben soll die das können.
Fehler dahingehend werden i.d. Regel im Ereignislog protokolliert.
Es sollte immer ein DC auf eigenem Blech mit den vm's mitlaufen.
Die Aussage ist wirklich aus dem letzten Jahrhundert.
Kenne keinen der noch einen extra DC auf Blech laufen hat, nur weil es ein DC ist.
Edit: Abgesehen davon dass es unnütz Lizenzen kostet
2
Im Wesentlichen Obacht auf die Logs geben und diese ggf. einmal alle quer anschauen, ob da etwas Auffälliges steht. Wenn sonst nichts zu sehen ist und auch im Alltag kein negatives Feedback kommt, dann wird es schon passen.
Erfahrungsgemäß die meisten Probleme kommen eigentlich auf bei Plattformwechsel, Hybridstellungen oder von local to cloud.
Erfahrungsgemäß die meisten Probleme kommen eigentlich auf bei Plattformwechsel, Hybridstellungen oder von local to cloud.
Zitat von @Delta9:
Die Aussage ist wirklich aus dem letzten Jahrhundert.
Kenne keinen der noch einen extra DC auf Blech laufen hat, nur weil es ein DC ist.
Die Aussage ist wirklich aus dem letzten Jahrhundert.
Kenne keinen der noch einen extra DC auf Blech laufen hat, nur weil es ein DC ist.
Früher oder später lernt es jeder, auch die aus dem "neuen" Jahrhundert ;)
Zitat von @user217:
Früher oder später lernt es jeder, auch die aus dem "neuen" Jahrhundert ;)
Zitat von @Delta9:
Die Aussage ist wirklich aus dem letzten Jahrhundert.
Kenne keinen der noch einen extra DC auf Blech laufen hat, nur weil es ein DC ist.
Die Aussage ist wirklich aus dem letzten Jahrhundert.
Kenne keinen der noch einen extra DC auf Blech laufen hat, nur weil es ein DC ist.
Früher oder später lernt es jeder, auch die aus dem "neuen" Jahrhundert ;)
Bin zwar auch aus dem letzten Jahrhundert bzw Jahrtausend und kenne es aus den Anfangszeiten der Virtualisierung noch einen DC auf Blech laufen zu lassen.
Vielleicht magst du ja die Vorteile eines "DC's auf Blech" erläutern.
1
Die Grundidee hinter DC auf Blech kann man eigentlich nur mit Abhängigkeiten des Hypervisors begründen. Da wird aber häufig nicht mehr wirklich nachgedacht sondern das hat sich als Grundsatz einfach etabliert. Ich habe das nie gemacht, ich kann mich auch so an esxi anmelden.
Wenn das storage wg. hardwarefehler abkackt und die ganze vm gaudi inkonsistent wird und der lehrbub zeitgleich das veeam repo vollhaut so das keine konsistente aktuelle rücksicherung mehr möglich ist, ist man mega froh über sowas ;)
Zitat von @ukulele-7:
Die Grundidee hinter DC auf Blech kann man eigentlich nur mit Abhängigkeiten des Hypervisors begründen. Da wird aber häufig nicht mehr wirklich nachgedacht sondern das hat sich als Grundsatz einfach etabliert. Ich habe das nie gemacht, ich kann mich auch so an esxi anmelden.
Die Grundidee hinter DC auf Blech kann man eigentlich nur mit Abhängigkeiten des Hypervisors begründen. Da wird aber häufig nicht mehr wirklich nachgedacht sondern das hat sich als Grundsatz einfach etabliert. Ich habe das nie gemacht, ich kann mich auch so an esxi anmelden.
Genau so haben wir es die letzten 15 Jahre auch gemacht. ESX Hochfahren, VCenter anwerfen, DC'S starten und ab die Post.
Wir sind also 15 Jahre ohne physichn DC ohne Probleme klar gekommen.
Zitat von @user217:
Wenn das storage wg. hardwarefehler abkackt und die ganze vm gaudi inkonsistent wird und der lehrbub zeitgleich das veeam repo vollhaut so das keine konsistente aktuelle rücksicherung mehr möglich ist, ist man mega froh über sowas ;)
Wenn das storage wg. hardwarefehler abkackt und die ganze vm gaudi inkonsistent wird und der lehrbub zeitgleich das veeam repo vollhaut so das keine konsistente aktuelle rücksicherung mehr möglich ist, ist man mega froh über sowas ;)
Dann ist im Vorfeld alles schiefgelaufen was schieflaufen kann.
Natürlich sollten beide DC's nicht auf der selben Hardware laufen. Also eigene ESXer und eigene Storages.
Zur Not bei einem ESX den lokalen Datastore missbrauchen.
und wenn man nur ein Storage hat dann hat man eh andere Probleme.
Und wenn man nur ein Veeam Repo hat dann hat man noch nichts von der " 3-2-1 Regel" gehört.
1
Alternativ Veeam nicht in die Domäne mit aufnehmen bzw. nichts von der Domäne abhängig machen. Ist bei mir auch in der Domain, das wollte ich bei der nächsten Neuinstallation auch anders machen, müsste eigentlich gehen.
1
