VMware Horizon 2312: Cloud Pod Architecture

Last Modified: Jan 25, 2024 @ 10:21 am


This article applies to all VMware Horizon versions 2006 (8.0) and newer.

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 – Horizon Console 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 Architecture Topology Limits Horizon 8 at VMware Docs:

  • 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

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.
  • Note: Horizon Cloud Universal Broker doesn’t have this problem.

For more information on multi-datacenter design for Horizon, see VMware Workspace ONE and VMware Horizon Reference Architecture, which includes the following:

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

Initialize First Pod

  1. In Horizon Console, expand Settings 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. On the right, feel free to rename the federation by clicking the Edit button. This is the Federation, not the Pod.

    • Enter a new name.
  6. On the left, expand Settings, and click Sites.
  7. 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. Sites can contain multiple pods. Site is typically a geo location or data center.

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

    • Enter a Pod name.
  10. See VMware 2080522 Restoring View Connection Server instances in a Cloud Pod Architecture pod federation.

Additional Pods – Join Federation

  1. Connect to Horizon Console in the second pod.
  2. On the left, expand Settings, 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. On the left, expand Settings, and click Sites.
  8. If this pod is in a different site, then in the top half of the window click Add to create a new site.
  9. Give the site a name, and click OK.
  10. Highlight the first site.
  11. On the bottom, highlight the new pod, and click Edit.
  12. Rename the pod and put it in the 2nd site. Click OK.
  13. The top of Horizon Console 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

Global Entitlements contain one or more Local Pools from one or more pods. Connections to the Global Entitlement can be load balanced across the member pods and pools.

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 (i.e. don’t assign users). Instead, create a Global Entitlement and add the local pool to it.

  1. Before creating a Global Entitlement go to Inventory > Desktops or Inventory > Applications, click a pool name, scroll down to the Pool Settings section and record the settings. Your Global Entitlement must have the same settings.
  2. In Horizon Console, on the left, expand Inventory, and click Global Entitlements.
  3. On the right, click Add.
  4. In the Type page, select Desktop Entitlement or Application Entitlement, and click Next.
  5. In the Name and Policies page, give the entitlement (icon) a name. For Application Entitlements, it’s one Global Entitlement per application so include the application name.
    • Horizon 2006 and newer can specify a Display Name that is different than the name of the entitlement.
    • Horizon 2103 and newer can set a Federation Access Group to restrict administrator access to this Global Entitlement. You can create Federation Access Groups in the Horizon Console at Settings > Administrators, and on the right is a tab named Federation Access Groups. You can edit the Global Entitlement later to specify a Federation Access Group.
  6. Scroll down.
  7. Scroll down for more settings:
    1. You can configure tag restrictions (Connection Server restrictions) from this wizard.
    2. You can select a Category Folder where the published icon will be placed on the client’s Start Menu or Desktop. This feature requires Horizon Client 4.6 and newer.
    3. Configure Category Folder. You can type in a new folder or select an existing one. Specify whether the shortcut should appear on the Start Menu, Desktop, or both.
  8. Scroll down to the Policies section and configure the following. Note: these settings must match the Local Pool or you won’t be able to add the Local Pool to the Global Entitlement. Some of these settings can’t be changed without deleting the Global Entitlement and recreating it.
    1. For Desktop Entitlements, the User Assignment field (Floating or Dedicated) must match the Local Pools.
    2. Scope determines from which which site/pod the Local Pool is selected. Users connect to a specific Connection Server. Scope specifies if the Local Pool can be selected from any any pod in any site, from any pod in the same site as the Connection Server that the user connected to, or from the same pod as the Connection Server that the user connected to. For Dedicated Assignment pools, the user always connects to the assigned desktop no matter which Connection Server the user initially connected to.
    3. The Use home site checkbox tells the global entitlement to respect user home sites. When you assign a user to a home site, when the user launches the global entitlement, it tries to find a Local Pod in the same site as the user’s home site. This helps keep the user’s session close to the user’s data (e.g. home directory, roaming profile).
    4. Change the Default display protocol to VMware Blast. These settings must match the Local Pools.
    5. Horizon 2306 (8.10) and newer have a Session Distribution Policy to distribute sessions across the local resources in the Global Entitlement. Horizon 2309 (8.11) supports either Session Count or Load Index.
    6. For Desktop entitlements, you can allow users to Restart their machines or use Session Collaboration, or initiate separate sessions from different client devices. These settings must match the Local Pools.
    7. For Application entitlements, there’s 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. These settings must match the Local Pools.
    8. There’s 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.


    9. For Application Entitlements, there’s a selection for Multi-Session Mode. Pre-launch must be disabled to enable this setting.
    10. 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. Global Entitlements won’t work until you add some Local Pools to it. Make sure your Horizon Console is connected to the Pod that has the Local Pool.
  13. On the left, expand Inventory and click Global Entitlements.
  14. On the right, click the link for the name of the Global Entitlement. Global Entitlements are synced to every pod.
  15. Switch to the Local Pools tab and click Add.
  16. 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 Console browser to the other pod and edit the Global Entitlement from there.
  17. If the GUI won’t let you add the local pool then try it from the command line to see the actual problem. lmvutil parameter names are case sensitive. Some settings can only be changed by deleting the Global Entitlement and recreating it.
  18. Point your Horizon Console to another pod and view the Global Entitlements.
  19. On the right, click the hyperlink for the name of the Global Entitlement and follow the same procedure to add Local Pools. Horizon will automatically load balance user connections across all local pools based on the Scope policy (All Sites, Within Site, or Within Pod) in the Global Entitlement and Home Sites.
  20. 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 new Global Entitlement containing the backup pools.
      • The new Global Entitlement for backup should have the same settings as the production Global Entitlement.
      • You don’t have to assign anybody to the new Global Entitlement that will be the backup.
    2. Add Local Pools to the new Global Entitlement that will be the backup for when prod is down.
    3. Edit the production Global Entitlement.
    4. Scroll down to Backup Global Entitlement and click Browse.
    5. Change the selection to Backup Global Entitlement, select the Global Entitlement that will backup this one. Click Submit.
  21. Horizon Console, at Inventory > Desktops can show if a Local Pool is a member of a Global Entitlement. Scroll to the right to see the Global Entitlement column. This column doesn’t seem to be visible for Applications.


  1. Once Global Entitlements are enabled, a new Search Sessions node is added, which allows you to search for sessions across federated pods. Brokering Pod is the pod containing the Connection Sever that the user initially connected to to get the list of icons as opposed to the pod that contains the Local Pool that the session is actually launched from.
  2. The Monitor > Dashboard in Horizon Console shows the health of remote pods.

Home Sites

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

  1. Configure your Cloud Pod Architecture with multiple Sites and at least one Pod per Site.
  2. In Horizon Console, on the left, click Users and Groups.
  3. On the right, switch to the Home Site Assignment tab and click Add.
  4. Find a user or group for this home site, and click Next.
  5. Select the site to assign the users to and click Finish. This list of sites comes from your Cloud Pod Sites configuration.
  6. Home Sites can be assigned to both users and groups. User assignments override group assignments.
  7. Edit your Global Entitlement and ensure that Use Home Site is checked. You can optionally require that each user has a Home Site.
  8. 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.

  9. 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 for a specific Global Entitlement.

Related Pages

39 thoughts on “VMware Horizon 2312: Cloud Pod Architecture”

  1. Hello, Carl
    should the second server be a replica? If not, is it possible to make two connection servers in one asset directory?

  2. I have an existing cluster of two connection servers. I am wanting to implement the Cloud Pod Architecture so that users can connect to VMs at different sights. When I do the initialization, will it interrupt the functionality of the current setup (will users still be able to connect to their apps/VMs)?

    1. I don’t think it prevents new connections, but I haven’t explicitly tested it while initialization is happening.

  3. Hi Carl

    When using persistent disks in a cloud pod environment, is there anyway to replicate those disks from POD A to POD B, in order to create a “High-availability solution” ?

      1. Hi CArl,

        Your default configuration for FSlogix Cloud Cache is Direct connection ?

        Two situations were it’s a problem on our side :
        1) Duplicate session between POD1 and POD2 despite we disabled the possibility for a user to have multiple session… User connecting to the duplicate session cannot connect because of his profile connected still connected to the original VDI

        2) In case of a crash of the Datacacenter POD 2, the users previously connected to this POD2 still have a LOCK file in their fslogix profile. They are unable to open a session on the POD1 until we remove manually the lock file. (Goal a cloud cache is to have high avaibility but LOCK file didn’t permit to have it).

        Any advice?

        1. I usually configure Home Sites so individual users connect to the same site every day. Then if I need replication for FSLogix (not usually), then I replicate the entire file server to the other datacenter and have a recovery process if needed. Or I create new FSLogix profiles in the other datacenter. It’s a cost/benefit decision.

          1. In our case, most of time I configure two file servers, one in each datacenter. FSlogix Cloud cache take care of replicating the profile of all users on the two file server in real-time.
            The two PODS are in different datacenter and pools are configured in floating desktop mode. So no Home Site are configured and users can connect to a random site/Datacenter.

            But it does not change the problem that if the Datacenter become unavailable, the profil of users previously connected to the concerned datacenter keep a .lock file in their profile (replicated on the second File Server) until a manual delete.

            Any idea ?

  4. Carl, thanks for maintaining the single best online Horizon “how to” repo!

    Please add a fifth port requirement to the four already listed above to allow the “dynamic port range of 49152 through 65535 for PRC (sic) communication” between Connection servers for VDMDSG replication.
    Source: KB1027217 (scroll to the very bottom): https://kb.vmware.com/s/article/1027217
    The KB should read “RPC”.
    The ever-changing “Release Notes”, “CPA Port Requirements doc” and “VMware Horizon TCP and UDP Ports” docs on VMware’s websites all mention dynamic *RPC* port requirements, but they stop short of providing the reader with specifics, referring the reader to MS.
    For MS documentation regarding RPC replication ports, see:
    Ray Heffer is correct to say that TCP135, the RPC Endpoint Mapper port, is required. But he does not mention that the Endpoint Mapper then tells the client on which dynamic port (49152 through 65535) the RPC server service will listen for replication traffic.
    Long story short: TCP49152 through TCP65535 are required for ADAM_VMwareVDMDSG replication traffic betwen Connection servers in a CPA.

  5. Carl,
    I have an existing v7 CPA that I am wanting to upgrade to 8.2212. I built two new 2212 CS and added them to the CPA federation, however the subscription license has not populated into the new 2212 CS yet and has been several days. What am I missing.

  6. Hi Carl,

    Can a Global Entitlement span a 7.13 pod running Windows Server 2012 R2 and a pod running server 2016+ on Horizon 8.x?
    I ask as I know they use a different ADAM version, so not sure if they can co-exist. I can’t find any specific VMware article giving me direction either way.

  7. Hello Carl,

    “16. Select the local pools you want to add and click Add. Remember, only add one app per Global Entitlement.”

    So you mean I cannot add two apps from two Farms from two different vcenters (one local pool) in one Application Global Entitlment?

    I have two vCenters with one Horizon Connection Server in the first datacenter and Replica Server in the second datacenter (<1ms), how I need to fault tolerate an app in Horizon?


    1. I think you can add multiple local app pools to an app entitlement but the user only sees one icon. Normal Cloud Pod entitlement policies determine from which site the pod is chosen.

  8. Hi Carl,

    I have two pods, each in a separated Datacenter and I encounter some duplicated session accros the PODS. In short : A user connect to POD 1 for example, then disconnect and when he try to reconnect, horizon redirect him (don’t know why) to the POD2. Because of the direct access FSlogix profil, user cannot open a Windows session (lock file on POD 1).

    Did you already encounter this problem and have an idea to resolve it?

    Thank you very much !

  9. Hi Carl,

    It’s me again ! Thank you a lot for your answer about my above comment, i was not able to thank you because of maximum reply restriction 🙂

    I would have a last question, still in the same configuration (two Datacenter, two PODS, local datastore only).
    I read somewhere that we have no excuses to not use two vCenter because the licence is included with horizon environnement but..

    My question : Do you have an idea to handle only one Golden Image? I read above the replicate option but is there any other option maybe more accessible for the IT team of my customers?

    Thank you for your time !

  10. Hi Carl! what should i use for a DRP in my Horizon Environment? CPA, Site Recovery Manager or a mix of both? I have a pool of 50 VDI Instant Clone.

    1. Instant Clone gold images should be duplicated in both sites. You can maintain separate golden images in each site. Or update in one site and replicate to the other site.

      Then use Horizon Cloud to create pools in both sites. Power Management can keep the DR site powered off until you need it.

  11. Hi Carl, a customer is in the process of deploying CPA in 2 sites. They have existing manual pools in one site with dedicated users assigned to their respective desktop. After creating the Global Entitlement, is there any way to assign users to their existing desktop again? Thanks.

    1. Global Entitlement is composed of local pools. Are you saying that the local pools lose their user-to-desktop assignment when you add the local pool to a global entitlement?

  12. If I have 2 sites, each with a pod and each with a pool of vms, the scope is set to All Sites and no home site set, how does horizon select which vm the user is directed to?

    1. Create a Global Enetitlement with pools from multiple local pods and it will distribute users across those local pools.

      1. Hi Carl,
        Seems clear that Global Entitlement allow a spread of the sessions accros PODS in separated site.
        But what if my goal is to have an active active site with 100VM powered-on on each Datacenter and that one of the two DC goes down? Is there a way to automatically provision 100 new VM’s on the DC survivor ?
        From what I understand it’s not possible (global entitlement didn’t show any provisionning settings) and thus it will be better to avoid the PODS architecture and have a normal Horizon architecture with 200 VM spread on all the ESXi of the two DC and if the half goes down, horizon will automatically provision 100VM (because of machine catalog minimum provisionned vm setting) to the ESXi suvivors through the vCenter?

        1. Local Pools in Horizon have a Provisioning tab where you can set Max Machines, Spare Machines, and Min Number of Machines. You can tweak those settings to spin up more machines when more are needed.

          Global Entitlements support a Backup Global Entitlement.

          1. Unfortunately local pools are not usefull. I don’t want 200Vm’s on each DC running everytime but only when one DC goes down to work in a “degraded” mode (DC survivor temporary over provisioned).

            Concerning Backup Entitlement I thought that it would be the answer but it seams that it’s only a backup when the global entitlement failed. In my case it will not be the case because one DC will continue to work with 100 VM’s. And as already said before we cannot configure any provisioning settings in global or backup entitlement so it will only redirect users to the surviror horizon POD who doesn’t have enough VM’s.

            I would really like a “global machine catalog” with 400 min machine and with 200 min powered-on machines configured spread over the two DC. When one DC goes down the min powered machine is no more reached and the 100 machines sleeping in the DC survivor will be powered-on automatically for the users that will be redirected.

          2. Set two local pools with 200 max each, and 100 minimum. Global Entitlement should spread users across the two local pools. If one not available, then the remaining one should create more VMs up to 200 max.

            Horizon Cloud supports multi-pod desktop pools. I’m not sure if that’s any different than setting min/max on local pools.

  13. Hi Carl, I am planning to deploy 2 pods and I want all users VDI sessions to distribute across two pods randomly. My doubt is, if one user is already logged in to a session from Pod1, and same user try to attempt to login from another device, user will get same active session or request may reach to pod2 connection server and get another desktop? Is it have mechanism to redirect request to same active session even if request will go to pod2 connection server?

    1. If the user tries to access a pool that the user is already logged into then it will reconnect to the existing session. Otherwise it depends on your Global Entitlement scope policy. If set to All Sites, then I think it will pick a machine randomly from all sites. You can change it to Same Site to only connect to machines in pods that are in the same as as the Connection Server that the user authenticated with.

  14. Hi Carl, how does initializing a pod affect an existing single pod setup? Will the users notice any difference in either the Horizon client or HTML5 client?

Leave a Reply

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