Your client does not support opening this list with Windows Explorer error

The dreaded Your client does not support opening this list with Windows Explorer error. I have seen a couple of times eventually discovering new causes of this error message. But the Internet is a good source solving this, after doing a couple of cross tests and research.

Basically you get this on your client when you try to open a document library with explorer (Open with explorer button on the ribbon on the Library tab) and something went wrong.

Your client does not support opening this list with Windows Explorer

Generally speaking

SharePoint is a monster, and a cause of a problem can be in any layer of the topology in any part of your infrastructure. To tackle this you have to do a couple of cross test to eliminate possible causes and narrow down to a particular element in your infrastructure. The questions you want to find answers for are the following:

• Is this only one client machine, multiple ones, or all of them?
• Do the client machines affected by this problem have anything in common?
• Are there anything in between your server and clients? (Firewalls, proxy, etc) Try the same connection without these if possible to exclude them.
• If you have multiple servers in your SP farm (like multiple front ends) do they all affected or only a subset?
• Did you do any patch installation or upgrade on your farm recently?

Answering these questions and testing will turn your focus on a particular point in your infrastructure and your next steps depends on the results.

I just mention a couple of causes of this error I met recently, might be helpful:

• On the client WebClient service is not running, it is actually disabled. This is very common and easy to identify and solve
• You use an unsupported or old browser
• You have WebDav publishing role service on your IIS installed
• WebDav commands are filtered on a firewall between servers and clients
• URL scan is installed on server and misconfigured, for example webdav commands are disabled

And plenty of other cause exists in the wild.

A strange problem

One in particular I want to share which puzzled me for a while was this strange behaviour:

• User tried to open explorer view from a client and for the first time worked perfectly
• But the second time he always got this error

I tried all the known solutions I knew without a success so I did a search and found the following post, which sounded like my problem: http://stackoverflow.com/questions/8926551/your-client-does-not-support-opening-this-list-with-windows-explorer

Nobody posted a solution so I decided to troubleshoot it.

My first step is always the event viewer. If something really bad happens on SharePoint, it is logged in there too, so always keep an eye on them. In this case no error message or even a warning happened.

The next step is the ULS log. This can be tedious because on a busy system there are plenty of entry and it is hard to find related ones. I always recommend using ULSViewer to filter logfiles: http://archive.msdn.microsoft.com/ULSViewer/

My initial search for error did not reveal anything so my idea was to find the entries related to the successful try and entries related to the unsuccessful try and compare the flow side by side.

Well the difference was… huge.

ULS log of the successful try, it contains plenty of OPTIONS and PROPFIND requests

The successful trace contained plenty of entries with OPTIONS and PROPFIND for various URLs under the site collection, while the other one contained only these lines:

Name=Request (PROPFIND:http://letitknowext:80/)
Leaving Monitored Scope (Request (PROPFIND:http://letitknowext:80/)). Execution Time=3.86557509404128
Entering monitored scope (Request (PROPFIND:http://letitknowext:80/))
Name=Request (PROPFIND:http://letitknowext:80/)
HTTP Request method: PROPFIND
HTTP request depth header: 0
Overridden HTTP request method: PROPFIND
HTTP request URL: /
HTTP request translate header: f
Leaving Monitored Scope (Request (PROPFIND:http://letitknowext:80/)). Execution Time=28.7151020590606

Luckily I turned failed request tracing on and configured it before I did the tests, so I checked them.

Turn on Failed Request Tracing it is an extremly useful troubleshooting tool in IIS

Failed Request Tracing saved me a couple of times – an extremely useful tool, that contrary to its name, traces both successful and unsuccessful requests and tells you lots of information.

There were plenty of files related to the first attempt and only two belonging to the second so opened them eagerly. The first did only tell me that it needs authentication and try again, but the second was very interesting.

Server responds 404

Spot the final status, finally, an error message! The status code was 404 which means the server could not find the requested resource. Checked the request and realised it is nothing special, just went for the root URL of the web application which does not exists based on the trace…

Client requested the root site collection

I could not reached it using a browser so went to central admin to confirm this. And yes, there were no root site collection on this web app. After I created one, the problem disappeared.

Another possible cause for this “famous” error message is the lack of a root site collection!  Don’t forget to create it.