Deploying AVD: From Pilot to Production
The Pilot Is Part of the Deployment
An AVD pilot should not be viewed as a demonstration environment or a miniature version of production.
It is a structured exercise designed to uncover assumptions before those assumptions become widespread incidents.
The pilot should use the same architectural principles, security controls, identity model, profile technology and operational processes intended for production. Where the pilot differs in scale, those differences should be clearly documented so that they do not hide potential capacity or performance problems.
Before users are introduced, the pilot should have:
- An agreed scope and set of success criteria
- Defined user personas
- Representative applications and data sources
- A production-aligned session host image
- Profile storage and FSLogix configuration
- Security and endpoint management policies
- Monitoring, logging and alerting
- A support and escalation process
- A documented rollback approach
AVD Insights uses Azure Monitor Workbooks and Log Analytics to provide visibility into the environment. This should be configured before the pilot begins rather than added after users report problems.
Select Representative Pilot Users
One of the most common pilot mistakes is selecting only technically confident users from the IT department.
IT users are useful during the first stage, but they rarely represent the full range of business activities, application dependencies, working locations and peripheral requirements found across an organisation.
Pilot participants should be selected from each of the personas identified during discovery.
For example:
- Task workers who use a limited number of transactional applications
- Knowledge workers who use Microsoft 365, Teams, browsers and line-of-business applications
- Power users who require greater CPU, memory or application performance
- Developers and technical users who require development tools, administrative utilities or access to controlled environments
- Remote and mobile users connecting across different network conditions and endpoint types
- External users or contractors who may have different identity and device-trust requirement
- Privileged users who require tightly controlled access to administrative systems
The way I’ve always approached the initial pilot testing (all the way back to RDS and Citrix deployments) is to choose the pickiest users who are the most likely to complain. This may not be counter intuitive as you want an easy testing, but if you pick these users, you know they’ll let you know every issue and bug that needs tweaking so that the production should (in theory at least!) run more smoothly.
What the Pilot Must Validate
The pilot should validate complete user journeys rather than individual infrastructure components.
A successful VM deployment doesn’t prove that users can perform their jobs. Testing should begin when the user opens the client and continues until they have completed their normal business processes and signed out successfully.
1. Login and Connection Times
Login testing should measure more than the total time between entering credentials and seeing a desktop.
The deployment team should understand where time is being spent, including:
- Authentication and Conditional Access
- Session host selection
- Group Policy or Intune policy processing
- FSLogix profile attachment
- Login scripts and mapped drives
- Application initialisation
- Start menu and desktop loading
Testing should include both first-time and returning users because the experience may differ significantly.
Results should be recorded by persona, location, endpoint type and host pool. A single average can hide users who are experiencing unacceptable delays.
2. Profile Performance
FSLogix profile containers provide a roaming profile solution for virtual desktop environments, but their performance still depends on storage design, authentication, network connectivity and configuration.
The pilot should validate:
- Profile creation
- Profile attachment and detachment
- Sign-in and sign-out performance
- Outlook and Microsoft 365 cache behaviour
- Profile exclusions.
- Recovery from an incorrectly disconnected session
- Behaviour when the profile location is unavailable
- Storage capacity, latency, throughput and IOP
- Administrative access and support procedures
Profile testing should also confirm that users receive a consistent experience when they connect to different session hosts.
A profile that works for five pilot users doesn’t automatically prove that the storage platform will perform under production concurrency. Capacity modelling and load validation must still be completed.
3. Application Behaviour
Applications should be tested using real business workflows rather than simply confirming that the executable opens.
Application test scripts should include:
- Launch and sign-in
- Licensing and activation
- Application add-ins.
- Database connectivity
- Printing and document generation
- Links between applications
- Performance under expected session density
- Behaviour after the session host image is updated
For RemoteApp deployments, additional testing should confirm that application windows, file associations, notifications, authentication prompts and links to other applications behave correctly.
Where an application depends on a particular server, port, protocol, identity or file path, that dependency should be included in the test script rather than left as undocumented knowledge.
4. File and Data Access
File access testing should cover every location required by the applications and users.
This may include:
- Azure Files
- On-premises SMB file servers
- SharePoint and OneDrive
- Application data shares
- Legacy UNC paths
- Mapped drives
- FSLogix profile shares
Testing should confirm:
- DNS resolution from the session host subnet
- Network routing through firewalls, private endpoints, VPNs or ExpressRoute
- Authentication and Kerberos behaviour
- Share-level and NTFS permissions
- Read, write, modify and delete operations
- Performance when opening and saving large files
- Behaviour during a temporary connectivity interruption
Testing only with an administrative account can conceal permission problems. The tests should use the same identities and group memberships that production users will have.
5. Printing and Peripheral Devices
Printers and peripherals are often dismissed as minor details until they prevent a department from completing an essential process.
AVD can redirect resources such as printers, webcams, microphones, smart cards, USB devices and the clipboard between the endpoint and remote session. The resulting behaviour can depend on the client, operating system, host pool RDP properties, Group Policy and Intune configuration.
Testing should therefore cover the actual devices used by each persona.
Security and usability must be considered together. Enabling every redirection may create unnecessary risk, while disabling all redirection may make important business processes impossible.
The pilot should establish the minimum set of redirections required by each user group.
6. Security Policies
The pilot must confirm that security controls work without preventing legitimate business activity.
Validation should include:
- MFA/Conditional Access
- Device compliance requirements
- Role-based access control
- Privileged Identity Management
- Session timeout and lock policies
- Endpoint protection
- Local administrator restrictions
- Access to management interfaces
- Audit logging
Policies should be tested with standard users, support personnel and privileged administrators.
It is particularly important to test the combined result of different policy layers. A host pool property may permit a feature while Group Policy or Intune blocks it. For several redirection settings, the more restrictive configuration determines the resulting behaviour.
7. Monitoring and Alerts
Monitoring should be tested in the same way as an application or profile.
It isn’t enough to confirm that logs are being collected. The team must prove that meaningful events result in visible and actionable alerts.
Moving from Pilot to Production
The transition to production should be broken into controlled rollout stages.
Each stage should have defined entry criteria, test activities, exit criteria, support arrangements and rollback triggers.
Stage 1: Technical Pilot
The technical pilot is primarily used by the AVD engineering, infrastructure, security and support teams.
Its purpose is to validate:
- Resource deployment
- Host pool configuration
- Identity and domain integration
- Session host registration
- Image deployment
- Policy application
- FSLogix attachment
- Application installation
- Network routing
- Monitoring and alerting
- Administrative and support access
The technical pilot should resolve fundamental platform issues before business users are introduced.
Exit criteria
The environment can be deployed repeatedly, users can connect securely, core services operate correctly and the support team has sufficient visibility to diagnose problems.
Stage 2: Business Pilot
The business pilot introduces a small number of representative users from each agreed persona.
Its purpose is to validate normal working practices, application workflows, data access, peripherals and user experience.
Structured feedback sessions should be held throughout the pilot. Feedback should be categorised rather than placed into a single list:
- Service-blocking defects
- Performance issues
- Configuration defects
- Training requirements
- User preference requests
- Future enhancements
Not every preference should block production. However, any issue preventing users from completing a critical business process should have a clear resolution or accepted workaround.
Exit criteria
Representative users can complete agreed business processes, critical defects have been resolved and remaining risks have named owners and approved treatment plans.
Stage 3: Early Adopter Rollout
Early adopters are the first users to move onto the service as their primary working environment.
They should be comfortable providing detailed feedback, but they must still represent genuine business workloads. An early adopter phase composed entirely of technology enthusiasts may produce misleading results.
During this stage, the organisation should validate:
- Day-to-day support demand
- Incident categorisation
- Knowledge articles
- User communications
- Training materials
- Image servicing
- Application change processes
- Operational handovers
- Capacity and scaling assumptions
Exit criteria
The platform is stable during normal operation, support processes are working, recurring incidents are understood and the operational team can manage the service without relying entirely on the project team.
Stage 4: Departmental Rollout
Users should then be migrated in planned departmental or functional waves.
Moving complete teams can simplify support and reduce confusion, but some departments may need to be divided where applications or working practices differ significantly.
Each rollout wave should be followed by a short stabilisation period before the next wave begins.
Exit criteria
The department has migrated successfully, critical workflows are operating, support demand is within agreed limits and no unresolved issue creates unacceptable risk for the next wave.
Stage 5: Full Migration
Full migration should only begin after the previous rollout stages demonstrate that the service is technically stable and operationally supportable.
The legacy environment should not be decommissioned until rollback periods have expired, data has been validated, dependencies have been removed and formal approval has been obtained.
Practical Deployment Outputs
A safe AVD rollout should produce a set of reusable operational documents.
Pilot Plan
The pilot plan should define:
- Scope
- Participants
- Personas represented
- Applications included
- Test locations and devices
- Pilot schedule
- Success measures
- Known exclusions
- Support arrangements
- Risk owners
- Entry and exit criteria
Rollout Wave Plan
The rollout plan should identify:
- Users and departments in each wave
- Migration dates
- Dependencies
- Communication dates
- Training requirements
- Support coverage
- Change freezes
- Rollback window
- Approval owner.
The plan should also show why each group has been placed in its particular wave.
Rollout waves are usually only for the larger deployments with hundreds or even thousands of users. For a smaller company of say, 100 users, it may be a tad overkill.
Rollback Plan
Rollback should be designed before deployment, not invented during an incident.
The rollback plan should identify:
- What conditions trigger rollback
- Who can authorise it
- How users return to the previous platform
- How application and profile data are protected
- How partially completed migrations are handled
- How access assignments are reversed
- Which image version will be restored
- How users are informed
- How the incident is reviewed before another attempt
Not every issue requires a complete rollback. The plan can include options such as removing a single image version, pausing a rollout wave, returning one department to the previous service or isolating an affected application.
Go/No-Go Checklist
Before each production wave, the programme should hold a formal go/no-go review.
A rollout should proceed only when:
- The required users and applications are in scope
- The approved image version has passed testing
- Login and profile performance are within agreed thresholds
- Required file shares and data services are accessible
- Printing and peripherals have been validated
- Teams and media optimisation are working
- Security policies have been tested
- Monitoring and alerts are active
- Capacity is available for the migration wave
- Support teams are prepared
- User communications have been issued
- The deployment runbook has been reviewed
- Rollback has been tested or rehearsed
- Critical defects are closed
- Remaining risks have been formally accepted
- Technical and business owners have approved the release
A no-go decision should not be viewed as project failure. It is evidence that the governance process is doing its job.
…and finally
An AVD deployment isn’t successful because the resources were created or because the planned migration date was reached.
It is successful when users can complete their work securely, reliably and with an acceptable experience and when the organisation can operate, monitor, support and change the service after the project team steps away.
Moving from a technical pilot to a business pilot, early adopters, departmental waves and finally full migration gives the organisation multiple opportunities to identify problems while their impact is still limited.
Infrastructure as code, image pipelines, policy as code and controlled deployment pipelines then make the process repeatable.
The safest AVD deployments are not the ones that encounter no problems. They are the ones designed to discover problems early, respond consistently and prevent the same issue from reaching the next rollout wave.
This follows naturally from the earlier articles on discovery, architecture, identity, applications, profiles and backend file access, while setting up the next stage: operating, monitoring and continuously optimising the production AVD service