As an add-on to my previous blog post about SharePoint Server 2016 Zero Downtime Patching Neil Hodgkinson, Bob Fox and Karl Reigel recorded a video which demonstrates Zero Downtime Patch from Start to Finish:
Have a look at the video – the first 10 minutes are more or less a read of my article in an audio-book style, the remaining 20 minutes contain a demonstration of zero downtime patching in an actual farm.
In the video they are using only the PSConfig parameter which performs the database upgrade. When performing the steps on a production environment ensure to use a required parameters as outlined in this article:
Permalink
Interesting… the video recommends installing and running the configuration wizard on the application servers first however, the steps below the video suggests doing the Web Front Ends first. Or did I miss something.
Permalink
Hi Bismarck,
thanks for the heads-up! I have sent the feedback to the relevant people to see what our official guidance for 2016 is.
Cheers,
Stefan
Permalink
I think it boils down to where you want central admin to be. It’s a good idea to put it on a server that’s accessible only from your internal network, so usually that means any server that’s not WFE.
Permalink
Agree Piotr but in this case its up to the admin on how well they lock down the environment and access into CA. Good point though and again both ways work.
Permalink
We recommend that you run the first Upgrade on the box that hosts Central Admin. In this case that is running on both of the Web Front Ends.
Permalink
Perfect! Thanks Bob for the clarification! 🙂
Permalink
So the guidance now is to ‘not” stop Search (NET STOP OSEARCH16) on any server, or stop Distributed Cache before applying updates?
Permalink
Bob. You no longer need to stop any service instance – The go local logic inside the SharePoint 2016 architecture will always direct service requests to machines that are online and you do not suffer from the problem of service requests being directed to servers that are not online just because they are registered in the application loadbalancer. In SP2016 the application loadbalancer is a fall back to the go local logic only. This means that if you have a HA farm then you will not suffer outages if you maintain the upgrade domain logic as explained in the video and in Stefans blog.
For distributed Cache, if social feeds are important to your environment then yes you need to follow appropriate guidance and flush the cache to another machine before patching. We mentioned this in the slides after the demo but didn’t demonstrate it for time saving reasons.
Permalink
Great article and video, thanks Bob and Stefan (as well as Neil and Karl) !
Question. During a Prod SP2016 Search farm install I see we need to be HA and follow upgrade domains, thats fine. Do we need to pause/stop crawls or should we just let them go as normal? I have customers with pretty tight crawling schedules. -Thanks
Permalink
Kris. I think for sanity reasons only I would prefer to pause crawls when patching regardless. On a personal level as the operations Engineer I would always prefer the farm to be in a known state prior to patching. Crawling as you know being a search specialist goes through a number of states through out he duration of a crawl. Although technically you should be able to patch without considering crawling, the former PFE in me says don’t do that.
Permalink
please let me know any MSDN article about 2016 Zero Downtime Patching
Permalink
MSDN is for developers. Patching is an Admin Task – so Technet would be the right place.
And this post contains a link to an Technet article.
Permalink
The article ‘Video demo of Zero Downtime Patching in SharePoint Server 2016’ doesn’t have any video. Has it been taken off or moved? Please help!
Permalink
I’m referring to the link in your article. https://technet.microsoft.com/EN-US/library/mt767550(v=office.16).aspx
Permalink
Hi Aneesh,
the video is currently being updated with new content. Should be available again in a couple of days.
Cheers,
Stefan
Permalink
The new video is now available.
Permalink
Thanks Stefan!
Permalink
Is this applicable only for 2016 HA environments?
Permalink
Only for HA – otherwise you won’t have the necessary redundancy to switch one server of during patching.