Entitling users or groups in a Horizon View Federated Pod
Once the VMware Horizon View Federated Pod has been created and desktop pools have been deployed in at least one pod, we can create a global entitlement. In this section, we will walk through the creation of a global entitlement. With a global entitlement, users see only one desktop pool in the Horizon View Client, yet they might be assigned desktops from any number of pods in the pod federation based on the entitlement configuration.
Getting ready
The following figure is a conceptual example of a global entitlement in a VMware Horizon View federation using the names of the objects used as an example later in this section. In this example, the sample user is a member of the global entitlement called Global-Finance. Global-Finance provides entitlement to two floating desktop pools, named RTP-Finance-Floating and SantaClara-Finance-Floating. The RTP-Finance-Floating pool is located in a pod named RTP-Pod1 in the RTP data center, and the SantaClara-Finance-Floating pool is located in the pod named Santa-Clara-Pod1 in the Santa Clara data center. While this example shows you only two pods in the pod federation, remember that up to four pods are supported. The user-entitlement process remains the same regardless of how many pods are there in the federation.
Since the Global-Finance pool has a scope policy of ANY
, when a user requests a desktop, the Federated Pod Architecture feature looks for desktops from both the RTP and Santa Clara pods. While we have other pools available in each pod, they are not part of the Global-Finance pool, and as such, their desktops are not available for assignment to the Global-Finance pool users.
By default, a user will be provided with a desktop from a pod where they are located when they initiate the Horizon View Client logon process. If desktops are not available from any local entitled pods, yet other pods in other sites have desktops available, the user will automatically be assigned a desktop from the remote pod.
Note
This section shows you the creation of a floating assignment global pool, which is the most logical choice, given that it provides the most flexibility for user assignment. While dedicated assignment global pools can be created, once a user has been assigned a desktop, they will continue to use it regardless of where they happen to be located. Additionally, were one pod to run out of desktops, large numbers of users might be permanently assigned desktops not local to them, which might lead to performance problems if there is insufficient bandwidth to support large numbers of remote users.
The advantage of the Federated Pod Architecture is that the user need only select a single desktop pool at login, and Horizon View will assign them whatever desktop is available from any pod specified in their global entitlement while still selecting local Horizon View pods by default, wherever possible.
To entitle AD users or groups access to resources in a federated pod, command-line access to one of the Connection Servers in the federated pod is required.
How to do it...
In this section, we will walk through the steps required to create a Horizon View Federated Pod global entitlement, including the assignment of both AD resources as well as Horizon View desktop pools. For this exercise, we will use the following resources:
- Global-Finance: This is the name of the new federated pod global entitlement.
- RTP-Finance-Floating: This is the floating assignment pool located in RTP-Pod1.
- SantaClara-Finance-Floating: This is the floating assignment desktop pool located in Santa-Clara-Pod1.
- Vjason\Global-Finance: This is the AD security group that will contain the users entitled to the Global-Finance global entitlement. When supplying the AD group name, you must include as well as show the domain name.
Note
In this example, we have an AD security group named Global-Finance that contains nested AD security groups for each region. This type of hierarchy is common in global AD environments where security groups can be used differently from one region to the next. While Horizon View can identify nested security groups and grant the necessary access to the global desktop pool, the site assignment feature described in the next section cannot. Should you wish to assign AD security groups to specific Horizon View sites, you must first entitle each individual security group to the Horizon View global entitlement. The process used to entitle security groups is outlined in step 4 in this section.
For each command shown in this section, we will see both the command syntax as well as a demonstration of the command being executed in our own Horizon View environment. Refer to the following steps:
- The first step is to create our global entitlement and make any changes to the default configuration. In this example, we will create a floating assignment entitlement with a scope of
ANY
, which enables Horizon View to assign users' desktops from any desktop pools added to the entitlement:lmvutil.cmd –-authAs user –-authDomain domain –-authPassword password –-createGlobalEntitlement –-entitlementName "name" –-isFloating –-scope scope
- Next, using a command prompt in a Connection Server located in the
RTP-Pod1
pod, we will associate a previously created standard desktop pool with the global entitlement created in step 1. As we specified--isFloating
in the previous example, only floating assignment desktop pools can be associated. The desktop pool ID that is used is the same one used when the desktop pool was first created:lmvutil.cmd --authAs user --authDomain domain --authPassword password --addPoolAssociation --entitlementName "name" --poolId "id"
- Next, using a command prompt in a Connection Server located in the
Santa-Clara-Pod1
pod, we will repeat the process used in step 2, but this time, using the pool ID for a standard desktop pool located in that pod, as shown in the following screenshot:Note
Use the
lmvutil.cmd --listGlobalEntitlements
command to review all global entitlements that have been created. - Our final step is to assign an AD security group to the global entitlement. This step should be repeated as many times as necessary in order to add additional users or groups, and the format used should be
domain\name
, as shown in the following example:lmvutil.cmd --authAs user --authDomain domain --authPassword password --addGroupEntitlement --entitlementName "name" --groupName "domain\name"
- The previous command can also be applied to individual AD user accounts using the following format:
lmvutil.cmd --authAs user --authDomain domain --authPassword password --addUserEntitlement --entitlementName "name" --userName "domain\name"
With these steps complete, and assuming that all assigned desktop pools are ready, users will be able to log in to their newly created global desktop pool. The following screenshot shows you the appearance of the global desktop pool in the Horizon View Client, which is displayed as a single desktop pool even though the global entitlement is linked to two individual desktop pools located in wholly separate pods:
How it works...
The lmvutil.cmd
command-line utility is again used to create global entitlements. The following table outlines additional command-line switches that are used to create a global entitlement and then associate it with users and desktop pools. As previously noted, these switches are case-sensitive, and each is preceded by two dashes.