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
I hope that it will help you a lot!
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?
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.
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.
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.
Great to hear! thanks for sharing
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.
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.