I have a co-worker that is trying to use relevance to get information about a UPD (user profile disk) however I don’t think the relevance language is capable of getting that info. However, we know how to do this in PowerShell, so how can I integrate PowerShell into relevance in order to get the information we need.
like assigning a variable from the results of a powershell script
Bottom line is you can’t. Bigfix properties can only be created using the relevance language as that is a 100% guaranteed read-only mechanism (just think how many security backdoors and issues could be created if a inspection could run code that can change something using scripting languages).
What you would need to do it create a task that runs your PowerShell script and the script outputs the results to either a file or registry key and then create a Bigfix property to parse the file or registry key. The downside of this is its a somewhat detached process so the data created by the script can become stale, but if you can’t find a way to inspect the endpoint via relevance, its the only approach.
I hear what you are saying, and yet, I have seen relevance use WMI to gather info, which pre-dates PowerShell and yet it has the ability to manipulate things as well.
However, WMI is likely getting phased out.
I realize the power you wield as a BigFix operator/Admin, if you plan to blow up your environment limiting relevance isn’t going to prevent that. Behold, you have a tool that can in a matter of seconds manipulate that endpoint with a task, so limiting relevance has no bearing on the conversation at all.
Most languages have commands/functions that “get” info and others that manipulate info
What is important about this conversation is protecting the system from unwanted guests being able to manipulate it without authorization.
and we have had BigFix pen tested by a security company that does that for a living, and the good news is that it passed with flying colors.
I have been making the comment that Powershell relevance inspectors would be amazing to have for years! Obviously, you won’t be able to make changes but PS can be use quite extensively to retrieve data nowadays! There are plenty of use-cases where PS is required because you just can’t retrieve the data via relevance, so you are stuck writing an audit script, then scheduling it to run on machines and store the data somewhere only to read back via relevance - cumbersome and risky all-in-all! One example, that comes to mind immediately is installed cert data (name, valid from, valid to, CA Authority, etc) - with powershell is just a matter of running a dir (get-item) and the path, where via relevance is just not there (you can potentially read back the thumbnails from registries but not the actual cert details)…
I completely agree with you, especially now that PowerShell 7.x is here and can be installed on more than just Windows.
Honestly I can see why Development of it for BFX relevance would not be a worthy investment for a single platform, even though it is likely the most widely used, now however there is just no reason not to.
@Xanuri If you can post your working Powershell command and/or explain what UPD information your trying to obtain, we may be able to assist in getting the information via normal relevance techniques.
The “IDEA” for Powershell inspectors is here:
https://bigfix-ideas.hcltechsw.com/ideas/BFP-I-76
Vote and add commentary if you want to support this idea.
I just submitted an idea for “Scripted Properties” which i feel is a better way to go about this than to change traditional Retrieved Properties to be anything other than read-only. Please check it out and give it a vote if you agree. 
Add a new “Scripted Properties” functionality that combines Properties and Actions
https://bigfix-ideas.hcltechsw.com/ideas/BFP-I-252
I like the concept on this, as it’s similar in concept to Automatic Groups (which technically run an action on the endpoint, but the details of this are abstracted from the operator’s view)
I do as well (voted), the only thing that will be very tricky if you need such property to be multi-platform (Windows + Unix + Linux + etc). It will be practically impossible to come up with a script that works across the board.
I would personally think that collecting stdout, stderror, etc from action can be a good alternative. You create yourself an action that you want to collect data with and all the necessary logic that would allow you to make it cross-platform, and collect the results of its execution, so that data is available. You can then easily retrieve it both via Web Reports or even RestAPI for reporting purposes based on the action you’ve set-up. It would also give you control over the reevaluation times (maybe you want to make sure is outside of business hours and such), which blind frequency doesn’t give you any flexibility with.
Have the powershell scrip run locally with a scheduled job and export the results into the registry or a file and then use BigFix to read that as relevance?
What scripting methods to support would certainly be a problem, and maybe more one of personal choice. I’m from a Windows background so PowerShell might be my preference but for Linux, you can’t expect PowerShell to be the favoured option and even adopting a cross platform language such as Python, that then means you’re having to push something to endpoints that maybe exposes more vulnerabilities that the company or support teams care to add. I certainly wouldn’t want to deploy Python to all my estate
If there was a “language” inspector as and if it was supported, that could be an approach eg (just hypothetical mock-up)
Q: results from "ps -ef | grep -i bes" of bash
Q: results from "(Get-content (${env:ProgramFiles(x86)}+'\BigFix Enterprise\BES Client\__BESData\__Global\Logs\' + (get-date ((get-date).AddDays(-1)) -uformat '%Y%m%d.log')) | select-string -pattern 'DownloadPing').length" of powershell
Would this still expose a backdoor that could be exploited though? Could a non-MO or L1 operator who cannot create fixlets then be able to create a property in their site that allows them to change something when their console permissions do not allow?
@straffin’s idea is excellent. It is well considered, encompasses a variety of existing BigFix features, and addresses a number of existing usecases. Well done!
(And I’ve upvoted it!)
very possible if PowerShell 7.1.x or 7.2.x is used vs. 5.1