Configure Jump Client Settings

Jump Client Schedules

To control when certain Jump Clients can be accessed, create Jump Client policies. View and edit existing Jump policies, or create a new policy by clicking Add New Jump Policy.


Jump Schedules :: Edit

Create a display name for this policy that will help you identify it when applying it to Jump Clients. Set a code name for integration purposes. If you do not set a code name, one will be created automatically. Add a description to help identify this policy.

You can choose to enable or disable this policy. If it is disabled, then any Jump Clients that use this policy can be accessed without time restrictions.

Set the time zone you want to use for this policy's schedule, and then add one or more schedule entries. For each schedule entry, enter the start day and time and the end day and time. This time window delimits when this Jump Client can be accessed.

If, for instance, the time is set to start at 8 am and end at 5 pm, a representative can start a session using this Jump Client at any time during this window but may continue to work past the set end time; he or she will not, however, be allowed to re-access this Jump Client after 5 pm. If stricter access control is required, check Force session to end when schedule does not permit access. This will force the support session to disconnect at the scheduled end time. In this case, the representative will receive recurring notifications 15 minutes prior to the automatic session end.

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.


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.

Allow simultaneous representative access to a single Jump Client provides a way for multiple representatives to gain simultaneous 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 representative 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. 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 Configuration > 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 Configuration > 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 Configuration > 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 5,000 Active Jump Clients Up to 10,000 Active Jump Clients


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

B200 B300 B400
Up to 1,000 Passive Jump Clients Up to 5,000 Passive Jump Clients Up to 10,000 Passive Jump Clients

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

Tip: Passive Jump Clients are designed to support a large number of Jump Clients within an internal network. Active Jump Clients are highly recommended if you do not control the remote network [e.g., customers' desktops] or if the remote network is unknown [e.g., laptops].