4

Our client has recently moved to a new SharePoint 2013 farm from another SharePoint 2013 farm trying to fix corruption on the web front end. Some servers from the old farm were used in the new farm. In doing this move, there have been several issues. The most pressing is that WebDav is not working on SharePoint document libraries.

In comparing Fiddler requests/responses with a working WebDav SharePoint 2013 environment, we have found that PROPFIND request to the library URL, result in redirect responses to the "Forms/AllItems.aspx" page which is not what we want. It seems like there is some server-side setup that is messed up.

Here is the request with the Host and Authorization headers removed:

PROPFIND http://somedomain.com/Lists/SomeDocuments HTTP/1.1
User-Agent: Microsoft-WebDAV-MiniRedir/6.1.7601
Depth: 0
translate: f
Connection: Keep-Alive
Content-Length: 0

Here is the entire response:

HTTP/1.1 302 Redirect
Content-Type: text/html; charset=UTF-8
Location: http://somedomain.com/Lists/SomeDocuments/Forms/AllItems.aspx
Server: Microsoft-IIS/8.0
X-SharePointHealthScore: 0
SPRequestGuid: 5d80019d-bb49-5008-c154-025bfa963df1
request-id: 5d80019d-bb49-5008-c154-025bfa963df1
X-FRAME-OPTIONS: SAMEORIGIN
SPRequestDuration: 28
SPIisLatency: 0
Persistent-Auth: true
X-Powered-By: ASP.NET
MicrosoftSharePointTeamServices: 15.0.0.4569
X-Content-Type-Options: nosniff
X-MS-InvokeApp: 1; RequireReadOnly
Date: Wed, 29 Apr 2015 15:43:35 GMT
Content-Length: 188

<head><title>Document Moved</title></head>
<body><h1>Object Moved</h1>This document may be found <a HREF="http://somedomain.com/Lists/SomeDocuments/Forms/AllItems.aspx">here</a></body>

Note that the "/Lists" in front of the document library in the URL is there on purpose. The libraries were set up this way and WebDav was working with this setup prior to moving from one farm to another.

Any suggestions would be most appreciated!

UPDATE: When looking at the authentication provider (in the Default zone), it is just using Windows auth (NTLM) and we have "Require Use Remote Interfaces permission" checked as well as "Enable Client Integration" set to "yes". We have been testing with a site collection administrator, so it should have the remote interfaces permission.

Improve this question

1 Answer 1

Reset to default
0

The answer for us was removing the URLScan ISAPI filter. We don't know how this was put there; it might have been part of the base VM image provided by IT. For more details see:

http://blogs.msdn.com/b/briangre/archive/2011/11/17/urlscan-intereferes-with-webdav.aspx

We also thought that the "WebDav Publishing" server role was to blame, but that wasn't the case for us. IT could be for others, so I will explain further... It turns out that you can add that role in Windows Server 2012 (found at: Web Server (IIS) > Web Server > Common HTTP Features > WebDav Publishing). However, just adding that role does not cause a problem. Once that role is added it is available to be enabled for your IIS website. If you enable it for your IIS website that is associated to a SharePoint web app, then it does cause WebDav to fail for SharePoint. In our case, we had the role added, but did not have the feature enabled in IIS so it was not a problem for us.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.