Understand shared responsibility
Good preparation distinguishes what Microsoft manages from what the organization must design, operate, monitor, and protect. The pilot should test that complete chain.
A pilot is not productionIts purpose is to test architecture assumptions, not merely connect users.
User experience is end-to-endIdentity, network, profile, image, and applications jointly shape the outcome.
Every decision needs an ownerWithout ownership, the pilot creates technical and operational debt.
Before the first session
An AVD pilot starts with architecture decisions
Azure Virtual Desktop provides managed control-plane components, while the organization remains responsible for session hosts, images, profiles, networking, identity, and recovery of its resources.
Decision framework
7 decisions before the pilot
Each area should end with a documented decision, a named owner, and an acceptance criterion.
01
Host pool and user persona strategy
Segment users into real personas and decide personal or pooled host pools, desktop or RemoteApp, session density, and the load-balancing approach.
Which users require a persistent personal desktop?
Which application limits session density?
Deliverable: Persona matrix, host-pool map, and sizing assumptions.
02
Identity, join type, and access controls
Define Microsoft Entra joined or hybrid joined session hosts, group-based assignments, MFA, Conditional Access, SSO, and privileged administration.
Is connectivity to identity services reliable?
Which Conditional Access exceptions are genuinely required?
Deliverable: Identity flow, access model, and security approval.
03
Network, DNS, and connectivity
Design the AVD spoke, address space, subnet capacity, DNS, access to on-premises services, egress inspection, and RDP Shortpath where required.
Which application flows cross the datacenter boundary?
Have latency, bandwidth, and required endpoints been validated?
Deliverable: Network flow matrix, IP plan, and validated connectivity.
04
FSLogix and user data
Choose profile-container storage based on capacity, performance, availability, cost, and recovery. Separate profile, user data, and application data decisions.
What are the real profile size and growth rate?
What happens to the profile during a regional outage?
Deliverable: Profile design, storage sizing, and recovery approach.
05
Golden image and application lifecycle
Define the image source, build process, application packaging, security baseline, testing rings, update cadence, and rollback for a problematic image.
Who approves a new image version?
How are business-critical applications tested?
Deliverable: Image pipeline, ownership, and release runbook.
06
Monitoring, scaling, and cost governance
Enable diagnostics, AVD Insights, alerts, and KPIs. Agree the scaling plan, capacity buffers, tagging, budgets, and cost ownership.
Which metrics prove a good user experience?
How much capacity remains available at peak periods?
Deliverable: Monitoring baseline, scaling plan, and cost model.
07
Business continuity and pilot success
Agree failure scenarios, RTO/RPO, the secondary-region pattern, profile and data resilience, failover ownership, and test cadence. Define measurable acceptance criteria.
Which personas require DR, and how quickly?
Who signs off pilot acceptance?
Deliverable: BCDR decision, pilot scorecard, and go/no-go criteria.
Architecture baseline
The minimum architecture baseline
The pilot should fit a landing-zone model rather than operate as an isolated proof of concept.
Identity
Join model, assignments, Conditional Access, MFA, RBAC, and privileged access.
Network
Spoke design, DNS, hybrid connectivity, egress, firewall, and latency.
Profiles & Images
FSLogix storage, image factory, application packaging, and update rings.
Operations & DR
Insights, alerts, autoscale, budgets, backup, and tested DR runbooks.
Practical principle: Do not change join type, profile platform, or network topology after onboarding starts without assessing downtime, parallel build, and migration effort.
Readiness gate
Pilot readiness checklist
The pilot is ready when decisions are known and tests measure specific outcomes.
User personas and host-pool types are approved
Join model and identity connectivity are tested
Conditional Access, MFA, and admin roles are defined
AVD subnet, DNS, routing, and egress are validated
FSLogix capacity and performance assumptions are measured
Golden image and update/rollback process are available
AVD Insights, alerts, and operational owners are active
Pilot KPIs, BCDR assumptions, and acceptance owners are agreed
The pilot should reduce uncertainty — not merely produce desktops.
Start with representative personas and applications, measure user experience and operations, and finish with a documented go/no-go decision.
Documentation