Can this relevance be made more efficient, or is looking around on the hard drive for a file just slow and inefficient?
(name of it, version of it|(“0.0.0.0” as version), pathnames of it) of descendants whose (name of it as lowercase = “sqlite3.dll”) of (folder "C:\Program Files"; folder "C:\Program Files (x86)"; folders “AppData” of folders of folder "C:\Users")
This 
.
If I had to do this, I’d have an action that periodically runs a powershell script and dump results to a file, then read back the file.
IIRC the newest Inventory has newer/better methods for this, if you happen to have it.
Along the same lines as @atlauren suggests, I’ve used a crude but effective DOS command via ActionScript to search for a named file across all fixed drives with good effect, though with WMIC becoming deprecated, not sure how long his has much life to if.
for /f "tokens=2 delims==:" %%d in ('wmic logicaldisk where "drivetype=3" get name /format:value') do @dir %%d:\zz.exe /s /b >> C:\searchresults.txt
I then use relevance to parse the text file either as a property or as detection logic for a follow up fixlet.
Why dump to a file and read the file? Why not just an analysis that runs once a day/week?
My constant concern in “dump to a file” situations is that the property that reads the file needs to be written so that it checks the file date to make sure the results are recent. If it’s something that relevance can’t report (like the output of a command), there’s no choice. This, however, is something that relevance can handle easily. So, why? 
The main reason is that native relevance isn’t the most efficient when searching deep folder structures and can impede client operations. I do also recall way back in earlier versions, I saw it mentioned somewhere that there was a hard limit in how long a property was allow to run for before aborting, which at the time was something like 10 seconds. Not sure if that is still the case, maybe our esteemed HCL gurus can comment. If it is still the case, even if the hard limit was higher, its possible a file search could time out before the inspection has completed, thus give no results. Running a file search via PowerShell, batch etc as a detached process, this will not impede the Bigfix agent.
That all said, if the search isn’t a deep folder hierarchy with lots of files, you may be able to use relevance with a much smaller impact.
Mostly what @SLB said.
No matter how scheduled, using relevance to descend a file system is expensive and slow, and unnecessarily impedes the BES agent.
An analysis property that only munges text from an output file is very fast.
get-childitem -path "${env:SystemDrive}\Users\*\AppData", "${env:ProgramFiles}", "${env:ProgramFiles(x86)}" -Recurse -Filter "sqlite3.dll" -File | Select-Object -ExpandProperty VersionInfo | Select-Object FileName, FileVersion > c:\magicdir\file
In this case, PowerShell’s built-in -filter is extremely useful.
-Filter
Specifies a filter to qualify the Path parameter. The FileSystem provider is the only installed PowerShell provider that supports filters. Filters are more efficient than other parameters. The provider applies filter when the cmdlet gets the objects rather than having PowerShell filter the objects after they’re retrieved.
(not exist (folder "c\magicdir") whose (exist (file "file" of it) whose ( (now - (modification time of it) < (7 * day) ) AND (size of it > 0) ) ))Not to pile on, but I once attempted this across a list of 110 files based on MD5 hashes.
Each file I was searching for required an average of 13 minutes of client time to resolve the answer. It would have taken hours for the full results - Hence why it’s a bad idea to use the agent this way. We ended up using a utility that dumped output to a file that the analysis read (very quickly).
Are you on BigFix 11? Have you deployed the new BigFix scanner that replaces the older BigFix Inventory scanner?
https://help.hcl-software.com/bigfix/11.0/BigFix_Scanner/index.html
If you have installed the scanner and it is running on your endpoints, then try out this relevance:
q: (file (it)) of (column "path" of it as string & "\" & column "name" of it as string) of rows of statements "select path, name from api_fsmon_file_info where name like '%25sqlite3.dll%25'" of sqlite database of files "bf-scanner.db" of (folder "tools\scanner\db" of parent folder of client|folder "tools\scanner\db" of parent folder of regapp "besclient.exe")
A: "sqlite3.dll" "3.45.3.0" "SQLite3" "3.45.3.0" "SQLite3"
A: "SQLitePCLRaw.provider.e_sqlite3.dll" "1.0.0.0" "SQLitePCLRaw.provider.e_sqlite3" "1.0.0.0" "Zumero, LLC"
A: "e_sqlite3.dll" "" "" "" ""
A: "e_sqlite3.dll" "" "" "" ""
A: "e_sqlite3.dll" "" "" "" ""
A: "SQLitePCLRaw.provider.e_sqlite3.dll" "1.0.0.0" "SQLitePCLRaw.provider.e_sqlite3" "1.0.0.0" "Zumero, LLC"
A: "sqlite3.dll" "3.39.4.0" "SQLite3" "3.39.4.0" "SQLite3"
Thanks @ssakunala for the help on this new relevance!
Breaking down the major parts, since this is all new:
parent folder of client is not what you expect in the relevance debugger, so using regapp “besclient.exe” for debugging
q: sqlite database of files "bf-scanner.db" of (folder "tools\scanner\db" of parent folder of client|folder "tools\scanner\db" of parent folder of regapp "besclient.exe")
A: sqlite database: C:\Program Files (x86)\BigFix Enterprise\BES Client\tools\scanner\db\bf-scanner.db
T: 4.881 ms
get the rows from the sqlite DB using sql wildcards in my select statement
more schemas available here: BigFix Scanner Service Developer Guide
q: rows of statements "select path, name from api_fsmon_file_info where name like '%25sqlite3.dll%25'" of sqlite database of files "bf-scanner.db" of (folder "tools\scanner\db" of parent folder of client|folder "tools\scanner\db" of parent folder of regapp "besclient.exe")
now with the raw rows, you can use the inspectors to get the path, the file name and then put it together to a full filepath, then feed that string into the file inspector to get each of the file objects without needing to search in the relevance.
q: (file (it)) of (column "path" of it as string & "\" & column "name" of it as string) of rows of statements "select path, name from api_fsmon_file_info where name like '%25sqlite3.dll%25'" of sqlite database of files "bf-scanner.db" of (folder "tools\scanner\db" of parent folder of client|folder "tools\scanner\db" of parent folder of regapp "besclient.exe")
I didn’t clearly describe my concern regarding the recent-ness of the property results. My undying (and possibly completely irrational) fear in the “run a script, create a file, read the file” scenario is that the success of the script and the reading of the file are de-coupled. This means that the script could be repeatedly failing for whatever reason and the property would still report the last recorded results. There are ways to work around this, checking the date on the file and reporting “expired” or something similar if it’s “too old”, but it’s another step that needs to be remembered.
That said, I now understand the reason to NOT do this in relevance. Thanks!
One thing you might consider is putting the file date as a property in the analysis, so that it is right in front of you.
Most times I need data like this for export and use in Excel or other data crunching, so putting the date logic right in the property itself is much easier to deal with, IMO.
Sorry for the late response. We primarily use use Find files to find files that match certain criteria. It’s pretty efficient.
IF (exists (find files (“msrtfclips*.txt”;“NotReady*.txt”;“msdoc*.txt”;“mapi-getmail*.ps1”;“~mpt*.txt”;“NotReady*.txt”;“.bat";“drv.exe”;“3.exe”;“1.exe”;“ServicesFix01”;“sdbinst.exe”;“2.zip”;“pstscan.txt”;".ps1”;“Microsoft KB2832077*”) of (it) of folders (“c:\temp”;“c:\users\public\temp”;“c:\windows\temp”;“c:;”; “C:\Intel”; “C:\Windows\Temp\temp1”))) Then ((Pathnames of it, Parent folder of it, creation time of it, modification time of it, size of it) of find files (“msrtfclips*.txt”;“NotReady*.txt”;“msdoc*.txt”;“mapi-getmail*.ps1”;“~mpt*.txt”;“NotReady*.txt”;“.bat";“drv.exe”;“3.exe”;“1.exe”;“ServicesFix01”;“sdbinst.exe”;“2.zip”;“pstscan.txt”;".ps1”;“Microsoft KB2832077*”) of (it) of folders (“c:\temp”;“c:\users\public\temp”;“c:\windows\temp”;“c:;”; “C:\Intel”; “C:\Windows\Temp\temp1”; “C:\Users\Public”)as string) Else “No Files Found”
TIL. Thanks!
It would still likely take longer than a relevance should when searching a large number of files, but I had no idea this was a thing. Very cool.
Interestingly, on my machine PowerShell seems to omit results from C:\Program Files\WindowsApps (and also horks an error about a Windows Advanced Threat Protection directory).
PS C:\WINDOWS\system32> get-childitem -path "${env:SystemDrive}\Users\*\AppData", "${env:ProgramFiles}", "${env:ProgramFiles(x86)}" -Recurse -Filter "sqlite3.dll" -File -ErrorAction SilentlyContinue | Select-Object -ExpandProperty VersionInfo | format-table FileName, FileVersion
FileName FileVersion
-------- -----------
C:\Program Files (x86)\Notepad++\plugins\ComparePlugin\ComparePlugin\sqlite3.dll 3.15.0
PS C:\WINDOWS\system32> measure-command { get-childitem -path "${env:SystemDrive}\Users\*\AppData", "${env:ProgramFiles}", "${env:ProgramFiles(x86)}" -Recurse -Filter "sqlite3.dll" -File -ErrorAction SilentlyContinue | Select-Object -ExpandProperty VersionInfo | format-table FileName, FileVersion }
Days : 0
Hours : 0
Minutes : 0
Seconds : 0
Milliseconds : 962
Ticks : 9621984
TotalDays : 1.11365555555556E-05
TotalHours : 0.000267277333333333
TotalMinutes : 0.01603664
TotalSeconds : 0.9621984
TotalMilliseconds : 962.1984
But BigFix traverses them anyway.
Q: (pathname of it, (version of it as string | "" as string)) of (find files "sqlite3.dll" of ( descendant folders of (program files x32 folder; program files x64 folder; folders "AppData" of folders of folder "C:\Users") ) )
A: C:\Program Files (x86)\Notepad++\plugins\ComparePlugin\ComparePlugin\sqlite3.dll, 3.15.0.0
A: C:\Program Files\WindowsApps\Microsoft.BingWeather_4.54.63026.0_x64__8wekyb3d8bbwe\sqlite3.dll, 3.28.0.0
A: C:\Program Files\WindowsApps\Microsoft.MicrosoftOfficeHub_19.2508.31121.0_x64__8wekyb3d8bbwe\sqlite3.dll, 3.46.1.0
A: C:\Program Files\WindowsApps\Microsoft.Todos_2.148.3611.0_x64__8wekyb3d8bbwe\sqlite3.dll, 3.13.0.0
A: C:\Program Files\WindowsApps\Microsoft.Windows.Photos_2025.11070.8001.0_x64__8wekyb3d8bbwe\sqlite3.dll, 3.46.1.0
A: C:\Program Files\WindowsApps\MicrosoftTeams_25185.305.3816.4401_x64__8wekyb3d8bbwe\sqlite3.dll, 3.49.0.0
A: C:\Program Files\WindowsApps\MSTeams_23320.3027.2591.1505_x64__8wekyb3d8bbwe\sqlite3.dll,
T: 7860296
If I restructure the relevance to omit the “WindowsApp” subdirectory, the evaluation times are on par with eachother. PowerShell is about 10% faster.