x-scips
Goto Top

W2K3 Domäne mit Replikationsproblem in der Ereignisanzeige NtFrs 13508 ohne 13509 auf DC001 und NtFrs 13568 auf DC002

Hallo @dmins,

folgende Konstellation der Domänencontroller;
DC001 (FSMO Inhaber)
DC002
BK001 (temporärer DC)
MI4 (anderer Standort)

Auf DC001 (& BK001 mit entsprechend gänderten Werten) erscheint folgende Meldung:
Ereignistyp: Warnung
Ereignisquelle: NtFrs
Ereigniskategorie: Keine
Ereigniskennung: 13508
Datum: 19.11.2009
Zeit: 14:49:42
Benutzer: Nicht zutreffend
Computer: DC001
Beschreibung:
Der Dateireplikationsdienst konnte die Replikation von DC002 nach DC001 für c:\ad\sysvol\domain mit DNS-Namen dc002.Intertec.int nicht aktivieren. Es wird ein neuer Versuch gestartet.
Mögliche Ursachen für diese Warnung sind:

[1] Der DNS-Name dc002.Intertec.int von diesem Computer konnte nicht ausgewertet werden.
[2] Der Dateireplikationsdienst wird auf dc002.Intertec.int nicht ausgeführt.
[3] Die Topologieinformationen im Active Directory dieses Replikats wurden noch nicht auf allen Domänencontrollern repliziert.

Diese Ereignisprotokollmeldung wird einmal pro Verbindung angezeigt. Nachdem der Fehler behoben wurde, wird eine andere Ereignisprotokollmeldung angezeigt, die bestätigt, dass die Verbindung hergestellt wurde.

Auf DC002 die andere Meldung:
Ereignistyp: Fehler
Ereignisquelle: NtFrs
Ereigniskategorie: Keine
Ereigniskennung: 13568
Datum: 19.11.2009
Zeit: 14:18:32
Benutzer: Nicht zutreffend
Computer: DC002
Beschreibung:
Der Dateireplikationsdienst hat ermittelt, dass sich der Replikatsatz "DOMAIN SYSTEM VOLUME (SYSVOL SHARE)" sich in JRNL_WRAP_ERROR befindet.

Name des Replikatsatzes : "DOMAIN SYSTEM VOLUME (SYSVOL SHARE)"
Replikatstammpfad : "c:\ad\sysvol\domain"
Replikatstammvolume : "\\.\C:" n% Ein Replikatsatz stößt auf JRNL_WRAP_ERROR, wenn der Eintrag, von dem gelesen werden soll, nicht vom NTFS-USN-Journal gefunden > wird. Mögliche Ursachen hierfür sind: n%
[1] Volume "\\.\C:" wurde formatiert.
[2] Das NTFS-USN-Journal auf Volume "\\.\C:" wurde gelöscht.
[3] Das NTFS-USN-Journal auf Volume "\\.\C:" wurde abgeschnitten. Chkdsk kann das Journal abschneiden, falls es beschädigte Einträge am Ende des Journals vorfindet.
[4] Der Dateireplikationsdienst wurde seit längerer Zeit auf diesem Computer nicht mehr ausgeführt.
[5] Die Rate der Laufwerks-E/A-Aktivität auf "\\.\C:" war zu schnell für den Dateireplikationsdienst.
Das Festlegen des Registrierungsparameters "Enable Journal Wrap Automatic Restore" auf 1 führt dazu, dass folgende Maßnahmen zum automatischen Beheben des Fehlerzustands vorgenommen werden.
[1] Beim ersten Poll, der in 5 Minuten durchgeführt wird, wird dieser Computer vom Replikatsatz entfernt. Wenn Sie nicht 5 Minuten warten möchten, führen Sie "net stop ntfrs" aus, gefolgt von "net start ntfrs", um den Dateireplikationsdienst neu zu starten.
[2] Beim auf die Löschung folgenden Poll wird der Computer erneut zum Replikatsatz hinzugefügt. Durch das erneute Hinzufügen wird eine vollständige Struktursynchronisierung für den Replikatsatz ausgelöst.

WARNUNG: Während des Wiederherstellungsvorgangs sind Daten in der Replikatstruktur möglicherweise nicht verfügbar. Sie sollten den oben beschriebenen Registrierungsparameter auf 0 festlegen, um eine unerwartete Nichtverfügbarkeit von Daten durch die automatische Wiederherstellung zu verhindern, wenn dieser Fehlerzustand erneut auftritt.

Führen Sie regedit aus, um diesen Registrierungsparameter zu ändern.

Klicken Sie auf "Start", dann auf "Ausführen", und geben Sie dann "regedit" ein.

Erweitern HKEY_LOCAL_MACHINE.
Folgen Sie folgendem Pfad:
"System\CurrentControlSet\Services\NtFrs\Parameters"
Doppelklicken Sie auf den Namen des Wertes
"Enable Journal Wrap Automatic Restore"
und aktualisieren Sie den Wert.

Ist der Name des Wertes nicht vorhanden, können Sie ihn mit dem Befehl "Neu" und dann "DWORD-Wert " im Menü "Bearbeiten" hinzufügen. Geben Sie den Wert genauso ein wie oben gezeigt.


Bei Ausführung des Befehls Nltest /dsgetdc: /pdc /force /avoidself auf DC001 bekomme ich folgende Antwort:

DsGetDcName failed: Status = 1355 0x54b ERROR_NO_SUCH_DOMAIN

Auf den anderen DCs bekomme ich bei dem Befehl die korrekten Daten ohne Fehler angezeigt.

Manuelle ausgelöste Replikationen (per GUI und CMD) sind ohne Fehlermeldung möglich und Änderungen kommen auf der jeweils anderen Maschine an. Allerdings habe ich nicht wirklich Lust auf ausufernde Probleme weshalb ich bitte Hilfe benötige!

Der Regkey auf dem DC002 wurde bisher noch nicht gesetzt. Vorher möchte ich erst alles andere so gut wie möglich ausschließen.

Hat jemand eine Idee, wo ich ansetzen kann?

Content-ID: 129793

Url: https://administrator.de/contentid/129793

Ausgedruckt am: 17.11.2024 um 06:11 Uhr

Yusuf-Dikmenoglu
Yusuf-Dikmenoglu 19.11.2009 um 18:45:01 Uhr
Goto Top
Servus,

versuche zuerst den Fehler 13568 zu beseitigen, dann verschwindet auch der Fehler 13508.

Siehe dazu:

[LDAP://Yusufs.Directory.Blog/ - Dateireplikationsfehler mit der ID 13568]
http://blog.dikmenoglu.de/Dateireplikationsfehler+Mit+Der+ID+13568.aspx


Viele Grüße
Yusuf Dikmenoglu
x-scips
x-scips 19.11.2009 um 22:34:55 Uhr
Goto Top
Hi,

vielen Dank für die schnelle Antwort. Morgen werde ich die Vorgehensweise umsetzen. Bin schon gespannt auf das Ergebnis.
Was mir fast schon mehr Sorgen macht ist die Sache des DC001 auf

Nltest /dsgetdc: /pdc /force /avoidself

und der Antwort

DsGetDcName failed: Status = 1355 0x54b ERROR_NO_SUCH_DOMAIN

Hierfür evtl. auch eine Idee?

Grüße

Ralf
x-scips
x-scips 22.11.2009 um 22:26:52 Uhr
Goto Top
Hat nicht vielleicht doch jemand eine Idee zu dem Problem

Nltest /dsgetdc: /pdc /force /avoidself

und der Antwort

DsGetDcName failed: Status = 1355 0x54b ERROR_NO_SUCH_DOMAIN

????
x-scips
x-scips 22.11.2009 um 23:11:28 Uhr
Goto Top
Zitat von @Yusuf-Dikmenoglu:
Servus,

versuche zuerst den Fehler 13568 zu beseitigen, dann verschwindet
auch der Fehler 13508.

Siehe dazu:

[LDAP://Yusufs.Directory.Blog/ - Dateireplikationsfehler mit der ID
13568]
http://blog.dikmenoglu.de/Dateireplikationsfehler+Mit+Der+ID+13568.aspx


Viele Grüße
Yusuf Dikmenoglu

Hallo Yusuf,
vielen Dank für den Link, wäre eine einfachere Möglichkeit folgende?:

Dem Domänencontroller glaubhaft machen, man habe den Systemstatus aus einer früheren Sicherung zurückgespielt.

Im Verzeichnisdienstwiederherstellungs-Modus starten
Regedit.exe aufrufen und kontrollieren, ob der Wert "DSA Previous Restore Count" unter
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters vorhanden ist.
Wenn ja, dann den Eintrag im Wert nur notieren.
Wenn nein, nichts tun. Den Wert NICHT erstellen.
Erstellen des Wertes "Database restored from backup" unter HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters
Datentyp: REG_DWORD; Wert=1
Den Domänencontroller normal starten.
Prüfen, ob sich der Wert, der unter Punkt 2) notiert wurde, sich um 1 erhöht hat

Hätte die Vorgehensweise nicht den gleichen Effeckt nur ohne D4 zu setzen?

Grüße
x-scips
x-scips 25.11.2009 um 13:25:47 Uhr
Goto Top
Hallo Yusuf und der Rest mit gleichem Fehler,

seitens MS habe ich eine Vorgehensweise erhalten, die der Beschreibung in Yusufs Homepage entspricht, jedoch nicht den gesammten Aufwand beschreibt. Nachfolgend die Schritte:

1.Clear the staging folder contents
2. Take a backup of the policies and scripts folder and then empty them.
3. Set the registry entry for non-authoritative restore (D2).

To perform D2 we have to do the following steps.

1. Click Start, and then click Run.
2. In the Open box, type cmd and then press ENTER.
3. In the Command box, type net stop ntfrs.
4. Click Start, and then click Run.
5. In the Open box, type regedit and then press ENTER.
6. Locate the following subkey in the registry:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NtFrs\Parameters\Backup/Restore\Process
at Startup
7. In the right pane, double-click BurFlags.
8. In the Edit DWORD Value dialog box, type D2 and then click OK.
9. Quit Registry Editor, and then switch to the Command box.
10. In the Command box, type net start ntfrs.
11. Quit the Command box.

Now the server will be in seeding state and get the sysvol contents from the
partner (upstream partner).

Diese Vorgehensweise hat bei mir umgehend zum Erfolg geführt und sofort nach Start des NtFRS haben die DCs wieder sauber miteinander kommuniziert.

Da diese Meldung doch für einiges Kopfzerbrechen gesorgt hat, bin ich mit dieser Lösung sehr zufrieden und schicke meinen Dank an Yusuf und die Kollegen von MS...