How to speed up CU installation in SharePoint Server Subscription Edition

Long installation times for SharePoint cumulative updates are nothing new. We have already dealt with a similar problem in SharePoint 2013, see Speeding up CU and SP installation on SharePoint 2013. In SharePoint Server Subscription Edition (SPSE), we can also reduce installation time by stopping certain services before starting the update.

This time, however, the cause is different. In SharePoint 2013, one of the issues we addressed was the resources consumed by running services. In SPSE, the mechanism used by the update installer to stop SharePoint and IIS services does not work as expected. The services remain running and use files that the installer is trying to update in the Global Assembly Cache (GAC). This makes the installation take longer.

So, if you expected that moving to a newer SharePoint version would mean you no longer needed this procedure, unfortunately that is not the case. The solution is to stop the required services manually before installing the CU and start them again once the installation has completed successfully.

Stopping services before installing the CU

First, check which services are running on the server you are updating. Not all servers in a farm have the same role, so you may not need to deal with Search or Distributed Cache services on every server.

If the server handles user requests, first take it out of the load balancer, or perform the update during a scheduled maintenance window.

Using the Services console (services.msc), stop the following services in the order shown. Distributed Cache has its own procedure, described below.

Keep to this stopping order so that the services do not restart one another. Wait for each service to stop completely. Also note their original state so that, after the update, you start only the services that were running beforehand.

Take care with Distributed Cache

If you use zero-downtime patching, you need to stop the local Distributed Cache instance gracefully so that it can transfer its data to the other running cache hosts.

In the SharePoint Management Shell, with the required permissions, run:

Stop-SPDistributedCacheServiceInstance -Graceful

Wait for the operation to complete. If you have only one cache host, there is nowhere to transfer the cached content, and you must allow for the cache being unavailable when you stop it.

For details, see Microsoft’s documentation on managing Distributed Cache.

Installing the CU and starting the services

Once the required services have stopped, start the CU installation and wait for it to complete successfully. During the installation, check that the services remain stopped.

Afterwards, restore the services that were previously running in reverse order:

1. SharePoint Caching Service (SPCache).
2. SharePoint Search Host Controller (SPSearchHostController).
3. SharePoint Server Search (OSearch16).
4. World Wide Web Publishing Service (W3SVC).
5. SharePoint Administration (SPAdminV4).
6. SharePoint Tracing Service (SPTraceV4).
7. SharePoint Timer Service (SPTimerV4).

For Distributed Cache, follow the procedure for starting the instance. Start the other services using the Services console and check their status.

Do not forget the Configuration Wizard

Once the CU has been installed on all servers in the farm, remember to run the SharePoint Products Configuration Wizard on each of them. The required services must be available again before you run it.

This procedure helps reduce the installation time of the update package itself. It does not address the time the Configuration Wizard subsequently takes to process the databases, and the actual time saved will vary depending on your environment.

Once everything is complete, check the service status and make sure SharePoint is working correctly. Only then put the server back into the load balancer.