Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Incompatible with latest Purity OS #3

Open
DerekAtTW opened this issue Apr 24, 2024 · 5 comments
Open

Incompatible with latest Purity OS #3

DerekAtTW opened this issue Apr 24, 2024 · 5 comments

Comments

@DerekAtTW
Copy link

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
Copy link

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
Copy link

ladedruck commented Sep 9, 2024

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
Copy link

rbailey2 commented Oct 1, 2024

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

@emike09
Copy link

emike09 commented Oct 23, 2024

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 [email protected] 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
Copy link
Author

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants