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:

I’ve highlighted the get_FollowPersonalSiteUrl() method because we’ll be revisiting that shortly.

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 (). 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.

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:

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

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:

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 , 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!

Q&A

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

On 9th July 2014, Microsoft published an article titled . Amongst other announcements, that article introduced the idea of templates within Azure Infrastructure as a Service () 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 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 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

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

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 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 , 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 are followed.
    
  • All SharePoint VMs host an instance of the Distributed Cache Service. Some Microsoft staff (including ) 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 . 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 . 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 ). 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 . 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

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

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

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

Wrap-up

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.

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 . 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/) cloud flavours. This was my first SPC – so I can’t really compare it to previous events – but it was a blast!

Continue reading →

I ran into an issue today whereby I was unable to log in to Lync Online due to the following error: