Philosophy: Settings vs Properties

Hey BigFixers, I’ve got a philosophical question for you:

Why use a Property instead of a Setting? or Why use a Setting instead of a Property?

That’s an intentionally wide-open question, since I’m interested in your thoughts and practices. I don’t really have a problem I’m trying to solve, just an understanding I’m trying to develop.

Thanks!

1 Like

BigFix Settings and Properties are very different things.

BigFix Settings are a cross platform way to tag a system with info. They are mostly static.

Properties generally use relevance to come up with a result. The result can change automatically if the device is changed. For example, if it were to be moved to a different subnet or a different OU, that could affect the result of a property relevance evaluation (if either of those are used) but it would not affect the Setting until someone intentionally updated the setting.

You could have a property that attempts to determine the primary user(s) of a system by checking which user(s) login most often. This property might not be perfectly accurate in all cases, but might work for the majority of cases. The other advantage is if the device is reassigned to a new user without being wiped first for some reason, then the property will eventually report the new user correctly. If however you KNOW the primary user of a system, then you can tag that system with a BigFix setting so that the primary user is recorded and known. BUT in the case where the device is reassigned to a new primary user, then the setting will be WRONG until it is manually updated. This is why I like a hybrid approach. Tag the system with the primary user when it is known or obvious from the property result, but also have an analysis that tries to dynamically figure out the primary user so that you can see where there are discrepancies and investigate it: https://bigfix.me/analysis/details/2995831

Obviously primary user is just one example, BigFix settings could be for any purpose.

All that said, you should not overuse settings because their values get sent back by the client with EVERY report no matter what. This is both good and bad. If you overuse them, then the minimum report size for all clients will grow.

1 Like

This is exactly why I left it wide open. It would have taken like 2 years for me to even think of seeing if BF could be used for calculating the most likely primary user!
Also I hadn’t thought of the settings being reported, and how that can be both boon and bane.

Right quick: Am I right in my assessment that Settings are set on the client device, but Properties are in the BigFix database itself?

1 Like

These are all good questions you are asking. The short answer is they are both on the client and the bigfix database in effect, but you can use settings in other relevance evaluations because they are semi static, while you cannot use the results of properties in other relevance evaluations (for the most part) because they are semi dynamic and might result in a kind of infinite loop of cascading relevance changes, where every evaluation loop the results would change due to changes from the previous loop. You can automatically update the value stored in a BigFix client setting based upon a relevance evaluation through the use of a BigFix action, but even then this is self limiting because it can only change as often as the action runs on the client.

Settings are set on the client device either through a clientsettings.cfg file upon initial install, through direct configuration of the settings on the device, (Windows Registry or a File for non-Windows) or through a BigFix action. A clientsettings.cfg or BigFix action is generally best.

Once a setting is set, then the client reports back the name, the value, and the effective date for the setting with every client report and the root server then keeps track of it in the database. It can be reported on with session relevance. The values stored in settings CAN be inspected on the client using relevance and CAN be used in other relevance evaluations.

Properties contain client relevance. They have a name, a reporting interval, and the relevance the client should evaluate to come up with the result. Ideally the reporting interval would be once every 6 hours or less often for optimal efficiency of the client evaluation loop, but there are valid reasons for efficient properties to report more often. When a property is created, it’s name, reporting interval, and relevance is sent to the client by updating the contents of a site and the client being told that there is new site content to gather. Once the client gets the new property, it will evaluate the relevance and send back the result so that it can be tracked by BigFix and available in the console and in session relevance. The BigFix client will keep track of the property result from the previous evaluation and compare that result on the next evaluation. If the result is the same it WILL NOT update the result in it’s reports. It will only do so when the result changes. This is the essential difference between a regular “client report” and a “full report”. Regular client reports are differential and only report changes. This allows relays and the root server to be more efficient by reducing the amount of data from clients they must ingest. If you tell a client to send a “full report” then it will send up all results from all properties and the true/false status from all content. Full reports are very large and will take the root server much longer to ingest into the database.

1 Like