In the previous blog post, I provided a step by step guide to setup Work Folders in a lab environment using the Preview release of Windows Server 2012 R2. With the GA release, Work Folders leverages Windows Failover clustering to increase availability. For general details about failover clusters, see Failover Clustering.

In this blog post, I’ll show you how to configure the Work Folders on failover clusters using the latest Windows Server 2012 R2 release.

Overview

Work Folders is a new technology in the File and Storage Services role. Work Folders enables users to sync their work data across their devices using a backend file server so that their data is available to them wherever they are. In the Windows Server 2012 R2 release, Work Folders is supported on traditional failover file server clusters.

Pre-requisite

In this blog post, I’ll provide you with the step by step guide to set up Work Folders in a highly available failover configuration, and discuss the differences in managing a clustered Work Folders server vs. a standalone Work Folders server. This post assumes that you have a good understanding of Work Folders, and know how to configure Work Folders on a standalone server. If not, refer to the Work Folders Overview as well as Designing a Work Folders Implementation and Deploying Work Folders.

To follow this step by step guide, you will need to have the following computers ready:

• Domain controller: a server with the Active directory Domain Services role enabled, and configured with a domain (for example: Contoso.org)
• A two node server cluster, joined to the domain (Contoso.org). Each node runs Windows Server 2012 R2 build. (for example: HAWorkFolders)
• One client computer running Windows 8.1 or Windows RT 8.1

The computers can be physical or VMs. This blog post will not cover the steps to build the two node clusters; to set up a failover cluster, see Create a Failover Cluster.

Express lane

This section provides you a checklist on how to setup sync shares on clusters, detailed procedures are covered in the later sections.

1. Enable the Work Folders role on both cluster nodes
2. Create a file server role in the cluster
3. Configure certificates
4. Create sync share
5. Client setup

Enable Work Folders role service

The Work Folders role service needs to be enabled on all the cluster nodes. In this blog posts, as I have a two node cluster, I will enable roles on both nodes, by running the following Windows PowerShell cmdlets on each node:

PS C:\> Add-WindowsFeature FS-SyncShareService

To check if the computer has Work Folders enabled, run

PS C:\> Get-WindowsFeature FS-SyncShareService

Note: If Work Folders is installed, FS-SyncShareService will be marked with X.

Creating a clustered file server

Highly available services are created by using the High Availability Wizard in Failover Cluster Manager. Since Work Folders is part of the File and Storage Services Server role and you have already enabled Work Folders on each node, you can simply create the file server in the cluster, and configure sync shares on the highly available file server. The clustered file server will also be referred as a clustered file server instance, which is often called a cluster name account, virtual computer object, or (VCO).

Note: Work Folders isn’t supported on Scale-Out File Servers.

To create a clustered file server:

1. Open Failover Cluster Manager

2. Right click Roles, and then click Configure Roles…

3. Click File Server.

4. Choose the “File Server for general use” option:

5. Enter a name for the clustered file server instance (VCO). This will be the sync server name used by Work Folders client computers and devices during sync.

6. Select the disk on which users’ data will be stored.

7. Click on the confirmation to proceed on the role creation.

8. After you’re finished, the sync server appears in Failover Cluster Manager.

Configure certificates

For general certificate management, see this post. This section will focus on certificate configurations in a cluster using self-signed certificate. Note: the certificate must be configured on each of the nodes.

1. Create a self-signed certificate on one of the cluster nodes by using Windows PowerShell:

PS C:\> New-SelfSignedCertificate –DnsName “SyncServer.Contoso.org”,”WorkFolders.Contoso.org” –CertStoreLocation cert:\Localmachine\My

Note: the DNS name should be the name you used for the clustered file server instance (VCO) for the sync server. For multiple VCOs, the certificate must include all of the VCO names.

2. Export the certificate to a file

To export the certificate with password, you can either use certmgr.msc, or Windows PowerShell. I’ll show you the cmdlet version referenced in this page:

$cert = Get-ChildItem –Path Cert:\LocalMachine\My\<thumbprint>

$type = [System.Security.Cryptography.X509Certificates.X509ContentType]::pfx

$pass = read-host "Password:" -assecurestring

$bytes = $cert.export($type, $pass)

[System.IO.File]::WriteAllBytes("ServerCert.pfx", $bytes)

3. Copy, then import the certificate on the other node

$pass = read-host “Password:” -AsSecureString

Import-pfxCertificate –FilePath servercert.pfx –CertStoreLocation cert:\LocalMachine\My –Password $pass

4. Configure SSL binding on both cluster nodes

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

Note: you can get the certificate thumbprint by running:

PS C:\>Get-ChildItem –Path cert:\LocalMachine\My

5. Copy, then import the certificate on the client computer. Note: this step is only necessary for self-signed certificate, where client computers don’t trust the certificate by default. Skip this step if you are using trusted certificate.

$pass = read-host “Password:” -AsSecureString

Import-pfxCertificate –FilePath servercert.pfx –CertStoreLocation cert:\LocalMachine\Root –Password $pass

Create a sync share

In a cluster, the sync share is created on the node that owns the disk resource. In other words

1. You cannot create sync shares on disks that are not shared across all the nodes.

2. You cannot create sync shares on the non-owner node of the clustered file server instance (VCO).

For example, I want to setup a sync share on disk E, which is owned by SyncNode1, I will run the following cmdlet on SyncNode1:

New-SyncShare HAShare -path E:\hashare -user Contoso\fin

Note: For more information about creating sync shares, see Deploying Work Folders.

Client setup

• Make sure that the client can trust the certificate used on the server. If you are using the self-signed certificate, you need to import it on the client. (see step 5 in Configure certificates)
• When the client connects to the sync servers, it connects to the clustered file server instance (e.g. https://SyncServer.Contoso.org). The client should not connect directly to any physical nodes.
• The Work Folders setup experience for users is the same as if Work Folders was hosted on a single server, as long as the administrator has set up Work Folders properly with a publicly accessible URL pointing to the VCO name.
• Sync happens in the background, and there is no difference between standalone or clustered Work Folder servers for ongoing sync, although users can’t sync while the server is in the process of failing over - sync continues after the failover has completed.

Managing clustered sync servers

Most of the management experiences are the same between standalone and clustered sync servers. In this section, I’d like to list out a few differences:

• All the nodes in the cluster need to have “Work Folders” enabled.
• When there are more than one clustered sync servers hosted by a single cluster, you can manage sync shares with the “scope” parameter in the cmdlet. For example, Get-SyncShare –Scope <sync server VCO> will limit the sync shares configured on a specific clustered sync server (VCO). You need to run the cmdlet on the cluster node which is hosting the VCO.
• Using Set-SyncServerSetting on a standalone server applies the settings on a single sync server; using the cmdlet on a clustered sync server applies the settings to all the clustered sync server (VCO) in the cluster.
• When managing sync shares (such as new, set, remove), you must run the cmdlet or wizard on the node that owns the disk resources that are hosting the sync share data.
• The SSL certificate is managed on each node in the cluster. The certificate must be installed and configured with SSL binding on each node; certificate renewal is also per node.
• The certificate CN must contain the sync server (VCO) name, not the cluster node names.
• When the client connects to the server, it connects using the sync server (VCO) name.

Conclusion

Work Folders supports failover clustering configuration in Windows Server 2012 R2. Most of the management experience is similar to the standalone servers, and the management should be scoped to the clustered sync server (VCO). Certificate management however is per-node.

I hope this blog post helps you to understand how to set up a highly available Work Folders server and provides you with insight into the differences in management between a standalone and highly available configuration. If you have questions not covered here, please raise it in the comments so that I can address it with upcoming postings.