Mit DFSN auf ein WebDav (Sharepoint) Share verlinken

Hallo zusammen,

hier ist Hubert mit einem weiteren Beitrag rund um DFS-N.

Wie Ihr ja sicherlich wisst, kann man in einem DFS-Link einen UNC Pfad hinterlegen um damit auf das entsprechende Share des Fileservers zu verlinken.
Die Anforderung die das DFS hier stellt ist lediglich, dass es sich um einen Pfad nach dem Muster \\Server\Share handelt.
Ob der File-Server und der Client von den Protokollen her miteinander sprechen können, ist dem DFS vollkommen egal.
Das DFS ist im Grunde nur der Vermittler; quasi wie ein Telefonbuch. Und das Telefonbuch interessiert sich ja auch nicht dafür ob ein Anschluss-Inhaber Deutsch, Englisch oder Suomi spricht.

Da also das DFS lediglich einen Pfad nach dem Muster \\Server\Share braucht, können wir dort jede Ressource eintragen die für die Clients über einen solchen Pfad ansprechbar ist.
Und da wir ein WebDav Share auf einem Webserver oder eben auch ein WebDav Share von Sharepoint (zum Beispiel Shared Documents) über einen Pfad wie “\\Sharepoint\Shared Documents” ansprechen können, können wir diese auch ins DFS eintragen.

Wenn wir dies jedoch über die DFS-Management Konsole (2008 / 2008 R2) machen, wird uns die Konsole darauf hinweisen, dass es das Share bzw. den Server nicht erreichen konnte bzw. der Zugriff blockiert ist:

Hier bitte nicht verwirren lassen!
Die neue DFS-Management Konsole hat ein paar Prüfroutinen mit auf den Weg bekommen, die den DFS-Admin vor Flüchtigkeitsfehlern bewahren sollen.
Eine dieser Prüfungen ist zu schauen, ob ein Share, das wir in einem Link eingetragen haben auch existiert und sich der Admin nicht irgendwo vertippt hat.
Nun ist es aber so, dass die Maschine auf der wir die DFS-Management Konsole geöffnet haben nicht zwingend Zugriff auf den Pfad im Link hat.
Es kann sein das die Maschine an der wir Administrieren schlicht keinen Zugang zum Netzsegment der Fileserver hat, die Clients die die Fileserver benutzen aber sehr wohl oder eben der User Account mit dem wir administrieren keinen Zugang hat.
Im Fall eines WebDav Links ist es so, dass die Konsole den Pfad gar nicht finden kann, weil WebDav Shares keine „normalen“ Fileserver Shares sind und zum Beispiel bei einem „net share“ nicht aufgeführt werden.

Hier also nicht von der Prüfroutine ins Boxhorn jagen lassen und einfach die Meldung quittieren und kein neues Share mit dem Namen anlegen lassen (sonst haben wir ein Fileserver- und ein WebDav-Share mit dem selben Namen auf der selben Maschine).

Wenn wir nun unseren neuen WebDav link ausprobieren, werden wir wahrscheinlich über das nächste Problem stolpern:
(Bei Zugriff per DFS Pfad)

Um auf ein WebDav Share zugreifen zu können, brauchen wir einen WebDav Redirector.
Also eine Komponente die WebDav versteht und spricht.
Auf den Clients (XP / Vista / Win7) gibt es hierfür den WebClient Service.
Unter XP kann dieser jedoch nicht alles (zum Beispiel kann er kein https).
Bei den Servern sieht dies ein wenig anders aus.
Windows 2003 hat ebenfalls einen WebClient Service.
Windows 2008 und Windows 2008 R2 haben den WebClient Service nur wenn das Desktop Experience Feature installiert wurde.

Und warum funktioniert der Zugriff mit Windows 7 dann nicht?

Weil der WebClient nicht läuft.
Mit Windows 7 wurde der standardgemäße Starttyp des WebClient Dienstes auf manuell geändert, das heisst, er wird nach Bedarf gestartet.

Hierfür hat der WebDav Network Provider (https://msdn.microsoft.com/en-us/library/aa378775(v=VS.85).aspx) die Funktionalität bekommen den WebClient zu starten, wenn er erkennt, das wir auf einen WebDav Pfad zugreifen.
Deswegen funktioniert auch der direkte Zugriff per UNC Pfad nach einer kurzen Verzögerung.

Wenn wir jedoch über einen DFS-Link darauf zugreifen, ruft die MUP (https://msdn.microsoft.com/en-us/library/ff550860(v=VS.85).aspx) den DFS Client auf und ab dann sind andere Komponenten im Spiel und diese haben nicht die Möglichkeit den WebClient nach Bedarf zu starten.
Wenn der WebClient bereits läuft, zum Beispiel weil wir vorher einmal auf den UNC Pfad direkt zugegriffen haben, oder weil der Starttyp auf automatisch steht, dann klappt der Zugriff.
Läuft der WebClient nicht, schlägt der Zugriff mit einem ERROR_BAD_NETNAME fehl.

Bei Zugriff per Netzlaufwerk:

Hier ist also der einfachste Weg den Starttyp des WebClient auf Automatisch umzustellen:
„sc config webclient start= auto“

(Elevation nicht vergessen :) / und das Leerzeichen hinter dem „=“ auch nicht)

So!
Ich hoffe dies hat euch einen guten Überblick über DFS Links auf WebDav Shares gegeben.
Und nun viel Vergnügen dabei eure klassischen Fileserver mit euren Sharepoint- und Web-Servern in einer DFS Struktur zu verheiraten.

Euer Hubert