Herabgestufter Domänencontroller noch in Domänencontroller-OU und AD-Sites & -Dienste

Herabgestufter Domänencontroller noch in Domänencontroller-OU und AD-Sites & -Dienste

Ich habe alles Folgende getan, während ich als Domänenadministrator angemeldet war.

Ich hatte zwei AD-Sites, jede mit ihrem eigenen Domänencontroller. Der „Backup“-Domänencontroller war über ein Site-to-Site-VPN verbunden, der gesamte Datenverkehr war zugelassen und er war der EINZIGE Server in dieser AD-Site/diesem AD-Subnetz. Da mir klar wurde, dass es sinnlos war, diesen Domänencontroller ganz allein in seinem eigenen Subnetz über ein Site-to-Site-VPN zu betreiben, startete ich einen dritten Domänencontroller in derselben Site/im selben Subnetz wie der ursprüngliche Domänencontroller.

Ich habe es ein paar Tage lang gelassen, damit alle drei synchronisiert werden konnten – und sichergestellt, dass repadmin /showrepl und repadmin /replsummary alle ERFOLGREICHE Ergebnisse zeigten. Juhu! Bevor ich den Server herabgestuft habe, der ganz allein steht (im AD-Standort/Subnetz am anderen Ende des Site-to-Site-VPN), habe ich sichergestellt, dass ALLE DNS der anderen Mitgliedsserver, die der Domäne beigetreten sind, auf den ursprünglichen DC und meinen neu erstellten 3. DC zeigen, und habe auch sichergestellt, dass der ursprüngliche DC ALLE FSMO-Rollen innehatte (was er tat). An diesem Punkt habe ich also 3 DCs, alle GCs.

Ich habe zuerst den Server herabgestuft, der sich ganz allein in der Remote-AD-Site befindet (ich habe das Kontrollkästchen „Entfernung dieses Domänencontrollers erzwingen“ aktiviert), neu gestartet, dann die Funktionen „Rollen hinzufügen/entfernen“ ein zweites Mal ausgeführt, um die ADDS-Rolle zu ENTFERNEN, und neu gestartet. Nachdem ich die Meldung „ERFOLGREICH HERABGESTUFT“ (Screenshot unten) gesehen hatte, dachte ich, alles sei in Ordnung. Dann habe ich den Mitgliedsserver aus der Domäne entfernt und neu gestartet. Ich habe sogar überprüft, ob die Server vor der Herabstufung und Entfernung der ADDS-Rolle die erforderlichen Firewall-Ports für eine ordnungsgemäße AD-Kommunikation geöffnet hatten:

  • TCP 53 (DNS)
  • TCP 88 (Kerberos-Schlüsselverteilungscenter)
  • TCP 135 (Remoteprozeduraufruf)
  • TCP 139 (NetBIOS-Sitzungsdienst)
  • TCP 389 (LDAP)
  • TCP 445 (SMB, Net-Anmeldung)
  • TCP 464 (Kerberos-Passwort)
  • TCP 3268 (Globaler Katalog)
  • TCP 49152 – 65535 (zufällig zugewiesene hohe Ports)
  • UDP 53 (DNS)
  • UDP 88 (Kerberos)
  • UDP 123 (NTP)
  • UDP 389 (LDAP)
  • UDP 445
  • UDP 464

Da es „ERFOLGREICH HERABGESTUFT“ war, hatte ich erwartet, diesen herabgestuften/ADDS-Rolle-entfernten/aus der Domäne abgekoppelten Server nicht in der OU der Domänencontroller oder in AD-Sites und -Dienste zu sehen, aber da ist er. Überraschenderweise sind dort sogar die NTDS-Einstellungen vorhanden – in den meisten Threads, die ich gelesen habe, ist nur der Server noch da, aber ohne NTDS-Einstellungen darunter.

Hat jemand eine Idee? Bitte geben Sierelevante LINKS zur Unterstützung Ihrer Kommentare. Vielen Dank!!

ENTSCHULDIGUNG, wenn diese Frage nicht richtig formatiert ist. Ich habe mir fast die Haare ausgerissen, als ich versucht habe, die ganze Formatierung herauszufinden, und habe einfach aufgegeben!!!!

Bildbeschreibung hier eingeben

Antwort1

Führen Sie in einer Eingabeaufforderung auf den verbleibenden Domänencontrollern den folgenden Befehl aus:

nltest /dclist:IhreDomain

Wenn sie alle eine konsistente Ansicht der vorhandenen DCs haben und keiner von ihnen den herabgestuften DC auflistet, bereinigen Sie den herabgestuften DC einfach manuell in ADUC, ADS&S und DNS.

verwandte Informationen