13
JOURNAL WRAP ERROR - jetzt ist meine gesamte domäne funktionsuntüchtig - bin verzweifelt
Nachdem ich auf meinem einzigen Domänencontroller (W2K3 SP2) den registry-key HKLM\System\CurrentControlSet\Services\NtFrs\Parameters\Enable Journal Wrap Automatic Restore auf 1 gesetzt habe, hat er mir die shares \sysvol und \netlogon entfernt. seither ist ein anmelden am domänencontroller (zumindest über mstsc) nicht mehr möglich...
Hallo!
ich hatte folgende struktur:
2 DC (W2K3 SP1 und SP2) + Exchange und einiges andere...
nun habe ich den 1. DC auswechseln müssen, weil auf C: nur mehr 500 MB frei waren (habe ich so von meinem vorgänger geerbt...)
der plan war also folgender:
1. DC1 mit dcpromo entfernen (hat funktioniert)
2. DC2 sollte nun DHCP und DNS sowie alle rollen vom 1. übernehmen (hat funktioniert)
3. neuen DC3 mit Server2008R2 installieren und mit dcpromo in bestehende strukur integrieren (so, ab nun kommen die probleme).
DC3 brachte nun folgende fehlermeldung:
Protokollname: File Replication Service
Quelle: NtFrs
Datum: 01.01.2010 21:14:01
Ereignis-ID: 13565
Aufgabenkategorie:Keine
Ebene: Warnung
Schlüsselwörter:Klassisch
Benutzer: Nicht zutreffend
Computer: DC3.meinedomänelocal
Beschreibung:
Der Dateireplikationsdienst initialisiert den Systemdatenträger mit Daten eines anderen Domänencontrollers. Der Computer "WICKY" kann nicht zum Domänencontroller benannt werden, bis dieser Vorgang beendet ist. Das Systemvolumen wird dann unter SYSVOL freigegeben.
Um die SYSVOL-Freigabe zu überprüfen, geben Sie an der Eingabeaufforderung folgendes ein:
net share
Wenn der Dateireplikationsdienst den Initialisierungsvorgang beendet, erscheint die SYSVOL-Freigabe.
Die Initialisierung des Systemdatenträgers kann einige Zeit in Anspruch nehmen. Der Zeitaufwand ist von der Datenmenge im Systemdatenträger, der Verfügbarkeit anderer Domänencontroller, und dem Replikationsintervall zwischen anderen Domänencontrollern abhängig.
also habe ich am DC2 (der ja in der Zwischenzeit der einzig verbleibende funktionierende Domänencontroller war) nachgesehen, und habe folgenden fehler entdeckt:
Ereignistyp: Fehler
Ereignisquelle: NtFrs
Ereigniskategorie: Keine
Ereigniskennung: 13568
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:\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.
so, und diesen registry-key habe ich nun gesetzt mit folgendem Ergebnis:
DC3 repliziert immer noch nicht (und wird daher auch nicht zum domänencontroller )
das liegt daran, dass die shares \sysvol und \netlogon bei jedem neustart verschwinden
und, was wesentlich schwerwiegender ist:
ich kann mich nun am DC2 nicht mal mehr anmelden (zumindest nicht remote).
einer der vorhanden fehler:
Der Domänecontrollername für das Computernetzwerk konnte nicht ermittelt werden. (Die angegebene Domäne ist nicht vorhanden, oder es konnte keine Verbindung hergestellt werden - Fehlercode 1054
ich komme zwar remote (als von einem anderen PC, auf den ich mich mit mstsc verbunden habe) in die computerverwaltung von DC2, leider aber nicht in die registry, um den eintrag zu entfernen.
fehlermeldung:
Ein Programm kann das erforderliche Dialogfeld nicht öffnen, da keine Pfade gefunden wurden...
weiss jemand rat, wie ich meine Struktur nochmal retten kann? Ich bin wirklich verzweifelt...
Danke im voraus für Eure Tipps!!!
lg
Hallo!
ich hatte folgende struktur:
2 DC (W2K3 SP1 und SP2) + Exchange und einiges andere...
nun habe ich den 1. DC auswechseln müssen, weil auf C: nur mehr 500 MB frei waren (habe ich so von meinem vorgänger geerbt...)
der plan war also folgender:
1. DC1 mit dcpromo entfernen (hat funktioniert)
2. DC2 sollte nun DHCP und DNS sowie alle rollen vom 1. übernehmen (hat funktioniert)
3. neuen DC3 mit Server2008R2 installieren und mit dcpromo in bestehende strukur integrieren (so, ab nun kommen die probleme).
DC3 brachte nun folgende fehlermeldung:
Protokollname: File Replication Service
Quelle: NtFrs
Datum: 01.01.2010 21:14:01
Ereignis-ID: 13565
Aufgabenkategorie:Keine
Ebene: Warnung
Schlüsselwörter:Klassisch
Benutzer: Nicht zutreffend
Computer: DC3.meinedomänelocal
Beschreibung:
Der Dateireplikationsdienst initialisiert den Systemdatenträger mit Daten eines anderen Domänencontrollers. Der Computer "WICKY" kann nicht zum Domänencontroller benannt werden, bis dieser Vorgang beendet ist. Das Systemvolumen wird dann unter SYSVOL freigegeben.
Um die SYSVOL-Freigabe zu überprüfen, geben Sie an der Eingabeaufforderung folgendes ein:
net share
Wenn der Dateireplikationsdienst den Initialisierungsvorgang beendet, erscheint die SYSVOL-Freigabe.
Die Initialisierung des Systemdatenträgers kann einige Zeit in Anspruch nehmen. Der Zeitaufwand ist von der Datenmenge im Systemdatenträger, der Verfügbarkeit anderer Domänencontroller, und dem Replikationsintervall zwischen anderen Domänencontrollern abhängig.
also habe ich am DC2 (der ja in der Zwischenzeit der einzig verbleibende funktionierende Domänencontroller war) nachgesehen, und habe folgenden fehler entdeckt:
Ereignistyp: Fehler
Ereignisquelle: NtFrs
Ereigniskategorie: Keine
Ereigniskennung: 13568
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:\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.
so, und diesen registry-key habe ich nun gesetzt mit folgendem Ergebnis:
DC3 repliziert immer noch nicht (und wird daher auch nicht zum domänencontroller )
das liegt daran, dass die shares \sysvol und \netlogon bei jedem neustart verschwinden
und, was wesentlich schwerwiegender ist:
ich kann mich nun am DC2 nicht mal mehr anmelden (zumindest nicht remote).
einer der vorhanden fehler:
Der Domänecontrollername für das Computernetzwerk konnte nicht ermittelt werden. (Die angegebene Domäne ist nicht vorhanden, oder es konnte keine Verbindung hergestellt werden - Fehlercode 1054
ich komme zwar remote (als von einem anderen PC, auf den ich mich mit mstsc verbunden habe) in die computerverwaltung von DC2, leider aber nicht in die registry, um den eintrag zu entfernen.
fehlermeldung:
Ein Programm kann das erforderliche Dialogfeld nicht öffnen, da keine Pfade gefunden wurden...
weiss jemand rat, wie ich meine Struktur nochmal retten kann? Ich bin wirklich verzweifelt...
Danke im voraus für Eure Tipps!!!
lg
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 132593
Url: https://administrator.de/contentid/132593
Ausgedruckt am: 22.11.2024 um 01:11 Uhr
13 Kommentare
Neuester Kommentar
Servus,
kühlen Kopf bewahren und den folgenden Artikel durcharbeiten:
[LDAP://Yusufs.Directory.Blog/ - Dateireplikationsfehler mit der ID 13568]
http://blog.dikmenoglu.de/Dateireplikationsfehler+Mit+Der+ID+13568.aspx
Viele Grüße und Frohes Neujahr 2010
Yusuf Dikmenoglu
kühlen Kopf bewahren und den folgenden Artikel durcharbeiten:
[LDAP://Yusufs.Directory.Blog/ - Dateireplikationsfehler mit der ID 13568]
http://blog.dikmenoglu.de/Dateireplikationsfehler+Mit+Der+ID+13568.aspx
Viele Grüße und Frohes Neujahr 2010
Yusuf Dikmenoglu
hallo Yusuf!
danke erstmal für deine rasche Antwort. Ich wollte dann gestern nicht mehr weiterarbeiten, weil ich keinen klaren Gedanken mehr fand...
danke vor allem für deine spitzen Artikel!!! Ich hab sie schon verwendet, als ich den 2k8 (DC3) integrieren wollte (step-by-step-Anleitung).
danke auch für die ermunternden Worte!!!
meine Frage ist aber: wie soll ich mich überhaupt an der Maschine anmelden, um die im Artikel beschriebenen Maßnahmen einzuleiten?
Der Domänenadmin kann sich ja gegenüber dem DC nicht mehr authentifizieren, wiel die Domäne nicht verfügbar ist.
(Ich bin derzeit 500 Km vom DC entfernt und kann nur via mstsc zugreifen. Frage: sagt dir Deine Erfahrung, dass er mich lokal einsteigen läßt oder kann ich das ebenfalls vergessen?)
falls ein Anmelden generell auszuschließen ist, hätte ich noch eine Idee eines Plans B:
Ich kann mich hingegen noch am DC3 (2k8) anmelden, weil dieser ja noch kein vollwertiger Domänencontroller ist (weil ja die Replikation nicht funktioniert hat).
Gilt dieser Artikel auch für 2k8? (falls ja könnte ich ja das sysvol von DC2 (auf das ich ja noch zugreifen kann über das share c$) manuell replizieren und irgendwie dann den DC3 zu einem vollwertigen Domänencontroller machen)....
bin jedenfalls für alle antworten dankbar!
danke erstmal für deine rasche Antwort. Ich wollte dann gestern nicht mehr weiterarbeiten, weil ich keinen klaren Gedanken mehr fand...
danke vor allem für deine spitzen Artikel!!! Ich hab sie schon verwendet, als ich den 2k8 (DC3) integrieren wollte (step-by-step-Anleitung).
danke auch für die ermunternden Worte!!!
meine Frage ist aber: wie soll ich mich überhaupt an der Maschine anmelden, um die im Artikel beschriebenen Maßnahmen einzuleiten?
Der Domänenadmin kann sich ja gegenüber dem DC nicht mehr authentifizieren, wiel die Domäne nicht verfügbar ist.
(Ich bin derzeit 500 Km vom DC entfernt und kann nur via mstsc zugreifen. Frage: sagt dir Deine Erfahrung, dass er mich lokal einsteigen läßt oder kann ich das ebenfalls vergessen?)
falls ein Anmelden generell auszuschließen ist, hätte ich noch eine Idee eines Plans B:
Ich kann mich hingegen noch am DC3 (2k8) anmelden, weil dieser ja noch kein vollwertiger Domänencontroller ist (weil ja die Replikation nicht funktioniert hat).
Gilt dieser Artikel auch für 2k8? (falls ja könnte ich ja das sysvol von DC2 (auf das ich ja noch zugreifen kann über das share c$) manuell replizieren und irgendwie dann den DC3 zu einem vollwertigen Domänencontroller machen)....
bin jedenfalls für alle antworten dankbar!
Zitat von @Edi.Pfisterer:
meine Frage ist aber: wie soll ich mich überhaupt an der Maschine anmelden, um die im Artikel beschriebenen Maßnahmen
einzuleiten?
meine Frage ist aber: wie soll ich mich überhaupt an der Maschine anmelden, um die im Artikel beschriebenen Maßnahmen
einzuleiten?
Hmm... du könntest versuchen das Netzwerkkabel ziehen zu lassen und dich dann versuchen am DC als Domänen-Admin anzumelden.
Natürlich kommst du wenn das Netzwerkkabel gezogen nicht mehr drauf, dass müsste dann jemand für dich vor Ort übernehmen.
Hinterher änderst du dann das Domänen-Admin Kennwort.
Frage: sagt dir Deine Erfahrung, dass er mich lokal
einsteigen läßt oder kann ich das ebenfalls vergessen?)
einsteigen läßt oder kann ich das ebenfalls vergessen?)
Wie bereits geschrieben, wenn das Netzwerkkabel entfernt wurde gibt es durchaus eine Chance.
Gilt dieser Artikel auch für 2k8? (falls ja könnte ich ja das sysvol von DC2 (auf das ich ja noch zugreifen kann
über das share c$) manuell replizieren und irgendwie dann den DC3 zu einem vollwertigen Domänencontroller machen)....
über das share c$) manuell replizieren und irgendwie dann den DC3 zu einem vollwertigen Domänencontroller machen)....
Ja, der Artikel gilt für alle Serverversionen, denn die SYSVOL-Probleme haben sich in dieser Hinsicht bei den genannten EventIDs nicht geändert.
Halte dich aber haarklein an den Artikel und kopiere nicht händisch das SYSVOL. Benutzer dazu die BURFLAGS-Keys in der Registry (steht im Artikel).
Gruß, Yusuf
hallo!
danke vielmals für Deine Antwort, sie macht mir mächtig Hoffnung!
Eine vorerst letzte Frage habe ich noch, bevor ich mich in den nächsten Tagen doch auf den Weg zum Serverraum machen werde...
Durch diesen von mir vorgenommenen registry-eintrag hat er am DC2 (der einzige, der jemals funktionierte, es nun aber auch nicht mehr tut...) die Ordner "Scripts" und "Policies" bereits in den Ordner "NtFrs_PreExisting___See_Eventlog" verschoben und anschließend die shares entfernt.
Wenn ich Deine Anleitung also richtig verstehe, dann scheitere ich bereits beim ersten zu prüfenden Punkt
Es muss geprüft werden, auf welchem Domänencontroller in der Domäne, dass SYSVOL-Verzeichnis komplett
(Policies und Scripts Verzeichnis vorhanden?) und auch freigegeben ist. Ob das SYSVOL freigegeben ist, kann man z.B. in einer
Eingabeaufforderung (CMD) mit dem Befehl NET SHARE überprüfen. Es müsste unter anderem der Pfad „%systemroot%\Sysvol\sysvol“
mit dem Freigabenamen SYSVOL angezeigt werden.
Was nun?
Obwohl ich sicherlich 50 GPO's habe, könnte ich die gerne alle neu erstellen, wenn nur die Domäne irgendwie wieder funktionstüchtig wird...
(nicht zuletzt deshalb, weil ich bei einer kompletten Neuerstellung der Domäne [als letzter Ausweg] alle Mailboxen verloren wären... - oder gibts da einen Weg??)
Bin weiterhin für alle Anregungen dankbar!!!
lg
danke vielmals für Deine Antwort, sie macht mir mächtig Hoffnung!
Eine vorerst letzte Frage habe ich noch, bevor ich mich in den nächsten Tagen doch auf den Weg zum Serverraum machen werde...
Durch diesen von mir vorgenommenen registry-eintrag hat er am DC2 (der einzige, der jemals funktionierte, es nun aber auch nicht mehr tut...) die Ordner "Scripts" und "Policies" bereits in den Ordner "NtFrs_PreExisting___See_Eventlog" verschoben und anschließend die shares entfernt.
Wenn ich Deine Anleitung also richtig verstehe, dann scheitere ich bereits beim ersten zu prüfenden Punkt
Es muss geprüft werden, auf welchem Domänencontroller in der Domäne, dass SYSVOL-Verzeichnis komplett
(Policies und Scripts Verzeichnis vorhanden?) und auch freigegeben ist. Ob das SYSVOL freigegeben ist, kann man z.B. in einer
Eingabeaufforderung (CMD) mit dem Befehl NET SHARE überprüfen. Es müsste unter anderem der Pfad „%systemroot%\Sysvol\sysvol“
mit dem Freigabenamen SYSVOL angezeigt werden.
Was nun?
Obwohl ich sicherlich 50 GPO's habe, könnte ich die gerne alle neu erstellen, wenn nur die Domäne irgendwie wieder funktionstüchtig wird...
(nicht zuletzt deshalb, weil ich bei einer kompletten Neuerstellung der Domäne [als letzter Ausweg] alle Mailboxen verloren wären... - oder gibts da einen Weg??)
Bin weiterhin für alle Anregungen dankbar!!!
lg
hallo!
habe nun den Artikel "How to rebuild the sysvol tree and its content..." durchgearbeitet und dort vor allem Augenmerk auf How to temporarily stabilize the domain SYSVOL tree gelegt.
Ich habe anschließend über das C$-Share den Sysvol-Ordner kontrolliert, ob alle Parsing-Points sowie Subfolder vorhanden sind (wie hier beschrieben) und habe die Ordner "Policies" und "Scripts" wieder an den richtigen Ort kopiert (waren ja im NtFrs_PreExisting___See_Eventlog).
Dann habe ich über Remote-Computerverwaltung den Dienst NTFRS gestoppt und DISABLED sowie die Shares SYSVOL und NETLOGON erstellt.
Remote-Reboot des DC2 und:
Keine Veränderung der Situation
shares sind wieder verschwunden, obwohl der NTFRS gestoppt wurde. Zustand daher unverändert, "Domäne nicht vorhanden".
Die Ereignisanzeige von DC2 zeigt folgenden Eintrag von gestern:
Ereignistyp: Warnung
Ereignisquelle: NtFrs
Ereigniskategorie: Keine
Ereigniskennung: 13566
Datum: 02.01.2010
Zeit: 03:05:58
Benutzer: Nicht zutreffend
Computer: DC2
Beschreibung:
Der Dateireplikationsdienst liest die Daten in den Systemdatenträger ein. Der Computer "DC2" kann nicht zum Domänencontroller benannt werden, bis dieser Vorgang beendet ist. Das Systemvolumen wird
dann unter SYSVOL freigegeben.
Um die SYSVOL-Freigabe zu überprüfen, geben Sie an der Eingabeaufforderung folgendes ein:
net share
Wenn der Dateireplikationsdienst den Scanvorgang beendet, erscheint die SYSVOL-Freigabe.
Die Initialisierung des Systemdatenträgers kann einige Zeit in Anspruch nehmen. Der Zeitaufwand ist von der Datenmenge im Systemdatenträger abhängig.
Weitere Informationen über die Hilfe- und Supportdienste erhalten Sie unter http://go.microsoft.com/fwlink/events.asp.
Bin mit meinem Latein am Ende!!!!!!!!
Verstehe ich mein Problem richtig, dass die Authenifizierung gegenüber der Domäne nicht mehr funktioniert, weil die Default Domain Policy nicht mehr geladen werden kann, weil das SYSVOL nicht vorhanden ist?
Wie kann ich ihn dazu bewegen, den in der Ereignisanzeige genannten Scanvorgang als beendet anzusehen, und mir nicht die SYSVOL-Freigabe zu killen?
Kann es sein, dass der DC2 beim Eintrag BurFlags D2 hat und daher versucht, von DC3 zu replizieren, das aber nicht gelingt (weil dort noch kein sysvol vorhanden) und daher das share entfernt wird?
Kann der Registry-Eintrag "Enable Journal Wrap Automatic Restore", den ich mangels Zugriff auf die Registry von DC2 nicht entfernen kann, dafür verantwortlich sein?
(eigentlich aber - wenn ich die Sachlage richtig behirne - wohl eher nicht, da der Service NTFRS gestoppt ist, oder?
Falls obige Überlegung richtig ist: Welcher Dienst killt diese Freigabe dann?)
Könnte es Sinn geben, die Dateien aus dem SYSVOL-Ordner von DC2 manuell auf den DC3 zu kopieren, die Parsing-Points mit LINKD manuell zu erstellen und dann BurFlags auf D4 zu setzen?
Sysvol Share is missing
Aber: wird der DC3 dadurch auch ein Domänencontroller mit voller Funktionalität (was er ja derzeit nicht ist, was ich einerseits der Ereignisanzeige entnehme und andererseits daran erkenne, dass ich mich noch einloggen kann, weil er nur lokal und nicht gegenüber der Domäne authentifiziert...)
Generelle Frage:
Welcher Eintrag läßt einen Domänencontroller nach erfolgter Replikation zu einem vollwertigen Domänencontroller werden? (Denn daran scheiterts bei mir ja letztendlich, oder?)
What now?
Btw: Meine Verzweiflung hat ein neues Stadium erreicht ;-(
Danke für jede Anregung - Yusuf, hilf mir bitte!
Mit googlen komm ich leider nicht mehr weiter und aufs gerade Wohl herumzuprobieren ist - denke ich - generell gesehen keine gute Idee!
Ich denke, mir kann nur noch jemand mit dem nötigen und umfangreichen Basiswissen und der dazugehörigen Kombinationsgabe weiterhelfen...
Bitte, bitte, bitte!
habe nun den Artikel "How to rebuild the sysvol tree and its content..." durchgearbeitet und dort vor allem Augenmerk auf How to temporarily stabilize the domain SYSVOL tree gelegt.
Ich habe anschließend über das C$-Share den Sysvol-Ordner kontrolliert, ob alle Parsing-Points sowie Subfolder vorhanden sind (wie hier beschrieben) und habe die Ordner "Policies" und "Scripts" wieder an den richtigen Ort kopiert (waren ja im NtFrs_PreExisting___See_Eventlog).
Dann habe ich über Remote-Computerverwaltung den Dienst NTFRS gestoppt und DISABLED sowie die Shares SYSVOL und NETLOGON erstellt.
Remote-Reboot des DC2 und:
Keine Veränderung der Situation
shares sind wieder verschwunden, obwohl der NTFRS gestoppt wurde. Zustand daher unverändert, "Domäne nicht vorhanden".
Die Ereignisanzeige von DC2 zeigt folgenden Eintrag von gestern:
Ereignistyp: Warnung
Ereignisquelle: NtFrs
Ereigniskategorie: Keine
Ereigniskennung: 13566
Datum: 02.01.2010
Zeit: 03:05:58
Benutzer: Nicht zutreffend
Computer: DC2
Beschreibung:
Der Dateireplikationsdienst liest die Daten in den Systemdatenträger ein. Der Computer "DC2" kann nicht zum Domänencontroller benannt werden, bis dieser Vorgang beendet ist. Das Systemvolumen wird
dann unter SYSVOL freigegeben.
Um die SYSVOL-Freigabe zu überprüfen, geben Sie an der Eingabeaufforderung folgendes ein:
net share
Wenn der Dateireplikationsdienst den Scanvorgang beendet, erscheint die SYSVOL-Freigabe.
Die Initialisierung des Systemdatenträgers kann einige Zeit in Anspruch nehmen. Der Zeitaufwand ist von der Datenmenge im Systemdatenträger abhängig.
Weitere Informationen über die Hilfe- und Supportdienste erhalten Sie unter http://go.microsoft.com/fwlink/events.asp.
Bin mit meinem Latein am Ende!!!!!!!!
Verstehe ich mein Problem richtig, dass die Authenifizierung gegenüber der Domäne nicht mehr funktioniert, weil die Default Domain Policy nicht mehr geladen werden kann, weil das SYSVOL nicht vorhanden ist?
Wie kann ich ihn dazu bewegen, den in der Ereignisanzeige genannten Scanvorgang als beendet anzusehen, und mir nicht die SYSVOL-Freigabe zu killen?
Kann es sein, dass der DC2 beim Eintrag BurFlags D2 hat und daher versucht, von DC3 zu replizieren, das aber nicht gelingt (weil dort noch kein sysvol vorhanden) und daher das share entfernt wird?
Kann der Registry-Eintrag "Enable Journal Wrap Automatic Restore", den ich mangels Zugriff auf die Registry von DC2 nicht entfernen kann, dafür verantwortlich sein?
(eigentlich aber - wenn ich die Sachlage richtig behirne - wohl eher nicht, da der Service NTFRS gestoppt ist, oder?
Falls obige Überlegung richtig ist: Welcher Dienst killt diese Freigabe dann?)
Könnte es Sinn geben, die Dateien aus dem SYSVOL-Ordner von DC2 manuell auf den DC3 zu kopieren, die Parsing-Points mit LINKD manuell zu erstellen und dann BurFlags auf D4 zu setzen?
Sysvol Share is missing
Aber: wird der DC3 dadurch auch ein Domänencontroller mit voller Funktionalität (was er ja derzeit nicht ist, was ich einerseits der Ereignisanzeige entnehme und andererseits daran erkenne, dass ich mich noch einloggen kann, weil er nur lokal und nicht gegenüber der Domäne authentifiziert...)
Generelle Frage:
Welcher Eintrag läßt einen Domänencontroller nach erfolgter Replikation zu einem vollwertigen Domänencontroller werden? (Denn daran scheiterts bei mir ja letztendlich, oder?)
What now?
Btw: Meine Verzweiflung hat ein neues Stadium erreicht ;-(
Danke für jede Anregung - Yusuf, hilf mir bitte!
Mit googlen komm ich leider nicht mehr weiter und aufs gerade Wohl herumzuprobieren ist - denke ich - generell gesehen keine gute Idee!
Ich denke, mir kann nur noch jemand mit dem nötigen und umfangreichen Basiswissen und der dazugehörigen Kombinationsgabe weiterhelfen...
Bitte, bitte, bitte!
Jeder DC verhält sich erst dann als ein DC, wenn im Dateireplikationsprotokoll (falls das SYSVOL über FRS repliziert wird),
die EventID 13516 protokolliert wurde. Erscheint dieser Eintrag nicht, gibt sich der Server auch nicht als DC aus und verhält sich auch keineswegs als ein DC.
Du musst einen DC ausfindig machen, auf dem das SYSVOL-Verzeichnis einwandfrei vorhanden ist und korrekt funktioniert.
Wie du das herausfindest, beschreibe ich in meinem oben verlinkten Artikel.
Auf dem DC auf dem das SYSVOL korrekt ist, setzt du den Burflags Eintrag D4.
Auf dem DC der kein SYSVOL hat, trägst du Burflags D2 ein. Funktioniert SYSVOL nicht wie es sein muss, fungiert der Server nicht als DC.
Ich pflege zu sagen: SYSVOL-Probleme sind ecklige Probleme.
Was du tunlichst vermeiden solltest, kopiere nichts händisch im SYSVOL "herum".
Wenn alles ordnungsgemäß funktioniert, dann macht alles das System automatisch und ein "Hand anlegen" ist nicht notwendig.
Gruß, Yusuf
die EventID 13516 protokolliert wurde. Erscheint dieser Eintrag nicht, gibt sich der Server auch nicht als DC aus und verhält sich auch keineswegs als ein DC.
Du musst einen DC ausfindig machen, auf dem das SYSVOL-Verzeichnis einwandfrei vorhanden ist und korrekt funktioniert.
Wie du das herausfindest, beschreibe ich in meinem oben verlinkten Artikel.
Auf dem DC auf dem das SYSVOL korrekt ist, setzt du den Burflags Eintrag D4.
Auf dem DC der kein SYSVOL hat, trägst du Burflags D2 ein. Funktioniert SYSVOL nicht wie es sein muss, fungiert der Server nicht als DC.
Ich pflege zu sagen: SYSVOL-Probleme sind ecklige Probleme.
Was du tunlichst vermeiden solltest, kopiere nichts händisch im SYSVOL "herum".
Wenn alles ordnungsgemäß funktioniert, dann macht alles das System automatisch und ein "Hand anlegen" ist nicht notwendig.
Gruß, Yusuf
Hallo Yusuf!
Danke für Deine Antwort!!!!
Mein Problem ist es leider, dass ich nur noch eine Maschine habe, der schon einmal als DC funktionierte, aber das SYSVOL in diesem Ordner verschoben hat. Ein einwandfreies SYSVOL-Verzeichnis nach den Kriterien Deines Artikels könnte ich zwar herstellen, er würde aber immer noch nicht als DC funktionieren, da er ja nicht dein Eintrag 13516 aufweist.
Ist dies für die Replikation auf den anderen DC erheblich oder ausschließlich der Eintrag D4?
Falls D4 reicht: WELTKLASSE!!! dann dürfte ich die Domäne wieder zum Laufen bringen...
(Bitte um eine kurze Stellungnahme diesbezüglich - ein einfaches "D4 reicht" würde genügen
Falls D4 alleine nicht ausreichend ist, könnte folgendes Szenario sinn geben? (hier würde ein einfaches "AD sichern funktioniert" genügen
(Ich kann leider auf kein brauchbares Backup des Systemstate zurückgreifen)
1.) Nur das AD (ohne SYSVOL) von DC2 über das Backup Utility sichern und herunterfahren
2.) auf einer anderen Maschine einen Server neu zu aufzusetzen und gleich benennen wie den alten DC2
(müsste das ein 2008 R2 sein? habe das AD vor Auftreten meines Problems mithilfe Deines Artikels auf Schema-Version 47 umgestellt)
3.) auf diesem Server mit dcpromo eine vollständig neue Domäne (mit selbem Namen) zu installieren
4.) mit dem Backup Utility nur das AD aus der alten Domäne wiederherstellen
5.) die Gruppenrichtlinien neu erstellen
Falls beide Vorhaben wenig Sinn ergeben, würde ein einfaches "Pech gehabt" genügen
bin für JEDE Antwort dankbar!!!
lg
Danke für Deine Antwort!!!!
Mein Problem ist es leider, dass ich nur noch eine Maschine habe, der schon einmal als DC funktionierte, aber das SYSVOL in diesem Ordner verschoben hat. Ein einwandfreies SYSVOL-Verzeichnis nach den Kriterien Deines Artikels könnte ich zwar herstellen, er würde aber immer noch nicht als DC funktionieren, da er ja nicht dein Eintrag 13516 aufweist.
Ist dies für die Replikation auf den anderen DC erheblich oder ausschließlich der Eintrag D4?
Falls D4 reicht: WELTKLASSE!!! dann dürfte ich die Domäne wieder zum Laufen bringen...
(Bitte um eine kurze Stellungnahme diesbezüglich - ein einfaches "D4 reicht" würde genügen
Falls D4 alleine nicht ausreichend ist, könnte folgendes Szenario sinn geben? (hier würde ein einfaches "AD sichern funktioniert" genügen
(Ich kann leider auf kein brauchbares Backup des Systemstate zurückgreifen)
1.) Nur das AD (ohne SYSVOL) von DC2 über das Backup Utility sichern und herunterfahren
2.) auf einer anderen Maschine einen Server neu zu aufzusetzen und gleich benennen wie den alten DC2
(müsste das ein 2008 R2 sein? habe das AD vor Auftreten meines Problems mithilfe Deines Artikels auf Schema-Version 47 umgestellt)
3.) auf diesem Server mit dcpromo eine vollständig neue Domäne (mit selbem Namen) zu installieren
4.) mit dem Backup Utility nur das AD aus der alten Domäne wiederherstellen
5.) die Gruppenrichtlinien neu erstellen
Falls beide Vorhaben wenig Sinn ergeben, würde ein einfaches "Pech gehabt" genügen
bin für JEDE Antwort dankbar!!!
lg
D4 reicht 
beide Domänencontroller nun voll funktionsfähig!!!
JA JA JIPPIAIEEEEHHHH
zur Info, falls mal jemand das selbe Malheur hat wie ich es hatte:
Fehlerbeschreibung:
Domäne unerreichbar, da SYSVOL nicht mehr repliziert wird
Lösung:
auf irgendeinem 2. DC prüfen (nach YUSUFs Artikel), ob SYSVOL vorhanden ist und funktioniert
(falls dem nicht so sein soll, würde ich meinen, man kann es auch per Hand - wie beschrieben - herstellen und die beiden Gruppenrichtlinien
Registry-Key wie in Yusufs Artikel beschrieben auf D4 setzen
Done!
Abschließend:
DANKE YUSUF für Deine Ratschläge und Hinweise!!!
Habe wirklich sehr viel über die Funktionsweise von SYSVOL und FRS dazugelernt, obgleich ich dies unter anderen Umständen lieber getan hätte....
lg
beide Domänencontroller nun voll funktionsfähig!!!
JA JA JIPPIAIEEEEHHHH
zur Info, falls mal jemand das selbe Malheur hat wie ich es hatte:
Fehlerbeschreibung:
Domäne unerreichbar, da SYSVOL nicht mehr repliziert wird
Lösung:
auf irgendeinem 2. DC prüfen (nach YUSUFs Artikel), ob SYSVOL vorhanden ist und funktioniert
(falls dem nicht so sein soll, würde ich meinen, man kann es auch per Hand - wie beschrieben - herstellen und die beiden Gruppenrichtlinien
- Default Domain Controllers Policy {6AC1786C-016F-11D2-945F-00C04fB984F9}
- Default Domain Policy {31B2F340-016D-11D2-945F-00C04FB984F9} (Infos gibts hier
Registry-Key wie in Yusufs Artikel beschrieben auf D4 setzen
Done!
Abschließend:
DANKE YUSUF für Deine Ratschläge und Hinweise!!!
Habe wirklich sehr viel über die Funktionsweise von SYSVOL und FRS dazugelernt, obgleich ich dies unter anderen Umständen lieber getan hätte....
lg
Na also... wer sagts denn. Welch ein Erfolgserlebnis oder? Und vor allem der Lerneffekt dabei. Viel besser als....
Ich sagte es schon einmal: SYSVOL Probleme sind ecklige Probleme und können einem das Leben mehr als schwer machen.
Na dann, viel Erfolg weiterhin.
Gruß, Yusuf
Ich sagte es schon einmal: SYSVOL Probleme sind ecklige Probleme und können einem das Leben mehr als schwer machen.
Na dann, viel Erfolg weiterhin.
Gruß, Yusuf
hallo Yusuf!
Danke nochmal, auch für Deine abschließenden Worte!
Es ging in meinem Fall um eine recht große Infrastruktur (>350 Clients, >500 User, >50 GPO's, eine ganze Menge selbst gebastelter VB-Scripts, Exchange-Server, ISA + Scripts zum Sperren des Internetzugriffs einzelner User/Gruppen oder ganzer VLANs per Weboberfläche, Nagios, etc.), wäre also doch eine Mörderarbeit gewesen, alles wieder herzustellen... (vor allem bei Fehlen eines brauchbaren System-State-Backups)....
Bin wirklich happy!!!
Danke!!!
Danke nochmal, auch für Deine abschließenden Worte!
Es ging in meinem Fall um eine recht große Infrastruktur (>350 Clients, >500 User, >50 GPO's, eine ganze Menge selbst gebastelter VB-Scripts, Exchange-Server, ISA + Scripts zum Sperren des Internetzugriffs einzelner User/Gruppen oder ganzer VLANs per Weboberfläche, Nagios, etc.), wäre also doch eine Mörderarbeit gewesen, alles wieder herzustellen... (vor allem bei Fehlen eines brauchbaren System-State-Backups)....
Bin wirklich happy!!!
Danke!!!
Aber ein "neu installieren" der Domäne war doch zu keiner Zeit notwendig, sofern weitere DCs existieren und zumindest ein einziger ordnungsgemäß funktioniert.
Im schlimmsten Fall hätte man lediglich den "Problem-DC" herunter- und wieder heraufgestuft. Das aber auch nur dann, wenn ein "gesunder" DC existiert.
Ob jetzt die Umgebung aus 100 Users oder 100.000 besteht ist dabei egal. Die Vorgehensweise bleibt gleich.
Wichtig ist eben, dass min. ein zweiter DC existiert (ggf. mehr) und das SYSVOL auf einem anderen DC ordnungsgemäß vorhanden ist.
Gruß, Yusuf
Im schlimmsten Fall hätte man lediglich den "Problem-DC" herunter- und wieder heraufgestuft. Das aber auch nur dann, wenn ein "gesunder" DC existiert.
Ob jetzt die Umgebung aus 100 Users oder 100.000 besteht ist dabei egal. Die Vorgehensweise bleibt gleich.
Wichtig ist eben, dass min. ein zweiter DC existiert (ggf. mehr) und das SYSVOL auf einem anderen DC ordnungsgemäß vorhanden ist.
Gruß, Yusuf
Das war ja genau mein Problem, dass durch eine Verkettung unglücklichster Umstände zwischen meinem ersten Posting und dem von gestern KEIN DC mehr vorhanden war, der ordnungsgemäß funktionierte.
im Wesentlichen:
Situation vor meinem Problem: 2 DC
Der 1. DC, der alle Rollen inne hatte (+DNS + DHCP), hatte nur mehr 500 MB auf C: frei
(geerbtes Problem von meinem Vorgänger, der die Partitionsgrößen etwas "ungeschickt" wählte)
Lösung: zusätzlichen DC integrieren, der sollte 2k8R2 haben
daher: alles auf Schemaversion 47 umstellen. (Danke für Deine Anleitung, die habe ich bereits vor meinem ersten Posting verwendet)
Da der 1. DC diese Umstellung evtl. platzmäßig nicht verkraften würde, habe ich ihn mit dcpromo ordnungsgemäß heruntergestuft (lief auch einwandfrei)
nächster Schritt:
neuen DC mit dcpromo heraufstufen.
und nun nahm das Verderben seinen Lauf!
noch bevor der neue DC SYSVOL synchronisierte, hat sich SYSVOL auf dem zu diesem Zeitpunkt einzigen DC verabschiedet wegen JOURNAL WRAP (und ich habe auch noch etwas nachgeholfen durch den Eintrag des in der EventID vorgeschlagenen Registry_Keys, weil ich vor der Heraufstufung des neuen DC sicherstellen wollte, dass die Dateireplikation einwandfrei läuft.... DAMN! )
und von da an hatte ich eben leider keinen funktionierenden DC mehr, weil keiner der beiden DC mehr ein funktionierendes SYSVOL hatte...
workaround war nun (nach eingehender Studie Deines Artikels und etlicher M$-Seiten):
SYSVOL aus dem temp-ordner NtFrs_PreExisting___See_Eventlog des ursprünglich 2. DC manuell auf den neuen DC kopiert und Share manuell erstellt sowie dort D4 eingetragen.
NTFRS am neuen DC gestartet;
nun NTFRS remote am ursprünglich 2. DC gestartet (konnte mich ja nicht mehr einloggen), dieser hat nun vom neuen DC repliziert und den Eintrag EventID 13516 vorgenommen. Danach dürfte (hier bin ich nun im Bereich der Vermutung) der neue DC von diesem DC repliziert haben und hat ebenfalls EventID 13516 eingetragen.
Ende gut, alles gut
Prinzipiell hast Du natürlich recht, dass es keinen Unterschied macht, ob 5 oder 500 USER - was die Grundfunktionalität von AD betrifft.
Nur: mit einem SBS und 5 Usern hätte ich mir keine 50 Minuten den Kopf zerbrochen, sondern die Homeshares gesichtert, die Kiste neu aufgesetzt und spätestens 5 Stunden später läuft der Laden wieder...
Danke für Alles!!!!
Werde hinkünftig Deinen BLOG regelmäßig verfolgen.
LG aus Wien
im Wesentlichen:
Situation vor meinem Problem: 2 DC
Der 1. DC, der alle Rollen inne hatte (+DNS + DHCP), hatte nur mehr 500 MB auf C: frei
(geerbtes Problem von meinem Vorgänger, der die Partitionsgrößen etwas "ungeschickt" wählte)
Lösung: zusätzlichen DC integrieren, der sollte 2k8R2 haben
daher: alles auf Schemaversion 47 umstellen. (Danke für Deine Anleitung, die habe ich bereits vor meinem ersten Posting verwendet)
Da der 1. DC diese Umstellung evtl. platzmäßig nicht verkraften würde, habe ich ihn mit dcpromo ordnungsgemäß heruntergestuft (lief auch einwandfrei)
nächster Schritt:
neuen DC mit dcpromo heraufstufen.
und nun nahm das Verderben seinen Lauf!
noch bevor der neue DC SYSVOL synchronisierte, hat sich SYSVOL auf dem zu diesem Zeitpunkt einzigen DC verabschiedet wegen JOURNAL WRAP (und ich habe auch noch etwas nachgeholfen durch den Eintrag des in der EventID vorgeschlagenen Registry_Keys, weil ich vor der Heraufstufung des neuen DC sicherstellen wollte, dass die Dateireplikation einwandfrei läuft.... DAMN!
)und von da an hatte ich eben leider keinen funktionierenden DC mehr, weil keiner der beiden DC mehr ein funktionierendes SYSVOL hatte...
workaround war nun (nach eingehender Studie Deines Artikels und etlicher M$-Seiten):
SYSVOL aus dem temp-ordner NtFrs_PreExisting___See_Eventlog des ursprünglich 2. DC manuell auf den neuen DC kopiert und Share manuell erstellt sowie dort D4 eingetragen.
NTFRS am neuen DC gestartet;
nun NTFRS remote am ursprünglich 2. DC gestartet (konnte mich ja nicht mehr einloggen), dieser hat nun vom neuen DC repliziert und den Eintrag EventID 13516 vorgenommen. Danach dürfte (hier bin ich nun im Bereich der Vermutung) der neue DC von diesem DC repliziert haben und hat ebenfalls EventID 13516 eingetragen.
Ende gut, alles gut
Prinzipiell hast Du natürlich recht, dass es keinen Unterschied macht, ob 5 oder 500 USER - was die Grundfunktionalität von AD betrifft.
Nur: mit einem SBS und 5 Usern hätte ich mir keine 50 Minuten den Kopf zerbrochen, sondern die Homeshares gesichtert, die Kiste neu aufgesetzt und spätestens 5 Stunden später läuft der Laden wieder...
Danke für Alles!!!!
Werde hinkünftig Deinen BLOG regelmäßig verfolgen.
LG aus Wien
Hallo Yusuf & Edi,
ich hatte die tolle Idee, eine Fehlermeldung im NTFRS-Protokoll zu beseitigen, indem ich artig die in der Meldung beschriebene Aktion durchführte, die Datei NTFRS_CMD_FILE_MOVE_ROOT anzulegen und den Replikationsdienst neu zu starten. Die Meldung lautete:
Leider habe ich anschließend bemerkt, dass sich keine Anmeldung am Terminalserver mehr ausführen ließ, die Domain sei nicht vorhanden.
Tests am DC wieergaben die gleiche Meldung, hingegen gab den DC korrekt aus. Nachdem ich alle Einträge im DNS-Server gecheckt hatte fiel dann auf, dass ein schon länger nicht mehr existenter Server noch einige Male auftauchte. Ich bereinigte also alles und startete den Dienst mehrfach neu doch erhielt immer wieder nur die Meldung:
Also hatte ich als Ausgangspunkt nur noch 1 DC ohne funktionierendes SYSVOL. Wohl aber die Files, die hineingehörten, da MS hier glücklicherweise vorgesorgt und diese in das in der Meldung benannte Verzeichnis verschoben hatte:
Das war mein Glück. Ich kopierte diese nun wieder in das domain-Verzeichnis, stoppte den Dateireplikationsdienst, machte den Server zum Master (D4 als Wert für BurFlags) und startet den Dateireplikationsdienst.
Und siehe da:
und das machte mich nun glücklich:
Und das tat ich 
Somit steht fest, es geht auch für einen Server in genannter Konstellation.
Ich danke Euch für Eure Unterstützung!
LG aus Berlin
ich hatte die tolle Idee, eine Fehlermeldung im NTFRS-Protokoll zu beseitigen, indem ich artig die in der Meldung beschriebene Aktion durchführte, die Datei NTFRS_CMD_FILE_MOVE_ROOT anzulegen und den Replikationsdienst neu zu starten. Die Meldung lautete:
Der Dateireplikationsdienst hat ermittelt, dass ein Replikatstammpfad von "c:\windows\sysvol\domain" in "c:\windows\sysvol\domain" geändert wurde. Falls diese Änderungen absichtlich vorgenommen wurde, muss die Datei NTFRS_CMD_FILE_MOVE_ROOT im neuen Stammpfad neu erstellt werden. Leider habe ich anschließend bemerkt, dass sich keine Anmeldung am Terminalserver mehr ausführen ließ, die Domain sei nicht vorhanden.
Tests am DC wie
netdom query fsmo netdom query pdc Der Dateireplikationsdienst liest die Daten in den Systemdatenträger ein. Der Computer "SERVER2" kann nicht zum Domänencontroller benannt werden, bis dieser Vorgang beendet ist. Das Systemvolumen wird dann unter SYSVOL freigegeben. Also hatte ich als Ausgangspunkt nur noch 1 DC ohne funktionierendes SYSVOL. Wohl aber die Files, die hineingehörten, da MS hier glücklicherweise vorgesorgt und diese in das in der Meldung benannte Verzeichnis verschoben hatte:
Der Dateireplikationsdienst hat die vorhandenen Dateien in c:\windows\sysvol\domain nach c:\windows\sysvol\domain\NtFrs_PreExisting___See_EventLog verschoben. Und siehe da:
Der Dateireplikationsdienst hat diesen Computer dem folgenden Replikatsatz hinzugefügt:
"DOMAIN SYSTEM VOLUME (SYSVOL SHARE)" Der Dateireplikationsdienst verhindert nicht mehr die Heraufstufung des Computers "SERVER2" zum Domänencontroller. Der Systemdatenträger wurde erfolgreich initialisiert. Der Anmeldedienst wurde benachrichtigt, dass der Systemdatenträger jetzt als SYSVOL freigegeben werden kann.
Geben Sie "net share" ein, um die SYSVOL-Freigabe zu überprüfen. Somit steht fest, es geht auch für einen Server in genannter Konstellation.
Ich danke Euch für Eure Unterstützung!
LG aus Berlin
