Summary: Guest blogger and security expert, Yuri Diogenes, completes his series about enabling BYOD.

Microsoft Scripting Guy, Ed Wilson, is here. Today’s guest blogger is Yuri Diogenes, who continues his security series about enabling BYOD. Yuri is a senior knowledge engineer, and he is a coauthor of the book Windows Server 2012 Security from End to Edge and Beyond. You can follow him on Twitter at @YuriDiogenes.

This is the last post of a series, and before we start, I would like to recap what has been documented so far:

• In Using PowerShell to Enable BYOD–Part 1, I explained how to enable device registration to allow the Contoso, Ltd. IT department to have awareness of users’ devices and to perform second-factor authentication.
• In Using PowerShell to Enable BYOD–Part 2, I explained how to enable Web Application Proxy to allow Contoso IT to publish internal resources for users coming from the Internet.

This post will continue the Contoso IT story to embrace “bring your own device” (BYOD). If you want to know more about BYOD, read the General Considerations Regarding BYOD section in Bring Your Own Device (BYOD) Survival Guide for Microsoft Technologies. I also encourage you to listen to my two parts interview with TechNet Radio about BYOD:

• TechNet Radio: (Part 1) Understanding BYOD: What it Means for My Company
• TechNet Radio: (Part 2) Understanding BYOD: How to Make it Happen

Scenario 3: Protect data that resides on users’ devices

Talking about BYOD without covering file share and how these files will reside on the user’s device isn’t a compelling story. Even knowing that now we have technologies, such as SharePoint and SkyDrive, which allow users to share files by using web technologies, the reality is that traditional file server access by using the Universal Naming Convention (UNC) path is still there, and it won’t go away soon. Users are used to accessing files that are shared on a server, and they also want to be able to store some of their files in a shared location that can be accessible via a UNC path.

By using a new capability in Windows Server 2012 R2 called Work Folders, you can enable users to access shared folders that are located on an internal file server, and synchronize the data with their device. The following image shows the core infrastructure for this scenario:

Notice that Windows Application Proxy will be used to publish the resource and AD FS will be used for authentication and authorization.

Scenario definition

Contoso IT is moving to the third phase of their deployment. Now they need enable users to be able to sync their work data to their devices, and still be able to classify information and apply protection to sensitive data. They also want to centralize the data—that is, ensure that a copy of the information is kept within the corporate realm so that the information is available, backed up, and subject to corporate business rules.

The steps to enable Work Folders by using Windows PowerShell are quite simple. However, there are some prerequisites that must be in place before you enable this capability. To review the requirements that must be in place before you deploy this role, see Designing a Work Folders Implementation.

After the core infrastructure it is in place, you can enable the Work Folders role in Windows Server 2012 R2 by using the following Windows PowerShell command:

Add-WindowsFeature FS-SyncShareService

The following image shows an example of this operation:

After you enable this feature, you should plan where you are going to enable the sync share. Please read Performance Considerations for Work Folders Deployments to be aware of the performance impact of this feature. When you enable the FS-SyncShareService feature, Windows adds the SyncShare module to Windows PowerShell. Then, when you plan the sync share location, you can use the New-SyncShare cmdlet to create a new sync share. Following is an example of this operation:

You could also provide password policy enforcement at the end of the command. For example, if the company requires an automatic lock screen policy every 15 minutes, you could add the RequirePasswordAutoLock $true parameter. By enforcing this policy, you also enforce the following policies:

• Password minimum length of six characters
• User account lockout after a maximum of 10 failed sign-in attempts

For Contoso IT, it is also important to encrypt the data, so you need to add the –RequireEncryption $true parameter. For more information about the parameters that are available when you create a new sync share, read New-SyncShare.

It is important to notice the group that is used in the previous example is ContosoSales. This is a security global group in Active Directory. When you deploy Work Folders, we recommend that you plan which users should be authorized to synchronize their data with their devices, and then create groups (or utilize the groups you already have) to enable only users that belong to those groups to perform this operation. For Contoso IT, is also important that this capability is available via SMB access. This requires that the group you give access to has the Read/Write share permission level.

Note  You need to share the folder. To do that, open Windows Explorer and navigate to This PC. Right-click the Sales folder, click Share with, and then click Specific people. Add Contoso\ContosoSales and change the permission level to Read/Write.

After the SMB share access is granted to the users’ group, the default setting is that the server will verify the folder for synchronization every five minutes. You can change this time by using the following command:

Set-SyncServerSetting -MinimumChangeDetectionMins

Validate the environment

At this point, you should be able to validate the environment. To perform this validation, follow the **Client Setup **section in the topic Work Folders Test Lab Deployment. Notice that you need to add the registry keys that are mentioned in the topic for validation purposes in your lab environment—don’t add them in a production environment. The following image shows what you will see on the client computer when you create a file and observe the synchronization status:

Notice that the file name appears in green font because it is encrypted with EFS on the user’s device.

On the server, you can use Get-SyncUserStatus to obtain more information about the sync status for a particular user and share as shown in the following example:

Additional resources

• For more information about how to monitor Work Folders, see Monitoring Windows Server 2012 R2 Work Folders Deployments.
• To set up your environment to test this functionality, follow the instructions in Work Folders Test Lab Deployment.

I hope you liked this series about BYOD. Have a great 2014!

~Yuri

Thank you for your expertise, Yuri. This has been an awesome series.

I invite you to follow me on Twitter and Facebook. If you have any questions, send email to me at scripter@microsoft.com, or post your questions on the Official Scripting Guys Forum. See you tomorrow. Until then, peace.

Ed Wilson, Microsoft Scripting Guy