The Scenario

The following procedure guides you through a Connection Broker setup that satisfies the following scenario.

We want to know	Here’s what you have
What type of desktops are you managing?	Virtual machines hosted in VMware vSphere and managed by vCenter Server.
What type of desktop pool structure do you want to use?	One pool that contains the desktops running a Linux operating system that belong to the QA group, as defined by having a name that begins with “qst”, and that have an installed NoMachine NX Server, as defined by having a name containing “nx”.
Is this a persistent or non-persistent pool, i.e., should the user be permanently assigned to the desktop after they log in the first time?	Once a user is assigned to a particular desktop, never release the desktop to its pool; the desktop is persistent. If the user disconnects from their VM without logging out, keep their session active for one hour. After one hour, forcefully log the user out.
What system do your users authenticate against?	OpenLDAP
What display protocol will you use?	NoMachine NX
How is the power state of the machine managed?	Power off the VM 15 minutes after the user logs out.
What client device do users have?	Leostream Connect

The following procedure assumes that you previously completed the following steps. Please, see the referenced section of the Leostream documentation for more information on these procedures.

1. The Connection Broker virtual appliance is installed in your virtualization layer (see the Leostream Installation Guide)

2. You have logged into the Connection Broker Administrator Web interface and entered your license key (See “Entering Your License Key” in the Connection Broker Administrator’s Guide)

3. You have configured your Connection Broker network settings (see “Setting Network Configuration and Connection Broker VIP” in the Connection Broker Administrator’s Guide)

Setup

Before setting up the Connection Broker, the following other components must be installed and configured.

Local User Setup

This example assumes that local user accounts already exist on the Linux VMs for all users that will log into these Linux VMs via the Leostream Connection Broker. These local users must have the same user name and password as used to log into Leostream Connect.

Leostream Agent Installation

In order for the Connection Broker to perform actions on the remote desktop when the user disconnects, you must install the Leostream Agent on the remote desktop. For Linux VMs, install the Java version of the Leostream Agent. For information on installing the Java version of the Leostream Agent on Linux desktops, consult the Leostream Installation Guide.

After the Leostream Agent is installed, ensure that it points to your Connection Broker by inspecting the /etc/leostreamagent.conf file. This file should contain the following line:

ConnectionBrokerAddress=cb_address

where cb_address is the IP address or fully qualified domain name of your Connection Broker. If the /etc/leostreamagent.conf file does not point to your Connection Broker, edit and save the file, then restart the Leostream Agent using the following command:

service leostreamagentd restart

NoMachine NX Installation

To prepare the VMs and clients for use with NoMachine NX:

1. Install the NX Client, NX Node, and NX Server packages on the Linux VMs.
2. Install the NX Client on the client machine.

For NoMachine installation instructions, go to http://www.nomachine.com/installation.php.

Refer to the NoMachine Documents Web page for complete information on installing and configuring NX Servers and NX Clients.

Leostream Client Installation

In addition to the NX client, install the Windows version or Java version of the Leostream Connect client on the client devices. See the Leostream Installation Guide for the appropriate instructions.

Back to top

---

Procedure

Step 1: Registering your virtual machines with the Connection Broker

In order for the Connection Broker to assign virtual machines and applications to end users, you must first tell the Connection Broker about the external systems that host the VMs or publish the applications.

Leostream defines centers as the external systems that inform the Connection Broker about desktops, applications, and other resources (such printers, and Teradici PC-over-IP host devices) that are available for assignment to end users.

In this scenario, virtual machines are hosted in VMware vSphere, and vSphere is managed by VMware vCenter Server. For the Connection Broker to manage these machines, define a center for the vCenter Server, as follows.

1. Go to the > Resources > Centers page, shown in the following figure.

2. Click the Add Center link, as shown in the following figure.

3. The Add Center form opens. Fill in the form with the appropriate information for your center, for this example, the following form creates a center for VMware vCenter Server:

4. Click Save. The > Resources > Centers page shows the new center, and indicates that the center is refreshing, as shown in the following figure.

5. To view the desktops that the Connection Broker registered from the center, go to the > Resources > Desktops page, shown in the following figure.

Back to top

---

Step 2: Grouping desktops into pools

After you create your centers and the Connection Broker registers all your desktops, you can combine the desktops into logical groups, or pools. Use pools to create sets of desktops that have similar attributes, or come from the same center. Creating pools is optional, but provides convenience and flexibility when configuring your Connection Broker.

The Leostream Connection Broker defines a pool as any group of desktops or applications.

1. To view the existing pools, go to the > Resources > Pools page, show in the following figure.

The Connection Broker provides four default pools:

• The All Desktops pool contains all desktops that are registered with the Connection Broker, including VMs, Terminal Server sessions, and physical desktops. This pool does not contain desktops published in a Citrix XenApp farm.

• The All Windows Desktops pool is a subset of the All Desktops pool. This pool contains only the desktops that are running a Microsoft Windows operating system.

• The All Linux Desktops pool is a subset of the All Desktops pool. This pool contains only the desktops that are running a Linux operating system.

• The All Applications pool contains all applications and desktops published in a Citrix XenApp farm.

2. To create a new pool, click the Create Pool link, as shown in the following figure.

3. The Create Pool form opens. Fill in the form to create a pool of desktops with similar attributes.

For example, the following form creates a pool named Linux NX Desktops that is the subset of the All Linux Desktops pool. All desktops in this pool must have a name that begins with the string “qst” and contains the string “nx”, which is the convention used in this example to denote all desktops used by QA and running an NX Server.

4. Click Save. The > Resources > Pools page shows the new pool, indented under its parent pool, as shown in the following figure.

Back to top

---

Step 3: Creating Protocol, Power Control, and Release Plans

After you separate your desktops into pools, define the behaviors you want to assign to the desktops in those pools. To perform this step, ask yourself the following questions.

• What display protocols do I want the user to use when connecting to their desktops?

• How do I want to manage the power state of each desktop, for example, should it be turned off when the user logs out?

• How long do I want my user to be able to use a particular desktop, and claim it for their use? For example, if the user logs out, should they remain assigned to that desktop, or should another user be able to log into that desktop?

The Leostream Connection Broker defines a plan as a set of behaviors that can be applied to any number of pools. This step describes three types of plans: 1) Protocol, 2) Release, and 3) Power Control.

Creating Protocol Plans

Protocol plans determine which display protocol the Connection Broker chooses when connecting the user to their remote desktop. A particular protocol plan can assign multiple protocols, and the Connection Broker uses the protocol appropriate for that desktop. To create a Protocol plan:

1. Go to the > Plans > Protocol page, shown in the following figure.

2. For this example, create a new protocol plan that uses NoMachine NX to connect to the Linux machines. Click the Create Protocol Plan link, as shown in the following figure

3. In the Plan name edit field, enter a descriptive name that you can use to assign this protocol plan to pools.

4. Configure the protocol plan to use NoMachine NX, as shown in the following figure.

The NoMachine NX Configuration file has the same format as the .nxs session file saved by the NX Client. The options in the file correspond to UI elements on the NX Client.

5. The remainder of the Edit Protocol Plan form configures the parameters used when launching a remote session from other types of client devices. You do not need to modify these sections for this example.

6. Click Save. The new protocol plan appears on the > Plans > Protocols page.

Creating Power Control Plans

Power control plans define what happens to the desktop’s power state when the user disconnects or logs out of the desktop. To create a Power Control plan:

1. Go to the > Plans > Power Control page, shown in the following figure.

2. Click the Create Power Control Plan link, as shown in the following figure.

3. The Create Power Control Plan form opens. Fill in the form with the appropriate information, for example, the following form creates a plan that shuts down the desktop 15 minutes after the user logs out.

4. Click Save.

Creating Release Plans

Release plans determine whether a desktop is persistent or non-persistent.

The Leostream Connection Broker defines a persistent desktop as a desktop that is continuously assigned to a particular user, i.e., the desktop is never released back to its pool. A non-persistent desktop is a desktop that is released to its pool. Non-persistent desktops rely on their Power Control plan to determine if they should be reverted to a clean snapshot after the desktop is released.

To create a Release plan:

1. Go to the > Plans > Release page, shown in the following figure.

2. Click the Create Release Plan link, as shown in the following figure

3. The Create Release Plan form opens. Fill in the form with the appropriate information. For example, the following form creates a Release plan that logs the user out if they remain disconnected from their desktop for more than an hour.

4. Click Save. The new Release Plan appears on the > Plans > Release page, shown in the following figure.

The Leostream Connection Broker defines a rogue user as a user that has remotely logged into a desktop, but whose remote session is not managed by the Connection Broker. A rogue user can be a user that natively launched, for example, an RDP session to the desktop. Alternatively, a rogue user could be a user who logged into the desktop via the Connection Broker, but the Connection Broker subsequently released the desktop back to its pool before the user logged out.

Back to top

---

Step 4: Building Connection Broker Policies

After you define your pools and plans, build policies that assign the plans to desktops.

The Leostream Connection Broker defines a policy as a set of rules that determine how desktops are offered, connected, and managed for a user, including: what specific desktops are offered; what display protocol is used to connect to those desktops; which Power Control and Release plans are applied to those desktops; what USB devices the user can access in their remote desktop; and more.

To create policies:

1. Go to the > Users > Policies page, shown in the following figure.

2. Click the Create Policy link, as shown in the following figure.

3. The Create Policy form opens. Fill in the form with the appropriate information, as shown in the following figures. In this step, enter a name for the policy.

4. Select a pool to use for this policy, as shown in the following figure

5. The When User Logs into Connection Broker section, shown in the following figure, tells the Connection Broker how to offer desktops from the selected pool. In this example, the Connection Broker offers two desktop from the pool. Because the release plan performs actions on disconnect, the desktop must have an installed Leostream Agent.

6. The When User is Assigned to Desktop section, shown in the following figure, tells the Connection Broker how to manage a desktop when the user is assigned to that desktop.

7. Finally, to complete the Desktop Assignment from Pools section, in the Plans section, select the Protocol, Power Control, and Release plans defined in step 3, as shown in the following figure.

The next two steps in this procedure are provided for informational purposes. You do not need to modify any options in these sections to complete this example.

8. After you configure the Desktop Assignment from Pools section, you can indicate if the policy also offers Citrix XenApp applications, and configure how it handles hard-assigned desktops. This example does not require these sections, which are shown for reference in the following figure.

9. The Connection Broker uses the settings in the Desktop Assignment from Pools section to determine which desktops to offer from each pool. You can optionally filter individual pools, or all the pools, prior to the Connection Broker choosing desktops. The Pool Filters apply only to the individual pool they are associated with in the Desktop Assignment from Pools section. Policy Filters apply to all desktop pools in the policy. This example does not use Pool Filters or Policy Filters, which are shown for reference in the following figure.

10. Click Save. The new policy is listed on the > Resources > Policies page, as shown in the following figure.

Back to top

---

Step 5: Adding an Authentication Server

After you have your pools and policies configured, setup your authentication server in the Connection Broker. This example uses an OpenLDAP authentication server with the structure shown in the following figure.

To create an authentication server in the Connection Broker for this OpenLDAP server:

1. Go to the > Users > Authentication Servers page.

2. Click the Add Authentication Server link, as shown in the following figure.

3. The Add Authentication Server form opens. Fill in the form with the appropriate information for your authentication server, as shown in the following figure.

4. Click Next >. The second page of the Add Authentication Server form opens. Enter your domain name, and confirm the information from the previous form is correct, as shown in the following figure.

5. Specify where in the OpenLDAP tree the Connection Broker begins searching for users, and what field the Connection Broker uses to match login names against, as shown in the following figure.

If your users need to log in using the value stored in their UID attribute, you must manually add UID to the Match Login name against this field drop-down menu. Please, contact support@leostream.com for instructions. This example uses CN for user login.

At this point, your authentication server setup is complete, and you could scroll down and click Save. To follow through this example, however, leave the Add Authentication Server form open and proceed to step 6.

Back to top

---

Step 6: Assigning Policies to Users

Step 6 builds on step 5 using the Add Authentication Server form.

If you clicked Save to close the Add Authentication Server form, use the Edit action associated with the authentication server to open the Edit Authentication Server form.

1. Use the Assigning User Role and Policy section to assign policies to users based on the user’s OpenLDAP attributes. This example matches the user to a policy based on the user’s organizational unit (ou) attribute.

2. After all the rules are configured, set a default role and policy to apply to users that are not assigned a policy by one of the rules, as shown in the following figure.

3. Select any final options to apply to this authentication server, as shown in the following figure.

4. Click Save to save any changes to the authentication server.

Your basic Connection Broker configuration is complete, and you can now test your setup.

Back to top

---

Step 7: Testing a User Login

The following procedure allows you to test if your policies and authentication servers are correctly configured.

1. Go to the > Users > Users page, shown in the following figure.

2. Click the Test Login link, as shown in the previous figure. The Login Test dialog opens.

3. Specify the test parameters, as shown in the following figure.

The following figure describes an example test result.

Back to top

---