I have noticed that MS has introduced the option to install Onedrive per machine rather than per user:
You need sync client build 19.043.0304.0003 or later for this to work. Download is available from:
We have tried this and it works nice. You might check this out...
Note: Feature is still in preview!
At this moment we don't have a lot of configuration setup regarding Onedrive.
It's purely installing Onedrive in the golden image using the correct Onedrivesetup.exe and the new command, and using group policy to force the use of files on demand and SSO. The user is still able to download files to it's desktop but these files are discarded once they logoff due to the fact we are using non-persistend desktops.
There is actually no UEM configuration needed for this to work.
You might need to make a few tweaks if you are also using Writable Volumes.
You are correct! --- "There is actually no UEM configuration needed for this to work."
I setup the new Machine-Based OneDrive (Build 19.043.0304), applied a couple computer Group Policies to force Files-on-demand & Auto Sign-in.
Logged in, and it sets up my Files-on-demand OneDrive after a minute or so.
It does force kill the explorer.exe process during the setup...which is kinda annoying. But other than that, this is completely usable in a non-persistent environment.
If anyone knows of a reason to use UEM to capture anything from the profile related to OneDrive, please let us know.
That explorer restart is indeed annoying but sadly is by design as mentioned by MS: Why does OneDrive restart Windows Explorer? - OneDrive
"Is OneDrive crashing Windows Explorer?
No, the restarting of Windows Explorer is to ensure that sync can work correctly."
Glad this info might help others ;-)
Working on a Windows 10 1803 project and one of the requirement was to make Onedrive available in a non-persistent VDI environment
With the new client installed on the local machine instead of installing it under "appdata/local" and doing some additional configuration it works........
After testing some days, we have noticed that after a user uploads content to Onedrive from the local physical machine and logged in directly with a new session in VDI, all the old content will be deleted in the cloud and only the recent uploaded files shows up for on-demand!!! within the virtual desktop
we have managed the following configuration with Ivanti/Appsense
# to avoid warnings that the onedrive folder has been removed or replaced. the following folders and registry settings to provide SSO will be saved.
- C:\Users\%username%\OneDrive - vmware\.*
- C:\Users\%username%\OneDrive - vmware\
If we don't include the file "C:\Users\%username%\OneDrive - vmware\.*" Onedrive will ask the user at every login that the folder has been replaced, so you can choose to retry or setup onedrive again.
Does anyone have a clue what happened?
I have a couple of customers that have been running this setup for a couple of months without any issues. Certainly with the latest Machine based installer the setup is a lot cleaner as it used to be with the user based installer. And as mentioned in the blog, there are some benefits with the method, the profile bloat, and performance impact during logon are gone.
As FSlogix was recently bought by Microsoft, I highly suggest checking this out as it will benefit the manageability and the overall UX of OneDrive. Everything gets redirected into a VHDX and therefore provides the "data persistence" on a non-persistent VDI. Meaning the client won't be downloading all files (even files-on-demand) every time they log in to a new VM.
I know the same setup is also possible with a Writeable volume (AppVolumes) but I haven't had the time to test this in the lab.
If anyone has some additional questions, don't hesitate to ask or send me something on twitter "@HerremansJens"
We have got the app working apart from it gives the error about the folder not being the same folder.
It opens on startup, we have Files On Demand enabled and it remembers who is logged into OneDrive, but it then gives the error below every time a user logs in, which if they click 'try again' it works ok for that session:
I have read around online but have not found anything about someone actually fixing the error we are getting. It all seems to be about getting the app working in the first place (which we already have).
We have experienced the same sync errors after logging in (W10 1809/Fslogix/system wide installer/UEM) this seems to be fixed in build 19.152.0927. This is the current production ring version, the current enterprise ring has this error. The user impact is enough for us to switch from enterprise ring to production ring until the fix is implemented in enterprise.
We are already running on that version. One of my first thoughts was to try different versions of OneDrive, but it has made no difference.
With FSlogix something like this also happned when only onedrive data was included and not sharepoint data and only when a user/tester chose to sync a sharepoint library to the onedrive client.