At work, we use Microsoft SharePoint as the central repository for our documentation, procedures, and knowledgebase. We’ve been on SharePoint 2010 for a couple of years, and last weekend I upgraded us to SharePoint 2013. The migration/upgrade went very smoothly, but one of the remaining issues is that “Open with Explorer” wasn’t working on the new site.
This feature allows users to open a library in Windows Explorer view using WebDAV, with the ability to manipulate files and folders in bulk using the file system tools: drag and drop, copy/paste, etc. It’s a very useful feature that most of our techs use regularly, but every time we tried to use it, we’d get a popup message stating, “
We're having trouble opening this location in File Explorer. Add this web site to your Trusted Sites list and try again.“. No matter what we did with Trusted Sites, Intranet Sites, or various zone security settings, it didn’t work.
There are TONS of articles and forum posts on this issue, but nothing worked:
- It didn’t make a difference whether we were using Windows 7 or Windows 8/8.1.
- Restarting WebClient service: no difference.
- Clearing cache and cookies: no difference.
- Tried installing MS’s hotfix for Windows 7. Still no joy.
- Played with browser settings for a while, thinking it might have something to do with the way IE 10 & 11 implement 32-bit support on 64-bit environments, but determined this didn’t make a difference.
- Tried quite a few other things (registry settings, etc.) that I’m not remembering right now, but none of them helped either.
Finally decided to use Fiddler to see if it could shed any light on what was happening. After firing it up, enabling HTTPS proxy, and installing certificates, I used its built-in features to clear the WinINet cache and cookies. Immediately, Open with Explorer started working! At first I thought it must be that the functionality to clear cache and cookies was more thorough than the built-in inetcpl.cpl functions, but the feature stopped working again after a reboot and the only way to get it to work again was by going through the steps above, so clearly something else was going on related to proxying itself–mystifying. Went back to researching, but with a little bit more information to work with, although I wasn’t quite sure what to make of it.
Funny thing is, I’m not sure exactly how I landed on the solution eventually–I think an article I was reading while researching brought it to mind without actually suggesting it as a solution. I recalled having a completely different issue with Server Name Indication recently for another client, and remembered enabling it on the web site when setting up IIS on the new SharePoint server. Furthermore, the other unsolved issue with SharePoint was the inability to connect to SharePoint using the excellent SPConnect app since the migration–were getting an SSL handshake error, indicating the error was taking place before it even had a chance to try authenticating, so SNI could be the issue there as well, if the app doesn’t support it.
Sure enough, going into IIS Manager and un-checking the “Require Server Name Identification” in the site bindings did the trick. Fortunately we aren’t needing to use any additional SSL bindings on this server, so it won’t effect functionality to disable it.
Now that I know what to look for, I’m finding other posts indicating the same issue and solution. It appears the WebClient service doesn’t support SNI, but this doesn’t appear to be well documented (at all?) by Microsoft.