If you work in IT, you are an enabler. You enable people to do their jobs. One of the best bang for the buck projects you can take on is remote document access. For this project to be successful, your technology has to be:

• widely available
• simple to use
• easy to manage

If any of these three points are not met, the project will flounder. In my opinion, Work Folders is the technology that meets all three requirements.

 

Why Work Folders?

When Work Folders was first released, I was incredibly excited until I read the client requirements – just Windows 8 support. At the time, Windows 7 was the dominant OS and few of my staff could take advantage of Work Folders. The landscape has changed. With the free Windows 10 upgrade, the vast majority of my staff suddenly had access to Work Folders. Further, Microsoft has released has iOS app that is fully supported on both iPhone/iPads and an Android app. Work Folders will even run on Windows RT devices!

A user wanting to use Work Folders only needs to know their email, username, and password. Your public DNS configuration points external access to the correct internal resource. Because the sync client is already built into Windows, staff do not need to download additional software (or even change application settings).  Your AD environment already contains the usernames/passwords for your staff so they don’t even have to create an account.

Work Folders asking for an email address.

Finally, Work Folders is easy for the IT administrator manage. It leverages your existing Folder Redirection infrastructure for data access. Your file servers do have to be at Server 2012R2 or above though. Using Works Folders doesn’t exclude you from using other remote storage technologies because it stacks on top of file server. Finally, adopting Work Folders will likely set you ahead of the curve as it will likely replace other technologies like Offline Files.

Are you sold on Work Folders yet? Great! We will divide our work up into two parts. In this first part, we will configure DNS and get our certificates. In the second part, we will enable the Work Folders role, tie in multiple file servers, and roll it out to our users. The second part will even have a setup guide for your staff to use.

Configuring DNS and Firewalls for Work Folders

There are two main routes that you can take in configuring Work Folders. The first route involves an ADFS reverse proxy server acting as a middleman between the client and your file servers. This is the recommended route. This post will focus on the second route though (no reverse proxy server). This second route is less complex and will help you get a working solution up very quickly. Once you have a working environment, you can migrate to the reverse proxy server route if desired.

The Work Folders client uses an auto-discover feature to streamline the initial connection and future synchronizations. Because of this, you will need at least two public DNS records. The first record should be a type A record pointing workfolders.public-domain-name to the public IP of a file server running the Work Folders role (we will configure the role in part 2).  This server can be a dedicated machine running just the Work Folders role or it can be an existing file server used in your Folder Redirection architecture. Many organizations will choose to resolve workfolders.public-domain-name to an existing file server.

Other file servers that you wish to allow Work Folders to access will also need a DNS record created. Let’s say your environment has three servers where redirected documents are stored. You will need to have the following public records created:

• workfolders.test.com > resolves to File Server 1
• fs2.test.com > resolves to File Server 2
• fs3.test.com > resolves to File Server 3

Work Folders runs over HTTPS. Servers running the Work Folders role will need port 443 opened on the local server and on your external firewalls.

 

Configure Certificates for Work Folders

For Work Folders to run without any end-user authentication, your Work Folders infrastructure will need a 3rd party trusted SAN certificate. If you are doing a proof of concept test, you can use an internal certificate if your clients are domain joined. The 3rd party trust certificate allows non-domain join devices (like an iPhone) to trust the connection to your Work Folders server.

Generate the certificate request on the server that will have the public DNS name of workfolders.public-domain-name. You can generate a certificate with IIS or directly with certreq. Submit the certificate request to your favorite 3rd party CA. Request a SAN certificate. For your subject alternative names, ensure that you have workfolders.public-domain-name plus an entry for each file server that will be used.

Once your certificate has been created, install it with certmgr.msc. Start MMC.exe as an administrator – load the Certificates tool – select Computer account to do this.

Place the certificate into the original server’s personal store. Next, export the certificate from that server with the private key. Import that certificate into the computer’s personal store with the private key on each of your remaining file servers.

This wraps up part 1 of your work folders setup. In our next part, we will configure the server role and get users connected to their redirected folders remotely! If you have any questions or ran into any issues, let me know in the comments below.