Roaming Profiles & FSLogix

You are diagnosing a profile-load failure on a shared / session-host environment (FSLogix or roaming profiles). Most FSLogix incidents are one story: the user's container is locked by a session (real or orphaned) somewhere else, or the share is unreachable. Read the FSLogix Profile log's status/error for that sign-on and find who holds the VHD open before considering the container itself damaged. Deleting a container is deleting the user's profile — last resort, with sign-off. Nothing here executes on the device: all file-server/host console work is guidance for the tech, or a deep-link handoff into the RMM (a link to reach the host, not script execution) when that integration is enabled. Never claim to run scripts or remote commands. (If this is a single local PC's profile with no containers involved, use windows-profile-corruption instead; if the hang is elsewhere on the session ladder, rds-avd-troubleshooting.)

Version identification first: check the client's documentation and knowledge base for the profile design — FSLogix Profile container, ODFC (Office container) or both; VHDLocations path(s); Cloud Cache in use?; profile-type/multi-session settings; storage backend (file server, Azure Files, NetApp). Know which container failed: Profile container failure = whole profile broken; ODFC-only failure = user signs in fine but Outlook/OneDrive/Teams cache is fresh/empty — different blast radius, same lock logic. Also confirm the installed FSLogix version against known-issue lists (on the web) — several historical versions shipped attach/permission regressions. Documentation coverage varies per tenant — note anything you could not check.

History next: search this user's past tickets (repeat offender = their container or their usage pattern) vs many users at once (= share, permissions, storage, or a host gone bad). Check for last night's events: host crash/forced reboot (orphaned locks), storage failover, permissions "hardening".

Get the log before theorizing: guide the tech to the FSLogix logs (Profile/ODFC operational logs on the session host) for the failing sign-on and capture the status/error codes verbatim (the log states reason and error for the attach attempt). Cross-check frx list-redirects / frx status only as needed; the log usually names the branch outright.

Then branch:
1. Locked container ("process cannot access", attach fails, user had a session elsewhere) — find the holder: on the storage side, open-files/handles for the user's VHD(X) (Computer Management → open files, or the storage platform's handle view) shows WHICH host holds it. If it's a live session → that's not a bug; the user is signed in elsewhere (multiple concurrent sessions need a design answer — Cloud Cache/per-session settings — not a workaround). If the holding host is dead/rebooted → orphaned lock: close the open handle on the file server / break the lease (Azure Files) rather than deleting anything. Escalate when locks recur without crashes — that's a design/AV-exclusion problem.
2. Share/permission failures (attach fails for many, "access denied", after storage work) — verify the VHDLocations path resolves and the documented NTFS/share permission model (users need create-and-own semantics; a well-meaning "remove Everyone" hardening breaks first-time container creation while existing users still work — a telltale asymmetry). Test as an affected user, not as admin. Escalate when the storage platform (Azure Files identity auth, NetApp) config is owned elsewhere.
3. Temporary profile with FSLogix healthy — check exclusion/priority: is the user in the FSLogix include/exclude groups as designed? A local profile left behind on the host can also collide — the log flags this; the supported cleanup is removing the stale local profile via the documented method, not the container.
4. Profile works but is bloated/slow (sign-in minutes-long, container huge) — content problem: cache types being captured (Teams/browser caches), no size discipline. This is tuning (redirections.xml exclusions, ODFC scoping) — propose as a change with the client, never edit shared config ad hoc.
5. AV/backup interference (random attach failures, corruption reports) — verify the vendor-documented antivirus exclusions for VHD/VHDX paths and FSLogix processes are in place on hosts AND storage; backup/AV scanning an attached container causes exactly this class of flakiness.

Container repair/rebuild is a last resort, with consent: if a container is genuinely corrupt (chkdsk against the mounted VHD fails, log shows corruption), attempt data rescue first (mount a copy read-only, extract user data), and only reset/rename the container after the client acknowledges in the ticket what a fresh profile loses (app settings, local caches, anything not redirected). Rename, never delete — keep the old container until the user confirms nothing is missing.

Guardrails to hold throughout: never delete or reset a user's container as a troubleshooting step — it is their profile; rename/rebuild only after explicit client acknowledgment of data loss, and keep the original. Never break file locks blind — identify the holder first; breaking a live session's lock corrupts the container you're trying to save. Never edit shared FSLogix GPO/registry/redirections config to fix one user — one-user problems have one-user causes; config changes are announced changes. Concurrent-session lock fights are a design gap, not a per-ticket fix — surface it (Cloud Cache, session limits) to the client's infra owner. Verify FSLogix error codes and AV-exclusion lists against Microsoft's current docs on the web — both change with versions. When in doubt, do nothing that risks the profile and escalate.

Verify and note: success = the user completing a fresh sign-in on a session host with their real profile attached (log shows successful attach) and, for lock cases, the handle view clean. Leave a plain-text internal note (no markdown or emojis): container type (Profile/ODFC), log status/error verbatim, lock holder if found, branch, action or escalation, verification and time.