Very similarly, we issue our Actions with a Custom Constraint, which we define with a custom setting. In the Take Action dialog, we use “Run only when…PatchWindowState does not equal False”
We issue a single action for each Patch Baseline against all computers of an OS (i.e. one action targeting a group “All Windows Computers”, another against “All Linux Computers”, etc.), all using this Action Constraint.
When the patch baseline actions arrive at the clients, they show Action Status of “Constrained” until we set a value for the PatchWindowState client setting and make it anything other than “False”. (If the Client Setting does not exist at all, the Action still remains “Constrained”).
We send a separate action out to clients to change their PatchWindowState settings to a value (we use several different ones). For example, we might have an Offer out to clients to set “PatchWindowState” to “Opt-In”, so the users can start a Patch Window at their discretion. We also schedule a separate action to set “PatchWindowState” to “Required” at a deadline time - and anyone who hasn’t Opted-In gets hit at the Deadline time.
We have another action that schedules the reboots, also constrained based on the values of PatchWindowState. If PatchWindowState is “Opt-In”, we give a “nice” reboot message with 24-hours to reboot. Once PatchWindowState changes to “Required”, they pick up a different Reboot action, which is “less-nice” and only gives 2-hours notice for reboots.
This is very similar to the Maintenance Window dashboard, except that we don’t lock the entire client. These settings only affect our Patch Baselines that are configured with the action constraints, so the clients do continue executing any other actions that are sent to them.