VMware Horizon 7 – Cloud Pod Architecture

Last Modified: Oct 24, 2020 @ 6:29 am


This post applies to all VMware Horizon 7 versions including 7.13 (ESB) and 7.10.3 (ESB).

Change Log


Cloud Pod Architecture lets you publish a single icon that load balances connections across multiple pools in multiple pods in multiple sites (datacenters).

  • Global Entitlements – Entitlements are the same thing as published icons. When you create an entitlement (local or global), you are publishing an icon from a pool.
    • For local entitlement, the icon is only published from one pool.
    • For global entitlement, the icon can be published from multiple pools. The pools can be in one pod or from multiple pods.
    • Don’t configure both global and local entitlements for the same pool.
    • A single pool can only belong to one global entitlement.
    • For applications, only one application per global entitlement.
  • Pod Federation – Global entitlements can’t be created until a Pod Federation is created. This federation could be one pod or multiple pods.
    • The pods can be separated into sites. Each site can contain multiple pods.
  • Global Load Balancing – Use NetScaler GSLB or F5 GTM to connect Horizon Clients to a globally available Horizon Connection Server. The connected Horizon Connection Server then uses Global Entitlements to select a site/pod/pool.
    • When a user launches a Global Entitlement, the Connection Server selects a pod based on the Global Entitlement Scoping, which can be All Sites, Within site, or Within Pod. This is from the perspective of the Connection Server the user is currently connected to. Horizon will prefer the local pod if possible.
    • Users or groups can be assigned to Home Sites. Global Entitlements can be configured to prefer Home Sites over the normal site/pod selection criteria.
  • Dedicated Assignment – For Dedicated Assignment pools, global entitlement only helps with the initial connection. Once the user is assigned to a desktop then that desktop is always selected. Users are not automatically provided with a desktop from another site if the site containing their dedicated desktop has gone down. The desktop request will fail because the dedicated desktop isn’t available. The administrator could configure a separate Global Entitlement for the users to provide a floating desktop until such time the original site recovers. That floating entitlement should be arranged to deliver desktops from other sites as required.
  • Firewall Ports – The Horizon Connection Servers participating in Cloud Pod Architecture communicate with each other over TCP 135, TCP 22389, TCP 22636, and TCP 8472. Make sure these ports are open. More info at Ray Heffer VMware Horizon 7.4 Network Ports for Cloud Pod Architecture.
  • RBAC – View Administrator includes a new administrator privilege: Manage Global Sessions. The regular Administrators role has access to multiple pods. The new Local Administrators role can only manage the local pod.

Cloud Pod Limits in Horizon 7.11 and newer:

  • Max users = 250,000
  • Max Pods = 50
  • Max Sessions per Pod = 12,000
  • Max Sites = 15
  • Max Connection Servers per Pod = 7
  • Max Horizon Connection Server Instances = 350

Cloud Pod Limits in Horizon 7.8 and newer:

  • Max users = 250,000
  • Max Pods = 50
  • Max Sessions per Pod = 10,000
  • Max Sites = 15
  • Max Connection Servers per Pod = 7
  • Max Horizon Connection Server Instances = 350

Cloud Pod Limits in Horizon 7.6:

  • Max users = 200,000
  • Max Pods = 25
  • Max Sessions per Pod = 10,000
  • Max Sites = 10
  • Max Connection Servers per Pod = 7
  • Max Horizon Connection Server Instances = 175

Traffic flow (Rob Beekmans – VMware Horizon View Cloud Pod – unwanted routing?):

  • Use F5 GTM or NetScaler GSLB to connect users to a Horizon Connection Server in any pod. If active/active, use proximity load balancing to control which pod is initially accessed.
  • The Horizon Connection Server looks up the Global Entitlements to determine the destination pod for the Pool.
  • User’s PCoIP session goes through the initially connected Horizon Connection Server and across the DCI (Datacenter Interconnect) circuit to the remote pod. There’s no way to re-route Blast/PCoIP through a Horizon Connection Server in the remote pod. In fact, the Horizon Connection Servers in the remote pod are never accessed. You need sufficient DCI bandwidth to handle this Blast/PCoIP traffic.

For more information on multi-datacenter design for Horizon 7, see VMware Horizon 7 Enterprise Edition Multi-Site Reference Architecture, which is an 88-page document that includes the following:

  • Identity Manager
  • App Volumes
  • Horizon 7 Cloud Pod Architecture
  • User Environment Manager
  • SQL AlwaysOn Availability Groups
  • Nnetworking
  • Storage (e.g vSAN)
  • Active Directory
  • Distributed File System
  • Global Load Balancing

Initialize First Pod

As of Horizon 7.8, Cloud Pod can be configured in Horizon Console (https://myConnectionServer/newadmin).

  1. In Horizon Console, expand Settings and click Cloud Pod Architecture. Or in View Administrator, on the left, expand View Configuration, and click Cloud Pod Architecture.

  2. On the right, click Initialize the Cloud Pod Architecture feature.
  3. Click OK to initialize.

  4. A status page is displayed.

  5. If prompted, click OK to reload the client.

    • Then on the left, expand View Configuration, and click Cloud Pod Architecture.
  6. On the right, feel free to rename the federation by clicking the Edit button.

    1. Enter a new name.

  7. On the left, expand Settings (or View Configuration), and click Sites.

  8. On the right, in the top half, highlight the first site, and then click the Edit button to rename the Default First Site to be more descriptive.

    1. Enter a Site name.

  9. Click the Site to highlight it to reveal the Pods on the bottom half of the window.
  10. Highlight the pod and click Edit to make the name more descriptive.

    1. Enter a Pod name.

  11. See VMware 2080522 Restoring View Connection Server instances in a Cloud Pod Architecture pod federation.

Additional Pods – Join Federation

  1. Connect to View Administrator or Horizon Console in the second pod.
  2. On the left, expand Settings (or View Configuration), and click Cloud Pod Architecture.
  3. On the right, click Join the pod federation.

  4. Enter the name of an existing Horizon Connection Server that is already joined to the federation.
  5. Enter credentials, and click OK.

  6. The Join status is displayed.
  7. If prompted, click OK to reload the client.
  8. On the left, expand Settings (or View Configuration, and click Sites.

  9. If this pod is in a different site, then in the top half of the window click Add to create a new site.

  10. Give the site a name, and click OK.

  11. Highlight the first site.
  12. On the bottom, highlight the new pod, and click Edit.

  13. Rename the pod and put it in the 2nd site. Click OK.

  14. In Horizon 7.7 and newer, the top of Horizon Administrator shows you which Pod you are administering. You might have to refresh the page to see the correct Pod name after it was renamed.

Global Entitlements

Pools and Entitlements are two different things. You can create a pool without entitling anybody to the pool.

Local Entitlements and Global Entitlements are two different things. Global Entitlements are created separately, and then you assign pools from multiple pods to the Global Entitlement.

Do not create both Global Entitlements and Local Entitlements for the same pool otherwise users might see two icons. Create the local pool, but don’t entitle it. Instead, create a Global Entitlement and add the local pool to it.

  1. In Horizon Console (or View Administrator), on the left, expand Inventory (or Catalog), and click Global Entitlements.

  2. On the right, click Add.

  3. In the Type page, select Desktop Entitlement or Application Entitlement, and click Next.

  4. In the Name and Policies page, give the entitlement (icon) a name. For Application Entitlements, it’s one entitlement per application so include the application name.
  5. Horizon 7.2 and newer lets you configure tag restrictions (Connection Server restrictions) from this wizard.
  6. Horizon 7.3 and newer lets you select a Category Folder where the published icon will be placed on the client’s Start Menu. This feature requires Horizon Client 4.6 and newer.
  7. Horizon 7.5 and newer let you put the published icon on the endpoint’s desktop too. See Create Shortcuts for a Desktop Pool at VMware Docs.

    1. Configure Category Folder.

  8. Scroll down to the Policies section and configure the following:
    1. The Use home site checkbox tells the global entitlement to respect user home sites.
    2. Change the Default display protocol to VMware Blast.

    3. In newer versions of Horizon, you can allow users to reset/restart their machines.
    4. Check the box next to HTML Access.
    5. Horizon 7.2 adds a Pre-launch checkbox. If you need the Pre-launch feature, then enable the Pre-launch checkbox on at least one application, and entitle the application to the users that need the Pre-launch feature.
    6. Horizon 7.3 adds a checkbox named Client Restrictions. When this is enabled, you can add Client Computer Accounts to an AD Group and entitle the published icon to that computer AD group. The published icon can then only be accessed from the client computers in the AD group.


      • Windows clients only. If the this feature is enabled, then all non-Windows clients are blocked.
      • Horizon Client 4.6 and newer. All other versions are blocked.
      • In Horizon 7.8 and newer, the Active Directory security group can contain client computers that belong to any AD Organizational Units (OUs) or default Computer container. For older versions of Horizon, the computers must be in the Computer container.
      • See Implementing Client Restrictions for Desktop and Application Pools at VMware Docs.
    7. Horizon 7.7 and newer have a selection for Multi-Session Mode. Pre-launch must be disabled to enable this setting.
    8. Make other selections.
  9. Click Next when done.
  10. In the Users and Groups page, add users that can see the icon associated with the Global Entitlement. Click Next.

  11. In the Ready to Complete page, click Finish.

  12. Double-click the new global entitlement or click the link for the name of the Global Entitlement.

  13. Switch to the Local Pools tab.
  14. On the Local Pools tab, click Add.

  15. Select the local pools you want to add and click Add. Remember, only add one app per Global Entitlement. Also, you can only add pools from the local pod. To add pools from a different pod, you must point your Horizon Administrator or Horizon Console to the other pod and edit the Global Entitlement from there.

  16. Go to another pod and view the Global Entitlements.
  17. On the right, double-click the Global Entitlement or click the hyperlink for the name of the Global Entitlement.

  18. On the Local Pools tab, click Add to add pools from this pod.

  19. Horizon Console 7.11 and newer can configure backup global entitlements. 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.
    1. Create a Backup Global Entitlement containing the backup pools. You don’t have to assign anybody to the Backup Global Entitlement.
    2. Edit the production Global Entitlement.
    3. Under Backup Global Entitlement, click Browse.
    4. Change the selection to Backup Global Entitlement, select the Backup Global Entitlement and click Submit.
  20. Horizon Console 7.11 and newer at Inventory > Desktops can show if a Local Pool is a member of a Global Entitlement.


  1. Once Global Entitlements are enabled, a new Search Sessions node is added, which allows you to search for sessions across federated pods. The Search Sessions node is available in Horizon Console 7.9.

  2. The Dashboard in Horizon Administrator shows the health of remote pods. The Dashboard has not yet been added to Horizon Console.

Home Sites

The Home Sites feature causes Global Entitlements to prefer pools in the user’s Home Site before looking for pools in remote sites.

Horizon 7 lets you configure Home Sites for users from within Horizon Administrator. Horizon 7.8 lets you configure Home Sites for users from within Horizon Console.

  1. Configure your Cloud Pod Architecture with multiple Sites and at least one Pod per Site.
  2. In Horizon Console or Horizon Administrator, on the left, click Users and Groups.

  3. On the right, switch to the Home Site tab (or Home Site Assignment tab).
  4. Click Add.

  5. Find a user or group for this home site, and click Next.

  6. Select the site to assign the users to and click Finish.

  7. Home Sites can be assigned to both users and groups. User assignments override group assignments.

  8. Edit your Global Entitlement and ensure that Use Home Site is checked. You can optionally require that each user has a Home Site.
  9. Each Global Entitlement can have its own Home Site configuration that overrides the global Home Site configuration.
    • In Horizon Console, click the hyperlink for the Global Entitlement’s name, switch to the tab named Home Site Override, and then click Add.

    • In Horizon Administrator, double-click a Global Entitlement, switch to the Home Site Override tab, and click Add.
  10. Since you could have a combination of default Home Site for user, default Home Site for group, and Global Entitlement-specific Home Sites, it’s helpful to know which Home Site is effective for each user and Entitlement.
    • In Horizon Console, in the Users and Groups node, switch to the Home Site Resolution tab. Find a user, and it will show you the Home Site Resolution.
    • In Horizon Administrator, on the Users and Groups page, on the Home Site tab, if you switch to the Resolution sub-tab, you can find a user name, click Look Up and see which Home Site is assigned to the user for each entitlement.

Related Pages

34 thoughts on “VMware Horizon 7 – Cloud Pod Architecture”

  1. Carl, I have 2 Pods, each with 4 connection serves in them.
    How would I go about removing a connection server from the current pod, and adding it to a new one?
    I see all kinds of documentation on initializing pods and adding pods to a federation but nothing on moving connection servers from one pod to another.
    Thanks for the great right ups!

  2. Hi Carl, good article but is there any best practice of initializing a current standalone Production POD with CPA – e.g. shutdown all Connection Servers in the POD and snapshot? Need to ensure a rollback post initializing CPA in case something goes wrong? Cheers. Paul.

    1. I don’t see how that would harm anything. So far I’ve never needed to restore after enabling CPA.

  3. Carl,

    Your article are really awesome. I have one newbie question here. I have two sites, lets say LA and FL. LA is primary, FL is DR site.

    AD server on LA is configured like example.com, and all hosts, VMs, users, CA (cert auth), instant clone pool, their users all are under example.com

    Now, AD server on FL is under a child domain fl.example.com. Now what I see is, all users, computers they are not available on FL AD Users and Computers, though DNS is showing all the LA zones.

    Again, on LA DNS, FL’s zones are not showing, but they are reachable using hostname.

    Can you tell me if my this setup is wrong? How the users who were created on LA will have access to FL desktop pool? Do I also need to create an additional domain controller of primary domain example.com at FL?

    1. Is your FL DNS zone configured to replicate to the entire forest? Or just the domain?

      You should be able to assign LA users to the FL pools. Make sure LA/Domain Users are added to the local Users group for any Horizon Agent machine that is added to the FL domain.

      1. Hi Carl,

        Thanks for your quick responses.

        Which one I shall configure, replicate to entire forest or just to the child domain? Though from any LA parent domain host, I can ping, access any host on the FL child domain. Currently the setting is configured to replicate to the child domain itself only.

        Regarding your second opinion, can you tell me how can I add LA/Domain Users to Local Users group on FL domain as I will be deploying floating, non-persistent, instant clone pool ?

  4. Dear Mr. Stalhood, could you also add the Horizon Universal Broker Part? Would be great! (best instruction site by far btw).
    All the best

    1. Depends on how far apart they are. VMware strongly recommends that a View Pod not be stretched across two data centers. The latency between the servers in the pod must be very low.

  5. Is there a listing anywhere of rules that would cause a global entitlement to route a user to a non home site? For instance if a pool has no available desktops, will it automatically switch? If a user has a previous session that is hung and is unable to log back in, will it route them over, etc?

  6. Is there any VDI solution that supports directory federation vs extended the domain controller into the cloud?

    1. For both Horizon and Citrix, the Horizon Agents or Citrix Agents must be joined to a domain. But it doesn’t necessarily have to be the same domain as the users. If the user’s domain is not trusted by the Agent’s domain, then you can federate using SAML. Horizon uses Identity Manager and True SSO to federate.

  7. Are global policies applied to a global entitlements? In the global policy I’ve enabled USB Redirection, but when I access to a desktop pool using global entitlements USB aren’t redirect, if I access dekstop pool using “local entitlements” USB redirection work.

    any ideas?


  8. Great post! Do I need to copy one local pool in the default site pod to the other site pod if I want to use the secondary site as DR site? How do I copy one local pool from one site to the other site?

  9. Great write up. I see you have deep understanding of multi-site deployments in both XD, XA, and Horizon.
    For a multi-site published app deployment, what, in your opinion is the cleanest deployment requiring the least custom config? Currently a Citrix shop BUT Seems that Horizon Cloud Pod Architecture solves many shortcomings of Citrix multi-site deployment. Paired with AppVolumes + Other VMW tools, its almost a no brainer.

    1. You still have to build and configure each datacenter separately.

      Cloud Pod does nothing more than create one global icon that load balances multiple local icons, just like Citrix StoreFront does when it aggregates icons from multiple farms. The difference is that Cloud Pod is included with Horizon Connection Server, while Citrix StoreFront is a separate machine/configuration. Note: Cloud Pod global entitlements are created for each individual app, whereas StoreFront automatically aggregates all icons with the same name.

      StoreFront has more controls for routing of ICA Traffic (HDX Optimal Routing). Cloud Pod cannot reroute Blast/PCoIP connections to a different entry point.

      1. Thanks. Do you have a good reference architecture for the Citrix multi-site? What I find online is multi-site configs using PoSH scripts to sych the sites. I just feel like after working on Citrix for so long, looking at all the puzzle pieces that VMW solution has to offer seems it all fits together nicely, where the Citrix side looks like its patching stuff together. I dont just mean multi-site, I mean the entire stack up and down.

        1. First need a proper design. This is too big a topic for a comment reply, and I usually recommend a consultant perform the design.

          Which components are active/active vs active/passive? Each component has different multi-datacenter design. These components include: DNS, ICA Proxy, StoreFront, Controllers, WEM, Layering, VDAs, vCenter, Application Data, User Profiles/HomeDirs, License Servers, etc.

          Some components are easy to build separately (duplicate) in each datacenter (e.g. StoreFront). Whereas other components can only live in one place at a time (e.g. user profiles). For duplicated components, how to replicate configurations? Stretch a single configuration database across datacenters? To eliminate cross-datacenter dependencies, I usually prefer separate configurations (databases) per datacenter, unless it’s a metro cluster. Client-side components can aggregate multiple back-end components.

          You typically use automation to keep every datacenter identical. Even in the stretched farm scenario, each datacenter has separate vCenter, separate master images, separate Catalogs. How to keep them identical?

          If you don’t stretch a farm, then only a small number of configurations are identical in both datacenters. This includes: Citrix Policies, Published Apps/Delivery Groups, and Administrators. Citrix Policies can be stored in a GPO and applied to multiple DCs. That just leaves published apps. There are scripts that can export/import. Or always use PowerSehll to create them identically in both datacenters.

  10. When I want Join view server to existing POD i will get it error “The Active Directory Lightweight Directory Services Installation Wizard (Dcpromo) was unable to establish connection with the following domain controller. “

      1. In test environment I turn Off Firewal on new server and the others to. With telnet the connection goes through for all requirements ports.

  11. Carl – If a client deploys an active/active cloud pod arch and they want to do maintenance on one site (plenty of capacity on each side), how does the cloud pod arch behave? This used to easy prior, as before cloud pod, they stretched the connection server lay out between two sites, stopped a service and traffic was routed to the site no under maintenance.

    Thanks! Tim

  12. Carl, Thank you so much for such detailed information.

    I don’t suppose you have plans of writing one on Citrix’s latest 7.15 LTSR release.

Leave a Reply

Your email address will not be published. Required fields are marked *