Jaa

URLScan intereferes with WebDav

  • Artikkeli

This is by no means an all-encompassing blog entry about trouble-shooting WebDav with SharePoint, but this is a post about a single issue that I encountered and hope to help others with additionals toolsets in this area.

While assisting a customer with a new SharePoint Foundation 2010 environment we were having problems getting WebDav working. From a Windows 7 client he was getting the following error message:

 

<We also received an error from SharePoint Designer 2010 regarding a file not found, but at the moment I cannot reproduce that error>

I've found several blogs and information out there that says you need the IIS WebDav redirector installed in order for this to work in SharePoint, but you do not need that installed. We had also verified that this client had the Web Service Client running *and* that this client could do WebDav communications with other servers and even other SharePoint environments.

We took a network trace of a working environment and one of the failing environment and noticed that in the failing environment we were getting a 404 returned for the GET to the folder.  

Failing Trace:

260 <date time> <client> <server> WEBDAV WEBDAV:Request, OPTIONS /Shared%20Documents  {HTTP:40, TCP:39, IPv4:9}
264 <date time> <server> <client> WEBDAV WEBDAV:Response, HTTP/1.1, Status: Not found, URL: /Shared%20Documents  {HTTP:40, TCP:39, IPv4:9}

  Frame: Number = 264, Captured Frame Length = 905, MediaType = ETHERNET
+ Http: Response, HTTP/1.1, Status: Not found, URL: /Shared%20Documents , Using GSS-API Authentication
- WebDav: Response, HTTP/1.1, Status: Not found, URL: /Shared%20Documents
    WebdavPayLoad: 404 NOT FOUND

 

Success Trace:

1978 <date time> <client> <server> WEBDAV WEBDAV:Request, OPTIONS /Shared%20Documents  {HTTP:107, TCP:106, IPv4:71}
1979 <date time> <server> <client> WEBDAV WEBDAV:Response, HTTP/1.1, Status: Ok, URL: /Shared%20Documents  {HTTP:107, TCP:106, IPv4:71}

  Frame: Number = 1979, Captured Frame Length = 915, MediaType = ETHERNET
+ Http: Response, HTTP/1.1, Status: Ok, URL: /Shared%20Documents
  WebDav: Response, HTTP/1.1, Status: Ok, URL: /Shared%20Documents

What you'll see within the Internet Services Manager is the URLScan ISAPI filter loaded. This may be at the root level or on a specific site:

 

To remove this ISAPI filter, simply click to select it and then click Remove from the Actions pane on the right and click Yes on the confirmation dialog box. A restart should not be required for this change to take effect. Now you should be able to open SharePoint lists/libraries using WebDav from your client.

 

There is another possible solution to this symptom even if you do not have URLScan installed. I had a peer of mine discussing request filtering on IIS 7.5 that performs the same type functions as URLScan. To get to request filtering, open Internert Information Services Manager and navigate to the server level:

 

Double-click on Request Filtering to see if any of the HTTP Verbs have been filtered on this IIS Server:

 

 

 

SUMMARY:

If you are unable to get WebDav to work in your SharePoint environment, then there are several things to check including, but not limited to the list below:

  • Disable IIS WebDav (this is not needed, but has been reported to interfere with SharePoint)
  • Take a network trace -- if you see 404 responses to a folder request, then investigate URLScan or IIS Request Filtering
  • Be sure to update your client. All Windows clients have had updates to the webdav client files (XP, Vista, and Windows 7)
  • Review this whitepaper on Troubleshooting WebDav and FPRPC

 

Credits:

Thanks to the following for additional assistance in resolving this issue:

  • Christopher Haun (Microsoft Premier Field Engineer) - information leading to URLScan as the culprit
  • Dean Cron (Microsoft Premier Field Engineer) - additional information regarding URLScan and the fact that most of its functionality is actually included in IIS 7.5
  • Scott Manning (Microsoft Premier Field Engineer) - information showing that built-in IIS request filtering can cause the same symptoms