Domänencontroller replizieren nicht mehr

[anselmo80 10]

Hallo zusammen!

Ich habe folgendes (riesiges) Problem.

Wir haben 3 Standorte. In jedem Standort steht ein Domänencontroller mit Windows Server 2003 inkl. einem Exchange 2003 Server (alles DCs einer Domäne). Am Dienstag ist in Standort A die Zeit nicht auf den 07.03.06 sondern aus Versehen auf den 03.07.06 gesetzt worden (ich weiß das man die Zeit nicht manuell synchronisieren sollte, aber unser Funkempfänger tuts zur Zeit nicht und da wollte ich es mal eben kurz per Hand tun).

Seitdem besteht das Problem, dass die Standorte B und C nicht mehr mit Standort A replizieren können. Eine Anmeldung der Clients in Standort B und C schlug ebenfalls fehl. Probleme im Standort A gab es keine (hier ist auch der PDC-Emulator).

Mit Netdom habe ich die Kennwörter der DCs in Standort A und B zurückgesetzt. Danach konnten sich die Clients wieder anmelden und auch Exchange startete und funktioniert dort wieder. Für die User ist somit wieder alles beim alten.

Das Problem besteht nun in der Replikation der Server. In Standort B bekomme ich die im nächsten Beitrag angegebenen Fehlermeldungen im Eventlog.

 

DNS-Namensauflösungen und so weiter funktionieren.

Ich habe auch schon die Technet und EventID durchsucht, aber alle Hinweise (oft DNS-Probleme) treffen bei mir nicht zu, da die Einstellungen stimmen. Außerdem glaube ich, dass mein Ursprungsproblem eben mit der Änderung der Zeit zusammenhängt und dadurch die Passwörter mit denen die Server sich gegenseitig authentifizieren nicht mehr stimmen.

Hat irgendjemand evtl. eine Idee, was man hier noch tun kann?

 

VIelen Dank schon mal.

Gruß, anselmo

[anselmo80 10]

Ereignistyp: Fehler

Ereignisquelle: Kerberos

Ereigniskategorie: Keine

Ereigniskennung: 4

Datum: 10.03.2006

Zeit: 09:06:24

Benutzer: Nicht zutreffend

Computer: DC Standort B

Beschreibung:

Der Kerberos-Client hat einen KRB_AP_ERR_MODIFIED-Fehler von Server "host/DC Standort A.DOMÄNE" empfangen. Der verwendete Zielname war SMTPSVC/DC Standort A.DOMÄNE. Dies deutet darauf hin, dass das Kennwort, das zum Verschlüsseln des Kerberos-Diensttickets verwendet wurde, anders als das Kennwort auf dem Zielserver ist. Häufige Ursache hierfür sind identische Computerkontonamen im Zielbereich (DOMÄNE) und dem Clientbereich. Wenden Sie sich an den Systemadministrator.

 

------------------

 

Ereignistyp: Warnung

Ereignisquelle: NTDS KCC

Ereigniskategorie: Konsistenzprüfung

Ereigniskennung: 1865

Datum: 10.03.2006

Zeit: 09:02:24

Benutzer: NT-AUTORITÄT\ANONYMOUS-ANMELDUNG

Computer: DC Standort B

Beschreibung:

Die Konsistenzüberprüfung (KCC) konnte keine vollständige umfassende Struktur erstellen. Die folgende Liste einiger Standorte kann daher von dem lokalen Standort nicht erreicht werden.

 

Standorte:

CN=Kleve,CN=Sites,CN=Configuration,DC=DOMÄNE,DC=local

CN=SITE A,CN=Sites,CN=Configuration,DC=DOMÄNE,DC=local

 

-------------------

 

Ereignistyp: Fehler

Ereignisquelle: NTDS KCC

Ereigniskategorie: Konsistenzprüfung

Ereigniskennung: 1311

Datum: 10.03.2006

Zeit: 09:02:24

Benutzer: NT-AUTORITÄT\ANONYMOUS-ANMELDUNG

Computer: DC Standort B

Beschreibung:

Die Konsistenzprüfung hat Probleme mit der folgenden Verzeichnispartition ermittelt.

 

Verzeichnispartition:

CN=Configuration,DC=DOMÄNE,DC=local

 

Es gibt für die Konsistenzprüfung nicht genügend Sitekonnektivitätsinformationen in Active Directory-Standorte und -Dienste, um eine umfassende Gesamtstrukturreplikationstopologie zu erstellen. Oder ein oder mehrere Domänencontroller mit dieser Verzeichnispartition ware nicht in der Lage, die Verzeichnispartitioninformationen zu replizieren. Dies liegt vermutlich an nicht zugreifbaren Domänencontrollern.

 

Benutzeraktion

Verwenden Sie Active Directory-Standorte und -Dienste, um eine der folgenden Maßnahmen durchzuführen:

- Veröffentlichen Sie genügend Informationen über Standortkonnektivität, so dass die Konsistenzprüfung eine Route ermitteln kann, durch die die Verzeichnispartition diesen Standort erreichen kann. Diese Option wird empfohlen.

- Fügen Sie zu einem Domänencontroller hinzu, der die Partition an diesem Standort enthält, ein ein Verbindungsobjekt von einem Domänencontroller hinzu, der die selbe Partition an einem anderen Standort enthält.

 

Wenn keine dieser beiden Aufgaben von Active Directory-Dienste und -Standort den Problemzustand behebt, überprüfen Sie die bisher durch die Konsistenzprüfung protokollierten Ereignisse, die die nicht zugreifbaren Domänencontroller identifizieren.

 

----------------------

 

Ereignistyp: Warnung

Ereignisquelle: NTDS KCC

Ereigniskategorie: Konsistenzprüfung

Ereigniskennung: 1566

Datum: 10.03.2006

Zeit: 09:02:24

Benutzer: NT-AUTORITÄT\ANONYMOUS-ANMELDUNG

Computer: DC Standort B

Beschreibung:

Alle Domänencontroller am folgenden Standort, die die Verzeichnispartition über diesen Transport replizieren können, sind zurzeit nicht verfügbar.

 

Standort:

CN=SITE A,CN=Sites,CN=Configuration,DC=DOMÄNE,DC=local

Verzeichnispartition:

CN=Configuration,DC=DOMÄNE,DC=local

Transport:

CN=IP,CN=Inter-Site Transports,CN=Sites,CN=Configuration,DC=DOMÄNE,DC=local

[grizzly999 11]

Ah, wohl ein VPN dazwischen. Ich bin mir sicher, den von mir hier genannten Patch auf den Servern einspielen hilft:

http://www.mcseboard.de/showthread.php?t=84460

 

 

 

grizzly999

[anselmo80 10]

Hallo!

Danke für die Antwort - und fürs Lesen des ganzen Texts :-). Ein VPN ist bei uns nicht dazwischen. Es sind ganz "normale" Verbindungen.

Die Verbindung von Standort B zu A habe ich mittlerweile auch schon hinbekommen. Ich habe auf dem DC in Standort B den KDC gestoppt und anschließend mit

 

klist purge

 

den Ticket Cache geleert. Mit dem vorherigen zurücksetzen des Computerkontos hat das dann wohl gereicht. Zuerst kam die Meldung, dass er die Replikation des AD wieder aufnimmt und dann sah ich im Replmon die Verbindungen auch wieder als aktiv. Fehler gibt es auch keine mehr, was die beiden Server angeht.

 

Jetzt werde ich gleiches noch mal für die Verbindung mit Standort C versuchen.

[grizzly999 11]

Haben die 2003 Server SP1 drauf?

 

grizzly999

[anselmo80 10]

Die Server haben alle SP1...

[grizzly999 11]

Ok, dann sage ich voraus, dass die Problem, auch wenn sie im Moment behoben scheinen, ohne den genannten Patch wieder auftreten können. Spiele ihn ein ;)

 

Wegen VPN: weisst du, ob Euer Provider für die Standleitungen (von denen gehe ich mal aus) nicht Teile davon oder temporär komplett die Verbindung über VPN Strecken leitet?

Die Fehlermeldungen und IDs sind typisch für dieses Problem, das hatte ich nicht nur einmal bisher, und zwar bei 2003SP1. Da wurden Sachen im TCP/IP Stack geändert (verschlimmbessert), die die Blackhole Detection betreffen, was hauptsächlich bei Remote-Verbindungen über VPN betreffen. Wie gesagt, Provider von solchen Verbindungen sind da manchmal sehr flexibel, wenn es darum geht, Leitungen mal über einen anderen Carrier zu leiten. Daher sind diese Fehler ohne den eingespielten Patch oftmals auch nur temporär.

 

 

grizzly999

[anselmo80 10]

Es sind Standleitungen :D

Ich werde mir den Patch dann doch noch mal anschauen. Danke für den Hinweis. Vor allem weil wir in Zukunft die Standleitungen wohl durch VPN-Leitungen ersetzen werden.

 

Wobei ich immer noch glaube, dass das Problem eigentlich von der Umstellung des Datums herrührt. Zum einen entstanden die Probleme erst danach und zum anderen wiesen auch manche Fehlermeldungen darauf hin, dass die Authentifzierung nicht mehr funktioniert (habe ich den Kerberos 4 Fehler oben eigentlich geposted?). Deswegen denke ich, bin ich mit dem Löschen des Ticket Cache schon ganz gut gefahren.