First verify whether the slow attempt resumes the same session on the same host or creates another session, because a true reconnect should be investigated as session-resume work, while a new session can be delayed by an FSLogix container still mounted on the original host.
1. Establish where the 3–4 minutes occur
Since the affected host is already identified, extend that correlation to include the connection ID, connection states, and AVD checkpoints. AVD measures connection time from WVDConnections state Started to the desktop ShellReady checkpoint and separates service routing from host-side logon processing.^1^
Run this for one slow and one fast attempt:
let user = "[Email]";
let start = ago(24h);
WVDConnections
| where TimeGenerated >= start and UserName == user
| project ConnectionTime=TimeGenerated, CorrelationId,
State, SessionHostName, ResourceAlias
| join kind=leftouter (
WVDCheckpoints
| where TimeGenerated >= start
| project CheckpointTime=TimeGenerated, CorrelationId, Name
) on CorrelationId
| order by ConnectionTime asc, CheckpointTime asc
Validate the column names against your workspace schema. AVD diagnostics tables use the WVD prefix, and diagnostics record Started, Connected, and Completed connection states.^2^
For the slow attempt, record:
- Whether
SessionHostName matches the host holding the disconnected session.
- Whether the Windows session ID is unchanged.
- Time from
Started to Connected.
- Time from
Connected to ShellReady.
- Any
WVDErrors, including ServiceError and CorrelationId.
ServiceError=true requires Microsoft escalation. ServiceError=false rules out an AVD service-side error, but still requires correlation across the client, RDStack, deployment, and Windows host.
2. If it is the same Windows session
A same-session reconnect normally does not require a new profile-container attachment. In the FSLogix profile log, search the exact interval for:
-
LoadProfile: <user>
-
Begin Session: Logon
-
loadProfile time:
-
Milliseconds
- warnings and errors
The primary file is:
C:\ProgramData\FSLogix\Logs\Profile\Profile_<date>.log
Use the process ID to follow that user’s sequence.^3^
If no new LoadProfile sequence occurs, profile attachment is unlikely to account for the delay, although overlapping FSLogix or filter-driver activity is still possible. Prioritize:
- Task Scheduler: inspect tasks with On remote connection, On workstation unlock, or other session-state triggers. Windows supports triggers specifically for remote connect/disconnect and lock/unlock.^4^
- Event Viewer: correlate:
-
Applications and Services Logs → Microsoft → Windows → TaskScheduler → Operational
-
... → GroupPolicy → Operational
-
... → TerminalServices-LocalSessionManager → Operational
- Windows Application and System
- User Profile Service: check
Windows Logs → Application, filtered to User Profiles Service, then Applications and Services Logs → Microsoft → Windows → User Profile Service → Operational.^5^
- Host pressure: align CPU, available memory, disk latency, and session count with the delay. AVD Insights includes the relevant processor, memory, disk, and Terminal Services counters.^1^
3. If reconnect creates a session elsewhere
Check for the original disconnected session and an FSLogix lock on its host. By default, FSLogix maintains an exclusive container lock and does not permit another connection to use that container unless a supported multiple-connection configuration is implemented.^6^
If this condition is confirmed:
- In the applicable GPO, open:
Computer Configuration → Administrative Templates → Windows Components → Remote Desktop Services → Remote Desktop Session Host → Session Time Limits.
- Configure Set time limit for disconnected sessions to an organization-approved interval.
- Run
gpupdate /force on a test host and reproduce the disconnect/reconnect sequence.
- Confirm the old session logs off and releases the VHD/VHDX before another host creates a session.
This trades resumable disconnected sessions for clean sign-ins after the configured timeout, so test it in a test host pool first. Do not configure concurrent sessions on the same AVD session host; FSLogix documents that concurrent connections are unsupported in an AVD host pool.^7^
4. FSLogix and Azure Files conditional checks
- Compare the installed FSLogix build with current known issues. Version
25.02 (3.25.202.4223) had a fixed defect where containers could fail to detach; the documented resolution is to install the latest FSLogix version.^8^
- On Microsoft Entra-only joined hosts, FSLogix Apps Event ID 26 LDAP errors are expected and can be ignored; they do not establish the reconnect delay.^8^
- For Azure Files, inspect Storage account → Monitoring → Metrics → File during the slow window. Check throttling response types plus
SuccessE2ELatency and SuccessServerLatency. A large gap between those latency metrics points toward client/network latency; throttling is visible through the response-type dimension.^9^
If event correlation remains inconclusive, collect the FSLogix Support Tool package from the affected host; it includes FSLogix logs, event logs, registry configuration, permissions, gpresult, mounted volumes, processes, and system information.^10^
References
- Azure Virtual Desktop Insights glossary
- Send diagnostic data to Log Analytics for Azure Virtual Desktop
- Troubleshooting with Logging and Diagnostics
- SessionStateChangeTrigger object
- Troubleshoot user profiles with events
- Troubleshooting issues with container locked or in use
- Concurrent or multiple connections to a single container
- Known Issues - FSLogix | Microsoft Learn
- Troubleshoot Azure Files performance problems
- FSLogix Support Tool