End-to-End User Connection Workflow in a Cloud Pod Architecture Environment

The preceding topics describe the pieces of Cloud Pod Architecture individually. This topic walks through what actually happens, step by step, from the moment an end user connects until they are looking at a remote desktop or published application.

1. The user starts Horizon Client (or a browser) and connects to a server URL. This may be the address of a specific Unified Access Gateway or Connection Server instance, or a single DNS name that a load balancer or DNS service resolves to the nearest pod. Whichever Connection Server instance the client reaches first is referred to elsewhere in this guide as the connecting pod or brokering pod.
2. The user authenticates. Authentication happens against the connecting pod, using Active Directory credentials or, if Workspace ONE mode is enabled, by first being redirected to log in through Omnissa Access. Users who are configured for unauthenticated access skip this step for application entitlements.
3. The connecting pod resolves the user's entitlements from the Global Data Layer. Because global entitlements are replicated data, the connecting pod does not need to contact any other pod to know which global desktop and application entitlements the user (directly, or through group membership) belongs to. At this point the Connection Server restrictions and client restrictions policies are also evaluated: an entitlement whose tags do not match the connecting Connection Server instance's tags, or whose client-restriction group does not include the user's device, is filtered out of the list before the client ever sees it.
4. Horizon Client displays the remaining global entitlements to the user, along with any configured shortcuts. The user selects one.
5. The connecting pod determines where to start looking for a resource. If the global entitlement has Use Home Site enabled, the search starts at the user's home site — either their own global home site or, if one is configured, the per-entitlement home site override, which takes precedence. If no home site applies, the search starts at the site the user is currently connected to.
6. The connecting pod applies the global entitlement's scope policy to decide how far the search is allowed to extend outward from that starting point: only the connecting pod (Within Pod / LOCAL), any pod in the same site (Within Site / SITE), or any pod in the entire federation (All Sites / ANY).
7. The search itself runs local-first, then outward. If a matching desktop or application pool with available capacity exists in the local pod, it is used. Otherwise, the connecting pod uses VIPA to query peer Connection Server instances in progressively wider scope — first the rest of the local site, then other sites, in preference order — until a resource is found or the allowed scope is exhausted. If a Session Load Distribution policy (Load Index, Session Count, or None) is configured, the search picks the least-loaded pool or farm within the least-loaded pod, according to that policy.
8. For a dedicated desktop entitlement, this search-and-allocate sequence happens only once per user. After a specific desktop is first assigned, every later connection — from this site, another site, or another device — is brokered directly back to that same desktop, bypassing the scope/home-site search. Floating entitlements repeat the full search on every connection.
9. The pod that owns the chosen resource prepares the session (powering on or unlocking the virtual machine, or accepting a new RDS session), and the connecting pod relays the connection details back to Horizon Client.
10. Horizon Client opens the display-protocol session (Blast or PCoIP, per the entitlement's protocol policy) directly against the resource-owning pod — typically through the Unified Access Gateway appliance paired with that pod, which may or may not be the same appliance the user first connected through in step 1.
11. The new session is recorded back into the Global Data Layer, which is why it is immediately visible from Horizon Console on any pod, tagged with the user, the hosting pod, the brokering pod, and the site.
12. If the user disconnects and later reconnects, the connecting pod checks the Global Data Layer for an existing session anywhere in the federation before starting a new search, and reconnects the user to it if one is found. Multiple sessions can still arise — for example if a pod hosting a session goes offline and the user starts a new one elsewhere — in which case Horizon Client prompts the user to choose a session, and the Automatically Clean Up Redundant Sessions policy determines whether the sessions the user does not pick are cleaned up automatically or left for manual logoff.
13. If Home Site Redirection is enabled, a user who connects to a site other than their designated home site is transparently redirected to their home site's URL without being asked to reauthenticate through the Unified Access Gateway, reducing backhaul traffic.

The health-insurance sales-agent scenario in Example: How to Set Up a Basic Cloud Pod Architecture Configuration walks through this same sequence with concrete pod, site, and entitlement names, and is a useful companion to the steps above.