Common AVD performance issues (and how to fix) 

Azure Virtual Desktop has become a permanent fixture in how UK organisations work. With UK workers averaging more remote days per week than anywhere else in Europe, virtual desktops are the daily working environment for thousands of people. 

Which means that when AVD runs slowly, it’s a productivity problem that affects every user, every day. Things like logins that take five minutes instead of twenty seconds, or a session stuttering every time you open a spreadsheet. It means real lost time and a seriously vexed team constantly complaining why is azure virtual desktop so slow.

The reassuring part is that most AVD performance issues trace back to a small set of recurring root causes. And all of them are fixable. In this article, we’ll walk through the most common problems, explain what causes them in plain terms, and show you how to fix them (or better still, prevent them). 

In most environments, performance complaints come down to one or more of these: 

• Undersized or overloaded session hosts. The virtual machines running your users’ desktops don’t have enough resources for the number of people using them. 

• Profile and storage bottlenecks. FSLogix loads each user’s settings and files at login which can be fighting slow or misconfigured storage.

• Network latency. The connection between your users and the Azure region hosting their desktops is too slow, or taking an inefficient route. 

• Misconfigured or absent autoscaling. Hosts aren’t powered on in time for user logon, or they’re scaled down so hard to save costs that there’s no capacity left when people need it.

• Application optimisation. Some apps are built assuming a single user with dedicated local resources, not a shared multi-session host. Things like heavy local caching, aggressive background processes, or licensing checks that weren’t designed for concurrent sessions can all drag performance down for everyone on that host, even when the underlying VM is properly sized. 

Each of these shows up differently for users, so we’ll take them symptom by symptom. We begin with the complaint that usually generates the most tickets.  

If any single issue defines a bad AVD experience, it’s slow sign-in. It’s the part of the platform every user meets every day. When things go wrong, users can be left staring at a loading screen for five, ten, or even fifteen minutes. 

Several culprits tend to be behind it: 

Bloated profile containers. AVD typically uses FSLogix to manage user profiles. FSLogix packages up each person’s settings and app data into a virtual disk file that gets attached when they sign in. If that container has swollen with browser caches and temporary files, every login means dragging a bloated disk across the network, this can be resolved by implementing redirection.xml which tell FSlogix which files and folders to exclude. 

Synchronous policy processing. Group Policy Objects (GPOs) are the rules IT teams use to configure Windows machines centrally, covering everything from drive mappings to security settings. By default, Windows can process these one at a time before letting the user in, and each one adds seconds to the wait. If you’re applying policies through both Group Policy and Intune (Microsoft’s cloud-based device management tool), the overlap makes things worse. 

Unused built-in apps. Windows is bloated with apps most business users never touch, like Xbox, News, and Clipchamp. Each one still has to register itself during login, sneakily adding ten to twenty seconds. Windows 11 24H2 introduced a policy-based removal feature, available through Intune or Group Policy, that strips this bloat automatically. One caveat: it doesn’t currently support multi-session environments. So for pooled AVD deployments the practical route is still removing these apps from your golden image (the master template your session hosts are built from). 

The fixes for slow logins are well established: 

• Enable asynchronous policy processing so rules apply in the background rather than blocking sign-in.  

• Remove unused built-in apps with the new policy.  

• Put FSLogix containers on premium storage with SMB Multichannel enabled (a feature that lets file transfers use several network connections at once).  

• Add antivirus exclusions for FSLogix processes and file paths, because security software scanning every profile disk operation is a common hidden drag. 

If you apply them together, these changes can take login times from over a minute to under twenty seconds. Definitely worth it.  

Since FSLogix sits underneath so many login and in-session problems, it deserves its own section. 

When profiles are slow, storage configuration under FSLogix is the first place to look. The core issue is that profile containers generate a lot of disk activity. It’s measured in IOPS (input/output operations per second, essentially how many read and write requests the storage can handle). Microsoft’s storage guidance is to plan for 10 IOPS per user during normal operation, spiking to 50 IOPS per user during sign-in and sign-out. If your storage can’t keep up during the morning rush, everyone feels it. 

There’s a less obvious constraint too. Azure Files, a common home for FSLogix containers, has a hard limit of 10,000 open file handles per root directory. That becomes a real ceiling when you scale up. So it’s a strong argument for keeping profile containers on their own dedicated share, rather than mixing them in with general file storage. 

Beyond sizing the storage properly, a few configuration choices make a big difference: 

• Use the VHDX container format, with disk compaction scheduled to run periodically so containers shrink back down rather than growing forever.

• Exclude browser caches and temporary files from the profile container to control bloat at the source. 

• Set realistic FSLogix service timeouts so a failed disk attachment produces a clear error instead of an indefinite hang. 

• Apply antivirus exclusions for FSLogix’s virtual disk files and services, just as with login optimisation. 

These aren’t necessarily complicated on their own. The problem is that FSLogix defaults don’t include them, so environments set up quickly can miss several at once, and the effects stack up. 

If sessions feel laggy, the network between the user and Azure is the first place to look. So if typing appears delayed, windows jerk around when you drag them, or video calls stutter, this may be the cause. 

The key metric is round-trip time (RTT): how long a signal takes to travel from the user’s device to the Azure region hosting their desktop and back. Microsoft’s guidance is that RTT should stay below 150 milliseconds for a stable session. Between 150 and 200ms is tolerable for text-based work. Above 200ms, users will notice, with unresponsive input and dropped connections. 

High latency isn’t always about distance. Routing matters just as much. A network designed to push all traffic through a central VPN (or through security that inspects encrypted traffic) forces desktop sessions to take the scenic route. That means a user in Leeds might have their desktop traffic hauled down to a London datacentre, inspected, and only then sent to Azure. This “hairpinning” pattern can add enormous latency for no security benefit, because AVD traffic is already encrypted. So wherever it’s possible, remote desktop traffic should route directly to the nearest Azure gateway. 

Two protocol features are worth checking as well: 

RDP Shortpath lets AVD sessions use UDP, a faster transport protocol than the TCP fallback, for a more responsive connection. AVD’s monitoring tools will show you whether Shortpath is actually active or whether sessions are quietly falling back to the slower path. 

RDP Multipath is a newer development that sends traffic over redundant network paths simultaneously, so a wobble on one route doesn’t interrupt the session. Redundant UDP paths became generally available in mid-2025, with redundant TCP paths following in 2026. It’s aimed squarely at users connecting over the public internet, which would include most hybrid workers. 

Session hosts are the Azure virtual machines that actually run your users’ desktops. In a pooled setup, multiple users share each host, and getting the ratio right is one of the biggest factors in day-to-day performance. 

Microsoft publishes sizing guidance based on workload intensity: up to six users per vCPU for light work, four for medium, two for heavy, and a dedicated one-to-one ratio for power users. The multi-session tiers sit on a baseline of at least 8 vCPUs and 16GB of RAM per host, while the power tier carries its own spec with far more memory per user. Take it with a grain of salt however, in real world environments we find these recommendations to be far too optimistic. At Synextra we work with the client to baseline their requirements and match this to the correct SKU.

In practice, a safer planning assumption is two to four users per vCPU even for supposedly medium workloads, because modern browsers and collaboration tools are hungrier than the guidance assumes. 

There’s also a counterintuitive rule about VM size. Bigger isn’t proportionally better. Doubling a host’s core count doesn’t double its user capacity; the realistic gain is around 1.5x to 1.9x, because the overhead of coordinating work across cores grows too. Microsoft recommends keeping multi-session hosts between 4 and 24 vCPUs for this reason. A fleet of moderately sized hosts usually beats a few giants. 

Start by benchmarking actual user requirements rather than applying a formula. Split users into low, medium, and high usage groups based on what they actually run, then size each host pool to its group. Run a pilot group on your proposed configuration and watch the real numbers for a few weeks. Then adjust before rolling out widely.  

The metric to watch above all is user input delay: the gap between a user pressing a key and the session responding. Microsoft says it should ideally sit below 100 milliseconds. Its monitoring flags anything above two full seconds as “Bad”, but by that point your help desk should already know. 

Sizing decisions also have a direct cost dimension, since every extra host is billed compute. Our guide to Azure Virtual Desktop pricing breaks down how those choices translate into your monthly bill. 

Autoscaling is how AVD matches capacity to demand: powering hosts on as people start work, and turning off as they leave. If it’s done well, it keeps performance steady while cutting AVD costs substantially (since idle hosts are billed compute whether anyone uses them or not). Done badly, it causes performance problems of its own. 

AVD’s native scaling plans work around four daily phases: ramp-up, peak, ramp-down, and off-peak, each with its own capacity rules. Here’s a few tips to keep them healthy: 

Avoid flapping. Flapping is when an environment cycles rapidly between adding and removing hosts, scaling out and back in every few minutes rather than settling. It usually happens because the scale-out and scale-in thresholds sit too close together. Users get shuffled around, and both performance and cost suffer for it. Keep a wide buffer between the two triggers. 

Never force users off. During scale-in, hosts should enter drain mode, which stops new sessions landing on them while letting existing users finish naturally. Only deallocate once the host is empty. Forcibly logging off active users to save a few pounds is a fast way to destroy trust in the platform. 

Pre-warm for the morning. One pretty standard autoscaling failure is the cold start: everyone logs in at 8:30am, the environment scrambles to boot hosts, and the first wave of users suffers. Prevent it by starting capacity fifteen to thirty minutes before the working day, as well as keeping a small standby buffer of hosts at all times. 

Review quarterly. A scaling plan tuned for last year’s working patterns can become wrong as habits shift. Treat it as a living configuration, not a set-and-forget one. 

Everything above is easier to fix, and much easier to prevent, when you can actually see what’s happening. Guesswork is the enemy of AVD performance. 

AVD Insights is Microsoft’s built-in monitoring solution, built on Azure Monitor and Log Analytics (Azure’s central services for collecting and querying operational data). Setting it up involves deploying a monitoring agent to your session hosts and pointing it at a Log Analytics workspace. Once running, it tracks the metrics that really matter: connection reliability, user input delay per session, frame delays, and the resource usage of each host. It also has prebuilt queries for rapid diagnostics, so you don’t need to write your own from scratch. 

A lot of value comes from baselining. Establish what normal looks like in your environment (like typical login times / RTT, and typical host utilisation) and set alerts for meaningful deviations. A login time creeping from twenty seconds to forty is invisible in a single support ticket, but obvious on a trend line, and it’s far better to catch it there than in a complaint. 

As a rough guide to healthy figures: RTT under 150ms, user input delay under 100ms, and average host CPU sitting between 40 and 70%. That last range is important in both directions. Consistently low CPU means you’re paying for capacity that nobody uses, which is a cost problem dressed up as a performance bonus. 

Third-party platforms like Nerdio can layer sizing recommendation engines on top of these raw metrics. This can be worth it at scale, but for most environments, native tooling covers the essentials. 

This is a fair question, since many firms weighing up AVD are coming from Citrix or considering it as an alternative. 

On raw protocol performance, Citrix still holds an edge in difficult network conditions. Its HDX protocol has built its reputation on resilience under heavy packet loss and jitter, and it degrades more gracefully than AVD’s stack when connections get genuinely bad. AVD performs strongly on clean, stable links, and features like RDP Multipath are narrowing the gap. But for use cases dominated by poor connectivity (think branch offices on weak links, or internationally distributed teams), Citrix’s protocol advantage is real. 

One more nuance: AVD’s hardware-accelerated HEVC video encoding, which improves the experience for graphically demanding work, requires GPU-enabled hosts. Standard pooled fleets are limited to H.264. 

Protocol behaviour is only one factor in choosing between AVD and Citrix, of course. Cost and management overhead both tend to pull in AVD’s favour, as does its Microsoft ecosystem integration, and the wider VDI market holds options beyond either platform. 

AVD performs well when it’s measured and sized on evidence, then reviewed regularly. It performs badly when it’s set up once and left alone. 

If you take four things away, make them these. Get FSLogix and its storage right, because profiles underpin the experience of every single login. Watch user input delay and RTT as your core health metrics, with proper baselines. Revisit your sizing and scaling assumptions quarterly; working patterns drift and yesterday’s perfect configuration slowly stops being perfect. And keep your image optimised: strip out applications you no longer need and keep the rest updated, since bloat and outdated software both eat into performance and login times.

If your users are grumbling about slow desktops and you want to talk to a team who lives and breathes this stuff, we’re happy to help. At Synextra, we design and manage AVD environments for UK businesses of all shapes, and we keep them running well long after launch. Get in touch with the team for a chat about what your environment needs.