Share via

FSLogix Profile Failed to Attach After Restoring VHDX from Azure Snapshot (Error 0x0000003B) – Correct SID but Profile Ignored

Ankit Shrivastava 0 Reputation points
2026-05-06T12:51:15.0966667+00:00

Description / Question Body

Hello Microsoft Community,

I am facing an issue with FSLogix Profile Containers in Azure Virtual Desktop (AVD) after restoring a user profile from an Azure snapshot backup. I would appreciate guidance or confirmation if I am missing any supported steps.

Environment

  • Azure Virtual Desktop (AVD)
  • FSLogix Profile Containers (VHDX)
  • Profile location: Azure File Share
  • User authentication: Active Directory (domain‑joined session hosts)
  • FSLogix version: (add version if known)

Issue Description

A user was unable to log in to AVD RemoteApp after their FSLogix profile was restored from a snapshot. During sign‑in, the following error is shown:

“The user profile failed to attach.”

FSLogix error details:

  • Status: 0x0000001B – Unknown status
  • Reason: 0x00000005 – Reason initialized to empty state
  • Error Code: 0x0000003B – An unexpected network error occurred

What Has Been Verified / Performed

  • ✅ Confirmed the user’s current AD SID using Get-ADUser
  • ✅ Restored the FSLogix VHDX file from Azure snapshot backup

  • Description / Question Body

    Hello Microsoft Community, I am facing an issue with FSLogix Profile Containers in Azure Virtual Desktop (AVD) after restoring a user profile from an Azure snapshot backup. I would appreciate guidance or confirmation if I am missing any supported steps.

    Environment

  • Azure Virtual Desktop (AVD)
  • FSLogix Profile Containers (VHDX)
  • Profile location: Azure File Share
  • User authentication: Active Directory (domain‑joined session hosts)
  • FSLogix version: (add version if known)

    Issue Description

    A user was unable to log in to AVD RemoteApp after their FSLogix profile was restored from a snapshot. During sign‑in, the following error is shown:

“The user profile failed to attach.”

FSLogix error details:

  • Status: 0x0000001B – Unknown status
  • Reason: 0x00000005 – Reason initialized to empty state
  • Error Code: 0x0000003B – An unexpected network error occurred

    What Has Been Verified / Performed

  • ✅ Confirmed the user’s current AD SID using Get-ADUser
  • ✅ Restored the FSLogix VHDX file from Azure snapshot backup
  • ✅ Verified the **profile folder name contains the correct SID **I later renamed the restored VHDX, but FSLogix still ignored it and continued creating a new, small VHDX file. This behavior also occurred when I tested with my own restored FSLogix profile (same error and outcome). Goal To successfully reattach a restored FSLogix profile container without recreating a new user profile, and to understand the correct and supported restore process. Any guidance, best practices, or official documentation references would be greatly appreciated.
  • Thank you in advance.
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

2 answers

Sort by: Most helpful
Most helpful Newest Oldest
  1. Himanshu Shekhar 6,145 Reputation points Microsoft External Staff Moderator
    2026-05-06T13:52:48.21+00:00

    FSLogix profile containers store the entire user profile inside a VHD/VHDX file, which is dynamically attached during user sign‑in and mounted as the active profile. [learn.microsoft.com]

    For a successful attachment, the following conditions must be met:

    The session host must be able to access the storage location (Azure Files / SMB share). The user must have correct NTFS and share permissions The correct VHDLocations configuration must be present and reachable

    The profile container must be accessible and not locked or in an inconsistent state - https://learn.microsoft.com/en-us/azure/virtual-desktop/fslogix-profile-containers

    When any of these conditions are not met, FSLogix cannot attach the profile and may instead create a new profile container.-https://learn.microsoft.com/en-us/fslogix/troubleshooting-old-temp-local-profiles

    Based on Microsoft documentation, there is no special FSLogix‑specific “reattach” or “rehydrate” operation after restore.

    Supported restore guidance is:

    • Restore the VHDX to the original storage location
    • Ensure:
      • Correct permissions (NTFS + SMB + RBAC)
        • Correct folder and naming structure
          • Storage and network access from session hosts
          • Allow FSLogix to discover and attach the container during sign‑in

    There is no supported step to force attach or override FSLogix behavior if the container is not considered valid or accessible.Based on Microsoft Learn troubleshooting references, the following are the supported and most relevant causes:

    Storage access / network path issue - FSLogix requires the session host to successfully access the file share path over SMB.
    If the path cannot be reached or resolved, the profile attach fails. [learn.microsoft.com]

    Permissions mismatch after restore - After restoring a VHDX from backup/snapshot:

    • NTFS ACLs or ownership may not match the current user
    • Azure Files RBAC or share permissions may not allow access

    Permissions are one of the most common causes of FSLogix profile attachment failures. [learn.microsoft.com]

    Profile container not attachable (corruption or inconsistent state) - FSLogix depends on Windows virtual disk APIs to attach the VHDX. If the disk cannot be opened or attached, the operation fails (attach failure is a recognized error class in FSLogix). [learn.microsoft.com]

    Incorrect or unreachable VHDLocations configuration - If FSLogix cannot correctly resolve or access the configured storage path, it will not use the existing profile. [learn.microsoft.com]

    When FSLogix cannot attach the existing container, it falls back to creating a new profile container, which matches the behavior you observed.

    Based on Microsoft documentation, there is no special FSLogix‑specific “reattach” or “rehydrate” operation after restoring.

    Supported restore guidance is:

    • Restore the VHDX to the original storage location
    • Ensure:
      • Correct permissions (NTFS + SMB + RBAC)
      • Correct folder and naming structure
      • Storage and network access from session hosts
    • Allow FSLogix to discover and attach the container during sign‑in

    There is no supported step to force attach or override FSLogix behavior if the container is not considered valid or accessible.

    To proceed in a supported manner, please validate the following:

    1. Access validation from session host

    Confirm UNC path is reachable

    • Validate SMB port 445 access

    Permissions validation

    User has:

      - NTFS permissions on folder + VHDX

  - SMB Share permissions

  - Azure RBAC role (e.g., Storage File Data SMB Share Contributor)

    Test VHDX integrity

     - Attempt to manually mount the VHDX on a test VM

 - Confirm disk opens successfully

    Check FSLogix logs

    • Location: C:\ProgramData\FSLogix\Logs
      • Look for:
      • VHD open/attach failures
        • Access denied / path resolution errors

    Ensure no duplicate/invalid files

    • Only one valid VHDX exists for the user
      • No conflicting naming that could affect detection

    Was this answer helpful?

  2. AI answer

    2026-05-06T12:51:54.0233333+00:00

    The error details and behavior described match known FSLogix issues where the profile container fails to attach and FSLogix falls back to creating a new (temporary/local) profile. From the available information, the supported restore and reattach process focuses on ensuring:

    1. The restored VHDX can be successfully attached (size, integrity, and storage health).
    2. The storage path and permissions are correct.
    3. Network/DNS and SMB access are healthy.

    Use the following checks and steps, in order:

    1. Verify storage path configuration (VHDLocations/CCDLocations)
      • On the AVD session host, open Registry Editor and check:
        • HKEY_LOCAL_MACHINE\SOFTWARE\FSLogix\Profiles
        • HKEY_LOCAL_MACHINE\SOFTWARE\Policies\FSLogix\Profiles (if used)
      • Confirm VHDLocations (or CCDLocations for Cloud Cache) points exactly to the Azure Files share where the restored VHDX resides and is of type REG_SZ or REG_MULTI_SZ as documented.
      • If multiple paths are configured, ensure the restored VHDX is in one of those paths and that the path is reachable.
    2. Confirm storage permissions for the user and session host
      • FSLogix profile attach failures commonly result from SMB permissions issues.
      • From the AVD session host, sign in as (or run as) the affected user and:
        • Browse to the UNC path configured in VHDLocations.
        • Verify the user can list the directory, open it, and create a test file/folder.
      • If the user cannot read/write, configure permissions as per the storage provider guidance (for SMB, see the “Configure SMB Storage Permissions” article referenced in the FSLogix docs).
    3. Check for network or DNS issues to the Azure Files share
      • From the AVD session host, run Test-NetConnection to the file server / Azure Files endpoint:
        • Test-NetConnection -ComputerName <server-fully-qualified-domain-name> -CommonTCPPort SMB
      • Ensure name resolution and SMB connectivity succeed. Any failure here can cause 0x0000003B (unexpected network error) and prevent the restored VHDX from attaching.
    4. Validate storage capacity and container size
      • Ensure the Azure Files share has sufficient free capacity. If the storage provider is full:
        • New containers cannot be created.
        • Existing containers may fail to attach or detach correctly.
      • On the share, right‑click the restored VHDX and check Size on disk.
        • Compare with the SizeInMBs FSLogix setting.
        • The container must have more than 200 MB free to attach successfully.
      • If the container is at or near its maximum size, increase SizeInMBs so FSLogix can expand the disk, then mount the VHDX offline and remove unnecessary data (with caution, as deleting the wrong data can corrupt the profile).
    5. Confirm the restored VHDX is not in use and not corrupted
      • Ensure no other session host has the same profile container attached. If the profile is in use on another VM, FSLogix may fail to attach and fall back to a temporary/local profile.
      • Temporarily mount the restored VHDX on a maintenance VM to confirm it mounts cleanly and the file system is healthy.
    6. Check for third‑party firewall/IPS interference
      • If third‑party firewall or intrusion prevention software is installed on the AVD session host, temporarily disable it and reproduce the sign‑in.
      • FSLogix relies on SMB (and HTTPS for Cloud Cache) and its file system drivers; interference here can cause attach failures.
    7. Monitor for temporary/local profile fallback
      • When the container fails to attach, FSLogix may:
        • Allow a temporary or local profile, or
        • Block sign‑in if PreventLoginWithFailure / PreventLoginWithTempProfile is enabled.
      • If RemoteApp is used, note that frxshell.exe cannot block sign‑in for remote apps in some scenarios, so users may still sign in with a temporary/local profile even when those settings are enabled.
    8. General restore best practices for FSLogix containers
      • Restore the VHDX to the exact same path and name expected by FSLogix (including SID‑based folder naming convention).
      • Ensure the share, permissions, and network path are fully functional before allowing the user to sign in.
      • After restore, validate attach behavior with a test user or maintenance session before returning the profile to production use.

    If, after these checks, FSLogix still ignores the restored VHDX and creates a new small container, focus on:

    • Verifying the restored VHDX’s path exactly matches the configured VHDLocations path and naming convention.
    • Ensuring the restored container has sufficient free space and is not corrupted.
    • Confirming there are no storage permission or network/DNS issues, as these are the most common causes of attach failures leading to fallback profiles.

    References:

    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.