OneDrive Client

[clareq]

I use the method here: Updating the builtin Onedrive client in Windows 10 1511 during OS deployment – CCMEXEC.COM – Enterprise Mobility to update to the new client before any users log on.

[Theldron]

Not had time to try anything with it yet. Probably going to abandon it until my new "test PCs" turn up (Very PC have run out of motherboards so they are now delayed, grrr). I was getting nowhere very slowly testing on two computers that take almost a minute to respond to me pressing Ctrl+Alt+Del.

 

Hi Katy,

 

Did you ever get this running? Or has anyone else?

 

I am trying to get OneDrive on demand running, but can't even get OneDrive to run at the moment. When the PC joins the domain it won't run, outside fine. Have set the GPO to disable for the "Prevent OneDrive being used for file storage" and added the %localappdata%\Microsoft\OneDrive to Applocker, but still when I click on OneDrive I get nothing.

 

Cheers

[Katy]

Yes, there was an old GPO setting for back when it was called SkyDrive which was set to prevent it running, got rid of this and it worked.

[gshaw]

A few things:

 

• Users need write access to C: (i.e. don't block drives via GPO)
  
• No restrictions on running from local appdata
  
• Registry keys in place for single sign-on (enable ADAL if you have any form of SSO)
  
• Allow downloads from Microsoft to get the auto updater file
  

Here's how I got it running on 1709

 

https://gshaw0.wordpress.com/2017/11/08/onedrive-files-on-demand-first-steps/

 

For us at least it's miles better than that nasty WebDAV protocol and only brings down the files required. The only concern I have long-term is the local cache growing too large. Trying to figure out a script for that but MS doesn't have great support for analysing their own file system "space used on disk" via scripting

Edited October 11, 2018 by gshaw

[Theldron]

Ah right. I am on a new network built last year, but was built by an outside organisation, so not sure if anything is there.

[Theldron]

Right, I blocked inheritance to the test PC and have slowly been adding the GPOs back to it. It seems to be Applocker that is blocking OneDrive. I have a Path rule in their %OSDRIVE%\Users\*\AppData\Local\Microsoft\OneDrive but this doesn't seem to be working.

[rosslaing]

sadams1980 Try adding \* at the end of your path

%OSDRIVE%\Users\*\AppData\Local\Microsoft\OneDrive\*

 

**Edit - ignore the space after \OneDrive, no idea why thats going in there, I aint typing one! **

Edited October 16, 2018 by rosslaing

[richmackie]

I've also spent ages trying to get this to work but I've only got so far. At one school where I have AD synced O365 and SSO (so the store and suchlike sign users in automatically) I tried to run OneDrive.exe as my user to set it up, but the folder wasn't in %localappdata%\Microsoft, so I copied it from the administrator's profile folder. Ran that and it signed me in and set itself up, but then didn't like me moving to another PC, because when I did the same thing it complained that the OneDrive folder couldn't be found in my local profile and made me sign in again.

 

Why do Microsoft make things so difficult?

[Theldron]

sadams1980 Try adding \* at the end of your path

%OSDRIVE%\Users\*\AppData\Local\Microsoft\OneDrive\*

 

**Edit - ignore the space after \OneDrive, no idea why thats going in there, I aint typing one! **

 

Thanks I am not at the school today, will try it tomorrow.

[Theldron]

I've also spent ages trying to get this to work but I've only got so far. At one school where I have AD synced O365 and SSO (so the store and suchlike sign users in automatically) I tried to run OneDrive.exe as my user to set it up, but the folder wasn't in %localappdata%\Microsoft, so I copied it from the administrator's profile folder. Ran that and it signed me in and set itself up, but then didn't like me moving to another PC, because when I did the same thing it complained that the OneDrive folder couldn't be found in my local profile and made me sign in again.

 

Why do Microsoft make things so difficult?

 

Because where would be the fun if everything was simple.

[richmackie]

Because where would be the fun if everything was simple.

 

I say that a lot to be fair. And you get to feel pleased with yourself when you eventually get something to work.

[Theldron]

Hi all,

 

Tried the path suggested still no luck. I get a message up saying the "administrator has blocked the program".

 

Here are the Applocker rules in place:

 

 

Also I had to take the test PC off the domain to install the latest OneDrive client. When I try to install the client on the domain I get an error:

 

FileSyncConfig.exe "The application was unable to start correctly (0x0000364). Click OK to close the application.

[rosslaing]

Have you tried by Publisher yet? I tend to do that anyway as exe's dont always seem to be in the same place depending on who installed stuff and how long ago it was. Only suggesting this to see if it is a path issue. I normally just use the Product name, which should be Microsoft Onedrive, this will also cover the ONEDRIVESTANDALONEUPDATER.EXE

[Theldron]

Have you tried by Publisher yet? I tend to do that anyway as exe's dont always seem to be in the same place depending on who installed stuff and how long ago it was. Only suggesting this to see if it is a path issue. I normally just use the Product name, which should be Microsoft Onedrive, this will also cover the ONEDRIVESTANDALONEUPDATER.EXE

 

Thanks mate, i'm just trying that now.

 

[Theldron]

Found in event viewer this file is still being blocked.

 

%OSDRIVE%\USERS\STAFFTEST\APPDATA\LOCAL\MICROSOFT\ONEDRIVE\17.3.6816.0313\FILESYNCCONFIG.EXE

[Theldron]

Found in event viewer this file is still being blocked.

 

%OSDRIVE%\USERS\STAFFTEST\APPDATA\LOCAL\MICROSOFT\ONEDRIVE\17.3.6816.0313\FILESYNCCONFIG.EXE

 

Added that to Applocker, still being blocked.

[rosslaing]

im beginning to feel your pain

[Theldron]

im beginning to feel your pain

 

At last!!!!!! Progress made, looking at Applocker in event viewer found it also blocks DLL files in the Appdata\local\.......onedrive folder. Need to add this to the DLL rules in Applocker.

[Katy]

Going to resurrect my old thread (googling for this issue brought me back to my own thread as one of the top results...)

 

I've got Win 10 1809 installed, office Click to Run, and the GPO settings to make OneDrive automatically configure. It does - but eventually, there is a 5 minute delay between the desktop appearing, and explorer restarting and "OneDrive - TenancyName" being available.

 

During this 5 minute window at one point "OneDrive" appears in Explorer and lets people save things into a folder on the C drive which isn't synced anywhere.

 

Subsequent logins on the same user/machine combo and it works perfectly - OneDrive Tenancyname is available straight away.

 

Has anybody managed to get this 5 minute delay reduced down to a couple of seconds? I can't really tell everybody "Your first logon you can't do anything for 5 minutes" - especially pupils who move machines every lesson - and we're having to remove all on premise storage, so users will only be presented with OneDrive for storage.

 

As a side point, getting Office Click to Run to auto sign in seems to be a black art - if I open it before OneDrive has finished doing its thing, I'm prompted. If I open it after, I'm prompted but cancelling lets me in anyway. If I wait for subsequent logons, I'm not prompted at all.

[KevinB]

The long delay is caused by OnedriveSetup.exe running in both machine and then user contexts, then realising there is an update, downloading it, and running that in both machine and user contexts. It's a seriously bad way of doing things IMO.

 

The workaround I have in place is a bit OTT but seems to work. You'll need SCCM or some other timed package allocation software to get it working. The following is for SCCM but you can adapt it to others I guess.

 

1. Manually download the latest Onedrive client and store it in your package repository.

2. In the same folder create update.cmd:

%SYSTEMROOT%\system32\takeown /f %SYSTEMROOT%\SysWOW64\OneDriveSetup.exe >> %SYSTEMROOT%\logs\Onedrive.log
%SYSTEMROOT%\system32\icacls %SYSTEMROOT%\SysWOW64\OneDriveSetup.exe /Grant System:(F) >> %SYSTEMROOT%\logs\Onedrive.log
Copy %~dp0onedrivesetup.exe %SYSTEMROOT%\SysWOW64\OneDriveSetup.exe >> %SYSTEMROOT%\logs\Onedrive.log /Y

3. Create a package to deploy the files and run update.cmd on whatever schedule you choose. I set it to run hourly so that within an hour of startup a PC will have the latest available version of OnedriveSetup.exe. I also deploy that package as a final step in OSD TSs.

 

The weak point is me remembering to check the site for the latest version of OnedriveSetup.exe I suppose I could script something to scrape it every so often but that sounds like work

 

Edit: With this in place we find students can start work straight away if it's something new, Onedrive kicks in after about 2 to 2:30 the first time and 10 to 15s subsequently on the same PC, and anything they save in the time that Onedrive is setting up gets synced properly. Obviously they won't see existing work until it's in sync.

Edited February 6, 2019 by KevinB

[gshaw]

The long delay is caused by OnedriveSetup.exe running in both machine and then user contexts, then realising there is an update, downloading it, and running that in both machine and user contexts. It's a seriously bad way of doing things IMO.

 

The workaround I have in place is a bit OTT but seems to work. You'll need SCCM or some other timed package allocation software to get it working. The following is for SCCM but you can adapt it to others I guess.

 

1. Manually download the latest Onedrive client and store it in your package repository.

2. In the same folder create update.cmd:

%SYSTEMROOT%\system32\takeown /f %SYSTEMROOT%\SysWOW64\OneDriveSetup.exe >> %SYSTEMROOT%\logs\Onedrive.log
%SYSTEMROOT%\system32\icacls %SYSTEMROOT%\SysWOW64\OneDriveSetup.exe /Grant System:(F) >> %SYSTEMROOT%\logs\Onedrive.log
Copy %~dp0onedrivesetup.exe %SYSTEMROOT%\SysWOW64\OneDriveSetup.exe >> %SYSTEMROOT%\logs\Onedrive.log /Y

3. Create a package to deploy the files and run update.cmd on whatever schedule you choose. I set it to run hourly so that within an hour of startup a PC will have the latest available version of OnedriveSetup.exe. I also deploy that package as a final step in OSD TSs.

 

The weak point is me remembering to check the site for the latest version of OnedriveSetup.exe I suppose I could script something to scrape it every so often but that sounds like work

 

Edit: With this in place we find students can start work straight away if it's something new, Onedrive kicks in after about 2 to 2:30 the first time and 10 to 15s subsequently on the same PC, and anything they save in the time that Onedrive is setting up gets synced properly. Obviously they won't see existing work until it's in sync.

Sounds very similar to what I've done on my MDT TS but also need to schedule the latest client download [emoji1]

 

Why MS can't update the client (and Store appa for that matter) via WSUS really is a mystery.

Edited February 6, 2019 by gshaw

[mrbios]

The long delay is caused by OnedriveSetup.exe running in both machine and then user contexts, then realising there is an update, downloading it, and running that in both machine and user contexts. It's a seriously bad way of doing things IMO.

 

The workaround I have in place is a bit OTT but seems to work. You'll need SCCM or some other timed package allocation software to get it working. The following is for SCCM but you can adapt it to others I guess.

 

1. Manually download the latest Onedrive client and store it in your package repository.

2. In the same folder create update.cmd:

%SYSTEMROOT%\system32\takeown /f %SYSTEMROOT%\SysWOW64\OneDriveSetup.exe >> %SYSTEMROOT%\logs\Onedrive.log
%SYSTEMROOT%\system32\icacls %SYSTEMROOT%\SysWOW64\OneDriveSetup.exe /Grant System:(F) >> %SYSTEMROOT%\logs\Onedrive.log
Copy %~dp0onedrivesetup.exe %SYSTEMROOT%\SysWOW64\OneDriveSetup.exe >> %SYSTEMROOT%\logs\Onedrive.log /Y

3. Create a package to deploy the files and run update.cmd on whatever schedule you choose. I set it to run hourly so that within an hour of startup a PC will have the latest available version of OnedriveSetup.exe. I also deploy that package as a final step in OSD TSs.

 

The weak point is me remembering to check the site for the latest version of OnedriveSetup.exe I suppose I could script something to scrape it every so often but that sounds like work

 

Edit: With this in place we find students can start work straight away if it's something new, Onedrive kicks in after about 2 to 2:30 the first time and 10 to 15s subsequently on the same PC, and anything they save in the time that Onedrive is setting up gets synced properly. Obviously they won't see existing work until it's in sync.

 

When i try this method it breaks shared computer login for licensing Office C2R from working, and users start getting prompted to login when i load an office application such as word. (Even though in the top right it says the user is logged in)

[liamrobbo]

Going to resurrect my old thread (googling for this issue brought me back to my own thread as one of the top results...)

 

I've got Win 10 1809 installed, office Click to Run, and the GPO settings to make OneDrive automatically configure. It does - but eventually, there is a 5 minute delay between the desktop appearing, and explorer restarting and "OneDrive - TenancyName" being available.

 

During this 5 minute window at one point "OneDrive" appears in Explorer and lets people save things into a folder on the C drive which isn't synced anywhere.

 

Subsequent logins on the same user/machine combo and it works perfectly - OneDrive Tenancyname is available straight away.

 

Has anybody managed to get this 5 minute delay reduced down to a couple of seconds? I can't really tell everybody "Your first logon you can't do anything for 5 minutes" - especially pupils who move machines every lesson - and we're having to remove all on premise storage, so users will only be presented with OneDrive for storage.

 

As a side point, getting Office Click to Run to auto sign in seems to be a black art - if I open it before OneDrive has finished doing its thing, I'm prompted. If I open it after, I'm prompted but cancelling lets me in anyway. If I wait for subsequent logons, I'm not prompted at all.

Onedrive takes around 4-5 mins to 'provision' on first login, but i found it wasn't auto logging my users in, despite Azure SSO and the "silently configure" GPO being Set. The user had to click settings and 'add account' before it would kick in. In the end i've written a batch script that checks to see if the Onedrive.exe exists yet, once it does, run the exe and run first time setup. I've also converted this into a GUI using VB to call the batch script and provide a visual progress bar to users, once its done it will tell them its ready and open their one-drive folder. Its a bit of a workaround but it works and makes the process fully automatic. Will provide the source files soon if anyone wants them.

[Katy]

Onedrive takes around 4-5 mins to 'provision' on first login, but i found it wasn't auto logging my users in, despite Azure SSO and the "silently configure" GPO being Set. The user had to click settings and 'add account' before it would kick in. In the end i've written a batch script that checks to see if the Onedrive.exe exists yet, once it does, run the exe and run first time setup. I've also converted this into a GUI using VB to call the batch script and provide a visual progress bar to users, once its done it will tell them its ready and open their one-drive folder. Its a bit of a workaround but it works and makes the process fully automatic. Will provide the source files soon if anyone wants them.

Is it just as slow using your script or does that speed it up any? 5 minute wait at the start of every lesson for pupils (except the lucky few who happen upon a PC they have used recently) isn't gonna work.

[liamrobbo]

Unfortunately doesn't speed up the process, from what i can tell most of the MS sites are saying its 'Just how it is' and Onedrive needs to be installed per user. Copying the files to default profile during deployment might make an impact but not had chance to test that yet. i only have staff on Onedrive at the moment so its a not much of an issue just yet