SYSVOL Replikation mit DFSR, GPMC Import scheitert mit - The directory is not empty

Hallo, kurz vor Monatsende hier nochmal Rol. Heute zum Thema DFSR Replikation von SYSVOL und fehlschlagendem Import/Restore mittels GPMC.
Der Kunde hatte einen Fall eröffnet, daß der Import zunächst sporadisch, dann immer häufiger mit dem Fehler Popup “The directory is not empty” fehlschlägt.
Dazu wurde dann auch ein Applikationsevent 2002 geloggt, wie z.B.:

Log Name: Application
Source: Group Policy Management
Event ID: 2002
Task Category: None
Level: Error
Keywords: Classic
User: Contoso\GPOAdmin
Computer: MyDC1.contoso.com
Description:
Import of backup failed. Error [The directory is not empty.].
Details - Backup
Directory: The directory is not empty.

Das wurde im Zusammenhang mit der NTFRS - DFSR Migration beobachtet. Und tatsächlich – wurde DFSR kurz gestoppt, war der Fehler nicht aufgetreten.
Hatten wir versucht, den Fehlerfall mit dem ProcMon einzufangen, dann ist der Fehler durch das veränderte Timing jedoch auch nicht aufgetreten. Allerdings wurde durch das ProcMon Log deutlich, was die GPMC auf Datei- und Verzeichniss-Ebene so alles veranstaltet. Besipiel:

1:10:20.2481292 PM mmc.exe 6006 SetDispositionInformationFile \\MyDC1.contoso.com\SysVol\contoso.com\Policies\{A0635A64-4470-4C5B-97AD-9C76BE0752A2}\AdmOld NOT EMPTY Delete: True

Jetzt wurde es schon etwas klarer, die GPMC arbeitet mit Temporärdateien und –Verzeichnissen, die abschließend wieder entfernt werden sollen. Allerdings kann es bei ungünstigem Timing dazu kommen, daß sie sich dabei mit der DFSR Replikation in die Haare kommt. DFSR hat noch Handles offen, wenn die GPMC das Verzeichnis löschen möchte, es kommt zum Fehler “The directory is not empty”.

Als Lösungschritt haben wir uns zunächst angesehen, welche Arbeitsverzeichnisse die GPMC verwendet, siehe
929266 Morphed folders appear in the SYSVOL Group Policy folder after you use Group Policy Object Editor to view a GPO on a Windows Server 2003-based domain controller
https://support.microsoft.com/default.aspx?scid=kb;EN-US;929266

Demnach sind unsere Kandidaten also:

AdmOld
MachineOld
UserOld
MachineStaging
UserStaging

Da die GPMC diese Verzeichnisse nur temporär verwendet, macht es ja gar keinen Sinn, diese überhaupt replizieren zu lassen. Da DFSR zudem die Option anbietet, auch Verzeichnisse für einen "Replicated Folder" auszuschließen, war das unser nächster Lösungsansatz. Dazu passen wir das AD Attribut msDFSR-DirectoryFilter an. Für den Replicated Folder SYSVOL liegt es unter
CN=SYSVOL Share,CN=Content,CN=Domain System Volume,CN=DFSR-GlobalSettings,CN=System,DC=Contoso,DC=com

Bei NTFRS migriertem Sysvol war für msDFSR-DirectoryFilter schon enthalten:
DO_NOT_REMOVE_NtFrs_PreInstall_Directory,NtFrs_PreExisting___See_EventLog

Das haben wir dann mit unseren GPMC Verzeichnissen erweitert auf:
DO_NOT_REMOVE_NtFrs_PreInstall_Directory,NtFrs_PreExisting___See_EventLog,AdmOld,MachineOld,
UserOld,MachineStaging,UserStaging

Danach dem lokalen DFSR Dienst am DC noch Bescheid geben, daß sich etwas für ihn im AD geändert hat: DFSRDIAG POLLAD

Ergebnis: Da DFSR nun diese Verzeichnisse ignoriert, kam es wie erwartet zu keinen weiteren Fehlern beim GPMC Import.

Fazit:
Obwohl wir zwar die Lösung über die Anpassung von DFSR erreichen konnten, haben wir trotzdem gleichzeitig eine Änderung für das nächste OS Release der GPMC beantragt, mit der Änderung die Arbeitsverzeichnisse mit dem Flag FILE_ATTRIBUTE_TEMPORARY zu versehen, siehe https://msdn.microsoft.com/en-us/library/windows/desktop/gg258117(v=vs.85).aspx . Damit werden diese von DFSR ebenfalls ignoriert, ohne daß man jedoch eine separate Anpassung der DFSR Konfiguration machen muß.

Das gilt natürlich allgemein für jede Applikation, die aktiv auf einem DFSR Replicated Folder arbeitet, und bei der man vermeiden sollte, daß sich die Datenzugriffe mit DFSR ins Gehege kommen.

Damit gutes Gelingen!
Euer Rol

Aktualisierung, 21.März 2012

Anmerkung: Beim Einführen der Filter bitte darauf achten, daß in der Zeit bis die Filter Einstellung durch die AD Replikation propagiert ist und durch den DFSR Dienst (DFSRDIAG POLLAD /Mem:<Member> ) aufgenommen wurde, keine gefilterten Objekte eingeführt werden. Sonst kann es passieren, daß ein DFSR Member, der den Filter noch nicht kennt, ein Update einbringt, was bei Partnern zur Inkonsistenz zwischen DFSR Datenbank und Dateisystem führen kann.