SharePoint Patching Best Practices

If you only have 2 minutes, read the summary below. It documents the best practices discussed in this article in short statements. If you have more time, you should also read the rest of this article which gives more background information on the different topics.

Summary

General recommendations

  • Evaluate and install all SharePoint security updates as soon as possible and install them shortly after they have been released
  • Evaluate all SharePoint updates in a test environment which resembles the production environment before installing them in production
  • Take backups before installing SharePoint updates
  • For virtual servers you can take snapshots of all machines in the farm (important: only “cold” snapshots are supported – see below for more details) before installing new updates
  • If you are using the command line tool PSCONFIG.EXE instead the SharePoint Configuration Wizard be sure to specify all required parameters
  • After installing an additional language pack install the latest monthly update (for SharePoint Server 2016 and 2019 only the language dependent fix) again to ensure that the newly installed language components are upgraded to the same patch level as the rest of the farm
  • Keep Workflow Manager patching in sync with SharePoint patching
  • Last but not least: consider migrating your on-premises SharePoint farm to SharePoint in Microsoft 365 – here the complete patching effort and various other administrative tasks are handled by Microsoft for you.

SharePoint 2007

  • This version of SharePoint is out of support and no updates (including security updates) are released for this version anymore. Continuing to run SharePoint 2007 in production workloads puts your data at risk. Microsoft recommends upgrading to a supported version immediately.

SharePoint 2010 or 2013

  • Plan to upgrade to SharePoint Server 2016 or 2019. The newer versions of SharePoint Server improve the patching experience significantly:
    • Simplified packaging model (only 2 different packages to install compared to 30+ in earlier versions)
    • Shorter patching time (due to the simplified consolidated packaging model)
    • Zero-downtime patching (no maintenance window required)
    • Patching using Side-by-side functionality
  • Reduce patching time to a fraction using Russ Maxwell’s PowerShell script
  • Apply the full server packages (also known as Uber packages) rather than individual fixes
  • Be aware that SharePoint Server 2010 and 2013 are in extended support and mainly security updates are released for these SharePoint versions. To get all the latest product improvements including non-security updates, upgrade to SharePoint Server 2016 or even better SharePoint Server 2019.
  • Patch levels older than April 2018 CU are no longer supported

SharePoint Server 2016 and 2019

SharePoint Patching Best Practices

Patching SharePoint can be challenging for SharePoint administrators for several reasons including the following:

  • Historically SharePoint consisted of a large number of components which could be patched independently
  • SharePoint patching requires two independent steps (installing the binaries and upgrading the databases)
  • SharePoint patch level needs to be in sync between different servers in the same SharePoint farm
  • SharePoint patching time is hard to predict and sometimes can take several hours
  • Microsoft recommends installing security updates as soon as possible to protect your environment from security vulnerabilities that others may try to exploit
  • There may be concerns that installing a SharePoint update could impact existing functionality
  • SharePoint updates cannot be uninstalled – so if something goes wrong there is no easy way to roll it back
  • Unlike other products like Windows or Office, it can be complex to automate the deployment of SharePoint updates across a farm

This article discusses several best practices and considerations for SharePoint administrators to simplify this process.

Best Practices around Security Updates

How quickly should security updates be installed?

Security updates should be installed as soon as possible after they are released – preferably within a couple of days. The longer your SharePoint environments operate without the latest security updates, the more risk you have that they could be compromised via an unpatched security vulnerability.

Do packages marked as security update only contain security related fixes?

No. SharePoint updates are cumulative, so each security update includes all fixes that have been released for both security and non-security related issues up to that point for the patched component.

Is it ok to install only the security updates and not the non-security updates released monthly?

Although it is supported to install only those packages which include the security updates it is recommended to keep SharePoint Server fully updated by installing the latest SharePoint updates regardless of whether they’re security or non-security updates. However, it is less urgent to install non-security updates quickly after they’re released unless you are impacted by one of the issues fixed in that update.

With SharePoint server 2016 and 2019 only two SharePoint update packages (one package which includes fixes for all language independent components like executables and one package which includes fixes for all language dependent components like resource files) are required to patch a SharePoint server.

If a language dependent patch isn’t available for a given month, update to the latest previously available language dependent patch. For example, if applying the July 2019 Public Update for SharePoint Server 2016, install the language independent update for July 2019 and the language dependent patch from April 2019. If you do not install the language dependent patch, you may encounter missing or incorrect functionality.

Be aware that at least once a year it is mandatory to install also the non-security updates based on the Updated Product Servicing Policy for SharePoint Server 2016 and 2019

General Recommendations

Best Practices to reduce the risk of regressions

Microsoft performs rigorous validation of each fix, both internally and with a select set of partners and customers before it is released to ensure it has the highest quality. This has helped to significantly reduce the number of regressions reaching our customers in the last couple of years.

Due to the large number of components and various ways to configure them, it is impossible to test all possible configuration combinations. So it’s unlikely, but possible, for a code change to introduce unwanted behavior with a specific configuration for some of our customers. Third party software and other customizations can also introduce additional variables that may be difficult to validate in our internal testing.

We recommend that customers use a test environment to validate new fixes with common use cases and business critical functionality before installing updates in their production environments. Test environments should simulate their production environments as much as possible to ensure meaningful validation.

As an additional safeguard we advise to take a backup (system state and file system backups of the SharePoint server and SQL / farm backup of the databases) before installing any updates as it is not possible to uninstall SharePoint updates after they have been installed.

If the SharePoint farm is installed on virtual machines, taking a consistent snapshot of all servers (SharePoint, SQL, etc.) could be used as an alternative. However, it would require downtime as so call “hot snapshots” are unsupported with SharePoint. The snapshots must be taken when all virtual machines are shut down to guarantee a consistent state between the SharePoint servers and the SharePoint databases.

Best practices around SharePoint Products Configuration Wizard and PSCONFIG.EXE

SharePoint patching consists of two steps: applying the binaries on each server and running the SharePoint Products Configuration Wizard on each machine in the farm to finalize the installation by upgrading the SharePoint databases and other administrative tasks. Be aware that the configuration wizard performs various tasks on the SharePoint server machines itself, including the registration of new/updated services and features and copying SharePoint binary files around to the required location. It is important that this step is performed after applying the patches otherwise SharePoint might not function correctly. If this step has to be delayed (e.g. the maintenance window is not big enough) at least the following PowerShell command has to be run on each server machine to ensure that the correct binary files are being used: Install-SPApplicationContent

Best practices for patching with language packs

SharePoint consists of language independent components (e.g. executables) and language dependent components (e.g. resource files which carry UI elements for the different languages). During patching both components have to be updated to ensure that the binaries can reference the correct resource elements. Language packs include only the language dependent components of SharePoint.

If a new language pack is installed on a SharePoint farm the patch level of the language dependent components for the new language will most likely not be the same as the patch level of the language independent components and the patch level of the other language dependent components already installed on the server. To ensure that the components installed with the language pack are upgraded to the same patch level as the rest of the farm it is required to apply the most current installed monthly patch again. For SharePoint Server 2016 and 2019 only the most current language dependent update must be applied again.

Best practice for patching Workflow Manager client on the SharePoint server machines

SharePoint updates sometimes include updates for the workflow activities for SharePoint 2013 workflows. It is important to ensure that the most current Workflow Manager updates are installed as well when new SharePoint updates are installed. This ensures that WFM is compatible with workflow activities updates included in the SharePoint update.

Also be aware that Workflow Client and Server components must be in sync. WFM client updates must be installed before WFM server is updated.

The SharePoint Configuration Wizard will update the SharePoint Workflow Activity definitions in WFM. In case this fails (e.g. because the WFM server cannot be reached because it is patched simultaneously with the SharePoint machines) the workflow definitions need to be updated manually after patching is completed using the following PowerShell command: Copy-SPActivitiesToWorkflowService

More details: Update Workflow in SharePoint Server

Best practice for patching with 3rd party components

3rd party components and other customizations cannot be considered when Microsoft tests new updates. It is important that the compatibility of 3rd party components with the latest updates is evaluated before new patches are installed in a production environment. A SharePoint administrator should contact the 3rd party vendor to get information about compatibility. In addition, the steps listed above in the Best Practices to reduce the risk of regressions section earlier in this chapter should be followed.

Best Practices for legacy versions of SharePoint

SharePoint 2007

This version of SharePoint is out of support and no updates (including security updates) are released for this version anymore. Continuing to use SharePoint 2007 in production workloads puts your data at risk.

Our advice is to remove such systems from your network and upgrade to a fully supported version of SharePoint.

SharePoint 2010 or 2013

Be aware that SharePoint Server 2010 and 2013 are in extended support and mainly security updates are released for these SharePoint versions. To get all the latest product improvements including non-security updates, upgrade to SharePoint Server 2016 or even better SharePoint Server 2019.

Also be aware that patch levels older than April 2018 CU are no longer supported.

SharePoint 2010 and 2013 have a significantly different packaging model than SharePoint Server 2016 and 2019. SharePoint 2010 and 2013 have 30+ different patchable components which all can potentially be on a different patch level in a single farm. Keeping track of the patch level of all components and ensuring that the latest updates are installed can be challenging if the full server packages (also known as Uber packages) are not applied. This is especially important for security updates where it would be dangerous if a security update for a component is missing. In contrast SharePoint Server 2016 and 2019 have only two patchable components. To ensure that all patchable components are always on the latest patch level we recommend applying full server packages (also known as Uber packages) rather than individual fixes:

Unlike SharePoint Server 2016 and 2019, patching of a SharePoint 2010 or 2013 farm cannot be done without downtime. This requires accurate planning of the required maintenance window to ensure that the patch downtime has minimum impact on users. Using the correct farm topology and the right strategy it is possible to reduce the downtime during patching of a SharePoint 2010 or 2013 farm to a minimum – but as mentioned before it is not possible to eliminate it completely.

If no further precautions are taken installing the monthly fixes on a SharePoint server can take several hours as certain Windows services are started and stopped repeatedly. The installation time for updates can be reduced to a fraction of the normal installation time (e.g.) using the PowerShell script created by Russ Maxwell which ensures that the services are only restarted once.

Important: SharePoint 2010 will reach end of support on October 13, 2020. No further support (including both security updates and non-security updates) will be provided after this date.

Our advice is to plan the migration of your SharePoint 2010 environment to one of the fully supported versions of SharePoint (SharePoint Server 2016 or 2019) or – if possible – to SharePoint in Microsoft 365 before SharePoint 2010 reaches end of support.

If your production environment is currently running on SharePoint 2013 we also recommend to evaluate SharePoint Server 2016 and 2019 as these versions include several features which improve the patching experience significantly.

Best Practices for SharePoint Server 2016 and 2019

SharePoint Server 2016 and 2019 have several improvements which enhance the patching experience significantly:

These use a simplified packaging model (only 2 different packages compared to 30+ in earlier versions) which reduces the size of the installation packages for our patches and also the installation time significantly.

Using the correct farm topology, it is possible to apply SharePoint updates for these versions without any downtime which removes the need for a maintenance window.

A side effect of zero-downtime patching is the fact that different servers in the farm are on different patch levels during the patching process. Due to these different patch levels, SharePoint servers would potentially serve different versions of the same JavaScript files to the end user. To prevent this SharePoint Server 2016 and 2019 include side-by-side functionality which – if enabled – guarantees that all servers in the farm send the same JavaScript files to the end users during patching.

Closing Note

SharePoint patching can be a challenging task. As security updates are important and applying them quickly is critical, patching of SharePoint farms is a frequent task for SharePoint administrators.

Newer versions of SharePoint have been improved to reduce the complexity of patching and to guarantee availability during the patch timeframe. SharePoint administrators should still carefully plan their patching strategy to minimize the potential risks of patch deployment.

Migrating to SharePoint in Microsoft 365 can remove this burden from customers. Microsoft ensures that Microsoft 365 contains our most advanced security capabilities and fixes to protect customer data.

References

43 Comments


  1. If you only install the security updates on all SharePoint servers, do you have to run the Configuration Wizard on all servers afterwards?

    Reply

    1. Hi Raphael,
      ALL SharePoint fixes require the configuration wizard. No exceptions.
      Cheers,
      Stefan

      Reply

      1. Hi Stefan, thank you very much for your helpful blog. Do you know why run of config wizard after patch installation is not mentioned in the install instructions of the patches?
        Kind regards, Reto

        Reply

        1. Hi Reto,
          sorry to be honest I don’t know.
          Cheers,
          Stefan

          Reply

  2. Thanks Stefan, can you also confirm whether the security updates themselves can be uninstalled or is this the same for non-security where the farm needs to be rolled back or rebuilt?

    Reply

    1. There is no difference. You cannot uninstall fixes marked as security updates.

      Reply

  3. Stefan,
    Am trying to update a SharePoint farm from 2010 SP1 to 2010 SP2 to resolve an issue that is preventing me from migrating sites to online.
    Is there any order that I need to follow to install service pack 2 in my environment? also, how easy would it be to restore SharePoint to a working state using VMs checkpoint and SQL full back up for a Sys Admin with a limited SharePoint knowledge?

    Reply

    1. Hi James,
      you should install first SP2 for SharePoint Server 2010 and then SP2 for each installed language pack.
      Afterwards you need to run the SharePoint configuration wizard.

      To be able to revert to the previous state using snapshots you should shutdown all SharePoint servers in the farm and also the SQL server.
      Afterwards you would take cold snapshots (means snapshots while the machines are shutdown) of all SharePoint machines and the SQL server machine.
      Ensure to include the SQL server databases in the snapshot – alternatively you can take SQL backups of all SharePoint databases.
      After the snapshots are completed you need to restart the machine starting with the SQL server.
      Then install the SharePoint updates as listed above.
      If you need to revert to the previous state you should again shutdown all machines including SQL server and reapply the previously created snapshots on all machines.
      Then boot up again with starting with the SQL server if required you can then restore the peviously taken SQL backups after SQL server is back in its previous state you would start the SharePoint machines and you should be good.

      Cheers,
      Stefan

      Reply

      1. Stefan,
        Thanks for your response, regarding the language packs, how do I get their SP2? do I have to manually download them from Microsoft, or can I get them via windows upate or CU updates?

        Also, my DB is on SAN, can I just perform a full DB backup prior to the update rather than performing a cold snapshot on the server it self?

        and I have 3 servers in the farm, do I install SP2 on the one running central admin and then the other two servers, or there is no certain order for installing it?

        Reply

        1. Hi James,
          each language pack SP2 has to be downloaded and installed separately from download center.

          About SQL backup: yes, in this case take an SQL backup.

          It is recommended to start with the central admin server and afterwards install it on the other machines.

          Cheers,
          Stefan

          Reply

  4. Hi Stefan!

    This is a great post, thank you!

    I watched Neil Hodgkinsons & Bob Fox’s great video about ZDP, and I have a few ZDP questions (for SP2016).

    1) In the video, no special care was taken to pause the Search Service Application or stop Search services. But I assume I should still do that? (Like described in https://docs.microsoft.com/en-us/SharePoint/upgrade-and-update/install-a-software-update#HostSearch)

    2) Will Russ Maxwells patch binary installation script still help make binary installation faster in SP2016? Or is there no point in using his script for SP2016?

    3) In the video, Bob ran PSConfig first on his WFE1 server, as it had Central Admin (and it was of course removed in the load balancer). I host CA on all my servers, and usually run PSConfig/Wizard GUI on the first APP-server. Should I do as Bob does, or should I continue running PSConfig first on my APP server? But that will mess the server order suggested in the video…

    4) Just double checking: I can run ZDP without using side-by-side functionality, right?

    Thank you so much for any help!

    Reply

  5. Hi Steven,

    you are not correct that you are safe if the OS was properly patched.
    Any unpatched product running on top of a patched OS can lead to vulnerabilities.
    If you haven’t patched SP2013 since 2017 you are missing out 50+ security fixes and my recommendation would be to install all missing security fixes asap.

    Cheers,
    Stefan

    Reply

  6. Hello Stefan Sir,

    I am Ganesh working as a SharePoint Administrator.
    I want to generate audit report for 90 days in SharePoint 2013.
    So is there any Powershell Script to generate the same?

    Reply

  7. Last update on our SP2016 Server was Dec 2019, which is multi-language update. So now can I do the May 2020 patch which doesn’t have multi-language patch? Or do I have to update to April 2020 and then to May 2020? I will very appreciate your answer. Thank you!

    Reply

    1. Hi Kalai,
      you need to install the language independent fix from May CU and the language dependent fix from April CU.

      Cheers,
      Stefan

      Reply

  8. Hi Stefan, Is it necessary to install language pack related security updates if we are not using any language packs in SP2019 farm?
    i.e. If we dont have any language packs installed in the farm do we still need to install the language packs related security updates?

    Reply

    1. Yes it is necessary. SharePoint always has at least on language installed – the base language of your SharePoint installation. You can install additional languages through language packs. Language dependent security fixes apply to all installed languages including the base language.

      Cheers,
      Stefan

      Reply

  9. hi stefan, good day,

    i got questions regarding Microsoft SharePoint patches..

    My Microsoft SharePoint 2016 was not patched since past 6 months.. i am planning to patch it mid of next month.. do i need to install the entire 6 months patches or just install the current month patches should be sufficient? Please advise.

    Reply

    1. Hi Devs,
      you only have to install the most recent CU (as well the language dependent and the language independent component) to fully patch your server.
      Cheers,
      Stefan

      Reply

      1. Thank You for Prompt Response Stefan.. God Bless. 🙂

        Reply

  10. Hi Stefan,
    Thank you for the hard work you are doing for us.
    I have a SharePoint 2013 farm composed of 2 WFE servers, 2 App servers, and 2 SQL servers, the farm hasn’t been patched since September 2019. My questions are:
    1- which patch/es should I use, and how many are there since September 2019, should I apply all of them one by one?
    2- What order should I folow to do the patching? (Should I first dismount App server 1 from load balancer then run the binaries then mount it back; dismount App server 2 from load balancer run the binaries then mount it back and do the same for the 2 WFEs one by one then mount them back. And then dimount App server 1 from the load balancer and run PSConfig.exe then mount it back – dismount App server 2 from the load balancer, run PSConfigui.exe mount it back – and do same for the 2 WFE servers one by one.)
    I’m kinda lost on this part when patching is concern (dismounting and mounting).
    I’m planning to do the patching this weekend and your inputs are apreciated.
    3- Is it posible to dismount say: App server 1 run the binaries and run PSConfigui.exe then mount it back to load balancer? And do the same with the remaining servers in load balancer?

    Best Regards/

    Reply

    1. Hi Franck,
      1) SharePoint CUs are cumulative. Just install the Uber packages of the latest CU and you are good.
      2) you should start with the machine hosting the central admin – the rest does not really matter
      3) no. machines with an older patch level cannot work with an upgraded database. you have to install the binaries first on all machines. afterwards you should run psconfig on one machine (during this time users are not allowed to access the site collections on the database being upgraded – it would be unsupported. so you have a downtime here during database upgrade). After psconfig was run on one machine (which upgraded this machine and the databases) you can run psconfig on all other machines in parallel.
      More details can be found in this blog post:
      https://blog.stefan-gossner.com/2016/04/29/sharepoint-2016-zero-downtime-patching-demystified/
      Its mostly about zero downtime patching for 2016 and 2019 but also discusses best practices to reduce the downtime for SP2013.
      Cheers,
      Stefan

      Reply

  11. Thank you so so much Stefan, this helps a lot.
    but all my machine have central administration, I didn’t built this farm I took over when our admin left.
    in this case, should I start on WFE1 or App1 server or it doesn’t matter which one?

    Thank you again.

    Reply

    1. In this case I would start with one of the app servers.

      Reply

      1. Thank you Stefan! You are the best.

        Reply

  12. Hi Stefan,

    Quick question, to diconnect a server like WFE or APP server from load balancer, is this the PowerShell command for disconnection: >”Disconnect-SPConfigurationDatabase”?
    After you finish patching, what’s the PowerShell command to connect the same server back again to the load balancer?

    Reply

    1. Hi Franck,
      you need to reconfigure the load balancer to ensure that it does not route traffic to the relevant server.
      This cannot be done with a powershell cmdlet of sharepoint – it depends on your load balancer if this can be scripted and how.
      Cheers,
      Stefan

      Reply

  13. Got it Stefan, Thank you!

    Reply

  14. Stefan,

    I have SP2019 and have a question about CU’s. We do not have multi-language. When i apply a monthly CU, should we also apply the multi-language CU for that month?

    Thank you for the wide variety of great info on this and other topics.

    Reply

    1. Hi Steve,
      independent from the number of language packs: you always have to install only two packages: the language independent one and the language dependent one.
      The language dependent will apply the fixes for all installed language packs.
      Cheers,
      Stefan

      Reply

  15. Hi Stefan,
    Again thank you, today I did the patching and ran to an issue I googled it and the first respond that came out how to fix the issue was your blog. It was very very helpful and I fix it in the matter of second. I installed the patches but when I started the configuration wizard, almost all were missing on the servers and from your blog, you mentioned to run “Get-SPProduct -Local” which I did and the error was fixed, again thank you.
    But I do still have some errors, the configration failed right 8 of 10 (configuring or installing web application files),
    I ran config.exe that didn’t work. The central administration can’t open, I can browse the sites collections on the server. The database upgrade status said: failed (because the configuration wizard has errored out).
    Any ideas??

    Thank you

    Reply

  16. Hi Stefan,

    I really need help on this, I tried almost everythink I could but but I’m still having this issue. It’s last part of SP products comfiguration wizard in SharePoint 2013. This error happened when the configuration is at 9 of of 10, here’s the error message:

    Configuration Failed
    one or more configuration tasks failed. Tasks that were successfully complete won’t be rolled back. Detailed failure information is listed here:

    Failed to upgrade SharePoint Products.

    This is a critical task. You have to fix failures before you can continue. Follow this link for more information about how to troubleshoot upgrade failure: http://go.microsoft.com/fwlink/?LinkId=259653

    An exception of type
    Microsoft.SharePoint.PostSetupConfiguration.PostSetupConfigurationTaskException was thrown. Additional exception information:

    <>

    Thank you and really need your help on this

    Reply

    1. Hi Franck,
      this requires a deeper analysis.
      I would recommend to open a support case with Microsoft to investigate this.
      Cheers,
      Stefan

      Reply

  17. Hi Stefan,

    I was able to fix the issue, thank you

    Reply

    1. Hi Franck, how did you resolve your issue?

      Reply

  18. Currently running 2013 Foundation at an RTM patch level (yes…I know). The database is also at 2012 SP1. What’s my best course forward for patching these? Do I need to patch SQL Server first? Should I install SharePoint SP1 first and then the highest CU? Long term endgame is to migrate to O365.

    Reply

    1. Hi John,

      we don’t have any best practices for such an outdated patch level.
      Personally I would first update SQL server to the latest patch level and then install SP1 + latest CU for SharePoint foundation.
      Ensure to take database and SPFarm backup before going through this to ensure to have a backup in case you need to roll back.

      Cheers,
      Stefan

      Reply

  19. Hi Stefan,

    Do SharePoint Cumulative updates also include the security fixes or do we have to install the security updates also along with the CUs.

    Thanks in advance..
    Logarajan

    Reply

    1. Hi Logarajan,
      it would be a weird design if the CUs would not include the most critical fixes. 😉
      Of course the CU includes the security fixes as well.
      Cheers,
      Stefan

      Reply

  20. Hi Stefan,
    If we setup automatic installation of security updates on a sharepoint farm, as now security update includes SharePoint updates, do we risk to have service interruption ?
    Best regards,
    Benjamin

    Reply

    1. Hi Benjamin,
      automatic installation of SharePoint security fixes is not encouraged.
      Reason is that SharePoint security fixes cannot be uninstalled and should be evaluated against all business critical features in a test environment before applying on production.
      Depending on the SharePoint version you could also leverage zero-downtime patching for SharePoint which will not work with automatic installation.
      With automatic patching you will for sure have downtime.
      Last point is that it is mandatory to run the sharepoint configuration wizard on all machines after the fixes have been installed on all machines – this is also a manual step and required planning.

      With other words: I would not do it.

      Cheers,
      Stefan

      Reply

      1. Thanks a lot for your complete and very quick answer !

        Reply

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.