OneDrive w/non-persistent VDI

[vap0r]

Anyone have any luck with this? We're using Horizon Instant-Clones with AppVolumes. We recently upgraded to 1709 with hopes that "Files on Demand" would help resolve our issues but no luck.. I can get UEM to handle most of the stuff but it seems the one hang up is the folder that OneDrive creates/looks at when you launch it. I'm constantly getting an error message that says "Your OneDrive folder can't be created in the location you selected, please try a different location.". As soon as I hit "try again" everything works fine. 

On the flip side, we've been trying to implement FSLogix Profile/O365 containers in order to make things work but we're running into a snag with corrupt VHD/VHDX while using AppVolumes. 

Surely someone else has a similar issue or a resolution? Well one can hope...

[kevinpower]

Hello Vap0r,

I have seen the popup with the text "Try again or Setup" before while making Onedrive available within our windows 10 guest vm.

Did you see my personal blog about it?

The problem is that Onedrive will check for a hidden file within the root folder of Onedrive under the C:\Users\%username%\OneDrive - vmware\

When the file exist, the warning will disappears.

Do not roam the hidden file with roaming profiles or UEM, it results that all your stored data will be deleted

https://virtualblog.nl/2019/05/28/vdi-onedrive-windows-10/

I hope that it will help you a lot!

[vap0r]

So I followed the guide and made the changes.  Everything is working outside of this error.  This has been an error that we've been getting throughout the process.

Any ideas?

[kevinpower]

Hello,

hmmm, did you installed the onedrive client on machine based? (“C:\Windows\SysWOW64\OneDriveSetup.exe /allusers”) or do you get this error while starting up Onedrive under a normal user?

[vap0r]

Yeah I did the machine based installer.  It looks like the issue is the AppVolumes service (svservice.exe) is trying to launch it as part of the writable when I try that route and it's launching it as an administrator which is causing the error.  Talking with our VMware rep he says there may be a writable exclusion we can use to make it work.  Just not sure what that is at this point. 

[jooji]

Thats where im at with OneDrive for Business too. I cant see a way around it because its looking for the folder location in C:\users... where OneDrive keeps the local cache for the user, as its a new instant clone its obviously not there. Unless if you can change where OneDrive it looking/configured to somewhere persistent but im not sure.

[vap0r · Accepted solution]

So we were able to come up with a solution using writable volumes.  It turns out it was working fine with regular users but any user with elevated credentials we were seeing the issue.

We were able to fix it but turning off the "Automatically launch OneDrive" via a logoff task in UEM (to keep it from launching under the svservice process).

That logoff task is:   REG DELETE "HKCU\Software\Microsoft\Windows\CurrentVersion\Run" /f /v "OneDrive"

Also have a separate shortcut setup in UEM that puts OneDrive in the startup folder to autolaunch if you're in a specific group, which allows OneDrive to be launched after the AppVolumes/svservice portion of the logon.

---------------------------------------------------------------------------------------------------------

Was it helpful? Let us know by completing this short survey here.

[kevinpower]

Great to hear! thanks for sharing

[LenBoyer]

Vap0r, would love to connect and compare. I have been struggling for 3+ months to get this addressed. VMWare engineers are not helpful at all.

[mchadwick19]

Did configuring svservice parameters disable\ignore run keys work (or was it attempted)? This should tell the process to ignore any of the virtualized run keys that exist in writables/appstacks.

[matkay521225]

We are continuing to experience issues with OneDrive in a non-persistent Windows 10 environment.  We have the latest versions of AppVolumes 2.18 and OneDrive deployed.  We applied the recommended fix "svservice parameters disable\ignore run keys" noted in this thread, but it did not resolve the OneDrive problems.  We are using the per-machine installation.  We are using the "Files On Demand" OneDrive feature.  We have narrowed this down to a combination of OneDrive files on demand and VMware Writable Volumes.  If writable volumes are disabled, OneDrive and files on demand work perfectly.