Deploy BeyondTrust PRA Jump Clients and Jump Groups Reliably

TL;DR — You are deploying BeyondTrust PRA jump clients onto target machines and assigning them to the right jump groups so they show up online in the PRA console and can be reached through the intended policy boundary. The most common failure is outbound connectivity from the target host to the PRA appliance or a package generated with the wrong site/group policy; test TCP 443 to the appliance first, then redeploy a package generated for the correct jump group. Reading time: ~5 min

Goal

When you finish, one or more target hosts will have a BeyondTrust PRA jump client installed, those hosts will appear online in the expected jump group in your PRA deployment, and an authorized user will be able to start a session to the host through that group.

Prerequisites

• BeyondTrust Privileged Remote Access admin access with permission to create or download jump client installers and manage jump groups
• Access to the PRA appliance hostname or public URL, for example pra.example.com
• The jump group name you want the hosts to land in, for example Linux-Prod or Windows-Servers
• Credentials with local admin/root on each target host
• Network path from each target host to the PRA appliance on TCP 443; verify with:

curl -I https://pra.example.com/

• Linux targets: bash, curl, and either dpkg or rpm; check with:

bash --version
curl --version
dpkg --version || rpm --version

• Windows targets: PowerShell 5.1+; check with:

$PSVersionTable.PSVersion

• If your org uses outbound proxying, the proxy hostname, port, and whether authentication is required
• A maintenance window if endpoint security blocks unsigned/new remote-support agents in your environment

Steps

Step 1: Confirm the target host can reach the PRA appliance

Run one of the following on the target host.

Linux/macOS:

curl -I https://pra.example.com/

Windows PowerShell:

curl.exe -I https://pra.example.com/

You should see an HTTP response over TLS, typically shaped like:

HTTP/1.1 200 OK
server: nginx
content-type: text/html; charset=utf-8

or sometimes a redirect:

HTTP/1.1 302 Found
location: /login

A successful step returns headers, not Could not resolve host, Connection timed out, or SSL certificate problem.

Step 2: Create or identify the destination jump group in PRA

In the PRA admin interface, open the jump group management area in your appliance UI and either create the target group or copy the exact existing group name. Use the literal group name you want, for example Linux-Prod.

If your UI exposes a path similar to an admin area, use the jump-group page there and create Linux-Prod or Windows-Servers exactly; vendor layouts vary by version, but the value to enter is the exact jump group name.

You should see the jump group listed by that exact name in the PRA admin UI.

Step 3: Generate a jump client installer bound to the correct site and jump group

In the PRA admin interface, generate/download a jump client installer for the correct public site/appliance and assign it to the exact jump group from Step 2. Save the installer to your workstation with a filename that identifies the group, for example:

jumpclient-linux-Linux-Prod-amd64.bin
jumpclient-windows-Windows-Servers.exe

If your PRA UI asks for a site, select the public site users actually connect through, not a test site. If it asks for a jump group, select Linux-Prod or your exact target group.

You should end up with a downloadable installer file for each platform you need.

Step 4: Install the jump client on a Linux host

Copy the Linux installer to the target host, then install it as root.

scp ./jumpclient-linux-Linux-Prod-amd64.bin root@app01:/root/
ssh root@app01 'chmod +x /root/jumpclient-linux-Linux-Prod-amd64.bin && /root/jumpclient-linux-Linux-Prod-amd64.bin'

If your package is a .deb or .rpm, use the package manager instead:

scp ./jumpclient-linux-Linux-Prod-amd64.deb root@app01:/root/
ssh root@app01 'dpkg -i /root/jumpclient-linux-Linux-Prod-amd64.deb'

scp ./jumpclient-linux-Linux-Prod-amd64.rpm root@app01:/root/
ssh root@app01 'rpm -Uvh /root/jumpclient-linux-Linux-Prod-amd64.rpm'

Then confirm the service/process exists:

ssh root@app01 'ps aux | grep -i jump | grep -v grep; systemctl list-units --type=service | grep -i jump || true'

You should see an installed process or service entry and no installer error such as permission denied or missing library errors.

Step 5: Install the jump client on a Windows host

Copy the installer to the host and run it elevated.

Start-Process -FilePath "C:\Temp\jumpclient-windows-Windows-Servers.exe" -Verb RunAs -Wait

If you are pushing from a remote PowerShell session, copy then execute:

Copy-Item .\jumpclient-windows-Windows-Servers.exe \\winhost\C$\Temp\
Invoke-Command -ComputerName winhost -ScriptBlock { Start-Process -FilePath "C:\Temp\jumpclient-windows-Windows-Servers.exe" -Verb RunAs -Wait }

Then confirm the service is present:

Get-Service | Where-Object { $_.Name -match 'jump|beyondtrust|bomgar' }

You should see a running or installed service object rather than Cannot find any service with service name.

Step 6: If the host uses an outbound proxy, install only after proxy egress works

Test the appliance URL through the proxy from the target host.

Linux:

https_proxy=http://proxy.example.com:8080 curl -I https://pra.example.com/

Windows PowerShell:

curl.exe -x http://proxy.example.com:8080 -I https://pra.example.com/

If your proxy requires auth, use the literal credentials format your proxy expects:

https_proxy=http://DOMAIN\\svc_proxy:SuperSecret@proxy.example.com:8080 curl -I https://pra.example.com/

You should get the same HTTP headers as Step 1; if you get 407 Proxy Authentication Required, fix proxy auth before installing the client.

Step 7: Confirm the endpoint lands in the intended jump group

In the PRA representative/admin interface, open the jump item or jump client listing and filter by the exact hostname, for example app01, then check its group assignment is Linux-Prod.

If the host appears in the wrong group, regenerate the installer for the correct jump group and reinstall using the package from Step 3.

You should see the host online under the exact jump group you selected.

Verify it works

Run these checks end-to-end.

1. From the target host, confirm appliance reachability:

curl -I https://pra.example.com/

Expected shape:

HTTP/1.1 200 OK

or:

HTTP/1.1 302 Found
location: /login

1. On Linux, confirm the client process/service is still running after install:

ps aux | grep -i jump | grep -v grep
systemctl list-units --type=service | grep -i jump || true

Expected result: at least one jump-client-related process or service line.

1. On Windows, confirm the service exists:

Get-Service | Where-Object { $_.Name -match 'jump|beyondtrust|bomgar' }

Expected result: a service in Running or Stopped state, not an empty result.

1. In the PRA console, verify the host is online in the intended jump group and start a test session to it. Expected result: the session connects without the host first appearing in another group or remaining offline.

Common pitfalls

Wrong jump group selected when generating the installer

Mistake: you downloaded a valid installer, but it was bound to Default or a test group instead of Linux-Prod.

Symptom: the host appears online, but under the wrong jump group, so the right team cannot find or use it.

Fix: regenerate the installer with the exact target jump group and reinstall that package.

Target host cannot reach the PRA appliance on TCP 443

Mistake: outbound firewall rules or DNS block the target host from connecting to pra.example.com.

Symptom: install appears to complete, but the host never comes online; curl -I returns errors like:

curl: (6) Could not resolve host: pra.example.com
curl: (7) Failed to connect to pra.example.com port 443: Connection timed out

Fix: open outbound TCP 443 and fix DNS resolution, then rerun the installer.

TLS inspection or certificate trust breaks the client connection

Mistake: a proxy or security device resigns TLS and the target host does not trust that CA for this traffic.

Symptom: curl -I shows certificate failures such as:

curl: (60) SSL certificate problem: unable to get local issuer certificate

Fix: bypass TLS interception for the PRA hostname or install the required trust chain on the target host.

Proxy required, but the host has no working proxy path

Mistake: the environment requires outbound web traffic through a proxy, but the host or service account cannot use it.

Symptom: direct curl -I fails, and proxy tests return:

HTTP/1.1 407 Proxy Authentication Required

Fix: provide the correct proxy host, port, and credentials, verify with curl -x ... -I, then reinstall.

Endpoint security quarantines the installer or service

Mistake: EDR/AppLocker/application control blocks the jump client binary or service registration.

Symptom: the installer exits immediately, the service never appears, or Windows logs show blocked execution.

Fix: allowlist the installer and installed service path in your endpoint controls, then rerun the install elevated.

Reusing an old installer after changing PRA site/group settings

Mistake: you changed the intended site or jump group in PRA but kept deploying a previously downloaded installer.

Symptom: newly installed hosts keep registering to the old site/group even though the console configuration has been updated.

Fix: discard cached installers, download a fresh package after the change, and redeploy that exact file.

This article was written by an AI system and published pending human review. Verify anything you intend to act on.