DC repliziert nicht richtig

oehrken · 23. November 2010

Hallo Gemeinde,

bei einem Kunden folgendes Konstrukt,

1 x SBS2003 Prem, 50 XP User, 1 x 2k3 Std. Datenbank, 1 x 2k3 Std. Fileserver

bis vor 2 Monaten alles in Ordnung, dann einen der 2k3 Server als zus. DC, DNS installiert. Seit dem kommt es sporadisch zu merkwürdigen Vorgängen, das einzelne Arbeitsplätze sich nicht anmelden können. D.h. den Computer aus der Domäne rausnehmen und wieder einbinden, dann geht es.

Also bis her hat sich das alles in Grenzen gehalten (1 x pro Woche), heute waren mehrere davon betroffen, anmelden nicht möglich. Erst nachdem der 2. DC neu gebootet wurde, war alles ok.

DNS funktioniert auf beiden Servern so wie soll.

Wie gehe ich am besten vor um so etwas einzugrenzen.

testperson · 23. November 2010

Hey,

was gibts denn in der Ereignissanzeige zu sehen?

Daim · 23. November 2010

Servus,

dann einen der 2k3 Server als zus. DC, DNS installiert.

die Forward Lookup Zone ist aber AD-integriert gespeichert? Weiterhin sollte in den TCP/IP-Einstellungen der DCs, die DNS-IP-Adresse "Überkreuz" eingetragen werden.

LDAP://Yusufs.Directory.Blog/ - Welcher DNS-Server sollte eingetragen werden ?

Seit dem kommt es sporadisch zu merkwürdigen Vorgängen, das einzelne Arbeitsplätze sich nicht anmelden können.

Wenn dieser Fall eintritt, kann der Client den DC/SBS anpingen (den Namen und die IP)?

D.h. den Computer aus der Domäne rausnehmen und wieder einbinden, dann geht es.

Wie wurden diese Clients installiert? Sind das zufällig geimagete bzw. geclonete Systeme und falls ja, wurde SYSPREP angewendet?

Erst nachdem der 2. DC neu gebootet wurde, war alles ok.

Dann sollte in jedem Fall das Eventlog die erste Anlaufstelle sein. Des Weiteren solltest du auf dem DC das DCDIAG ausführen.

DNS funktioniert auf beiden Servern so wie soll.

Wie hast du das denn verifiziert?

Die Clients haben beide DCs als DNS-Server in ihren TCP/IP-Einstellungen eingetragen?

oehrken · 24. November 2010

Danke für die Antworten, heute hat sich das Problem verschärft.

Ich habe erstmal die DNS Einträge in der Lan-Verbindung "über Kreuz" eingestellt wie in Yusufs Blog beschrieben. Dann habe ich festgestellt, das der neue DC im DNS leer war, seit vorgestern. Ich habe eine neue Zone angelegt und mit dem SBS replizieren lassen, die Einträge sind übernommen worden. Im DNS-Ereigniss des neuen DC erscheint eine Fehlermeldung 4000 "DNS-Server konnte ActiveDirectory nicht öffnen......". Der DNS-Server funktioniert mit nslookup nicht, der SBS schon.

:confused:

DCDiag auf dem SBS:

Replication Check failed

Outbound replication is disabled to correct, run "repadmin /option............."

Dazu kenne ich leider die Syntax nicht.

Test Services failed

IsmServ is stopped

(welcher Dienst ist das?)

Alle anderen Tests sind passed.

Würde mich riesig freuen, wenn jemand ein paar Tipps hätte.

dmetzger · 24. November 2010

Outbound replication is disabled to correct, run "repadmin /option............."

"repadmin /options Servername -DISABLE_OUTBOUND_REPL" (ohne An- und Ausführung, Servername = Name des betreffenden DCs)

oehrken · 26. November 2010

Das Thema hat sich jetzt dahin gehend rausgestellt, das jeden Tag einige PC´s

sich nicht mehr anmelden können. Dann wieder aus der Domäne rausnehmen und neu anmelden. Manchmal geht es auch nach mehreren Versuchen und einiger Zeit von selbst wieder.

Habe jetzt beschlossen, den 2ten DC herab zu stufen, geht jedoch nicht weil er sich am AD nicht anmelden kann.

Versuch mit dcpromo /forceremoval , siehe Yusufs Blog, werde ich gewarnt, das alle DNS-Einträge verloren gehen.

Werden dies Einträge auf dem SBS auch gelöscht? Möchte jetzt nichts verkehrt machen.

Oder gibt es eine andere Möglichkeit.

Im Eventlog sind jede Menge Einträge, die besagen das veraltete Einträge darin sind und mit dem repadmin /removelingeringobjects raus genommen werden können. Dieses Command funktioniert bei mir nicht.

dmetzger · 26. November 2010

Werden dies Einträge auf dem SBS auch gelöscht?

Nein, betrifft das lokale DNS-Replikat.

Im Eventlog sind jede Menge Einträge, die besagen das veraltete Einträge darin sind und mit dem repadmin /removelingeringobjects raus genommen werden können.

Bedeutet, dass die AD-Datenbank auf dem Problem-DC nicht mehr konsistent ist und Objekte enthält, die nicht repliziert werden können.

Das passiert nicht einfach so. Habt Ihr irgendwann eine Image-Sicherung des DCs zurückgespielt o.ä.? Was ist die Ausgabe von "repadmin /showutdvec * DC=Domäne,DC=TLD" (ohne An- und Ausführung)?

Dieses Command funktioniert bei mir nicht.

Sollen wir die Fehlermeldung raten?

Hast Du die Syntax korrekt eingegeben, und findest Du die Ereignis-ID 1988 in der Ereignisanzeige? Und wenn ja: Weshalb erwähnst Du diese Information nicht im Forum?:

Outdated Active Directory objects generate event ID 1988 in Windows Server 2003

Das Thema hat sich jetzt dahin gehend rausgestellt, das jeden Tag einige PC´s
sich nicht mehr anmelden können. Dann wieder aus der Domäne rausnehmen und neu anmelden.

Das ist ein Symptom der inkonsistenten AD-Datenbank auf dem Problem-DC. Hat nichts mit den Clients zu tun, sondern mit diesem DC.

oehrken · 26. November 2010

Also vor ca 6 Wochen wurde der SBS mit Acronis im Offline-Modus auf eine neue Hardware gezogen. Bis vor 10 Tagen war auch nichts aussergewöhnliches im Eventlog zu sehen.

Wenn ich dcdiag auf dem Problem-DC ausführe, bekomme ich Fehlermeldungen, die Tombstone Zeit ist über 60 Tage und der DC kann nicht repliziert werden.

Den Grund habe ich jetz begriffen.

Meine Frage ist jetzt, wenn ich den 2ten, oder Problem-DC, mit dcpromo /forceremoval entferne und nur als Memberserver weiterfahre, ist grundsätzlich etwas dagegen zu sagen?

Das entfernen der Metadateien wie bei Yusuf beschrieben wird noch berücksichtigt.

dmetzger · 26. November 2010

Dein Lösungsweg ist:

1. DC mit dcpromo /forceremoval herunterstufen;

2. Prüfen, ob alle Spuren des DCs beseitigt sind (SRV-Einträge in _msdcs-Zone, DC-Objekt in Standorten und Diensten, DC-Objekt in OU Domänencontroller, Nameserver-Einträge etc.);

3. Mitgliedserver wieder zum DC/GC/DNS-Server hochstufen -> AD-Datenbank wird neu angelegt und repliziert.

Wir wiederholen es in diesem Forum, beim Kunden und im Unterrichtsraum immer wieder: NIE, NIE, NIE eine Image-Sicherung von einem Domänencontroller erstellen und später zurückspielen. Acronis, Ghost und Konsorten haben auf einem Domänencontroller absolut nichts verloren. Das ist Grundlagenwissen.

Daim · 27. November 2010

Hola,

1. DC mit dcpromo /forceremoval herunterstufen;
2. Prüfen, ob alle Spuren des DCs beseitigt sind (SRV-Einträge in _msdcs-Zone, DC-Objekt in Standorten und Diensten, DC-Objekt in OU Domänencontroller, Nameserver-Einträge etc.);

das stimmt...

3. Mitgliedserver wieder zum DC/GC/DNS-Server hochstufen -> AD-Datenbank wird neu angelegt und repliziert.

... aber das nicht. Denn nach dem Ausführen von DCPROMO /Forceremoval ist der gewaltsam heruntergestufte DC kein Mitgliedsserver, sondern ein Standaloneserver! Dann kann man auf einem Standaloneserver direkt das DCPROMO ausführen und den Server wieder zum DC stufen. Der Server muss also nicht zuerst ein Mitgliedsserver werden, um das DCPROMO auszuführen. Somit erspart man sich dann auch einen Schritt und damit einen Neustart.

dmetzger · 27. November 2010

Daim, Du hast diskussionslos Recht. "Mitgliedserver" ist in diesem Fall der unpräzise und daher falsche Begriff. War auch nicht meine Absicht, den heruntergestuften Server zuerst wieder zum Domänenmitglied zu machen, um ihn dann erneut hochzustufen, sondern einfach - eben das falsche Wort.

Off-Topic:

Sieh Dich vor - ich werde ab sofort jede Deiner Zeilen mit der Lupe lesen! :p

bearbeitet 27. November 2010 von dmetzger
Smiley eingefügt, damit es nicht so grimmig aussieht.

oehrken · 28. November 2010

So, dank Eurer Unterstützung läuft seit gestern das Netz ohne Error´s im Eventlog. Habt nochmal vielen Dank.

Jetzt nur zu meinem Verständniss. Wie soll denn ein DC im schlimmsten Fall (Server gestohlen, abgebrannt oder abgesoffen) schnell wieder hergestellt werden. Ich habe es bisher immer so gehalten, ein Image auf ein NAS im Keller (oder entfernt vom eigentlichen Server) und die tägliche Dasi mit CA auf Tape.

In meiner Testumgebung hat ein Restore auf dem Weg immer funktioniert.

Das ich einen DC in einer laufenden Domäne nicht mit Image clonen soll, leuchtet mir ein. Doch im Offline-Modus (alle DC und Arbeitsplätze sind aus)

sollte ein Server-Cloning doch möglich sein. Sonst dürfte man eine Domäne doch nicht ausstellen.

Vielleicht kann mir das noch jemand erklären.

Danke und schönen Sonntag noch.

blub · 28. November 2010

Hi,

"Server gestohlen" ist der sicherlich der worstcase, d.h. nämlich dass alle PW deiness ADs in fremden Händen liegen.

"Abgesoffen/ abgebrannt" eines einzelnen DCs würde ich mit einer Neuinstallation begegnen. Bei guter Automation und guten Prozessen eine Angelegenheit von ca. 2h

cu

blub

Daim · 28. November 2010

Wie soll denn ein DC im schlimmsten Fall (Server gestohlen, abgebrannt oder abgesoffen) schnell wieder hergestellt werden.

Wenn es sich um einen reinen DC handelt, brachst du den DC garnicht wiederherstellen. Du bist sicher mindestens genauso schnell, wenn du die Metadaten des AD bereinigst [1], also die DC-Informationen aus dem AD und DNS entfernst, und anschließend den (anderen) Server nach einer Neuinstallation zum zusätzlichen DC stufst [2].

Wird allerdings der DC gestohlen, stimmt etwas gewaltig an euren Sicherheitsvorkehrungen nicht! Denn genau dieser Fall darf genau aus dem Grund, den blub genannt hat, nicht eintreten! In solch einem Fall, müssen schleunigst sämtliche Kennwörter von administrativen Konten geändert und der DC muss aus dem AD entfernt werden.

Genau aus diesem Grund, wurde der RODC erkoren [3]! Dieser ist geradezu prätestiert für Aussenstellen, die nicht die gleiche physikalische Sicherheit bieten können wie die Zentrale.

Doch im Offline-Modus (alle DC und Arbeitsplätze sind aus)
sollte ein Server-Cloning doch möglich sein.

Aber nur dann, wenn alle DCs einer Domäne ausgeschaltet sind, könnte das funktionieren. Trotzdem ist das nicht supportet und ist alles andere, als eine gute Idee [4]. Sichere die Server stets mit der Variante, die der Hersteller supportet. Klar, das Thema Backup ist aufwändig, gehört jedoch zur täglichen Administration. Die Server und Technologien müssen "supportet" gesichert werden!