Configuring Connectors and Connections

Overview

Login Enterprise connectors are used for remotely initiating sessions to published applications and desktops across a variety of technologies, including Citrix Virtual Apps and Desktops (CVAD), Citrix Cloud, Microsoft Remote Desktop Services, Microsoft Azure Virtual Desktop, Microsoft Windows 365, and VMware Horizon.

Connectors are selected and configured as part of a test configuration and come in 3 distinct types: Standard Connectors, Desktop Connectors, and Custom Connectors.

Currently, Login Enterprise offers 6 Connector types:

• Citrix Netscaler 12.1 and 13.0

• Citrix Storefront

• Microsoft RDS

• VMware Horizon View

• Desktop Connection

• Custom Connector

Review the parameters you must specify to configure a connector for your test. The parameters supply the details of how to interact with the target environment. These required parameters are the same regardless of test type, so once you have configured a particular connector for one type of test, the configuration settings can be used for any other test or test type.

If you haven't created a test, see, for example, how to create a Load Test.

Benefits of Using Connectors

• Seamless integration: The Login Enterprise appliance offers pre-configured Connectors for leading platforms such as Citrix Netscaler 12.1, Citrix Netscaler 13.0, Citrix Storefront, Microsoft RDS, and VMware Horizon View. This ensures seamless integration, simplifying remote access setup.

• Customization options: Organizations can tailor configurations with the Custom Connector feature, adapting settings to specific needs while maintaining simplicity.

• Optimized user experience: Users benefit from optimized remote desktop experiences, accessing applications and desktops effortlessly through streamlined integration with industry-standard platforms.

• Centralized management: Administrators can efficiently manage and monitor Connectors from a unified interface, simplifying remote access management and troubleshooting processes.

• Scalability and compatibility: With support for diverse Connectors, the Login Enterprise appliance scales easily to accommodate changing IT environments while ensuring compatibility with evolving technology landscapes.

Citrix Netscaler 12.1 and 13.0

For the two Citrix clients, we interact with their web interfaces to identify and select the desired resource from the supplied URL. That will result in an ICA file, which we then pass to Citrix\ICA Client\wfcrun32.exe to initiate the actual remote session.

The Citrix Netscaler connector exclusively supports nFactor authentication and is currently compatible only with forms-based authentication factors, such as LDAP. For configuring nFactor and understanding the requirements, refer to the following links:

• nFactor authentication with NetScaler Unified Gateway

• nFactor Authentication – NetScaler Gateway 12 / Citrix Gateway 12.1

• nFactor Authentication – Citrix Gateway 13

In Login Enterprise, the Citrix Netscaler connector supports the following parameters:

• Netscaler URL: Specifies the Netscaler URL.

• Resource: Defines the resource name visible to end users upon logging into StoreFront.

• Display Configuration: Offers options for full-screen display or custom resolution settings.

• Accounts: Allows selection from previously configured account groups or all accounts.

• Launchers: Provides the option to choose from previously configured launcher groups or all launchers.

Citrix Storefront

In Login Enterprise, the Citrix Storefront connector supports the following parameters:

• Server URL: Specifies the Store URL (not the StoreWeb URL). Refer to the provided screenshot as an example.

• Resource: Specifies the resource name visible to end users upon logging into StoreFront.

• Display Configuration: Offers options for full-screen display or custom resolution settings.

• Accounts: Allows selection from previously configured account groups or all accounts.

• Launchers: Provides the option to choose from previously configured launcher groups or all launchers.

Seamless Mode for Citrix Published Apps

Seamless Mode supports published applications delivered through Citrix virtualization platforms. This mode allows for more accurate performance testing that aligns with Citrix’s best practices. When enabled, it launches apps in seamless mode instead of the Login Enterprise default windowed mode (TWIMode=Off).

This configuration is especially useful for organizations running newer Citrix LTSR versions where ShellBridge or other seamless mode mechanisms affect application behavior and performance. Running in windowed mode may no longer reflect the typical user experience in these environments.

Seamless Mode is only available when using Launcher version 6.2 or later. Ensure your Launcher is up to date before enabling this setting.

If the Launcher version is not supported, this option will be ignored, and the Test will run in windowed mode.

Benefits of Seamless Mode

• Reflects Citrix’s recommended configuration for published apps.

• Improves the accuracy of performance metrics.

• Enhances the realism of Test scenarios for end-user experience.

How to Enable Seamless Mode

1. Open the connector configuration for StoreFront and/or NetScaler.

2. Locate the Seamless Mode toggle.

3. Enable Seamless Mode to allow published apps to launch outside a fixed window.

4. Save the configuration.

If Seamless Mode is not enabled, Login Enterprise defaults to windowed mode (TWIMode=Off) for compatibility.

Behavior and Compatibility

• Enabling Seamless Mode allows multiple published app sessions to be tracked reliably using ProcessId (instead of relying on window titles).

• Session lifecycle behavior (start, monitor, terminate) is consistent in both seamless and windowed modes.

• If Seamless Mode is disabled, apps will behave as they did in previous versions.

• Upgrading to this version does not change existing connector behavior unless Seamless Mode is explicitly enabled.

• Enabling Seamless Mode may affect testing results, such as changes in the EUX score.

• Seamless Mode requires the app window to stay in focus. When multiple published app sessions are running simultaneously, they may compete for focus. In some cases, this can cause interference between sessions, and some applications may fail, depending on the application itself and how the script is written.

Best Practices

• Use Seamless Mode when testing Citrix-published apps.

• Refer to in-product tooltips for guidance on when to enable Seamless Mode.

• Always confirm that your Launcher version supports this feature before use.

Microsoft RDS

For the Microsoft Remote Desktop Session (RDS), we construct an RDS file that contains the target server, resource information, and authentication information, then we execute MSTSC.exe to launch it and monitor the resulting process.

In Login Enterprise, the Microsoft RDS connector supports the following parameters:

• RDS Broker / RDP Host: Allows connection to an RDS farm or a single desktop.

• Resource: Optionally specifies the name of the desktop pool when the RDS broker is configured.

• RDS Gateway: Optionally configures RDS Gateway information if applicable.

• Suppress Certificate Warnings: Enables ignoring certificate warnings for untrusted hosts.

• Display Configuration: Supports fullscreen or custom resolution settings.

• Accounts: Provides the option to choose from previously configured account groups or all accounts.

• Launchers: Offers selection from previously configured launcher groups or all launchers.

Multi-Host Configurations

Multi-host configurations in the Microsoft RDS are crucial for achieving various objectives such as high availability, load balancing, scalability, and fault tolerance. Unlike using the RDS Broker for load balancing, the multi-host configuration allows organizations to specify hosts or IP addresses directly, bypassing load balancing. This means that virtual users can be directed to specific hosts, such as host1, host2, and so on, without going through the Broker's load-balancing mechanism.

This approach offers flexibility, as you can choose to test only a subset of servers within the RDS Farm. For instance, if you want to test only a few servers (e.g., host1 to host5) instead of all servers on the farm, you can utilize the Multi-host option. By doing so, you can ensure that virtual users are directed only to the specified hosts, without undergoing load balancing by the Broker. This strategy helps optimize testing scenarios and ensures efficient resource utilization.

To add Multi-host configurations:

1. When creating or modifying your Microsoft RDS environment, click Multi-Host Configs on the right (The Multiple-server hosts window will open).

2. In the Multiple server hosts table, provide the details of the RDS servers you wish to have tested. You can also copy and paste a list of machines here for easy entry. Please note that we will connect to your machines in a round-robin style. That is, we will connect to machine 1 first, then proceed to machine 2, and so on in a sequential fashion.

3. Click Save to apply the changes.

VMware Horizon View

For the VMware Horizon View connector, we call the installed vmware-view.exe executable with the appropriate resource, server, and authentication parameters, and monitor the resulting process. Below is a breakdown of the parameters used:

• Resource: This parameter specifies the resource (virtual desktop or application) that the user wants to access.

• Server: This parameter specifies the server address or hostname of the VMware Horizon View server.

• Authentication Parameters: These parameters include credentials or authentication tokens required to authenticate the user and establish a secure connection.

If your VMware View client is not included in your System Path variable, you need to provide the explicit path. Typically, the path is as follows:

• For 64-bit versions of VMware View client: C:\Program Files\VMware\VMware Horizon View Client\vmware-view.exe

• For 32-bit versions of VMware View client: C:\Program Files (x86)\VMware\VMware Horizon View Client\vmware-view.exe

Ensure to verify the installation directory on your system and adjust the path accordingly when specifying it.

In Login Enterprise, the VMware Horizon View connector supports the following parameters:

• Server URL: Specifies the View Server for the RDS connection.

• Resource: Defines the resource name visible to end users.

• Connection command line: Contains the path and parameters used by the VMware View executable. See the connection command line table for more information. The example provided below is the default command line from the Login Enterprise.

• Accounts: Allows selection from previously configured account groups or all accounts.

• Launchers: Enables selection from previously configured launcher groups or all launchers.

Additionally, you can incorporate all accepted parameters for the Horizon View Client. For further details, see the VMware View Connector Reference.

Connection command line

The following variables are commonly used in the connection command line for the VMware Horizon View connector. The available connection command line options are controlled by the VMware client itself. If you need to set additional options, see the Omnissa documentation.

Desktop Connection

The Desktop connector lets you trigger a Test run without building and utilizing a remote-access system. Instead of having a system that triggers a login for a properly configured account, you as a user, run the appropriate program by hand. When you select a Desktop connector, there are no configuration parameters. The Test definition lets you simply copy a command (LoginPI.Login.exe <URL> <TestID>) and paste it into your existing session to download and execute the Test.

The Desktop connection method is highly beneficial for initial testing and can also prove invaluable in unique situations where creating a remote session is not feasible. Instead, you can use existing machines with active interactive sessions to trigger the Tests.

To set the connector in the environment (Continuous Testing or Application Testing), you need three values:

• Environment Name

• Connector (Desktop)

• Description

Once configured, you might notice the lack of other configurations as seen in the different connectors. This is normal as we start the process from the machine; there is no remote connection required. You can now configure the environment as usual. 

Continuous Testing Scenario

There are other differences in the connection setup of the Desktop Connection with other remoting configurations. With Continuous Testing, the schedule has changed from a detailed overview to a simple enable or disable button. Enabling the schedule will allow the desktop machine to start. If it is disabled, no sessions can be initiated. 

The Actions list is almost the same as the Continuous Testing that uses a remote connection. There is a single difference. Instead of logging off at the end, we have the Restart on complete. The "Restart on Complete" will automatically restart the machine. Depending on the configuration, the machine will auto-start / login and repeat the same process. 

If you do not want the machine to reboot after each run, you can decide if you want to run the process once or repeat it x number of times. We have seen situations where customers want to repeat the process 9999 times using the "Repeat all steps above" function.

Notifications are also different, as you can see, there are no results concerning the connection of the environment. There are no Logon Failures, Logon Measurements, and Latency measurements done. Only application failures are measured by default. 

You have the option, similar to other situations, to add specific thresholds you wish to be notified of when they are crossed. 

Application Testing Scenario

Application testing configuration differs from Continuous Testing and Application Testing done with a remoting protocol. Again, the function "Restart on Complete" is added to the Action list. You can decide to reboot the machine when it is done. 

The thresholds are configurable as normal, but without the Login and Latency measurements.

Logon App

To configure the Logon App for Desktop situations, see Configuring Logon Components.

Custom Connector

The Custom Connector provides a flexible solution for defining commands with parameter substitution, allowing the Launcher to execute various remote connection software. This versatility enables you to trigger connections using executable clients on the Launcher machine.

When none of the predefined connector options meet your requirements, the Custom Connector offers a tailored approach. For example, if your setup requires compatibility with a specific version of NetScaler not supported by our out-of-the-box connectors, the Custom Connector can accommodate this need. While third-party scripts are also viable, it's worth noting that the Custom Connector is most often used seamlessly with the Universal Web Connector (UWC). For guidance on using the UWC with the Custom Connector, see Configuring the Universal Web Connector.

In Login Enterprise, the Custom Connector supports the following parameters:

• Host: Specifies the connection server.

• Resource: Defines the resource name visible to end users.

• Connection command line: Specifies the command line executed on the Launcher machine to initiate a session. See the connection command line table for details.

• Accounts: Allows selection from previously configured account groups or all accounts.

• Launchers: Enables selection from previously configured launcher groups or all launchers.

Connection command line

The following variables are used in the connection command line for the custom connector.

Custom Fields

You can add custom fields during account configuration and use them with custom connectors, just like you would with email, username, domain, password, and other standard fields. You can define up to five custom fields with editable values, but their names remain fixed.

Benefits of Using Custom Fields

Custom fields offer several practical advantages, especially when used with the Universal Web Connector:

• Enhanced customization: You can store extra information, like additional usernames or authentication tokens, making your setup more specific to your needs.

• Improved flexibility: Custom fields let you pass values in command lines, so you can easily adapt to different configurations without changing core settings.

• Streamlined testing: You can quickly adjust field values for testing. This makes your testing process more efficient and thorough.

• Seamless integration: Custom fields work well with custom connectors and Swagger, helping you manage extra data smoothly across different tools.

• Increased efficiency: Updating custom field values through Launchers and command lines reduces manual errors and saves time.

Setting Custom Field Values

Custom field values can be set when creating a new account. To edit these values later, use the account editing form. Click the “pencil” icon in each row to open this form, which will display the fields with their current values pre-populated.

If any custom fields have been saved, the panel automatically expands to show their values. Custom fields can hold various types of values, including a single digit, random text, or an authentication token. They accept any string up to 1,024 characters in length.

To use saved custom field values with custom connectors, you need to update your Launchers. This ensures that the latest custom field values are correctly integrated and utilized.

Adding Custom Fields as Arguments

Once the Launchers are updated, you can include custom fields as arguments when starting a new custom connector process. For example, you might pass a custom field value like this:

CustomConnector.exe --custom1 "{custom1}"

Modifying Command Line Values

You can also modify the command line to source values for username, email, domain, and other fields from custom fields instead of their dedicated fields. For example:

CustomConnector.exe --username "{username}" --password "{password}" --domain "{domain}"--resource "{resource}" --email "{email}" 

Can be updated to:

CustomConnector.exe --username "{custom1}"--password "{custom2}" --domain "{custom3}" --resource "{custom4}" --email "{custom5}"

This flexibility allows you to use custom field values in various configurations and testing scenarios.

Other Customization Options

In some cases, you might need to test with an additional username, password, or authentication token. Custom fields provide this additional level of customization.

Custom fields can also be added when creating accounts in Swagger (API v5 and v6). Since this is optional, the property can be set to null or omitted entirely.

Custom Events for Connectors and Launchers

You can emit custom events directly from connector scripts and view them alongside standard Launcher events in the Events feed. This helps you trace and diagnose custom connector behavior without relying on external logs.

What Are Custom Events?

Custom events are user-defined messages sent from your connector implementation during a Test. They appear in the Events section of the Login Enterprise UI and include:

• A timestamp

• A session ID

• A message (custom, free-form text)

This functionality lets you track key steps, issues, or decisions made during the Test session, especially helpful when using custom logic or workflows in your connector.

When to Use Custom Events

Use custom events to:

• Report internal states, checkpoints, or branching logic

• Flag warnings or known edge conditions in real time

• Log custom errors tied to a specific test session

Custom events are purely informational and do not affect test execution or scoring.

Viewing Custom Events

Custom events appear in:

• The Events tab of a test run, alongside standard events like SessionStart and SessionEnd

• Launcher logs, for local debugging

• The Events section of the Appliance UI, where they can be identified by their message text.

These events follow the same retry and buffering logic as standard events, so they won't be lost during temporary connection issues.

Enabling Custom Events

To use custom events:

1. Ensure you are using Login Enterprise v6.2, which supports this feature.

2. Generate a Configuration-level Public API system access token (see Adding a System Access Token).

3. Include the Session ID in your Custom Connector invocation (refer to Passing Session ID to the Custom Connector).

No additional configuration is required on the Appliance or Launcher side.

Implementation

Custom Events are implemented as an API call (see Using the Public API). You must provide the User Session ID of the session you want to attach your event to, and a “description” field as a JSON payload.

The API is a REST method at /v8-preview/user-sessions/{sessionId}/events. It accepts POST invocations only, and expects a simple payload:

{
"description": "Event message content"
}

For instance, to post a Custom Event for a specific User Session from PowerShell, this command will work (as will the corresponding Invoke-RestMethod):

Invoke-WebRequest -Method POST `
  -uri https://login-ent.loginvsi.com/publicApi/v8-preview/user-sessions/$sessionId/events `
  -H @{"accept" = "*/*"; "Content-Type" = "application/json"
  "Authorization" = "Bearer secret-api-key"} `
  -body '{ "description": "This is a custom event" }'

Note that you may need to tell PowerShell to ignore certificate errors if you are using a self-signed certificate (see this Public API example for how to do that).

To make this call from a Login Enterprise Stand-Alone Engine script, use this code:

using System.Net;

string appliance = "appliance-hostname";
string apiKey = "generated-API-key";
var client = new WebClient();
client.Headers.Add("accept", "*/*");
client.Headers.Add("Content-Type", "application/json");
client.Headers.Add("Authorization", $"Bearer {apiKey}");
var response = client.UploadString($"https://{appliance}/publicApi/v8-preview/user-sessions/{sessionId}/events", "{ \"description\": \"This is a custom event\" }");

To make this call from a Linux server or Linux-like environment, you can use this curl:

curl -X POST https://login-ent.loginvsi.com/publicApi/v8-preview/user-sessions/$sessionid/events -H 'accept: */*' -H 'Content-Type: application/json' -H "Authorization: Bearer $key" -d '{ "description": "This is a custom event" }'

REST calls are standard, so you can implement this in any language you need to.

Notes and Considerations

• Custom events do not support attachments such as screenshots or logs.

• The feature is optional and backward compatible. If your environment doesn’t use a supported Launcher version, the functionality will not be available.

• Use descriptive but concise messages. Overuse of verbose or excessive events may clutter logs.

• Your Custom Connector must already have the address for the Login Enterprise Appliance and the API Secret Key built into the code, or you will need to add them as Custom Fields for all of your accounts, and add the Custom Fields to your command-line invocation.

How Custom Events for Connectors and Launchers and Passing Session ID to the Custom Connector work together:

Pass {sessionId} in your Custom Connector command line; the Launcher substitutes the real session ID at runtime, allowing the connector to POST {"description":"..."} to https://<appliance-FQDN>/publicApi/v8-preview/user-sessions/{sessionId}/events so events appear attached to that test session in the Appliance Events feed.

Passing Session ID to the Custom Connector

Before Login Enterprise v.6.2, the sessionId was only available inside the Launcher process. This enhancement ensures that the sessionId is passed to the connector during its initialization.

How It Works

When you define a Custom Connector, there is a new variable available for command-line substitution: {sessionId}. Add it to your custom connector invocation, and you can use that parameter however you need to. You must make sure your custom connector is expecting and will accept this new parameter.

When the Launcher initiates a custom connector on the Appliance, it supplies the current sessionId. This allows the connector to tag any custom events or log messages with the correct session so that they appear in the appropriate place in the Appliance UI.

Key Details

• Accuracy: The sessionId is accurate and deterministic, ensuring that any custom events posted by the connector are matched to the correct session in the event list.

• Non‑breaking: Existing custom connectors that do not use the sessionId continue to function without any changes.

Example Connector Script

Here is a simple example script showing how to pass the session ID to a PowerShell script and use that script to post Custom Events. To use this script as a Custom Connector, set your Connection Command Line field to this:

powershell.exe -c C:\LoginVSI\Scripts\connector.ps1 {host} "{username}" "{password}" "{domain}" "{resource}" "{email}" {sessionId}

The script simply receives these parameters, posts a custom event reporting the parameters passed, sleeps for 30 seconds, and posts a closing custom event. You would place your actual commands to perform the login in place of the sleep 30.

[CmdletBinding()]
param(
[string]$hostname,
[string]$username,
[string]$password,
[string]$domain,
[string]$resource,
[string]$email,
[string]$sessionid
)

$appliance = "your-appliance-FQDN"
$apikey = "your API secret key"

Invoke-WebRequest -Method POST `
-uri https://$appliance/publicApi/v8-preview/user-sessions/$sessionId/events `
-H @{"accept" = "*/*"; "Content-Type" = "application/json"
"Authorization" = "Bearer $apikey"} `
-body "{ ""description"": ""Host $hostname; Username $username@$domain; Resource $resource; Email $email; SessionID $sessionId"" }"

# perform the actual login process

sleep 30

Invoke-WebRequest -Method POST `
-uri https://$appliance/publicApi/v8-preview/user-sessions/$sessionId/events `
-H @{"accept" = "*/*"; "Content-Type" = "application/json"
"Authorization" = "Bearer $apikey"} `
-body '{ "description": "This is a custom event injected at the end of the test" }'

Additional Resources

• For information on Launchers overview and best practices, see Launchers Overview and Best Practices.

• To learn about the Login Enterprise Windows Launcher setup, configuration, maintenance, and more, see Configuring the Windows Launcher. 

• To learn about the Universal Web Connector, see Configuring the Universal Web Connector.

• To see an example of a Custom Connector implemented as a Stand-Alone Engine script, see Setting Up the Win 365 Connector.

If you have questions or need additional information on specific Connectors configurations or scripts, feel free to contact our support at support@loginvsi.com.