13. June 2026

AVD Discovery and Requirements: The Foundation of a Good AVD Design

AVD projects shouldn’t start with VM sizing, host pool creation, or application publishing.

They should start with discovery. This phase is closely linked to the planning phase and you will use the planning decisions to help you start looking at the areas that need discovery and how to document them.

Before any design decisions are made, it’s important to understand who will use the platform, how they work, what applications they need, what data they access, where they connect from, and what security and operational requirements must be met.

That means a good AVD design needs more than technical assumptions. It needs clear requirements.

Discovery is More Than Counting Users

As mentioned in the last article, treating the planning phase as a quick 10 minute meeting to say you want to move to AVD is the biggest mistake you can make. Likewise, treating the discovery phase as an exercise in counting users will ensure that your AVD environment will cause you multiple headaches for a long time..

For example:

“We have 500 users, so we need enough session hosts for 500 users.”

That sounds logical, but it’s too shallow.

A proper discovery process asks more detailed questions:

What types of users do we have?
Do they all need the same desktop experience?
Which users need full desktops and which only need RemoteApps?
Which applications are business-critical?
Are any applications sensitive to latency?
What backend systems do those applications connect to?
Where is the data stored?
How do users authenticate?
Are users working from corporate devices, personal devices, thin clients, or shared machines?
What are the security, compliance, backup, and DR requirements?

Without this information, the design can quickly become a best guess. And with AVD, guesswork often leads to poor performance, frustrated users, increased cost, and redesign later in the project.

Understanding User Personas

A strong AVD discovery phase should begin by identifying user personas.

Not every user works in the same way, so not every user should automatically receive the same desktop.

Typical AVD personas may include:

This helps avoid the common mistake of designing one generic desktop for everyone.

Some users may need a full desktop. Others may only need published applications. Some may need dedicated host pools. Others may be fine in a shared pooled environment.

The goal is to design around how people actually work. You may have several of these user personas within the organisation and not actually realised it. The discovery phase will give you a clear understanding of how your users are working and their requirements.

Application Discovery

Applications are often where AVD projects become complicated.

It’sn’t enough to know the names of the applications your using. You need to understand how they behave, what they depend on, and whether they are suitable for a multi-session desktop environment.

Application discovery should include:

Application name and owner
Business criticality
User groups that need access
Installation method
Licensing model
Compatibility with Windows multi-session
Backend dependencies
Authentication method
Database or file share dependencies
Printing or peripheral requirements
Update and patching process
Vendor support agreements

This is especially important for legacy applications. Some may rely on mapped drives, hardcoded paths, old authentication methods, certificates, local admin rights, or specific network routes.

If these dependencies are missed during discovery, they usually appear later as deployment blockers.

This is the part that can catch out many organisations as they start to discover just how many apps they actually have and can realise that many either aren’t used or they’ve long been neglected.

I’ve seen it many times where a business critical application needs to be moved to AVD and no one knows where the install files are or how to install it and the vendor shut up shop years ago so there’s no help to be had. The application discovery phase can often be a painful wake up call for many organisations.

Data Access and File Share Dependencies

AVD users rarely work in isolation. Their applications need access to data.

That data may sit in:

On-premises file servers
Azure Files
SQL databases
SharePoint
SaaS platforms
Line-of-business systems
Legacy application servers

During discovery, it’s important to map which users and applications need access to which data sources.

For example, if an application published through AVD needs to access an on-premises file share, the design must account for identity, permissions, DNS, routing, latency, and authentication.

This is where AVD design quickly becomes wider than just desktops.

A session host may be in Azure, but the data may still be on-premises. That makes network design, hybrid identity, and application dependency mapping critical.

Identity and Authentication

Identity is one of the most important areas in an AVD deployment.

Discovery should capture how your users authenticate today and how they should authenticate in the future.

Key areas to review include:

Active Directory Domain Services
Microsoft Entra ID
Hybrid identity
Multi-factor authentication
Conditional Access policies
Single sign-on requirements
Domain join model for session hosts
Access for external or third-party users
Privileged admin access
Service accounts
Legacy authentication dependencies

A poor identity design can create user frustration, security gaps, and application access issues.

For example, users may be able to sign into AVD successfully but then fail to access a backend file share or application because Kerberos, permissions, DNS, or network access were not correctly understood.

The discovery phase should expose these requirements early.

Network and Connectivity Requirements

AVD performance depends heavily on network design.

During discovery, you need to understand both sides of the connection:

User access into AVD
Session host access to backend services

This includes questions such as:

Where are users connecting from now? Are they office-based, remote, branch-based, or global?
What devices are they using? E.g. Laptops (corporate or BYOD), thin clients
Is traffic routed through VPNs, firewalls, or proxies?
Do session hosts need access to on-premises applications?
Is DNS resolution working across Azure and on-premises?
Are there latency-sensitive applications?
Is internet breakout controlled or inspected?
Is there a hub-and-spoke network design already in place?

AVD may use Microsoft’s control plane, but the user experience is still heavily influenced by network routing, latency, DNS, and access to application dependencies.

A good discovery phase identifies these constraints before the design is finalised.

Security and Compliance Requirements

Security should be captured during discovery and built into the design from the start.

Security discovery should include:

User access current requirements
MFA usage
Device compliance rules
Data protection requirements
Clipboard, drive redirection, and printing controls
Local admin restrictions
Privileged access management
Logging and monitoring
Defender for Cloud integration
Security baseline requirements
Compliance obligations

Different user groups may need different controls.

For example, a finance team accessing sensitive data may require stricter session controls than a general task worker group. External users may need more restricted access than internal employees. Privileged administrators may need separate host pools, stronger monitoring, and tighter role-based access controls.

Discovery helps identify these differences before the platform is built.

Operational Requirements

A successful AVD deployment isn’t just one that works on go-live day.

It needs to be supportable.

The discovery phase should capture who will own and operate the platform after deployment.

This includes:

Who manages images?
Who patches session hosts?
Who monitors performance?
Who handles user support?
Who manages FSLogix profiles?
Who responds to security alerts?
Who owns application updates?
Who manages scaling plans?
Who reviews cost optimisation?
Who owns backup and disaster recovery?

These questions are often overlooked, but they are essential.

Without a clear operating model, AVD can become difficult to manage after the initial project team has moved on.

Practical Outputs from the Discovery Phase

A good discovery phase should produce clear outputs that feed directly into the planning and design stages.

Typical outputs include:

These outputs help turn discovery into something useful.

Discovery shouldn’t just produce a long list of notes. It should create structured information that directly supports the AVD design.

Discovery Reduces Risk

The value of discovery is simple: it reduces risk.

It helps prevent situations such as:

Users being placed in the wrong host pool
Session hosts being undersized
Applications failing due to missing dependencies
File shares being inaccessible
Authentication issues appearing during testing
Poor performance due to network routing
Security controls being applied too late
Support teams not knowing who owns what
Costs increasing because capacity was poorly planned

Good discovery doesn’t guarantee a perfect deployment, but it significantly improves the quality of the design decisions that follow.

…and finally

The discovery phase is where an AVD project moves from assumption to evidence. It should build on the planning phase so you know where you need to start looking for discovery.

It gives architects, engineers, project teams, security teams, application owners, and business stakeholders a shared understanding of what the platform currently has and needs to deliver.

Without discovery, AVD design becomes guesswork. Creating a workload assessment to document the details from the discovery phase enables you to document your findings in a central location.

For service providers, working with the customer closely on the discovery phase ensures that there are no issues during the designing and implementation phases and a smooth production rollout.

With discovery, the design can be shaped around real users, real applications, real dependencies, real risks, and real business requirements. That is the foundation of a good AVD deployment.

In the next part of this series, we will look at the designing phase and how the discovery phase feeds into that. Get the design phase wrong and prepare for months of headaches!