Profile Disks with FSLogix and Cloud Cache-only (due to lack of Azure AD-only support for Azure Files) can be pretty crappy, given FSLogix provides no pre-mount or post-mount offline chkdsk to ensure file system integrity of the profile volume. This lack of integrity checking invariably breaks things, such as OneDrive sync, which relies on a clean file system. Performing the offline chkdsk is made harder due to the fact the FSLogix VHDX won't mount using Powershell/Disk Manager/diskpart, so the only option is to use an AVD session host to log in to the impacted user, and performing a force-unmount chkdsk of the profile disk that's loaded for the impacted user.
Sometimes the profile is so borked it won't mount. The only option at this point is to look in C:\ProgramData\Fslogix\Cache for the impacted user, then copy an older .VHDX and .meta file for the impacted user back into the blob storage container used for the cloud cache (can check all the session hosts for different versions), or recreate the profile by renaming/deleting the blob storage container used by the impacted user.
TODO: weekly/monthly copy of the cached profiles to a separate Azure VM/storage disk, as this is easier than implementing a backup system for page blobs, given Microsoft can't be bothered providing a backup/restore framework for this.
Have the impacted user log into an AVD session host
Create a text file named '<user>.txt' in the user's profile folder
Make sure all apps are closed (browsers, Office, OneDrive)
Don't bother with ondrive.exe /reset - it rarely fixes the problem, as it doesn't do a proper reset
Log on to the AVD session host as an admin user
From an elevated Command Prompt, run 'mountvol'
You'll need to iterate over the entries listed as NO MOUNT POINTS
dir \\?\Volume{GUID}\\Profile
^ - if it's a profile disk, the first line with show 'Volume in drive \\?\Volume{GUID} is Profile-<user>', and the profile folder contents should list the '<user>.txt' file created earlier
Once you've identified the impacted user profile, run 'chkdsk /f \\?\Volume{GUID}'
^ - Answer Y to a force dismount
Chkdsk will repair the NTFS volume, fixing the underlying problem preventing OneDrive to sync and also fixing up any Office-related file system corruption
Sign out and sign back in to the impacted user on an AVD session host
Quit OneDrive and any other Office apps
Control Panel > User Accounts > Credential Manager > Windows Credentials
- Remove any Microsoft_OneDrive entries and Office entries
- Only virtualapp/didlogical needs to be there
Use Task Manager to end explorer.exe for the impacted user
Run Regedit from Task Manager > File > Run New Task
- Rename HKEY_CURRENT_USER\SOFTWARE\Microsoft\OneDrive to OneDrive.OLD
- Go to HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Desktop\NameSpace and delete the GUID entries for the OneDrive tenant entries ("OneDrive - <M365 name>" and "<M365 name>")
Run CMD from Task Manager > File > Run New Task
- Cd c:\Users\<user>
- Ren "<M365 name>" "<M365 name>.OLD"
- Ren "OneDrive - <M365 name>" "OneDrive - <M365 name>.OLD"
- ^ - gets the old OneDrive folders out of the way
- Cd AppData
- ren Local\OneDrive OneDrive.OLD
- ^ gets rid of old cache + settings
Run explorer from Task Manager > File > Run New Task
The desktop shell will come back up, and now you can re-run OneDrive, sign in as the user and re-sync user content and sync document libraries.
No comments:
Post a Comment