I have created a baseline that performs driver updates for our machines. I want to achieve two things:
Deploy the driver update baseline in a "phased rollout". i.e., deploy to a small group, then to increasingly larger groups of users. Essentially we would use Active Directory OUs for my org.
Run this action recurringly on a schedule, e.g., once per month.
Patch policy seems to be the intended way to achieve this but patch policy seems to only deploy fixlets and not baselines. I would prefer not to condense my baseline into a single fixlet, I can share the baseline if needed.
Any recommendations on achieving this? So far I have been doing this manually and would prefer to automate this process.
Is that Baseline going to be modified, so basically a new Baseline each month, or is it going to be static for several months in order to rollout across the entire estate ?
This is one way that comes to mind.
Create the Computer Groups mapped to OUs
Create a non-expiring (Policy) action for each computer group from that Baseline, and target dynamically by group… ensure that the execution constraints are set such that the action never ends, retries on failure, reapplies the action, and then ‘Run only when’ a property matches true.
The Run only when constraint uses a retrieved property that returns TRUE only on the specified day and time of every month… set the relevance to evaluate this day and time.
You need one day/time property per group
I wanted individual actions per deployment instead of a single repeating action, but I think this approach could work for us. This specific relevance will only work in our environment, but this is what I ended up creating for it:
disjunction of (if (setting "Computer Type" of client as string contains "Workstation") then (((if it contains "OU=Workstation Support," then ((current date) >= (first monday of current month_and_year + 1day) and (current date) < (first monday of current month_and_year + 1day + 2week)) else false); (if (it contains "OU=Database Services," or it contains "OU=Is Policy Application Team,") then ((current date) >= (first monday of current month_and_year + 1day) and (current date) < (first monday of current month_and_year + 1day + 2week)) else false); (if it contains "OU=Information Systems," then ((current date) >= (first monday of current month_and_year + 2day) and (current date) < (first monday of current month_and_year + 2day + 2week)) else false); (if it contains "OU=Federation," then (nothing) else false); (if it contains "OU=Home Office," then ((current date) >= (first monday of current month_and_year + 3day) and (current date) < (first monday of current month_and_year + 3day + 2week)) else false); (if it contains "OU=District Claims Offices," then ((current date) >= (first monday of current month_and_year + 4day) and (current date) < (first monday of current month_and_year + 4day + 2week)) else false); (if it contains "OU=County Offices," then (nothing) else false); (if (exists matches (regex "OU=(Desktops|Laptops),OU=[A-F].OU=County Offices,") of it) then ((current date) >= (first monday of current month_and_year + 7day) and (current date) < (first monday of current month_and_year + 7day + 2week)) else if (exists matches (regex "OU=(Desktops|Laptops),OU=[G-O].OU=County Offices,") of it) then ((current date) >= (first monday of current month_and_year + 8day) and (current date) < (first monday of current month_and_year + 8day + 2week)) else if (exists matches (regex "OU=(Desktops|Laptops),OU=[P-Z].OU=County Offices,") of it) then ((current date) >= (first monday of current month_and_year + 9day) and (current date) < (first monday of current month_and_year + 9day + 2week)) else false)) of (distinguished name of local computer of active directory as string)) else (if (setting "Computer Type" of client as string contains "Workstation") then ((current date) >= (first monday of current month_and_year + 10day) and (current date) < (first monday of current month_and_year + 10day + 2week)) else false))
Sorry I'm late to this party, but this is exactly what Maintenance Windows should solve. Check the "Manage Maintenance Windows" Dashboard for a starting point.
The idea is you can send one action, targeting all of your computers, with a constraint that the action only runs when that computer is within its scheduled Maintenance Window.
Then, you schedule different maintenance window times into your separate batches of computers.
When each computer reaches their scheduled Maintenance Window, they start running your driver or patching actions, and then stop when their maintenance window schedule closes
And you are left with a single driver install action, that can show your percentage of complete, success, failure, or waiting for maintenance window time, across your entire estate.
I feel foolish for not thinking of this. However, I noticed that you can only set maintenance windows for a maximum of 24 hours. For something I want to run monthly, having a computer offline for just a single day can miss the window and would lead to waiting another month. Ideally the window could last a week to give the computer ample time to take the action.
EDIT: Also, I cannot do the first Monday of the month + a number of days. My first group of computers to take the update needs to take it first so there is time to inspect potential issues with the driver updates. Our driver repo is updated the first Monday of every month, our first group should take the driver updates the day after. The limitation of not being able to add first "day of the month + additional days" in maintenance windows means I'd have to do the first Tuesday of every month for my first group; if the first day of the month is anything but a Sunday or Monday then the driver repo won't be updated.
The method @gbl888 mentions above is useful, and it's the basis of how Maintenance Windows work.
(Assuming you're on the thick BES Console)...the "Run only when" constraint on the Take Action dialog can be based off of any Global Property. It doesn't have to be the "In Maintenance Window" property that the maintenance wizard generates, it can be anything you like. So you can create windows of longer durations, repeating as frequently as you like.
In my last job, I had something to allow end-users to set their own time. I had an Offer Action to "start maintenance window", and when the user accepts the Offer it applied a client setting to start their maintenance window and patches would start running. Then I had another repeating Policy Action that would close their maintenance window again, once that client setting was 4 hours old, so their window would close. Then each month I'd set up patch baseline actions (targeting everything), as well as actions to force starting maintenance windows on endpoints, only if that endpoint's maintenance window client setting was 30 days old (i.e. the user never took the Offer).
That way every machine had a maintenance window every month, and the user could choose when that happened if they accepted their Offer before my forced maintenance time started.
Just some ideas of the things you could do...mull it over, and if you like any of those approaches but need some help with the mechanics, let us know.
Yeah this in particular is an annoying limitation of the Manage Maintenance Window dashboard - especially since the Patch Policy scheduling in WebUI does support "first NAMED day of month + X days" option.
I've done this plenty in custom relevance, just the Wizard doesn't support it.
If you want to build a custom setting in relevance for that let me know, we can help with that too.
With my previous employer, we leveraged local endpoint settings, in our case in the registry, to define a weekly maintenance window such as day of week, hour of day, duration etc, then used that for controlling when Bigfix activity would run. Of course, these settings could be file based or even client settings but for us we were using Bigfix to take over from another tool that already had registry based maintenance windows configuration.
We then used fixlets that locked and unlocked the agent (which has both pros and cons but for us lock state was most suitable), with the unlock fixlet being in a custom site that had lock override applied. We could have had a global property that envaulted True of False when the maintenance windows was active and then used that as an action constraint but our case was we needed to prevent any actions from running regardless of who had deployed them or what type of content it was for, e.g patch, software updated, config changes etc.