Updating SharePoint Server Farms

Microsoft SharePoint is a broad platform with a wide range of functionality and considerable options for customisation.

As a result applying updates / patches / hotfixes / service packs to SharePoint Server Farms can be a somewhat concerning process, particularly if your team has not had a great deal of experience with SharePoint.

This article considers;

Update Types
Risk
Strategy
Method
Further Reading
Alternatives

Update Types

Build Updates

You have a number of different types of update that might be applied.

Updates to the underlying Windows Server Operating System
Updates to the supporting SQL Server database
Security updates to SharePoint which ship via Microsoft Update
SharePoint Hotfixes
SharePoint CU,PU, and SharePoint Service Packs (Please refer to ‘Further Reading’ at the bottom of this article to understand the difference).

Version Upgrades

This article is not concerned with version upgrades. By version upgrades we mean the process of moving from, for example, SharePoint 2013 to SharePoint 2016 or Windows 2008 R2 to Windows 2012.

Risk

Risk Factors

You want your server farm to be relatively up-to-date for secure and reliable operation. In seeking this outcome you have to balance out the effort required to apply updates and the risk that application of the update might negatively effect your farm.

Factors that can increase the risk of a negative outcome.

Server side customisation.
Client side customisation.
Breadth. The more of SharePoint that you use the more the risk is slightly raised.
Use of 3rd party products that form part of your solution.
History. Was the farm upgraded from a previous version of SharePoint.
The type of update being applied. Windows and SQL updates tend to be lower risk than SharePoint Updates. You may therefore have a different strategy and update frequency for;
- Windows and SQL Updates
- SharePoint security updates
- SharePoint updates – CU,PU and Service Packs

This is not to say that updating a farm to which any of this factors is applicable is going to break. It just means that the likelihood is marginally increased and that should inform your strategy.

Why Would An Update Break My Farm?

Whilst there is no specific reason why any update should negatively impact SharePoint it happens. Some examples are included below.

Some SharePoint updates have been known to break services such as user profile synchronisation.
Some SharePoint updates change CSS class names and other front end artefacts. If your developers have applied front end customisation with JavaScript / JQuery these customisations can be affected.
A security update could close a loophole that custom code on your farm violates.

Strategy

Risk Mitigation – Testing

Consider these factors against the importance of SharePoint to your organization.

Higher Risk + Higher Importance – Apply patches to a test farm and regression test key functionality (justifies high effort).
Lower Risk + Lower Importance – Apply patches directly (does not justify high effort).

Risk Mitigation – Backup

In all instances ensure that you have a backup of the appropriate farm components before proceeding.

Risk Mitigation – Which SharePoint Update To Apply?

Whilst it is always tempting to apply the latest update that is not always the best approach. A more sensible approach would be to work backwards. For example if the Feb CU for your SharePoint version does not address any issues with the Jan CU then that is a very strong indicator that the January update is stable and a good candidate for application.

Risk & Effort Mitigation – Update Frequency

The update frequency is likely to be determined by your decision to test updates before application since this will determine the effort involved in applying updates.

The update frequency for a high effort farm might be the sooner of;

When you HAVE to update because you have a problem
When a service pack is released
Every 12 months

The update frequency for a low effort farm might be the sooner of;

When you HAVE to update because you have a problem
When a service pack is released
Every 3 months

Where security is a particular concern (for example SharePoint sites with external access) you might benefit from a combined approach

Windows Updates and SharePoint security updates
- Apply when they become available
SharePoint Updates
- Apply every 3 months

Method

Windows Update

By windows update we mean more generally WSUS and alternatives.

At this time (early 2016) this is working well for Windows Server updates and SharePoint Security updates.

This is not working well for SharePoint Updates (CU,PU,Service Pack). Do not apply such updates through this mechanism.

Schedule

Always run your updates at a scheduled time not automatically. This is mainly to enable you to ensure that PSConfig is run after application.

User

SharePoint hotfixes, CUs, PUs and Service Packs should be installed as the SharePoint installation user who will have the necessary server, SharePoint and SQL Permissions.

Topology

All web front end and application servers in the farm must have the same updates applied.

If you are using mirrored or clustered SQL then you will need to follow best practice for the update of these resources. This is beyond the scope of this article but essentially such resources should be on the same update level.

PSConfig

After installing updates to all farm servers you must run PSConfig (SharePoint products and technologies configuration wizard) to update the databases and web applications. This applies to service packs, PU, CUs, security updates and hotfixes.

PSConfig should be run as the SharePoint installation user who will have the necessary server, SharePoint and SQL Permissions to execute this process.

Check Upgrade and Migration in Central Admin

Check upgrade and migration in central admin.

Ensure that the upgrade has completed.
Ensure that the database schemas have updated.

Alternatives

Hosted SharePoint offerings such as Office 365 offer an opportunity to escape from the effort and therefore cost of updating SharePoint. This decision, however, needs to be balanced against a certain loss of control over the infrastructure and the implications therein.