Jump to content

NTDS SDPROP auf W2K DC, AD im Eimer?


Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Empfohlene Beiträge

Hallo,

 

ich habe hier ein mittelschwere bis großes Problem.

 

Aus einem mir nicht nachvollziehbaren Grund spinnt ein W2K DC und loggt wie wild folgende Eventlog Eintrage im Sekundentakt! Die Folgen davon weiter unten.

 

Ereignistyp:	Warnung
Ereignisquelle:	NTDS SDPROP
Ereigniskategorie:	Interne Verarbeitung 
Ereigniskennung:	1214
Datum:		04.05.2008
Zeit:		19:31:28
Benutzer:		Jeder
Computer:	Servername-[color="RoyalBlue"][b]W2KDC[/b][/color]
Beschreibung:
Active Directory hat beim Verarbeiten der Übermittlung der 
Sicherheitsbeschreibung auf DNT=0x3547 
keine Sicherheitsbeschreibung gefunden (Fehler 0x6). 
Eine Standardsicherheitsbeschreibung wird für das Objekt 
übernommen. Das kann dazu führen, dass die Sicherheit auf 
diesem Objekt auf diesem Domänencontroller anders sein wird. 
Schreiben Sie eine neue Sicherheitsbeschreibung auf dieses Objekt, 
um das Problem zu beheben.

Weitere Informationen über die Hilfe- und Supportdienste erhalten 
Sie unter http://go.microsoft.com/fwlink/events.asp.

 

Ereignistyp:	Fehler
Ereignisquelle:	NTDS SDPROP
Ereigniskategorie:	Interne Verarbeitung 
Ereigniskennung:	1205
Datum:		04.05.2008
Zeit:		19:31:28
Benutzer:		Jeder
Computer:	Servername-[color="RoyalBlue"][b]W2KDC[/b][/color]
Beschreibung:
Der Verzeichnisdienst hat beim Verarbeiten der Übermittlung der 
Sicherheitsbeschreibung keine Sicherheitsbeschreibung auf 
DNT=0x3547 gefunden (Fehler 0x6). Die Übermittlung auf 
untergeordnete Objekte dieses Objekts findet nicht statt.

Weitere Informationen über die Hilfe- und Supportdienste erhalten 
Sie unter...

 

Die MS KB schweigt sich zu dem Fehler aus, ein Hinweis in KB328422 und die damit verbundene Installation von SP4 auf dem DC brachte erwartungsgemäß nichts.

 

Auf dem Server pollt die LSASS.exe nebenbei bei 50% CPU Auslastung. Ein Virus kann an sich ausgeschlossen werden, da ein Virenscanner auf dem Server läuft. Meine Vermutung ist eher, dass die Auslastung etwas mit dem eigentlichen Fehler zu tun hat.

 

Parallel wird auf einem anderen DC (W2K3 mit Exchange) regelmäßig folgendes Ereignis mitgeloggt:

 

Ereignistyp:	Warnung
Ereignisquelle:	NTDS Replication
Ereigniskategorie:	Replikation 
Ereigniskennung:	1586
Datum:		28.04.2008
Zeit:		12:56:48
Benutzer:		NT-AUTORITT\ANONYMOUS-ANMELDUNG
Computer:	Servername-[b][color="DarkOrange"]W2K3DC[/color][/b]
Beschreibung:
Der Prfpunkt unter Windows NT 4.0 oder frher fr die Replikation mit 
dem PDC-Emulationsmaster war nicht erfolgreich. 

Eine vollstndige Synchronisierung der Datenbank für die 
Sicherheitskontenverwaltung auf Domänencontroller unter Windows 
NT 4.0 und fürher kann stattfinden, wenn die Funktion des 
PDC-Emulationsmasters vor dem nchsten erfolgreichen Prfpunkt auf 
den lokalen Domnencontroller bertragen wird. 

Die Prüfpunktverarveitung wird in 4 Stunden erneut versucht. 

Zustzliche Daten 
Fehlerwert:
8451 Der Replikationsvorgang ist auf einen Datenbankfehler gestoen.

Weitere Informationen ber die Hilfe- und Supportdienste erhalten 
Sie unter...

 

Im Zuge dessen ist eine Übertragung der FSMO Rollen auf den W2K3 DC nicht erfolgreich und wird mit Fehlern wie diesem quittiert:

 

Die Übertragung der Funktion des aktuellen Betriebsmasters 
konnte nicht durchgeführt werden. Grund: Der angeforderte 
FSMO-Vorgang konnte nicht ausgeführt werden. Der aktuelle FSMO 
Inhaber war nicht erreichbar.

 

Das AD Schema kann ebenfalls nicht auf W2K3 R2 erweitert werden.

 

Ziel ist eigentlich das AD irgendwie von der W2K Maschine herunterzubekommen bzw. die FSMO Rollen + GC auf einen anderen Server zu übertragen.

 

Meine Frage(n) deshalb:

 

1. Gibt es einen Weg die Übertragung der FSMO Rollen + GC zu erzwingen?

2. Kennt vielleicht jemand das Fehlerbild des W2K DCs und weiß Abhilfe?

 

Bin für jeden Tipp dankbar!!!

 

Gruß Wolke

Link zu diesem Kommentar

Servus,

 

ok, bei der Fehlermeldung mit der EventID 1214 hat also das Objekt seinen security descriptor (zu deutsch, Sicherheitsbeschreibung) verloren. Ist zwar merkwürdig, denn von alleine verliert das Objekt nicht einfach so seine Sicherheitsinformationen - daher vermute ich, liegt der Hase im Pfeffer noch an einer anderen Stelle begraben. Aber was ich für noch ärgerlicher finde, ist die Fehlerbeschreibung:

 

Active Directory hat beim Verarbeiten der Übermittlung der Sicherheitsbeschreibung auf DNT=0x3547

keine Sicherheitsbeschreibung gefunden (Fehler 0x6).

 

Nun sollen wir also wissen, welches Objekt DNT=0x3547 ist? Hallo? Gehts noch?

Leider schweigt dazu ebenfalls die Suchmaschine, so dass hier - wenn einer überhaupt wissen könnte um welches Objekt es sich handelt - einzig und allein Microsoft das wäre.

 

Ich würde sicherheitshalber zuerst einen Integritäts-Check über die AD-DB laufen lassen und wenn dabei Fehler gemeldet werden sollten, ein FIXUP drüber laufen lassen.

 

Yusuf`s Directory - Blog - Die Active Directory-Datenbank reparieren

 

 

8451 Der Replikationsvorgang ist auf einen Datenbankfehler gestoen.

 

Auhaa... auf diesem DC stimmt definitiv etwas nicht mit der AD-Datenbank.

Führe zuerst eine Datensicherung durch und führe auf diesem DC, den o.g. Link durch.

Aber achte das du eine funktionierende Sicherung hast, denn das FIXUP könnte evtl. am Ende noch mehr Schaden einrichten.

 

 

Der angeforderte

FSMO-Vorgang konnte nicht ausgeführt werden. Der aktuelle FSMO

Inhaber war nicht erreichbar.

 

Wenn auf beiden DCs ein Integritätstest durchgeführt und bei gemeldeten Fehlern, diese behoben sein sollten, ist zwingend mit DCDIAG und NetDIAG durch weitere Tests die DCs zu prüfen. Die Eventlog der DCs sind natürlich ebenfalls zu durchforsten und den Fehlern nachzugehen.

Link zu diesem Kommentar

Hmmm wäre ja auch zu schön gewesen. Jemand postet: JA, GENAU DEN FEHLER HATTE ICH AUCH SCHON, das löst Du so und so... aber leider.... :(

 

Die Idee mit der AD Reparatur ist nicht schlecht aber ehrlich gesagt ist mir die Geschichte etwas zu heiß, um sie einfach so auszuprobieren.

Die Sicherung des AD zu dem Zeitpunkt, an dem der Fehler nicht existierte wird der Kunde sicher nicht mehr haben und ob das Passwort für den Wiederherstellungsmodus bekannt ist wage ich zu bezweifeln...

 

Ich werde mich wohl mit dem Support in Verbindung setzen müssen. Da war zwar letztens schon rauszuhören: "Pech gehabt, Hotfixes für W2K is nicht mehr..." aber vielleicht können die noch etwas sinnvolles anbieten.

 

So mal rein nach Bauchgefühl und Erfahrung. Würde das "seizen" der FSMO Rollen sinnvoll bzw. von Erfolg gekrönt sein (laut MS Artikel von Lukas ist es ja das empfohlene Vorgehen)?

Das Problem, dass das AD auf dem W2K im Eimer ist habe ich dann weiterhin. Es ist weiterhin zu bezweifeln, ob sich der Gute mit einem DCPROMO sauber aus dem AD enfernen lässt.

Link zu diesem Kommentar
Die Idee mit der AD Reparatur ist nicht schlecht aber ehrlich gesagt ist mir die Geschichte etwas zu heiß, um sie einfach so auszuprobieren.

 

Du kannst ja trotzdem vorher nur einen Check drüber laufen lassen.

Einen Reparaturversuch (Fixup) musst du ja nicht laufen lassen.

Aber mit einem Check der AD-DB weiß man schonmal, ob prinzipiell mit der DB alles soweit ok ist.

 

 

Die Sicherung des AD zu dem Zeitpunkt, an dem der Fehler nicht existierte wird der Kunde sicher nicht mehr haben und ob das Passwort für den Wiederherstellungsmodus bekannt ist wage ich zu bezweifeln...

 

Dann kläre ob eine aktuelle funktionierende Sicherung, mindestens vom System State existiert. Das Kennwort für DSRM kannst du vorher auch unter Windows 2000 rücksetzen. Dort funktioniert das zurücksetzen mit SETPWD.

 

How to Change the Recovery Console Administrator Password on a Domain Controller

 

 

Ich werde mich wohl mit dem Support in Verbindung setzen müssen. Da war zwar letztens schon rauszuhören: "Pech gehabt, Hotfixes für W2K is nicht mehr..." aber vielleicht können die noch etwas sinnvolles anbieten.

 

Den PSS kannst du jederzeit anrufen. Ich würde mir erstmal vor Ort mit dem Kunden einen genauen Überblick verschaffen.

 

 

So mal rein nach Bauchgefühl und Erfahrung. Würde das "seizen" der FSMO Rollen sinnvoll bzw. von Erfolg gekrönt sein (laut MS Artikel von Lukas ist es ja das empfohlene Vorgehen)?

 

Ja, dass würde - sofern die AD-Datenbank auf dem DC keinen Schaden hat - sicher funktionieren. Aber dann muss zwingend der Ursprungsträger vom Netz genommen werden, ehe noch mehr Schaden entsteht.

 

 

Das Problem, dass das AD auf dem W2K im Eimer ist habe ich dann weiterhin.

 

Genau und momentan wäre ich mir nicht sicher, ob sogar das seizen funktionieren würde.

 

Es ist weiterhin zu bezweifeln, ob sich der Gute mit einem DCPROMO sauber aus dem AD enfernen lässt.

 

Das wäre auch nicht so das Problem. Den kann man auch händisch aus dem AD entfernen.

Link zu diesem Kommentar
Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Schreibe einen Kommentar

Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.

Gast
Auf dieses Thema antworten...

×   Du hast formatierten Text eingefügt.   Formatierung jetzt entfernen

  Only 75 emoji are allowed.

×   Dein Link wurde automatisch eingebettet.   Einbetten rückgängig machen und als Link darstellen

×   Dein vorheriger Inhalt wurde wiederhergestellt.   Editor-Fenster leeren

×   Du kannst Bilder nicht direkt einfügen. Lade Bilder hoch oder lade sie von einer URL.

×
×
  • Neu erstellen...