Issue Deploying WinCollect 10.1.13-12 via Software Distribution

Content Authoring
1

Hello everyone,

I’m trying to deploy WinCollect 10.1.13-12 using Software Distribution, but I’ve encountered an issue when passing parameters. Below is the core cmd command that works outside of BigFix:

msiexec.exe /qn /i wincollect-10.1.13-12.x64.msi WC_SCRIPT=\\ournetwork.com\NETLOGON\redacted\redacted\wincollect\update_StandardEventLogs_Sysmon1.xml ADMIN_GROUP="false"

I created a software distribution package using the wizard. When prompted for parameters, I entered:

WC_SCRIPT=\\ournetwork.com\NETLOGON\redacted\redacted\wincollect\update_StandardEventLogs_Sysmon1.xml ADMIN_GROUP="false"

After deploying the action for testing, it failed. Running the same action via the Fixlet Debugger returned the following error:

STATUS: Running action...
Command succeeded (Prefetch download manager collected file) prefetch e35641d68aaae5df7dc9202c8210bbe88dfbac7e sha1:e35641d68aaae5df7dc9202c8210bbe88dfbac7e size:7684130 http://bigfixserver.company.com:52311/Uploads/e35641d68aaae5df7dc9202c8210bbe88dfbac7e/wincollect-10.1.13-12.x64.msi.tmp sha256:710e0b7384f22ea7c62216d288ff6f675c034b4a6494182ac1662de2a92c7301
Command succeeded extract e35641d68aaae5df7dc9202c8210bbe88dfbac7e
Command failed (Relevance substitution failed) wait "{pathname of system folder & "\msiexec.exe"}" /qn /i "{(pathname of client folder of current site) & "\__Download\wincollect-10.1.13-12.x64.msi"}" WC_SCRIPT=\\ournetwork.com\NETLOGON\redacted\redacted\wincollect\update_StandardEventLogs_Sysmon1.xml ADMIN_GROUP="false"
Command failed (Relevance clauses must be surrounded by { and } guards.) wait "{pathname of system folder & "\msiexec.exe"}" /qn /i "{(pathname of client folder of current site) & "\__Download\wincollect-10.1.13-12.x64.msi"}" WC_SCRIPT=\\ournetwork.com\NETLOGON\redacted\redacted\wincollect\update_StandardEventLogs_Sysmon1.xml ADMIN_GROUP="false"

--- Result ---
Evaluation Failure.

Key Observations:

  1. The error indicates a Relevance substitution failure and mentions:

    • Relevance clauses must be surrounded by { and } guards.

  2. The parameters, when passed manually in cmd, work correctly, so the issue seems specific to how the parameters are being interpreted in the action script.

Steps Already Taken:

  • Verified the MSI path and syntax.
  • Checked the prefetch and extraction steps, which complete successfully.

Questions:

  1. Does the action script require additional formatting for the parameters (e.g., escaping backslashes or quotes)?
  2. Is there a better way to handle these parameters within BigFix?
  3. Are there known issues with passing parameters in a wait command for msiexec.exe?

Any advice or suggestions would be greatly appreciated. Thanks in advance!

2

I would remove the quotes before and after the brackets.

I may not be correct, but I believe you have the correct number of brackets and the quotes are throwing that off.

wait {pathname of system folder & "\msiexec.exe"} /qn /i {(pathname of client folder of current site) & "\__Download\wincollect-10.1.13-12.x64.msi"} WC_SCRIPT=\\ournetwork.com\NETLOGON\redacted\redacted\wincollect\update_StandardEventLogs_Sysmon1.xml ADMIN_GROUP="false"
3

This error from the Debugger can be misleading. It basically can happen for any relevance evaluation error (in the Debugger).

I have my suspicions on the cause, but first, the general method I’d use to troubleshoot. That line has two relevance substitutions in it - I would copy those into two separate ‘parameter’ statements before your ‘wait’ command, so we can see with of the two fails to evaluate.

prefetch e35641d68aaae5df7dc9202c8210bbe88dfbac7e sha1:e35641d68aaae5df7dc9202c8210bbe88dfbac7e size:7684130 http://bigfixserver.company.com:52311/Uploads/e35641d68aaae5df7dc9202c8210bbe88dfbac7e/wincollect-10.1.13-12.x64.msi.tmp sha256:710e0b7384f22ea7c62216d288ff6f675c034b4a6494182ac1662de2a92c7301

extract e35641d68aaae5df7dc9202c8210bbe88dfbac7e

parameter "test1"="{pathname of system folder & "\msiexec.exe"}"

parameter "test2"="{(pathname of client folder of current site) & "\__Download\wincollect-10.1.13-12.x64.msi"}"

wait "{pathname of system folder & "\msiexec.exe"}" /qn /i "{(pathname of client folder of current site) & "\__Download\wincollect-10.1.13-12.x64.msi"}" WC_SCRIPT=\\ournetwork.com\NETLOGON\redacted\redacted\wincollect\update_StandardEventLogs_Sysmon1.xml ADMIN_GROUP="false"

What I suspect is that in the Debugger, that second one might fail because there is no ‘current site’. Since this is in the Debugger, and ‘current site’ is taken from the source fixlet/task, there is no ‘current site’ and that evaluation fails. There’s not a great way in the Debugger to get a reference to the __FixletDebugger__Download folder, but you could use the Relevance pipe operator ( | ) to handle the error; if the expression to the left of the pipe gives an error, the value to the right is used instead. So here

parameter "downloadfolder"="{pathname of client folder of current site|pathname of folder "__FixletDebugger" of data folder of client}\__Download"

this parameter will be the sitename__Download folder if this is run in a Task on the client, or the “C:\Program Files (x86)\BigFix Enterprise\BES Client__BESData__FixletDebugger__Download” folder if that ‘current site’ evaluation gave an error - and this should be where the Fixlet Debugger is downloading files in the test action.

I think the problem in the actual Task is probably different though. In the Task, the ‘client folder of current site’ should be able to evaluate correctly, so I think there’s a different issue. I haven’t tried this, but I suspect that the ‘extract’ command is not renaming the download back to the original filename that you expect. It might just be ‘__Download\e35641d68aaae5df7dc9202c8210bbe88dfbac7e’ after that ‘extract’ command. I’m not super confident in that, I don’t think I’ve used the compress/extract commands for single files very much. But just by way of debugging it might be worth using a parameter to list the files in the download folder, after extracting, so you that parameter appears in the log and you can see if it looks right. Something like

prefetch e35641d68aaae5df7dc9202c8210bbe88dfbac7e sha1:e35641d68aaae5df7dc9202c8210bbe88dfbac7e size:7684130 http://bigfixserver.company.com:52311/Uploads/e35641d68aaae5df7dc9202c8210bbe88dfbac7e/wincollect-10.1.13-12.x64.msi.tmp sha256:710e0b7384f22ea7c62216d288ff6f675c034b4a6494182ac1662de2a92c7301

extract e35641d68aaae5df7dc9202c8210bbe88dfbac7e

parameter "downloadfolder"="{pathname of client folder of current site|pathname of folder "__FixletDebugger" of data folder of client}\__Download"

parameter "filelist"="{concatenation "; " of names of files of folders (parameter "downloadfolder")}"

wait "{pathname of system folder & "\msiexec.exe"}" /qn /i "{parameter "downloadfolder"}\__Download\wincollect-10.1.13-12.x64.msi" WC_SCRIPT=\\ournetwork.com\NETLOGON\redacted\redacted\wincollect\update_StandardEventLogs_Sysmon1.xml ADMIN_GROUP="false"

The other thing that seems likely, is that when running under Action context, the client cannot reach your network share at \\ournetwork.com\NETLOGON\redacted\redacted\wincollect\update_StandardEventLogs_Sysmon1.xml . Since this is running as LocalSystem, not a Domain User account, usually we can’t reach any UNC paths. You should probably include that .xml file as part of the action downloads instead of reaching it over a UNC path.