OneDrive Silent Configure Process broken - Will not spawn new process

[Stephen McGuigan]

Hi All

I am having a few issues with OneDrive Autoconfigure.

I have followed the documentation to set up the GPOs for silent config. my config is below (tenant IDs and usernames hidden to protect the innocent)

Computer GPOS -

 

with the following GPPs in to set some registry keys:

User GPOs -

and GPP for EnableADAL

My problem is that on user login, OneDriveSetup.exe launches as expected and spawns child processes to set the client up.

it then creates a "OneDrive" node in explorer (rather than "OneDrive - ClientName") and the Onedrive.exe process terminates.

it does not spawn the OneDrive for Business process.

If I then click on the "OneDrive" node in explorer, it spawns a new OneDrive.exe process which removes the "OneDrive" node, restarts explorer and replaces it with "OneDrive - ClientName" fully configured and working...

below is the process flow.

Has anyone seen this issue before?

Thanks in advance

Stephen

[#2]

Hi Stephen,

I'm seeing the same in a customer environment.

On second login, OneDrive silently configures fine (and in my case, kicks of KFM).

If I do any of the following:

• Go into OneDrive's settings and click "add an account" - silent config completes - without prompt for credentials.
• End the OneDrive.exe process - and restart - silent config completes 
• Log off and log back in again - silent config completes

Did you get to the bottom of this? I don't want to script around it, but given the nature of the shared devices i'm deploying, i may have to.

Stefan

[#3]

Hi Stefan

I was at msignite last week and showed it to a couple of the one drive developers.

It has been logged as a bug. I am working with them to resolve.

Stephen

[#4]

Hi Stephen,

We are having the same issue - however it has only cropped up for us when testing 1809 build of Windows 10. 1803 works fine.

Is there a link anywhere to the specific bug Microsoft have logged?

[#5]

Hi Stephen

I've been trawling the net for the same. Everything worked fine on Win 10 1709 and 1803. Once we moved over to 1809, OneDrive only signs the user in after the second time they log in. Unfortunately a large portion of our customer's computers are set up as Kiosks, which means all data are reset as soon as you restart. Therefore they require OneDrive to sign the user in the first time.

So after investigating, this is what I found:

In Win 10 1809, the OneDriveSetup.exe version 18.143.717.2. sits under C:\Windows\SysWOW64. When a new user logs in, the registry runs OneDriveSetup.exe /thfirstsetup

This overwrites whatever version of OneDrive the user has under %UserProfle%\Appdata\Local\Microsoft\OneDrive. This also takes a while to complete. Once it's done after about 5 minutes, the registry entry changes to: "C:\Users\UserProfileName\AppData\Local\Microsoft\OneDrive\OneDrive.exe" /background

Hence it only runs OneDrive for business properly after the restart, and apply the Group Policies accordingly.

I'm in the process of testing overwriting the installer with the new 19, or older 17 version (Win 10 1803 has 17.3.6816.313). If anyone got it working so far, please let us know :)

Cheers.

Loftey

[#6]

Hi @Stephen McGuigan, @Stefan van der Busse and @RobinPengilley 

Ok, so OneDriveSetup 19.2.107.8 from the production ring here: https://support.office.com/en-us/article/new-onedrive-sync-client-release-notes-845dcf18-f921-435e-b...

seems to work. I can see 2 choices - mess with the default user registry, or mess with SysWOW64.

** WARNING - don't mess with either of these unless you know what you're doing. Always make backups and test first!! **

Registry method: Load the Default Profile hive > Software\Microsoft\Windows\CurrentVersion\Run

Change the OneDriveSetup entry and point it to the 19.2.107.8 setup version instead. Unload hive. Restart and test.

SysWOW64 method: Change the permissions of OneDriveSetup.exe so you can replace it with the 19.2.107.8 version. Restart and test

If you find an easier/better way, feel free to comment. Note - this was for an Azure AD joined environment.

Cheers

Loftey