Since upgrading to Windows Vista in June 2007, I’ve been having a hard time getting explorer view working in our SharePoint 2007 environment. Some of you might have seen this message, "Your client does not support opening this list with Windows Explorer."
In October 2007, a new entry on the SharePoint blog (http://blogs.msdn.com/sharepoint/archive/2007/10/19/known-issue-office-2007-on-windows-vista-prompts-for-user-credentials-when-opening-documents-in-a-sharepoint-2007-site.aspx) was posted which explained the issue. I had been using the fakeproxy workaround for a while (http://www.portalsolutions.net/Blog/Lists/Posts/Post.aspx?ID=27) but still had limited success with it. it seems it would work on some sites but most sites it wouldn’t work. After installing all of the hotfixes related to the issue and installing Vista SP1 which I hoped to fix the issue, I was able ready to give up on Vista.
I calmed down a bit and decided to try to figure this thing out and worst case is to call Microsoft for support. I knew my next step was to get out the packet sniffer (www.wireshark.org) and see if that help shed some light on things. The first thing I noticed when viewing the packets of a working explorer view was that it seems the webdav does a propfind for all directories under the current site you are trying to open in explorer view. For example, if I had a document library at http://site/usa/teams/IT/documents/ then vista would do a propfind at /, /usa, /usa/teams, /usa/teams/IT, and then finally /usa/teams/IT/documents.
But when I tried explorer view on a document library that didn’t work, it would do the propfind at / and then /usa but the server would respond 404 not found.
This was an issue for us because one of our managed paths was usa/teams. So apparently if it’s a normal managed path then sharepoint will respond to the propfind, but if there is a slash (/) in a managed path then sharepoint doesn’t know to respond to the propfind. I ended up having to create a site at the path /usa and that fixed my explorer view issues.
As it turns out, windows xp also does webdav this way, but when the webdav fails in windows xp, frontpage remote procedure call (fprpc) kicks in to display the explorer view but that wasn’t happening on my vista machine.