13. June 2026

AVD Planning - Why it needs to be properly considered

AVD is often described as a way to deliver desktops and applications from Azure. Technically, that’s true. But treating AVD as simply “deploying some session hosts and publish a few apps” is where many projects start to go wrong.

AVD is not just a collection of virtual machines.

It’s a full end-user compute platform that depends on identity, networking, storage, security, application delivery, monitoring, support processes, cost control, backup, disaster recovery, and operational ownership.

That means successful AVD deployments start with proper planning, not with VM sizing.

Start with business requirements, not infrastructure

One of the biggest mistakes in AVD projects is jumping straight into technical design questions:

“How many session hosts do we need?” “What VM size should we use?” “How many users per host?” “Should we use pooled or personal desktops?”

These are important questions, but they shouldn't be the starting point.

The first questions should be business-focused:

Who will use the platform?
What do they need to do?
Where will they connect from?
What applications do they need?
What data do they access?
What performance expectations do they have?
What security controls are required?
Who will support the service once it is live?

AVD should be designed around the users and the workloads, not around assumptions about infrastructure. I’ve seen the same problem on different platforms over the years, whether it be RDS, Citrix or Horizon. Too much emphasis is put on what and not the why.

Not all users need the same AVD experience

A common trap is designing one host pool, one image, one application set, and one standard configuration for everyone. In reality, different user groups often may have very different requirements.

For example:

Task workers may need a lightweight desktop with a small number of published applications.
Developers or technical users may need more CPU, memory, admin tooling, or persistent settings.
Finance teams may need access to specific applications, sensitive data, and stricter security controls.
Contact centre users may need predictable performance, audio optimisation, and carefully controlled session behaviour.
Third-party users may need tighter access restrictions, conditional access policies, and limited application visibility.

Trying to force all of these users into one standard AVD design can create performance issues, security gaps, poor user experience, and unnecessary cost.

Good AVD planning should identify user personas early and use them to shape the design.

What Should Be Planned Before Deployment?

Before deploying session hosts, the project should work through the main design areas that will influence the success of the platform.

User Personas

Define the different types of users who will consume the service.

This should include the applications they use, their working patterns, performance expectations, location, security requirements, and whether they need a full desktop or only published apps.

Application Requirements

Applications are often the real driver of AVD design.

You need to understand which apps are required, how they are installed, whether they support multi-session use, whether they have dependencies, and whether they need access to back-end databases, file shares, printers, APIs, or legacy systems.

Understanding 3rd party/vendor support for the apps form the beginning is an absolute must to ease headaches during testing.

Identity Model

Identity is central to AVD.

The design needs to consider whether users and session hosts will use Microsoft Entra ID, Active Directory Domain Services, Microsoft Entra Domain Services, or a hybrid model.

Authentication, conditional access, MFA, single sign-on, Kerberos, and access to domain-joined resources all need to be considered before deployment.

File Share Access

Many AVD environments depend heavily on file shares.

Users may need access to Azure Files, FSLogix profile containers, home drives, shared departmental data, or application data.

Planning should include permissions, authentication, network access, private endpoints, latency, resilience, backup, and how profile data will be protected.

Security Requirements

AVD security is more than locking down the session host.

The design should include identity controls, network segmentation, endpoint protection, privileged access, application control, data protection, monitoring, logging, patching, and secure administration.

Security should be built into the design from the start, not bolted on after go-live.

Backup and Disaster Recovery

AVD is often a critical access platform.

If users rely on it to access applications and data, then backup and disaster recovery need proper attention.

This includes session host recovery, image management, FSLogix profile protection, application availability, file share recovery, regional failure scenarios, and documented recovery procedures.

Simply being “in Azure” does not automatically make the platform resilient.

Remember that overdoing backup and DR can also have a negative impact on the platform and performance. If you don’t need to replicate profiles, don’t add features such as FSLogix Cloud Cache “just to be on the safe side”. Make sure that time and thought goes into the planning.

Operational Ownership

A good technical design can still fail if nobody owns the service properly.

Before deployment, it should be clear who is responsible for monitoring, patching, image updates, scaling plans, user support, incident management, application updates, security reviews, cost management, and continuous improvement.

AVD needs an operating model, not just a deployment plan.

Aligning AVD Design to the Azure Well-Architected Framework

A strong AVD design should also align with the five pillars of the Azure Well-Architected Framework.

Reliability

The platform should be designed to remain available, recover from failure, and support business continuity.

This includes capacity planning, host pool resilience, profile availability, backup, DR planning, and dependency mapping.

Security

Users, data, applications, and administrative access all need to be protected.

Security planning should include identity, conditional access, MFA, least privilege access, network controls, logging, endpoint protection, and secure configuration baselines.

Cost Optimisation

AVD can be cost-effective, but only when it is planned properly.

Costs are influenced by VM sizing, user density, scaling plans, reserved instances, storage choices, image design, licensing, and operational processes.

Poor planning often leads to oversized hosts, underused capacity, and unexpected storage or networking costs.

Operational Excellence

AVD needs repeatable processes for deployment, support, change control, monitoring, patching, image management, incident response, and continual improvement.

The goal is not just to deploy the platform, but to run it well.

Performance Efficiency

Performance should be designed around user experience.

This includes VM sizing, application behaviour, profile performance, storage latency, network routing, graphics requirements, Teams optimisation, and session host capacity.

Performance issues are often the result of design assumptions made too early.

…and finally

AVD can be a powerful platform for delivering secure, flexible, and scalable access to desktops and applications.

But success depends on planning. The best AVD projects do not start with session hosts. They start with users, applications, business requirements, security expectations, and operational ownership.

AVD is an end-user compute platform. It should be designed with the same care as any other critical business service.

In the next part of this series, we will look at the discovery phase and why it's one of the most important foundations of a successful AVD design.