Search

Connectors and connection configuration

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, the Login Enterprise offers 6 Connector types:

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:

In the 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.

Frame 95.png

Citrix Storefront

In the 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.

Frame 94.png

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 the 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.

Frame 92.png

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).

Frame 91.png


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.

Frame 90.png

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 the 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. 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.

Frame 93.png

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

Frame 252.png

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

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. 

Frame 253.png

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 idea is that the machine will auto-start / login and repeat the same progress. 

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 for 9999 times using the "Repeat all steps above" function.

Frame 254.png

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 it is being crossed. 

Frame 255.png

Application Testing

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. 

Frame 256.png

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

Frame 257.png

Logon App

To configure the Logon App for Desktop situations, see the 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 the Universal Web Connector.

In the 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.
  • Accounts: Allows selection from previously configured account groups or all accounts.
  • Launchers: Enables selection from previously configured launcher groups or all launchers.

Frame 96.png

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.

Frame 537.png

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.

Frame 538.png

You need to update your Launchers to use saved custom field values with custom connectors. This ensures that the latest custom field values are correctly integrated and utilized. For more information, see Updating Launchers.

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}"

Frame 539.png

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 with custom fields

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.

Additional resources

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