Overview of SharePoint On Premise Zero Downtime Patching

by | Oct 6, 2020 | Collaboration

Organizations with high-availability SharePoint on premise farms can virtually eliminate system downtime for application patching by leveraging Microsoft’s zero downtime patching functionality. 

What is Zero Downtime Patching (ZDP)?

  • A method of patching a SharePoint farm without creating downtime for the end users. 
  • ZDP was developed for SharePoint Online as a method to patch servers while users continued browsing their tenant sites. 
  • Why is it neededTraditional patching of SharePoint versions prior to SharePoint 2016 required downtime in order to apply service packs and cumulative updates. 

Requirements for zero downtime patching

  • SharePoint 2016 or above. 
  • High availability in the environment is required in order to accomplish ZDP. 
  • Server Roles must have redundancy for this to work.  Note: Minroles come in handy here, but are not required. 
  • A load balancer is required to be able to route users to particular servers while patching others. 

The Side-by-Side feature

  • Running in side-by-side mode ensures that all the web front ends in the farm serve the same static content during the upgrade, even if static files on a given WFE are being upgraded or replaced.  
  • Side-by-side is built in to PSCONFIG but must be enabled. This feature makes sure users have the same experience of the sites when browsing SharePoint and working on their files, even while file-system files are being changed and updated. 

An Example zero downtime patch scenario

  • 2 Front-end with Distributed Cache servers 
  • 2 Application with Search Servers 
  • SQL Server 2016 server 
  • Front end load balancer 

Steps to ZDP

  1. Ensure Side-By-Side functionality is turned on : 
    • $webapp = Get-SPWebApplication <webappURL>
      $webapp.WebService.EnableSideBySide = $true
    • Note: As of the March 2017 update for SharePoint 2016, this feature is auto-enabled. 
  2. Remove 1st front end server from load balancer pool. 
  3. The 2nd front end server will continue to serve content. 
  4. Install binaries on the 1st front end server, reboot when complete. 
  5. Once the 1st front end server is rebooted, it can be placed back into the load balancer pool. 
  6. When the 1st front end server is back in the pool and serving traffic, remove the 2nd front end server from the load balancer pool. 
  7. Install binaries on the 2nd front end server, reboot when complete. 
  8. Leave the 2nd front end server out of load balancer pool for now. 
  9. Install binaries for patch on the 1st application server, reboot when complete. 
  10. Once the 1st application server is rebooted, install the binaries on the 2nd application server.  Reboot the 2nd application server when complete. 
  11. Shut down the distributed cache service on 2nd front end server. 
  12. Run the configuration wizard on 2nd front end server. 
  13. Start the distributed cache service on 2nd front end server. 
  14. Place the 2nd front end server back into load balancer pool. 
  15. When the 2nd front end server is up and serving traffic, remove the 1st front end server from the load balancer pool. 
  16. Shut down the distributed cache on the 1st front end server. 
  17. Run the configuration wizard on the 1st front end server. 
  18. Start the distributed cache on the 1st front end server. 
  19. Place the 1st front end server back into the load balancer pool. 
  20. Run the configuration wizard on the 1st application server 
  21. Run the configuration wizard on the 2nd application server. 

What’s left?

  • With using side-by-side mode, you need to instruct the side-by-side feature what version of the interface to use.  Run powershell to set the appropriate version: 
  • $webapp.WebService.SideBySideToken = <current build number in quotes, ex: “16.0.4338.1000”>

Have questions? Need help building a scalable platform? Send us an email at info@peters.com or call 630.832.0075 to start the conversation.