Windows Server 2012 R2 and BYOD (Part 2)

If you would like to read the other parts in this article series please go to:

• Windows Server 2012 R2 and BYOD (Part 1)
• Windows Server 2012 R2 and BYOD (Part 3)
• Windows Server 2012 R2 and BYOD (Part 4)
• Windows Server 2012 R2 and BYOD (Part 5)
• Windows Server 2012 R2 and BYOD (Part 6)
• Windows Server 2012 R2 and BYOD (Part 7)
• Windows Server 2012 R2 and BYOD (Part 8)
• Windows Server 2012 R2 and BYOD (Part 9)

The Requirements

As I explained in the first part of this article series, the workplace join feature is new to Windows Server 2012 R2. It should therefore come as no surprise that I will be basing all of the backend walkthroughs on Windows Server 2012 R2.

For the sake of demonstration, I am going to be creating a lab environment which I will then use to walk you through the deployment and configuration process. My lab consists of a Windows Server 2012 R2 Hyper-V Server with eight logical processors and 32 GB of RAM. I am creating four virtual machines, with two virtual processors and 4 GB of RAM each.

The first of these virtual machines will be configured to act as a domain controller for a lab domain. I will be calling the lab domain BYOD-Lab.com. The virtualized domain controller will be named DC.BYOD-Lab.com.

The domain controller will also be acting as an enterprise certificate authority. The workplace join feature is based around the use of digital certificates, so we will be using this enterprise certificate authority to issue the necessary certificates.

The second virtual machine is going to act as an Active Directory Federation Server. This will be the server that is responsible for facilitating the workplace join and single sign on for end user devices. I will be referring to this particular VM as ADFS.BYOD-LAB.com

Technically, the two virtual machines that I have just described are sufficient for implementing workplace join capabilities. However, we need a couple more VMs if we actually want to use the infrastructure that we have created. As such, the third VM that we will be creating is a Web server. This server will host a Web application that we will make accessible to an end user device. Microsoft actually provides an application that works really well for this purpose. I will show you how to acquire and deploy this application later on. I will be referring to this VM as Web.BYOD-Lab.com.

The fourth VM is going to act as our end user device. Unlike the first three virtual machines which are going to be running Windows Server 2012 R2, the fourth virtual machine is going to be running Windows 8.1. Because this virtual machine is intended to emulate an end user device, it will not be domain joined. I will be referring to this VM as W81Client.

Here is a quick breakdown of how the various virtual machines will be configured:

Table 1

Configuration Assumptions

Before I delve into the configuration process, I want to lay out my assumptions for this article. For the most part, I will be walking you through the entire configuration process in a step by step manner. However, there are some basic configuration tasks that I will not be covering on a granular level. For the purposes of this article series, I am assuming that you know how to perform the following tasks:

• Create a virtual machine
• Install Windows
• Set up a domain controller
• Create Active Directory users and groups
• Assign IP addresses
• Assign computer names
• Join a server to a domain

Configuring the Domain Controller

For the purposes of this article, I am going to assume that you have already installed Windows onto the DC.BYOD-Lab.com VM, assigned it the appropriate computer name and IP address, and configured the VM to act as a domain controller. Now that the basics are in place, we need to configure the VM to act as an enterprise certificate authority for the domain.

Begin the process by opening the Server Manager and selecting the Add Roles and Features command from the Manage menu. When you do, Windows will launch the Add Roles and Features Wizard. Click Next to clear the wizard’s Welcome screen . On the following screen, select the Role-Based or Feature based Installation option and click Next. Select your server and click Next once again.

When you reach the Server Roles screen, select the Active Directory Certificate Services option. When prompted, click the Add Features button to add the features required to support the role. Click Next until you reach the Role Services screen. Select the Certificate Authority and the Certification Authority Web Enrollment check boxes and then click Next. Continue clicking Next until you reach the Confirmation screen. At that point, take a moment to verify that all of the correct options have been selected and then click Install.

Configuring the Enterprise Certificate Authority

When the wizard completes, click on the link to begin the configuration process. When you do, Windows will launch the AD CS Configuration Wizard. Click Next to bypass the wizard’s Credentials screen. At this point, you will be taken to the Role Services screen. Select the Certification Authority check box and the Certification Authority Web Enrollment check box and then click Next.

When you reach the Setup Type screen, select the Enterprise CA option and then click Next. On the following screen, Windows will ask you if you want to create a root CA or a subordinate CA. Choose the Root CA option and click Next.

When you reach the Private Key screen, select the Create a New Private Key option and click Next. Click Next to accept the defaults on the Cryptography screen and then click Next once again to accept the defaults on the CA Name screen. You should also click Next to accept the default validity period of five years.

Click Next to accept the default certificate database path. You will now be taken to the Confirmation screen. Take a moment to verify that the information that is displayed is correct, and then click the Configure button. The configuration process should now be completed. When the process completes, click the Close button.

It is important to remember that we are setting up the enterprise certificate authority to work in a lab environment. If you were provisioning a production environment and you wanted to use an in house certificate authority then you should put more thought into your choices rather than blindly accepting default values as we have done here. For example, you would want to place the certificate databases on your most secure and reliable storage device rather than allowing Windows to place the databases on the C: drive.

Conclusion

Now that we have an enterprise certificate authority in place, we can move forward with preparing the rest of our infrastructure. In Part 3, I will walk you through the remainder of the domain controller preparation process and we will begin setting up the Active Directory Federation Services.

If you would like to read the other parts in this article series please go to:

• Windows Server 2012 R2 and BYOD (Part 1)
• Windows Server 2012 R2 and BYOD (Part 3)
• Windows Server 2012 R2 and BYOD (Part 4)
• Windows Server 2012 R2 and BYOD (Part 5)
• Windows Server 2012 R2 and BYOD (Part 6)
• Windows Server 2012 R2 and BYOD (Part 7)
• Windows Server 2012 R2 and BYOD (Part 8)
• Windows Server 2012 R2 and BYOD (Part 9)