File Explorer is slow when traversing files synced with OneDrive

I would love to know if anything has improved after the oneDrive update

Any news if Microsoft resolved this with patches or is the administrator full access on the regkey still the workaround? 

My findings indicates that OneDrive's post-installation sync performance depends on how admin privileges are elevated.
Installing with a local admin account results in smooth folder traversal after granting "All Packages" Full Control on the registry key.
However, installing via "Run as administrator" with an admin password causes sync delays, even after granting "All Packages" Full Control on the registry key.

Can anyone confirm if it got better with the latest OneDrive update?

I note the https://support.microsoft.com/en-au/office/onedrive-release-notes-845dcf18-f921-435e-bf28-4e24b95e5fc0 currently show 24.226.1110.0004 (December 9, 2024) as the current version. It calls out:

• Resolved issue causing File Explorer slowness, especially in VDI environments where many sessions share the same host.

Hi,

I have been in contact with Microsoft support for more than 6 months regarding the same issue, but not in a context of AVD.

Any Windows 11 workstation with few SharePoint libraries synchronized has the same issue. Browsing OneDrive folders in Windows Explorer is slow and sluggish. The problem has existed since the very first Windows 11 release, Windows 10 has never been concerned.

Support told me to delete the subkeys in SyncRootManager, which effectively solves the issue for a short term, but then you completely loose the OneDrive integration (no sync status, no OneDrive contextual menu entries, etc.) and subkeys are recreated on reboot or OneDrive restart.
In SyncRootManager, I don't have many subkeys, only one per synced Library, plus my own OneDrive. But I guess it creates the same situation as a multi-user environment.

Support also told me a OneDrive fix would be release in December.

Looking on the Internet, I came across this thread, and did the authorization change on the Package key in registry, which way more effective as I keep the OneDrive SyncStatus, contextual menu entries to "Always keep on this device" and "Free up space", and it persists after reboot, but I also lost the other handy OneDrive entries in  the contextual menu (View Online, Share, Version History...).

I saw on OneDrive release notes page that the issue should be fixed since November 25th with version 24.221.1103.0003 : "Resolved issue causing File Explorer slowness, especially in VDI environments where many sessions share the same host."
Current OneDrive version is 24.226.1110.0004 which was release on December 9th.

Unfortunately, nothing is solved to me with those versions, have you seen any improvement on your side?

I have wasted an enormous amount of time with that simple issue, plus the productivity loss of users in my company which are complaining. I hope this will be fixed soon.

Like described in my previous post :

Customer with 4 AVD-servers still has this problem. On each server the exact same versions installed :

• Windows 11 Build 23H2 version 22631.4602
• Microsoft FSLogix Apps version 2.9.8884.27471
• MS OneDrive version 24.211.1103.0003
• No applications like Citrix installed

I change the permissions on the newest OneDrive key under 'HKEY_CLASSES_ROOT\PackagedCom\Package' and then immediatelly is the delay gone.

I did some further research. When  I change the permissions on this key without saving, and immediately revert and save the changes the delay is also gone.

For this I created a PowerShell oneliner :

gci "REGISTRY::HKEY_CLASSES_ROOT\PackagedCom\Package"|Where{$_.PSChildName-Match"OneDrive"}|%{$P=$_.Name;Set-Acl "REGISTRY::$P" $(Get-ACL "REGISTRY::$P")}

Execute this and the same permissions are applied and delay is gone.

Hi  fr-ma 

Thanks for this, I created a scheduled task that at startup, calls a powershell script:
Remove-Item -Path HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\SyncRootManager\* -Recurse

I tested this and could see the reg keys are cleared and new reg keys are generated when users sign into the AVD session hosts.

Users are already confirming better experience now. 

This video describes exactly the problem : https://rivier.hosted.panopto.com/Panopto/Pages/Viewer.aspx?id=203b5b74-07d9-4ec1-8da0-b02a015a0e18
Additional information; delay opening folders and files directly from the desktop (MS OneDrive redirected). AVD-environment with FS Logix profiles. I did a thorough research.

Solution per AVD-server :
- Put the AVD-server in drain mode.
- Log off all users.
- Log on with an Administrator account.
- Remove MS OneDrive.

- Remove the following registry keys :
HKEY_CLASSES_ROOT\PackagedCom\Package > Remove all keys that begins with 'Microsoft.OneDriveSync_'
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\PackagedCom\Package > Remove all keys that begins with 'Microsoft.OneDriveSync_'
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\OneDrive
HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\OneDrive

- Download newest MS OneDrive cliënt :
https://support.microsoft.com/en-us/office/onedrive-release-notes-845dcf18-f921-435e-bf28-4e24b95e5fc0

- Install MS OneDrive : .\OneDriveSetup.exe /allusers
- Log on with an user-account.

No need to reboot the server.

Anamolies :
- Different versions after installing MS OneDrive :
Sometimes version '22.012.0117.000' is installed, and after couple of seconds the version changes to version '24.192.923.6.0'. Other times version '24.186.0915.0004' is installed. I decided to keep the newest version '24.192.923.6.0' installed, that is mostly the version after the first reinstall.

- After reinstallation problem isn't resolved :
The permissions are exactly the same as on other AVD-servers that has the problem resolved. Strange enough when I change the permission for existing entry 'All Application Packaged' to Full Control the problem is resolved. Even when I undo the change... I think when the problem still persists you have to remove MS OneDrive once again, remove all earlier named registry entries, and install MS OneDrive again. I don't have an explanation for this.