SBS, 3DC Sysvol, Repl. DNS defekt

[Markus_wien 10]

Sind zwar noch nicht alle Daten

 

uh, was fehlt den noch?

 

Ist der von Dir heruntergestufte DC der "RUM-S1" oder war das ein anderer? Fall er es ist - kannst Du mittels NTDSUTIL schauen, ob er noch in den Metadatan vorhanden ist? Siehe How to remove data in Active Directory after an unsuccessful domain controller demotion - falls auf dem SBS SP1 installiert ist, ist das recht schmerzlos.

nein, der rum-s1 ist der, der noch drin ist.

der bgh-s1 ist der heruntergestufte. und diese Anleitung habe ich schon befolgt, denn vorher bekam ich beim heraufstufen die Meldung dass er noch drin sei.

 

Das Ergebnis deiner Abfrage hab ich drangehängt (musste ich aufteilen, datei hatte 46kb).

 

Edit: Achtet bei Informationen welche ihr postet auf vertrauliche Daten im Anhang.

[Markus_wien 10]

Ergebnis von repadmin /showism /v am SBS:

 

==== TRANSPORT CN=IP,CN=Inter-Site Transports,CN=Sites,CN=Configuration,DC=ferro
pan-kobra,DC=com CONNECTIVITY INFORMATION FOR 3 SITES: ====

       0,    1,    2
Site(0) CN=burghausen,CN=Sites,CN=Configuration,DC=xx,DC=com
   0:0:0, 100:180:0, 100:180:0
   All DCs in site CN=burghausen,CN=Sites,CN=Configuration,DC=xx,DC
=com (with trans & hosting NC) are bridgehead candidates.
   Schedule between CN=burghausen,CN=Sites,CN=Configuration,DC=xx,D
C=com and CN=rumaenien,CN=Sites,CN=Configuration,DC=xx,DC=com (cost
100, interval 180):
       Connection is always available.
   Schedule between CN=burghausen,CN=Sites,CN=Configuration,DC=xx,D
C=com and CN=wien,CN=Sites,CN=Configuration,DC=xx,DC=com (cost 100,
interval 180):
       Connection is always available.

Site(1) CN=rumaenien,CN=Sites,CN=Configuration,DC=xx,DC=com
   100:180:0, 0:0:0, 100:180:0
   1 server(s) are defined as bridgeheads for transport CN=IP,CN=Inter-Site Tra
nsports,CN=Sites,CN=Configuration,DC=xx,DC=com & site CN=rumaenien,C
N=Sites,CN=Configuration,DC=xx,DC=com:
       Server(0) CN=rum-s1,CN=Servers,CN=rumaenien,CN=Sites,CN=Configuration,DC
=xx,DC=com
   Schedule between CN=rumaenien,CN=Sites,CN=Configuration,DC=xx,DC
=com and CN=burghausen,CN=Sites,CN=Configuration,DC=xx,DC=com (cost
100, interval 180):
       Connection is always available.
   Schedule between CN=rumaenien,CN=Sites,CN=Configuration,DC=xx,DC
=com and CN=wien,CN=Sites,CN=Configuration,DC=xx,DC=com (cost 100, i
nterval 180):
       Connection is always available.

Site(2) CN=wien,CN=Sites,CN=Configuration,DC=xx,DC=com
   100:180:0, 100:180:0, 0:0:0
   1 server(s) are defined as bridgeheads for transport CN=IP,CN=Inter-Site Tra
nsports,CN=Sites,CN=Configuration,DC=xx,DC=com & site CN=wien,CN=Sit
es,CN=Configuration,DC=xx,DC=com:
       Server(0) CN=S1,CN=Servers,CN=wien,CN=Sites,CN=Configuration,DC=ferropan
-kobra,DC=com
   Schedule between CN=wien,CN=Sites,CN=Configuration,DC=xx,DC=com
and CN=burghausen,CN=Sites,CN=Configuration,DC=xx,DC=com (cost 100,
interval 180):
       Connection is always available.
   Schedule between CN=wien,CN=Sites,CN=Configuration,DC=xx,DC=com
and CN=rumaenien,CN=Sites,CN=Configuration,DC=xx,DC=com (cost 100, i
nterval 180):
       Connection is always available.


==== TRANSPORT CN=SMTP,CN=Inter-Site Transports,CN=Sites,CN=Configuration,DC=fer
ropan-kobra,DC=com CONNECTIVITY INFORMATION FOR 3 SITES: ====

Site CN=burghausen,CN=Sites,CN=Configuration,DC=xx,DC=com is not con
nected by this transport.
Site CN=rumaenien,CN=Sites,CN=Configuration,DC=xx,DC=com is not conn
ected by this transport.
Site CN=wien,CN=Sites,CN=Configuration,DC=xx,DC=com is not connected
by this transport.
       0,    1,    2
Site(0) CN=burghausen,CN=Sites,CN=Configuration,DC=xx,DC=com
   0:0:0, -1:0:0, -1:0:0
   All DCs in site CN=burghausen,CN=Sites,CN=Configuration,DC=xx,DC
=com (with trans & hosting NC) are bridgehead candidates.

Site(1) CN=rumaenien,CN=Sites,CN=Configuration,DC=xx,DC=com
   -1:0:0, 0:0:0, -1:0:0
   All DCs in site CN=rumaenien,CN=Sites,CN=Configuration,DC=xx,DC=
com (with trans & hosting NC) are bridgehead candidates.

Site(2) CN=wien,CN=Sites,CN=Configuration,DC=xx,DC=com
   -1:0:0, -1:0:0, 0:0:0
   All DCs in site CN=wien,CN=Sites,CN=Configuration,DC=xx,DC=com (
with trans & hosting NC) are bridgehead candidates.

[olc 18]

Ok, also Site-Links sehen gut aus.

 

Da die anderen beiden Dateien (ldifde Export) noch nicht freigeschaltet sind, stelle ich einmal folgende Vermutung auf: Aus irgendwelchen Gründen funktioniert die Replikation nicht mehr (unter Umständen fehlende SPNs auf dem SBS), daher kann das Universal Group Membership Caching die Benutzerdaten in den externen Seiten nicht vom SBS abrufen. Da hier ein Timeout gesetzt ist, der zyklisch die Daten abrufen soll, kam es mit den Anmeldungen zu Problemen, da die Caches nicht aktuell gehalten werden können.

 

Wie gesagt, ist eine Vermutung. Die Frage ist dementsprechend, wie man die Replikation wieder zum Laufen bekommt. Wenn auf dem SBS SPNs fehlen, kann man diese wieder manuell nachtragen. Wird sich zeigen, ob danach andere Fehler auftauchen - und wenn ja, was zu vermuten ist, welche. Sollte sich der andere DC danach wieder hochstufen lassen, wäre das gleiche Vorgehen für den RUM-S1 angesagt - das ginge am schnellsten. Ist das DCPROMO danach nicht möglich, schauen wir weiter.

 

Wie gesagt, ich warte einmal auf die LDIFDE Exports oben.

 

Viele Grüße

olc

[olc 18]

Mhhhh, lag ich wohl falsch mit meiner Vermutung. Die SPNs scheinen korrekt registriert zu sein... :suspect:

 

Also ohne einen Gesamtüberblick komme ich nun auch nicht mit Tipps weiter.

 

Ich schicke Dir einmal eine PN...

 

Gruß olc

[olc 18]

...nur eine kurze Zusammenfassung, weil schon spät:

 

Wir haben diverse Aktionen durchgeführt, bis hin zu den Klassikern wie An update to turn off default SNP features is available for Windows Server 2003-based and Small Business Server 2003-based computers , KerberosMaxPacketSize, Secure Channel der DCs zurückgesetzt, UPNs geprüft, Firewalls etc. pp.

 

Am Ende: Das Computerkennwort des PDCe (SBS) selbst mußte zurückgesetzt werden, d.h. How To Use Netdom.exe to Reset Machine Account Passwords of a Windows 2000 Domain Controller gegen sich selbst gefahren werden. Unglaublich...

 

Man lernt nie aus. :D

 

Viele Grüße

olc

[Markus_wien 10]

Auch hier nochmal ein recht herzliches Dankeschön für deine tolle Unterstützung.

 

Ohne dich hätt ich das nicht allein geschafft.

 

lg markus aus wien.

[olc 18]

Gerne. :)

 

Für alle, die vielleicht einmal vor dem gleichen Problem stehen:

Das Zurücksetzen des PDCe Kennworts gegen sich selbst war sicherlich nicht die Ursache und auch nicht die ganze Lösung des Problems. Im Grunde zeigten sich mehrere Fehlerquellen, die Schritt für Schritt abgearbeitet werden mußten. Man sieht auch am Verlauf des Threads, daß sich die Fehler bzw. die Fehlerbilder änderten.

 

Es sieht eher so aus, als ob zu Beginn der Probleme schlicht die Netzwerkverbindung Probleme machte (daher auch bestimmte Connection Objects nicht vorhanden waren, obwohl die Site Links standen) - da auch eine Änderung der VPN-Verbindung im Raum stand, ist die Kerberos MaxPacketSize ein heißer Kandidat.

Es konnte dann nicht mehr repliziert werden, was die Vermutung in die Richtung verstärkt, daß schlichtweg auch keine Universellen Gruppenmitgliedschaften repliziert werden konnten, so daß die Benutzer Anmeldeprobleme bekamen.

Schlußendlich war auch das DNS noch ein wenig zu überprüfen, wo auch einige Kleinigkeiten geändert wurden.

 

Der letzte Schritt war das Zurücksetzen des Computerkennworts des SBS, was ich persönlich noch nie erlebt habe: Der Befehl mußte ohne stoppen des KDC gegen sich selbst gefahren werden, also als Target der S1 angegeben werden. Wie das zur Problemlösung beigetragen hat, ist mir immer noch unklar. :D

 

Ok, genug gelangweilt.

 

Viele Grüße

olc