Explorer View in Sharepoint

johnkubik
johnkubik used Ask the Experts™
on
I am trying to use explorer view in a SharePoint documents library (SharePoint 2007) on Windows 7, and Windows 8 -- IE 9/10. I have a few settings that enable it to work on some machines, but I am trying to find an over list of settings that are going to allow for my computer to open the "explorer view" without getting the error "Your client does not support opening this list with Windows Explorer."

So far some potential fixes have been:

Disabling Protected viewing in IE.
Changing BasicAuthLevel to '2' in registry
Enabling WebClientService in services.msc
Adding site to trusted sites
Compatibility mode enabled

Even with those configurations set correctly there are still some users that are not able to access the explorer view. I have searched hi and low in order to find other ways of enabling explorer view and am running into issues.

Please help!
Comment
Watch Question

Do more with

Expert Office
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®
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

Author

Commented:
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.
Fundamentals of JavaScript

Learn the fundamentals of the popular programming language JavaScript so that you can explore the realm of web development.

Commented:
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.

Author

Commented:
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!
Commented:
On the server, WebDav needs to be enabled with the WebClient service running.  However, I did see a KB article that indicated SharePoint uses it's own version of WebDav and may not communicate with the WebDav you see on the server.  Other settings include IIS settings for authentication to make sure the sites are available.  In all reality there aren't a lot of server-side settings to look at specific to WebDav.

For IE 9, I simply go into the Programs and Features and remove the Internet Explorer 9 Microsoft update.  When the computer reboots, v8 is enabled.

For my users that had IE9, they could use Explorer View.  However, it was a difference of 1 second response times with IE8 to nearly a minute with IE9.  And IE9 Explorer View was not consistent.  Sometime we could upload files, other times it failed.  But I suspect that the issue is with the WebClient service on the local system and the processes IE9 uses for authentication.

I just closed a ticket with Microsoft on Friday regarding an issue with repeated authentication prompts for our users who use Explorer View almost exclusively.  After two months of reviewing server and client log files, Microsoft provided the following registry entry for the WebClient service on the user systems.  It's working for us.  You can try using it with IE 9 if you wish, but I haven't tried that since I'm sticking with IE8.

1. HKEY_LOCAL_MACHINE > SYSTEM > CurrentControlSet > WebClient > Parameters
2. Add a Multi-String Value:
Name = AuthForwardServerList
Value (Line 1) = https://*.domain.com (URL[s] of the SP site[s])
Value (Line 2) = FQDN to the SharePoint server (i.e. server.domain.com)

You can add more values into the list.  Enter a line for the SharePoint URL and then the FQDN to the server on the next line.  I have numerous entries in mine for sites that exist in a MOSS 2007 environment and in a WSS 3.0 environment.

Hope this helps =)

Author

Commented:
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*

Commented:
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!

Author

Commented:
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.

Commented:
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 =)

Author

Commented:
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!!!!!!

Author

Commented:
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!

Commented:
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.

Author

Commented:
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!!

Commented:
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.

Do more with

Expert Office
Submit tech questions to Ask the Experts™ at any time to receive solutions, advice, and new ideas from leading industry professionals.

Start 7-Day Free Trial