Incompatible with latest Purity OS

[DerekAtTW]

after upgrading to purity 6.5.x this wonderful monitor stopped functioning with "connection reset" errors. called pure and they said they dropped support for the 1.x API versions

anyone have awareness of an updated sensor?

[flakshack]

We recently upgraded Purity to 6.5.7 and this script stopped working. The script was reporting the error: "Invoke-RestMethod : The underlying connection was closed: An unexpected error occurred on a send."

I did some quick RESTAPI testing in Postman and determined that the API calls are still working. Maybe that will break in the future, but not at this version of Purity.

For whatever reason (TLS related?), the script fails to make the RESTAPI connection in PowerShell 5, but in my debugging, I quickly discovered that it works perfectly fine in PowerShell 7. There's probably a much better solution to this problem, but the following workaround solved the problem for us by having PRTG launch the script using PowerShell 7.

Install PowerShell 7 on your PRTG server and any PRTG probe servers (if you have them).

Create a new .BAT file in your PRTG EXEXML folder on each server. I called mine:

C:\Program Files (x86)\PRTG Network Monitor\Custom Sensors\EXEXML\Powershell7-Launcher.bat

Inside the .BAT file

@echo off
REM This batch file is used to get around PRTG limitations on PowerShell 7.  
REM All parameters are passed to pwsh using '%*'
"C:\Program Files\PowerShell\7\pwsh.exe" -NoProfile -NonInteractive -ExecutionPolicy Bypass %*

Create a new EXE/Script Advanced sensor and select this new batch file.

In the Parameters section, pass the full path to the unmodified Get-PureFA-Sensor.ps1 script, along with the previous parameters.

-File "C:\Program Files (x86)\PRTG Network Monitor\Custom Sensors\EXEXML\Get-PureFA-Sensor.ps1" -arrayaddress %host -scope capacity -apikey XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

Note that the entire parameter is passed to PowerShell, so we have to remove the single-quotes around the strings.

Anyway, this seems to work fine for us. Hope you have similar luck.

[ladedruck]

Hi

I had the same issue with Purity 6.5.7. Fixed it like that:

• Import a valid SSL certificate to the pure array or create a self signed certificate and import it to trusted root CAs on the PRTG probe.
• Make sure you use the exact FQDN from the certificate CN to access the pure storage array
• Comment or delete line 835 from the Get-PureFA-Sensor.ps1

#[System.Net.ServicePointManager]::ServerCertificateValidationCallback = {$true}

Cheers Claudio / Swiss IT Professional AG

[rbailey2]

ladedruck's solution worked for me on 6.5.8. Thanks for that!

[emike09]

Can confirm ladedruck's solution as well. We used our internal CA to generate a new certificate. The default self-signed cert doesn't have a CN, so isn't valid for PRTG to connect.

Looks like lloydy@purestorage.com no longer works at Pure, unfortunately, so hopefully others here are smart enough to check this Issues section. I think I might fork it.

[DerekAtTW]

emike09 did fork it, and his fork is working great for us. thanks!