Scripts work with debugger but not with the BigFix client.

1

I’ve been at this for too long.
I have scripts that I’m trying to get BF to run but they fail with every attempt I’ve made.
I have a Powershell script that I can get the BF FixLet debugger action to successfully run but when I try to deploy the same with BF proper it doesn’t work.

I’m looking for guidance.
What I know:
The script works when I run it locally by hand on the client system.
When BigFix runs the script, I don’t get what I expect. IE: nothing.

What I’ve tried:
Script type = powershell
Script type = BF action script (BFAS)

BFAS:
I’ve tried:

wait C:\Windows\SysWOW64\WindowsPowerShell\v1.0\powershell.exe -WindowStyle Hidden -NonInteractive -ExecutionPolicy Bypass Script.ps1
dos C:\Windows\SysWOW64\WindowsPowerShell\v1.0\powershell.exe -WindowStyle Hidden -NonInteractive -ExecutionPolicy Bypass Script.ps1

and the same above with path to the PS.exe quoted “”

the PS script:

Stop-Service spooler
Remove-Item -Path $env:windir\system32\spool\PRINTERS\*.*
Start-Service Spooler -ErrorAction Ignore
Remove-Printer printerHostName -ErrorAction SilentlyContinue
Remove-PrinterPort -Name printerHostName -ErrorAction SilentlyContinue
Add-PrinterPort -Name printerHostName -PrinterHostAddress 'printerHostName.domain.local'
Get-ChildItem "\\uncPath\oemsetup.inf" -Recurse -Filter '*inf' | ForEach-Object {PNPUtil.exe /add-driver $_.FullName}
add-printerdriver -name "PCL6 Driver for Universal Print"
Add-Printer -Name "readableName" -PortName "printerHostName" -drivername "PCL6 Driver for Universal Print"
Set-PrintConfiguration -PrinterName "readableName" -Color $false -ErrorAction SilentlyContinue
(New-Object -ComObject WScript.Network).SetDefaultPrinter("readableName")

i’ve also tried:
BFAS:

C:\Windows\SysWOW64\WindowsPowerShell\v1.0\powershell.exe -encodedcommand encodedString

and variance of the above with execution policy bypass

I’m looking for any guidance.
I thought that using the encoded command would completely account for any quotes, brackets, and escaping as that gets overly complicated for me. The result, an installed printer doesn’t exist.
But the strangest thing is all of what I’ve tried works when I do it by hand, just not from BF.

I’ve even tried:

waithidden "C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe" -ExecutionPolicy Bypass -command "get-help | out-file C:\temp\test_32_powershell.txt"
waithidden "C:\Windows\SysWOW64\WindowsPowerShell\v1.0\powershell.exe" -ExecutionPolicy Bypass -command "get-help | out-file C:\temp\test_64_powershell.txt"

those work, I get the file and it has help text.
So I don’t get why the other powershell commands don’t work.

Thanks.

2

I would bet you have to disable WOW redirection.

If you want to invoke powershell 64bit without disabling wow redirection, you would have to do:

C:\Windows\Sysnative\WindowsPowerShell\v1.0\powershell.exe

Unless you disable redirection, you are actually getting the 32bit powershell in all of these even when you are using the 64bit path.

Add this near the top of your actionscript:

action uses wow64 redirection {not x64 of operating system}

You will find that in both of these cases, it is actually the 32bit powershell that gets invoked, not the 64bit powershell due to the redirection, unless you disable it.

Consider the following actionscript:

wait C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -command "echo System32 $Env:PROCESSOR_ARCHITECTURE > C:\test_log.txt"

wait C:\Windows\SysWOW64\WindowsPowerShell\v1.0\powershell.exe -command "echo SysWOW64 $Env:PROCESSOR_ARCHITECTURE >> C:\test_log.txt"

wait C:\Windows\Sysnative\WindowsPowerShell\v1.0\powershell.exe -command "echo Sysnative $Env:PROCESSOR_ARCHITECTURE >> C:\test_log.txt"

action uses wow64 redirection {not x64 of operating system}
wait C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -command "echo System32-RedirectionDisabled $Env:PROCESSOR_ARCHITECTURE >> C:\test_log.txt"

Then the results:

System32
x86
SysWOW64
x86
Sysnative
AMD64
System32-RedirectionDisabled
AMD64

This is NOT really a quirk of BigFix, it is really a quirk of WOW redirection on windows.

It is counterintuitive and annoying, but the System32 location is actually the 64bit windows path. SysWOW64 is where 32bit applications get silently redirected to and actually contains the 32bit windows stuff.

A 32bit application CANNOT invoke the 64bit System32 folder directly without either disabling redirection, or by using the fake virtual path Sysnative.

1 Like
3

Thank you very much.

action uses wow64 redirection {not x64 of operating system}
waithidden “C:\Windows\Sysnative\WindowsPowerShell\v1.0\powershell.exe” -ExecutionPolicy Bypass -
encodedcommand UwB…

Worked!!

Is there a way to enforce the bitness of the PowerShell action script type in Bigfix?
So I can run BigFix action script type as 64 bit PowerShell?

I’d like to move away from running encoded commands to having a more readable/editable PowerShell “action script” in bigfix.

Thank you so very much.

EDIT: I realized after post, that I was redundant in supplying both:
action uses wow64 redirection {not x64 of operating system}
and
waithidden “C:\Windows\Sysnative\WindowsPowerShell\v1.0\powershell.exe”

thanks again.

4

“By default and for ensuring the backward compatibility with 32-bit systems, the BigFix Agent operates in a 32-bit context for running actions. This means that the paths to your files are automatically translated by Windows into the 32-bit equivalent paths. This is the so-called wow64 redirection.”

https://developer.bigfix.com/action-script/reference/execution/action-uses-wow64-redirection.html

If they will add “PowerShell X64” action type it will be great!

Meanwhile, you can create a ps1 file with createfile and run it with the -File option

5

That is a good topic to start actually - compatible to what exactly and more importantly is that justified? On Server side the last x32 OS was with Windows 2008 (2008 R2, 2012, 2012 R2, 2016, 2019 and 2022 were all x64 only), which has been 4-5 years passed its end of support; on Desktop side Win 7, 8 & 10 (latter only up to build version 2004 only), of which only Win10 is technically still supported… So question is how many Win10 x86 machines would organization have in comparison to how many x64 Windows OS they would have? Does the number justify it?

IMHO, there needs to be switch to x64 agent with default x64 context and ability to switch to x32 context optionally.

3 Likes
6

I’ve found the following idea - https://bigfix-ideas.hcltechsw.com/ideas/BFP-I-264

2 Likes
7

Good call to open one for it. Voted now.

8

I’m wondering if the development path exists that instead of making the agents fully 64bit, could at least the action methods be able to default to the architecture of the OS, maybe via a client setting to toggle a new feature on or off depending on customer needs. I can appreciate that any change needs great care in order to not break existing content, be it HCL provided or custom content.

Just to illustrate my thinking

_BESClientActionUsesNaitveBitness = False (default) – This would keep any action methods to how they function today. No setting would also default to this mode

_BESClientActionUsesNaitveBitness = True – This would switch any action methods to the bitness of the core OS

I’m sure there are additional scenarios that would also need to be taken into account but maybe this type of route allow for the transition to 64 bit as the default with support for 32 bit OS while allowing customers to prepare/update existing content accordingly.

3 Likes
9

I ran into the bitness issue when I realized that PNPUtil.exe is x64 now.
I’m no expert but a 64-bit shell should be backward compatible with 32-bit content and as such there should be very minimal issues with using it by default. Given that the vast majority of content is now 64-bit compatible I don’t really see a reason to specify 32-bit except in the rare use case where specific content explicitly requires it and if you have one of those use cases you’re likely aware of it.

I was pointed here by my internal BF team because they couldn’t answer my questions as to why my scripts were failing(from BigFix), so I’m only at best a “2nd hand user”. Knowing about the nature of BF using 32-bit should least be made evident in the interface, although I didn’t find out without research, I’m sure I’m not the only person this quirk has bitten. Having the ability to set bitness would be a sweet addition to the interface, although I can see the rationale behind not allowing such customizability.

Thank you all again for all of your wonderful feedback.