What would be an efficient patching and reboot strategy while using baselines
I am concerned with the performance in #2 if we are restarting after every patch install. If we have multiple baselines, can we restart between baselines and will it achieve better performance that #1?
I’m using Baselines and using a Fixlet to reboot the endpoints not the post-action option that comes with the action’s options.
In this way, I can reboot the endpoint before starting the patching activities(Just if they are in a pending restart state), then let the patches to be installed and as final component of my baseline I use once again the Reboot Fixlet to reboot the endpoints once they got installed patches.
So are you saying there is no benefit as such in performing pending restarts in middle of the window? One reason i have heard is that it slows down the baselines.
But there are others who are proponents of restarting throughout the window so that it might make other patches relevant and they will get applied when baseline reapplies.
When there is something like a Servicing Stack Update in the patches, MS says that it needs to be installed separately from all other patches and requires its own reboot. In those cases, I am putting in a separate fixlet to reboot the endpoint before moving to the rest of the patches in the baseline. I’ve found if I don’t do that, then the endpoint tries to install everything, does the reboot at the end of the action, and then has to retry installing most of them again. In fact, it often requires 3 total reboots. I don’t honestly know if this really make a difference for the overall amount of time required, though.
To be honest, many companies I’ve been at have found that they run into problems with patching if they don’t reboot every endpoint right at the start of the patching–no matter which patching tool they use.
There isn’t really a right or wrong here. It’s a matter of what fits for the staff and the organization.
At my site, we do not include reboots in the patch actions themselves. We have a separate reboot action at the beginning of the window, and another at the window’s end. I’m not certain if two reboots is really necessary, but the team found it worked best. This practice was adopted several Windows releases ago and with a different tool, but it stuck and everyone’s used to it.
We have a set of filters that are used to isolate patches of different variety/priority; those filters are then used to populate baselines.
-Andrew
Thanks for all the suggestions. We use a patch window and a reboot window. We have properties inMW and inRW for the patch and reboot window respectively. So if we have to do a pre-patching reboot, do i need to create a separate property for it or segregate the inMW for that purpose?
Same, we have a very strict patching window. I use pending restart detection relevance on a custom task action (Restart 60) on the front of my baselines, so if there is a pending reboot it will execute first, if there isn’t - its skips right past it. I do the same on the back-end, I find it to be faster than waiting for the post execution restarts (also it removes hindrances in terms of users who forgot to kill their sessions, etc.)
In terms of restarts in the middle of a baseline, or group of patches - no, I bundle them up, make sure they have restart detection in the action script, and hold until the end.
Isnt having restart action as a component not recommended? What would be a best way to do a restart first, patching after than and end with another restart?
We have a patching window followed by a reboot window. How to guarantee the restart action will start before the baselines if both are scheduled during patching window.
There are a lot of different “right” answes to this, and the only “wrong” ones are the ones that end up with patches not installed.
What is your starting point? Do you have a single baseline containing all of your patches, or do you have baselines separated by OS (i.e. one baseline for Win10, another baseline for 2016)? Do you keep separate baselines for non-OS stuff (like a baseline for Office, third-party updates, or the like)?
The simplest form would be to have a single baseline containing all of your required patches. In that scenario, I would organize the baseline into component groups, putting the prerequisites like servicing stack updates first, and include a task to reboot the machine (when the machine isnin a pending restart state) after the prerequisites. The next component group would include any service packs, rollups, etc. and include another reboot after that (again, only for things in Pending Restart), followed by a third component group of the normal monthly patches. When taking the Action, configure a post-action restart with timers and messaging as needed.
Advantages to that? If a prerequisite installed and flags the machine as pending restart, a restart happens. If nothing in the first component group is relevant, then the machine will not be in Pending Restart and we can safely skip that reboot. Either way the machine continues to the next component group (possibly after restarting).
Disadvantages? When you include a Task to restart the machine, you don’t get any options in terms of user messaging, delay options, or cancel options. You also don’t control exactly when the reboots happen - it’s just “sometime after the baseline starts, whenever it’s ready to reboot”. That may be ok for servers that are blocked out in, say, a 2-hour maintenance window, but end-users on their laptops may not appreciate it so much.
Since you list out separate Maintenance Window and Reboot Window, that may not work so well for you either. Since it had become a common occurrence that MS patches require sequencing with multiple reboots, you may end up needing to define two sets of patch and reboot windows. A first phase to do prerequisites and reboot, then a second phase to do patches and reboots. You could give these windows separate values, keep separate baselines for Prereqs and Patches, and use the “Run only when…” constraints on the actions to keep your prereqs and patches running in separate windows.
There are also a lot of options you could do around “breadcrumbs”, or having a task at the end of each baseline setting a client setting and using that value to step through a workflow. Or more customizations around Maintenance Windows. Or Orchestration / Server Automation.
In the end, what are the most important factors to you? Patching as early as possible? Minimizing the maintenance window time? Minimizing the number of reboots? Controlling the times of reboots? Having a gentler user experience around the reboots and messaging?