Hi All,
We’re relatively new to BeyondTrust PRA and are deploying multiple on‑prem PRA systems (one large Atlas system plus several HA systems for data‑residency). As we plan appliance upgrades (e.g. 24.2.3 → 24.3.3), we have concerns around remote access disruption and network impact, particularly related to Jumpoints.
Environment
- 24x7 OT environments
- 100+ Jumpoints (growing significantly)
- Jumpoints used as Jump Zone proxies aligned to Purdue/network segmentation
- JumpItems - primarily JumpClients and RDP.
- Remote sites connect via low‑bandwidth, often congested satellite links
Key Concerns
- Jumpoints are not backward compatible
- Remote access is unavailable until Jumpoints are upgraded to match the appliance version.
- Upgrade size & network impact
- Latest guidance suggests Jumpoint upgrades are full installers (~130 MB), creating risk of network congestion at scale.
- Lack of upgrade controls for Jumpoints
- No way to defer/disable auto‑updates, limit concurrency, throttle bandwidth, or prioritise upgrades (unlike Jump Clients).
- Limited benefit from Jump Zone Proxy clustering
- Only available from 24.3.x and doesn’t appear to significantly reduce upgrade disruption.
Questions
Are others operating PRA in large, distributed, or low‑bandwidth environments facing similar constraints?
How do you:
- Stage or control Jumpoint upgrades?
- Minimise remote access downtime?
- Prevent large, uncontrolled network spikes during upgrades?
We have an active support case and feature request open, but would really value practical, real‑world approaches from the community.
Thanks!
