Es gibt jede Menge Verwaltungsliteratur, die sich mit der ordnungsgemäßen Verwaltung von Windows-Servern befasst. Aber im wirklichen Leben laufen die Dinge nicht immer so, wie man es sich wünscht. In Microsofts Windows Server 2003 Administrator's Companion konnte ich von über 1400 Seiten nur eine Seite finden, in der es um die Einrichtung zusätzlicher Domänencontroller geht. Sie lassen es nahtlos klingen und verraten nicht viel darüber, was passiert, wenn „Peer“-DCs nicht repliziert werden können.
Um auf das konkrete Problem einzugehen: Vor etwa einem Monat ist ein DC aufgrund eines fehlerhaften RAID-Controllers ausgefallen. Es gab nichts Kritisches, das sofortige Aufmerksamkeit erfordert hätte, also wurde die Wiederherstellung auf die lange Bank geschoben. Einen Monat später haben wir den DC wieder zum Laufen gebracht und alles schien in Ordnung zu sein. Am nächsten Tag kann sich niemand mehr anmelden und sich beschweren, dass der"Benutzer existiert nicht"oder„Es konnte keine Vertrauensbeziehung aufgebaut werden“. Da ich wusste, dass ich den ausgefallenen DC gerade wieder ins Netzwerk gebracht hatte, nahm ich ihn sofort wieder vom Netzwerk und ließ alle die Arbeitsstationen neu starten. Danach funktionierte der Austausch einwandfrei, Freigaben wurden verfügbar und alle konnten sich anmelden. Nachdem ich ein wenig im Ereignisprotokoll herumgestöbert hatte, schien alles aufgrund von Replikationsproblemen auf dem SYSVOL gestartet zu sein. Ich habe gelesen, dass man die Replikation erzwingen kann, aber das würde bedeuten, ihn wieder ins Netzwerk zu bringen. Ich habe Angst, den DC wieder ins Netzwerk zu bringen, weil ich befürchte, dass noch etwas schiefgehen könnte. Welche anderen Probleme könnten also auftreten, wenn zwei DCs über einen Monat lang nicht repliziert werden?
Antwort1
Abhängig von der Dauer der Nichtsynchronisierung kann es passieren, dass einer von ihnen seineTombstone-LebensdauerDanach treten Probleme auf, wenn gelöschte Objekte wieder zum Leben erwachen. Allerdings beträgt die Mindeststandardzeit 60 Tage, sodass es kein Problem sein sollte, wenn weniger Zeit vergangen ist.
AD (und DNS und eine Vielzahl anderer Dienste) gehen mit Synchronisierungsproblemen um, indem bei jeder Änderung eine Seriennummer erhöht wird. Wenn Sie also PRIMARYDCÄnderungen vorgenommen haben, SECONDARYDCwird eine niedrigere Nummer angezeigt und die höhere Nummer wird verwendet.
Wenn Sie WIRKLICH besorgt sind, können Sie SECONDARYDCes immer löschen, manuell aus Active Directory entfernen, ein neues Image erstellen und es dann elegant zu einem anderen DC hochstufen. Ich denke jedoch, dass Sie sicher sind, wenn Sie es online bringen und Ihre SYSVOL-Probleme lösen. Wenn Sie besonders paranoid sein möchten, tun Sie es nach Feierabend, damit es beim Lösen von SYSVOL nicht zu Inkonsistenzen kommt.
BEARBEITEN Adaptr macht unten einen guten Punkt – stellen Sie sicher, dass keine FSMO-Rollen zugewiesen sind, SECONDARYDCbevor Sie es löschen, wenn Sie sich für diesen Weg entscheiden.