SOLVED

OneDrive exits and does not run properly, with Roaming Profile users

Copper Contributor

I wonder if anyone can help me get to the bottom of this.

 

We're seeing OneDrive fail to run correctly for a large number of users. Starting from a Fresh profile, or new user, the OneDriveSetup.exe appears to run to install the package in %APPDATA% as expected, but it doesn't stay running, it bombs out immediately.

 

No tray icon, no hooks into the OneDrive folder in Windows File Explorer. It's not merely an issue of it not syncing, it just doesn't run at all.

 

There are no hints as to why it's exiting in any logs I can find. I've searched the normal Windows App/System Event Logs, and taken a log at the text logs that appear inside the OneDrive folder under %APPDATA%.

We thought the version was too old at first, as Programs and Features was showing an older version number for the client, but poking the Updater app successfully install the latest version (it didn't do this without some coaxing) in a seemingly normal manner, and yet even after it's updated...it still won't stay running. Task Manager shows after traying to launch it, OneDrive.exe is present for a few seconds, but then disappears without ever having done anything.

 

But, curiously a whole bunch of people do have it working OK, and we can't seem to figure out what's different about them. One Class of users not affected are those who have Local Profiles only (profile path in AD is blank). There are a small number of people with Roaming Profiles for whom it still works, but anyone who has their Roaming Profile wiped & rebuilt suffers from the issue.

 

Not sure if the Roaming Profile thing is key to this, or a great big red herring. Just can't think what else could be affecting it.

 

Other noteworthy facts;

 

All users have Laptops and generally only sign in to that one system but are able to sign into any other device flexibly as required.

We have E3 Licensing across the board.

Group policy sets the OneDrive content folder as Excluded from Roaming Profile sync, and the only folder sync'd by default is named "OneDrive - OurOrgName" under the user's profile.

 

In the case of affected users, this folder isn't even being created, but I wouldn't expect it to until sync starts happening and pulling their content down from the cloud, and it never gets a chance to run.

 

 

Everyone affected can still access their content just fine via sharepoint/web interface, and the files section within Teams, and the OneDrive App on their Mobile phones. It's just the desktop client we have the issue with.

 

 

Can anyone offer any thoughts of what to check or test next?

 

 

 

3 Replies
Hi,

I have got 2 questions :)

Maybe instead of choosing the normal one drive installation, maybe choosing the /allusers (machine wide installer) so it will be installed in the program files folder?

Maybe looking into fslogix instead of putting the onedrive data in the roaming profile?
best response confirmed by PhotoVoltaic (Copper Contributor)
Solution

It turned out to be something annoyingly simple, the GroupPolicy "Block OneDrive..." being Enabled, setting the "DisableFileSyncNGSC=1" regkey, but we didn't notice this sooner because not all client PCs had picked up this Policy for various reasons. It had nothing to do with Roaming Profiles, that did indeed turn out to be a total red herring.

Just another one of those cases were you're sure it's not X, it must be Y or Z. But actually, it was X all along.

I just saw your post and the solution below and was hoping to get a better idea of what you have done to make it work?
What have you set in user profile (in AD), and in GPO in order to make it work with Roaming Profiles? I assume that user folders are also stored remotely?

Any help will be greatly appreciated.
1 best response

Accepted Solutions
best response confirmed by PhotoVoltaic (Copper Contributor)
Solution

It turned out to be something annoyingly simple, the GroupPolicy "Block OneDrive..." being Enabled, setting the "DisableFileSyncNGSC=1" regkey, but we didn't notice this sooner because not all client PCs had picked up this Policy for various reasons. It had nothing to do with Roaming Profiles, that did indeed turn out to be a total red herring.

Just another one of those cases were you're sure it's not X, it must be Y or Z. But actually, it was X all along.

View solution in original post