FRS repliziert C: \ WINDOWS \ SYSVOL \ domain \ scripts nach nicht autorisierender Wiederherstellung nicht

Wir führen mehrere Windows Server 2008 R2-Domänencontroller aus. Die Replikation von sysvol erfolgt durch NTFRS.

Gestern hat unser Master-DC einen "JRNL_WRAP_ERROR" für die SYSVOL-Aktie gemeldet. Ich habe ein chkdsk auf C: \ ausgeführt, aber es zeigte keine Probleme. Danach habe ich eine nicht autorisierende Wiederherstellung initiiert, indem ich ntfrs.exe gestoppt, BurFlags in HKLM / SYSTEM / CurrentControlSet / services / Ntfrs / Parameters / Backup \ Restore / Process beim Start auf "D2" gesetzt und ntrfs.exe erneut gestartet habe.

Dies scheint zwar für C: \ WINDOWS \ SYSVOL \ domain \ Policies zu funktionieren, zieht jedoch aus irgendeinem Grund keine C: \ Windows \ Sysvol \ domain \ -Skripte aus den anderen Domänencontrollern. Der Skriptordner enthält nach der nicht autorisierenden Wiederherstellung einige Verzeichnisse, die tatsächlich vorhanden sein sollen. Es enthält jedoch nicht alle und die darin enthaltenen sind unvollständig.

Ich habe auch C: \ Windows \ ntrfs \ jet umbenannt und die nicht autorisierende Wiederherstellung erneut gestartet, um Probleme im Zusammenhang mit dem Cache auszuschließen, aber es hat auch zu keinem Erfolg geführt.

Nach dem Neustart der nicht autorisierenden Wiederherstellung habe ich auch festgestellt, dass das Skriptverzeichnis seltsamerweise nicht in C: \ Windows \ SYSVOL \ domain \ NtFrs_PreExisting ___ See_EventLog angezeigt wurde , während dies im Verzeichnis Policies der Fall war. Ich nahm an, dass C: \ Windows \ SYSVOL \ domain \ einfach in diesen Ordner verschoben wird, aber es scheint nicht so einfach zu sein. Die Tatsache, dass Skripte weggelassen werden, lässt mich fragen, ob es eine Datenbank gibt, die den Inhalt in C: \ Windows \ SYSVOL \ domain \ verfolgt, sodass nur das verschoben wird, was es tatsächlich weiß.

Das Ereignisprotokoll hilft mir nicht viel. Es besagt, dass SYSVOL nach der nicht autorisierenden Wiederherstellung erfolgreich initiiert wurde.

BEARBEITEN: Im Moment haben wir dieses Problem behoben, indem wir AD auf dem betroffenen Server neu installiert haben. Während das Verzeichnis nach dem Entfernen gelöscht wurde, blieben C: \ Windows \ Sysvol \ domain \ scripts aus irgendeinem Grund erhalten - möglicherweise ein Problem mit Berechtigungen. Wir haben dann C: \ WINDOWS \ SYSVOL explizit gelöscht und AD erneut installiert.

Das Problem trat erneut bei einem anderen DC auf. Es stellte sich heraus, dass sich einige Dateien im Ordner C: \ Windows \ Sysvol \ domain \ scripts befanden - einige exe-Dateien wurden ausgeführt. NTFRs.exe konnte seine Aufgabe nicht ausführen.

ntrfsutl war nützlich, um dieses Problem zu beheben. http://support.microsoft.com/kb/822300/en-us ist sicherlich hilfreich. Ich habe ntrfsutl inlog verwendet , um den Status der übertragenen Dateien anzuzeigen . In meinem Fall befand sich der Skriptordner die ganze Zeit im Status IBCO_INSTALL_REN_RETRY . Ich habe dann alle Dateien, die Sperren enthielten, im Skriptverzeichnis (und seinen Unterverzeichnissen) gefunden. Dies waren einige Programme, die auch auf Client-Computern ausgeführt wurden (aber über die NETLOGON-Freigabe geöffnet wurden).

Sie können handle.exe von SysInternal Tools verwenden, um geöffnete Dateihandles zu identifizieren. In meinem Fall wurden einige Dateien durch den "System" -Prozess geöffnet. Diese wurden tatsächlich über die Netzwerkfreigabe von Clientcomputern geöffnet. Ich habe ihren Handle über compmgmt.msc geschlossen.

Nachdem alle geöffneten Handles geschlossen wurden, war die Replikation endlich erfolgreich.