Introduction

A profile storage migration can move FSLogix containers to the new file platform while session hosts still mount user profiles from the old share. Users log in with stale settings, one host pool uses the new location while another still reads the retired path, or sign-in breaks only after the previous share is shut down because profile path policy, host pool images, and session host registry settings often persist beyond the storage cutover.

Treat this as a profile-path problem instead of a generic FSLogix failure. Start by checking which VHD or VHDX path an affected session host actually mounts during logon, because migrations often validate the new storage share and copied profile containers while hosts continue following older redirection settings.

Symptoms

  • FSLogix profile containers still mount from the old share after migration
  • Users see stale desktops or settings despite a completed profile move
  • One host pool uses the new profile location while another still uses the previous share
  • Logons fail only after the old profile share is disabled
  • New session hosts work, but existing hosts still reference the retired path
  • The issue started after moving profile storage, VDI host pools, or file services

Common Causes

  • FSLogix VHD locations in GPO or registry still point to the old share
  • Session host images or golden templates still contain the previous profile path
  • One host pool or OU received updated policy while another still applies the retired configuration
  • DFS namespace or share aliases still resolve to the old backend
  • Profile containers were copied, but path publication and host configuration were not updated everywhere
  • Validation confirmed the new share contained profiles but did not verify where live hosts actually mounted them from

Step-by-Step Fix

  1. Capture one affected logon and record the exact FSLogix profile path, mounted container, and session host configuration it actually uses, because the live mount path determines where user state is loaded from.
  2. Compare that active profile path with the intended post-migration storage design, because one stale GPO or registry value can keep many users tied to the retired share.
  3. Review FSLogix policy, session host registry settings, golden images, DFS or share aliases, and host pool config for references to the old profile path, because profile attachment usually spans storage, policy, and image layers.
  4. Check each host pool, OU, and session-host image separately if behavior differs, because migrations often fix one pool while another still mounts containers from the previous share.
  5. Update the authoritative FSLogix configuration so affected hosts mount profiles from the intended share, because copying VHD files alone does not retarget logon behavior.
  6. Run a controlled sign-in from an affected host pool and confirm the user profile mounts from the intended location, because a successful desktop launch does not prove the right backend served the profile.
  7. Verify the old share no longer receives profile-mount activity from migrated hosts, because split profile sourcing can remain hidden while both locations are online.
  8. Review permissions, file locks, and profile cleanup timing if users still fail to switch, because the destination can be correct while storage access or concurrent mounts still block profile loading.
  9. Document which team owns FSLogix policy, host images, and migration validation so future profile-storage moves verify the actual mounted share before retiring the previous environment.