DFSN und Offline Files

Hallo zusammen,

hier nach längerer Zeit mal wieder Hubert mit Neuigkeiten rund um DFS.

Wie viele mittlerweile wissen, gelten beim Einsatz von Technologien wie Offline Files, Folder Redirection und Roaming Profiles auf DFSN (Distributed File System Namespace) ganz bestimmte Einschränkungen.
Diese sind im Detail hier zusammengestellt: https://blogs.technet.com/b/askds/archive/2010/09/01/microsoft-s-support-statement-around-replicated-user-profile-data.aspx

Um es kurz zusammenzufassen: Wenn wir für die oben genannten Technologien DFSN-Pfade verwenden wollen, darf nur ein Folder-Target (also nur ein Share) pro DFSN-Link eingetragen sein.

Wenn wir uns das folgende, kleine Beispiel anschauen wird auch klar, warum eine solche Konstellation nicht supported ist:
Wenn wir mehrere Shares hinter einem DFSN Link eingetragen haben, dann ist die implizite Erwartung, dass diese Shares miteinander replizieren. Ob diese Shares über DFSR, xcopy oder irgend einen anderen Mechanismus synchronisiert werden, ist für das Problem unerheblich.
Wenn wir nun auf einen solchen Pfad Offline Files aktivieren, dann eröffnen wir im Grunde einen zweiten Replikationskanal über den Offline Cache des Client.
Wenn also ein Failover eintritt, was selbst bei Bevorzugung eines Servers nicht ausgeschlossen ist, dann haben wir im besten Fall Replikationskonflikte und im schlechtesten Fall Datenverlust, bzw. wenn wir Teile des Userprofils per Folder Redirection oder Roaming Profiles auf‘s DFSN verschieben, können auch korrupte Userprofile dabei herauskommen.
Jeder der schon mal ein Problem, das durch korrupte Profile verursacht wurde, gejagt hat, kann ein Lied davon singen wie schön sowas ist.

Also: DON’T!

Dies führt uns also direkt zur Kernfrage dieses Blogs:
Wie kann ich verhindern, dass die User Offline Files auf DFS Pfade einschalten, die mehrere Folder-Targets haben?

Der erste instinktive Ansatz ist wahrscheinlich auf dem Client etwas zu konfigurieren, damit er diese Pfade vom Offline Caching ausschließt.
Es gibt zwar eine solche Policy („Prohibit `Make Available Offline` for these file and folders") aber diese gilt für „Windows XP Professional only“.
In Windows 7 gibt es nur die Möglichkeit bestimmte Dateitypen auszuschließen, aber nicht bestimmte Pfade. Dies nützt uns also hier nichts.

Wenn wir auf dem Client keine Möglichkeit haben, dann halt auf dem Server.
In den Eigenschaften des freigegebenen Ordners können wir in den Sharing Optionen einstellen, ob der Client sich die Daten Offline bereitstellen darf, die Daten Offline bereitstellen muss, oder keine Daten von diesem Share Offline Verfügbar gemacht werden dürfen.

...und nach klicken der Schaltfläche "Caching":

Anmerkung: Das hier beschrieben gilt für Windows Server. Viele 3rd Party Fileserver haben aber meines Wissens auch solche Einstellungen, allerdings unter anderem Namen.

Problem: Nun kann es mit dieser Einstellung aber passieren, daß es plötzlich länger dauert, bis ein DFSN Referral/Link verwendet wird. Woher kommt nun diese Verzögerung?

Wenn wir auf den Fileservern bzw. den Shares hinter einem DFSN-Link das Caching auf der Serverseite abschalten, dann passiert folgendes:
Der Client verbindet sich zum ersten Server in seiner Referral Liste, dann zum zweiten, dann zum dritten und immer so weiter, bis er entweder einen Server mit weniger restriktiven Caching Einstellungen gefunden hat (uneinheitliche Einstellungen sind nicht empfohlen), oder die Liste einmal durch ist.
In diesem Fall bleibt er dann zum ersten Server verbunden, aber eben erst nachdem er die Liste einmal durch ist.
Je nachdem wo die Fileserver stehen, kann dies einen "Moment" dauern.

Wenn wir uns (unter Win7/2008R2) ein “dfsutil cache referral” anschauen dann sehen wir dort als AccessStatus für die Server ein 0xc000003a was einem STATUS_OBJECT_PATH_NOT_FOUND entspricht. Dies ist der Fehlercode den DFSN von den Offline Files zurück bekommt und das ist ein Fehlercode der einen DFSN-Failover auslöst - sprich das zuvor beschriebene Abarbeiten der Referral-Liste und die damit verbundene Verzögerung.

Lösung: Wenn wir also ein solches Scenario einsetzen wollen, dann sollten wir das Hotfix aus Artikel “An unexpected network error occurred" error message when you try to browse a DFS folder in Windows 7 or in Windows Server 2008 R2”; https://support.microsoft.com/kb/2649905 installieren, damit die Offline Files ein STATUS_OBJECT_NAME_NOT_FOUND zurückliefern, was eben keinen Failover triggert.

Es ist halt ein kleiner aber feiner Unterschied, ob es einen Pfad oder Share nicht gibt, oder ein Objekt mit einem bestimmten Namen (wie z.B. desktop.ini) nicht existiert.

So, jetzt könnt Ihr steuern, welche Links nicht Offline gecacht werden können, damit Ihr wie oben beschrieben, im supporteten Rahmen bleibt.
Euer Hubert