Work Folders can't encrypt files on Windows 10 1903 RRS feed

  • Question

  • Hi,

    problems with WF encryption was discussed here many times before, but I think that now it's related to Windows 10 1903, because Windows 10 1809 is working fine.

    Error message is still the same:

    Sync failed. Work Folders path: C:\Users\MYUSER\Work Folders; Error: (0x80c80314) The Work Folders path has to be encrypted. You might have an application holding the Work Folders folder open or the folder might be compressed. Close File Explorer and any open files or apps, and check the folder's Advanced properties to ensure that the folder is not compressed. EventID 2100

    I had tried Windows 10 1903 domain joined / not domain joined, followed tips on but WF encryption is still failing.

    Has anyone working WF on Windows 10 1903 with encryption enabled?

    Best regards,


    Wednesday, May 29, 2019 9:53 AM

All replies

  • Hi,

    I found a similar case, please refer to the link below:  

    Meanwhile, you can report the issue to Microsoft through the feedback platform.

    Best regards,


    Please remember to mark the replies as an answers if they help.
    If you have feedback for TechNet Subscriber Support, contact

    Thursday, May 30, 2019 2:37 AM
  • Hi,

    Just checking in to see if the information provided was helpful.

    Please let us know if you would like further assistance.

    Best Regards,


    Please remember to mark the replies as an answers if they help.
    If you have feedback for TechNet Subscriber Support, contact

    Monday, June 3, 2019 9:30 AM
  • Hi,

    I've reported problem through Feedback Hub, I have no solution yet. Thanks.

    Best regards,


    Monday, June 3, 2019 1:33 PM
  • Hi,

    I am sorry that this issue still hasn't been resolved.

    If this issue is urgent, my suggestion is to contact Microsoft Support to get them involved in checking your configuration.

    Best regards,


    Please remember to mark the replies as an answers if they help.
    If you have feedback for TechNet Subscriber Support, contact

    Tuesday, June 4, 2019 6:57 AM
  • Hi Jiri,

    I have similar issue. below is my solution, hopefully, it works for you too.

    The solution for me is turn off UAC, sign out and sign back in then it works.

    After it works, turn UAC on again then sign out and sign back in, it will remain works.

    Monday, June 17, 2019 4:34 PM
  • Hi heroviper,

    turning off or disabling the UAC didn't work for me. Nevertheless thanks for the effort of sharing your solution.

    I've contacted Microsoft Support and I will send update as soon I have working solution.


    Wednesday, June 19, 2019 1:41 PM
  • Hi Jiri, 

    is there something new to it?



    Monday, June 24, 2019 6:05 PM
  • Hi Armin,

    I assume that you are experiencing the same problem with WF on Windows 10 1903, but I don't have any news from MS yet, so I can only summarize my findings:

    I have this problem on two independent domains, they are both using Windows 2012 R2 as WF server.

    Tested with clean W10, non-domain joined (no GPO influence):

    Windows 10 1809 > WF OK, there wasn't any problem before, tested with multiple users / working for all users from both domains

    Windows 10 1903 > WF can't encrypt files, tested with multiple users / same result for both domains

    Windows 10 1809 > Setup WF with single WF user in single Windows account > upgrade to 1903 > WF is working for this single WF user after upgrade, but it's not working for any other WF account or any other/new windows account: WF can't encrypt files

    Windows 10 1809 > Tested WF with two different WF users (from same domain) in single Windows account > upgrade to 1903 > WF is working for all WF accounts (from same domain) in that single Windows account which was upgraded, but it's not working in other/new windows account: WF can't encrypt files


    Tuesday, June 25, 2019 6:03 PM
  • Small update: Today I've installed WF role on WS 2016 and WF client on W10 1903 still can't encrypt files (WF on W10 1903 works fine, when encryption is disabled in WF device policy). So this whole problem shouldn't be related just to WS 2012 R2.
    Wednesday, June 26, 2019 5:06 PM
  • Jiri,

    Below is what I have experienced today.

    1. I was trying to changing my roaming profile and did some change on server and local machine then I found that I stuck at same error again (Due to I delete and recreate the user account)

    2. I tried to disabled UAC and this time it does not work for me.

    3. I took further look and found even I log in as local admin to disabled UAC, whenever I log into domain user account, UAC will be on again....(Thus, whatever work for me before is due to I had set that account as domain administrator user so that I am able to completely disable the UAC)

    4. I removed the user, delete the local profile, remove work folder on the server and recreate it, make sure local workstation is set to UAC off. Then log into the same user again (Domain User Role Only) Now it works again.

    5. Also I found that laptop connect to WIFI might not work right away. If I login as user on desktop to make it sync then I log into laptop it will work right away.

    6. In conclusion, I am guessing it might has something to do with Syncsharestate

    I am going to play around few more days to see if I can find a solid conclusion. - The place for the answer

    Thursday, June 27, 2019 6:36 AM
  • After few more experiments, here are what I found:

    To be able to have it work:

    Domain user needs local admin role to be able to set the UAC to anything below default.

    Then log out of the account, and then log back in.

    Work Folder will start to sync

    After the first sync, you can set the UAC back to default and it will still works.

    Conclusion, after initial sync, does not matter what level of UAC or what role of user. It will work. - The place for the answer

    Thursday, June 27, 2019 8:36 AM
  • Hi heroviper,

    thanks for the summary of your findings, because it's definetly a step ahead for me. But I'm still getting mixed results here. Sometimes it just don't work... and I was trying it under local admin from the begining.

    Just like now, I was trying repeatedly stop/setup WF with UAC set to never notify, then logoff/login and and it wasn't working. I leaved user logged in for a couple of minutes (with message that WF can't encrypt files). After I came back, I have repeated whole process, stop/setup WF, then logoff/login and now it works. Maybe I was too fast this whole time :)

    I will try it on some production machines, this is not the end...


    Thursday, June 27, 2019 12:47 PM
  • HI Jiri,

    Here is some more info.

    Create domain user account A with local admin role

    Make sure there is no existing local profile for A, no roaming profile or work folder on server for A

    Turn off UAC with local admin account.

    Then sign in with expecting it going to work, but it failed.

    I restart few times, still the same.

    Then i perform a group policy update under account A gpupdate /force

    Log out and log back in, and it syncs.

    Now it looks like something to do with group policy was not properly apply.

    Hope this can help you to go further.

    By the way do you using group policy to create work folders for user or your manually connect to it?


    Frank - The place for the answer

    Thursday, June 27, 2019 7:00 PM
  • Hi Jiri,

    After many test, here is what I got.

    Below is my OU and applied group policies

    1st Level (Main OU)

    2nd Level (Computers)

    - Work Folder Setup (GP) - Force automatic setup for all users (User Configuration Disabled)

    2nd Level (Users)

    - Folder Redirection (GP) - Special Folder Redirection (Computer Configuration Disabled)

    - Work Folders (GP) - Specify Work Folders Settings (Computer Configuration Disabled)

    Create a domain user (without local admin right), UAC stay the same. Make sure testing workstation has the latest group policy applied.

    Log in as domain user, wait for around 5 to 10 minutes, then check work folder status. It shows synced.

    It looks like it might need to take some time for group policy to apply and encrypt the folder. 

    As you mention in your post, maybe we are just not patient enough.


    Frank - The place for the answer

    • Proposed as answer by HSChronic Thursday, July 11, 2019 6:27 PM
    • Unproposed as answer by HSChronic Thursday, February 6, 2020 3:25 AM
    Friday, June 28, 2019 6:00 AM
  • Hi Frank, thanks for all tips, I was mostly working with VMs not connected to domain. I will now continue testing on domain joined workstations. I can confirm that when WF can’t encrypt files even for the second try, deleting user profile is what mostly helps. I’m just surprised, that no one else is experiencing this problem. Regards, Jiri
    Friday, June 28, 2019 7:06 AM
  • I'm having the same issue. Frank seems to be hitting on something here though. UAC is enabled, clean build, 1st logon it doesn't work, run gpupdate /force and log off and back on it starts working. 

    Have you tried setting the GPO to loopback? Maybe that will do it. Honestly though it is a bug of some sort and needs to be addressed.

    Thursday, July 11, 2019 6:27 PM
  • Hi HSChronic,

    here are my latest findings:

    1) if WF doesn’t encrypt after setup, simple Logout/Login usually helps

    2) if still WF doesn’t encrypt, second try with Logout/Login mostly helps

    3) but if still WF doesn't encrypt, clean user profile with Logout/Login after WF setup was the surest solution

    At least for me changing UAC is no more required and user doesn't have to be local Administrator.

    I spotted a difference in client behavior when setting up WF:

    with WF server on Windows 2016, UAC dialog is shown

    with WF server on Windows 2012 R2, UAC dialog is never displayed

    Nevertheless Logout/Login after WF setup is needed for both server version.



    Thursday, July 11, 2019 8:22 PM
  • Hi Frank,

    Have you tried with this setting?

    Always wait for the network at computer startup and logon setting enabled.

    Open the appropriate Group Policy object for the computer or computers on which you want to implement the change.

    In the left panel, click to expand the following items:
    Computer Configuration
    Administrative Templates
    Double-click the Always wait for the network at computer startup and logon setting.
    Click Enable, and then click OK.


    Thursday, July 18, 2019 6:52 AM
  • Having the same issue with a new Dell laptop with Windows 10 v1903. Have tried everything that was mentioned so far. Is anyone else still having this issue? Any ideas?  The sync works fine if I disable the encryption requirement on the Work Folders server, but that's not an acceptable solution, due to the client's regulated industry.
    Saturday, August 31, 2019 6:13 PM
  • Hi Andrew,

    I've tried this on several computers with updated W10 1903 and it was working with logout/login after WF setup. Only several times I needed to recreate user profile. 100% working, but not ideal: install 1809, setup WF for user and then upgrade to 1903. WF was always working after OS upgrade.



    Monday, September 2, 2019 10:53 AM
  • There must be something else to it. I've tried the following:

    • Logout/login of the user (many many times)
    • Gpupdate followed by logout/login of the user
    • Reboot of the computer
    • Gpupdate followed by a reboot of the computer
    • Added user to Local Admins group and lowed UAC to lowest level
    • Deleted user profile (along with the user directory from C:\Users) and tried all of the above again

    Today I went as far as removing the computer from the domain, renaming the computer, and then rejoining it to the domain and trying all those same steps above again.

    I'm out of ideas! Only remaining solution I can think of is to send a tech on-site to reinstall Windows 10 using 1809 and then do all the setup BEFORE the 1903 update is applied.

    EDIT (2019-09-05):  I just set UAC back to the default level (2nd from the top), logged out and back in, and now it's working! <insert pulling hair out emoji>

    EDIT (2019-11-02): Just pulled my hair out again. It has something to do with one or more of the following:
    (1) Adding user to Local Admins
    (2) Lowering UAC to the lowest level
    (3) Rebooting and logging out and back in a few times
    (4) Raising UAC back to the default level (2nd from the top)
    (5) Rebooting and logging out and back in a few times

    I'll do another edit next time I run into this if I can narrow it down further.

    EDIT (2020-02-04): I'm pretty sure it has something to do with lowering UAC and then raising it back and then trying the sync (no reboot needed!).
    Thursday, September 5, 2019 12:33 AM
  • Has anyone made any progress on this? We have a large scale deployment and messing with UAC isn't really an option. Anything that has come with 1903 out of the box seems to be the biggest impact for us with machine refreshes.

    We're seriously considering just biting the bullet and migrating to OneDrive with Known Folder Redirection since the response has been pretty poor from the support side.

    • Edited by zchoate Tuesday, October 22, 2019 2:41 PM grammar
    Tuesday, October 22, 2019 2:41 PM

    Is anyone ever going to fix this one???

    I have hundreds of customers using Work Folders (under Windows Server 2012 R2, 2016, and 2019) and they can't use it with the native Work Folders client under Windows 10 1903 or 1909. It's been months and months now and there's still no fix in sight from you guys on this one (and not even an official response).

    I realize that you just don't care about your small business customers anymore, but it'd be really nice if you could drop us some crumbs and fix this one ASAP. Oy!

    EDIT: P.S. It'd also be really, really, nice if you could have someone fix the Get-SyncUserStatus Work Folders PowerShell cmdlet seeing as it's hopelessly broken under Windows Server 2019 as it never returns any user status information at all! SEE:

    Work Folders (Windows Server 2019) - Devices are not showing up under the User View neither Powershell

    • Edited by TheOfficeMaven Thursday, January 23, 2020 4:14 PM Added link to Get-SyncUserStatus documentation.
    • Proposed as answer by TPI Inc Tuesday, January 28, 2020 5:48 PM
    • Unproposed as answer by TPI Inc Tuesday, January 28, 2020 5:48 PM
    • Proposed as answer by TPI Inc Tuesday, January 28, 2020 5:48 PM
    • Unproposed as answer by TPI Inc Tuesday, January 28, 2020 5:48 PM
    Monday, January 20, 2020 10:43 PM
  • BUMP!
    Wednesday, January 22, 2020 3:39 PM

    This is beyond unacceptable. my clients are not able to sync as new people come on board. Windows 10 has devolved in such a ridiculous manner, it's mind blowing.

    Thursday, January 23, 2020 2:27 AM
  • And here's another completely ludicrous BUG that's related to using Work Folders under Windows Server 2019... If you happen to install the File Server Resource Manager server role on Windows Server 2019, in order for you to be able to create quotas or file screens on your Work Folders sync shares (etc.), then you (quite laughably) can't use the Group Policy Manager applet to edit your server's Group Policies any longer:

    FSRM Breaks Group Policy editing on Windows Server 2019 Domain Controllers

    Microsoft, this is completely unacceptable... It's so sad, that all I can do is laugh to keep myself from crying at this point. Your Windows Server team has become a complete and utter joke. Ugh!


    Thursday, January 23, 2020 4:09 PM
  • I think i figured it out.  Since it's similar to offline files which uses CSC, i took a look at the CSC folder in Windows.

    I took RECURSIVE ownership as a domain admin on the CSC folder under C:\windows. Then for the heck of it, I put the user of the system as full control, recursive for the c:\windows\csc folder. So CSC folder and all subfolders/files, full control for that specific user having issues. 

    Then logged out and back in again, and sync is now working successfully.

    One thing, made them domain admins temporarily, but that did not work, so i don't think making them domain admins did anything as the CSC folder is so locked down, nothing has access to it.

    Disclaimer here: Do not make a user Domain Admin to get this to work. I am just letting you know how I'm testing this, play by play.

    Finally, i mounted an older Win10, 1809 image, looked in the c:\windows folder and there is no CSC folder. So basically, this folder must get created on the fly, maybe when you enable Work Folders, but does not get permissioned properly hence the user or system cannot do whatever it needs to do there.

    Try this out, and let me know if you're successful.

    • Proposed as answer by TPI Inc Tuesday, January 28, 2020 5:53 PM
    Tuesday, January 28, 2020 5:53 PM
  • Alas, changing permissions on the CSC (client-side caching) folder doesn't work for me. Nice attempt though.


    Wednesday, January 29, 2020 1:02 AM
  • BUMP!
    Saturday, February 1, 2020 5:54 PM