Upgrade a SharePoint 2013 farm with minimal downtime

Updating and upgrading a large SharePoint 2013 farm without a DR farm will impact the availability. There is no way to upgrade a farm without downtime in this situation. In this post I will describe the steps to upgrade a SharePoint farm with minimal downtime after applying a Cumulative Update (CU). Patching the servers in the farm with a new CU is not in scope of this post, there is a good TechNet article describing different scenario’s on how to perform this activity (https://technet.microsoft.com/en-us/library/ff806338.aspx). However installing the CU and simply starting the configuration wizard will put your farm offline for a very long time with no control at what is going on during upgrade!

To have more control over the upgrade process, I divided the upgrade process in three phases (assuming that the CU was already installed on all servers in the farm):

  • Step 1> Update all content databases first, two databases on the same SQL instance can be upgraded in parallel. Its not recommended to upgrade more databases in parallel. During this activity only the Site Collection in the content database that is being upgraded is not available. The rest of the farm is still available during this activity.
  • Step 2> Run the configuration wizard on Central Admin server and upgrade the configuration database and remaining Service Applications databases. Because all content databases already have been upgraded in the previous step, this step will be a lot quicker than without upgrading the content databases first. Always check the notes of the CU if specific Service Application databases need to be upgraded separately, some CU’s require custom upgrade commands. During this step, the complete farm is unavailable.
  • Step 3> Run configuration wizard on remaining servers in the farm, start with the Apps / Search servers and end with the Web servers. Only the server that is running the configuration wizard is not available in the farm. If you build in resilience for the Service Application in the farm, this step also involves no / minimal downtime for the farm.

The Configuration Wizard can be replace with the PSConfig for scripting purposes:

PSConfig.exe -cmd upgrade -inplace b2b -wait -cmd applicationcontent -install -cmd installfeatures -cmd secureresources

All different states in the update/upgrade process of SharePoint are backward compatible and supported by Microsoft, however it is not recommended to wait to long before moving to the next state. In the next part of this post I will test these steps in a Lab setup.

After installing the binaries on the servers in the SP farm this is the start situation. The farm is still completely available, even if a new CU is installed but the farm is not yet upgraded.

Step 1> Upgrading all content databases in the farm

Functional tests after upgrading all content database were successfully:

 

Step 2> Run configuration wizard on the Central Admin server, this activity will update remaining Service Application database as well as the configuration database of SharePoint. During this step the farm is not available but a lot of downtime is saved because of step 1.

Functional testing with all content databases / configuration database & service applications upgraded. Central admin server is now fully upgraded, both Web servers still needs to be upgraded:

Step 3> Run the configuration wizard on the remaining servers in the farm, the Configuration wizard can only run on one server a time. If started on multiple servers, it will lock all servers except one server. The Configuration wizard will than move on to the next server in the farm. It is recommended to not follow this approach but run the Configuration wizard on one server, wait until it is finished and than move on to the next server (least downtime required).

After the last step the complete SharePoint farm is successfully upgraded to CU2016DEC update with minimal downtime for the end-users.

Share This Post:

rbruinsma