SharePoint Server 2016: Zero Downtime Patching
Introduction
One of the big news with the arrival of SharePoint Server 2016 was the ability to patch your machines without any end-user side disturbance. Many of us - including myself - had understood that the new topology design called "MinRole" was necessary and a prerequisite to using ZDP. NO! To our surprise, we have seen a section - a superb article elsewhere - on how to patch the SharePoint farm without any break. Let me explain…
With SharePoint Server 2013
Downtime is caused by patching SharePoint Server binary during installation and during execution of the Product Configuration Wizard.
During the IIS Server process is ground and/or recycles and hotfix installation can take hours - and I mean 5H, by the time - because of each installation of an MSP recycle the SharePoint services and is for this reason exactly why the SharePoint patching is super painful. Russ Maxwell explains everything in detail here: https://blogs.msdn.microsoft.com/russmax/2013/04/01/why-sharepoint-2013-cumulative-update-takes-5-hours-to-install)
Also note that the transactions phone data changes in the database configuration or in the content database, the views, the Stored Procedures, etc ... are triggered by the same SharePoint server; and therefore the time of patching is even longer and this may still cause "failures" during the patching.
With SharePoint Server 2016
During the patching SharePoint Server 2013, everything was in "read-only" mode, and it was not possible for you to add documents for the patching of servers. SharePoint Server 2016 uses the ideology "go-local" meaning that you can - FINALLY - add documents while you patch your machines. The local authorities are taken into consideration ...
Remember the old server with SharePoint; even if your machine was on the floor the call UPS tried to return until he realized that the server was down. Well, it's all over now, thanks to the go-local!
Another big change is that; in the back end, finally, SharePoint Server works with different versions. A stored procedure on one server can have the 1.5.1.1 version of the 1.4.1.1 version on the server2 ... The backward compatibility mode
Soon can we conclude that the old and new X X can coexist together and this in the same SharePoint farm?
In this video: https://technet.microsoft.com/EN-US/library/mt767550(v=office.16).aspx explains how the downtime patching is fêtable without MinRole; but with the ideology of MinRole, Having a duplicate infrastructure. Make sense, right?
Imagine your topology consists of 2 front, 2 Application, 2 and 2 Distributed Cache Search. Here are the steps to follow to have your patching without a headache (after seeing the video of course)
- Remove WFE 1 Loadbalancer
- Patch the WFE 1
- Restart the Web frontend 1
- Add the WFE 1 to Load
- Remove the front-end Web server 2 of Loadbalancer
- Patch the WFE 2
- Restart the Web frontend 2
- Patching the following servers: APP01, DC01 and SEARCH01 in parallel, and then restart the servers
- Patching the following servers: APP02, DCH01 SEARCH02 and in parallel, and then restart the servers
- On the web frontend, 2 is not to load, open the Management Shell and run the following command PSConfig: psconfig -cmd -upgrade in place b2b
- Once the upgrade is complete, add the WFE 2 to Load. Once the frontend Web server 2 was added to the Load, delete the Web front end 1 of the load
- On the Web frontend 1, run the PSConfig control step 10
- Add the WFE 1 to load
- On APP01, run the PSConfig control step 10
- On PSConfig DC01 run the command in step 10
- On SEARCH01, run the command PSConfig Step10
- Once the upgrade has completed repeat steps on APP02 servers, DC02 and SEARCH02
Video download link
Hope this video and explanation will benefit you during your upgrade machines: https://technet.microsoft.com/EN-US/library/mt767550(v=office.16).aspx
References
Credits, initially posted at: https://gokan.azurewebsites.net/2016/08/05/sharepoint-server-2016-zero-downtime-patching-enfin-expliquee/