Im attempting to build a script monitor that uses an old x86 com object, i thought i could specify the but depth of the powershell monitor by specifying the "Platform to run polling job on:" to x86. When i do this, i still received com errors due to the bit level, i performed the following to confirm that it is indeed running as x64..
$Test = $env:Processor_Architecture
Write-Host 'Statistic:' $Test
Is there any way to force the powershell script monitor to run under x86, or am i stuck here?
note, ive tried other ways of forcing the script itself to relaunch as x86, but they dont seem to work either.
if ($env:Processor_Architecture -ne "x86")
-noprofile -file $myinvocation.Mycommand.path -executionpolicy bypass
The changes you made under the "Advanced" section are likely not taking effect within templated editor when clicking "Test". That's just a theory. You may want to change the "Platform to run polling job on" to "x86" and then save the template and view the resulting output from the polling job.
I had to alter your script slight since "x86" and "AMD64" aren't numbers, but it does appear to be working properly in SAM 6.1.1. I would recommend upgrading as it appears this may have been an issue in SAM 6.0.1.
Would you mind doing me a favor and testing on a "Remote Host" as well?
in my testing, local execution can be done under x86, remote seems locked into x64.
Correct. The "Advanced" setting for running the Polling Job is related to the Orion Job Engine. E.G. 64bit Job Engine or x86 Job Engine. This setting does not control the bitness of PowerShell executed on remote hosts. To leverage 32bit PowerShell on the remote host you would need to account for this within your script, such as utilizing the Start-Job cmdlet with the -RunAs32 parameter.
SolarWinds solutions are rooted in our deep connection to our user base in the THWACK® online community. More than 150,000 members are here to solve problems, share technology and best practices, and directly contribute to our product development process.