OneDrive component FileCoAuth.exe not compatible with Software Restriction Policies

%3CLINGO-SUB%20id%3D%22lingo-sub-382963%22%20slang%3D%22en-US%22%3EOneDrive%20component%20FileCoAuth.exe%20not%20compatible%20with%20Software%20Restriction%20Policies%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-382963%22%20slang%3D%22en-US%22%3E%3CP%3EOur%20organization%20is%20new%20to%20OneDrive%20and%20Sharepoint%2C%20having%20for%20years%20used%20an%20on%20premises%20file%20server%20for%20all%20our%20collaboration%20and%20storage.%20Over%20a%20period%20of%203%20weeks%20we%20migrated%20all%20our%20separate%20shares%20to%20sharepoint%20sites%2C%20and%20experienced%20the%20following%202%20main%20difficulties%3A%201)%20our%20large%20store%20of%20photos%20in%20the%20communications%20site%20refused%20to%20consistently%20display%20thumbnail%20icons%20or%20previews.%202)%20users%20who%20opened%20the%20same%20files%20were%20not%20warned%20of%20the%20fact%20that%20the%20first%20one%20was%20editing%20and%20were%20forced%20to%20fork%20their%20changes%20into%20a%20different%20file%20if%20they%20were%20lucky%2C%20otherwise%20Onedrive%20would%20simply%20give%20them%20a%20synchronization%20error.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EWe%20were%20researching%20a%20different%20issue%20when%20we%20stumbled%20on%20the%20reason%20in%20the%20event%20viewer.%20%26nbsp%3B%20%22Access%20to%20C%3A%5CUsers%5Cxxuserxx%5CAppData%5CLocal%5CMicrosoft%5COneDrive%5C19.012.0121.0011%5CFileCoAuth.exe%20has%20been%20restricted%20by%20your%20Administrator%20by%20the%20default%20software%20restriction%20policy%20level.%22%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EOK%2C%20We%20have%20SRP%20in%20place%20and%20it's%20saved%20our%20bacon%20numerous%20times%2C%20but%20in%20the%20case%20of%20a%20misbehaved%20program%20(OneDrive%20in%20this%20case)%20we%20can%20add%20exception%20rules%20to%20allow%20it%20to%20launch%20out%20of%20the%20users%20profile.%20We've%20done%20it%20dozens%20of%20time%20and%20it%20works.%20(although%20I%20can't%20for%20the%20life%20of%20me%20understand%20why%20developers%20persist%20in%20behaving%20just%20like%20viruses%20and%20executing%20programs%20this%20way%2C%20shame!)%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EWell%20we%20added%20a%20special%20rule%20and%2C%20no%20difference.%20The%20above%20error%20message%20littered%20our%20event%20logs%2C%20and%20we%20noticed%20it%20was%20there%20seven%20or%20eight%20times%20every%20time%20office%20would%20open%20a%20file.%20We%20tried%20all%20sorts%20of%20angles%20on%20exception%20rule%20creation%20and%20no%20difference.%20(we%20did%20try%20turning%20off%20SRP%20and%20no%20error%20was%20produced%20--%20not%20really%20an%20option%20for%20prime%20time%20though)%20Finally%20we%20tried%20executing%20FileCoAuth.exe%20from%20the%20run%20dialog.%20No%20error%20reported%20and%20windows%20allowed%20us%20to%20do%20it.%20We%20also%20noticed%20that%20once%20it%20was%20successfully%20run%2C%20both%20of%20the%20problems%20I%20listed%20at%20the%20beginng%20simply%20disappeared.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3ESo%20then%20the%20thing%20was%20to%20put%20a%20workaround%20in%20place.%20We%20tried%20a%20login%20script%20to%20run%20the%20program%20but%20that%20produces%20the%20same%20error.%20In%20end%20we've%20settled%20on%20a%20powershell%20script%20invoked%20from%20the%20startup%20folder%20that%20waits%20for%20the%20presence%20of%20OneDrive%20and%20then%20runs%20FileCoAuth.exe.%20This%20works.%20But%20this%20is%20a%20bug%20someone%20should%20look%20at.%20SRP%2C%20also%20called%20Application%20Whitelisting%2C%20is%20an%20important%20defence%20measure.%20And%20Microsoft%20should%20make%20sure%20their%20corporate%20products%20are%20compatible%20with%20it.%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-LABS%20id%3D%22lingo-labs-382963%22%20slang%3D%22en-US%22%3E%3CLINGO-LABEL%3EOffice%20365%3C%2FLINGO-LABEL%3E%3CLINGO-LABEL%3EOneDrive%20for%20Business%3C%2FLINGO-LABEL%3E%3CLINGO-LABEL%3EStorage%3C%2FLINGO-LABEL%3E%3CLINGO-LABEL%3ESync%3C%2FLINGO-LABEL%3E%3C%2FLINGO-LABS%3E%3CLINGO-SUB%20id%3D%22lingo-sub-388183%22%20slang%3D%22en-US%22%3ERE%3A%20OneDrive%20component%20FileCoAuth.exe%20not%20compatible%20with%20Software%20Restriction%20Policies%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-388183%22%20slang%3D%22en-US%22%3EUpdate%3A%20OneDriveSetup.exe%20can%20now%20be%20run%20with%20an%20'%2Fallusers'%20switch%2C%20which%20installs%20it%20globally%20in%20%25PROGRAMFILES(X86)%25%20directory.%20FileCoAuth.exe%20runs%20fine.%20This%20was%20the%20right%20fix.%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-1010684%22%20slang%3D%22en-US%22%3ERE%3A%20OneDrive%20component%20FileCoAuth.exe%20not%20compatible%20with%20Software%20Restriction%20Policies%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-1010684%22%20slang%3D%22en-US%22%3EIt%20is%20important%20to%20say%3A%20new%20OneDriveSetup%20install%20should%20be%20version%20%26gt%3B%3D%2019.174.902.13%3CBR%20%2F%3EOtherwise%20it%20will%20not%20install%20per%20machine%3C%2FLINGO-BODY%3E
New Contributor

Our organization is new to OneDrive and Sharepoint, having for years used an on premises file server for all our collaboration and storage. Over a period of 3 weeks we migrated all our separate shares to sharepoint sites, and experienced the following 2 main difficulties: 1) our large store of photos in the communications site refused to consistently display thumbnail icons or previews. 2) users who opened the same files were not warned of the fact that the first one was editing and were forced to fork their changes into a different file if they were lucky, otherwise Onedrive would simply give them a synchronization error.

 

We were researching a different issue when we stumbled on the reason in the event viewer.   "Access to C:\Users\xxuserxx\AppData\Local\Microsoft\OneDrive\19.012.0121.0011\FileCoAuth.exe has been restricted by your Administrator by the default software restriction policy level."

 

OK, We have SRP in place and it's saved our bacon numerous times, but in the case of a misbehaved program (OneDrive in this case) we can add exception rules to allow it to launch out of the users profile. We've done it dozens of time and it works. (although I can't for the life of me understand why developers persist in behaving just like viruses and executing programs this way, shame!)

 

Well we added a special rule and, no difference. The above error message littered our event logs, and we noticed it was there seven or eight times every time office would open a file. We tried all sorts of angles on exception rule creation and no difference. (we did try turning off SRP and no error was produced -- not really an option for prime time though) Finally we tried executing FileCoAuth.exe from the run dialog. No error reported and windows allowed us to do it. We also noticed that once it was successfully run, both of the problems I listed at the beginng simply disappeared.

 

So then the thing was to put a workaround in place. We tried a login script to run the program but that produces the same error. In end we've settled on a powershell script invoked from the startup folder that waits for the presence of OneDrive and then runs FileCoAuth.exe. This works. But this is a bug someone should look at. SRP, also called Application Whitelisting, is an important defence measure. And Microsoft should make sure their corporate products are compatible with it.

2 Replies
Update: OneDriveSetup.exe can now be run with an '/allusers' switch, which installs it globally in %PROGRAMFILES(X86)% directory. FileCoAuth.exe runs fine. This was the right fix.
It is important to say: new OneDriveSetup install should be version >= 19.174.902.13
Otherwise it will not install per machine