VDI Architecture: The Universal Building Blocks

One Architecture, Many Logos

Open the Azure portal, the Citrix Cloud console, and Omnissa Horizon Console side by side and they look nothing alike. But underneath, every one of them is solving the same problem with the same five parts: a control plane/broker that makes decisions, a gateway/access layer that moves traffic securely, session hosts that do the actual computing, golden images that define what those hosts look like, and a profile layer that makes a shared or disposable host feel personal to one user. Learn this shape once and you can read any vendor’s documentation faster, because you’re mapping their terminology onto a structure you already understand.

Building Block 1: The Control Plane / Broker

The broker is the brain. When a user requests a desktop or app, the broker is what decides: is this user entitled to this resource, and which specific session host should serve them right now? Concretely, the broker:

• Validates the user’s identity and checks their entitlement (are they a member of the group assigned to this desktop/app group?)
• Tracks the real-time state of every session host in a host pool — powered on or off, current session count, health
• For non-persistent/pooled desktops, decides whether to reconnect the user to an existing disconnected session or place them on a fresh host
• Issues a connection ticket that authorizes the client to connect to a specific host

In Azure Virtual Desktop, this is the AVD service’s broker component (fully Microsoft-managed — you never see or patch it). In Citrix DaaS, this is the Delivery Controller function, exposed through Citrix Cloud. In Omnissa Horizon, this is the Connection Server role. Different names, identical job.

Building Block 2: The Gateway / Access Layer

The gateway is the front door between the outside world and your session hosts. Its defining property in every modern cloud-delivered platform is reverse connect: the session host initiates an outbound connection to the service, so administrators never need to open an inbound port on the host itself. The client also connects outbound to the same gateway, and the service brokers the two together.

This matters operationally: a session host sitting in a private subnet with no public IP and no inbound firewall rule can still serve users anywhere in the world, because it reached out first. AVD’s gateway is Microsoft-managed. Citrix uses Citrix Gateway service (cloud) or on-prem Citrix ADC/Gateway appliances. Omnissa Horizon uses the Unified Access Gateway (UAG). Same job, three names.

Building Block 3: Session Hosts

Session hosts are where the actual computing happens — the VM (or, in RDS-style deployments, the shared server) that runs the desktop OS and applications the user interacts with. They can be:

• Personal/persistent — one dedicated VM per user, state preserved between sessions
• Pooled/non-persistent — a shared pool of interchangeable VMs, any of which can serve any entitled user, typically reset to a clean state on logoff

Session hosts register themselves with the broker so it knows they exist and are healthy — which brings us to agent-based vs. agentless registration, covered below.

Building Block 4: Golden Images

A golden image is the standardized template — OS version, patches, agents, line-of-business applications, security tooling — that every session host in a pool is built from. Instead of hand-configuring a thousand VMs, you build and validate one image, version it, and roll it out. This is what makes fleets of identical, disposable session hosts practical: when something’s wrong, you don’t troubleshoot the VM, you rebuild it from a known-good image. Azure Compute Gallery, Citrix Machine Creation Services (MCS) templates, and Omnissa’s Instant Clone parent VMs are all implementations of this same idea — you’ll go deep on image management in Module 3.

Building Block 5: The Profile Layer

If golden images make every host identical, the profile layer is what makes each session feel personal despite that. It carries the user-specific state — documents, application settings, browser profile, taskbar pins — separately from the OS, typically as a mountable container attached at logon. This is what allows a genuinely stateless, disposable pooled host to still feel like ‘my desktop’ to the person using it. FSLogix (Microsoft), Citrix Profile Management, and Omnissa Dynamic Environment Manager (DEM) are the concrete tools here — Lesson 4 of this module is dedicated entirely to this layer.

The Full Connection Flow

Putting the five blocks together, here is what happens end to end when a user connects to a pooled desktop:

1. User opens the client (native app, Windows App, or a browser) and requests their feed of available desktops/apps.
2. Authentication happens against the identity provider (Microsoft Entra ID, Active Directory, or a Citrix/Omnissa-integrated identity source).
3. The broker evaluates entitlement and host pool state — is this user allowed here, is there a disconnected session to reconnect to, which healthy host has capacity — and selects a target session host.
4. A connection ticket is issued to the client, authorizing a session to that specific host.
5. The client connects through the gateway/access layer, which relays the session so the host needs no inbound port open.
6. The session lands on the session host, and the profile layer mounts the user’s profile container, so documents and settings appear as if local.
7. The display protocol takes over (Lesson 3 covers this in depth), streaming the desktop and carrying input back.

Agent-Based vs. Agentless Registration

How does the broker know a session host exists and is healthy? Two models:

• Agent-based: a platform-specific service runs on every session host (the AVD agent, the Citrix Virtual Delivery Agent/VDA, the Omnissa Horizon Agent) and maintains a live heartbeat connection to the broker, reporting health, session count, and readiness. This is the dominant model today because it gives the broker rich, real-time state independent of the underlying hypervisor.
• Agentless: the platform instead leans on the hypervisor’s or cloud provider’s own APIs to infer host state (is the VM running, is it responding to health probes), without a dedicated agent service. This trades some richness of signal for a smaller footprint on the host.

In practice, almost every production VDI platform you’ll operate — AVD, Citrix DaaS, Omnissa Horizon — uses agent-based registration for session hosts, because the agent is also what plumbs the display protocol, redirection channels, and management commands. Keep the term in mind, though: you’ll see “agentless” architecture discussions come up when comparing lighter-weight or browser-only remote access tools against full VDI platforms.

Once these five blocks and this connection flow are second nature, every platform-specific lesson later in this course becomes a matter of learning what a vendor calls each part — not learning a new architecture from scratch.