Patching SharePoint Management 101

Patching is considered to be one of the administrative tasks indispensable to sustainability of the SharePoint production farm. Patching is to not only protect the production farm but also to make it more stable to end-users who use SharePoint business applications every day.

Patching is required when the SharePoint operation team identifies issues that end-users experience during the use of SharePoint solutions.

Patching files commonly consists of the following forms:

  • Critical On-demand Hotfixes: one-off patches that are designed to be installed when SharePoint farm is having particular issues that the hotfixes address.
  • Cumulative Updates: this is a collection of hotfixes that Microsoft release to cover both critical and noncritical hotfixes for SharePoint product. Cumulative Updates are released on schedule. Each Cumulative Update contains all bug fixes that exist in previous Cumulative Update, and likely plus what have been fixed in the last couple of months.
  • Service Pack: this includes hotfixes, new or improved features that Microsoft recommends it to be installed to SharePoint farm.

Patching Strategy

Patching involves several sequence steps that are depicted as the following flow:

The process starts by identifying which type of patching files that address to the issues the end-user is encountering. This stage includes communication between the SharePoint Operation team and the SharePoint Support team in order to discuss deeply about the ongoing issues.

Once the patching approach has been determined, the SharePoint Operation team is accountable for notifying key personnel in the SharePoint Support team. At this stage, the entire plan of patching for the production farm is required. The plan needs to include the following things:

  • Timeline
  • Particular patching files
  • Prerequisites and Activities
  • Test Plan
  • Verification Check-list
  • Communication Plan

After the plan is approved by the SharePoint Support team, the SharePoint Operation team begins performing patching test by installing patching files in the UAT farm. Testing process is required at this stage that also involves the SharePoint Development team. Once patching is complete in the UAT farm, the SharePoint Operation team is accountable for verification of successful patching and results including amount of time that take for the patching, then informing the SharePoint Development team including testers who take in charge of fully testing SharePoint business applications in the SharePoint UAT farm.

The Backup stage is a must since patching SharePoint in the production farm would possibly change some schemas in SharePoint databases or configuration. The SharePoint Operation team needs to manually back up all critical components and databases that make whole SharePoint alive. These include the following:

  • Operating system file
  • IIS configuration
  • SharePoint file systems
  • SharePoint databases
  • Service application (that does not have service application databases)

This stage is to ensure if patching is failed, the production farm can be rolled back at the earlier state.

When everything is completely backed up, the SharePoint Operation team starts executing patching hotfixes, cumulative updates or installing Service Pack in the production farm. The patching may include hotfixes, cumulative updates or service pack for additional products installed in the production farm that are built on top of SharePoint platform (e.g. Project Server) or relevant products (e.g. Office Web App Server). There is a communication plan that is required at this stage. End-user is informed that the production farm would be stopped during patching.

The SharePoint Operation team and the SharePoint Development team work together in the last stage to verify whether the patching is successful or not. This stage includes full test to ensure there is no incompatibility that affects SharePoint business applications. The SharePoint Operation team finally is accountable for reporting to the SharePoint Management team and the SharePoint Support team.

Patching Procedure

There are two patching forms in SharePoint:

  • Slipstream patching: the patching files are included in SharePoint installation files.
  • Normal patching: the patching files are executable.

To perform slipstream patching, do the following step:

1. Download and copy original SharePoint 2013 installation to a network-shared folder.
2. Log into the machine then stop SharePoint Timer Service and IIS services.
3. Run the command to extract update package if any (<package_name> /extract \folderSP2013updates)
4. Run Setup.exe in the SharePoint 2013 installation folder
5. Run SharePoint Farm Configuration Wizard after the setup is complete.
6. Check version and database status in Central Administration
7. Repeat step 1-6 in other machines in the farm
8. Back up the whole SharePoint production farm
9. Repeat step 1 – 6 in every WFE and App machine in the production farm

Caveats and considerations:

  • Slipstream patching takes very much time since it installs SharePoint 2013 from scratch.
  • Slipstream patching is not recommended. It would be useful for a disaster after patching is failed.

To perform normal patching, do the following steps:

1. Back up the whole SharePoint UAT farm
2. Download and copy patching files to every WFE and APP machine in the UAT farm
3. Log into the machine then stop SharePoint Timer Service and IIS services.
4. Install patching files in the machine
5. Run SharePoint PSConfig to upgrade SharePoint database schemas.
6. Check version and database status in Central Administration
7. Back up the whole SharePoint production farm
8. Repeat step 1- 6 in every machine in the production farm

Caveats and considerations:

  • Normal patching is recommended, as it’s safe for the production farm.
  • Normal patching requires downtime less than slipstream patching.

Rollback Plan

Rollback plan is to ensure if patching is failed, the production farm can be reverted back to the previous state.

The step in Rollback plan is to capture SharePoint state and databases before patching would make any changes by adding binary files in SharePoint and schema in databases. Backup needs to be performed manually before patching. Refer to Backup and Recovery Plan and Guideline.


Below are references to be highly recommended:


  1. June 8, 2017 — 3:13 pm

    Thanks Thuan, usefull articles. As you say, if my farm don’t have any issue related OTTB function, I no need patching SP server right?

    • Thuan Soldier
      June 8, 2017 — 5:30 pm

      It depends on the organization you are working. If you work in a public sector organization or the one where security is very strict then they may ask you to patch SharePoint farm to reduce security threat (in case the CU contains security fixes). Normally, if the existing SharePoint farm is still working normally without any bug related to out-of-the-box feature, patching is not *really* necessary. The large SharePoint farm is, the complicated your patching is. Large farm requires a careful patching plan including testing effort which may not be charged if you are a professional service vendor.

      Before patching, do the impact analysis to make sure that every impact can be covered well with your recovery plan. That sounds kinda theory, but this is at least a step to do. Real-world SharePoint 2013 patching is not a silver bullet. It is all about preventive action!

Leave a Reply

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

© 2018 The Soldier of Fortune.