VMware Horizon 7.2 Administrator’s Guide
Administering Cloud Pod Architecture
in Horizon 7
Modified on 26 JUL 2017
VMware Horizon 7 7.2
Administering Cloud Pod Architecture in Horizon 7
You can find the most up-to-date technical documentation on the VMware Web site at:
hps://docs.vmware.com/
The VMware Web site also provides the latest product updates.
If you have comments about this documentation, submit your feedback to:
docfeedback@vmware.com
Copyright © 2017 VMware, Inc. All rights reserved. Copyright and trademark information.
VMware, Inc.
3401 Hillview Ave.
Palo Alto, CA 94304
www.vmware.com
2 VMware, Inc.
Contents
Administering Cloud Pod Architecture in Horizon 7 5
Introduction to Cloud Pod Architecture 7
1
Understanding Cloud Pod Architecture 7
Conguring and Managing a Cloud Pod Architecture Environment 8
Cloud Pod Architecture Limitations 8
Designing a Cloud Pod Architecture Topology 9
2
Creating Cloud Pod Architecture Sites 9
Entitling Users and Groups in the Pod Federation 10
Finding and Allocating Desktops and Applications in the Pod Federation 10
Considerations for Unauthenticated Users 12
Global Entitlement Example 13
Restricting Access to Global Entitlements 13
Considerations for Workspace ONE Mode 15
Cloud Pod Architecture Topology Limits 16
Cloud Pod Architecture Port Requirements 16
Security Considerations for Cloud Pod Architecture Topologies 16
Seing Up a Cloud Pod Architecture Environment 17
3
Initialize the Cloud Pod Architecture Feature 17
Join a Pod to the Pod Federation 18
Assign a Tag to a Connection Server Instance 19
Create and Congure a Global Entitlement 20
Add a Pool to a Global Entitlement 22
Create and Congure a Site 23
Assign a Home Site to a User or Group 24
Create a Home Site Override 25
Test a Cloud Pod Architecture Conguration 25
Example: Seing Up a Basic Cloud Pod Architecture Conguration 26
VMware, Inc.
Managing a Cloud Pod Architecture Environment 31
4
View a Cloud Pod Architecture Conguration 31
View Pod Federation Health in Horizon Administrator 32
View Desktop and Application Sessions in the Pod Federation 33
Add a Pod to a Site 33
Modifying Global Entitlements 34
Managing Home Site Assignments 37
Remove a Pod From the Pod Federation 39
Uninitialize the Cloud Pod Architecture Feature 39
3
Administering Cloud Pod Architecture in Horizon 7
lmvutil Command Reference 41
5
lmvutil Command Use 41
Initializing the Cloud Pod Architecture Feature 44
Disabling the Cloud Pod Architecture Feature 45
Managing Pod Federations 45
Managing Sites 47
Managing Global Entitlements 50
Managing Home Sites 58
Viewing a Cloud Pod Architecture Conguration 60
Managing SSL Certicates 65
Index 67
4 VMware, Inc.
Administering Cloud Pod Architecture in Horizon 7
Administering Cloud Pod Architecture in Horizon 7 describes how to congure and administer a Cloud Pod
Architecture environment in VMware Horizon® 7, including how to plan a Cloud Pod Architecture
topology and set up, monitor, and maintain a Cloud Pod Architecture conguration.
Intended Audience
This information is intended for anyone who wants to set up and maintain a Cloud Pod Architecture
environment. The information is wrien for experienced Windows or Linux system administrators who are
familiar with virtual machine technology and data center operations.
VMware Technical Publications Glossary
VMware Technical Publications provides a glossary of terms that might be unfamiliar to you. For denitions
of terms as they are used in VMware technical documentation, go to
hp://www.vmware.com/support/pubs.
VMware, Inc.
5
Administering Cloud Pod Architecture in Horizon 7
6 VMware, Inc.
Introduction to Cloud Pod
Security
Server
User
View
Connection
Server
View
Connection
Server
Security
Server
View
Connection
Server
View
Connection
Server
Security
Server
Security
Server
London Pod
London Datacenter
Interpod
communication
Remote
desktop or
application
New York Pod
New York Datacenter
Global Data Layer
Architecture 1
The Cloud Pod Architecture feature uses standard Horizon components to provide cross-datacenter
administration, global and exible user-to-desktop mapping, high availability desktops, and disaster
recovery capabilities.
This chapter includes the following topics:
“Understanding Cloud Pod Architecture,” on page 7
n
“Conguring and Managing a Cloud Pod Architecture Environment,” on page 8
n
“Cloud Pod Architecture Limitations,” on page 8
n
Understanding Cloud Pod Architecture
With the Cloud Pod Architecture feature, you can link together multiple pods to provide a single large
desktop and application brokering and management environment.
A pod consists of a set of Connection Server instances, shared storage, a database server, and the vSphere
and network infrastructures required to host desktop and application pools. In a traditional Horizon
implementation, you manage each pod independently. With the Cloud Pod Architecture feature, you can
join together multiple pods to form a single Horizon implementation called a pod federation.
A pod federation can span multiple sites and datacenters and simultaneously simplify the administration
eort required to manage a large-scale Horizon deployment.
The following diagram is an example of a basic Cloud Pod Architecture topology.
Figure 1‑1. Basic Cloud Pod Architecture Topology
VMware, Inc.
7
Administering Cloud Pod Architecture in Horizon 7
In the example topology, two previously standalone pods in dierent datacenters are joined together to form
a single pod federation. An end user in this environment can connect to a Connection Server instance in the
New York datacenter and receive a desktop or application in the London data center.
Sharing Key Data in the Global Data Layer
Connection Server instances in a pod federation use the Global Data Layer to share key data. Shared data
includes information about the pod federation topology, user and group entitlements, policies, and other
Cloud Pod Architecture conguration information.
In a Cloud Pod Architecture environment, shared data is replicated on every Connection Server instance in a
pod federation. Entitlement and topology conguration information stored in the Global Data Layer
determines where and how desktops are allocated across the pod federation.
Horizon sets up the Global Data Layer on each Connection Server instance in a pod federation when you
initialize the Cloud Pod Architecture feature.
Sending Messages Between Pods
Connection Server instances communicate in a Cloud Pod Architecture environment by using an interpod
communication protocol called the View InterPod API (VIPA).
Connection Server instances use the VIPA communication channel to launch new desktops, nd existing
desktops, and share health status data and other information. Horizon congures the VIPA communication
channel when you initialize the Cloud Pod Architecture feature.
Configuring and Managing a Cloud Pod Architecture Environment
You use Horizon Administrator and the lmvutil command-line interface to congure and manage a Cloud
Pod Architecture environment. lmvutil is installed as part of the Horizon installation. You can also use
Horizon Administrator to view pod health and session information.
Cloud Pod Architecture Limitations
The Cloud Pod Architecture feature has certain limitations.
The Cloud Pod Architecture feature is not supported in an IPv6 environment.
n
Kiosk mode clients are not supported in a Cloud Pod Architecture implementation unless you
n
implement a workaround. For instructions, see VMware Knowledge Base (KB) article 2148888.
8 VMware, Inc.
Designing a Cloud Pod Architecture
Topology 2
Before you begin to congure the Cloud Pod Architecture feature, you must make decisions about your
Cloud Pod Architecture topology. Cloud Pod Architecture topologies can vary, depending on your goals, the
needs of your users, and your existing Horizon implementation. If you are joining existing Horizon pods to
a pod federation, your Cloud Pod Architecture topology is typically based on your existing network
topology.
This chapter includes the following topics:
“Creating Cloud Pod Architecture Sites,” on page 9
n
“Entitling Users and Groups in the Pod Federation,” on page 10
n
“Finding and Allocating Desktops and Applications in the Pod Federation,” on page 10
n
“Considerations for Unauthenticated Users,” on page 12
n
“Global Entitlement Example,” on page 13
n
“Restricting Access to Global Entitlements,” on page 13
n
“Considerations for Workspace ONE Mode,” on page 15
n
“Cloud Pod Architecture Topology Limits,” on page 16
n
“Cloud Pod Architecture Port Requirements,” on page 16
n
“Security Considerations for Cloud Pod Architecture Topologies,” on page 16
n
Creating Cloud Pod Architecture Sites
In a Cloud Pod Architecture environment, a site is a collection of well-connected pods in the same physical
location, typically in a single datacenter. The Cloud Pod Architecture feature treats pods in the same site
equally.
When you initialize the Cloud Pod Architecture feature, it places all pods into a default site called Default
First Site. If you have a large implementation, you might want to create additional sites and add pods to
those sites.
The Cloud Pod Architecture feature assumes that pods in the same site are on the same LAN, and that pods
in dierent sites are on dierent LANs. Because WAN-connected pods have slower network performance,
the Cloud Pod Architecture feature gives preference to desktops and applications that are in the local pod or
site when it allocates desktops and applications to users.
Sites can be a useful part of a disaster recovery solution. For example, you can assign pods in dierent
datacenters to dierent sites and entitle users and groups to pools that span those sites. If a datacenter in
one site becomes unavailable, you can use desktops and applications from the available site to satisfy user
requests.
VMware, Inc.
9
Administering Cloud Pod Architecture in Horizon 7
Entitling Users and Groups in the Pod Federation
In a traditional Horizon environment, you use Horizon Administrator to create local entitlements. These
local entitlements entitle users and groups to a specic desktop or application pool on a Connection Server
instance.
In a Cloud Pod Architecture environment, you create global entitlements to entitle users or groups to
multiple desktops and applications across multiple pods in the pod federation. When you use global
entitlements, you do not need to congure and manage local entitlements. Global entitlements simplify
administration, even in a pod federation that contains a single pod.
Global entitlements are stored in the Global Data Layer. Because global entitlements are shared data, global
entitlement information is available on all Connection Server instances in the pod federation.
You entitle users and groups to desktops by creating global desktop entitlements. Each global desktop
entitlement contains a list of member users or groups, a list of the desktop pools that can provide desktops
for entitled users, and a scope policy. The desktop pools in a global entitlement can be either oating or
dedicated pools. You specify whether a global entitlement is oating or dedicated during global entitlement
creation.
You entitle users and groups to applications by creating global application entitlements. Each global
application entitlement contains a list of the member users or groups, a list of the application pools that can
provide applications for entitled users, and a scope policy.
A global entitlement's scope policy species where Horizon looks for desktops or applications when it
allocates desktops or applications to users in the global entitlement. It also determines whether Horizon
looks for desktops or applications in any pod in the pod federation, in pods that reside in the same site, or
only in the pod to which the user is connected.
As a best practice, you should not congure local and global entitlements for the same desktop pool. For
example, if you create both local and global entitlements for the same desktop pool, the same desktop might
appear as a local and a global entitlement in the list of desktops and applications that Horizon Client shows
to an entitled user. Similarly, you should not congure both local and global entitlements for application
pools created from the same farm.
Finding and Allocating Desktops and Applications in the Pod Federation
Connection Server instances in a Cloud Pod Architecture environment use shared global entitlement and
topology conguration information from the Global Data Layer to determine where to search for and how to
allocate desktops and applications across the pod federation.
When a user requests a desktop or application from a global entitlement, Horizon searches for an available
desktop or application in the pools that are associated with that global entitlement. By default, Horizon
gives preference to the local pod, the local site, and pods in other sites, in that order.
For global desktop entitlements that contain dedicated desktop pools, Horizon uses the default search
behavior only the rst time a user requests a desktop. After Horizon allocates a dedicated desktop, it returns
the user directly to the same desktop.
You can modify the search and allocation behavior for individual global entitlements by seing the scope
policy and conguring home sites.
10 VMware, Inc.
Chapter 2 Designing a Cloud Pod Architecture Topology
Understanding the Scope Policy
When you create a global desktop entitlement or global application entitlement, you must specify its scope
policy. The scope policy determines the scope of the search when Horizon looks for desktops or applications
to satisfy a request from the global entitlement.
You can set the scope policy so that Horizon searches only on the pod to which the user is connected, only
on pods within the same site as the user's pod, or across all pods in the pod federation.
For global desktop entitlements that contain dedicated pools, the scope policy aects where Horizon looks
for desktops the rst time a user requests a dedicated desktop. After Horizon allocates a dedicated desktop,
it returns the user directly to the same desktop.
Understanding the Multiple Sessions Per User Policy
When you create a global desktop entitlement, you can specify whether users can initiate separate desktop
sessions from dierent client devices. The multiple sessions per user policy applies only to global desktop
entitlements that contain oating desktop pools.
When you enable the multiple sessions per user policy, users that connect to the global entitlement from
dierent client devices receive dierent desktop sessions. To reconnect to an existing desktop session, users
must use the same device from which that session was initiated. If you do not enable this policy, users are
always reconnected to their existing desktop sessions, regardless of the client device that they use.
If you enable the multiple sessions per user policy for a global entitlement, all of the desktop pools
associated with the global entitlement must also support multiple users per session.
Using Home Sites
A home site is a relationship between a user or group and a Cloud Pod Architecture site. With home sites,
Horizon begins searching for desktops and applications from a specic site rather than searching for
desktops and applications based on the user's current location.
If the home site is unavailable or does not have resources to satisfy the user's request, Horizon continues
searching other sites according to the scope policy set for the global entitlement.
For global desktop entitlements that contain dedicated pools, the home site aects where Horizon looks for
desktops the rst time a user requests a dedicated desktop. After Horizon allocates a dedicated desktop, it
returns the user directly to the same desktop.
The Cloud Pod Architecture feature includes the following types of home site assignments.
Global home site
A home site that is assigned to a user or group.
If a user who has a home site belongs to a group that is associated with a
dierent home site, the home site associated with the user takes precedence
over the group home site assignment.
VMware, Inc. 11
Administering Cloud Pod Architecture in Horizon 7
Global homes sites are useful for controlling where roaming users receive
desktops and applications. For example, if a user has a home site in New
York but is visiting London, Horizon begins looking in the New York site to
satisfy the user's desktop request rather than allocating a desktop closer to
the user. Global home site assignments apply for all global entitlements.
I Global entitlements do not recognize home sites by default. To
make a global entitlement use home sites, you must select the Use home site
option when you create or modify the global entitlement.
Per-global-entitlement
home site (home site
override)
A home site that is associated with a global entitlement.
Per-global-entitlement home sites override global home site assignments. For
this reason, per-global-entitlement home sites are also referred to as home
site overrides.
For example, if a user who has a home site in New York accesses a global
entitlement that associates that user with the London home site, Horizon
begins looking in the London site to satisfy the user's application request
rather than allocating an application from the New York site.
Conguring home sites is optional. If a user does not have a home site, Horizon searches for and allocates
desktops and applications as described in “Finding and Allocating Desktops and Applications in the Pod
Federation,” on page 10.
Considerations for Unauthenticated Users
A Horizon administrator can create users for unauthenticated access to published applications on a
Connection Server instance. In a Cloud Pod Architecture environment, you can entitle these unauthenticated
users to applications across the pod federation by adding them to global application entitlements.
Following are considerations for unauthenticated users in a Cloud Pod Architecture environment.
Unauthenticated users can have only global application entitlements. If an unauthenticated user is
n
included in a global desktop entitlement, a warning icon appears next to the name on the Users and
Groups tab for the global desktop entitlement in Horizon Administrator.
When you join a pod to the pod federation, unauthenticated user data is migrated to the Global Data
n
Layer. If you unjoin or eject a pod that contains unauthenticated users from the pod federation,
unauthenticated user data for that pod is removed from the Global Data Layer.
You can have only one unauthenticated user for each Active Directory user. If the same user alias is
n
mapped to more than one Active Directory user, Horizon Administrator displays an error message on
the Unauthenticated Access tab on the Users and Groups pane.
You can assign home sites to unauthenticated users.
n
Unauthenticated users can have multiple sessions.
n
For information about seing up unauthenticated users, see the View Administration document.
12 VMware, Inc.
Global Entitlement Example
New York Datacenter
Pod Federation
Global Entitlement
“My Global Pool”
Members:
NYUser1
NYUser2
Pools:
pool1
pool2
pool3
Scope: Any
pool1 pool2
NY Pod
London Datacenter
pool3 pool4
LDN Pod
NYUser1
In this example, NYUser1 is a member of the global desktop entitlement called My Global Pool. My Global
Pool provides an entitlement to three oating desktop pools, called pool1, pool2, and pool3. pool1 and pool2
are in a pod called NY Pod in the New York datacenter and pool3 and pool4 are in a pod called LDN Pod in
the London datacenter.
Figure 2‑1. Global Entitlement Example
Chapter 2 Designing a Cloud Pod Architecture Topology
Because My Global Pool has a scope policy of ANY, the Cloud Pod Architecture feature looks for desktops
across both NY Pod and LDN Pod when NYUser1 requests a desktop. The Cloud Pod Architecture feature
does not try to allocate a desktop from pool4 because pool4 is not part of My Global Pool.
If NYUser1 logs into NY Pod, the Cloud Pod Architecture feature allocates a desktop from pool1 or pool2, if
a desktop is available. If a desktop is not available in either pool1 or pool2, the Cloud Pod Architecture
feature allocates a desktop from pool3.
For an example of restricted global entitlements, see “Restricted Global Entitlement Example,” on page 14.
Restricting Access to Global Entitlements
You can congure the restricted global entitlements feature to restrict access to global entitlements based on
the Connection Server instance that users initially connect to when they select global entitlements.
With restricted global entitlements, you assign one or more tags to a Connection Server instance. Then,
when you congure a global entitlement, you specify the tags of the Connection Server instances that you
want to have access to the global entitlement.
You can add tags to global desktop entitlements and global application entitlements.
Tag Matching
The restricted global entitlements feature uses tag matching to determine whether a Connection Server
instance can access a particular global entitlement.
At the most basic level, tag matching determines that a Connection Server instance that has a specic tag can
access a global entitlement that has the same tag.
The absence of tag assignments can also aect whether users that connect to a Connection Server instance
can access a global entitlement. For example, Connection Server instances that do not have any tags can only
access global entitlements that also do not have any tags.
VMware, Inc. 13
Administering Cloud Pod Architecture in Horizon 7
Table 2-1 shows how tag matching determines when a Connection Server instance can access a global
entitlement.
Table 2‑1. Tag Matching Rules
Connection Server Global Entitlement Access Permitted?
No tags No tags Yes
No tags One or more tags No
One or more tags No tags Yes
One or more tags One or more tags Only when tags match
The restricted global entitlements feature only enforces tag matching. You must design your network
topology to force certain clients to connect through a particular Connection Server instance.
Considerations and Limitations for Restricted Global Entitlements
Before implementing restricted global entitlements, you must be aware of certain considerations and
limitations.
A single Connection Server instance or global entitlement can have multiple tags.
n
Multiple Connection Server instances and global entitlements can have the same tag.
n
Any Connection Server instance can access a global entitlement that does not have any tags.
n
Connection Server instances that do not have any tags can access only global entitlements that also do
n
not have any tags.
If you use a security server, you must congure restricted entitlements on the Connection Server
n
instance with which the security server is paired. You cannot congure restricted entitlements on a
security server.
Restricted global entitlements take precedence over other entitlements or assignments. For example,
n
even if a user is assigned to a particular machine, the user cannot access that machine if the tag assigned
to the global entitlement does not match the tag assigned to the Connection Server instance to which the
user is connected.
If you intend to provide access to your global entitlements through VMware Identity Manager and you
n
congure Connection Server restrictions, the VMware Identity Manager app might display global
entitlements to users when the global entitlements are actually restricted. When a
VMware Identity Manager user aempts to connect to a global entitlement, the desktop or application
does not start if the tag assigned to the global entitlement does not match the tag assigned to the
Connection Server instance to which the user is connected.
Restricted Global Entitlement Example
This example shows a Cloud Pod Architecture environment that includes two pods. Both pods contain two
Connection Server instances. The rst Connection Server instance supports internal users and the second
Connection Server instance is paired with a security server and supports external users.
To prevent external users from accessing certain desktop and application pools, you could assign tags as
follows:
Assign the tag "Internal" to the Connection Server instance that support your internal users.
n
Assign the tag "External" to the Connection Server instances that support your external users.
n
Assign the "Internal" tag to the global entitlements that should be accessible only to internal users.
n
Assign the "External" tag to the global entitlements that should be accessible only to external users.
n
14 VMware, Inc.
CS1
Tag:
Internal
CS2
Tag:
External
User1
Pool:
public1
Pool:
secret1
Global Entitlement 1
Tags: Internal
Pools: secret1, secret2
Members: all users
Global Entitlement 2
Tags: External
Pools: public1, public2
Members: all users
Pod 1
Pod Federation
CS3
Tag:
Internal
CS4
Tag:
External
Pool:
public2
Pool:
secret2
Pod 2
Chapter 2 Designing a Cloud Pod Architecture Topology
External users cannot see the global entitlements that are tagged as Internal because they log in through the
Connection Server instances that are tagged as External. Internal users cannot see the global entitlements
that are tagged as External because they log in through the Connection Server instances that are tagged as
Internal.
In the following diagram, User1 connects to the Connection Server instance called CS1. Because CS1 is
tagged Internal and Global Entitlement 1 is also tagged internal, User1 can only see Global Entitlement 1.
Because Global Entitlement 1 contains pools secret1 and secret2, User1 can only receive desktops or
applications from the secret1 and secret2 pools.
Figure 2‑2. Restricted Global Entitlement Example
Considerations for Workspace ONE Mode
If a Horizon administrator enables Workspace ONE mode for a Connection Server instance, Horizon Client
users can be redirected to a Workspace ONE server to launch their entitlements.
During Workspace ONE mode conguration, a Horizon administrator species the host name of the
Workspace ONE server. In a Cloud Pod Architecture environment, every pod in the pod federation must be
congured to point to the same Workspace ONE server.
For information about conguring Workspace ONE mode, see "Congure Workspace ONE Access Policies
in Horizon Administrator" in the View Administration document.
VMware, Inc. 15
Administering Cloud Pod Architecture in Horizon 7
Cloud Pod Architecture Topology Limits
A typical Cloud Pod Architecture topology consists of two or more pods, which are linked together in a pod
federation. Pod federations are subject to certain limits.
Table 2‑2. Pod Federation Limits
Object Limit
Total sessions 120,000
Pods 25
Sessions per pod 10,000
Sites 5
Connection Server instances 175
Cloud Pod Architecture Port Requirements
Certain network ports must be opened on the Windows rewall for the Cloud Pod Architecture feature to
work. When you install Connection Server, the installation program can optionally congure the required
rewall rules for you. These rules open the ports that are used by default. If you change the default ports
after installation, or if your network has other rewalls, you must manually congure the Windows rewall.
Table 2‑3. Ports Opened During Connection Server Installation
TCP
Protocol
HTTP 22389 Used for Global Data Layer LDAP replication. Shared data is replicated on every Connection
HTTPS 22636 Used for secure Global Data Layer LDAP replication.
HTTPS 8472 Used for View Interpod API (VIPA) communication. Connection Server instances use the VIPA
Port Description
Server instance in a pod federation. Each Connection Server instance in a pod federation runs a
second LDAP instance to store shared data.
communication channel to launch new desktops and applications, nd existing desktops, and
share health status data and other information.
Security Considerations for Cloud Pod Architecture Topologies
To use Horizon Administrator or the lmvutil command to congure and manage a Cloud Pod Architecture
environment, you must have the Administrators role. Users who have the Administrators role on the root
access group are super users.
When a Connection Server instance is part of a replicated group of Connection Server instances, the rights of
super users are extended to other Connection Server instances in the pod. Similarly, when a pod is joined to
a pod federation, the rights of super users are extended to all of the Connection Server instances in all of the
pods in the pod federation. These rights are necessary to modify global entitlements and perform other
operations on the Global Data Layer.
If you do not want certain super users to be able to perform operations on the Global Data Layer, you can
remove the Administrators role assignment and assign the Local Administrators role instead. Users who
have the Local Administrators role have super user rights only on their local Connection Server instance and
on any instances in a replicated group.
For information about assigning roles in Horizon Administrator, see the View Administration document.
16 VMware, Inc.
Setting Up a Cloud Pod Architecture
Environment 3
Seing up a Cloud Pod Architecture environment involves initializing the Cloud Pod Architecture feature,
joining pods to the pod federation, and creating global entitlements.
You must create and congure at least one global entitlement to use the Cloud Pod Architecture feature. You
can optionally create sites and assign home sites.
This chapter includes the following topics:
“Initialize the Cloud Pod Architecture Feature,” on page 17
n
“Join a Pod to the Pod Federation,” on page 18
n
“Assign a Tag to a Connection Server Instance,” on page 19
n
“Create and Congure a Global Entitlement,” on page 20
n
“Add a Pool to a Global Entitlement,” on page 22
n
“Create and Congure a Site,” on page 23
n
“Assign a Home Site to a User or Group,” on page 24
n
“Create a Home Site Override,” on page 25
n
“Test a Cloud Pod Architecture Conguration,” on page 25
n
“Example: Seing Up a Basic Cloud Pod Architecture Conguration,” on page 26
n
Initialize the Cloud Pod Architecture Feature
Before you congure a Cloud Pod Architecture environment, you must initialize the Cloud Pod Architecture
feature.
You need to initialize the Cloud Pod Architecture feature only once, on the rst pod in a pod federation. To
add pods to the pod federation, you join the new pods to the initialized pod.
During the initialization process, Horizon sets up the Global Data Layer on each Connection Server instance
in the pod, congures the VIPA communication channel, and establishes a replication agreement between
each Connection Server instance.
Procedure
1 Log in to the Horizon Administrator user interface for any Connection Server instance in the pod.
You can initialize the Cloud Pod Architecture feature from any Connection Server instance in a pod.
2 In Horizon Administrator, select View > Cloud Pod Architecture and click Initialize the
Cloud Pod Architecture feature.
VMware, Inc.
17
Administering Cloud Pod Architecture in Horizon 7
3 When the Initialize dialog box appears, click OK to begin the initialization process.
Horizon Administrator shows the progress of the initialization process. The initialization process can
take several minutes.
After the Cloud Pod Architecture feature is initialized, the pod federation contains the initialized pod
and a single site. The default pod federation name is Horizon Cloud Pod Federation. The default pod
name is based on the host name of the Connection Server instance. For example, if the host name is CS1,
the pod name is Cluster-CS1. The default site name is Default First Site.
4 When Horizon Administrator prompts you to reload the client, click OK.
After the Horizon Administrator user interface is refreshed, Global Entitlements appears under
Catalog and Sites appears under View in the Horizon Administrator Inventory panel.
5 (Optional) To change the default name of the pod federation, select View > Cloud Pod
Architecture, click Edit, type the new name in the Name text box, and click OK.
6 (Optional) To change the default name of the pod, select View > Sites, select the pod,
click Edit, type the new name in the Name text box, and click OK.
7 (Optional) To change the default name of the site, select View > Sites, select the site, click
Edit, type the new name in the Name text box, and click OK.
What to do next
To add more pods to the pod federation, see “Join a Pod to the Pod Federation,” on page 18.
Join a Pod to the Pod Federation
During the Cloud Pod Architecture initialization process, the Cloud Pod Architecture feature creates a pod
federation that contains a single pod. You can use Horizon Administrator to join additional pods to the pod
federation. Joining additional pods is optional.
I Do not stop or start a Connection Server instance while you are joining it to a pod federation.
The Connection Server service might not restart correctly. You can stop and start the Connection Server after
it is successfully joined to the pod federation.
Prerequisites
Make sure the Connection Server instances that you want to join have dierent host names. You cannot
n
join servers that have the same name, even if they are in dierent domains.
Initialize the Cloud Pod Architecture feature. See “Initialize the Cloud Pod Architecture Feature,” on
n
page 17.
Procedure
1 Log in to the Horizon Administrator user interface for a Connection Server instance in the pod that you
are joining to the pod federation.
2 In Horizon Administrator, select View > Cloud Pod Architecture and click Join the pod
federation.
3 In the Connection Server text box, type the host name or IP address of any Connection Server instance
in any pod that has been initialized or is already joined to the pod federation.
4 In the User name text box, type the name of a Horizon administrator user on the already initialized
pod.
Use the format domain\username.
5 In the Password text box, type the password for the Horizon administrator user.
18 VMware, Inc.
Chapter 3 Setting Up a Cloud Pod Architecture Environment
6 Click OK to join the pod to the pod federation.
Horizon Administrator shows the progress of the join operation. The default pod name is based on the
host name of the Connection Server instance. For example, if the host name is CS1, the pod name is
Cluster-CS1.
7 When Horizon Administrator prompts you to reload the client, click OK.
After the Horizon Administrator user interface is refreshed, Global Entitlements appears under
Catalog and Sites appears under View in the Horizon Administrator Inventory panel.
8 (Optional) To change the default name of the pod, select View > Sites, select the pod,
click Edit, type the new name in the Name text box, and click OK.
After the pod is joined to the pod federation, it begins to share health data. You can view this health data on
the dashboard in Horizon Administrator. See “View Pod Federation Health in Horizon Administrator,” on
page 32.
N A short delay might occur before health data is available in Horizon Administrator.
What to do next
You can repeat these steps to join additional pods to the pod federation.
Assign a Tag to a Connection Server Instance
If you plan to restrict access to a global entitlement based on the Connection Server instance that users
initially connect to when they select the global entitlement, you must rst assign one or more tags to the
Connection Server instance.
Prerequisites
Become familiar with the restricted global entitlements feature. See “Restricting Access to Global
Entitlements,” on page 13.
Procedure
1 Log in to Horizon Administrator for the Connection Server instance.
2 Select View > Servers.
3 Click the Connection Servers tab, select the Connection Server instance, and click Edit.
4 Type one or more tags in the Tags text box.
Separate multiple tags with a comma or semicolon.
5 Click OK to save your changes.
6 Repeat these steps for each Connection Server instance to which you want to assign tags.
What to do next
When you create or edit a global entitlement, select the tags that are associated with the Connection Server
instances that you want to access the global entitlement. See “Create and Congure a Global Entitlement,”
on page 20, or “Modify Aributes or Policies for a Global Entitlement,” on page 35.
VMware, Inc. 19
Administering Cloud Pod Architecture in Horizon 7
Create and Configure a Global Entitlement
You use global entitlements to entitle users and groups to desktops and applications in a Cloud Pod
Architecture environment. Global entitlements provide the link between users and their desktops and
applications, regardless of where those desktops and applications reside in the pod federation.
A global entitlement contains a list of member users or groups, a set of policies, and a list of the pools that
can provide desktops or applications for entitled users. You can add both users and groups, only users, or
only groups, to a global entitlement.
Prerequisites
Initialize the Cloud Pod Architecture feature. See “Initialize the Cloud Pod Architecture Feature,” on
n
page 17.
Decide which type of global desktop entitlement to create, the users and groups to include in the global
n
entitlement, and the scope of the global entitlement. See “Entitling Users and Groups in the Pod
Federation,” on page 10.
Decide whether to restrict access to the global entitlement based on the Connection Server instance that
n
users initially connect to when they select the global entitlement. See “Restricting Access to Global
Entitlements,” on page 13.
If you plan to restrict access to the global entitlement, assign one or more tags to the Connection Server
n
instance. See “Assign a Tag to a Connection Server Instance,” on page 19.
Decide whether the global entitlement uses home sites. See “Using Home Sites,” on page 11.
n
Procedure
1 Log in to the Horizon Administrator user interface for any Connection Server instance in the pod
federation.
2 In Horizon Administrator, select Catalog > Global Entitlements and click Add.
3 Select the type of global entitlement to add and click Next.
Option Description
Desktop Entitlement
Application Entitlement
Adds a global desktop entitlement.
Adds a global application entitlement.
4 Congure the global entitlement.
a Type a name for the global entitlement in the Name text box.
The name can contain between 1 and 64 characters. This name appears in the list of available
desktops and applications in Horizon Client for an entitled user.
b (Optional) Type a description of the global entitlement in the Description text box.
The description can contain between 1 and 1024 characters.
c (Optional) To restrict access to the global entitlement, click Browse, select Restricted to these tags,
select the tags to associate with the global entitlement, and click OK.
Only the Connection Server instances that have the selected tags can access the global entitlement.
N You can only select tags assigned to Connection Server instances in the local pod. To select
tags assigned to Connection Server instances in another pod, you must log in to Horizon
Administrator for a Connection Server instance in the other pod and modify the global entitlement.
20 VMware, Inc.
Chapter 3 Setting Up a Cloud Pod Architecture Environment
d If you are conguring a global desktop entitlement, select a user assignment policy.
The user assignment policy species the type of desktop pool that a global desktop entitlement can
contain. You can select only one user assignment policy.
Option Description
Floating
Dedicated
Creates a oating desktop entitlement. A oating desktop entitlement
can contain only oating desktop pools.
Creates a dedicated desktop entitlement. A dedicated desktop
entitlement can contain only dedicated desktop pools.
e Select a scope policy for the global entitlement.
The scope policy species where to look for desktops or applications to satisfy a request from the
global entitlement. You can select only one scope policy.
Option Description
All sites
Within site
Within pod
Look for desktops or applications on any pod in the pod federation.
Look for desktops or applications only on pods in the same site as the
pod to which the user is connected.
Look for desktops or applications only in the pod to which the user is
connected.
f (Optional) If users have home sites, congure a home site policy for the global entitlement.
Option Description
Use home site
Entitled user must have home site
Begin searching for desktops or applications in the user's home site. If
the user does not have a home site and the Entitled user must have
home site option is not selected, the site to which the user is connected
is assumed to be the home site.
Make the global entitlement available only if the user has a home site.
This option is available only when the Use home site option is selected.
g (Optional) Use the Automatically clean up redundant sessions option to specify whether to clean
up redundant sessions.
N This option is available only for oating desktop entitlements and global application
entitlements.
Multiple sessions can occur when a pod that contains a session goes oine, the user logs in again
and starts another session, and the problem pod comes back online with the original session. When
multiple sessions occur, Horizon Client prompts the user to select a session. This option determines
what happens to sessions that the user does not select. If you do not select this option, users must
manually end their own extra sessions, either by logging o in Horizon Client or by launching the
sessions and logging them o.
h Select the default display protocol for desktops or applications in the global entitlement and specify
whether to allow users to override the default display protocol.
i (Global desktop entitlement only) Select whether to allow users to reset desktops in the global
desktop entitlement.
j Select whether to allow users to use the HTML Access feature to access desktops or applications in
the global entitlement.
When you enable the HTML Access policy, end users can use a Web browser to connect to remote
desktops and applications and are not required to install any client software on their local systems.
VMware, Inc. 21
Loading...