Fix for “Open with Explorer” in SharePoint 2013

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.

2014-09-19 08_44_54

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.

2014-09-15 18.51.03

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.

2014-09-19 09_46_30

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.

Autocomplete cache changes in Outlook 2010

While creating a new Outlook profile the other day, I found that in Outlook 2010, the autocomplete cache (the file that stores previously entered destination addresses) is no longer stored in the .NK2 file we all know and love, but instead in a .DAT file that’s supposed to follow the Exchange account (not sure whether this is dependent on the version of Exchange server–the articles I was able to find are kind of sketchy on this functionality, so maybe someone who runs across this blog can fill me in?).

In earlier versions of Office, restoring the autocomplete cache is as simple as copying/renaming the old .NK2 file to match the name of the new Outlook profile. Unfortunately under the “new and improved” system, the .DAT filename no longer matches the profile name, so you need to figure out which .DAT file matches which profile (using timestamps, etc.) before copying the old .DAT file to a new one.

Here’s some additional reading:

“The specified Active Directory user already exists as a CRM user” Error

Ran into this issue today while trying to create a new user in CRM 4: “The specified Active Directory user already exists as a CRM user. You are attempting to create a user with a domain logon that is already used by another user. Select another domain logon and try again.”

After investigating, I ran across this extremely helpful article from MSDN UK. It walks you through tracking down which CRM user corresponds to a particular Active Directory user (SID), which unfortunately has to be traced through three separate SQL tables. Turns out my AD user had been assigned to another user’s CRM account for some reason, and the CRM account disabled.

Restoring that clean dishes sparkle?

secret ingredientIf you have a dishwasher (and especially if you have hard water) you’ve probably noticed sometime in the last year that your dishes haven’t been getting as clean, and end up with a dull finish or white film. What you may not know is the reason why.

It turns out that in July laws went into effect in several states banning the sale of phosphate-containing dishwasher soaps. Phosphates are chemical compounds that among other things help soften water (which enhances sudsing) and suspends particles of solids to keep them from sticking. Because of the number of states simultaneously enforcing the ban, practically all manufacturers have been forced to modify their formulas to leave out phosphates, even in states where there is no ban.

So, what to do if you’ve recently found your dishwasher to be practically useless? For one thing, some reports indicate that phosphate-free formulas are improving, although still not as good as the old stuff. For us, we haven’t yet noticed an improvement, probably because our Arizona community has fairly hard water and we don’t have a water softener.

The solution we’ve discovered that actually works is to enhance our dishwasher soap with a small amount (typically a half a teaspoon or less per load) of TSP. TSP is a heavy-duty commercial cleaning product that turns out to have as it’s main ingredient trisodium phosphate (hence the name), which is not coincidentally the exact ingredient that used to be in your dishwasher soap. It’s sold at most hardware stores, so we’ve been picking up a pound of it for about $4 at Home Depot, which lasts for quite a while.

You shouldn’t need much of it at all–the original formulas only contained 5-8% phosphates, so don’t go overboard. It’s powerful stuff, so it can potentially discolor or worse if you use too much. That said, it’s been nice to finally be able to use our dishwasher again since we discovered this about a month ago.