A couple of weeks ago, I delivered a presentation on Work Folders deployments, and there was a slide on how Work Folders interoperates with other file server technologies. It occurred to me that it is worth writing a blog post about it.
File classification infrastructure (FCI)
File Classification Infrastructure was released in Windows Server 2008 R2 as part of File Server Resource Manager (FSRM). It enables organizations to classify their files (assign properties to files) and then use Windows mechanisms as well as partner solutions to apply actions based on the file classification. The classification runs on the server. When a file is created/modified on the device and syncs to the server, the classification engine detects the new file or file change, and classifies the file according to the rules. This allows the admin to continue managing the files when they are accessed through Work Folders.
RMS encryption
RMS encryption is typically deployed with FCI on file servers to protect sensitive data. Files are classified according to the classification rules and based on the classification result, and gets RMS encrypted if the file meets the appropriate policy. The encryption is considered a server change, so when the Work Folders client polls for changes, the encrypted file is downloaded to the clients.
The end user doesn’t need to do anything special to encrypt the data - RMS gives the admin the control to secure the data. The next time the user opens the file, they will notice the file is now RMS protected. To open this RMS protected file, the user might have to provide credentials if the device isn’t connected to the corporate network.
Quotas and File screen
Similarly, administrators can configure quotas and file screens for the Work Folders sync shares, which are enforced on the server. For example, if the user puts a file in Work Folders that isn’t allowed on the server, the file fails to upload due to the file screen policy. The user sees a file upload error in the Work Folders Control Panel due to file screen policy on the server. Similarly, if the user exceeds the quota on the server, additional uploads fail until they reduce the size of their Work Folders to below the quota limit. Users see the allowed quota size in the Work Folders Control Panel app on Windows.
DFS Replication
DFS Replication (DFSR) is commonly used on file servers to replicate files to different servers/locations. When planning for Work Folders data replication, it is important to know
- The data to be replicated
- The replication direction.
There are 3 types of data on the file server associated with Work Folders:
- The actual user data, which can be replicated for backup purposes (Note that user should sync with only a single Work Folders server)
- The Work Folders sync database, which tracks the file versions for sync purposes. The database path is located on the same volume as the sync share, under VolumeDrive:\SyncShareState\<SyncShareName>\Metadata
- Staging folder, which is under VolumeDrive:\SyncShareState\.
The database tracks the file version on the server, and it is used for comparisons when the client device checks with the server. The database is tied to a dataset on that server, and should not be copied to other servers. In the case where the primary file server is down, and the admin wants to enable sync using the replica server, they can do so by re-creating the matching sync shares. The sync service on the new server will create a new database for the given dataset.
The staging folder serves as a temporary location for uploaded files. The files are uploaded to the staging folder first, and once a file completes the upload, it will be moved to the actual user folder on the server. This folder doesn’t need to be replicated.
In short, the SyncShareState folder should NOT be replicated.
As for replication direction, we only support the one-way replication (read-only replication) from the sync server to other DFS-R servers. Because we can't track file changes through replication outside of the sync engine very well, so we want to avoid running into the bad situations.
Failover Clustering
You can set up Work Folders on a traditional failover cluster. There is no difference from the user experience perspective, though there are a few differences in how you administer the server. For more information, see this clustering managementblog post.
SMB
I think of SMB and Work Folders as two different access protocols to a dataset on the file server. They are almost orthogonal to each other. I say “almost”, because there is an interoperability aspect between the two.
File changes through Work Folders are tracked by a sync service, so all changes that originate on a client device are known to Work Folders. However, if the file changes by other means – for example, by access through SMB, Work Folders doesn’t intrinsically recognize the change. To catch these changes, we have a process to enumerate the files periodically to detect changes.
File enumeration does have a performance impact on the server. By default, enumeration takes place every 5 minutes. This means that when the client asks the server for changes, if the server sees that the user’s files haven’t gone through enumeration in the last 5 minutes, it starts the file enumeration process on that user’s dataset. The enumeration setting can be changed using the following cmdlet:
“Set-SyncServerSetting–MinimumChangeDetectionMins”.
The setting impacts on how quickly changes made outside of Work Folders get synced to all the client devices. So the admin needs to evaluate the tradeoff and set it appropriately.
Note1: Changes made outside of Work Folders can be made by users or by applications. For example, RMS encryption is considered outside of Work Folders, and so these changes get picked up during the server side change detection process.
Note2: SMB is just one protocol example of allowing for remote access, NFS and WebDAV behave similarly with Work Folders.
Dynamic Access Control (DAC)
There are a couple of areas relate to DAC interoperability with Work Folders: discovery and data access.
Discovery happens during the device setup of Work Folders. The client will query the server for sync locations on the server. On the server, each sync share is associated with one or more security groups - the server uses the user security group membership to find the correct sync share for a given user. During discovery, it will not use DAC.
Once the Work Folders configured on a device, it goes to the ongoing sync phase. For each sync session, after the user authenticates with the server, the server access the data in that user’s context, and all the NTFS file/folder permission are honored, including DAC.
Looking at this from a different angle, DAC is more relevant for team sharing, whereas Work Folders is targeted to individual user’s folder (e.g. home folders), so I don’t see the two features likely to operate on the same dataset.
Ending notes
The areas I covered above are the ones I chose to highlight and by no means to constitute the full list of interoperability for Work Folders, think of it as a starting point. Feel free to comment about other areas that you are interested in the comments.