Before you begin to configure 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.
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 data center. The Cloud Pod Architecture feature treats pods in the same site equally.
Entitling Users and Groups in the Pod Federation In a traditional Horizon environment, you use Horizon Console to create local entitlements. These local entitlements entitle users and groups to a specific desktop or application pool on a Connection Server instance.
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 configuration information from the Global Data Layer to determine where to search for and how to allocate desktops and applications across the pod federation.
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.
Global Entitlement Example In this example, NYUser1 is a member of the global desktop entitlement called My Global Pool. My Global Pool provides an entitlement to three floating desktop pools, called pool1, pool2, and pool3. pool1 and pool2 are in a pod called NY Pod in the New York data center and pool3 and pool4 are in a pod called LDN Pod in the London data center.
Implementing Connection Server Restrictions for Global Entitlements You can restrict access to global entitlements based on the Connection Server instance that users initially connect to when they select global entitlements.
Implementing Client Restrictions for Global Entitlements You can restrict access to global entitlements to specific client computers. To restrict access, you add the names of the client computers that are allowed to access a global entitlement in an Active Directory security group and then add this group to the global entitlement's users and groups.
Implementing the Session Pre-Launch Feature for Global Application Entitlements With the session pre-launch feature, a Horizon administrator can configure a published application so that the session starts before a user opens the application in Horizon Client. The session pre-launch feature enables faster start times for frequently used published applications.
Enabling Multi-Session Mode for Global Application Entitlements When you create a global application entitlement, you can specify whether users can start multiple sessions of the same published application on different client devices. This feature is called multi-session mode.
Enabling Session Collaboration for Global Desktop Entitlements With the Session Collaboration feature, end users can invite other users to join an existing remote desktop session.
Implementing Backup Global Entitlements When you edit a global desktop entitlement or global application entitlement, you can select a backup global entitlement. A backup global entitlement delivers remote desktops or published applications when the primary global entitlement fails to start a session because of problems such as insufficient pool capacity or unavailable pods. A backup global entitlement can contain pools from any pod in the pod federation.
Considerations for Mixed-Version Environments Mixed-version Cloud Pod Architecture environments are supported beginning with Horizon 7 version 7.4. For example, a pod federation can include pods that are running Horizon 7 version 7.4 and pods that are running Horizon 6 version 6.x.
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.
Considerations for VMware Cloud on AWS You can deploy Horizon 7 in a hybrid cloud environment when you use Cloud Pod Architecture to interconnect Horizon 7 on-premises and Horizon 7 pods on VMware Cloud on AWS. You can entitle users to virtual desktops and published applications on-premises and on VMware Cloud on AWS.
Considerations for RDS Per-Device Client Access Licensing When a Windows client device connects to a published desktop or application on an RDS host, it receives an RDS Per-Device Client Access License (CAL), if the Per-Device licensing mode is configured on the RDS host. By default, the CAL is stored only on the client device.
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.
Cloud Pod Architecture Port Requirements Certain network ports must be opened on the Windows firewall for the Cloud Pod Architecture feature to work. When you install Connection Server, the installation program can optionally configure the required firewall 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 firewalls, you must manually configure the Windows firewall.
Security Considerations for Cloud Pod Architecture Topologies To use Horizon Console or the lmvutil command to configure 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.