SharePoint Cumulative Updates Best Practices

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.

General rule

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

11 thoughts on “SharePoint Cumulative Updates Best Practices

  1. Hey Mark, great post. I have a quick question. My company’s SharePoint Admin recently left I have since accepted his responsibilities until we fullfill his position. I am a SharePoint Analyst with solid server side experience but in no way an admin. After analyzing the environment due to some performance issues/Memory utilization issues i found that our 2010 farm is outdated to April CU 2012. Here is my question.

    When multiple years behind, what is the best practice to get to the farm updated to the most recent CU (minus 6 months) in terms of process of doing so?

    Do i have to install all CUs and test or can i just skip straight from April 2012 to March 2014?

    Thanks much appreciated!

  2. Hi Mark,

    Excellent post.
    What are your views on applying OS only patches to your SharePoint server on a more frequent basis than applying the cumulative SharePoint updates? I completely agree with your point regarding the 6 month period between cumulative release and application but from a security perspective I like to be at the bleeding edge when it comes to patching OS vulnerabilities.

    Thanks in advance,

    • Yes! Excellent point of clarification, James. I do recommend more frequent OS updates and patches. I don’t have a steadfast rule for this but suggest something like a 30 to 60 day lag at most.

  3. Mark,

    It’s been up for debate across the web… What is the order for applying CUs when running PS Config. I have heard you should do your application servers together first, then your web front ends. Do you agree with this approach?


  4. Good advice, Mark. Hopefully, you have a little more for me: what do you do when a CU fails to install on 1 out of 4 servers, rendering the farm unusable? The logs are, as usual, somewhat unhelpful. I’ve had trouble with this server before, so I’m tempted to just rebuild it, but then I have to be able to remove it from the SharePoint farm gracefully (or not) – I’m thinking I just need to have it reimaged, run configuration on the remaining servers, then remove the bad server using Central Admin. But, if there is a way to force the update to install, that would be better….thanks in advance!

      • Thank you, Collin, for your reply on the solution. I have posted both for others to consider this as a possible issue for them.

        To answer your earlier question, this is difficult and could be quite a number of different reasons for getting errors such as this. The best advice I can offer would be to look at the SharePoint logs on the problematic server. Not much help, but a good first step.

  5. Do you have any advice about running psconfig on multiple WFEs at the same time? Have you done this? Do you know it if is possible to make an exact replica of a sharepoint environment? Currently we stand up a new SharePoint environment from scratch, then attach the content DBs later. That is our test/dev SharePoint environments, so they aren’t really exact.



  6. Hi Mark,
    We have public facing website the last patch was done in the month of May 2015 and we have not done any updates to SharePoint till to date. Only windows patches were done recently In month of December 2016. Will it cause any issue if we don’t do SharePoint patches. I have gone through many of the websites regarding the patches. Can you please let me know when should we often patch SharePoint if there are no current issues with environment.


  7. Pingback: Patching a Production SharePoint Servers | RAMESH@SHAREPOINT

Leave a Reply to Collin Ames Cancel reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s