I have a unique report requirement and I have not been able to create the report myself or find information within the forum that can help me.
Here’s the scenario:
We have a BigFix relay that sits in a DMZ. “Mobile” BigFix clients are configured for automatic relay selection, and we use a custom configuration with relay groups and failover. The idea being that when the client is “inside” and can find an internal relay, it uses it… When the client is “outside”, it uses the DMZ relay.
I can build a report that uses the following criteria:
Is “Mobile”
Is using automatic relay selection
Last reported using the DMZ relay
Last reported subnet is not one of ours
The problem is, this will only show me clients that are currently “outside” or were last reported “outside”. As soon as one of the clients comes “inside”, they will drop from the list. I would like to report on ALL clients that have reported via the DMZ relay.
Does the client retain historic information about relays it has successfully reported to, and if so, can reports gather that information? -or- Do relays retain information about (unique) clients that have reported to it, and if so, can reports gather that information?
The short answer is that the agents don’t maintain a complete history of their relay selection. But you can accomplish this task by using an action to tell the agent to record if it has reported to the DMZ Relay.
Try this… create a custom task or custom action:
setting “Used DMZ Relay”=“yes” on “{parameter “action issue date” of action}” for client
Target this to all computers that are reporting that they are using the DMZ relay.
Then you can make a property:
values of settings “Used DMZ Relay” of client
And so any client that has reported to the relay will have a value of “yes” for this setting…
I’m still learning relevances, so I can string this together myself, but I know that we’re creating text files on workstations as markers for the presence of a file or application. Then we have a policy action in place that checks for the existence of the marker - If yes, ok. If no, create textfile with datetime.
Is there a query that I can run from QnA that will show the current relay? And if so, can I create an action that checks the relay, if it’s the external DMZ (and textfile does not exist) create textfile?
You can do the text file thing, but using a client setting will be easier and will be cross platform. You can use Ben’s custom action and property above to get it done.
It looks like the only thing you’re having difficulty with is how to target the action. That’s actually easy, the key is to select the second radio button on the targeting tab of the take action dialog, ‘All computers with the property values selected in the tree below’. Then drill down in the tree to All Computers --> By Retrieved Property --> By Relay --> .
If you take the settings action as a policy, any machine that ever connects to your DMZ relay will be targeted by the action, and after the action runs the computer will report ‘Yes’ for your new ‘Used DMZ Relay’ property.
Thanks. Does this create a new setting called “Used DMZ Relay” on the fly?
Still being fairly new to BigFix, I like to know what the action is doing before I deploy to the enterprise.
Yes, you’ll get a new setting. On Windows, that’s effectively equivalent to setting a registry key. On other OSes the implementation is slightly different, but very similar in impact.
mikelocklar
This action would be ongoing if I deployed it without an end date, correct?
Yes, although if you choose the ‘Policy’ option from the presets menu you’ll find that in addition to un-checking the ‘Ends on’ box, it also sets automatic reapply behavior. That’s a good idea just incase there is a failure or the setting gets manually removed somehow.
If we create actions like these, and in the future decide that we don’t need to track the information anymore, what happens? Does this new setting stay in BigFix forever? My concern is mgmt wanting us to track more properties like this “on the fly” and ultimately impacting performance.
There is a ‘settings delete’ action you can use to get rid of the settings when you’re done… You can also delete the property to get clients to stop reporting the value.
In general, property bloat won’t affect performance too much as long as the properties meet a few criteria, namely, they don’t change frequently and they don’t have a lot of unique results. So a property like the one above that returns either nothing or ‘Yes’ and will only change once will have basically no impact on the system. On the other hand, a property that lists every website visited and the time it was visited will be very expensive because each result will be unique and I’d expect a high volume of results.
Those are the primary performance concerns on the console/server/database side. On the client side you worry mostly about properties that have long evaluation times. For example WMI queries tend to be much slower than our native inspectors. It’s also not hard to write relevance expressions that have O(n^2) behavior or worse, so you need to be careful about how you write the relevance and the potential size of the data set you’re evaluating.
Also, if you have a quality server and consoles, for the most part you shouldn’t have to worry about it to much unless you’re in the 20,000+ computer range.
Mike - Thanks for inquiring about this and thanks to Ben and Jesse for the assistance. I hadn’t really thought about doing something like this - but I like it and have done the same here. It is a great idea to know which systems have ever hit the DMZ. Because there is this sense that only “certain” laptops go off the network. We might be suprised to find out that laptops that should stay local are in fact doing some external roaming - and perhaps some workstations that grow feet
I’m not certain that this action is working as intended, and it’s possible that I’ve deployed it incorrectly. I see a lot of computers that are actively using this relay, currently online, and are reporting a value of for the property. I’m wondering if I targeted the deployment correctly.
Computers that were already associated with the relay at the time of the deployment are showing a value of “yes” as they come online. Computers that were not associated at the time of deployment are showing a value of . (Granted, we’re talking about a lot of computers and I’m trying to figure out what’s going on based on manually looking at the information in BF.)
I thought that by targeting “by relay” that any client that touched the relay would become applicable.
I think I deployed this action with the relay targeted, but using “specific computers selected in the list below” instead of “all computers with the property values selected in the tree below”. Could this be the case?
