0

using PowerShell v5.1 on windows server 2016, for monitoring the availability of the following CrowdStrike Cloud Endpoint: https://ts01-b.cloudsink.net, with a dedicated proxy in our organization:

$URLAddress = "https://ts01-b.cloudsink.net"
$ProxyAddress = "http://proxyout.dev:8080"

$response = $null
$errorcode = $null

[Net.ServicePointManager]::SecurityProtocol = "tls12, tls11, tls"


try
{
$request = Invoke-WebRequest -Uri $URLAddress -Method Get -UseBasicParsing -DisableKeepAlive -MaximumRedirection 0 -Proxy $ProxyAddress -ProxyUseDefaultCredentials

$response = $request.StatusCode
Write-Host "Status Code -- $response"
}
catch
{
$errormessage = $_.Exception.Message
$errorcode = $_.Exception.Response.StatusCode.Value__
}


IF ($response -eq '200')
{
IF ($errorcode -eq $null)
{
  Write-Host "url: ""$URLAddress"" is avalible. `nStatus Code: $response"

}
ELSE
{
  Write-Host "url: ""$URLAddress"" is avalible but porxy: ""$proxydev"" has an error, `nError Code: $errorcode `nError Message:`n$errormessage. `nStatus Code: $response"
}
}
ELSE
{
  Write-Host "url: ""$URLAddress"" is not avalible. `nStatus Code: $response `nError Code: $errorcode `nError Message:`n$errormessage"
}

$request.BaseResponse.Close() 

But I'm experiencing a strange behavior with the above script, for some reason i will get a permanent error of:

The underlying connection was closed: An unexpected error occurred on a send.

Even though when I'm running the script locally on target server, the script is working without any problems.

Running an analysis using SSL Report, i can verify that ts01-b.cloudsink.net is using TLS version 1.2. so i don't need to bypass the SSL certificate check [System.Net.ServicePointManager]::ServerCertificateValidationCallback = {$true} which is something that i saw mentioned frequently in other Stack Overflow posts, like:

Unexpected error occurred running a simple unauthorized Rest query

Invoke-WebRequest : The underlying connection was closed: An unexpected error occurred on a send

It is worth mentioning that the problematic window server is used by all the other developers in the organization, which run their own PowerShell scripts frequently manually or schedules by using a monitoring agent named SCOM by Microsoft.

I'm struggling to understand the root cause of this problem, has anyone experienced this kind of issue?

edwio
  • 198
  • 3
  • 20
  • What happens if you try the same url in a web browser on the broken server? (Using the same account as the script is running in) – mclayton Jan 09 '23 at 15:02
  • @mclayton, when running the PowerShell script manually on the target server, the script works without any problem. same for accessing it manualy trhoug the browser. – edwio Jan 09 '23 at 15:33

0 Answers0