AVD Windows 11 multi-session with FSLogix on Azure Files: reconnect to existing disconnected session stays at "Welcome" for 3-4 minutes, new sign-in is fast

Nguyen Thien Chuong 0 Reputation points
2026-10-25T13:38:10.55+00:00

Service Azure Virtual Desktop (pooled host pool), FSLogix Profile Container on Azure Files.

Scenario

  • After a full sign-out and a new sign-in, the desktop is ready in under 1 minute.
  • After a disconnect (closing the Windows App, or the laptop sleeping/hibernating) and a reconnect to the existing session, the user stays at the "Welcome" screen for about 3-4 minutes before the desktop is usable.
  • The delay affects the reconnect path only.

Result No error is shown. The session eventually loads normally.

Environment

  • Windows 11 Enterprise multi-session (version/build: 24H2 or 26H2)
  • Session hosts: Microsoft Entra ID joined
  • Profile storage: Azure Files
  • Client: Windows App
  • Region:

Troubleshooting efforts

  • Compared sign-out + sign-in versus disconnect + reconnect (results above).
  • Identified the session host involved using WVDConnections in Log Analytics.
  • Collecting the FSLogix Operational log, the FSLogix Profile log and Group Policy events for the slow reconnect window on that host.

Question What can cause a long "Welcome" screen only when reconnecting to an existing disconnected session, while a fresh sign-in is fast? Which logs or checks should I look at first (FSLogix, Azure Files, Group Policy, logon tasks)?

Azure Virtual Desktop
Azure Virtual Desktop

A Microsoft desktop and app virtualization service that runs on Azure. Previously known as Windows Virtual Desktop.

0 comments No comments

2 answers

Sort by: Newest
  1. Gulnaz Mushtaq 490 Reputation points MVP
    2026-10-25T17:23:11.35+00:00

    The main cause here could be session reactivation/shell delays, blocked user-session processes, or I/O stalls with SMB/FSLogix. If a fresh sign-in is quick, it suggests that a general profile-attach issue is probably not the case. Start by checking these in this order:

    1. FSLogix Profile logs: Navigate to C:\ProgramData\FSLogix\Logs\Profile and look for any waits, retries, or storage I/O issues during the reconnect.
    2. Remote Desktop Services and Windows events: Try to correlate the session reconnect events with the moments when Explorer starts responding again.
    3. Group Policy Operational: Look for any long processing gaps, scripts, or waits for network resources.
    4. Task Scheduler Operational: Review tasks triggered by logon, unlock, and resume events.
    5. Azure Files metrics: Compare the end-to-end latency, server latency, and any throttling that occurs during the delay.
    6. WPR performance trace: If the logs don’t clarify what’s taking up those 3–4 minutes, capture a trace during the reconnect process.

    A key diagnostic step is to check if FSLogix or SMB activity is ongoing throughout the delay. If it isn’t, then you should focus on shell initialization and processes in the current session.

    Was this answer helpful?


  2. AI answer

    2026-10-25T13:40:25.66+00:00

    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:

    1. 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^
    2. Event Viewer: correlate:
      • Applications and Services Logs → Microsoft → Windows → TaskScheduler → Operational
      • ... → GroupPolicy → Operational
      • ... → TerminalServices-LocalSessionManager → Operational
      • Windows Application and System
    3. User Profile Service: check Windows Logs → Application, filtered to User Profiles Service, then Applications and Services Logs → Microsoft → Windows → User Profile Service → Operational.^5^
    4. 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:

    1. In the applicable GPO, open:
      Computer Configuration → Administrative Templates → Windows Components → Remote Desktop Services → Remote Desktop Session Host → Session Time Limits.
    2. Configure Set time limit for disconnected sessions to an organization-approved interval.
    3. Run gpupdate /force on a test host and reproduce the disconnect/reconnect sequence.
    4. 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

    1. Azure Virtual Desktop Insights glossary
    2. Send diagnostic data to Log Analytics for Azure Virtual Desktop
    3. Troubleshooting with Logging and Diagnostics
    4. SessionStateChangeTrigger object
    5. Troubleshoot user profiles with events
    6. Troubleshooting issues with container locked or in use
    7. Concurrent or multiple connections to a single container
    8. Known Issues - FSLogix | Microsoft Learn
    9. Troubleshoot Azure Files performance problems
    10. FSLogix Support Tool
    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.