We have a few analysis we like to use occasionally, that have no need to run on every systems, or any systems all the time for that matter.
For Example, we have an analysis that pulls all the event log entries for shutdown event. This kind of query is resource intensive and even if we set it to run once a day, it is not something we need running all the time.
So we created what we call “On Demand” Analysis.
We have a key in the registry for our company and keep numerous settings there.
We created a task that sets a key in that part of the registry. When the key is set, the analysis is relevant. If the key is missing or set to false, the analysis is not relevant.
This allows us to send the task, make it relevant, wait for it to populate, gather the information and then send another task to remove the reg key or delete it, making the analysis not relevant.
Great tip @D.Dean. Do you ever find reporting quirks as machines become relevant then not relevant for the analysis, e.g console shows the data of when the analysis property was relevant but Web reports shows it as as the computer that was relevant is no longer relevant to the analysis?
As a suggestion, have the relevance key off of the presence (or evalution) of a trigger file.
exists file "foo" of folder "CustomSite_bar" of data folder of client
Then use site file distribution to send that file (or updates there of) to all clients. A site file is just a file. It doesn’t have to be anything special.
You might even do something like building a datestamp into the filename, then have the relevance parse that date stamp so that the analysis is only relevant if that day is now as current date.
We have been at 11.0.3 for a couple months now. It has been a while since we were at 10.0.12 and that may have been before we were using the “On Demand” process.