Solving site and document follow issues in SharePoint 2013 caused by security updates

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 a number of other folks have encountered this issue 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 (KB3085567), or are on the August 2015 Cumulative Update (KB3055009) 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 regressions page. That particular CU is also particularly troublesome to install, sometimes requiring three attempts.

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 this article 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.

ULS get_FollowPersonalSiteUrl() error

Microsoft’s investigation

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 (KB3101373). 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 breaks outbound search federation), 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.

My follow-up

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:

Missing get_FollowPersonalSiteUrl() method

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
KB Type Release Date UserProfiles.dll version UserProfiles.ServerStub.dll
KB3054858 PU August 11, 2015 15.0.4745.1000
KB3055009 CU August 11, 2015 15.0.4745.1000 15.0.4745.1000
KB3054813 PU September 8, 2015 15.0.4745.1000
KB2986213 CU September 17, 2015 15.0.4749.1000 15.0.4745.1000
KB3085567 PU October 13, 2015 15.0.4757.1000
KB3085492 CU October 13, 2015 15.0.4757.1000 15.0.4745.1000
(replaces KB3054858)
PU November 10, 2015 15.0.4745.1000
KB3101364 PU November 10, 2015 15.0.4745.1000
KB3101373 CU November 10, 2015 15.0.4771.1000 15.0.4745.1000
KB3114345 CU December 8, 2015 15.0.4779.1000 15.0.4745.1000
KB3114497 CU January 12, 2016 15.0.4787.1000 15.0.4745.1000

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 Microsoft categorise cumulative updates as hotfixes 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:

  1. I installed the October PU (KB3085567) alone, with no other additional updates. Site and document follow functionality was fixed as I had anticipated.
  2. 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.
  3. 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 October 2015 PU (KB3085567), 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 why [Microsoft] recommend / require to run the Configuration Wizard also for Security fixes

The SharePoint Cloud Search Service Application – initial thoughts

In May, I was lucky enough to attend Microsoft’s Ignite 2015 conference in Chicago along with a handful of other Content and Code colleagues. A stand-out session for me unveiled the forthcoming SharePoint Cloud Search Service Application, which – among other enhancements – will finally deliver a consolidated on-premises and cloud Search Index, that lives in SharePoint Online. The news that this thing will be available for both SharePoint Server 2013 and 2016 was particularly interesting.

You can read more over on the Content and Code blog, in a post titled why we care about the SharePoint Cloud Search Service Application.

Introduction to Basic and HA SharePoint Server Farms in Microsoft Azure IaaS

Too long, didn’t read (TLDR) summary

  • The Azure SharePoint Server Farm application template appears to be targeted at development and testing scenarios.
  • You get two topology options: a “basic” farm (3 VMs, no HA) and a “high-availability” farm (9 VMs). The HA option costs about twice as much per month.
  • It cost me about £10 to “spin-up”, then de-allocate an Azure SharePoint Server Farm, but your mileage may vary.
  • I’ve uploaded a SPSFarmReport of a vanilla “high-availability” Azure SharePoint Farm for you to peruse at your leisure.

On 9th July 2014, Microsoft published an article titled Microsoft Azure Continues to Deliver Rapid Innovation in the Cloud . Amongst other announcements, that article introduced the idea of templates within Azure Infrastructure as a Service (IaaS) for multi-machine/tier applications such as SharePoint:

“Create, deploy, monitor and manage rich virtual machines’ based applications, and manage virtual networks within a fully customizable Portal experience. In addition to creating simple virtual machines, we are adding the ability to automate the deployment of rich multi-machine application templates with a few clicks. With this, deploying a multi-tier, highly-available SharePoint farm from the portal will be a few clicks away!”

Sure enough, a quick trip over to the Azure Preview Portal confirmed that this functionality is available within the gallery (for me at least):

In this blog, I briefly note down my thoughts on how this offering has been positioned, then go on to discuss what you get, and some of the main assumptions that Microsoft have made when putting these templates together. Note that I have no “inside” information – everything here is inferred from the Azure Preview Portal, and inspection of the VMs that are provisioned when creating an Azure “SharePoint Server Farm”.

When might we deploy an Azure “SharePoint Server Farm”?

Looking at the screenshot above of the Azure Preview Portal, it isn’t obvious whether the Azure SharePoint Server Farm is intended for development, testing, production or all of the above. The Azure SharePoint Server Farm article is clearer, as it differentiates between a “basic” farm (three VMs, no HA) and a “high-availability” farm (nine VMs with HA), and briefly notes their intended purpose (emphasis added):

  • “You can use this [basic] farm configuration for a simplified setup for SharePoint app development or your first-time evaluation of SharePoint 2013.”
  • “You can use this [high-availability] farm configuration to test higher client loads, high-availability of the external SharePoint site, and SQL Server AlwaysOn for a SharePoint farm. You can also use this configuration for SharePoint app development in a highly available environment.”

As you can see, it appears that an Azure SharePoint Server Farm is intended for development, test and evaluation purposes. There is no mention of production workloads, and I speak to some of the possible reasons for that below.

What do I get?

By clicking the “Create” button in the Azure Preview Portal, you will either create a “basic” or “high-availability” SharePoint Server 2013 farm. The topologies of those farms are shown below:

“Basic” Azure SharePoint Server Farm (3 VMs, no high-availability), from the Microsoft Azure site

“High-availability” Azure SharePoint Server Farm (9 VMs, including a SQL Server 2014 AlwaysOn availability group), from the Microsoft Azure site

Clearly there are a ton of configuration options within each VM that are not spoken to above. Here are some of the key design choices that I noted whilst perusing my Azure SharePoint Server farm:

  • A new forest and root domain are created along with your Azure SharePoint Server farm. If you already have existing AD DS infrastructure in Azure IaaS, there does not appear to be a way of installing SharePoint within that infrastructure.
  • A SQL Server 2014 AlwaysOn availability group is created automatically. This requires SQL Server 2014 Enterprise Edition, which isn’t cheap (as reflected in the VM costs shown below).
  • The following choices were made regarding SharePoint Server 2013:
    • SharePoint Server 2013 Service Pack 1 is installed (build 15.0.4569.1000).
    • A single content-serving Web Application is created, with a single root path-based Site Collection. This does not align with Microsoft’s recommendation to use host-named Site Collections for new SharePoint 2013 environments.
      • Interestingly, port 80 is open within the Windows Firewall, exposing this Web Application to the Internet. We would typically expose SharePoint to the Internet using a reverse proxy server such as the Windows Server 2012 R2 Web Application Proxy, and ensure that all Web Applications are SSL-secured for security reasons.
    • No Service Applications are provisioned aside from those that are created automatically when creating a new farm (the Security Token Service and Application Topology Service).
    • Only the Setup and Farm Accounts are provisioned. In production, it is unlikely that those accounts would be sufficient, assuming that Microsoft’s best practices related to least-privilege configuration are followed.
    • All SharePoint VMs host an instance of the Distributed Cache Service. Some Microsoft staff (including Steve Peschka) recommend dedicated Distributed Cache servers for performance and stability reasons.
  • The default pricing tier/specifications SQL Server and SharePoint VMs do not meet Microsoft’s minimum hardware and software requirements for SharePoint 2013. For example, Web and Application servers require 12 GB RAM and 4 CPU cores per server, and the default pricing tier selected for those VMs (A2 Standard) provides 3.5 GB RAM and 2 cores. I expect the default specifications for Azure SharePoint Server Farm VMs to be insufficient per SharePoint 2013 Service Application resource requirements, even if those VMs are intended for development or testing purposes.

These design points underline the idea that an Azure SharePoint Server Farm is a starting point for development and testing. We still need to apply additional effort to get these guys into a state that is ready for anything but the most basic SharePoint development. Today, that effort would most likely take the form of applying a PowerShell script to automate “remaining” Service Application, Web Application and systems configuration in order to produce a farm that is aligned with the production environment(s) that it supports.

It’s worth noting that if an Azure SharePoint Server Farm were intended for production usage, the act of creating it via the Azure Preview Portal does not remove the need to plan and design. Once we arrive at a design, it is likely that we would choose the “high-availability” option for production as a starting point, then add or remove VMs to meet our requirements. Identity integration would be a key design consideration given that “Azure SharePoint Server Farms” come with a dedicated Active Directory Forest (essentially a Resource Forest). Taking all of this into account, I question how much time we would save by using the Azure SharePoint Server Farm template in production, and can see why the feature is marketed as a development/test capability.

How much is it?

It’s always challenging to talk about pricing in a blog post, as Microsoft licensing agreements differ from customer to customer. What I will do is put together a quick “back of the napkin” price list so that you can see the relative cost of the “basic” and “high-availability” Azure SharePoint Server Farm options. Note that these are list prices, and I only list the default pricing tier costs mentioned on the Azure Preview Portal. Additional licensing costs (such as those required for SharePoint) are likely to apply, and an MSDN subscription may make this more affordable, as recently noted by a Microsoft employee. I’m no licensing expert, so please check with your licensing reseller before committing to anything.

List prices for “basic” Azure SharePoint Server Farm (default pricing tiers on pay-as-you-go) on July 20th, 2014

VM role Quantity Default pricing tier Monthly cost
Domain Controller 1 A1 Standard 42.61
SQL Server 1 A5 Standard 2130.67
SharePoint 1 A2 Standard 85.23
      £ 2258.51

List prices for “high-availability” Azure SharePoint Server Farm (default pricing tiers on pay-as-you-go) on July 20th, 2014

VM role Quantity Default pricing tier Monthly cost
Domain Controller 2 A1 Standard 85.22
SQL Server 2 A5 Standard 4261.34
SQL Server File Share Witness (FSW) 1 Basic A0 9.47
SharePoint 4 A2 Standard 340.92
      £ 4696.95

A few points to note about the pricing shown in the Azure Preview Portal (and listed above):

  • The default pricing tier/specification of individual VMs in each “tier” is the same in both the “basic” and “high-availability” options.
  • As explained earlier in this post, the default pricing tier/specifications SQL Server and SharePoint VMs do not meet Microsoft’s minimum hardware and software requirements for SharePoint 2013. For example, Web and Application servers require 12 GB RAM and 4 CPU cores per server, and the default pricing tier selected for those VMs (A2 Standard) provides 3.5 GB RAM and 2 cores. I expect the default specifications for Azure SharePoint Server Farm VMs to be insufficient per SharePoint 2013 Service Application resource requirements, even if that farm is intended for development or testing purposes. Of course, you can bump up those specifications at an additional cost.
  • SQL Server VM costs appear to include SQL Server licensing fees, whereas SharePoint VMs do not. This is reflected in the “choose your pricing tier” dialogue shown below.

“Choose your pricing tier” dialogue for SQL Server VMs

“Choose your pricing tier” dialogue for SharePoint VMs

Personally, I find it a little odd that you can’t change the SQL Server license that is applied when creating a SharePoint farm via the Azure Preview Portal. Although SQL Server Enterprise licensing is required for the “high-availability” option (per usage of a SQL Server 2014 AlwaysOn availability group), I can’t think why an Enterprise license would be required for the “basic” option, and imagine this choice significantly increases cost.

By the way, if you find yourself wondering how to reduce costs whilst a development or test environment is not in use, I have found the Stop-AzureVM PowerShell cmdlet to be very useful. As noted in that article, shutting down all VMs in a cloud service releases the associated public virtual IP address, which may be a problem if you have public DNS infrastructure that points to that IP. In my case, this hasn’t been a problem as the Azure SharePoint Server Farm that I created is temporary in nature. Also note that stopping (de-allocating) VMs means that you won’t incur compute charges, but you will still get charged for other resources such as storage.

Stopped (de-allocated VMs), after running Stop-AzureVM

For what it’s worth, I incurred a cost of just over £10 for “spinning up” a “high-availability” Azure SharePoint Server Farm, then de-allocating it right away using Stop-AzureVM. You can see in the chart below that the “OTHERS” category makes up a small percentage of the overall cost, which presumably includes storage. Remember that costs vary by region and by subscription, so your mileage may vary.

Cost of “spinning up” a “high-availability Azure SharePoint Server Farm” with default options selected


That’s all for now. If you’d like to know a little more about the configuration of a “high-availability” Azure SharePoint Server Farm, feel free to download an SPSFarmReport that I ran post-creation.

ULSViewer.exe download (MSDN archive version)

17/09/2014 update: Microsoft have released a new version of ULSViewer, which you might want to try instead of this one.

For reasons that are unknown to me, the MSDN Archive Gallery has recently been taken down. That gallery contained ULSViewer.exe, a much-loved tool that no SharePoint guy or gal should be without. Although there are many versions of the tool out there in the wild, I believe this is the version originally created for Microsoft’s internal support teams by Dan Winter. I’m not sure if this is the “best” version as such, but it certainly works for me.

ULSViewer appears to be subject to the MSDN Code Gallery Binary License, meaning that we are free to install, use, copy and distribute the software. To my surprise, I couldn’t find the tool elsewhere online, so have uploaded it to this blog. Enjoy!

Download ULSViewer 2.0.3530.27850

Continue reading

SPC14 word cloud summary

A couple of weeks back, I was lucky enough to be sent along to the Microsoft SharePoint Conference 2014 with a handful of my colleagues at Content and Code. For me, this conference gave me a lot of confidence that we are implementing the right solutions for our clients that use SharePoint in its private (on-premises/managed hosting) and public (Office 365/Microsoft Azure) cloud flavours. This was my first SPC – so I can’t really compare it to previous events – but it was a blast!

Continue reading

How to renew your ADFS 2.0 token signing certificate in SharePoint

Over the past year or so, Content and Code have found that Active Directory Federation Services (ADFS) has become a more common requirement for both cloud and on-premises SharePoint deployments. Although we find that it is often implemented to facilitate single sign on across otherwise disconnected infrastructure, we have also deployed it to support claims augmentation for SharePoint environments that utilise SAML claims. As such, we have built up a fair chunk of experience deploying and operating ADFS in both production and our own internal development environments. Continue reading

Configuring Active Directory Import for a SharePoint 2013 User Profile Service Application using PowerShell

Writing an IT PRO focussed blog post on any aspect of the User Profile Service in SharePoint is tough as there is a good chance that someone like Spence Harbar will come along and write a better/more informed one. However, whilst configuring a new SharePoint 2013 environment today I found myself wondering how one automates configuration of the “new” Active Directory Import mode – there doesn’t appear to be much out there on Technet. I figured a quick post would be useful in the absence of more detailed information. Continue reading

Using SPWebService.FileWriteChunkSize to turn off Shredded Storage in SharePoint 2013 RTM

14/11/2013 update:​ Chris Mullendore, a Microsoft PFE has written a ​great blog that discusses both Shredded Storage and RBS. He whole-heartedly recommends using the default FileWriteChunkSize settings. I’ll leave this blog up just to illustrate that it is possible to modify this value, but it appears to be one of those “just because you can, doesn’t mean you should” settings.

Over the last few weeks​ I’ve been looking at some of the new capabilities in SharePoint 2013 from an infrastructure perspective, focusing mainly on search and the topic of this blog post: Shredded Storage. Continue reading