Wie ein DFS Namespace NICHT aussehen sollte

Hallo zusammen, diesmal wieder Hubert mit einem weiteren Gastbeitrag diesmal zu DFSN.
Ich bin im Rahmen von Supportanfragen in letzter Zeit vermehrt über DFS Namespaces (DFSN) gestolpert bei denen leider ein paar Grundprinzipien von DFS ausser Acht gelassen wurden.
Zwei Dinge hatten all diese Namespaces gemeinsam:

• Die Daten (also das was eigentlich auf dem Fileserver Share liegen sollte) lagen im DFS-Root Share.
• Es gab diverse Probleme mit diesen Namespaces oder den Daten dahinter.

Daher möchte ich mit diesem Beitrag erklären, warum Daten in der DFS-Root problematisch sind und wie man es besser macht.

Ich setze im Folgenden einige Kenntnisse zu DFS voraus.
Der Technet Artikel „How DFS Works“ vermittelt solide Grundlagen Kenntnisse zu DFS: https://technet.microsoft.com/en-us/library/cc782417(WS.10).aspx

Im Umgang mit DFS Namespaces ist es enorm wichtig, die einzelnen Server-Rollen gedanklich zu trennen, auch wenn alle oder manche auf der selben Maschine laufen.

Wir unterscheiden:

• Domain Controller (nur im Falle von Domain-DFSN interessant)
• DFSN Server
• Fileserver

Im Falle eines Domain-DFS nennen die Domain Controller den Clients die für den angefragten Namespace zuständigen DFSN-Server.
Bei einem Standalone DFS sprechen die Clients den DFSN-Server direkt über seinen Server-Namen an.

Die DFSN-Server benennen den Clients das \\Fileserver\Share für den jeweils abgefragten DFS-Link.

Sobald der Client den Fileserver kontaktiert spricht er nur noch mit diesem und DFSN ist bis zum nächsten Klick auf den Namespace aussen vor.

Jeder der DFSN-Server legt sich auf seiner lokalen Festplatte (normalerweise C:\DFSRoots) ein Abbild des Namespaces an, damit er den Clients eine schöne Ordner Struktur zur Anzeige im Windows Explorer geben kann.
Es gibt eigentlich keinen Grund diese Struktur woanders hin zu verschieben (kann beim Hinzufügen eines DFSN Servers angegeben werden), da die gesamte Struktur, auch bei grossen Namespaces nur wenige Kilobyte verbraucht.
Ein erstes Indiz für die oben beschriebene Fehlkonfiguration ist meist, dass diese lokale Repräsentation aus Platzgründen! auf eine andere Platte verschoben wurde.

Diese lokale Repräsentation sieht normalerweise wie folgt aus:
Unter C:\DFSRoots gibt es einen Ordner der heisst wie der zugehörige Namespace, also zum Beispiel:
C:\DFSRoots\DFSNamespace1

Dieser Ordner ist unter dem selben Namen als Share frei gegeben. Das Share würde also dann heissen:
\\DFSNServer1\DFSNamespace1

Unterhalb dieses Ordners befinden sich je nach Struktur des Namespaces weitere Ordner (sog. Intermediate Folders) die die Reparse Points (lokale Repräsentation eines Links) enthalten, oder die Reparse Points befinden sich bei einer Flachen Struktur direkt unterhalb des Namespace Root Folders.
Hier ist also 1:1 die Struktur Abgebildet wie wir Sie aus der DFS Management Console kennen.
Wenn wir lokal auf einen solchen Reparse Point browsen bekommen wir eine Fehlermeldung, da diese nur bei einem Zugriff über Netzwerk funktionieren.
Also:
C:\DFSRoots\DFSNamespace1\Link1     <-   Reparsepoint also Fehlermeldung
\\DFSNServer1\DFSNamespace1\Link1 <-   Link also Weiterleitung zum zugehörigen Fileserver Share

Ein weiteres Symptom für obige Problematik ist, dass der Namespace gar keine oder nur sehr wenige Links enthält und stattdessen in dieser lokalen Struktur meist direkt Unterhalb des Namespace Root Folders diverse Ordner liegen die die Daten enthalten.

Und genau das ist unser Problem.

Im Folgenden versuche ich zu erklären warum Daten in der DFS Struktur ein Problem sind:

1. Problem: Service Startup

Der DFS-Service (dfssvc) enumeriert beim Start alle Objekte in dieser Struktur um herauszufinden, welche davon Links sind und welche nicht.
Anhand der Informationen im AD (Domain DFS) bzw. Registry (Standalone DFS) packt er jeden der Reparse Points einmal an und erzeugt neue Reparse Points für neu hinzugekommene Links.
Anschliessend prüft er welche der Links ein Last-Modified Timestamp haben das älter ist als das Service Startup Timestamp. Diese Links werden dann als „orphaned“ (verwaist) gelöscht.
Die Logik dahinter ist: Jeder Link der in AD/Registry existiert ist beim Start einmal angepackt worden. Ein Link der nicht angepackt wurde, existiert demzufolge in AD/Registry nicht mehr und kann somit gelöscht werden.
Wenn wir nun in dieser Struktur viele Daten und somit Objekte liegen haben zieht sich der Service-Startup Vorgang unnötig in die Länge.

2. Problem: Berechtigungen

Diese Struktur ist absolutes Hoheitsgebiet des DFS-Service. Seit Windows 2008 kann der DFS-Service bei einem V2 oder Standalone Namespace dort Berechtigungen anhand dessen vergeben, was ihm konfiguriert wurde.
Siehe hierzu auch: https://technet.microsoft.com/en-us/library/dd759150.aspx?wa=wsignin1.0

Im Umkehrschluss bedeutet dies, das alle Berechtigungen, die jemand anderes als der DFS-Service auf diese Struktur gesetzt hat (also auch die die ein Admin gesetzt hat) rausfliegen und durch das ersetzt werden, was in AD bzw. Registry hinterlegt ist.
Ohne https://support.microsoft.com/kb/2464365 macht der DFS-Service dies auch bei V1 Namespaces.

Extrem ärgerlich wenn man dann zum Beispiel Userprofile statt auf dem Fileserver-Share wo sie hingehören in den DFS-Root Folder gelegt hat und dort die Berechtigungen verändert werden. Dass die Profile nicht sauber zurückgeschrieben werden können, ist dann vermutlich das kleinste Problem.
Ansonsten gilt hierbei natürlich auch wieder:
https://blogs.technet.com/b/deds/archive/2010/10/19/dfsr-support-aussage-bzgl-serverbasierten-benutzerprofilen-und-basisordnern.aspx

3. Problem: Replikation

DFSN Repliziert keine Daten. Hat es noch nie, und wird es auch nicht.
Alle Domain DFSN-Server holen sich die Konfiguration aus dem AD. Dort ist Sie gespeichert, dort wir Sie verändert und von dort repliziert die Konfiguration zu den einzelnen DFSN-Server.
Jeder dieser DFSN-Server legt dann wie oben beschrieben bei sich selber die nötigen Strukturen an.
Etwaige Daten in dieser Struktur werden nicht zwischen den DFSN-Servern repliziert.
Wenn ich also in obiger Fehlkonfiguration Daten auf den Server \\DFSNServer1 lege werden diese niemals auf \\DFSNServer2 zu sehen sein.
Es sei den…

4. Problem: DFSR

Ja, Es sei denn ich mache das Ganze noch schlimmer und setze mit DFSR (oder einer anderen Replikations Technologie) eine Replikation zwischen den DFS Root Shares zweier DFSN-Server, also zum Beispiel
\\DFSNServer1\DFSNamespace1
und
\\DFSNServer2\DFSNamespace1
auf.
Dann haben wir zusätzlich zu den obigen Problemen auch noch eine Replikations Technologie, die versucht Reparse Points, Daten und Berechtigungen von einem Server auf den anderen zu schieben, während der DFS-Service versucht Ordnung in dieser Struktur zu wahren (alte Links löschen, neue anlegen) und die ihm konfigurierten Berechtigungen sicherzustellen, während nebenher vielleicht noch ein Admin per Skript regelmäßig die Berechtigungen neu setzt (da die ja immer wieder verschwinden) und die User auf ihren Daten arbeiten und diese ändern.
Also ich weiss nicht wie es euch geht, aber ich kann nicht vorhersagen, was dann passiert, wer gewinnt und welche Symptome alle zu sehen sind.
Aber eins kann ich mit Sicherheit sagen: Zuverlässig funktionieren wird das nicht.

Also nachdem wir nun wissen, wie man‘s nicht macht, wie geht’s denn dann richtig?

Hier ist die Antwort:

1. Nach Möglichkeit die lokale Struktur des DFS-Service auf C:\DFSRoots (genauer %Systemdrive%\DFSRoots) belassen.
Der einzige Grund der mir einfällt diese Struktur nicht auf der Systempartition zu belassen wäre wenn dort eine sehr langsame HardDisk dahinter steht, und wir sehr viele Zugriffe auf die DFS Struktur bewältigen müssen. Dann stellt sich mir aber die Frage ob die Maschine mit einer so langsamen Platte grundsätzlich als DFSN-Server für einen solchen Namespace geeignet ist.

2. Files gehören auf den Fileserver bzw. in ein eigenes Share.
Wir können ohne Probleme einen DFS-Server auch als Fileserver einsetzen.
In diesem Fall müssen die Daten aber in einem eigenen Share liegen.
Nehmen wir an \\Server\DFSNamespace ist unser DFS.
Dann erzeugen wir ein weiteres Share zum Beispiel \\Server\Data mit einem Link im Namespace ( \\Server\DFSNamespace\Link1) verweisen wir dann auf \\Server\Data
Wenn wir nun Berechtigungen Administrieren müssen können wir dies auf dem Fileserver Share ( \\Server\Data) wie gewohnt machen und müssen dies nicht mehr in der DFS-Struktur tun, wo der DFS-Service sein Hoheitsgebiet hat.
Ausserdem können wir dann ohne Probleme eine Replikation von \\Server\Data mit einem anderen Server  z.B. \\BackupServer\Data einrichten.

Kleine Anmerkung am Rande:
Wenn Ihr eine Replikation mit DFS-R für Shares einrichten wollt, die in einem DFS-N eingebunden sind, dann tut dies bitte über den DFS-R  Ast in der DFS Management Konsole und NICHT über den Wizzard, der im Anschluss an die Einrichtung eines DFS Links mit zwei Zielen aufpoppt.
Mit dem Wizzard schafft ihr euch eine künstliche Abhängigkeit zwischen DFS-N und DFS-R wo eigentlich keine ist.

Und ganz allgemein, beim Einrichten von DFSN Strukturen zusammen mit DFSR, bitte den Artikel zur Supportability beachten:
Information about Microsoft support policy for a DFS-R and DFS-N deployment scenario; https://support.microsoft.com/kb/2533009

So!
Ich hoffe das hat euch eine gute Übersicht gegeben, wie ein Namespace aussehen kann und wie er definitiv nicht aussehen sollte, bzw. zu welchen Problemen dies führt.

Gruss
Euer Hubert