Unable to onboard on-premise Windows server with script

Question

Hello,

I try to use the onboard script to install an azure agent on a Windows 2012 R2 server. However, when i launch the script, i got the error :
Invoke-WebRequest : La connexion sous-jacente a été fermée : Une erreur inattendue s'est produite lors de l'envoi.

Au caractère C:\exploite\Scripts\OnboardingScript.ps1:66 : 5
+     Invoke-WebRequest -UseBasicParsing -Uri "https://gbl.his.arc.azure.com/log"  ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidOperation : (System.Net.HttpWebRequest:HttpWebRequest) [Invoke-WebRequest], WebException
    + FullyQualifiedErrorId : WebCmdletWebResponseException,Microsoft.PowerShell.Commands.InvokeWebRequestCommand

When i try to access the website, i get the following (asking activate TLS in french) :

TLS 1.0, 1.1 and 1.2 are already activated. What could be wrong ?

Answer 1

Hello palm lbi, You are running the Azure agent onboarding PowerShell script (OnboardingScript.ps1) on a Windows Server 2012 R2 machine. You have already verified that TLS 1.0 / 1.1 / 1.2 are enabled at the OS level, and the target Azure URL is reachable in a browser, but the script still fails.

The issue you are getting might be the reason below.

1. PowerShell uses .NET, not the OS TLS settings directly: On Windows Server 2012 R2, .NET defaults to TLS 1.0, even if TLS 1.2 is enabled in the OS.
2. Azure onboarding endpoints reject TLS 1.0 / 1.1: When PowerShell attempts the request using an older protocol, the server drops the connection during the TLS handshake, resulting in this error.
3. The error message is misleading: The message suggests a network issue, but the real cause is TLS protocol negotiation failure, not connectivity.

This behavior is widely documented for Invoke-WebRequest on Server 2012 R2 and PowerShell ≤ 5.1. Invoke-WebRequest (Microsoft.PowerShell.Utility) - PowerShell | Microsoft Learn

 To resolve this :

Force TLS 1.2 in the onboarding script (mandatory): Add this line at the very top of OnboardingScript.ps1, before any Invoke‑WebRequest call:

[Net.ServicePointManager]::SecurityProtocol =
[Net.SecurityProtocolType]::Tls12 `
-bor [Net.SecurityProtocolType]::Tls11 `
-bor [Net.SecurityProtocolType]::Tls

This explicitly forces PowerShell to negotiate TLS 1.2 and resolves the issue in most cases.

Verify PowerShell and .NET versions:

Requirements:

• PowerShell 5.1
• .NET Framework 4.6 or higher

Older versions on Server 2012 R2 are known to fail TLS 1.2 connections even when forced.

Hope this helps. and please feel free to reach out if you have any further questions. Thanks

Answer 2

Make sure that all network prerequisites are satisfied - as per https://learn.microsoft.com/en-us/azure/azure-arc/network-requirements-consolidated?tabs=azure-cloud

Also review https://learn.microsoft.com/en-us/windows-server/security/tls/tls-registry-settings?tabs=diffie-hellman

---

If the above response helps answer your question, remember to "Accept Answer" so that others in the community facing similar issues can easily find the solution. Your contribution is highly appreciated.

hth

Marcin

Answer 3

palm lbi hi,

that error on WinServer 2012 R2 is almost always related to TLS negotiation, even if TLS 1.0, 1.1 and 1.2 are enabled in the registry. The real issue is usually that PowerShell and .net are not actually using TLS 1.2 by default. Azure arc endpoints require TLS 1.2 and modern cipher suites.

On Server 2012 R2, PowerShell 4 or older .net versions default to TLS 1.0. You need to explicitly force TLS 1.2 before Invoke-WebRequest runs. Test this in the same session before executing the onboarding script [Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12

Retry the Invoke-WebRequest manually against https://gbl.his.arc.azure.com/log. If it works after forcing TLS 1.2, update the onboarding script to set the SecurityProtocol at the top.

.net framework 4.7 or later is installed? Proper TLS 1.2 support with modern cipher suites depends on updated .net and Windows patches. Install the latest cumulative updates for 2012 R2.

If the browser shows the TLS activation message, it usually means the server is negotiating an outdated protocol or weak cipher like RC4. Check cipher suites via IISCrypto or PowerShell and ensure strong cipher suites are enabled and RC4 is disabled. At the end no outbound proxy or ssl inspection device breaking TLS handshake. Azure Arc endpoints must allow outbound HTTPS with TLS 1.2 without interception.

rgds,

Alex