OneDrive for Business Next Generation Sync Client - why APPDATA?? RRS feed

  • Question

  • Hi fellow admins, Hi Microsoft Support,

    we are currently planning our deployment of the OneDrive Next Generation Sync client. For obvious security reasons (Crypto trojans) we have Software Restriction Policies in use, and whitelisted %PROGRAMFILES% on our clients. This works great, as every kind of software is administratively installed at c:\Program Files, and the user may execute binary files from there because of the whitelisting. 

    Taking a look at the Installation process of the Onedrive NG Sync Client, it installs itself into the User Profiles APPDATA Directory like any usual trojan/virus does, instead of the usual %PROGRAMFILES% Directory. Just... no words... Microsoft, what the heck, why???

    I do not see any kind of advantage using the APPDATA approach. It has so many disadvantages, I don't even know where to start. Installing Software into the users APPDATA Profile directory is nothing else than a bad habit by some dumb software developers (looking at you, Spotify/Dropbox/MeetingTools/etc) to enable users to circumvent the lack of administrative rights. I don't get it why Microsoft is supporting this unprofessional behaviour by using this method by themself.

    Even worse: AFAIK it is not even possible to administratively deploy the OneDrive Next Gen Client to Program Files like some other software allows me to do optionally (e.g. Google Chrome). We are forced by Microsoft to use the Appdata folder.

    This means

    • we have to lower our security standards (SRP), punching a possible security hole for trojan developers
    • we have multiple instances of maybe very old unpatched insecure versions of onedrive.exe binaries in APPDATA Folders on our systems - one for every user profile.
    • In times of limited space of SSD Hard drives, is it really a good idea to develop software which is stored multiple times on a hard drive?
    • we administrators have lesser control over the installed software, as we have to replace/configure it multiple times per machine/user instead of only one time per machine. e.g. Current User Registry vs Local Machine Registry.....

    So I simply don't get the strategy behind this. I do not see a single advantage in a company environment. Can someone please explain me the bigger plan behind this? Or just tell me that there is an upcomming plan to make a deployment it to PROGRAMFILES possible?

    • Edited by romm81 Tuesday, June 14, 2016 8:06 AM typo
    Thursday, April 28, 2016 9:11 AM

All replies

  • Full disclaimer, I'm in Field Engineering and do not speak for the Product Group. The primary driver for this change has to do with installing software to run as a SaaS application where frequent updates must occur without elevation prompts to non-privileged users.  Whether its Office 365 ProPlus or NGSC, the concept is to *install the service* and then allow clients to pull frequent updates so they are always up-to-date.  The best place to provide feedback for PG design\change consideration is at https://office365.uservoice.com/

    Respectfully yours,


    Dave Guenthner [MSFT] This posting is provided "AS IS" with no warranties, and confers no rights. http://blogs.technet.com/b/davguents_blog

    Tuesday, May 3, 2016 12:13 PM
  • Thanks for your reply, Dave. I honestly appreciate your attempt do justify this decision. At least, you tried to give an answer.

    The primary driver for this change has to do with installing software to run as a SaaS application where frequent updates must occur without elevation prompts to non-privileged users.

    Sorry, this may sound harsh, but in my opinion this argument is ridiculous. The reason for switching to APPDATA Install Path is, that you don't want to bother the users with elevation prompts? Well, then lets go back to Windows 98 Single User, FAT32 Filesystem without any kind of permission restriction. What do we need UAC for, if our poor users feel bothered with administrative decisions? Lets just disable UAC completely so the user may install updates and software without getting annoyed by these popups. What was UAC even invented for? ... I hope you get my point.

    As you might know, there are a lot of possibilities to run a SaaS Service with frequent updates. Windows Task Scheduler, Background Services, WSUS... the hell, Microsoft even invented Click-to-run Setups to enable on-the-fly updates especially for their Office Products (which might include OneDrive!), without a single user prompt required. The Google Chrome Browser is deployed at %PROGRAMFILES%, and updates itself very often, and without any user interaction, by using the Microsoft Windows Task Scheduler.

    Thanks, I know about uservoice, though I highly doubt anything ever posted there will make any difference.

    Tuesday, May 3, 2016 1:47 PM
  • Now I can't say I've looked into this all too much but..

    Room81, what about just extracting the contents of the installer & deploying that?

    I did that with Yammer once and worked fine...

    Not sure if it's feasible at all... I just tried extracting it and then running the onedrive.exe.. and worked fine..

    Kindest regards, Martin

    Wednesday, May 25, 2016 9:53 AM
  • Hi Martin,

    thanks for your reply. Sorry, for my late reply, somehow I did not receive a notification about your posting. 

    TBH I did not try to extract the installer file. Even if this works at first glance, I would not see this as a solution, as this won't be an installation method which is official supported by Microsoft.

    * The installer might create some necessary registry settings, e.g. for Word or Outlook integration
    * There won't be any automatic updates applied by Microsoft (Click to run, WSUS, etc) so it is possible that the Application will suddenly stop working if it becomes outdated.
    * We won't have any MS support if there are any negative side effects or future problems with OneDrive

    In short, OneDrive won't be reliable when using this method. Thanks for the suggestion, though.

    Tuesday, June 7, 2016 2:42 PM
  • I just want to comment that I 100% agree with the OP. The recommended approach to prevent crytolocker/ransomware viruses that continue to wreck havok on enterprises, institutions, and consumers is to implement SRP whitelisting. Just ask the NSA...or even Microsoft!

    Security and convenience are almost always in direct contradiction to one another. The 'simpler" you make it for users to install and update software (exe, msi, bat, cmd, etc) the easier you make it for the malicious code.

    I to find it absolutely ludicrous that OneDrive for BUSINESS is being deployed to AppData with no alternative. This is the same reason I don't use WebEx and those other BS meeting software. If a user needs to install something they MUST get Administrative permission or have been given the right to elevate. AppData is nothing more then a way to circumvent this very security measure. Even the default Windows 10 OneDrive app installs to AppData on boot! Absolutely crazy.

    No, you don't need to use AppData to "keep software updated". No other Office program (Excel, Word, Powerpoint, etc) requires such behavior. There are other mechanisms to handle this.

    This really should be redesigned. Opening customers up to more security vulnerabilities is not cool!

    Tuesday, June 14, 2016 3:19 AM
  • Count me as another person who would like this decision changed, if it can be done.

    I've been locking down new computers for friends and family using SRP whitelisting (among other measures), and running into this very issue. In fact, I've been pushing for everyone I know to go with Windows 10 Pro, rather than Home, in part for the ability to implement SRP's.

    OneDrive is very useful--but not if it means opening security holes. Even for personal-use computers, it just doesn't make sense, and it seems to me is a bad practice.

    Thursday, September 1, 2016 2:18 AM
  • I want to add to this thread that Microsofts decision to shape the OneDrive for Business update process using the user permissions is now beginning to backfire, as expected. This is just so ridiculous....

    The OneDrive.exe File in %APPDATA% suddenly needs to changes values in HKLM to "finish installing update". HKLM is only writable by Administrators, so all of our business users are getting an UAC prompt from OneDrive once they login. As they do not have administrative credentials, OneDrive can't change the values and the users keep getting this message every day. 

    The workarrounds for this problem which are told by Microsoft are a joke. (See here and here)

    1. Enter Admin Credentials into UAC - this is not possible in a business environment

    2. Create a GPO Startup Computer Script to run this command on an elevated command prompt: C:\Users\<username>\AppData\Local\Microsoft\OneDrive\OneDrive.exe /permachineupdate

    Problem is: it is not possible to read the ENV Variable %username% on Computer Startup, as there is no logged on user at this time. So this is not a solution. Running this command within a logon script is also not possible, as this would run in the context of user permissions, which still may not write to HLKM. 

    So to circumvent the path dilemma, the official workarround is to update one Machine manually using administrative rights, and then copy the most up-to-date OneDrive.exe to a network share. After that, create a startup script which runs the command from the network share instead of the local computer. This is just ridiculous. 

    a) The update process of OneDrive itself is not within our control. See the post above from Dave Guenthner [MSFT]: the concept is to [...] allow clients to pull frequent updates so they are always up-to-date. This means we as admins do not have any idea WHEN a new version of OneDrive gets deployed, and when we have to update our network share file. 

    b) Even if we would update the onedrive.exe file in our network share like every hour: This would not work for our laptop users which are not attached to the company network. They do not have any access to our network share, and still their OneDrive.exe gets automatically updated from the Interwebz. 

    This whole issue could have been prevented when O4B would install itself like a normal software does, in %ProgramFiles%, and using a Standard Update Mechanism (e.g. Services) to update itself.

    Monday, December 19, 2016 11:58 AM
  • Hi romm8

    I know this an old post. However it's still an issue with OneDrive and Teams also. Did you find a way to allow OneDrive.exe through SRP without allowing the Path?

    Since the exe is updating frequently and the CodeSign Certificate is only valid a few months, Hash and certificate would not work very long. 

    Thank you


    Monday, August 6, 2018 10:22 AM
  • Hi Kaya,

    you are right, unfortunately this IS STILL AN ISSUE, and I am still furious that Microsoft does this kind of shit. 

    But no, we did not find a nice good solution. At the moment we are whitelisting the certificate, as you have suggested. This only works for a few months, so we have to replace it every now and then. Usually a user reports an onedrivesetup.exe error message popup to us, that's how we get notified that the certificate changed. Ridiculous, I know. 

    Going forward, we are in the process of switching to Windows 10. This brings 2 changes for us which might help with the situation, but we did not have the time to look at them:

    • OneDrive is already part of Windows 10, so maybe we can update it using WSUS? Maybe it's installed at a central location? Program Files?
    • We are going to use Applocker instead of SRP. Not sure how Applocker handles certificate whitelists, maybe a bit better, don't know. 

    Feel free to suggest additional ideas, this issue is far from being solved in my opinion.

    • Edited by romm81 Monday, August 6, 2018 10:56 AM
    Monday, August 6, 2018 10:56 AM
  • Hi romm81

    Thank you for the answer. We are planning the rollout to Windows 10. And I accidentally saw the OneDrive.exe entry in Event Viewer Application, while I was checking for Teams. 

    Even when SRP will no longer supported with next Windows Feature Update. We will start the rollout with SRP and later change to AppLocker. In AppLocker we have the option to add a "Publisher" to trusted sources. I don't know yet, if this will also works for classic desktop applications. But will check it the next few weeks. If it's true, what I read, with AppLocker we can not user certificates any more. 

    Monday, August 6, 2018 11:57 AM
  • Hello.

    But AppLocker is only for Windows 10 Enterprise and not for Professional one!

    I'm correct?

    Friday, October 26, 2018 1:00 PM
  • Yes, AppLocker is only available in Windows 10 Enterprise. As of now, most useful business settings are within Enterprise. Professional is almost not usable for companies. 

    To update this thread: Using Applocker is a good workaround to tackle this issue, as we are whitelisting Publishers instead of certificates. Still, installing to APPDATA is a bad practice.

    Friday, October 26, 2018 1:16 PM
  • I agree with every word that has been written so far in this thread.

    In my case it is the program FileSyncConfig.exe that is prevented to run by SRP. I was wondering what would happen if I run that program once with "run as admin". In the UAC prompt I read "Publisher: Unknown". Would that mean that I cannot use AppLocker (which I don't have any experience with) to whitelist that publisher?

    Thursday, November 1, 2018 1:11 PM
  • I just tested this for you: Adding filesyncconfig.exe (Win10, OneDrive v18.151.0729.0012) to Applocker revealed that it has the same Publisher as OneDriveSetup.exe.

    In our environment we are whitelisting the Publisher AND the Product Name (we do not trust every kind of Microsoft Product/Installer), but we put an asterisk in the Filename and Product Version. This whitelists in Applocker every .exe file which is OneDrive related. Works for us.

    See (german) Screenshot below:

    Thursday, November 1, 2018 1:41 PM
  • To give this old post a new spin: Microsoft FINALLY heard our moans and is going to release a OneDrive per-machine client! See here for more information:


    Monday, March 25, 2019 9:40 AM