Debugging an Explorer View issue
During a recent SharePoint 2010 upgrade project, we applied SP1 and DEC 2012 CU & encountered a frustrating issue. Everything in the farm was working as expected after we did the installation & ran PSCONFIG, except for an issue where some users could not use Explorer View to open some Document Libraries.
More detailed user testing revealed that the issue only occurred for user who were using computers running Windows Vista or later. Windows XP users could open in explorer view without a problem.
WebDAV vs Front Page RPC
The reason for the OS disparity is due to the different protocols by which SharePoint will try to open in Windows Explorer. As it is explained in a Microsoft white paper from 2006 on SharePoint Explorer View:
“The Explorer View prefers WebDAV over FPRPC. Because of the underlying design of the Explorer View and the default network provider order, it always tries to use SMB first, then WebDAV. Only when SMB and WebDAV have failed does it actually attempt to use FPRPC. This means that forcing the Explorer View to use WebDAV is more a case of creating an environment that makes sure WebDAV is successful instead of actually forcing the Explorer View to choose it.”
While the WebDAV protocol relies on the Web Client Service, the FPRPC protocol does not, instead relying on WebFolders. WebFolders are disabled by default beginning in Windows Vista, but are available in Windows XP which explains why Explorer View worked in XP and not later Windows OS.
Compounding the confusion
This client was leveraging nested managed paths. This caused a secondary issue because the managed path contained a “”, causing the WebDAV protocol not to be able to parse the address. The fix simply involved creating a wildcard Managed Path for the first part of the compound address. So if you have a URL which is “statecounty” you would just add a managed path for “state” and explorer view via WebDAV will work. Here is what this would look like:
Take Away
The lesson here is to avoid using compound Managed Paths in your SharePoint web applications. If you absolutely must use compound managed paths be sure to add a wildcard path for the first part of the compound path.
Thank you’s
A big thank you to Todd Klindt, of Rackspace, for giving us some good leads & Evan Riser from my team for chasing this all the way down the rabbit hole to a resolution.