Patching and software update strategy/methods for workstations

Usage and Config
1

This is mostly a strategy question/discussion. I was curious to hear from others and how they choose to deploy their patches, vs how they are choosing to deploy software updates, etc. My end goal is to make it as invisible as I can to the end user, but it’s not always possible for some things.

Security patches are pretty easy since they can be applied in the background and do not require an immediate reboot. I typically apply things after business hours, and I can eventually hit the unreachable/offline targets during business hours at a later time as necessary. The main ‘gotcha’ with them, at least for windows 10, is how long the reboot can take to fully apply and finish installing updates. I try to keep everyone informed of when this might occur, so they can be ready for the potential downtime.

Software updates are a little trickier. Usually the software needs to be closed while being upgraded, so it can introduce a small outage window. I typically try to push these after business hours to hit the bulk of my targets. My largest concern/opportunity for improvement is for the eventual push to computers that are typically offsite/offline/can’t wake-on-lan during the upgrades. I’ve tried communicating the expected upgrade time/outage through email, and BigFix messaging on the action etc, but nobody reads it :). Offers are interesting, but relying on users to execute them is not reliable. Curious to hear what others are doing for that scenario!

1 Like
2

In general, I am referring to patching end user devices. (laptops, desktops, persistent VDI, or similar)

I try to deploy OS patches on a similar schedule, but mostly in terms of the day of the week the patches start to be deployed, but not a precise timing. I let them run regardless of user presence in the background.

As for software updates, those are more complicated.

It really depends on if you want to minimize IT effort, or if you want to minimize end user pain and suffering.

In my opinion, the goal should always be to work towards less end user pain and suffering, but at the same time, IT Support is criminally underfunded and undervalued, which disincentives doing the right thing.

I’m going to document what I think is ideal for users.

You can deploy software updates that are set to prefetch right away, but only install if no user is logged in with a start time right away. This won’t patch all systems, but it will get some. You can have it get more if you logout inactive users after a certain time period automatically. You may need to prevent the computer from sleeping for this to work optimally. It is possible to prevent the computer from sleeping for up to a timeout at the start of a baseline, then allow it to sleep right away at the end if it finishes early.

The next option is to deploy software updates for specific software individually only if that software is not currently running. This really requires REST API automation to implement because otherwise it is just too much work. It is possible to have relevance that is only evaluated during an action and returns FALSE unless the application is closed, at which point it returns TRUE and runs. For this to work best, you need to stop applications from starting with the OS so that there is a greater opportunity for them to run. This option isn’t as useful as it once was since most OSes resume the applications that were previously running on login, but it will catch applications when the user quits them.

The last option is to deploy the same kind of baseline you would deploy only if users are logged off, but this time have it prompt users to accept the action with a deadline, and when it reaches the deadline, it runs regardless. You can deploy this baseline at the same time you deploy the first one, but set a start date in the future so that it doesn’t prompt users right away and gives the other options mentioned above an opportunity to run. Even if this ends up happening for a particular patch cycle, the above options could reduce the time this takes for the action to run.

3

I work in an operations support environment, with shift workers staffing 24x7 and frequently have multiple workstations for each person.

One tactic I take is to send baseline actions, and use a custom constraint property to “Run only when … PatchWindow … Is not … Closed”. The actions queue up on the clients, prefetches begin, and the actions status as ‘Constrained’.

Then I send an Offer action that allows the user to toggle their PatchWindow to ‘Open’. When they take the offer, their patch window opens and the Constrained actions execute, reboots happen, etc.

I send a second, ‘Deadline’ action, so if the user does not opt-in via the Offer by a deadline time, their patch window will open and their machine catches-up.

The Offer sets the effective date of PatchWindow to {now}, while the Deadline sets effective date to {parameter "action issue date" of action}. So once they opt-in, the Deadline won’t send them back into the patch window because it would be setting an earlier effective time for the client setting and is ignored.

1 Like
4

In this kind of environment, having a user opt-in to patching times is useful because they can do it on one, then the other, so they always have one available, but it would be nearly impossible to automate that in a reasonable way on the fly every time.