Need Platform improvements: Efficiency, Inspectors, Virtual properties, etc

Ideas
1

It is very rare that I run into real limitations of BigFix. I find the platform very capable, and many limitations can be worked around.

Some of the biggest limitations that I feel are some basics in the platform itself.

Inspectors:

I can’t really make my own inspectors. If they aren’t there, or there are missing parts to them, then I’m either stuck, or I have to jump through hoops to work around it. Running a task that outputs a file and then reading the results back is in some cases a valid way to get around inspector limitations, but it isn’t ideal, and in some cases much less so than others.

Also, I need more mac inspectors, updated SQLite inspectors on all platforms, etc…

Efficiency:

There are some things I can do with the way I use BigFix to optimize the overall efficiency, but I can only do so much. I’m very interested in platform changes that can help increase overall efficiency of the platform and remove some of the limitations where possible.

One thing I wish the platform had was a way to set an evaluation period for fixlets, tasks, baselines, and analysis applicability relevance in a similar way as the reporting period for properties. This would also apply to automatic groups, site subscriptions, and many other items.

Many of these items I would need to have the current behavior where they would be evaluated during every eval loop, but often most of them don’t need that much attention, particularly for baselines, fixlets, and tasks where the only real feedback I’m getting is if the computer thinks it is relevant or not. This is different from an actual action/deployment where it would run it if it is relevant, which is a more significant result.

I’d say I usually only care if a computer is relevant to a particular item if that item was just created or modified, and then I only care about it from there over the long term… once every 6 hours give or take. Another time I might care is if an action was just executed on an endpoint that was based upon that content, but even then I don’t always care that much.

In general I care a lot more about clients responding to actions as needed, but similarly there are many actions that I create, that really only need to be evaluated one time. Either they are relevant and they run, or they are not and that is unlikely to change. They could easily only be evaluated after the first time every 6 hours or less often.

I also have actions that are the opposite. I care about them responding to changes in the user state, the system power state, the network state, and similar other criteria. I want them to fire off rather quickly to these kinds of state changes, but once they have run, they really only need to run again if the state changes again. They could just be more aggressive all the time, but it would be even better if they only needed to be in response to events, but in general I have actions that I want to be much more reactive than actions are currently.

Virtual Properties:

This is a concept that I have been thinking about for a while now that potentially solves a few problems for me.

There are 2 different models, and I really have a need for both.

  • One is a property that shows up in an analysis but is actually sourced from a different analysis or property.

You can do this in the console by looking at the results and adding columns, but this only affects the currently logged on user. In order to do this for all users, I have to duplicate the property, which doubles up the amount of evaluation the client must do for this same relevance, which is not ideal… then multiply that by all of the analyses where this is an issue.

  • The other is a property that shows up in the console or an analysis, or etc… but is actually a calculated session relevance result from another property or set of properties.

One example is where I want the raw data reported by the client to be the actual time & date of something occurring, but I want to also have the option to display how many days ago that was in the console. The issue is if this is done on the client, then it is actually only valid since the last report time of the client, so it is effectively always wrong.

I can effectively do this in WebReports using custom reports, but I can’t do it in the console directly. Even so, this is also a problem in WebReports. Often I just want to display the results of an analysis in a WebReport, but if I have to calculate some values using session relevance, then I’m forced to use a custom report which requires much more effort.

Related:

CC: @AlanM

4 Likes