SharePoint Tidbit - SharePoint 2016 and Zero Down time simplified

Hey Guys,

Hopefully you have read about Zero downtime in SharePoint 2016 it is quite simple and easy to use but often looks complicated, don't take this the wrong way I suggest you take this seriously and perform testing and have a rollback plans but this is an awesome feature.  There are a few different moving parts that provide that Zero Downtime and if you don’t have each part configured properly then you start accruing downtime, this is a simple look at the feature.

Part 1 – Installing update on each server

As we install the update to each SharePoint server this will cause downtime that we can’t get away from, the way to resolve this is to have your services installed on at least two servers, so have two search servers (This should include all components although it could be argued that only query and index need to be load balanced for this purpose), two Web Front End’s, two Distributed Cache Servers, etc and make sure that while you apply the patch to a server you are not applying it to the other one at the sametime.

To help improve the speed that the patch is installed to the server itself I suggest trying the script created by my fellow PFE Russ Maxwell (https://blogs.msdn.microsoft.com/russmax/2013/04/01/why-sharepoint-2013-cumulative-update-takes-5-hours-to-install/)

Do NOT run PSConfig at this time!!

Part 2 – Updating the Database

This is where I feel the Zero Downtime shines, we can now upgrade a database online while still connected to the farm.  Using the cmdlet Upgrade-SPContentDatabase (https://technet.microsoft.com/en-us/library/ff607813.aspx) and at least SQL Server 2012 (https://msdn.microsoft.com/en-us/library/ms175158.aspx) you can update your databases in read-write without causing any downtime. 

Part 3 – Running PSconfig.exe on each server

Now that your content databases are updated we need to complete the patch install and update the Service Application databases.  You can do this by running the command line psconfig.exe (https://technet.microsoft.com/en-us/library/cc263093(v=office.14).aspx) or the gui version first on one server, then start it on all other servers, this will again cause downtime on each individual server as we stop several local services, so having HA for each service application and role (Or at least those important to your enterprise) is important.

Articles from the experts: https://blogs.technet.microsoft.com/stefan_gossner/2016/04/29/sharepoint-2016-zero-downtime-patching-demystified/ https://www.harbar.net/archive/2016/08/04/Zero-Down-Time-Patching-in-SharePoint-Server-2016.aspx https://blogs.technet.microsoft.com/pla/2016/03/10/zero-downtime-patching-in-sharepoint-server-2016/

Pax