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 use ZDP. NO! To my surprise I 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 during 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 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 184.108.40.206 version of the 220.127.116.11 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 headache (after seeing the video of course)
- Remove WFE 1 Loadbalancer
- Patch the WFE 1
- Restart the Web front end 1
- Add the WFE 1 to Load
- Remove the front-end Web server 2 of Loadbalancer
- Patch the WFE 2
- Restart the Web front end 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 front end 2 is not to load, open the Management Shell and run the following command PSConfig: psconfig -cmd -upgrade inplace b2b
- Once the upgrade is complete, add the WFE 2 to Load. Once the front-end Web server 2 was added to the Load, delete the Web front end 1 of the load
- On the Web front end 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
I hope this video and my explanation will benefit you during your upgrade machines https://technet.microsoft.com/EN-US/library/mt767550(v=office.16).aspx
- Video demo of Zero Downtime Patching in SharePoint Server 2016 (https://technet.microsoft.com/EN-US/library/mt767550(v=office.16).aspx