Designing a Work Folders Implementation

Applies To: Windows 10, Windows 7, Windows 8.1, Windows Server 2012 R2

This topic explains the design process for a Work Folders implementation, and assumes that you have the following background:

• Have a basic understanding of Work Folders (as described in Work Folders Overview)

• Have a basic understanding of Active Directory Domain Services (AD DS) concepts

• Have a basic understanding of Windows file sharing and related technologies

• Have a basic understanding of SSL certificate usage

• Have a basic understanding of enabling web access to internal resources via a web reverse proxy

The following sections will help you design your Work Folders implementation. Deploying Work Folders is discussed in the next topic, Deploying Work Folders.

Software requirements

Work Folders has the following software requirements for file servers and your network infrastructure:

• A server running Windows Server 2012 R2 for hosting sync shares with user files

• A volume formatted with the NTFS file system for storing user files

• To enforce password policies on Windows 7 PCs, you must use Group Policy password policies. You also have to exclude the Windows 7 PCs from Work Folders password policies (if you use them).

To enable users to sync across the Internet, there are additional requirements:

• A server certificate for each file server that will host Work Folders (plus a server certificate for your reverse proxy server). These certificates should be from a certification authority (CA) that is trusted by your users—ideally a public CA

• The ability to make a server accessible from the Internet by creating publishing rules in your organization’s reverse proxy or network gateway

• A publicly registered domain name and the ability to create additional public DNS records for the domain

• (Optional) An Active Directory Domain Services forest with schema extensions in Windows Server 2012 R2 to support automatically referring PCs and devices to the correct file server when using multiple file servers

• (Optional) Active Directory Federation Services (AD FS) infrastructure when using AD FS authentication

Work Folders has the following software requirements for client computers:

• Computers must be running one of the following operating systems:

  • Windows 10

  • Windows 8.1

  • Windows RT 8.1

  • Windows 7

  • Android 4.4 KitKat and later

  • iOS 8 and later

• Windows 7 PCs must be running one of the following editions of Windows:

  • Windows 7 Professional

  • Windows 7 Ultimate

  • Windows 7 Enterprise

• Windows 7 PCs must be joined to your organization’s domain (they can’t be joined to a workgroup).

• Enough free space on a local, NTFS-formatted drive to store all the user’s files in Work Folders, plus an additional 6 GB of free space if Work Folders is located on the system drive, as it is by default. Work Folders uses the following location by default: %USERPROFILE%\Work Folders

  However, users can change the location during setup (microSD cards and USB drives formatted with the NTFS file system are supported locations, though sync will stop if the drives are removed).

  The maximum size for individual files is 10 GB by default. There is no per-user storage limit, although administrators can use the quotas functionality of File Server Resource Manager to implement quotas.

• Work Folders doesn’t support rolling back the virtual machine state of client virtual machines. Instead perform backup and restore operations from inside the client virtual machine by using System Image Backup or another backup app.

Deployment scenarios

Work Folders can be implemented on any number of file servers within a customer environment. This allows Work Folders implementations to scale based on customer needs and can result in highly individualized deployments. However, most deployments will fall into one of the following three basic scenarios.

Single-Site Deployment

In a single-site deployment, file servers are hosted within a central site in the customer infrastructure. This deployment type is seen most often in customers with a highly centralized infrastructure or with smaller branch offices that do not maintain local file servers. This deployment model can be easier for IT staff to administer, since all server assets are local, and internet ingress/egress is likely centralized at this location as well. However, this deployment model also relies on good WAN connectivity between the central site and any branch offices, and users in branch offices are vulnerable to an interruption of service due to network conditions.

Multiple-Site Deployment

In a multiple-site deployment, file servers are hosted in multiple locations within the customer’s infrastructure. This could mean multiple datacenters or it could mean that branch offices maintain individual file servers. This deployment type is seen most often in larger customer environments or in customers that have several larger branch offices that maintain local server assets. This deployment model is more complex for IT personnel to administer, and relies on careful coordination of data storage and maintenance of Active Directory Domain Services (AD DS) to ensure that users are using the correct sync server for Work Folders.

Hosted Deployment

In a hosted deployment, sync servers are deployed in an IAAS (Infrastructure-as-a-Service) solution such as Windows Azure VM. This deployment method has the advantage of making the availability of file servers less dependent on WAN connectivity within a customer’s business. If a device is able to connect to the Internet, it can get to its sync server. However, the servers deployed in the hosted environment still need to be able to reach the organization’s Active Directory domain to authenticate users, and the customer trades infrastructure requirements on premise for additional complexity in maintaining that connection.

Deployment technologies

Work Folders deployments consist of a number of technologies that work together to provide service to devices on both the internal and external networks. Before designing a Work Folders deployment, customers should be familiar with the requirements of each of the following technologies.

Active Directory Domain Services

AD DS provides two important services in a Work Folders deployment. First, as the back-end for Windows authentication, AD DS provides the security and authentication services that are used to grant access to user data. If a domain controller cannot be reached, a file server will be unable to authenticate an incoming request and the device will not be able to access any data stored in that file server’s sync share.

Second, AD DS (with the Windows Server 2012 R2 schema update) maintains the msDS-SyncServerURL attribute on each user, which is used to automatically direct users to the appropriate sync server.

File Servers

File servers running Windows Server 2012 R2 host the Work Folders role service, and host the sync shares that store users’ Work Folders data. File servers can also host data stored by other technologies operating on the internal network (such as file shares), and can be clustered to provide fault tolerance for user data.

Group Policy

If you have Windows 7 PCs in your environment, we recommend the following:

• Use Group Policy to control password policies for all domain-joined PCs that use Work Folders.

• Use the Work Folders Automatically lock screen, and require a password policy on PCs that aren’t joined to your domain.

You can also use Group Policy to specify a Work Folders server to domain-joined PCs. This simplifies Work Folders setup a little bit– users would otherwise need to enter their work email address to lookup the settings (assuming that Work Folders is set up properly), or enter the Work Folders URL that you explicitly provided them via email or another means of communication.

You can also use Group Policy to forcibly set up Work Folders on a per-user or per-computer basis, though doing so causes Work Folders to sync on every PC a user signs in to (when using the per-user policy setting), and prevents users from specifying an alternate location for Work Folders on their PC (such as on a microSD card to conserve space on the primary drive). We suggest carefully evaluating your user's needs before forcing automatic setup.

Windows Intune

Windows Intune also provides a layer of security and manageability for non-domain-joined devices that would not otherwise be present. You can use Windows Intune to configure and manage users’ personal devices such as tablets that connect to Work Folders from across the Internet. Windows Intune can provide devices with the sync server URL to use – otherwise users must enter their work email address to lookup the settings (if you publish a public Work Folders URL in the form of https://workfolders.contoso.com), or enter the sync server URL directly.

Without a Windows Intune deployment, users must configure external devices manually, which can result in increased demands on a customer’s help desk staff.

You can also use Windows Intune to selectively wipe the data from Work Folders on a user's device without affecting the rest of their data – handy for if a user leaves your organization or has their device stolen.

Web Application Proxy/Device Registration Service

Work Folders is built around the concept of allowing Internet-connected devices to retrieve business data securely from the internal network, which allows users to “take their data with them” on their tablets and devices that would not normally be able to access work files. To do this, a reverse proxy must be used to publish sync server URLs and make them available to Internet clients.

While customers can leverage any of several different technologies to provide this functionality, Active Directory Federation Services (AD FS) in Windows Server 2012 R2 offers the following functionality that can be useful with Work Folders deployments:

• Web Application Proxy – a reverse proxy implementation that pre-authenticates access to web applications using AD FS. For more information, see Web Application Proxy Walkthrough Guide.

• Workplace Join and Device Registration Service– optionally allows users to join devices to the workplace that would not normally be domain-joined; for example, personal laptops, tablets, and smartphones. When these technologies are enabled, the AD FS administrator can configure applications and policies for corporate resources that require devices to be registered before they can gain access to published applications and resources. For more information, see Join to Workplace from Any Device for SSO and Seamless Second Factor Authentication Across Company Applications.

• Multifactor authentication (MFA) – optionally allows administrators to set up a policy based on user, device, or location data that requires users to authenticate with more than one authentication method; for example, a one-time password or a smart card. See Manage Risk with Additional Multi-Factor Authentication for Sensitive Applications.

• Multi-domain authentication – with AD FS you can support users from multiple domains syncing with a single sync server across the Internet. Without this capability, users from domains other than the one the sync server is joined to wouldn't be able to sync across the Internet.

Additional design considerations

In addition to understanding each of the components noted above, customers need to spend time in their design thinking about the number of sync servers and shares to operate, and whether or not to leverage failover clustering to provide fault tolerance on those sync servers

Number of Sync Servers

It is possible for a customer to operate multiple sync servers in an environment. This can be a desirable configuration for several reasons:

• Geographic distribution of users – for example, branch office files servers or regional datacenters

• Data storage requirements – certain business departments might have specific data storage or handling requirements that are easier with a dedicated server

• Load balancing – in large environments, storing user data on multiple servers can increase server performance and uptime.

For information on Work Folders server scaling and performance, see Performance Considerations for Work Folders Deployments.

Number of Sync Shares

Individual sync servers can maintain multiple sync shares. This can be useful for the following reasons:

• Auditing and security requirements – If data used by a certain department must be more heavily audited or retained for a longer period of time, separate sync shares can help administrators keep user folders with differing audit levels separated.

• Differing quotas or file screens – If you want to set different storage quotas or limits on which file types are allowed in Work Folders (file screens) for different groups of users, separate sync shares can help.

• Departmental control – If administrative duties are distributed by department, utilizing separate shares for different departments can aid administrators in enforcing quotas or other policies.

• Differing device policies –If an organization needs to maintain multiple device policies (such as encrypting Work Folders) for different groups of users, using multiple shares enables this.

• Storage capacity –If a file server has multiple volumes, additional shares can be used to take advantage of these additional volumes. An individual share has access to only the volume that it is hosted on, and is unable to take advantage of additional volumes on a file server.

Access to Sync Shares

While the sync server that a user accesses is determined by the URL entered at their client (or the URL published for that user in AD DS when using server automatic discovery), access to individual sync shares is determined by the permissions present on the share.

As a result, if a customer is hosting multiple sync shares on the same server, care must be taken to ensure that individual users have permissions to access only one of those shares. Otherwise, when users connect to the server, their client may connect to the wrong share. This can be accomplished by creating a separate security group for each sync share.

Further, access to an individual user’s folder inside a sync share is determined by ownership rights on the folder. When creating a sync share, Work Folders by default grants users exclusive access to their files (disabling inheritance and making them the owner of their individual folders).

Design checklist

The following set of design questions is intended to aid customers in designing a Work Folders implementation that best serves their environment. Customers should work through this checklist prior to attempting to deploy servers.

• Intended Users

  • Which users will use Work Folders?

  • How are users organized? (Geographically, by office, by department, etc)

  • Do any users have special requirements for data storage, security, or retention?

  • Do any users have specific device policy requirements, such as encryption?

  • Which client computers and devices do you need to support? (Windows 8.1, Windows RT 8.1, Windows 7)

    If you’re supporting Windows 7 PCs and want to use password policies, exclude the domain storing their computer accounts from the Work Folders password policy, and instead use Group Policy password policies for domain-joined PCs in that domain.

  • Do you need to interoperate with or migrate from other user data management solutions such as Folder Redirection?

  • Do users from multiple domains need to sync across the Internet with a single server?

  • Do you need to support users who aren't members of the Local Administrators group on their domain-joined PCs? (If so, you'll need to exclude the relevant domains from Work Folders device policies such as encryption and password policies)

• Infrastructure and Capacity Planning

  • In what sites should sync servers be located on the network?

  • Will any sync servers be hosted by an Infrastructure as a Service (IaaS) provider such as in an Azure VM?

  • Will dedicated servers be needed for any specific user groups, and if so, how many users for each dedicated server?

  • Where are the Internet ingress/egress points on the network?

  • Will sync servers be clustered for fault-tolerance?

  • Will sync servers need to maintain multiple data volumes to host user data?

• Data Security

  • Will multiple sync shares need to be created on any sync servers?

  • What groups will be used to provide access to sync shares?

  • If you're using multiple sync servers, what security group will you create for the delegated ability to modify the msDS-SyncServerURL property of user objects?

  • Are there any special security or auditing requirements for individual sync shares?

  • Is multi-factor authentication (MFA) required?

  • Do you need the ability to remotely wipe Work Folders data from PCs and devices?

• Device Access

  • What URL will be used to provide access for Internet-based devices (the default URL that is required for email-based automatic server discovery is workfolders.domainname)?

  • How will the URL be published to the Internet?

  • Will automatic server discovery be used?

  • Will Group Policy be used to configure domain-joined PCs?

  • Will Windows Intune be used to configure external devices?

  • Will Device Registration be required for devices to connect?

Next steps

After designing your Work Folders implementation, it’s time to deploy Work Folders. For more information, see Deploying Work Folders.

See also

For additional related information, see the following resources.