A Launcher (also referred to as a Launcher host, Launcher machine, or Launcher system) is a system that uses a connector to initiate remote connections with target machines. The Launcher also refers to the Windows machine on which the Login Enterprise Launcher software runs.

The Login Enterprise Launcher is used for receiving instructions from the Login Enterprise test scheduler to launch test sessions, the test sessions carry out the testing to produce metrics gathered by the test user, which represent real-life, load, or live production information and results that an actual user would experience.

The launcher acts as an endpoint, simulating what an actual user would do to connect to a published resource, also known as a target. This can make finding out issues as early as possible, such as if the launcher can't connect to a published resource; this could also be what an actual user would experience. You can view this alert in the Login Enterprise web interface and report it externally, i.e. by email.

Further, the launcher will retrieve round-trip-time latency counters between the launcher and the test target desktop; these statistics will be available in the Login Enterprise > Test results graphs.

Related terms and concepts

Some other related terms and concepts that you’ll find in this article include:

  • Account: a username/password pair used to trigger connections and identify connections once they start (usually an AD account).
  • Appliance: a Linux-based Login Enterprise control center.
  • Connector: a Login Enterprise software used to interact with a Connection Broker to launch a remote connection to a target desktop. Also, a Connector may relate to VMware connection and custom connections that Logine Enterprise supports. For more information on Connectors and connection options, see Connectors and Connection Configurations.
  • Target: an individual end-user machine where a Test will run.
  • Test: a collection of Application scripts that will perform a series of actions and take measurements as defined in those Application scripts. Tests also include taking other metrics outside the application scripts (workloads), such as Protocol latency, Logon times, EUX measurements, and Session Metrics.

For other terms and concepts, see the Login Enterprise Glossary.

How Launcher works

The Launcher initiates remote user login sessions whenever a Test defined in the Login Enterprise appliance calls for it. The Launcher software does not perform any of the testing functions or remote control. Rather, it simply triggers remote sessions so that a Test account can be logged into a target machine. The target machine is responsible for actually performing the Test actions (the Launcher informs the Login Enterprise appliance about session start time, which the appliance uses to calculate other things like total login time).

What happens when a Launcher starts

When the Launcher software starts, it is configured (through its appsettings.json file) to communicate with the Login Enterprise appliance that the installer was downloaded from. That config file contains both the URL of the Login Enterprise appliance and the API key for communicating with the Login Enterprise appliance. You could edit those settings after the Launcher is installed, to point to a different Login Enterprise appliance, but you cannot point a single Launcher at multiple Login Enterprise instances.

For system reliability, you should have the Launcher software start-up when the Launcher machine starts. That way, in the event of a host or data center failure, the Launcher will restart and reconnect to the appliance if its host reboots. The simplest way to do this is to define a service account for the Launcher host, have that service account set as console auto-login, and have the Launcher software executed as a login script. That way, even if the Launcher account logs out, it will immediately log back in and start its software. And since it’s a console session, the software will be allowed to continue running indefinitely. We encourage you to disable screen locking on the console of this machine for this user.

Initiating a session

When the Login Enterprise appliance wants to initiate a session, it checks the Test for the Launcher Group and Account Group, picks an available one from each, and sends a message to that Launcher. The Launcher receives the session information and Connector configuration and begins the process of trying to launch a login for the user through the configured Connector.

It determines whether the connection was successful or not by looking for specific events and return codes, and then alerts the Login Enterprise appliance. It will also report if the session terminates unexpectedly. The Target is responsible for reporting back to the Login Enterprise appliance that the session login is completed. All the Launcher can say is whether the process is still running. If the Target has not checked in with the appliance within 5 minutes (configurable), the Launcher will terminate the session and the appliance will mark it as failed.

Once the Target checks in, the appliance tells the Launcher and the launcher turns off that 5-minute timer and switches to simply monitoring the status of the remote session client’s process ID. It will report to the appliance if the session terminates itself. The appliance will tell the Launcher if the Target has reported completion and thus that the client is expected to terminate itself. So, between the appliance and the Launcher and the Engine, they know when a process starts, if it terminates unexpectedly, and when the termination is expected.

Launcher requirements

For the Launcher compatibility with operating systems, software and hardware requirements, see Login Enterprise Launcher requirements.

Downloading and installing a Launcher

To download and install the Launcher:

  1. Log in to your Login Enterprise with the launcher intended to be the host.
  2. In the Sidebar menu, navigate to Configuration > Launchers.

Frame 30.png

3. In Launchers, scroll down and find Download Launcher Setup.

4. In the bottom right, click Download file.

Frame 31.png

5. Once downloaded, extract the Launcher zip file.

6. Start the launcher installation by running the Setup.msi file, following the prompts.

The launcher will launch by default at the end of the installation.

Launcher menu window explained

When the launcher loads, pay attention to the Login Enterprise Launcher menu window:

Frame 39.png

Menu option Definition
Top bar Shows the Launcher version
Launcher name The launcher name defaults to the machine name where the launcher software is installed. If a specific name is required for a launcher, it should match the name of the machine.
Connections pane Shows active and historical test session connections and status
Right-side menu Shows connection information for selected connections
Open logs folder Shows deeper troubleshooting information, if needed
Bottom launcher connection status banner

If the banner is green, the connection to the Login Enterprise virtual appliance is successful.

The appliance hostname and the appliance version are at the right of the connection status banner.

Now the launcher will show in the Login Enterprise > Launchers. Note that the launcher will show dynamically. That is, if the launcher application is closed, it won't be visible in this tab any longer.

Frame 171.png

Launcher groups

To launch test sessions, you need to add Launchers to the Launcher Group.

Launcher Groups specify which Launchers should be used for a particular Test. Creating a Test requires at least one Launcher Group, so having at least one Launcher Group is a requirement. This is helpful when trying to logically divide launchers, for example, based on geographic location.

For large environments, creating or managing a large number of Launchers can be a manually-intensive process. To automate many operations, such as creating Launcher groups, adding Launchers to a Launcher Group, or assigning Launcher Groups to test, use the Public API, along with PowerShell.

For more information about the Public API, see Public API.

Creating a Launcher group

There are two ways to create a Launcher Group in Login Enterprise: through a Filter, or by Selection:

  • Filter lets you fill out the details and the launchers you want to add to the group. You can also use wildcards so you will not have to select several different launchers. Wildcards accepted include * and ?.
  • Selection lets you select launchers to add to the new group manually.

Note that if you add a Launcher to a Launcher Group by Selection, i.e. you choose it specifically and not by wildcard, and that Launcher goes offline, it will still be part of the Launcher Group. It will not show up in the Launchers list, and it will not be available for Tests, but if the Launcher comes back online, it will immediately be available in that Group and any Tests that include that Launcher Group. 

To create a group, in Launcher Groups, click the green "+", and select your method for grouping.

Frame 34.png

The following steps show how to add a launcher group via the Selection method:

  1. In Create a new selection group, give your group a name and, optionally, a description, then Next.

Frame 41.png

2. In the following window, click Show all launchers.

Frame 42.png

3. Select checkboxes next to the launchers you want to add to a group, then Save.

Frame 43.png

You have successfully created your Launcher group. These launchers are now able to successfully receive and execute new test connections to the target EUC stacks and platforms. Now you need to add launchers to a test.

Adding a Launcher to a Test

Launchers write a log file at %TEMP%\LoginEnterprise\Launcher\Logs. The log will be created as soon as the Launcher starts and will record successes and errors in its operations. The Launcher also displays a table in its window showing the tests that have been assigned to it since it started this current session. This list is kept in memory, so it is lost on every program restart.

To add a launcher to a test:

  1. In the Sidebar menu, navigate to Configuration > Manage tests, and select the test, for example, Continuous test.
  2. Click on the particular test instance, scroll down, and click Settings.
  3. In Settings > Launchers, select the checkbox with a launcher you want to add to the test.
  4. Click Save to apply the changes.

Frame 45.png

5. Go back to the Continuous Tests page.

6. Next to each test instance, in Schedule, select the toggle so that it’s turned on.

Frame 46.png

When the tests are turned on, you can now:

a. See the target session is being connected to in a console window:

Frame 47.png

b. The launcher application shows the connection was made, and the connection information in the launcher is visible.

Frame 54.png

c. You can see the connection sessions in the Launchers > Sessions.

Frame 48.png

When this particular test ends, it will start a new test via the launcher application. The launcher operation is autonomous and needs no human intervention.

Adding Launchers to Locations

The Launchers can be added to defined locations. This is to more closely represent successful connections and latency that real-life users would experience in, for example, an office branch. Having a launcher set up in each location needing to be monitored is a best practice. However, if you narrow down your selection to one location that’s not connecting to targets successfully, targeted troubleshooting can occur.

In a Load test scenario, the best practice ratio for simultaneous test connections per launcher is 30 to 1. So, if running a 100-user load test, you need 4 launcher hosts.

If launchers are attached to configured locations (see the screenshot below) when a Continuous test type is in progress, these launchers will be visible in the map view.

Frame 49.png

Observing Launchers and sessions in map view

  1. In the Sidebar menu, navigate to Dashboard.
  2. Click on the running test.
  3. In View by, select the map view.

Frame 50.png

Now, you can view the launcher location plotted on the world map. The hoverable tooltip shows connection and test successes and failures.

Frame 51.png

Checking a Launcher status

The system requires a minimum of one Launcher for any connections other than the Desktop Mode. The Launcher will also need the relevant connection client installed.

Launcher software should be on the same version as the Login Enterprise appliance. After you upgrade the appliance, always remember to upgrade each Launcher. If a Launcher is at a lower version, you will see a warning next to a particular launcher in the Launchers list.

If the major version number doesn’t match the launcher host versus the Login Enterprise appliance, that launcher won’t launch sessions at all and the warning message will be different. That is, a version 4.10 launcher won’t launch sessions from a 5.0 appliance version.

Frame 52.png

In this scenario, perform the upgrade by reinstalling the Launcher using a newly downloaded package. The flow is the same as for running the Setup.msi file during the initial launcher installation.

After the updated installation and this launcher is running, the Launchers page should no longer show the warning.

Tips and tricks

  • Putting the launcher shortcut in the launcher host's startup folder can make getting the launcher starting easier in case the launcher needs to be restarted.
  • Pinning the launcher to the Windows taskbar can make it easier to start the launcher application if it's ever closed.
  • The launcher can be installed over a network (see Silent installation). This lets you deploy multiple launchers easily.

Silent installation

To facilitate the deployment and update processes, you can use the command-line functions for the Launcher installation.

To run the MSI file silently, use the following parameters (make sure to replace the URL and the secret):

msiexec /I "\\fileserver\share\Setup.msi"/qb! serverurl= secret=E0733F0B555035C7E377CA8797530855770141C1

Copy the secret from the Download Launcher Setup > Launcher secret:

Frame 33.png

By utilizing silent installation of the Launchers, administrators can streamline the deployment process, reduce the potential for human error, and ensure consistent configurations across all deployed systems.

Additional resources