Why Are Azure Virtual Desktop Logons Slow? A Diagnostic Checklist

By David, 2026-10-11

"It takes forever to log in" is the most common complaint about Azure Virtual Desktop (AVD), and the least specific. The user sees a spinning circle, then a black screen, then a desktop they can't use for another twenty seconds. Behind that is a pipeline of six stages, run by different components, and any one of them can be the slow part.

This guide breaks an AVD logon into those stages, shows how to measure which one is slow, and gives the fix for each common cause: profile attach, Group Policy, AppX and first sign-in, startup apps, overloaded hosts and cold hosts. It's vendor-neutral until the section on Atlas.

The short version: don't guess. Turn on AVD Insights, look at Time to connect and the logon checkpoints for the slow users, and find the stage that takes the time. In most estates it's one of three: the FSLogix profile, Group Policy, or a host that's overloaded or still booting at 9 a.m.

Azure Virtual Desktop details below are taken from Microsoft Learn as of October 2026. Each section links to its source so you can check what has changed since.

1. The logon timeline: where the seconds go

An AVD sign-in isn't one event. It's a relay, and the user only sees the end of it.

1. Connect and pick a host. The client reaches the AVD gateway, and the broker chooses a session host using the host pool's load-balancing method. If no host is running and Start VM on Connect is on, the user waits for one to boot.
2. Sign in and set up the session. The RDP stack connects to the host and Windows authenticates the user. Any credential prompt the user has to answer happens here.
3. Attach the profile. FSLogix mounts the user's profile container from the file share, so it appears as their C:\Users\<user> folder.
4. Apply Group Policy and run logon scripts. User policy, drive and printer mappings, folder redirection and any logon scripts.
5. Start the shell. Explorer starts. On a first sign-in Windows also registers every provisioned app for the new profile, and Active Setup runs its per-user steps. This is the "black screen" stage.
6. Start the user's apps. Everything in the Run keys and the startup folder, plus Teams, OneDrive and whatever agents the image carries. The desktop is visible, but it isn't usable yet.

Some of these overlap, so the per-stage times never add up exactly to the total. That's fine: you're looking for the stage that is clearly bigger than the rest.

2. Measuring it: AVD Insights and what "good" looks like

AVD Insights is the Azure Monitor workbook for Azure Virtual Desktop. It reads the AVD diagnostic tables in your Log Analytics workspace, so the first job is to send host pool diagnostics there if you haven't already.

Microsoft defines Time to connect as the time between a user opening a resource and their desktop being loaded and ready to use. It has two stages: connection, which is how long the service takes to route the user to a host, and logon, which is signing the user in and setting up the session on the host. The clock starts when the connection starts and stops at the ShellReady checkpoint for a desktop, or when the first app starts for a RemoteApp. (Insights glossary)

Two caveats from Microsoft's own troubleshooting page are worth knowing before you trust a chart (Troubleshoot AVD Insights):

• Time to connect includes the time users spend typing their credentials. A user who leaves the password prompt open for a minute shows up as a one-minute logon. Look at medians and the 95th percentile, not the single worst case.
• Data arrives about 15 minutes late, because of Azure Monitor's ingestion latency. Don't test a fix and refresh the workbook straight away.

For the stage-by-stage view, the logon checkpoints are in the WVDCheckpoints table. Start by seeing which checkpoints your hosts actually report:

WVDCheckpoints
| where TimeGenerated > ago(1d)
| summarize count() by Name
| order by count_ desc

Then join them to WVDConnections on CorrelationId to get the time from connection to each checkpoint for a slow user.

What "good" looks like. Microsoft doesn't publish a target. As a working rule, a returning user on a warm host should reach a usable desktop in under 20 to 30 seconds. A first sign-in, which builds a new profile, will be slower. Anything over a minute is worth investigating, and a p95 much higher than the median means some users or some hosts have a problem the average hides.

On the host itself, two logs fill in the gaps Insights can't see:

• FSLogix writes a loadProfile time: line for every sign-in in C:\ProgramData\FSLogix\Logs\Profile.
• Group Policy logs event 8001 in Applications and Services Logs → Microsoft → Windows → GroupPolicy → Operational when user logon policy processing completes, with how long it took.

Keep the monitoring itself simple. For what to watch across the whole estate, see AVD monitoring.

3. The top causes, each with the fix

Profile attach (FSLogix)

Symptom. The wait is before the desktop appears, and the FSLogix loadProfile time: is a large share of it. It's worst at 9 a.m., when every user attaches a container at once.

Cause. Profile storage that can't keep up with the logon burst, storage in a different region from the hosts, containers that are locked and retried, antivirus scanning the VHDX as it mounts, or containers bloated with caches.

Fix. Measure first, then fix the storage: right tier, same region as the hosts, enough IOPS for the peak. Exclude the FSLogix VHD(X) files and processes from antivirus. Keep the container lean by redirecting caches out of it. Our FSLogix troubleshooting guide covers the errors and log codes in detail, and the AVD sizing guide covers which Azure Files tier fits your user count.

Group Policy processing

Symptom. The profile loads quickly, but users sit on "Applying user settings" or "Please wait for the Group Policy Client". Event 8001 shows user policy taking many seconds.

Cause. Policy that runs synchronously and waits on the network, drive maps or folder redirection pointing at servers that are slow or unreachable from Azure, WMI filters that take seconds to evaluate, item-level targeting on hundreds of preferences, and logon scripts that run synchronously so Explorer waits for them.

Fix.

• Run gpresult /h for a slow user and read the timings. Remove settings meant for physical PCs: AVD hosts don't need laptop power plans or offline files.
• Remove or fix drive maps and redirected folders that point at on-premises servers with poor latency from the AVD region.
• Replace WMI filters with security-group filtering where you can.
• Don't set Run logon scripts synchronously unless something truly depends on it, and move slow scripts to scheduled tasks or the image.
• Keep the AVD policy in a small number of GPOs linked to the session hosts' OU, with loopback processing set deliberately rather than inherited by accident.

AppX and provisioned apps (the black screen)

Symptom. A black screen for a long time after the profile loads, mostly on a user's first sign-in or the first one after a new image.

Cause. On a first sign-in Windows registers every provisioned Store app for the new profile, and Active Setup runs per-user steps for installed components. A full Windows 11 image carries dozens of consumer apps a session host never needs.

Fix. Remove the provisioned apps you don't use from the image with Remove-AppxProvisionedPackage, test the result, and keep the list in your image pipeline so it survives the next build. Turn off Show first sign-in animation in Group Policy (Computer Configuration → Administrative Templates → System → Logon). Microsoft's VDI optimization guidance lists the apps and services that are safe to remove. Our golden image management guide covers building that into a repeatable image.

Startup apps

Symptom. The desktop appears on time, but nothing responds for another 10 to 30 seconds. On a multi-session host, every user's apps start on the same CPUs.

Cause. Every app in the machine and user Run keys, the startup folder and logon scheduled tasks starts at once: Teams, OneDrive, the VPN client nobody uses on AVD, update checkers, tray tools.

Fix. Audit what starts: check Task Manager's Startup apps tab on a host, and the Run keys for both the machine and a test user. Remove what users don't need at sign-in. Configure Teams the VDI way, as in our Teams on AVD guide. On multi-session hosts, apply the same discipline to the browser: our Edge on multi-session guide covers startup boost and background modes.

A host overloaded at peak

Symptom. Logons are fine at 8 a.m. and slow at 9 a.m. The slow users all land on the same few hosts, which show CPU pinned near 100%.

Cause. Microsoft calls logon a CPU-intensive operation, so twenty users signing in to one host in ten minutes is the heaviest load that host sees all day. Depth-first load balancing makes it worse, because it fills one host to its session limit before using the next: everyone in the morning wave signs in to the same machine. (Load balancing)

Fix. Use breadth-first load balancing during the morning ramp-up so sign-ins spread across hosts, set the max session limit from measured peak load rather than the theoretical maximum, and go up a size or lower the limit if CPU is the ceiling. The sizing guide shows how to find the right density, and pooled vs personal host pools covers when a pool type itself is the problem.

Cold hosts (scaling)

Symptom. The first users of the morning wait a minute or more, and the delay disappears once a few hosts are up.

Cause. Scaling switched the hosts off overnight and nothing switched enough of them back on before people arrived. With Start VM on Connect, the user's connection starts a deallocated host, and they wait for Windows to boot and the AVD agent to register before their logon even begins. (Start VM on Connect)

Fix. Keep Start VM on Connect as the safety net, not the plan. Use a scaling plan's ramp-up phase, or a schedule, to start enough hosts before the morning wave, sized to how many people actually sign in at that hour. (Autoscale scaling plans) If your hosts' disks are moved to a cheaper tier while deallocated, make sure they're moved back before the host starts, not after.

4. Quick wins vs structural fixes

Do the quick wins first and measure again. They often get logons into the acceptable range, and the measurement tells you which structural fix is worth the effort.

5. How Atlas AVD surfaces logon performance

Everything above works with the native tools. Atlas AVD puts the same data in one place and turns it into alerts, so a slow logon shows up before the ticket does.

Logon timing, per pool and per user. With AVD Insights connected, the Logon Breakdown card on the Analytics Experience tab shows the median and p95 logon time and how long each logon checkpoint that Azure Virtual Desktop reports takes to arrive, so you can see which stage is slow. The User Sessions page shows each user's Logon Time next to their latency.

An experience score that includes logon. The End-User Experience Score rates each environment and user from 0 to 100, with logon duration and round-trip latency among the factors, so you can see which pool is hurting rather than read raw counters. See Session Performance Metrics and Session Analytics for login trends and peak concurrency.

Alerts before the tickets. Slow User Login fires when sign-in time for a host pool passes 20 seconds, and FSLogix Slow Profile Load when profile load passes 8 seconds. You can change both thresholds, and alerts can go to Teams, Slack or a webhook. Host CPU % and RAM % sit beside each host's session count, with High CPU and High Memory alerts for the overloaded-at-peak case.

Ask instead of digging. With your own AI provider connected, Atlas Advisor answers the same question in plain words. Ask it why logins are slow and it comes back with the pool's median logon time, the users with the slowest logons and which stage took the time for each, so you know where to look before you open a query. The demo at the top of this page shows that answer.

Warm hosts for the morning wave. The Autoscale Engine's Schedules set a minimum number of hosts for a time window, built for exactly this: login storms. Each schedule can use its own load-balancer type, so you can run breadth-first during the morning ramp-up. Smart Disk Tiering moves a deallocated host's disk back to its performance tier before Autoscale starts it, so a cold host doesn't also start on slow storage.

Leaner hosts. Windows Desktop Optimization (WDOT) applies optimization modules when Atlas provisions session hosts, including WDOT · AppX Removal, which removes provisioned and installed Store apps.

What Atlas doesn't do, so you can plan for it:

• It doesn't analyze or change your Group Policy. Use gpresult and event 8001 as in section 3.
• It doesn't manage startup apps or Active Setup on the hosts.
• It doesn't speed up the profile share itself. It tells you when profile load is the slow part; the storage fix is yours.
• The logon breakdown needs AVD Insights diagnostics in Log Analytics. Without them, it has no data to show.

New to AVD? What Is Azure Virtual Desktop? covers the moving parts. And slow logons usually trace back to one of the top 10 AVD mistakes, starting with profiles, scaling and monitoring.

FAQ

Why are Azure Virtual Desktop logons slow?

Usually because one stage of the logon is slow: the FSLogix profile attach, Group Policy processing, first sign-in app registration, startup apps, a host that's overloaded at peak, or a host that's still booting. Measure Time to connect and the logon checkpoints in AVD Insights to find which stage, then fix that one.

What is a good AVD logon time?

Microsoft doesn't publish a target. A returning user on a warm host should reach a usable desktop in under 20 to 30 seconds. First sign-ins are slower because Windows builds the profile. Investigate anything over a minute, and any p95 far above the median.

Why do users get a black screen when signing in to AVD?

A black screen means the profile has loaded but the Windows shell hasn't finished starting. The usual causes are first sign-in app registration for provisioned Store apps, Active Setup, policies or synchronous logon scripts still running, or a host short on CPU.

Does Time to connect in AVD Insights include typing the password?

Yes. Microsoft's troubleshooting page says Time to connect includes the time users spend entering credentials, so it can show false peaks. Use the median and p95 rather than the worst single connection.

Does Start VM on Connect slow down logons?

For the user who triggers it, yes: their connection starts a deallocated host, and they wait for it to boot before their logon begins. Use scheduled ramp-up to have hosts running before people arrive, and keep Start VM on Connect as the fallback.

Is breadth-first or depth-first better for logon speed?

Breadth-first spreads sign-ins across hosts, so it usually gives faster logons at peak. Depth-first fills one host before the next, which saves cost but concentrates the morning logon load on one machine.

Azure Virtual Desktop details in this article are taken from Microsoft Learn as of October 2026: Azure Virtual Desktop Insights glossary, Troubleshoot Azure Virtual Desktop Insights, Host pool load balancing, Start VM on Connect, Autoscale scaling plans and Optimizing Windows configuration for VDI. AVD Insights changes often, so check those pages before you change production.