Delay Native Fixlet Execution


I need to stop the Initiate Software Scan fixlet running during our Win10 OSD build.

For custom fixlets that apply only to Windows 10, this is simple enough, using the following two relevance clauses to find a string in the Windows computer description that denotes that the build is done, like this.

(name of operating system as lowercase starts with "win10")

(exists keys "HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters" whose (exists values whose (name of it = "srvcomment" AND it as string as lowercase contains "SOE Build Complete" as lowercase) of it) of registry)

The problem is the system wide fixlets, like Initiate Software Scan, apply to many different operating systems.

I cannot add either of the relevances above, because it would then ONLY return Windows 10 computers.

I’ve tried to make it conditional, so it only applies the second part of the relevance to Windows 10, but it still ONLY returns Windows 10 computers.

if (name of operating system as lowercase starts with "win10") then (exists keys "HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters" whose (exists values whose (name of it = "srvcomment" AND it as string as lowercase contains "SOE Build Complete" as lowercase) of it) of native registry) else false

Anyone have any suggestions?


Sure. Change the “else false” at the end to “else true”. Logic on that is
if (windows 10) then (check build is complete) else (true)

Rather than customizing the relevance on a lot of the in-box content, you might consider using this relevance to create a computer group and then target the scans against that group; or use this relevance (or an automatic group you create from the relevance) as part of the Site Subscription criteria for the Inventory site (or any number of other sites as well).

I’m pretty sure @jgstew has posted some pretty extensive work on delaying new clients from subscribing to particular sites, in order to speed up their initial provisioning - giving priority to the content you want to evaluate first. If I recall correctly he illustrated the use of minimum of subscribe times of sites > now - 1 * hour to stop a computer from subscribing to a custom site for one hour after its initial installation.


Thanks Jason,

you know I coulda sworn I tried that, but seems to be working now.

Splitting it up was going to be my next effort.

Delaying the site subscription is a great idea and something I had not thought of, but will look at.

Thanks again.

1 Like

minimum of subscribe times of sites is a proxy for the time that the bigfix agent was installed.

You can also look at the time the OS was installed, but that isn’t as cross platform.

See this forum post: Delay BigFix site subscription to speed up client provisioning

The nice thing about adjusting site subscription criteria is that it affects all of the items within it without changing any of them individually.

Another option is that you can have a baseline with additional relevance and then add items to the baseline and run the baseline. That way this additional relevance applies to the baseline components without actually editing the components themselves.

Generally the logic that is used to exclude systems until they have had bigfix installed for a period of time, or until they are flagged as having the build complete should be placed within a Site, a Baseline, or an Automatic Group and NOT within a fixlet itself. The fixlet should only be concerned with if it CAN run, not if it SHOULD run. This allows the same fixlet to be reused in many different ways without concern for the business logic that dictates when it SHOULD run… that is something else’s concern at another layer.

Also, I would recommend that automation that waits for a system to be tagged as completed initial provisioning be time limited, so it would be go as soon as the tag is set, or 6 hours, whichever comes first.