Sharepoint 2019 zero down time patching gives short downtime

Question

Hi,

We are trying and planning to implement a sharepoint 2019 farm which supports ZDP.
I have read these articles and watched the entire video.
https://learn.microsoft.com/en-us/sharepoint/upgrade-and-update/sharepoint-server-2016-zero-downtime-patching-steps
https://learn.microsoft.com/en-us/sharepoint/upgrade-and-update/video-demo-of-zero-downtime-patching-in-sharepoint-server-2016

The main question is the "simpleness" behind the instruction "Take the webfront out of the load balancer".
Our loadbalancer is BIGIP from F5. The settings there is that if you currently have a connection with the front end, the load balancer doesn't kill/migrate/transition/drain your session. You get to keep it even though the webfront (node) is out of rotation. This has X seconds of timeout so it doesn't take much for you to hop on over to the next webfront but there are scenarios where users are so active that they will keep the session with the front end that is about to be patched.

I have tried this my self and I eventuelly run into the error message "503 service unavailable". I refresh the page for 3-5 seconds and I now I have jumped over to the other web front.

The question is: Is it really zero downtime patching or short downtime patching?
Do you have any recommendations for settings in a load balancer? Surely they are not all the same. Perhaps some settings are unnecessary if Sharepoint deal with some issues that occur when trying to patch with zero downtime?

Answer 1

Hi @Daniel M
As per my research, I couldn't find any documentation on this issue. I would suggest open a ticket with Microsoft to help you to troubleshoot.

---

If an Answer is helpful, please click "Accept Answer" and upvote it.

Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.

Answer 2

I have tested some more.

The settings for a webfront that is a member of a pool in BIGIP are these:

Enabled (All traffic allowed)
Disabled (Only persistent or active connections allowed)
Forced Offline (Only active connections allowed)

I am sure that once the webfront is out of the load balancer (completely) then everything that has to do with windows, sharepoint and sql will probably work just fine. You are depending on the load balancers ability to actually not send users to the web front that is about to be patched.

I had better success with "forced offline" than "disable" in BIGIP. I constantly refreshed the sharepoint site and the web front that was disabled stilled served me the front page. If I wanted to I could "hang on to" the webfront so to say.
I changed the logo on the start page according to this article to be able to see which front end I was hitting.
https://www.sharepointdiary.com/2014/09/how-to-find-which-sharepoint-server-is-serving-to-you.html

Perhaps this is not normal user behaviour to constantly refresh the page like that....
The only thing I am wondering now is if there is any scenario that users may find downtime?

If I open a word document, make changes to it for quite some time without saving. By the time I am about to save my changes, the web front end may have been disabled from the load balancer and I get an error?
Or if I open a infopath form or trying to create a new item in sharepoint with many forms to fill. When I hit save/send, might I get an error if the web front has been disabled during the time I am filling out the form?
Do you see what I am trying to get at? Can we "force offline" and sharepoint will handle stuff "in the background" with the scenarios I am describing?