Best way to exclude computers from an Action?

[straffin]

We’d like to exclude particular computers from a particular action. What is the best way to do this?

I’ve created an “exclusion group” made up of the computer names to be excluded, but am unsure of how to go about it from there:

• I could add a relevance to the action of not exists (members of groups ######### of sites “My_Site”), but that could allow the action to apply before the group membership is established.
• I could make another “target” group that is all computers not in the exclude group. This may also allow the action to apply before group memberships are fully established.
• Any other ideas?

I’ve used an exclusion group so far because this will be a “policy action” and the targets and exclusions will change over time. I was also planning to create another “undo” policy action targeted at the exclusion group to clean up if the first ends up inadvertently applying due to group membership resolution.

[itsmpro92]

Maybe use a Computer setting to on all computers that should not be applicable (from the start) to include in the relevance, and then introduce the exclusion group. Your undo action could also include the preventative computer setting action.

[straffin]

It won’t be me identifying the excluded computers and the folks who will be may not be able to set Computer Settings, so that’s why I went with a group. Easier for them to see what computers are affected as well.

This also sounds like it would allow deployment before the setting is set.

(I really hate exclusions… targeting needs to be done by positive assertion, not negative, to avoid false positives. But, marking 99.8% of computers to receive something rather than 0.2% to NOT receive it is really inefficient.)

[itsmpro92]

Agreed - exclusions to a policy, when used, should be more or less permanent, and even then should be authorized by proper Change Management.

[D.Dean]

You can do something like this. We use it.

(("|" & computer name & "|") is not contained by "|Server1|WS1|WS2|DC1|BDC2|Computer1|Computer2|Computer3|")

Or to include them...

(("|" & computer name & "|") is contained by "|Server1|WS1|WS2|DC1|BDC2|Computer1|Computer2|Computer3|")

[straffin]

Where are you using this? In the Action Relevance? In a Group Definition? This is for a Policy Action whose Target will change over time, so we’d need a dynamic way to include/exclude. Static lists won’t work.

[fermt]

Do they have access to the computers?
If so, maybe an easy way to accomplish this is having a registry key in place that you can use as parameter in the relevance check that filter those systems out from the Fixlet.

[D.Dean]

We use it in the relevance but you could also use it in action relevance.

We do have a very robust patch exception process that would work for your request.

Setting the stage:

We are multi-tenant and customers often request we don't patch a system or application for whatever reason. We have a client setting that we can populate with with a code that corresponds with the application or type of exception we need.

(The following is copy and paste from our KB on the subject.)

Exception Processing and Example

We decided to make the exceptions cryptic by entering them as 6 bite binary code. This turned out to be highly beneficial because now we can enter multiple exceptions (tags) with a delimiter and use the relevance language “contains”. We were cryptic because we don't want anyone outside of my team to put in exceptions without our knowledge.

The EP - Google Chrome baseline ONLY contains patches for Chrome and EP - Mozilla Firefox baseline ONLY contains patches for Firefox

Binary
000101 = "No Chrome"
000110 = “No Firefox"

If a system is tagged 000101, no chrome patches
If a system is tagged 000110, no Firefox patches

Relevance language used on those baselines:
The following relevance works; but it is not how I would write it. I pulled it from one of our baselines.

not exists (if exist values of settings "MRS_PE" of client then value of setting "MRS_PE" of client else "False") whose (it as string as lowercase contains "000101" as lowercase)

If PE tag does not contain 000101 the EP - Google Chrome baseline is relevant and Google Chrome patches will be deployed

If PE tag does not contain 000110 the EP - Mozilla Firefox baseline is relevant and Mozilla Firefox patches will be deployed

We can use a delimiter to put multiple exceptions in the tag (: is the delimiter)
When we use the relevance "contains" systems tagged “000101: 000110” will not be relevant to Google Chrome OR Mozilla Firefox.

Finally, we have a backup of this exception in the registry in case the agent is uninstalled with the BESremove tool and the BigFix is reinstalled. If the two values, the client setting and the backup reg key, do not match, we have a policy to add the system to a discrepancy group and then anything in that group gets locked to prevent the undesired patches from being deployed.

=====================

So for you, you could create a custom client setting (Best to be OS friendly) and create a task to set it. Then you can set the property to whatever value you want, and use relevance in the policy to exclude anything that has that property.

[straffin]

This sounds really great (I love the obfuscatory codes… I do the same with our CrowdStrike grouping tags), but it still has the issue of presenting a race condition: which gets there first… the action or the setting to prevent the action? This is also a situation where local admins need to be able to put the exception in place without dragging my group into it . Thinking more about this as you folks all share ideas, I’m realizing that this is pretty much always going to be a “remove it and don’t put it back” situation rather than a “don’t put it there in the first place”, meaning the race condition will always be in a “second heat”, so to speak.

I also still think the problem at large is that exceptions are generally terrible and positively identifying the proper target is a far superior solution.

Sounds like either the extra target group OR relevance would be fine, but there definitely needs to be an undo action (that blocks redo) for the most likely scenario.

[D.Dean]

@straffin

but it still has the issue of presenting a race condition: which gets there first

Yes it does. We have this issue with Citric Provisioned servers and Non persistent VDI. They usually have limited disk space and they get their patch settings from the Gold Image they come from. So they will start downloading the data and then find out they are not relevant any longer.

We have moved away from those mostly, I think we have one customer left. However, there are work around. For example, create a task at the top of our baseline (component group) that is simply a delay. Run an action that simply pauses.

parameter "startTime" = "{now}"
pause while { (now - (parameter "startTime" as time)) < 15 * minute }

[straffin]

@D.Dean

create a task at the top of our baseline (component group) that is simply a delay. Run an action that simply pauses.

Oh… Oh my. That is gold. Pure, 24 karat gold.

Thank you!

[JasonWalker]

For this use case, I'd probably use Custom Constraints. This is how we implement Maintenance Windows, under the hood.

First you create a Global Property with a name like "In Exclusion Group". For the Relevance of that property I'd probably go with a simple client setting like

exists setting "exclusion_group" whose (value of it as string = "1") of client

When you take the Action, you populate that in the 'Run Only When' field, so that the action only runs where this value is not True:

Then your delegated admins can add or remove their machines from the exclusion group by applying the client setting. They can even apply it at installation time using a clientsettings.cfg so machines get installed with the Exclusion by default.

This 'run only when' sets up a Constraint which is also a relevance evaluation. This is a second evaluation that only happens while the action itself is relevant. If the Constraint is not satisfied (this client is Excluded), the Action Status becomes 'Constrained' instead of Not Relevant, which is usually more helpful in my opinion; it helps distinguish between machines that are already fixed/upgraded, versus those that are still in the queue but excluded for now.

Constraint Relevance also evaluates much more frequently than normal fixlet background evaluation, so when you switch a machine from Excluded to Not Excluded, the action usually picks up and runs much sooner than if we were changing a normal relevance evaluation result.

[straffin]

Any idea how this would behave if a targeted computer gets the Action before it gets the Group membership?

[itsmpro92]

If the consequence of the Action arriving first is not "deadly", you could put the Undo action in the actionscript of the Exclusion Action.

[atlauren]

Seems that if you want the flag (whether 1 or 0) to be a global gatepoint, you need to introduce it as a gatepoint?