Applies To: SharePoint

We recently upgraded to SharePoint 2010. Things went relatively smoothly, but we began to experience problems with some of our Office users. I looked everywhere but I couldn’t find anything that described our problem perfectly or that provided a solution. So here is the guide I wish we’d had before we called Microsoft Support.

Symptoms:

Windows 7/Vista machines had missing/broken links to the sites within the SharePoint Sites library on their machine. These were all users with MySites most of whom had had no problem opening and saving documents directly within Office to SharePoint 2007. This was affecting both Office 2007 and Office 2010 users.

Sometimes there was a MySite link, sometimes just a Member Sites folder, sometimes neither and sometimes various levels of Member Sites with the wrong type of Icon (Not like shown above). Some users could connect fine although it was very slow, others would have some very strange issues.

In addition to constantly asking for authentication or telling them access was denied to their own MySite, there were users who seemed to be saving their documents nowhere. Checking the Upload Center would show they did save them but not as expected.

For instance, one guy added his personal documents library to Office using the Connect To Office button on the SharePoint Ribbon. Trying to save a word document he double clicked on this link within the SharePoint Sites Library and everything saved. Further investigation with SharePoint Designer showed that their was a word document at his MySite root named PersonalDocuments.aspx.doc!

Obviously these links were broken. Sometimes they were gone from one day to the next and this was causing a lot of frustration. We tried messing with the registry entries, checking our version of Office, verifying access was setup correctly and finally gave up and called Microsoft Support.

Our Environment:

We had had a SharePoint 2007 farm using Windows Authentication. We built a new SharePoint 2010 farm and used the Database Attach upgrade approach. The new farm was built to use Kerberos authentication. When everything was good to go we switched the DNS entries to the new farm and voila, everything worked! (Obviously excluding the weird Office problems).

Our clients are mostly XP machines running Office 2007 – these had no issue. The Windows 7 clients running both Office 2007 and Office 2010 began experiencing the problems even though everything worked fine with SharePoint 2007.

Our DNS entry for SharePoint was set to the FQDN (ie sharepoint.something.something). Although alternate access mapping was setup for just the sharepoint portion, the FQDN is the only public url. This turned out to be the problem.

The Cause of the Problem:

The solution was found in this Microsoft Support article: Prompt for Credentials When Accessing FQDN Sites From a Windows Vista or Windows 7 Computer

In summary, the Web Client service uses Windows HTTP Services (WinHTTP) to do network operations behind the scenes (including requesting the list of Member Sites and MySite urls to update your SharePoint Sites Library). WinHTTP only sends user credentials in response to requests that occur on a local intranet site.

So just add your site to the Trusted Sites list and you’re done! Just kidding, that’s far too easy! WinHTTP does NOT use the security zone settings in Internet Explorer to determine if it should send the credentials. Instead it uses some pretty basic logic:

Are there any periods in the server’s name?
Nope: must be local – send them credentials!
Yes: Eeeek! Evil Internet, no credentials for you!

So if you happen to be using a FQDN or anything else with periods in the address, unless you’ve setup a local (no perioded(?)) proxy, no authentication is gonna happen which is pretty problematic for nearly every use case in SharePoint.

A hotfix is available for Vista and was included in Windows 7. But the hotfix doesn’t fix the logic nor does it start using the security zone definitions from your internet options. It provides a registry configuration of trusted sites (see solution below).

Testing the Problem:

Office only requests this list of sites/libraries once every 24 hours or so based on a registry key. However, following the steps below you can get it to make the request(s) again. In order to watch them, download and install Fiddler. You should be able to see all the requests as it makes them.

Close all Office programs (including Outlook)

Using RegEdit, delete the LinkPublishingTimestamp registry key.

Restart the Web Client service using the Services console (Administrator Tools > Services or Run services.msc)

Open Word and choose Save As (It may take a few minutes to start populating).

In Fiddler you should see all or at least most of the requests receive 401 responses (unauthorized). So, let’s get it fixed.

Solution:

1. Using RegEdit, navigate to the following key:
   HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WebClient\Parameters
2. Add a New Multi-String Vlaue (Edit > New).
3. Name it AuthForwardServerList and press Enter.
4. Set the value (Edit > Modify) to your FQDN. Or you can do something more comprehensive like http://*.something.something
5. To verify it worked follow the steps above and see if everything updates (Or wait a day for things to recycle)

Now slap that registry setting in a Group Policy targeted at Windows 7/Vista users and you’re good to go.