Webdav folders – no full functionality

I recently got to work on a problem where MOSS 2007 SP2 was installed on a Windows 2008 machine. As you all know, Windows 2008 comes with IIS 7.

The problem we had at hand had 2 particular symptoms

a. If we tried to access a SharePoint document library using UNC path, we will get back an error: <path> is not accessible. You might not have permission to use this resource.

b. If we browse to the document library using a browser, then select Explorer view, right click, we will get only the option New > Folder. In other words, the options to create office documents and other types of files will not be present. A couple of screen shots of what is expected vs. What is available is given below

Expected	Actual

Scoping Step 1: One of the things to remember is that IIS 7 comes with a new WebDav module. It can be downloaded from www.iis.net or installed along with adding the IIS web server role. That WebDav module does not work well with SharePoint sites. You can remove it specifically for SharePoint sites using the steps mentioned in this previous blog post of mine. After I confirmed that the new WebDav module was not installed, we proceed to the next step.

Scoping Step 2: If you see only New > Folder option, that is a behaviour that usually occurs when MS FPRPC protocol is in use. WebClient service in prior versions of Windows does not work with ports other than 80. It is important to understand that this is a limitation of the WebClient service and not the WebDav protocol. So in such cases the option is to use FPRPC protocol. FPRPC does not allow the rich experience that WebDAV allows. By default, WebDAV is preferred over FPRPC so that the end user has a richer experience when interacting with the SharePoint system. Thus if you see the reduced functionality, it means one of the following:

• WebClient service is disabled on the computer which forces the client to use FPRPC
• The site you are accessing is over a non standard protocol. (Limitation of the WebClient service, not protocol)

In this particular case the configuration was correct. WebClient service was started and further proof to this was that when accessing a SharePoint document library in another farm via Explorer View/UNC path, the full functionality was available. So there was no reason to suspect the client configuration.

Scoping Step 3: At this point, I had verified the basics and got enough evidence to prove this is a server side problem. So the next logical step was to capture a network trace to view the underlying traffic. The steps on how to capture a network trace are available in an earlier blog post of mine.

Below is how the traffic looks like when I filter traffic by WebDAV protocol. I have highlighted in yellow, the things I look at when reading the trace.

As you can see, the response the server is sending for an OPTIONS request is an HTTP 404. Unfortunately, there will be nothing in the ULS logs that you can use to further debug this. We debugged this problem and found the root cause. So I am just going to give you the answer now. After all blog is a way to share our domain knowledge, right?

You will see this behaviour when accessing SharePoint document libraries if the root site collection does not exist. The behaviour is that the server will send back an HTTP 404 response to the client. This can be easily reproduced by deleting the root site collection. Thus, if you see the above symptoms and have gone through the basics, capture a network trace and check if you see the response pattern as 401, 401, 404. If so, use the Central Administration website to check if the root site collection exists. If it doesn’t, then you will see an option to select the root site “/” against the Web Site Address option in the Create Site Collection page.

RESOLUTION – Create the root site collection with a blank site. If you do not wish to use it, just restrict access to the farm administrator using permissions.