Tip

Important considerations for setting up Work Folders

Here, I continue with the process of setting up Work Folders. In part one we were working on the server, and that's where we will pick up here in part two.

Requires Free Membership to View

Configuring SSL connections

There's still more work to be done on the server end. At this point, we need to configure SSL encryption. For lab deployments, you can use a self-signed certificate if you're opposed to spending money. Or, you can generate a certificate request for your existing public key infrastructure deployment and then get it signed by a trusted certification authority. The feature works with either process.

What names do you need to use? Work Folders client devices are hard coded to look for hosts answering at the SyncSvr.domain.tld and WorkFolders.domain.tld subdomains. You'll of course need certificates covering those namespaces for the SSL connections to be authentic. If you're using self-signed certificates, import those certificates into the local certificate stores on your client devices so Windows knows to trust those certificates when they're presented within the transaction.

Your normal PKI will probably not help here. These client devices will generally be personal devices that aren't domain members and don't exchange certificates as part of the domain join process.

Once you get a certificate or generate a self-signed certificate, find the thumbprint for that certificate. Again, PowerShell comes to the rescue:

Get-ChildItem –Path cert:\LocalMachine\My

Next, open up a regular command line session and not another instance of the PowerShell interface. Then, use netsh to bind that particular certificate to all hostnames on the server at the default IP SSL port of 443. The long appID attribute number is static, so feel free to cut and paste here if it suits you:

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

Configure DNS records

We're almost to the finish line on the server side. We need to set up DNS A records for the SyncSvr.domain.tld and WorkFolders.domain.tld domains.

Use whatever DNS option you implemented to create these records. You'll also need to make sure these records exist in your public as well as the private namespace if you are doing what is commonly known as "split DNS." The A records for each should resolve to the externally facing IP address of your sync server, assuming you want to enable syncing over the big, bad and wild Internet.

That's the end of the server process. Let's look at what a client experience is like using Work Folders.

Work Folders on the client side

The client process is pretty simple. The heavy lifting is done on the server side, and since the clients are hardcoded to look for sync servers at the domain names above, as we discussed, there are not a lot of settings to configure on the client side.

Follow these steps to enroll a client in Work Folders:

  1. Open Control Panel and click on System and Security.
  2. Click on Work Folders and then click on Set up work folders.
  3. Enter the end user's email address. The wizard will look for WorkFolders.domain.tld and then attempt to create a partnership. You will be prompted for credentials on non-domain joined machines.
  4. The wizard will ask to point out where on the local machine you'd like to store synced content. It will also populate a little Work Folders icon on the left side of an Explorer window.

That's it. By default, Work Folders will attempt to sync every five minutes.

Possible problems with Work Folders

Work Folders joins an already crowded field of sync options, and for a numbers of reasons, I suspect your use of it will be limited in the near term. Here's why.

Right now, you can only use Work Folders in conjunction with Windows 8.1 devices and Windows RT 8.1 devices. There will be future clients for Windows 7 and Windows 8 devices in the coming months -- sorry, nothing for Windows XP! On the server side, Windows Server 2012 R2 is required to run the sync share and there will not be any backporting to earlier server versions, like Windows Server 2008, R2 or 2012.

Work Folders is pretty much an all or nothing affair. Except for being able to choose a specific subfolder on the path of the shared sync folder, Work Folders sync everything, so you can't select single files. Devices with limited local storage, like tablets and phablets, could find themselves without free space very quickly with this solution unless it is carefully managed by the end user.

With these caveats, Work Folders is still an in-the-box option for Windows 8.1 clients to help bridge the personal device-corporate device gap. It can also enable end users to get access to what they need from wherever they are and whatever device they are using. You should evaluate it and find where it makes sense for your organization.

About the author: 
Jonathan Hassell is an author, consultant and speaker on a variety of IT topics. His published works include RADIUSHardening WindowsUsing Microsoft Windows Small Business Server 2003 and Learning Windows Server 2003. Jonathan also speaks worldwide on topics ranging from networking and security to Windows administration. He is president of 82 Ventures LLC, based in North Carolina, and is currently an editor for Apress Media LLC, a publishing company that specializes in books for programmers and IT professionals.

This was first published in April 2014

There are Comments. Add yours.

 
TIP: Want to include a code block in your comment? Use <pre> or <code> tags around the desired text. Ex: <code>insert code</code>

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
Sort by: OldestNewest

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

Disclaimer: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.