Heute stand ich vor einem äußerst kniffligen Problem: Ein SharePoint-Server, Version 2010, aber das tut nichts zu Sache, weil das gleiche Problem wohl auch bei allen anderen Versionen auftritt, funktioniert an sich recht gut. Man hatte auch schon eine ganze Menge an Dokumenten in Bibliotheken diversester Sites hochgeladen.
Nun wollten die Benutzer aber auf diese Dokumente auch mit dem Windows Explorer, also mit WebDAV zugreifen. In einem von 3 Fällen funktionierte das auch, aber was ist mit den anderen 2 Fällen? Nach den üblichen Troubleshooting-Maßnahmen (Netzwerk, Namensauflösung, Authentifizierung) stand ich ziemlich ratlos da. Dabei habe ich auch ein altes, aber sehr gutes Whitepaper zum Thema WebDAV in SharePoint entdeckt. Ein wirklich heißer Tipp für alle, die WebDAV-Probleme lösen wollen.
Doch das half mir auch nicht weiter. Also mussten die schweren Geschütze in Form eines Netzwerkmonitors aufgefahren werden. Dabei entdeckte ich ein sagen wir mal “eigenartiges” Verhalten des WebDAV-Clients von Windows: Versucht man den Inhalt von z. B. http://sharepoint/websites/sales abruft, versucht der Client Dateieigenschaften (PROPFIND-Methode) von http://sharepoint/websites abzurufen. Blöd nur, wenn es unter dieser URL gar keine Website gibt, weil es sich um einen Wildcard-Pfad handelt. Der IIS gibt dann einen 404er zurück und das war’s dann mit der schönen WebDAV-Verbindung.
Wie löst man das Problem dann? Durch einen Glückstreffer: Eigentlich kenne ich jede Menge SharePoint-Server, die zusätzliche Websitesammlungen in WildCard-Pfaden haben und bei keinem gibt es WebDAV-Probleme. Der Unterschied: Bei meinem Problemkind gibt es am Root-Pfad (im Beispiel http://sharepoint) auch keine Website. Also habe ich einmal im Root-Pfad eine Websitesammlung eingerichtet und – Bingo! WebDAV funktioniert jetzt auf den Clients.
Die Moral aus der Geschichte: Im Root-Pfad sollte man zwingend eine Websitesammlung einrichten, damit auch der eigenartige WebDAV-Client von Windows zufrieden ist.