Jump Clients: Manage Settings and Install Jump Clients for Unattended Access
The Mass Deployment Wizard enables administrators and privileged representatives to deploy Jump Clients to one or more remote computers for later unattended access.
From the dropdown, select whether to pin the Jump Client to your personal queue, to a team queue, or to the general queue. Pinning to your personal queue means that only you can access this remote computer through its Jump Client.
Select the Public Portal through which this Jump Client should connect. If a session policy is assigned to this public portal, that policy may affect the permissions allowed in sessions started through this Jump Client.
You may apply a Jump Policy to this Jump Client. Jump policies are configured below and determine the times during which a representative can access this Jump Client. If no Jump policy is applied, this Jump Client can be accessed at any time.
Adding a Group Name helps to organize your Jump Clients into categories within the representative console.
Set the Connection Type to Active or Passive for the Jump Clients being deployed.
If you have one or more Jumpoints set up as proxies, you can select a Jumpoint to proxy these Jump Client connections. That way, if these Jump Clients are installed on computers without native internet connections, they can use the Jumpoint to connect back to your Bomgar Appliance. The Jump Clients must be installed on the same network as the Jumpoint selected to proxy the connections.
Add Comments, which can be helpful in searching for and identifying remote computers. Note that all Jump Clients deployed via this installer will have the same comments set initially
The installer will remain usable only as long as specified by the This Installer is Valid For dropdown. If someone should attempt to run the Jump Client installer after this time, installation will fail, and a new Jump Client installer will have to be created. This time can be set for anywhere from 10 minutes to 1 year. This time does NOT affect how long the Jump Client remains active.
If Attempt an Elevated Install if the Client Supports It is selected, the installer will attempt to run with administrative rights, installing the Jump Client as a system service. If the elevated installation attempt is unsuccessful, or if this option is deselected, the installer will run with user rights, installing the Jump Client as an application. This option applies only to Windows and Mac operating systems.
Note: For Windows and Mac computers, a Jump Client pinned in user mode is available only when that user is logged in. In contrast, a Jump Client pinned in service mode, with elevated rights, will allow that system to always be available, regardless of which user is logged in.
If Prompt for Elevation Credentials if Needed is selected, the installer will prompt the user to enter administrative credentials if the system requires that these credentials be independently provided; otherwise, it will install the Jump Client with user rights. This applies only if an elevated install is being attempted.
By selecting Start Customer Client Minimized When Session Is Started, the customer client will not take focus and will remain minimized in the taskbar or dock when a session is started through one of these Jump Clients.
You can also set a Password for these Jump Clients. If a password is set, this password must be provided to modify or use any one of these Jump Clients.
Once you click
For system administrators who need to push out the Jump Client installer to a large number of systems, the Windows executable, Windows MSI, Linux
|Command Line Parameter||Value||Description|
|--install-dir||<directory_path>||Specifies a new writable directory under which to install the Jump Client. This is supported only on Windows and Linux. When defining a custom install directory, ensure that the directory you are creating does not already exist and is in a location that can be written to.|
|If override is allowed, this command line parameter overrides the pin location specified in the Mass Deployment Wizard.|
|--jc-public-site-address||<public-site-address-hostname>||If override is allowed, this command line parameter associates the Jump Client with the public portal which has the given hostname as a site address. If no public portal has the given hostname as a site address, then the Jump Client will revert to using the default public site.|
|--jc-session-policy-present||<session-policy-code-name>||If override is allowed, this command line parameter sets the Jump Client's session policy that controls the permission policy during a support session if the customer is present at the console.|
|--jc-session-policy-not-present||<session-policy-code-name>||If override is allowed, this command line parameter sets the Jump Client's session policy that controls the permission policy during a support session if the customer is not present at the console.|
|--jc-jump-policy||<jump-policy-code-name>||If override is allowed, this command line parameter sets the Jump Policy that controls how users are allowed to Jump to the Jump Client.|
|--jc-group||<group-name>||If override is allowed, this command line parameter sets the Jump Client's group name.|
|--jc-comments||<comments ... >||If override is allowed, this command line parameter sets the Jump Client's comments.|
Note: When deploying an MSI installer on Windows using an msiexec command, the above parameters can be specified by:
- Removing leading dashes (-)
- Converting remaining dashes to underscore (_)
- Assigning a value using an equals sign (=)
msiexec /i bomgar-scc-win32.msi KEY_INFO=w0dc3056g7ff8d1j68ee6wi6dhwzfefggyezh7c40jc90 jc_location=team:general jc_group=servers
Note that, unlike the representative console, Jump Clients installed from an MSI do auto-update.
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.
Create a display name for this policy that will help you identify it when applying it to Jump Clients. Also create 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.
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.
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. 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.