Work Folders allow you to maintain control of corporate data by storing it on server file shares while making it available consistently across a user’s multiple devices, including when the user’s device is disconnected from the network. Users want to get at the data—which they consider “theirs”—whenever and where ever they want to work. They often want to work with a local copy, but you need to maintain control of the data, even while making it available. (I’m sensing a recurring theme here.)
Have you ever had users email documents to themselves? Have you ever filled a USB flash drive port with epoxy or created a firewall rule to block consumer-based storage platforms (such as Box.com, Dropbox, or Microsoft OneDrive)? With Work Folders, you can stop fighting with users and allow appropriate, secured, protected synchronization of files.
Users can sync their work data to their devices, but files can still be classified, so that protection can be applied to sensitive data. Another quite important thing is that a copy of the information is always kept within the corporate realm, available and backed up.
For general information about Work Folders, visit Work Folders Overview.
In our next and final post on this topic, I’ll look at how you can totally protect your corporate data by removing it from a device if that device is lost, stolen, or taken home when someone leaves the company. But first, let’s look at how to set up Work Folders, and then sync and classify some data.
To set up Work Folders, first take care of the basics: Have a domain controller (or better, two!), with proper connectivity such as Domain Name System and Dynamic Host Configuration Protocol servers.
You implement Work Folders on file servers, where you set up sync shares. You configure one share per user, and you can enforce a quota. So, set up a Windows Server 2012 R2 computer as the file server. There, add the Work Folders Role service, found under the File and iSCSI Services node of the File and Storage Services role.
With the role service installed, a new menu item is created in Server Manager. Launch the New Sync Share Wizard.
You can then publish Work Folders directly through a reverse proxy or enforce conditional access by using Active Directory Federation Services, which, in turn, can use device registration information. The wizard will ask you for an existing share or a path for a new Sync Share.
Work Folders are designed so that each user assigned to the Sync Share has a personal folder within that share (with NTFS permissions protecting it, of course). This is similar to the “home folder” idea, and many organizations use the same structure. Users can access the Sync Share over Server Message Block (SMB) or Network File Share, as well.
As you work through the wizard, most of the options are fairly self-explanatory. A few might warrant some additional details, however.
On the Sync Access page, for example, you’re asked to specify the groups that you will allow to access this Sync Share. You can also specify individual users, but that would be silly. This setting controls who can use Work Folders hosted on this share on this server.
You are also asked to define the device policies. You can require that the files synced to a device must be stored in an encrypted format or that the device must have an auto-lock with a password. Work Folders use a different encryption key than any other encryption used on the device, which makes it much easier to wipe only the Work Folders, if needed.
Now, turn your attention to a Windows 8.1 client and complete the client-side setup. Here are the simplified steps:
There you have it: You can now access, change, and create folders on any of the devices that you’ve configured and optionally through the SMB share, as well. As you work online, you will see changes reflected quickly across all devices.
For a complete step-by-step guide to setting up and testing Work Folders see the Storage Team Blog entry Work Folders Test Lab Deployment, or the documentation page Deploying Work Folders.
Note that Windows 7 clients can participate with an optional download, as explained in Work Folders for Windows 7. Support for other devices is planned but has not yet been announced.
For extra credit, explore what happens when you configure Automatic File Classification on the file server. Perhaps you have a File Classification rule that all Microsoft Excel spreadsheets must have a Rights Management template applied (using Active Directory Rights Management Services [RMS]).
If a user creates a new Excel spreadsheet while working offline, as soon as the client is reconnected and the folders synchronized, the file classification goes into effect, applying the RMS template.
AD RMS is an important part of an information protection strategy; and now, it is complemented with Azure RMS. Traditionally, access to a computer file is governed by a discretionary access control list (DACL) that contains entries specifying who can have what types of access to the file. In Windows, DACLs are part of the file system and enforced by the operating system. However, once an authorized user is granted access to read or copy a file, nothing prevents that user from keeping a copy, and then redistributing it to others, whether those other people are authorized or not. RMS helps secure you against such risks.
AD RMS protects a file by storing it in an encrypted format. Instead of a simple DACL, permissions are enforced using encryption keys, policies, and licenses. This means that the owner of the document can set rules about how the document can be used, whether it can be printed or redistributed, or even have it expire after a set period of time.
Administrators can design templates (e.g., “internal use only” or “do not forward, do not print”) for documents, and the Windows Server 2012 File Classification Infrastructure (FCI) can be used to automatically apply templates based on the location, type or content of the file.
For more information about AD RMS, see Active Directory Rights Management Services on TechNet, or the implementation details in AD RMS Overview on MSDN. An example scenario of FCI is featured in Scenario: Get Insight into Your Data by Using Classification.
Azure RMS takes the RMS even further. Azure RMS is a cloud-based service that uses Azure AD as an identity store. Azure RMS offers additional flexibility to on-premises AD RMS, including support for not only Microsoft Office and Office 365 but also native viewers on Windows, Windows RT, Windows Phone, iOS, Android, and Macs.
Azure RMS supports the protection of many file types, including PDF and XML files, or entire ZIP files that can contain anything. Support remains for Office Documents, e-mail, and SharePoint libraries. And, protection can be extended to users outside of your own organization much more easily than with AD RMS. As with AD RMS, administrators can use templates and policies to protect documents. In fact, individuals outside of a corporate organization can even create a free individual RMS account, allowing your organization to securely share and manage documents with even the smallest of contractors or partners.
Get more information about Azure RMS at Azure Rights Management on TechNet.
NEXT BLOG POST IN THIS SERIES: Removing corporate data from devices
Catch-up with the previous entries in this blog series:
Part one: Setting up the environment
Part two: Making resources available to users
Part three: Registering BYOD devices
Learn more about Access and Information Protection here.
Comments in this blog are open and monitored for each post for a period of two weeks after the posting date. If you have a specific question about a blog post that is older than two weeks, please submit your question via our Twitter handle @MSCloud