Marc Lognoul's IT Infrastructure Blog

Cloudy with a Chance of On-Prem

SharePoint 2013: How to Estimate the Time Necessary to Deploy a SharePoint Update and Optimize it

SharePoint 2013


When planning the roll-out of a SharePoint Update (hot fix, cumulative update or service pack) on a production farm, it may be useful to estimate the effective time necessary to perform such an action. While the complete duration depends on many factors, I will attempt to give some guidance here. The most important thing being: benchmarking on your test environment is the key.

Note: While this article covers mostly SharePoint 2013, the same logic may apply to previous versions.

The Rollout Sequence

The complete roll-out sequence used to update a SharePoint Farm (The servers and the configuration and content they share) is made of the following core steps:

  1. Installing the Update Package on each Server in the Farm
  2. (Optionally) Rebooting the Server(s) (Depending upon the files being updated and their state (in use or not), a reboot may be necessary
  3. Applying the Update on a first server, usually the one hosting the Central Administration web application
  4. Applying the Update on remaining servers. Note: This should not be done simultaneously (see why in next section)

SharePoint Update Process

Installing the Update Package

This action consists in installing the update binaries and other dependencies thanks to the Windows Installer technology. In other words, this means it will apply a “patch” on an existing MSI package that is the original package you installed SharePoint with. At that time, it will not touch SharePoint configuration or content. Because it may have to update files that are currently in-use, a reboot might be necessary after this process. If you plan to install multiple updates as part of the same rollout, there is a probability of reboot after each installation (A server in a pending-reboot state will refuse to install).

To reduce the execution time you can apply the guidance hereunder. Apply them carefully and according to you organization’s SLA and other policies:

  • Before installing the package, check that each server is not already pending reboot, this will prevent installing the update until a preliminary reboot is performed
  • Stop/Pause the Windows Anti-virus Software running on Windows Server if any. Refer to you security policies for guidance.
  • Stop as many server processes as you can (IIS, SharePoint services, other services such as Search, SharePoint AV is any…). This will reduce the load on the server and increase the number of threads available to the MSI engine to perform its job. Obviously, this will make SharePoint unusable on the server where it takes place. Refer to your SharePoint SLA for guidance. The service stop/start order maters, therefore you can rely on these posts for detailed guidance and automation: SharePoint Brew [MSFT] Why SharePoint 2013 Cumulative Update takes 5 hours to install? and SharePoint IT Pro Blog [MSFT]How to install update packages on a SharePoint farm where search component and high availability search topologies are enabled
  • While this step can be executed simultaneously on multiple SharePoint servers in the farm, rebooting the servers might be required. Therefore you should always bear in mind your SLA
  • Pre-extracting the package will also help since otherwise, each server will unpack the archive before starting the installation. This TechNet Article explains how to extract fiels from an Update Package: Prepare to deploy software updates for SharePoint 2013
  • Once extracted, there is no dramatic performance difference between installing from locally stored sources or from a remotely hosted shared folder. However and because MSI also maintains its local source cache, it might be wiser to keep sources centralized to avoid local clutter and confusion
  • Like most of installation packages provided by Microsoft, SharePoint Update Packages are digitally signed with a Microsoft Certification Authority. Before executing the package content, Windows will attempt to validate the certificate by checking its status against the Microsoft Certificate Revocation List (CRL). If the SharePoint servers have no internet connection, it is therefore advisable to Disable the Certificate Verification. This will prevent useless spinning until a timeout is reached
  • Once the package is installed on every server, you can measure the time it took by looking at the MSI Events from the Windows Application Log. They cover the start, end and sometimes intermediate events. This MSDN Article give the list of related Event ID and meaning: Windows Installer Logging – Event Logging
  • Installation log files can be found under the %TEMP% folder of the user who performed it

Applying the Update (aka PSConfig B2B Upgrade)

This step consists in applying the at various SharePoint levels:

  • Sharepoint Server’s file system modifications, assemblies, GAC,  files Under the 15 folder…
  • IIS Configuration and files (web.config…)
  • SharePoint databases (schema and content)

The details of each modification, its result as well as useful timestamp information can be found in the upgrade.log file. This log file will provide good indication of the time it took to update each elements of SharePoint. This MS KB article, while a little outdated, will give a good explanation of the log file and the sequences it contains: MS KB Description of the sequences and actions that occur when you upgrade SharePoint Products and Technologies.

In a nutshell, the elements hereunder will influence the duration:

  • The Number of SharePoint servers in a farm
  • The Number of Web Applications and Extensions
  • The Number of databases, content databases in particular
  • Potentially, the number of objects in the SharePoint content. Some updates may have to create new content through, for example a new document library in each site or so

Executin the PSConfig on the remaining servers in the farm will take less time than on the first one (50% to 25% less). Anyway, it should never be performed simultaneously on multiple servers otherwise conflicts may occur when objects are getting updated in the Configuration database.

Below some guidance over this step:

  • Stopping/Pausing the Windows Anti-Virus software remains a good idea due to the number of files being accessed and modified
  • Unlike during the package installation, services such as IIS and SharePoint service should not be stopped because they are at some point, necessary in the upgrade process. The upgrade.log file will contain entries related to service start/stop/restart.
  • Keep the total number of servers, web application, IIS sites and content databases as low as possible
  • To speed up the content database upgrade by deferring it, you can remove all content databases and add them back gradually. Obviously, this will impact the content availability. Note: Temporarily removing CDB’s can also help recovering faster in case of disaster during the deployment if you have many and/or large databases

Additional Administrative Steps

While the steps stated above are the main technical ones, some orgnizations may also have to take administrative as well as extra technical steps into account such as:

  • Informing the users about the maintenance (if a downtime occurs)
  • Putting the servers/Farm in maintenance mode
  • Changing Load Balancer configuration
  • Performing a health check to make sure the farm is in overall good shape
  • Taking the appropriate back up
  • Getting approval from a security officer to stop the A-V software
  • Performing technical and functional testing after applying the update on the first server
  • Performing technical and functional testing after the update is applied on the whole farm
  • Update other components such as Workflow Manager and/or WAC
  • Setting-off the Maintenance Mode
  • Communicating to the end users

Obviously these may severly impact time necessary to deploy as well…


  • To accurarely estimate the total deployment time, you’ll need a test environment whose configuration and ideally content is close or identical to your production environment
  • Event Logs and log files contain all key events to benchmark a deployment
  • While updating a SharePoint farm may sometimes last for hours, ther are a couple of tips to make it shorter
  • While the SharePoint core steps are important, the additional administrative and technical steps around might also heavily influence the planning

Additional Information

Author: Marc L

Relentless cloud professional. Restless rider. Happy husband. Proud father. Opinions are my own.

Comments are closed.