|Although I’ve performed my own testing to support the content of this blog post, all software updates should be regression tested in your specific environment before being deployed to production. No two farms are exactly alike!
What’s the issue?
Last year, a client of ours reported that they were unable to follow sites in SharePoint 2013 following the installation of an August 2015 security update for Word Automation Services (KB3054858). The error message displayed was simply “Sorry, we couldn’t follow the site”. As it turns out, this regression also breaks SharePoint’s document follow functionality. This blog post identifies the security updates (plural) that cause this problem, and explains the options that are available to either avoid or resolve it.
If your farm is suffering from this problem, here are the error messages that you will see when attempting to follow SharePoint 2013 sites and documents:
Has this been “officially” recognised by Microsoft as a regression?
No. However, the testing that I’ve carried out so far has convinced me that the public updates listed below are responsible for the problem, and that it is not environment-specific. Additionally, it looks as though at various times since August 2015, when the regression was first shipped in KB3054858.
Given that deploying these updates can cause a SharePoint Server 2013 farm to “return to a former or less developed state” (the Oxford Dictionaries definition), I’m going to describe this issue as a “regression”, albeit an unofficial one.
Does this affect me?
This post is aimed at people that look after SharePoint 2013 farms that – for whatever reason – are a little behind in terms of SharePoint updates. If you’ve already deployed the October 2015 Public Update (), or are on the August 2015 Cumulative Update () or later then you shouldn’t be affected. You may of course be affected by other regressions, particularly if you have opted to install any recent cumulative updates. The August 2015 CU, for example, contains two known regressions that Todd Klindt reminds us about on his ever-useful SharePoint That particular CU is also particularly troublesome to install, sometimes requiring
If you aren’t sure about the distinction between the different types of SharePoint update that I’ve mentioned above (I think you should be able to tell cumulative and public updates apart, for example), I’d recommend reading by Stefan Goßner, a Senior Escalation Engineer at Microsoft. Since public updates usually include SharePoint security fixes, I use the terms “security update” and “public update” (PU) interchangeably for the remainder of this article.
Are we definitely talking about the same issue?
If you think that your farm might be suffering from the site and document follow issue that I’ve described, here is the ULS error that you should see when attempting to follow a site:
|Original error: System.MissingMethodException: Method not found: ‘System.String Microsoft.Office.Server.UserProfiles.UserProfile.get_FollowPersonalSiteUrl()‘.
at Microsoft.Office.Server.UserProfiles.UserProfileServerStub.GetProperty(Object target, String propName, ProxyContext proxyContext)
at Microsoft.SharePoint.Client.ServerStub.GetPropertyWithMonitoredScope(Object target, String propertyName, ProxyContext proxyContext)
I’ve highlighted the get_FollowPersonalSiteUrl() method because we’ll be revisiting that shortly.
Our client uses SharePoint’s native social functionality extensively, so we decided to escalate the site and document follow issue to Microsoft in an effort to speed up the resolution. Microsoft Support provided the following statements and recommendations:
- The problem relates to a dependency between the Microsoft.Office.Server.UserProfiles.dll and Microsoft.Office.Server.UserProfiles.ServerStub.dll assemblies, which manifests itself when KB3054858 (released August 11, 2015) is installed without the August 2015 CU or later.
- Although installing the August 2015 CU or later will resolve the issue, Microsoft recommended that we deploy the November 2015 CU (). The precise reasons for that recommendation have not been disclosed to us yet.
Having considered the known regression that the November 2015 CU contains (it ), our client decided to proceed with Microsoft’s suggested course of action. Installing the November 2015 CU *does* resolve the site and document follow issue. But that’s not the whole story.
Since deploying this fix, I’ve had some time to perform my own testing to help determine which specific updates contain the site and document follow regression. My intention was not to second-guess Microsoft’s recommendation, but I did want to clearly understand the root cause of the problem in order to ensure that I can provide folks with the right advice. In doing so, I’ve concluded that at least four separate security updates released between August and November 2015 can cause the regression, and that deploying the November 2015 CU is *not* the only way to fix it. Feel free to skip the end of this post if you simply want to see the list of affected updates. If you’d like to see the “evidence” that backs my assertions, read on.
I started my testing by configuring a local single-server lab environment in an attempt to re-create the issue (I figured that even my mediocre PowerShell skills could manage that). I installed SharePoint Server 2013 with Service Pack 1, then installed all security updates for SharePoint up to and including the August 2015 PU (KB3054858). The site and document follow issues described by my client immediately reared their ugly head. Keep in mind that my lab is sat on my home machine, and is completely isolated from the client’s infrastructure.
I decided to fire up .NET Reflector and dig a little deeper. Having analysed dependencies within Microsoft.Office.Server.UserProfiles.ServerStub.dll (the file mentioned in the ULS entry), it appeared clear that the version of this assembly that ships with KB3054858 relies on a method that was absent in my lab farm’s version of Microsoft.Office.Server.UserProfiles.dll:
In contrast, the get_FollowPersonalSiteUrl() method was alive and kicking after I upgraded my lab farm to the August 2015 CU, and I was once again able to follow sites and documents. All this is expected behaviour based on the Microsoft Support statements included earlier.
I was now keen to understand which SharePoint 2013 updates included the two DLLs in question. Through liberal usage of Hyper-V checkpoints and reflector, I found that:
- Microsoft.Office.Server.UserProfiles.ServerStub.dll hasn’t changed since August 2015, and ALL SharePoint Server 2013 updates (cumulative and public) include it
- The “missing” get_FollowPersonalSiteUrl() method was added to Microsoft.Office.Server.UserProfiles.dll in the August 2015 CU
- All *cumulative* updates released since August 2015 contain Microsoft.Office.Server.UserProfiles.dll and therefore the “missing” method
- However, the October 2015 PU is the ONLY *public* update released since August 2015 that contains Microsoft.Office.Server.UserProfiles.dll and therefore the “missing” method
To help clarify the version history of these assemblies, I’ve pulled together a list of all cumulative and public updates that have been released for SharePoint Server 2013 since August 2015. Note that I have excluded SharePoint Foundation 2013 updates, as those do not appear to include the two assemblies in question (most likely because the User Profile Service Application doesn’t ship with the Foundation SKU):
SharePoint Server 2013 updates released since August that include the Microsoft.Office.Server.UserProfiles.dll assembly
|Public Update that includes Microsoft.Office.Server.UserProfiles.dll
|Cumulative Update that includes Microsoft.Office.Server.UserProfiles.dll
|Update that does NOT include Microsoft.Office.Server.UserProfiles.dll
|August 11, 2015
|August 11, 2015
|September 8, 2015
|September 17, 2015
|October 13, 2015
|October 13, 2015
|November 10, 2015
|November 10, 2015
|November 10, 2015
|December 8, 2015
|January 12, 2016
Note that this list my not be exhaustive – the security updates were mostly identified by reviewing the list available within Windows Update. Please let me know if I’ve missed off a SharePoint Server 2013 update that shipped between August 2015 and January 2016.
Having identified that the October 2015 PU is the only public update released since August 2015 that contains Microsoft.Office.Server.UserProfiles.dll, I was keen to understand whether that update alone would “fix” the site and document follow regression without having to install a cumulative update. Keep in mind that that should only be installed if they resolve specific problems, whereas security updates should be tested and deployed as soon as possible.
I rolled back my lab environment to its original “regressed” state (SharePoint Server 2013 with Service Pack 1 + all security updates up to and including the August PU), and confirmed that I got the “Sorry, we couldn’t follow the site” error. Once again using Hyper-V checkpoints, I ran through a number of different scenarios to help confirm that the October 2015 PU irons out the site and document follow regression:
- I installed the October PU (KB3085567) alone, with no other additional updates. Site and document follow functionality was fixed as I had anticipated.
- I rolled back to the August PU (KB3054858), and installed ALL outstanding SharePoint 2013 security updates up to and including January 2016. Given that the October PU was included, site and document follow functionality was fixed.
- I once again rolled back to the August PU, and installed all outstanding SharePoint 2013 security updates up to and including January 2016 EXCEPT the October 2015 PU. This time, site and document follow functionality remained broken.
Although clearly not exhaustive, these tests give me a level of confidence that installing the October 2015 PU is one (perhaps the only) way of fixing – or avoiding – the regression described here short of deploying a cumulative update. With this information in-hand, my default approach to resolving this problem is to simply test and install all outstanding security updates for SharePoint as a first port of call.
In contrast – with limited time available to thoroughly investigate the root cause – we followed Microsoft’s recommendation to install the November 2015 CU for our client due to a pressing need to restore SharePoint’s follow functionality. I now plan to point Microsoft Support at this post in order to help understand whether the October PU would also have been a viable option, and will post an update if I receive any further clarification.
If you decide to go ahead with the , it should be available for download via Windows Update if you’ve opted in to receive non-OS updates. Security updates for SharePoint 2013 sit within the “Office 2013” category and look like this if you happen to be installing them via Windows Update (remember to opt in to non-OS updates):
One should of course be testing and installing all security updates, but this specific PU resolves the follow regression described in this post. Remember to test all this in your environment first, and please stop by to let me know how you get on!
Should I just install all available security updates rather than the specific update that you’ve mentioned?
Yes, I suggest you test and deploy all security updates. Make sure, however, that KB3085567 is included if you’ve run into the site and document follow issue.
Which updates can cause the site and document follow regression?
The security updates highlighted in red in the table will cause the site and document follow issue described here *if* they are installed without the October 2015 PU, or the August 2015 CU or later.
So do I need to install any cumulative updates?
As far as I can tell, no CUs are required to fix the site and document follow issue.
Why would anyone run into this problem now, given that one can simply “install all security updates” to avoid it?
I don’t expect that many farms will suffer from this regression given that the October 2015 PU includes the goodies required to avoid it. However, considering that patching SharePoint can be very time consuming, I anticipate some folks might run into this if they are behind on patching and need to deploy a subset of the outstanding security updates for SharePoint (perhaps to minimise an outage window).
Should I run PSConfig after installing security updates?
Yes – see