SharePoint Cumulative Updates Best Practices
This guidance pertains to production SharePoint environments and is applicable to SharePoint 2007, 2010, 2013, and likely future versions.
Maintaining a healthy SharePoint environment requires a practical approach to applying cumulative updates. SharePoint Cumulative Updates are patches released by Microsoft that fix known issues. As their name suggest, they are cumulative in content so they include previously released patches. However, a plan that simply applies the latest updates is likely not in your best interest and can actually put your environment at risk.
Install updates and patches when you encounter an issue that is addressed by the update. The only exception is you should maintain a reasonably current level of updates. It is not ideal to let your environment lapse two years behind in SharePoint updates.
Maintain a 6+ month lag
Maintain your production environment at a 6 to 12 month update lag. In other words, don’t install any updates that are less than 6 months old, unless it is necessary. I recommend not extending much beyond a 12 month lag behind the latest updates. This keeps your SharePoint environment relatively current while minimizing your risk as new updates are applied. Should you encounter an issue after applying an update, the likelihood of a fix already existing in a subsequent update is much greater than if you had applied the newest update available. Microsoft does a good job of testing their releases, but the number of possible configurations, feature combinations, and server patch levels are almost infinite so you are wise to stay away from the bleeding edge.
Test your updates first
Every update should be applied to a test environment and thoroughly tested before applying said update to production. The idea of having to completely regression test SharePoint is not practical nor should it be expected. But you should have a test environment for every production environment, and that test environment should be used to test updates.
Urgent updates (updates that address an urgent problem in production), will require more focused and targeted testing. This is less than ideal, but necessary when a critical issue is identified. However, general operational maintenance updates can be applied to the test environment and remain there for several months before applying that same update to production. This allows for more exhaustive user and operational testing activity to expose any possible problems.
Synergy with developers
If you have SharePoint developers on staff or contract, they can provide a tremendous benefit regarding updates. You should coordinate your update plans with them to ensure they are developing with at least the current production version, or even better, the next cumulative update identified and targeted for production. I suggest developers keep their environments to a relatively recent update level. This is usually not an issue for them and can be very easy if they develop using virtual machines.
Ensuring a successful update
Below are a few points that will help you make the update process as smooth as possible:
- Something to consider: Minimize server downtime. Placing the content databases in a read-only mode while installing the binaries right before applying the patches can reduce server downtime. This allows your users access the SharePoint servers during the initial upgrade process and only experience downtime during the later portion of the update process. Again, not necessarily a recommendation, but something to consider.
- If you are using virtualization, take snapshots or backups of your Web Front End and Application servers(s). I am a big proponent of virtualized SharePoint servers.
- After installing the binaries of the Service Pack, run the Psconfig command on every server:
- psconfig –cmd upgrade –inplace b2b –wait
SharePoint 2013 Updates site