PTF.PSx64

For everyone that does not have Visual Studio at hand, there is a Custom Sensor available at PRTGToolsFamily.com that does exactly what is described above.

PSx64 executes a PowerShell script in 64 bit mode and returns both the script result and exit code to PRTG.

Hello,

Understand this is an old topic but I am having the same issue and whilst I get close to a solution I am always stumble over a problem.

1. The PSx64 wrapper works. But I am nervous about placing a third party .exe on a production machine without knowing the full extent of the logic in the source code. Is there any chance I can get a copy of the source code for this and compile myself?

2. I took the sample C# code that was above the last post and did compile it for the x64 platform and deployed it to the EXE Custom Sensor folder. The PS1 script I have is using DFRS module which is x64 hence the issue. This works fine at the command prompt. However, when executing from within PRTG context the majority of the code works until it comes to a WRITE-HOST statement which I use to output the prtg formatted count:message result of the script. At that point in time I get a PS message indicating that "Write-Host" is not a known cmdlet.

Any Ideas would be appreciated. As mentioned the PSX64.exe works. Therefore, it must be doing something a lot more to handle the x32 vs x64 issue and evoking the correct instance of PS. But as I say, I would liek to have access to the source so that I can be comfortable with it running on a production platform.

Thanks in advance.

Hi tgm,

Please send an email to [email protected] and we will be happy to supply you with the (vb.net) source code of the PSx64 wrapper.

Hi,

I was also searching for a solution to run code with a 64-bit module from a custum EXE/XML sensor in PRTG. Eventually I was able to solve my problem using a different approach (since I'm not really into programming in C#).

I created two scripts;

• One is being ran as a scheduled task, which calls the script with the 64-bit powershell module. The script produces the output that I need for my sensor and outputs it to a file I specified on top of the script;

********** Snippet from first script **********

#Feeding the result to PRTG.
Write-Output "<prtg>
                 <result>
                 <channel>Some channel you need</channel>
                 <value>$value</value>
                 </result>
                 <result>
                 <channel>Another possible channel</channel>
                 <value>$value</value>
                 </result>
              </prtg>" | Out-File $outputDirAndName

********** Snippet from second script **********

#If the last written time was less then the warnings threshold, show the result from the inputfile, else trigger an alert.
if($lastWrittenTimeInMinutes -lt $warningThresholdInMinutes){
 
    Get-Content $inputFile

}
else{

    Write-Output " <prtg>
                       <error>1</error>
                       <text>Check Scheduled Task!</text>
                   </prtg>"

}

• The second script is the one PRTG actually targets (and calls with the 32-bit Powershell) and simply uses the "Get-Content" cmdlet to retrieve the results that the 64-bit Powershell has generated. One catch here; we need to be able to tell the difference between the result of the script triggering an alert and the fact that the scheduled task might not have ran for a while. So the second script should also look at the modified time of the input file.

So, if the file has been modified in less minutes then the warning threshold I specified on top of the script (meaning the scheduled task has ran), the sensor retrieves the values with "Get-Content". If the file wasn't modified in the number of minutes I specified, the scheduled task must not have ran and the sensor will output an alert saying I need to check it.

Just setup the channels now with the desired thresholds and you're good to go.

This solution might seem a bit devious at first, but I know exactly what the code running here is doing.

Hope this helps someone.

Is there any chance we might get to a 64 bit PRTG which can subsequently launch 64 bit powershell? As Microsoft moves into a 64-bit world, more and more of those PS modules are 64 bit only and this is becoming a real hassle to work around.

I just spend all day trying every workaround everyone else mentioned, launching powershell-64 bit exe from a powershell-32 exe, but that didn't work. Tried using a CMD and a BAT file to launch it but that didn't work. The powershell.exe that showed up in task manager was always the 32 bit no matter what.

I ended up using the suggestion posted above using a scheduled task to generate a text file, and then writing a sensor to read that text file. It's clumsy but it works.

It would be great if we could get a 64 bit PRTG on the roadmap though...it's going to be necessary.

Hi,

Creating an x64 version of the PRTG Probe Service might be part of future PRTG versions, I cannot tell you when this is going to happen at the moment. Thanks for your feedback!

Best regards, Felix

Hi, just a big up for this topic! We really need an x64 version of the PRTG probe service.

Please, may the gods hear us!! Nicolas

you should try this:
https://stackoverflow.com/questions/19055924/how-to-launch-64-bit-powershell-from-32-bit-cmd-exe

We're half way through 2019, where on the road map is refactoring PRTG to x64?

Hi there,

The Core Server already runs under 64-Bit, however for the Probe there are no plans to make it 64-Bit compatible at the moment (which then allows you to run 64-bit based sensors).

best regards

Dear PRTG,

I've killed few days to solve the task to monitor Windows Cluster.

FailOverClusters is one of PS-modules which exist in x64 only.

Ended with straightforward 'PSx64.cmd file.ps1 parameters':

"%SystemRoot%\sysnative\WindowsPowerShell\v1.0\powershell.exe" -f "C:\Program Files (x86)\PRTG Network Monitor\Custom Sensors\EXE\%~1" %~2

Please, don't ignore the issue.

13laze can you explain more detail exactly what you did? What did you change in PRTG to get your sensor working?

In my case:

The PRTG EXE Sensor is not working

Manually running this command works:

C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -file "C:\Program Files (x86)\PRTG Network Monitor\Custom Sensors\EXE\MyScript.ps1"

But manually running this next command will return the same error as the PRTG EXE sensor (the required module cannot be imported):

C:\Windows\SysWOW64\WindowsPowerShell\v1.0\powershell.exe -file "C:\Program Files (x86)\PRTG Network Monitor\Custom Sensors\EXE\MyScript.ps1"

Yeah, would be nice to get the syntax from the correct usage of PSx64.exe as the command give from i3laze seems to be incorrect. Nethertheless...Paessler : SHAME ON YOU for not giving a solution on your own. Shall i buy a visual studio package for ONE Powershell? There are a lot of ps1 scripts that only works with 64 bit PS.

Dear IT_IT,

if you contact [email protected] we can offer you an example for both the Exe/Script Custom standard sensor and advanced sensor how to run it from a 32 bit powershell calling the 64 bit powershell.

With a product as widely used as PRTG, there are a lot of improvement requests. Running 64-bit custom powershell scripts without the use of a wrapper is one of the many things which at this time is not on top of the list because other features are in higher demand.

I recently had need of this, because running 32-bit Powershell on a 64-bit server used a large amount of additional CPU overhead, causing just two Powershell sensors running once per minute to consume as much CPU as the other 100+ other sensors in our PRTG probe. I chose to use the PSx64.exe from prtgtoolsfamily.com, and it reduced the CPU usage needed to run the Powershell scripts by about 35%.

By the way Paessler, looking at the download count on the page below, it looks like this 64-bit Powershell tool is close second in popularity to the CSV export of sensor history. With over 5000 downloads each, perhaps this could be considered as 5000+ requests for each of these two features? (You mentioned other features are in higher demand, but maybe that depends on how that demand is measured?) http://prtgtoolsfamily.com/downloads/sensors

PRTG with all sensors running except Powershell scripts, total server CPU measured at 10.5% CPU usage. With one Powershell script running in 32-bit mode, total server CPU measured at 25.0% CPU usage. With the same Powershell script running in 64-bit mode with the PSx64.exe, total server CPU measured at 20.0% CPU usage. So additional CPU needed to run the same Powershell script was 9.5% in 64-bit mode instead of 14.5% in 32-bit mode.

If you (like me) also want to let Paessler know how hard this feature is required, please upvote my feature request. As a community we can use our voice to let them know what is important to us.

Please upvote https://kb.paessler.com/en/topic/88370-64-bit-probe

I used this snippet for a Failovercluster-Sensor and a Sensor requiring sqlserver module.

if ($env:PROCESSOR_ARCHITEW6432 -eq "AMD64") {
    # Source: https://stackoverflow.com/a/38981021
    #write-warning "Y'arg Matey, we're off to 64-bit land....."
    if ($myInvocation.Line) {
        &"$env:WINDIR\sysnative\windowspowershell\v1.0\powershell.exe" -NonInteractive -NoProfile $myInvocation.Line
    }else{
        &"$env:WINDIR\sysnative\windowspowershell\v1.0\powershell.exe" -NonInteractive -NoProfile -file "$($myInvocation.InvocationName)" $args
    }
    exit $lastexitcode
}

Issue is still there, and l PSx64.cmd workaround still work just fine..

Trick here is to supress any temptations to modify the .cmd script and stick with "\sysnative\", as this command only works when run from a 32-bit process on a 64-bit system. It will not work if you try to run this from a 64-bit process (like cmd.exe). The sysnative redirector is only available to 32-bit processes.