Der alte Betriebsmeister glaubt immer noch, er sei der „Eine“

Der alte Betriebsmeister glaubt immer noch, er sei der „Eine“

Ich habe eine Domäne mit 3 AD-Servern, ich nenne sie vorerst einfach:

  • AD01 (Win 2008 GC, Betriebsmaster)
  • AD02 (Windows 2008 GC)
  • AD03 (Windows 2003 GC)

Vor einigen Monaten gab es Hardwareprobleme mit AD01, daher wurden der Operations Master, PDC und Infrastructure Master nach AD02 verschoben. Während dieser Zeit waren alle Rechner eingeschaltet.

  • AD01 (Windows 2008 GC)
  • AD02 (Win 2008 GC, Betriebsmaster)
  • AD03 (Windows 2003 GC)

AD01 war dann einen Monat lang heruntergefahren. Beim Starten dieser Maschine mit ausgetauschter Hardware (NIC und RAID-Karte) habe ich jetzt ein seltsames Problem.

  • AD01 denkt, es sei noch der Operationsmaster in AD auf der lokalen Box
  • AD02 und AD03 denken, dass AD02 auf beiden Boxen der Betriebsleiter in AD ist
  • Beim Ausführen von DCDIAG auf AD01 treten eine Reihe von Problemen auf (siehe unten)

Beim Ausführen von „dcdiag /test:advertising“ auf AD01:

Doing primary tests

   Testing server: Default-First-Site-Name\AD01
      Starting test: Advertising
         Warning: DsGetDcName returned information for \\ad02.domain.local, when
         we were trying to reach AD01.
         SERVER IS NOT RESPONDING or IS NOT CONSIDERED SUITABLE.
         ......................... AD01 failed test Advertising


   Running partition tests on : ForestDnsZones

   Running partition tests on : DomainDnsZones

   Running partition tests on : Schema

   Running partition tests on : Configuration

   Running partition tests on : domain

   Running enterprise tests on : domain.local

Beim Ausführen von „dcdiag“ auf AD01 erhalte ich die folgenden Fehler (Auszug der endgültigen Ausgabe):

   Testing server: Default-First-Site-Name\AD01
      Starting test: Advertising
         Warning: DsGetDcName returned information for \\ad02.domain.local, when
         we were trying to reach AD01.
         SERVER IS NOT RESPONDING or IS NOT CONSIDERED SUITABLE.
         ......................... AD01 failed test Advertising
      Starting test: FrsEvent
         There are warning or error events within the last 24 hours after the
         SYSVOL has been shared.  Failing SYSVOL replication problems may cause
         Group Policy problems.



  Starting test: NCSecDesc
     Error NT AUTHORITY\ENTERPRISE DOMAIN CONTROLLERS doesn't have
        Replicating Directory Changes In Filtered Set
     access rights for the naming context:
     DC=ForestDnsZones,DC=domain,DC=local
     Error NT AUTHORITY\ENTERPRISE DOMAIN CONTROLLERS doesn't have
        Replicating Directory Changes In Filtered Set
     access rights for the naming context:
     DC=DomainDnsZones,DC=domain,DC=local

Starting test: Replications
   [Replications Check,Replications Check] Inbound replication is
   disabled.
   To correct, run "repadmin /options AD01 -DISABLE_INBOUND_REPL"
   [Replications Check,AD01] Outbound replication is disabled.
   To correct, run "repadmin /options AD01 -DISABLE_OUTBOUND_REPL"

Das Problem scheint also zu sein, dass AD01 das Memo nie erhalten hat, als ich den Operationsmaster verschoben habe. Und jetzt, da es gestartet ist, denken alle anderen AD-Server nicht mehr, dass es der Boss ist, wenn es versucht, zu replizieren usw. Ich muss AD01 also wirklich manuell aktualisieren, damit es weiß, wer der Operationsmaster, die Infrastruktur und der PDC ist - aber ich habe kein Glück.

Ich habe fast einen Tag lang gegoogelt und alle Lösungen führen zu „der Kuchen ist eine Lüge“

Ihre Ninja-Fähigkeiten werden sehr geschätzt

Antwort1

Gibt es einen Grund, warum Sie nicht einfach dcpromo auf AD01 ausführen, es von einem Domänencontroller herabstufen, neu starten und es dann erneut mit dcpromo als Backup auf einen Domänencontroller bringen können?

Antwort2

Ich scheine das Problem behoben zu haben. Beachten Sie den Kommentar im Fehler:

To correct, run "repadmin /options AD01 -DISABLE_INBOUND_REPL"

Ich habe dies für beide im Protokoll genannten Optionen getan. Dann bemerkte ich, dass der Netlogon-Dienst aus irgendeinem seltsamen Grund angehalten wurde ... was soll das?

Ich habe dann Netlogon gestartet und eine erzwungene Synchronisierung ausgeführt. Diesmal funktionierte die Synchronisierung und alles wurde wieder aktiviert.

Als Nächstes hätte ich es so gemacht wie Josh vorgeschlagen hat und dcpromo aus der Box heruntergeladen.

Jasons Kommentare zu DNS waren auch sehr hilfreich, da dies eines der ersten Dinge ist, an die ich gedacht habe – wenn also jemand anders vorbeikommt, würde ich das zuerst prüfen.

Vielen Dank für die schnellen Antworten. Ich bin schon lange ein Stackoverflow-Unterstützer und es ist toll zu sehen, dass das einfach großartig ist :-)

Antwort3

Ich vermute, dass die Operationsmasterrollen nicht von 01 verschoben wurden, sondern von 02 übernommen wurden. In diesem Fall ist das von Ihnen beschriebene Verhalten korrekt. 01 hat keine Ahnung, dass es nicht mehr der Master ist, der es einmal war.

Eine andere Möglichkeit besteht darin, dass die Rollen verschoben wurden, 01 jedoch heruntergefahren wurde, bevor alle geänderten DNS-Einträge irgendwie in einer AD-integrierten Zone zurück auf 01 repliziert wurden.

In beiden Fällen würde ich dc1 aus der Domäne entfernen und es mit Dcpromo erneut hinzufügen, da die Replikation irgendwie deaktiviert wurde

Antwort4

Ich habe zu früh gesprochen. Es scheint, dass ich ein „USN-Rollback-Problem“ hatte. http://support.microsoft.com/kb/875495/en-us

Das war ein riesiger Aufwand. Und anscheinend habe ich dabei AD beschädigt. Durch den Neustart von NETLOGON und die erneute Aktivierung der Synchronisierung habe ich fehlerhafte Daten auf den anderen Boxen wieder in AD gelassen.

Letzte Woche haben wir einen großen Postfachumzug in einen neuen Mailstore durchgeführt und anscheinend sind nun alle unsere Postfächer mit E-Mails vollgestopft. :(

Eines kann man daraus lernen:

Wenn NetLogon jemals „pausiert“ wird, gibt es dafür wahrscheinlich einen guten Grund.

verwandte Informationen