When the install line fails

Could not create SSL/TLS secure channel

On Windows Server 2016, 2019 and 2012 R2, the install line can stop before it downloads anything:

irm : The request was aborted: Could not create SSL/TLS secure channel.

Windows PowerShell 5.1 lets .NET pick the TLS version, and on those releases the default is TLS 1.0 and 1.1. The hub only accepts TLS 1.2 and above, so the connection is refused during the handshake. Nothing reaches the hub, and the machine's certificate store, the firewall and the install link are all irrelevant to this error.

The install page now hands out a command that already begins with the fix, so a freshly copied line works on these machines. An older command, or one written down before this changed, needs the protocol chosen first:

[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12; Set-ExecutionPolicy Bypass -Scope Process -Force; irm "https://hub.[yourdomain]/install/inst_…/windows.ps1" | iex

The downloaded script sets TLS 1.2 on its own second line, which is why the agent and its updates work on these machines once it is installed. That line cannot prevent this failure: it happens while PowerShell is still fetching the script, before a word of it has run. Only the command you paste can fix it.

The setting lasts for that PowerShell window only. Nothing needs to be changed permanently on the machine for the agent to work afterwards, because the agent brings its own TLS.

Still fails after setting TLS 1.2

Two things produce the same message and the line above will not fix either.

TLS inspection. A firewall or antivirus that decrypts HTTPS presents its own certificate. If the machine does not trust that issuer, the handshake fails. Confirm by opening the install link in a browser on that machine and inspecting the certificate: it should be issued by Let's Encrypt, not by your security appliance. Exempt the hub's hostname from inspection, or install the appliance's root certificate on the machine.
TLS 1.2 disabled in the registry. Some hardened builds switch it off under HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols. The client cannot ask for a protocol the system has turned off. Re-enable TLS 1.2 there; this needs a reboot.

Run this in an elevated PowerShell

The script stops on purpose when it is not running as Administrator. It installs a service, so it cannot proceed without it. Close the window, start PowerShell with Run as administrator, and paste the line again. Right-clicking the script or using an unelevated Windows Terminal tab is the usual cause.

Running scripts is disabled on this system

The install line already begins with Set-ExecutionPolicy Bypass -Scope Process -Force, which applies to that window alone and needs no permanent change. If the message appears anyway, execution policy is being forced by Group Policy, which a process-scope setting cannot override. Either exempt the machine, or download the script and run it through a policy your organisation allows. Check what is in force with Get-ExecutionPolicy -List.

The machine is behind a proxy

PowerShell does not always use the proxy configured for the browser. If the download hangs or is refused, point it at the proxy for that window:

[Net.WebRequest]::DefaultWebProxy = New-Object Net.WebProxy('http://proxy.example:8080'); [Net.WebRequest]::DefaultWebProxy.Credentials = [Net.CredentialCache]::DefaultCredentials

This covers the install download only. The agent's own tunnel does not go through a proxy: it dials the hub directly on 443. On a network where outbound 443 is only allowed through a proxy, the install can succeed and the machine still never connects. Allow the hub's hostname directly for those machines.

It installed but never appeared in the fleet

The install finished, the BEAgent service is running, and nothing shows up. The agent keeps its own log next to the binary at C:\BEAgent\be-agent.log; read that first, it names the reason.

Outbound 443 to the hub is blocked, or the tunnel's WebSocket upgrade is being stripped in transit. The agent connects out only, and directly: nothing needs to be opened inbound, and it will not use a proxy to get there.
The enrollment token was rotated after the install link was copied. Copy the current link from the company page and run it again with the apply option.
The machine already belongs to another company. A machine cannot be claimed by a second company's token on its own. Re-home it from the company page as superadmin, then re-run the install line with apply.

Page and script fetches are recorded in the audit trail, so you can confirm from the hub whether the machine ever reached it.

Checking the hub from the machine

One line tells you whether it is the network, the TLS version or the hub. Run it on the machine that failed:

[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12; (irm "https://hub.[yourdomain]/health")

A reply means the machine can reach the hub over TLS 1.2 and the install line will work with the same prefix. A TLS error with that prefix in place points at inspection or a disabled protocol. A timeout or refusal points at the network rather than at TLS.

Other platforms

Linux, macOS, FreeBSD and OpenWrt use curl, fetch or wget, which negotiate a modern TLS version by default, so this class of failure does not arise there. The usual causes on those platforms are running without sudo, no outbound 443, or too little free space on small routers, which need roughly 7 MB of flash.