Configure Jump Client Settings

Jump Client Statistics

An administrator can choose which statistics to view for all Jump Clients on a site-wide basis. These statistics are displayed in the representative console and include operating system, uptime, console user, CPU, disk usage, and a thumbnail of the remote screen. Existing Jump Clients will reflect changes to Jump Client statistics at the next update interval.


Jump Client Settings

The Active Jump Client Statistics Update Interval determines how often these statistics are updated. Managing which statistics are viewed and how often can help to regulate the amount of bandwidth used. The more active Jump Clients you have deployed, the fewer the statistics and the longer the interval may need to be.

Also set the maximum number of Jump Clients to upgrade at the same time. Note that if you have a large number of Jump Clients deployed, you may need to limit this number to regulate the amount of bandwidth consumed.

You may further regulate the bandwidth used during upgrades by setting Maximum bandwidth of concurrent Jump Client upgrades.

Note: Neither of these settings affects representative console upgrades or Bomgar Button deployments.

The option Allow simultaneous representative access to a single Jump Client provides a way for multiple representatives to gain access to the same Jump Client without having to be invited to join an active support session by another representative. The first representative to access the Jump Client maintains ownership of the session. Representatives in a shared Jump session will see each other and be able to chat.

Restrict Local Uninstall/Disable of Jump Clients limits the remote user’s ability to uninstall or disable Jump Clients from the right-click context menu, reducing the need to reinstall Jump Clients that should not have been uninstalled. If this option is enabled, only users with appropriate privileges on the target machine may uninstall the Jump Client via the host system's "uninstall programs" mechanism.

Allow Representatives to attempt to wake up Jump Clients provides a way to wake up a selected Jump Client by broadcasting Wake-on-LAN (WOL) packets through another Jump Client on the same network. Once a WOL is attempted, the option becomes unavailable for 30 seconds before a subsequent attempt can be made. WOL must be enabled on the target computer and its network for this function to work. The default gateway information of the Jump Client is used to determine if other Jump Clients reside on the same network. When sending a WOL packet, the user will have an advanced option to provide a password for WOL environments that require a secure WOL password.

Use screen state to detect Customer Presence sets how customer presence is determined. Customer presence is used when choosing whether to use the Customer Present Session Policy or the Customer Not Present Session Policy. If checked, the customer is determined to be present only if a user is logged in, the screen is not locked, and a screen saver is not running. If unchecked, the customer is considered present if a user is logged in, regardless of screen state.

Set whether ad-hoc Jump Clients pinned during a session should by default be active or passive.

The Passive Jump Client Port specifies which port a passive Jump Client will use to listen for a "wake up" command from the appliance. The default port is 5832. Ensure that firewall settings allow inbound traffic on this port for your hosts with passive Jump Clients. Once awake, Jump Clients always connect to the appliance on port 80 or 443 outbound.

Active vs. Passive Jump Clients

Jump Clients allow for one of two modes of behavior, active or passive. The default mode can be set from the Jump > Jump Clients page, and the mode can be switched from the Jump interface of the representative console.

A Jump Client in active mode maintains a persistent connection to the Bomgar Appliance, waiting for session requests. It sends statistics updates as frequently as once per minute, as defined in the Jump Client Settings on the Jump > Jump Clients page.

A passive Jump Client does not maintain a connection to the appliance but rather listens for connection requests. It sends statistics updates only once per day or upon manual check-in. By setting Jump Clients to passive mode, you can have a larger number of deployed Jump Clients without markedly increasing the appliance load.

In order to use a passive Jump Client, the appliance must be able to initiate contact with the computer on which the passive Jump Client is installed. This requirement may necessitate that you modify firewall rules to allow incoming connections to the target computer through the configured listen port. By default, this port is 5832; this can be modified from the Jump > Jump Clients page.

Passive mode may best be used on internal systems rather than external ones, although with correct firewall configurations, it may be used in either implementation. The following table presents key differences between the two modes.

Active and Passive Jump Clients
Active Jump Client Passive Jump Client

Maintains a persistent connection to the Bomgar Appliance.

Listens for a remote access request from the Bomgar Appliance.

Note: Some firewall configuration may be required.

Sends statistics to the Bomgar Appliance at regular intervals.

Sends statistics to the Bomgar Appliance once a day or upon manual check-in.

Enables remote access to any desktop operating system supported by Bomgar.

Enables remote access to any desktop operating system supported by Bomgar.

Number of installable clients is limited by your Bomgar Appliance model.

B200 B300 B400
Up to 1,000 Active Jump Clients Up to 10,000 Active Jump Clients Up to 25,000 Active Jump Clients

Bomgar Cloud supports up to 150 Active Jump Clients per license.

50,000 passive Jump Clients supported on all Bomgar Appliance models. Passive Jump Clients are not supported on Bomgar Cloud deployments.

If you need more passive Jump Clients, visit

Note: The maximum number of Jump Clients available to a Virtual Appliance is based on allocated resources. See the Virtual Appliance Sizing Guidelines at