Part 2 · Appliance & Site Configuration
Appliance Updates & Configuration
Before any site, policy, or user exists, someone has to bring the B Series Appliance itself onto the network, register it, and keep it patched. This module covers the /appliance interface — the base layer beneath the /login site you'll spend most of the rest of this course in.
Two interfaces, two layers
New admins often assume "the admin panel" is a single thing. In practice, a B Series Appliance exposes two distinct web interfaces that live at the same IP address but do very different jobs. The Base firmware — reached at /appliance — provides system-level configuration: networking, IP addresses, SSL certificates, updates, and licensing. The site software — reached at /login — is where users, policies, Jump Items, and everything else you'll configure in later modules lives. This module is entirely about the former. Think of /appliance as the layer you configure once when the box is racked and then return to only for patching, licensing, or networking changes, versus /login, which you're in constantly as you build out the site.
Out of the box, a B Series Appliance answers at https://<ip>/appliance with username admin and password password. You are forced to change this password on first login. If your network segment has DHCP, the appliance grabs an address automatically and you can find it via the console video port; without DHCP, you must set a static IP through the physical console before you can reach /appliance over the network at all.
Bringing the appliance onto the network
Initial setup happens in two possible paths depending on whether DHCP is available. On a DHCP-enabled segment, plug the appliance in, power it on, and it self-assigns an address you read off the console. On a static segment, you connect a monitor and keyboard to the console port and walk the text-based menu: log in with the default credentials, select the Networking menu, choose the interface (typically eth0), add an IP address and prefix length, then set the default gateway — all before the web interface is reachable at all.
Once you can reach /appliance in a browser, the Status > Basics page is the first stop. It displays the appliance's serial number, which BeyondTrust Technical Support uses to register the unit against the licensing servers — screenshotting this page and emailing it to Support is a standard part of bringing a new appliance online.
IP configuration
Under Networking > IP Configuration, the NIC Configuration section is where you add the static IP and subnet mask the appliance will actually run on day to day (as opposed to the temporary address used during initial setup). Each IP address can independently be flagged to support session traffic, web traffic, or both. Below that, the Global Network Configuration section holds the default gateway and DNS server addresses.
DNS is not optional here. Valid DNS settings are a prerequisite for both failover (Module 6) and automatic updates to function — the appliance needs to resolve BeyondTrust's update servers and, in a failover pair, potentially resolve its peer. An appliance with a broken or missing DNS entry will silently fail to check for updates and give you no obvious error beyond a stale "last checked" timestamp.
Applying updates
Update management lives on Appliance > Updates. As of recent releases, BeyondTrust ships with automatic updates disabled by default — a deliberate change from earlier behavior, made so that customers keep full control over when their production appliance changes version rather than being patched on a vendor-controlled schedule. FedRAMP customers are the one exception; automatic updates cannot be disabled for them.
To turn automatic updates on, you check Automatically install the latest updates during maintenance day(s) and time and pick a maintenance window. Alongside the window you select an Automatic Update Channel, which controls how aggressively the appliance chases new releases:
| Channel | Behavior |
|---|---|
| Fast Track | Updates as soon as they're available for the latest major release and its maintenance releases (e.g. 25.2, 25.2.2) |
| Standard Track | Regular cadence for the latest major release |
| Enterprise Track | Runs two versions behind the current release (n-2) for maximum stability before adoption |
Automatic updates do not apply to a failover configuration or an ATLAS deployment — in a backup/primary pair, both appliances must run identical software, so BeyondTrust deliberately excludes those topologies from unattended patching to avoid the two peers drifting out of sync mid-update. Updates can also be applied manually: an admin downloads an update package from BeyondTrust and uploads it through the Upload Update workflow on the /login > Management page, which stages the package, lets you review what it contains, and only installs once you explicitly confirm.
Guardrails around disabling critical updates
Because critical security patches matter more than general feature updates, PRA treats them separately. If an administrator unchecks Automatically install critical updates every day during the Maintenance Window, the system throws up a high-visibility warning explaining the security implications, and requires the admin to type a confirmation string exactly as shown before the change is even saved. This friction is intentional — it stops a misclick or a rushed change ticket from silently turning off critical patching.
The Updates page also surfaces a live connectivity indicator: a green dot means the update service is reachable with a timestamp of the last successful check; a red dot flags a connectivity issue with troubleshooting hints (firewall, DNS, proxy) and a link to Network Diagnostics; a blue dot means connectivity simply hasn't been verified yet. If automatic updates are enabled but the appliance can't reach the update service, a yellow inline warning banner appears directly in the Maintenance Window section so the gap doesn't go unnoticed until an audit.
An admin enables automatic updates, picks a maintenance window, and considers the job done — without noticing the appliance's DNS configuration is wrong or an outbound firewall rule to btupdate.com:443 is missing. The appliance never actually reaches the update service, and because updates were "enabled," nobody thinks to check again until a penetration test or compliance audit flags months-old software. Always confirm the green "Connected" status after configuring automatic updates, not just the checkbox.
Licensing
PRA licensing is tied to the specific serial number of the appliance and provisioned server-side by BeyondTrust once the appliance is registered (the Status > Basics screenshot workflow described above). Endpoint licensing — how many Jump Clients and Assets your site is entitled to configure — is then visible from the /login side on the Status page, which reports both Endpoint Licenses (the total allowed) and Endpoints Configured (the current count), along with Maximum Concurrent Users for the access console. If an update package contains only additional licenses rather than a software change, it can be installed without restarting the appliance — worth knowing when you're just unlocking capacity rather than patching.
Appliance-level settings beyond IP and updates
The console administration menu (the physical/video-port console, distinct from the web UI) exposes a subset of the same networking controls — hostname, IP addresses, default gateway, static routes, and DNS servers — plus options to shut down or reboot the appliance, enable an advanced support tunnel for BeyondTrust Technical Support, or reset the appliance password or a site's administrative password. This matters operationally: if the network configuration is broken badly enough that /appliance is unreachable over HTTP, the console is your fallback path to fix it without physically reimaging anything.
The appliance ships with two NICs. BeyondTrust supports placing both on the same network for NIC teaming (in which case only one NIC should actually be configured with an IP — giving both an address on the same subnet causes unexpected behavior) or splitting them across separate subnets for segmented traffic routing. When multiple IP addresses are needed on one subnet, the correct approach is to assign them all to a single NIC rather than spreading them across both.