Work Folders on a File Server Cluster

Author by Shannon Fritz

By now you might have heard about Work Folders, a new File Sync engine that is built into the Windows Server 2012 R2 File Server role.  It allows you to synchronize files located on a File Server to computers and devices using HTTPS rather than SMB.  This makes it very Internet friendly, as well as easy to deploy. When compared to the myriad of other sync solutions available (including many from Microsoft!), there are some benefits to Work Folders ranging from simplicity of Infrastructure (it’s just a file server, not SharePoint) to the location the data resides in (your own datacenter, not the public cloud). image Most of the guides you’ll find today show you how to put Work Folders on a single file server, and this work great.  After all, Work Folders is a Sync Engine, so if the file server goes offline, the end users will already have their content cached offline, but what if you want a little more resiliency on the back end?  Or what if you are already using a File Server Cluster to provide storage for user content and you want to leverage that infrastructure for Work Folders as well? In this guide, I’ll show you how you can configure Work Folders on an existing Failover Cluster with a File Server role. Note: This is not a Virtual Machine with a File Share running in a Hyper-V Cluster here.  While that works great, this “File Server Role” is a very different thing from a VM.  Where a VM is a Role of a Failover Closter, this File Server is also a Role of the cluster, but it’s not another instance of Windows running, it’s just a namespace that gives access to the Shared Storage of the cluster.  This is also not a Scale-Out File Server (SOFS) Cluster which is meant for server workloads like Hyper-V and SQL. Assuming you’ve already made clustered file server for "General Use", you should already have a disk and be ready to configure Work Folders in the cluster. image Just create a new folder on the cluster disk to use with Work Folders. image

On each node in the cluster, install the “Work Folders” role.


In Server Manager, Work Folders will now appear under the From the Tasks menu, create a new Sync Share.


Browse to select the folder you created earlier.

TIP: You can create sub-folders to make separate workfolder repositories for each department, team, location or whatever makes sense for you.  In this example, I’m just putting everyone in the same place.


The wizard has a very interesting Tip here for using Subfolders.  Let’s say you are already doing Redirected Folders and you have the users Desktop, Pictures, Favorites and Documents on an existing file share.  The root of that redirected folder share typically already has a set of folders named after the user alias, then inside there are the folders with the actual “Desktop” and “Documents” contents.  What this wizard will let you do is set up their existing “My Documents” folder to be made available as the Work Folder!  This could grant the user access to their Documents on computers outside the domain and not change the way they use their files in “My Documents” today.  Pretty clever!  That is, if you’re already using a 2012 R2 file server…


If you plan on creating multiple Sync Shares for different sets of users, then you should set a unique name.


Use a more specific group if you wanted to create different Sync Shares for different groups of users.


Devices that are capable of using Work Folders can be made to follow a couple basic security measure.  By default, locking and requiring a password is selected.


Review the summary page to confirm your selections, then click Create.


By default, Work Folders will sync at least once every 5mins.  You can change this value, but it has performance affects and you should probably leave it alone. 


Set-SyncServerSetting -MinimumChangeDetectionMins 1

Since I am demonstrating in a lab, I’ll set it to the lowest possible value of 1min so I can see changes happen as quickly as possible.  Again, you should not do this in production, this is just for demo.



When I first tested out Work Folders, I discovered I was unable to use a Wildcard certificate because it seems the wizard checks to make sure the “Common Name” of the certificate would match the FQDN of the URL that your users will connect to Work Folders.  By default, clients will expect to use “workfolders.[]”.  You can use something different, but then you must have 2012 or 2012 R2 Active Directory schema in order to set the msDS-SyncServerUrl attribute.  So let’s just assume you want to use the default DNS name of

However, after deploying Work Folders, I was able to replace the named SSL certificate with a wildcard, and it works fine.  So, can you use a wildcard certificate with Work Folders?  Yes, you can!  I am told that the wizard does work with a Wildcard, but in the screen shots below and through the rest of this article, I am using a named certificate.

In my example, the domain name is, so the Common Name and the DNS Alternative Name are set to "”.  And additional subject alternative name was also added to list the internal DNS names of the file server that is hosting the Sync Shared for Work Folders role (in my example that is the name of my file server cluster role which is “”).  Be sure to import this certificate, with the Private Key, to the Work Folder server(s) and on the Reverse Proxy that will be listening on the external address.


Once the certificate is imported, open the Details to copy the Thumbprint.


Use an Elevated CMD (it fails in PowerShell) to bind that certificate to the “IIS Hostable Web Core” on the Work Folder server(s).

netsh http add sslcert ipport=:443 certhash= appid={CE66697B-3AA0-49D1-BDBD-A25C8359FD5D} certstorename=MY

You can use the “show” command to see what certificate is in use.  netsh http show sslcert”. If you selected the wrong certificate then you have to remove it using the delete command, and then add a new one. For example… “netsh http delete sslcert ipport=:443


Create DNS records

If you do not create DNS records then end users will need to know the URI to access your Work Folders servers.  This might be useful if you have some separate Sync Server hosts, but you can make people’s lives a lot easier by creating a couple DNS records.  You get to pick whatever you want, but ideally, you should use the same FQDN both inside and outside of your corpnet.  I’ll use “”.


Internal DNS: Create an A record or CNAME that resolves to the file server running the Work Folders role (in my case, that’s the cluster role).

External DNS: Create an A record that resolves to the Reverse Proxy or NAT device on your corpnet edge.

Reverse Proxy

On the Reverse Proxy or NAT device, create the rule that will forward 443/TCP to the internal Work Folders server, and be sure to import the Work Folders SSL certificate with the Private Key.


In my example, I will be use the new Web Application Proxy to publish the “workfolders” URL using Pass-Through Authentication, and I’ve selected my named certificate.



Clients will assume the “workfolders.[domainname].com” DNS record will point them to the actual Work folder server, but you can use a Group Policy to define a different URI to use.  You can also set up computers to automatically configure the use of Work Folders so they just appear whenever a user logs in.  This is really only useful for Domain Joined machines, however if you manage non-domain joined machines with Intune you can actually configure Work Folders there too.


Client Setup

Users can type “Work Folders” on the Start screen to open the Control Panel and set up Work Folders.


Note: Clients for non-windows devices (like iOS iPhone and iPads) are coming, but at the time of this writing only Windows 8.1 and Windows RT 8.1 support Work Folders.


Users need only to enter their email address and the client will use the domain name after the @ to look up workfolders.[].  If you are not using that DNS name, then users will need to know it and enter it manually by clicking the link on this screen.

Non-domain joined machines will prompt the user to log in next.  If that’s the case, then you probably want to check the box to Remember your password.  Domain machines will do single sign-on.


Users can specify a different location to save the Sync’d files on their device.


This message informs users that their administrators may decide to enforce some of these security policies or change the settings at any time.  It doesn’t say which ones are actually in effect, but they have to accept the possibility that they may be enabled at some point before they can sync.


If you specified an existing folder then the contents of that folder will be uploaded to the Sync Share.


Some basic information about the sync status and free space on the server.


Now you can start dropping files in there and they’ll get sync’d back to your server.


From the server you can see what devices a user has syncing with their Work Folder.


Admins can Suspend a user, but this only prevents them from Syncing more changes, it does not remove the files from the devices.


You can easily stop syncing a Work Folder.  This will remove the “Work Folders” library from Explorer but it will NOT delete the files from your local disk and it will NOT delete the files from the Work Folders server.


You will need to delete the files from disk if you don’t want them anymore.


So what can go wrong?

image image

These two are pretty self-explanatory.  Enter the right username and password to fix the first one, and use a certificate on the Work Folders server that is issued by a CA that the client PC trusts.


This might come up if you are trying to use a Wildcard certificate or if you didn’t include the actual DNS name of your Sync Server as a Subject Alternative name in the certificate.  Remember, the Common Name and first DNS Alternate Name should be “”, then add on the internal DNS name of the actual server that is hosting the Work Folders role.


This happens on a fresh install of Windows 8.1 / 2012 R2 that has NO UPDATES installed, so it should be pretty uncommon.  Installing the first published Update Rollup (KB2883200) fixes it.



What happens when conflicting changes happen?  I did some lite testing to discover what happens when file conflicts occur.  These are my observations...

Create two different files with the same name from two different devices? The file with the more recent LastWriteTime “wins” the name.  This is usually the file that was saved last.  The other file will have the source device name appended to the filename.

Change an existing file from more than one device at the same time?  The file with the more recent LastWriteTime “wins” the name.  This is usually the file that was saved last.  The other file will be created with a name that has the source device name appended to it.

Change an existing file on one computer but delete it from another?  The deleted file will be replaced with the changed one.

Configure Work Folders on a second device to use a local folder that already has files?  The new files will be copied to the work folder and then down to all other devices.

Overall, I think Work Folders makes some pretty predictable and safe decisions when it comes to conflicts.  Instead of trying to merge changes or just abandon files, it just keeps copies and then lets you, the human, figure it out.

What’s next?

At this point, most people are starting to wonder about the governance of the content that is being synchronized to user’s devices and how they can control that data.  How do you wipe the files?  In short: You don’t.  It is possible to delete the content from the Sync Share on the server, and then once the client synchronize with it the content will be deleted locally, but of course, that requires the client to actually check in.  If they have stopped using Work Folders, then the content on that device is simply out of your control.

If you don’t like that, then you should be using Rights Management Services or Azure RMS to protect the files no matter where they end up.  Keep in mind you also face this concern when users decide on their own to use any of the other public cloud storage solutions or if they just copy things to thumb drives or email them around!

You can also employ Dynamic Access Control to automatically protect files in the Sync Share with RMS as well as provide a mechanism to begin leveraging Claims based access.

I am a fan of Work Folders and I think it is a very useful role for you to be able to leverage a simple File Server to allow your users to access their content without using a “public” cloud storage provider nor needing to deploy something more complex like SharePoint.

Microsoft is considering many opportunities to enhance this role to make it even better.  For example:

  • A Web UI to access Work Folders from a browser (think or now I guess)
  • Shared Work Folders (team folders, or access from federated identities)
  • Client access to multiple work folders (sync from more than one organization)
  • Native apps on devices (iOS, Android, Windows Phone, Xbox One?)
  • Selective Sync (only pull copies of files when they are accessed by the user)

Some of these are rumors or just speculation on my part, but it think we’ll be seeing a lot yet to come in this space!


VIDEO: TechEd 2013 WCA-B214 Work Folders Overview

VIDEO: TechEd 2012 WCA-B332 Work Folders Deep Dive

Shannon Fritz

Infrastructure Architect & Server Team Lead