Troubleshooting

Likely cause: A firewall between the endpoint/rep and the appliance is blocking outbound TCP 443, or — for peer-to-peer scenarios — UDP/TCP 3478/5349 and the 49152–65535 ephemeral range needed for STUN/TURN. Because every PRA connection is outbound-only (Module 1), this is almost always a client-side or DMZ egress rule, not something wrong on the appliance itself.

Fix: Confirm TCP 443 is open outbound from both the rep's network and the endpoint's network to the appliance. If Peer-to-Peer sessions or STUN/TURN media relay are in play, also open UDP/TCP 3478 and 5349 and the ephemeral UDP range. Check the firewall rule tables from Module 1 rather than assuming the appliance is down.

Likely cause: Two common causes. First, the endpoint genuinely can't reach the appliance (network change, endpoint powered off, agent crashed). Second — and easy to miss — an appliance certificate store that wasn't kept current before a version upgrade; BeyondTrust explicitly warns that failing to manage certificate stores before upgrading "may cause a majority of your existing Jump Clients to appear offline."

Fix: Check the endpoint's network connectivity first. If a large batch of Jump Clients went offline right after an appliance upgrade, suspect the certificate store rather than the individual endpoints (Module 3). A Jump Client that stays disconnected past the configured "days before automatically deleted" threshold gets uninstalled and removed automatically — use the smaller "labeled as lost" threshold to catch problems before that happens.

Likely cause: Automatic shared-IP failover has strict prerequisites: both appliances must be on the same subnet, Enable Backup Operations must be turned on for the backup site, and Enable Automatic Failover must be checked — none of which are default-on in every configuration. It's also common for admins to leave "Enable Backup Operations" turned on for what's supposed to be the normal-primary appliance, which then generates unwanted sync/alert behavior during planned maintenance, per BeyondTrust's own best-practice guidance (Module 6).

Fix: On the backup appliance's Failover page, verify Backup Operations and Automatic Failover are both enabled, confirm the appliances share a subnet (or that you're using the failover API for cross-subnet setups), and check the Primary Site Instance Timeout — the backup will only take over after the primary has been unreachable for that configured duration, not immediately.

Likely cause: Integrated login (LDAP, RADIUS, or Kerberos) failed — either the exchange failed too early to even identify a username, or the exchange succeeded but the security provider's configuration has no matching default policy or group lookup and so denies the user. Both cases generate a syslog event=login;status=failure entry, which is the fastest way to tell the two apart (Module 8).

Fix: Check the Syslog report or appliance logs for the failure reason first rather than guessing. If the username never resolved, the issue is upstream (network path to the LDAP/RADIUS/KDC server, or a bad service ticket for Kerberos). If the username resolved but access was still denied, review the security provider's default policy and group lookup mapping — the provider is reachable but isn't authorizing that user or group.

Likely cause: Session Policy evaluation runs through an ordered chain — Jump Item Session Policy, then Group Policy, then user-assigned policy — and only falls through to the Global Default Policy if none of those explicitly return Allow or Deny. The Global Default Policy cannot be deleted, cannot be set to "Not Defined," and denies everything by default. If a permission was left at "Not Defined" all the way up the chain, the user silently lands on a policy that denies by design (Module 17).

Fix: Treat any decision traced back to the Global Default Policy as a warning sign of a policy gap, not a one-off bug. Walk the same evaluation order — Jump Item, then Group Policy, then user policy — to find where the permission should have been explicitly set to Allow, and confirm nobody has changed the Global Default's answers away from their intentionally strict factory setting.

Likely cause: The B Series Appliance ships with a pre-installed self-signed certificate, which browsers and some integrations will flag as untrusted. Separately, a CA-signed certificate that was never renewed (or an ACME/Let's Encrypt automation that silently stopped working) will expire and break the same way (Module 4).

Fix: On /appliance > Security, check the certificate's Expiration column and Issued By field. Replace the default self-signed certificate with a CA-signed one for production use, and if you're using Let's Encrypt automated renewal, confirm the ACME server registration is still valid rather than assuming renewal "just works" forever.

Likely cause: The Asset Policy requires a ticket ID or approval, but the supporting configuration is incomplete — no Ticket System URL configured in /login, no User Prompt text configured, an HTTP (not HTTPS) URL used while "Treat Ticket ID as sensitive" is checked, or the external ticketing system itself timed out or explicitly rejected the ID (Module 12).

Fix: Read the specific error text in the access console — PRA differentiates "no ticket system URL configured, contact your administrator" (an admin-side gap) from "invalid ticket ID" (a user-side or external-system rejection). Admin-side errors get fixed on the Asset Policy's Ticket System configuration; user-side errors mean the ticket ID itself was wrong or the external system is down.

Likely cause: Duplicate active Jump Clients on the same endpoint — commonly from re-running a mass-deployment installer, or from an endpoint being re-imaged without the old Jump Client being properly removed first (Module 15).

Fix: Run the Duplicate Jump Clients report (a query against all active Jump Clients in the database) and remove the stale copies. This was specifically built for admins who were "having difficulty mapping the Jump Clients and their copies in the Rep Console to their allotted licenses" — it's the right tool, not manual searching through the Asset Management Interface.

Likely cause: Screen Sharing Recording, Database Connection user recording, and Command Shell Recording are three independent checkboxes under Configuration > Options > Access Session Logging Options — none of them retroactive. If the toggle was off during the session (or an Asset Policy had "Disable Session Recordings" checked), there is no recording to find later, no matter how you filter the report (Module 21).

Fix: Verify the relevant recording toggle was enabled before the session happened, and check whether the Asset the session ran against uses an Asset Policy with Disable Session Recordings checked — that setting silently overrides the global Configuration > Options toggles for any Asset using that policy.

Likely cause: Session Forensics relies on a search index, not a live scan of recordings. If forensics was just turned on, or was off during the session and later re-enabled, the index has to be rebuilt, and BeyondTrust explicitly notes that searches may not return all matches while that rebuild is in progress (Module 21).

Fix: Give the index time to finish rebuilding before concluding the data isn't there. If the session in question happened before Session Forensics was enabled at all, there is no forensics data to index for it — the Session report's own chat/file-transfer/recording links are still the fallback.

Likely cause: All of these features share one dependency — a working SMTP configuration on /login > Management > Email Configuration. Failover alert emails specifically require a valid SMTP server configured on the primary appliance, and that configuration is then copied to the backup on the next sync (Module 7 and Module 6).

Fix: Send a test email from the Email Configuration page first — don't assume the feature (failover alerting, approval notifications) is broken when the shared SMTP plumbing underneath it is what actually failed. If the primary and backup appliances disagree on SMTP settings, check whether a sync has actually completed since the SMTP settings were last changed.