You absolutely cannot make any changes to a system using Relevance ever, and if you can it is a serious bug. Relevance is strictly read only on purpose. You must use actions to make changes, otherwise you could use relevance to get around the auditing mechanisms of BigFix/IEM.
That error message has nothing to do with the database you are trying to write to, it has to do with the fact that Relevance always opens the DB in read only mode.
You need to use some other API to write into the DB in actionscript, but use relevance to determine if the action should be run and for relevance substitution.
It is a little odd to use relevance to do reading / detection, but then use VBS or PowerShell or something else to do your writing, but I do find that relevance substitution allows me to write code that is very clean and short.
You can also download any portable command line utility to use in actionscript in a dynamic way so you don’t even need to have something pre-installed on the client.
Ok, let me explain what I’m trying to accomplish: since in relevance you cannot use the “relevant fixlet” inspector if a fixlet is relevant or not ('cause of the chicken/egg paradox), I was trying to dump the list of relevant fixlets in a db without having an endless open action to do so, using a separate sqlite client.
Having a chance to execute a free sql statement would have given me the possibility to first fill a table with a list of relevant fixlet in the db and then read the db again and evaluate the result.
What are you using this relevant fixlet info for? There might be a better option.
It sounds like you just need to run an action to populate a SQLite DB with this info, then read it back using an Analysis property using the SQLite relevance inspectors.
If the data you want is already in a SQLite db, then you just need to use the relevance inspectors to read it.
I have to take an action on workstations that evaluate TRUE a match (an intersection) between all relevant fixlets in Patch for Windows site and a list of fixlet ids.
This might be better done externally using the REST API to query using Session Relevance which computers should have this happen to them, and use the REST API to deploy.
What is the relevance you are using to determine which fixlets the client is relevant to?
Right… so the rest api lets you deal with that automatically. You should be able to deploy what you need to all of the machines that it should go to with a single action.
I feel like I am missing some of what you are trying to accomplish and why you are using the relevance or non relevance of fixlets on a computer to do it.
Also, it would help if you shared as much documentation that you have looked at that was relevant and helpful and why, but also whatever relevance approaches you have tried client side to get what you want, or at least explain it in much more detail so that I / Others can help with the best approach using either method to get what you want.
I’m looking to create session relevance to return all fixlets in the Patches for Windows site that should be deployed to clients and then automatically put that into a baseline and deploy it. I then plan to do something similar for 3rd party software patching.
In my environment we used the REST API with something like this…
fixlets whose (source severity of it as lowercase contains “$$Severity$$” and name of it does not contain “(Superseded)” and size of (applicable computer set of it) > 5 and category of it contains “Security Update” and script of default action of it does not contain “MANUAL_BES_CACHING_REQUIRED”) of bes sites whose (name of it contains “$$CustomSite$$”)"
The program would swap out $$Severity$$ and $$CustomSite$$ with the severity and custom site we wanted a baseline for. Because it was generic this allowed us to use it with the external sites as well as our internal sites.
This would then generate different baselines with each severity level for each custom site.
The way I ended up doing it took a lot of code, I couldn’t figure out another way to do it so I had to pull all the relevance and actionscript out of every fixlet to generate the baselines but it works!
Thanks, thats helpful and definitely what I am looking to do in general.
Like I said, I’m taking a crack at it, so I’ll see if I come up with anything better as far as building the baseline itself. I think baselines require a copy of the actionscript/relevance of the fixlet so that they don’t change over time. This isn’t true of normal actions because you can use “SourcedFixletAction” which just includes a pointer to the origin fixlet instead of a copy of all of the code.
I’m planning to include fixlets in the Patches for Windows site that are newer than X days, plus those with at least X relevant computers. The idea is that if it is a new patch, you could have sleeping machines that haven’t reported in their relevance to those fixlets yet.
Hi
The solution jgstew is working on uses collected applicability data to evaluate which fixlets should be casted as actions to a specific number of machines.
Glbproject’s approach on the other hand, is to have the clients do the relevance evaluation locally: This would make things easier, avoiding a mailboxed action that targets thousands of machines individually, which could get problematic in very large environments, but poses the problem that the “relevant fixlet” inspector, by design, is unrealiable in such scenarios.
…so the question here seems to be if there’s a way to avoid such inspector shortcomings.
Using the sqlite inspector seemed a good idea, but we found it is not… can we think of a workaround?
My approach is to make baseline(s) that target all machines that should be patched, containing all patches that are relevant or very new. This means that machines with 0 relevant patches would still get targeted by the baseline, but they would not run it.
Well, in our environment (we have this translates in several thousands machines spending a huge share of their time evaluating patches (IBM’s repacks of Microsoft patches often have relevances in the order of 40kb, several hundred lines of code EACH) and I find this approach very inefficient.
We’re developing a strategy where the baselines (better: multiple action groups) run in a dedicated site, and the machines subscribe say, once a month, to that site, run the relevant actions, and then unsubscribe. This way all the machines evaluate the baseline, but only once or twice a month, and not constantly.
So are you seeing long evaluation loops on your clients? Are you resistant to increasing the workidle setting a bit?
So the clients won’t subscribe to patches for windows at all, just this separate site periodically?
I wonder if there is a good way to only have a baseline action evaluated periodically by just putting something in the beginning relevance that would cause it to evaluate to false, halting further evaluation, but then evaluate to true periodically which would cause evaluation to continue without the need to pop in and out of subscribing to a site, which seems messy. You could definitely do this with an action that tags them if it has been a while and another action that removes the tag, but this seems similar to what you are doing.
You can have the client only do eval loops on a periodic bases using the following setting:
concatenations "%0a" of ("<BaselineComponent Name=%22" & item 0 of it & "%22 IncludeInRelevance=%22" & item 1 of it & "%22 SourceSiteURL=%22" & item 2 of it & "%22 SourceID=%22" & item 3 of it & "%22 ActionName=%22" & item 4 of it & "%22><ActionScript MIMEType=%22" & item 5 of it & "%22>" & item 6 of it & "</ActionScript><SuccessCriteria Option=%22" & item 7 of it & "%22>" & item 8 of it & "</SuccessCriteria><Relevance>" & item 9 of it & "</Relevance></BaselineComponent>") of (name of it, (it as string as lowercase) of (not success on run to completion of default action of it), url of site of it, (it as string) of id of it, content id of default action of it, script type of default action of it, ("<![CDATA[" & it & "]]>") of script of default action of it, (if (success on custom relevance of it) then "CustomRelevance" else if (success on original relevance of it) then "OriginalRelevance" else if (success on run to completion of it) then "RunToCompletion" else "") of default action of it, (if (not success on custom relevance of it) then "" else ("<![CDATA[" & it & "]]>") of (custom success relevance of it)) of default action of it, ("<![CDATA[" & it & "]]>") of relevance of it) of fixlets whose(name of it contains "Windows" AND name of it does not contain "(Superseded)" AND name of it as lowercase contains "endpoint manager" AND name of it as lowercase contains "client" AND globally visible flag of it) of bes sites whose("BES Support" = name of it)
Escaped Session Relevance: (works with curl)
"concatenations %22%22 of (%22<BaselineComponent Name=%2522%22 & ( concatenation %22and%22 of substrings separated by %22%26%22 of item 0 of it) & %22%2522 IncludeInRelevance=%2522%22 & item 1 of it & %22%2522 SourceSiteURL=%2522%22 & item 2 of it & %22%2522 SourceID=%2522%22 & item 3 of it & %22%2522 ActionName=%2522%22 & item 4 of it & %22%2522><ActionScript MIMEType=%2522%22 & item 5 of it & %22%2522>%22 & item 6 of it & %22</ActionScript><SuccessCriteria Option=%2522%22 & item 7 of it & %22%2522>%22 & item 8 of it & %22</SuccessCriteria><Relevance>%22 & item 9 of it & %22</Relevance></BaselineComponent>%22) of (name of it, (it as string as lowercase) of (not success on run to completion of default action of it), url of site of it, (it as string) of id of it, content id of default action of it, script type of default action of it, (%22<