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)

  1. Remove WFE 1 Loadbalancer
  2. Patch the WFE 1
  3. Restart the Web frontend 1
  4. Add the WFE 1 to Load
  5. Remove the front-end Web server 2 of Loadbalancer
  6. Patch the WFE 2
  7. Restart the Web frontend 2
  8. Patching the following servers: APP01, DC01 and SEARCH01 in parallel, and then restart the servers
  9. Patching the following servers: APP02, DCH01 SEARCH02 and in parallel, and then restart the servers
  10. 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
  11. 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
  12. On the Web frontend 1, run the PSConfig control step 10
  13. Add the WFE 1 to load
  14. On APP01, run the PSConfig control step 10
  15. On PSConfig DC01 run the command in step 10
  16. On SEARCH01, run the command PSConfig Step10
  17. 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/