Partager via

Offline Files (CSC) Konzeptionierung

  • Article

Nach lange Zeit mal wieder ein Beitrag von Hubert aus unserem Netzwerk Team.

Heute geht es um das Thema Offline Files und was bei Aufbau eines dauerhaft funktionierenden Offline File Konzeptes zu beachten ist.

Hallo zusammen,

in letzter Zeit treffen bei uns vermehrt Support-Anfragen ein bei denen es um Offline Files Probleme geht. Die Symptome reichen von Clients, die nicht mehr Online kommen, die nicht Syncen können, die reihenweise Sync-Fehler und Konflikte werfen und Pfade die im SlowLink Modus nicht erreichbar sind, obwohl eigentlich keine Offline Files auf diesen Pfaden aktiviert sein sollten.

Diese Support Anfragen haben eines gemeinsam: Die Ursache der Probleme findet sich im verwendeten Offline Files Konzept und ist nur durch ein neues dauerhaft tragfähiges Konzept zum Einsatz der Offline Files zu lösen.
Die Migration von altem zu neuem Konzept zieht in aller Regel die Verwendung des FormatDatabase Registry Keys (https://support.microsoft.com/kb/942974/en-us) nach sich, da die Offline File Konfiguration auf dem Client oft komplett verstrubbelt und nur so zu bereinigen ist.
Dies wirft natürlich Fragen rund um das Backup von Clients auf, die unter Umständen seit Monaten nicht mehr erfolgreich syncen konnten und zieht somit oft monatelange Migrationsprojekte nach sich.
Um dies zu vermeiden, möchte ich mit diesem Blog den Admins dort draussen helfen, von vorneherein sinnvolle Offline Files Konzepte zu entwickeln, die dauerhaft funktionieren und die nötige Flexibilität bieten um zum Beispiel Daten auf der Fileserver Seite einfacher umziehen zu können.

Dies sind die Punkte die bei der Erstellung eines Offline File Konzeptes zu beachten sind.

1. Die 5 Wege der Offline Verfügbarkeit

Auf den folgenden 5 Wegen können Dateien in den Offline Cache des Clients gelangen, bzw. ein zugehöriges Scope und Partnerschaft innerhalb der Offline Files erstellt werden.
Über diese Wege müssen wir eine administrative Kontrolle erlangen und behalten.

a) Folder Redirection ohne Abschaltung des Offline Files Automatismus

Beim Einrichten einer Folder Redirection wird automatisch für jeden Umgeleiteten Ordner einzeln eine Offline Partnerschaft erstellt.
Durch setzen von „Do not automaticaly make Redirected Folders available Offline“ kann dieser Automatismus unterbunden werden.
Siehe https://gpsearch.azurewebsites.net/#293

b) Administrativ zugewiesene Offline Files

Per Group Policy können durch den Administrator Pfade vorgegeben sein, die vom Client Offline bereitgestellt werden müssen.

Siehe https://gpsearch.azurewebsites.net/#2056

c) Rechtsklick des Users auf Make Available Offline

Per Default kann der User zudem selber Pfade Offline bereitstellen.
Dies kann über die Policy Remove Make Available Offline Command verhindert werden um somit keine unvorhergesehenen Partnerschaften z.B. auf Gruppenlaufwerke zu bekommen.
Siehe https://gpsearch.azurewebsites.net/#2072

d) Caching Einstellungen auf dem File-Server Share

Auf jedem CIFS Share gibt es die Einstellungen: „Der Client kann Cachen“ (Default bei Windows), „Der Client muss Cachen“ und „der Client darf nicht cachen“.

Wenn ein Client auf ein Share zugreift, auf dem die Einstellung lautet „Der Client muss Cachen“, wird der Client in den Offline Files ein entsprechendes Scope und Offline File Partnerschaft anlegen, und die Daten vom Server heruntersynchronisieren.
Hier wären die Einstellungen auf den entsprechenden Shares zu prüfen.

e) LinkTargetCaching Verhalten bei Erzeugen einer .lnk Datei auf einem Offline Verfügbaren Pfad.

Per Default wird das Ziel einer .lnk Verknüpfung Offline Verfügbar gemacht, wenn die .lnk Datei selber auf einem Offline Verfügbaren Pfad liegt.
Ein User könnte Somit durch einen Shortcut in seinem My Documents Folder eine Scope für ein Gruppenlaufwerk erzeugenen, wenn er mit dem Shortcut dorthin verlinkt.
Das Verhalten kann über den Registry Key LinkTargetCaching kontrolliert werden.
Siehe https://support.microsoft.com/kb/817275/en-us

2. Berechtigungen auf der Fileserver Struktur

Der Offline File sync findet nicht (ausschliesslich) im Rechtekontext des angemeldeten Benutzers statt, da auch Offline Daten von anderen Benutzer gesynched werden müssen, obwohl der andere Benutzer nicht angemeldet ist.

Somit braucht Offline Files auf der Server Seite einen gewissen Satz an Mindest-Berechtigungen, damit ein Offline File Sync fehlerfrei stattfinden kann.
Diese Berechtigungen sind in https://support.microsoft.com/kb/2512089/en-usdokumentiert.

Hierbei wird zwischen Share Berechtigungen und NTFS Berechtigungen auf dem unter dem Share sitzenden Ordner, sowie der letzten Ebene in der der User dann seine Daten liegen hat, unterschieden.
Wenn wir per DFS auf diese Pfade zugreifen, gelten die Berechtigungen für das Share, den Ordner darunter bzw. die Pfade runter bis zu den Userdaten ab der ersten DFS-Root Ebene.

3. Scopes und gecachte Daten

Offline Files betrachtet \\Server\Share als ein Scope.
Jeder Zugriff auf einen UNC Pfad wird gegen die in den Offline Files hinterlegten Scopes geprüft. Erfolgt der Zugriff auf einen Pfad der als Scope in den Offline Files existiert, läuft der Zugriff durch die Offline File Logik, die steuert ob der Zugriff aus dem Cache oder vom Server bedient wird.
Daher ist ein Scope auch die Instanz die aus Sicht der Offline Files entweder Offline, oder Online ist.

Fällt, also das Scope \\Server\Share offline, so werden alle Zugriffe auf Daten unterhalb dieses Pfades in den Offline Cache umgelenkt.
Wurde jetzt jedoch nur ein Unterordner wie \\Server\Share\Daten\Offline_verfügbar Offline Bereitgestellt sind im Offline Modus nur Daten unterhalb dieses Ordners verfügbar. Daten auf anderen Pfaden wie \\Server\Share\Andere_Datensind im Offline Zustand nicht erreichbar, auch wenn der Client wie im Falle von Offline (Slowlink) eine Verbindung zum Server aufbauen könnte.

Somit empfiehlt es sich, Daten die Offline Verfügbar sein sollen, von den Pfaden her von Daten zu trennen, die nicht offline Verfügbar sein sollen.

Es hat sich in der Praxis bewährt Daten wie User Home Shares auf separate DFS Namespaces auszulagern.

4. Slowlink Mode und Background Sync.

Über die Policy Configure slow-link Mode kann für einzelne Pfade kontrolliert werden, ab welchen Schwellwerten für Latenz und Bandbreite die Offline Files das Scope in den Offline Modus schalten. Siehe https://gpsearch.azurewebsites.net/#2093

Es gilt zu bedenken, dass in Windows 7 auch ohne gesetzte Policy ein Default Wert für die Latenz von 80ms gilt.
Es ist zu beachten, dass in der Policy die Worte „Latency“ und „Throughput“ einzutragen sind. Die Registry kann kein Deutsch und somit mit den Worten „Latenz“ und „Durchsatz“ nichts anfangen.
Beim Einsatz von Offline Files auf DFS, kann für die DFS-Root ein sehr hoher Wert definiert werden, so dass die DFS Root selber nicht aufgrund der SlowLink Detection Offline geht.
Siehe auch den Blog meines Kollegen Ned Pyle zu diesem Thema:
https://blogs.technet.com/b/askds/archive/2011/12/14/slow-link-with-windows-7-and-dfs-namespaces.aspx

Im Offline zustand kann über die Policy Configure Background Sync gesteuert werden, in welchen Intervallen und mit welcher Varianz die Offline Files Änderungen auf Client und Server miteinander abgleichen. Siehe https://gpsearch.azurewebsites.net/#2095

Ebensowenig wie beim Foreground Sync (zum Beispiel aus dem SyncCenter heraus) kann beim Background Sync die verwendete Bandbreite eingeschränkt werden.

5. Umzug der Offline Verfügbaren Daten auf andere Pfade.

Dieses Szenario gilt es nach Möglichkeit zu vermeiden!

In https://support.microsoft.com/kb/977229/en-us sind abhängig von dem Weg der Offline Verfügbarkeit (Folder Redirection Automatismus vs. Jeder andere Weg) die zwei Supporteten Wege für einen Umzug beschrieben.
Beiden Wegen ist gemeinsam, dass dem KB Artikel penibelst gefolgt werden muss, und bei beiden Wegen eine zeitliche Abstimmungen zwischen Aktionen auf dem Client (Sync, Logoff, Logon) und Änderungen in der Infrastruktur (Setzen von Policies, Kopieren von Daten, etc.) gefordert ist.
Dies lässt sich erfahrungsgemäss schlecht bis garnicht automatisieren und ist „zu Fuss“ nur sehr schlecht für eine grössere Anzahl an Clients umsetzbar.
Daher wird dringend die Verwendung von DFS als Abstraktionsebene empfohlen, um bei einem Umzug der Daten, lediglich den DFS-Link auf das neue Ziel umsetzen zu müssen.
Beim Einsatz von DFS für Offline Files (und Roaming Profiles sowie mit DFSR) ist zwingend folgendes zu beachten:
https://blogs.technet.com/b/askds/archive/2010/09/01/microsoft-s-support-statement-around-replicated-user-profile-data.aspx

6. Zu Vermeidende Konfigurationen / Szenarios

Immer wieder stellen wir fest, dass bestimmte Daten auf mehreren Wegen Offline verfügbar gemacht wurden.
Zum Beispiel: Folder Redirection mit Offline Verfügbarkeit auf
\\Server\Share\Username\MyDocuments

Zusätzlich Administrativ zugewiesene Offline Files auf
\\Server\Share\Username

Somit ist der Unterordner MyDocuments auf zwei unterschiedliche Arten, also doppelt, offline Verfügbar gemacht.
Dies funktioniert nicht, bzw. führt zu diversen Fehlern während der Verwendung der Offline Files.

Ein weiteres Problem betrifft User die mehrere Maschinen gleichzeitig verwenden.
Zum Beispiel, ein Laptop mit Offline Verfügbarkeit und eine Desktop Maschine ohne Offline Verfügbarkeit.
Hier gilt es zu verhindern, dass der Offline Verfügbare Client zum Beispiel durch SlowLink Mode Offline fällt, da sonst der User auf dem Laptop eine Datei im lokalen Cache ändern könnte, während er gleichzeitig mit dem Desktop die selbe Datei auf dem Server verändert.
Sobald der Client wieder Online kommt, hätte er einen klassischen Sync-Konflikt.

Das selbe gilt für Daten an denen mehrere User arbeiten. Diese sind für den Einsatz mit Offline Files denkbar ungeeignet.

Es versteht sich denke ich von selbst, dass bevor Offline Files auf den Clients eingesetzt wird, die Clients nicht nur die aktuellen Security Updates sondern auch die aktuellsten Hotfixes für Offline Files, den Fileservice Client und die Shell installiert bekommt und ein Patch Management verwendet wird, dass diese Komponenten auch auf dem aktuellsten Stand zu halten.

Ich hoffe dies hat euch ein wenig weiter geholfen.
-Hubert

Comments