Explorer View in Sharepoint

Enable WebDav on your IIS front end servers.  

There is a discussion of other techniques you can try here:
http://social.msdn.microsoft.com/Forums/sr-Latn/sharepoint2010general/thread/e9a07773-db23-46e9-8d1d-7015cd5aa13b

So you are saying this is server side?

Could be - it was on SP 2010/ Server 2008 when I had problems.
(webdav  has completely changed for 2008)

http://social.technet.microsoft.com/Forums/en-US/sharepointgeneral/thread/023f4b23-3ce6-4d83-8cb0-7398b88ba6ab/

Here is lots of stuff about it, although to be honest you probably only need to enable it in the features list of the server.
http://learn.iis.net/page.aspx/350/installing-and-configuring-webdav-on-iis/

If you are on an earlier version of server software then please say what is you have.

From the research I've done with MS and other online resources, the way IE 9 and above interact with WEBDAV and windows authentication is not fully compatible with SharePoint 2007 Internet Explorer View.  We have SP2007 installed on a 64bit Windows 2008 system with all of the recommended settings from MS.  We have a lot of users that utilize Explorer View in their Windows environment to interact with documents on their SP 2007 Document Centers.  When I.E. 9 was released and users were upgrading, I started getting a lot more calls indicating that they couldn't open the folders or that it was VERRRRYYYY SSSLLLLOOOOWWWW.

After more than a year of dealing with this issue, the fix I use that works 100% of the time it to remove IE 9 and go back to IE8 on the user side.  And if a user that has IE8 starts experiencing slowness with their Explorer View folders, I simply reset IE's Advanced Settings and it speeds up again.  We no longer have this issue unless someone upgrades to IE 9 manually.

I have a standing request not to automatically deploy IE 9 to any of our users who use SharePoint's Explorer View functionality.

Hopefully a future upgrade to SP2013 will allow us to upgrade to the most recent browser.

Oh no!!! Wow, so IE 9, for simplicities sake, does not work with SP2007 explorer view?

You said there were some additional settings that needed to be configured. Would you happen to have them handy? Even if IE 9 can get to the folder, albeit slow, that would be a huge help!!

Do you have any information or SOPs you have developed for getting back to internet explorer 8? The deployment environment is currently Windows 7, so I was not aware of being able to have IE 8 take the place of IE 9.

You said you had some interaction with MS about this issue. Would you happen to have a support ticket ref number? If possible I am going to use a Support Credit I have to further investigate this issue... and it would be nice to have a reference for them to look at.

Thanks again for the help!

Thanks for the details...

I have some questions about the reg key that needs to be added...

For value 1, if the site has a list that I am trying to view in Explorer view and the URL of the list is:
https://www.sharepointsite.com/sites/sitename/pagename/subpage/list/Forms/Sort By Name.aspx

How should I change that to the https://*domain.com? Is it like compatibility mode where I only need the prefix.com? Or do I need to put the entire url listed above, minus the

Same question goes for the Fully Qualified Domain Name Value 2 key.

I am going to try and roll back to 8 right now and see if that helps. Can't wait!!!! *crosses fingers*

For the Reg Key, you only need the root URL.  I have "tons" of individual site collections running under numberous web applications that utilize mutliple sub-domain URLs and two or three different domains.  For me, https://*.myotherdomain.com covers 10 web applications and approximately 50 site collections.  https://*.myprimarydomain.com covers 4 web applications with 10 or so site collections.

The FQDN to the server is just one line to a server hosting the SharePoint services.  Thus, the values in my Auth... parameter simply looks like this:

https://*.myotherdomain.com
moss2007server.myprimarydomain.com
https://*.myprimarydomain.com
wss3server.myprimarydomain.com
http://specificsite.myprimarydomain.com
wss3server.myprimarydomain.com

That's it. This cover's most instances of where I use Explorer View.  You're basically telling the WebClient service where to go for authentication based on the URL.  You can see that I'm using a compination of wildcard and specific URL site addresses that use both HTTPS and HTTP.  Since I only have two SP servers (1 MOSS, 1 WSS), I use the FQDN to either of those depending on where the site is hosted.

I think you can make this list as long as you want.  The rule is to have one line with the URL and the next line with the server FQDN.  Rinse and repeat!

So in my case: https://www.sharepointsite.com/sites/sitename/pagename/subpage/list/Forms/Sort 

Value 1 would be:
https://*.sharepointsite.com

and value 2 would be:
https://*.sharepointsite.com


Going to try this before trying IE 8.

Value 2 should be the Fully Qualified Domain Name to your server.  That usually takes the form of servername.domain.com.  So if SharePointsite.com was hosted on a server call MOSS2007, it would be moss2007.sharepointsite.com if "sharepointsite" is your primary domain.  There's no HTTP/HTTPS in value 2.

For value 1, if you only have one web application running on the www sub-domain as indicated above, you could simply use https://www.sharepointsite.com.  I use the wildcards for simplicity and future expandability as I would be able to create additional web applications or site collections without having to modify my registry parameters again.

A URL and FQDN are always listed in pairs, separate by a carriage return.  That's the basic concept.  If you start to see and understand this, it will become a "no-brainer".  You'll always have an even amount of lines in the key value.

Line 1 - URL
Line 2 - server name to authenticate
Line 3 - URL
Line 4 - server name to authenticate
Line 5 - URL
Line 6 - server name to authenticate
etc...

In some cases based on your network topology, the server name may be the same.  This format tells the WebClient where to look for authentication based on the URL being accessed.

 I hope this is starting to make sense =)

It totally worked. I added: https://*.sharepointsite.com twice.

I also added https://*.sharepointsite.com to the trusted site list inside of internet settings.

I am using Windows 8 and IE 10 and it was not slow (going to check windows 7 IE 9 later).

This is an awesome solution. I have never seen this solution, and I have, quite literally, looked at 100's of forums looking for a solution (and have tried all of the different configurations, which did not work). Would you mind if I update all of the forums I have been on with this solution? I think it would solve a lot of headaches.


Thanks again!!!!!!

This answer fixed my issue. It is one configuration change that I have not seen in the months of scouring the internet looking for a resolution to the problem at hand.

This should be able to help lots of people!

Go for it.  I've been slowly dealing with Explorer View issues for a few years and I probably looked at those same forums, scoured TechNet, and emailed some contacts at Microsoft and Mindsharp for additional recommendations.  This has alleviated my problems for those that can use the Explorer View feature.  Hopefully user adoption will increase now as this was one of the major pain points for utilizing SharePoint 2007 for document management.

I still don't have a fix for the "Your client does not support Explorer View", but Windows 7 seems to fix that with IE8 as I haven't had that problem since the new OS started being deployed.

Odd, adding those registry keys precisely solved the "Your client does not support Explorer View" issue, along with disabling protected mode, enabling compatibility mode, ensuring the WebDav is enabled, and adding the site to the trusted list... sheesh!!

Very nice.  I don't think I would have checked those aspects and Microsoft technicians didn't indicate that the Reg Key would improve other "issues" of using SharePoint.  Of course, those weren't in the "scope" of the issue I called in. I think we'll sum that up as an Undocumented Feature!  And you saved yourself tons of time and a $260 support call to MS! Plus you get to keep your hair...assuming you have some.  I'm almost out =)  Have a good day.