Leverage the Mobile Device Extension for ad rms

Setting up the Windows Server 2012 R2 Base Configuration test lab

By following the instructions outlined hereafter, you should be able to successfully prepare your test lab environment based on virtual machines (VMs) running in Azure to later deploy and configure the mobile Device Extension environment, install and configure it with AD RMS along with Active Directory Federation Services (AD FS) in Windows Server 2012 R2 that is a prerequisite, etc. and start evaluating/using it.

Important note Individual virtual machines (VMs) are needed to separate the services provided on the network and to clearly show the desired functionality. This being said, the suggested configuration to later evaluate the Mobile Device Extension for AD RMS is neither designed to reflect best practices nor does it reflect a desired or recommended configuration for a production network. The configuration, including IP addresses and all other configuration parameters, is designed only to work on a separate test lab networking environment.

Any modifications that you make to the configuration details provided in the rest of this document may affect or limit your chances of successfully setting up the on-premises test lab environment. We recommend following this guide as-is first to familiarize yourself with the steps involved, before attempting a deployment on an environment with a different configuration.

In order to complete the document’s walkthrough, you need an environment that consists of the following components for the Azure-based test lab infrastructure:

• 
  One Azure virtual machine running Windows Server 2012 R2 (named DC1) that is configured as a domain controller with a test user and group accounts, and Domain Name System (DNS) server.
  
• 
  One Azure virtual machine running Windows Server 2012 R2 (named ADFS1) that is configured as an enterprise root certification authority and as an AD FS federation server.
  
• 
  One Azure virtual machine running Windows Server 2012 R2 (named ADRMS1) that is configured as an AD RMS cluster.
  

Note For more information about the system requirements for installing AD RMS, see the Microsoft TechNet article Pre-installation Information for Active Directory Rights Management Services⁴⁹.

• 
  One Azure virtual machine running Windows Server 2012 R2 (named SQL1) that is configured as a SQL Server 2012 computer, which will be used to support the AD RMS configuration and logging databases.
  

Important note The Mobile Device Extension for AD RMS requires that the AD RMS deployment uses a full Microsoft SQL Server-based database on a separate server and not the Windows Internal Database that is often used for testing on the same server.

• 
  One Azure virtual machine running Windows Server 2012 R2 (named EDGE1) that is configured as a Web server.
  

Important note The configuration of the Azure virtual machines and the related Azure virtual network (see below) in this guide is designed to give you hands-on practice in creating an AD RMS test environment suitable for testing and evaluating the Mobile Device Extension for AD RMS. The design decisions made in this guide were geared toward increasing your hands-on experience and to some degree reflect AD RMS best practices configuration. For full best practices and design and planning information related to AD RMS, see the Microsoft TechNet articles AD RMS Prerequisites⁵⁰, AD RMS Performance and Logging Best Practices⁵¹, and AD RMS Architecture Design and Secure Collaboration Scenarios⁵².
Note Windows Server 2012 R2 offers businesses and hosting providers a scalable, dynamic, and multitenant-aware infrastructure that is optimized for the cloud. For more information, see the Microsoft TechNet Windows Server 2012 R2 homepage⁵³.

These Azure VMs will enable you to:

• 
  Connect to the Internet to install updates, and access Internet resources in real time.
  
• 
  Remotely managed those using Remote Desktop connections by your computer that is connected to the Internet or your organization network.
  

Note You must be logged on as a member of the Domain Admins group or a member of the Administrators group on each computer to complete the tasks described in this guide. If you cannot complete a task while you are logged on with an account that is a member of the Administrators group, try performing the task while you are logged on with an account that is a member of the Domain Admins group.

• 
  Create snapshots so that you can easily return to a desired configuration for further learning and experimentation.
  

For that purpose, these VMs notably expose one public endpoint for Remote Desktop Protocol (RDP) and another one for remote Windows PowerShell (WinRMHTTPS) as illustrated hereafter.

The EDGE1 VM exposes in addition a public endpoint for HTTPS (HttpsIn).

The integrated test lab consists of:

• 
  A first subnet (10.0.1.0/24) that will expose the test lab resources that require Internet connectivity/endpoint(s). It is separated from a second subnet that hosts the corporate intranet resources. The computer on this subnet is EDGE1.
  
• 
  A second subnet (10.0.2.0/24) that simulates a private intranet. Computers on the Subnet2 subnet are DC1, ADRMS1, ADFS1, and SQL1.
  

Important Note Azure assigns IP addresses dynamically, which may seem inconvenient when you have the habit to set static IP addresses, especially for domain controllers. More specifically, static IP addresses are NOT supported. For more information, see section IP Addressing and DNS⁵⁴ of the MSDN article Guidelines for Deploying Windows Server Active Directory on Windows Azure Virtual Machines.

Within a subnet, the first 3 addresses are reserved and, in the case of Subnet2 above, the first address that is assigned by the Azure DHCP will be 10.0.2.4. However, it is guaranteed that the first address will remain constant, which is not the case for the addresses that belong to the rest of the range. Such a behavior must be taken into account if you want that a specific VM will have the same IP address allocated over the time, which will be the case of our domain controller DC1 that will also host the DNS server for the test lab environment.

For illustration purposes, we have opted to configure the domain litware369.com (LITWARE369). Since the lab depends on you using a unique name for your domain, you will have to choose a domain name of your own. For checking purposes, you can use the domain search capability provided by popular domain name registrars. Alternatively, you can use a subdomain of a domain you already control in lieu of Litware369.com.

Whenever a reference to litware369.com is made in a procedure, it has to be replaced by the DNS domain name of your choice to reflect accordingly the change in naming. Likewise, any reference to LITWARE369 should be substituted by the NETBIOS domain name of your choice.

Furthermore, for the sake of simplicity, the same password “pass@word1” is used throughout the procedures of the above TLGs as well as the ones detailed in this document. This is neither mandatory nor recommended in a real world scenario.

To perform all the tasks in this guide, we will use the LITWARE369 domain Administrator account AzureAdmin for each Windows Server 2012 R2 Azure VM, unless instructed otherwise.

Note When you configure Windows Server 2012 R2, you are required to click Continue or Yes in the User Account Control (UAC) dialog box for some tasks. Several of the configuration tasks require UAC approval. When you are prompted, always click Continue or Yes to authorize these changes. Alternatively, see the Appendix of this guide for instructions about how to set the UAC behavior of the elevation prompt for administrators.

The following five steps must be followed in order to set up the on-premises core infrastructure of our test lab:

1. 
   Deploying the base workloads in Azure.
   
2. 
   Configuring the domain controller.
   
3. 
   Configuring the root Enterprise CA.
   
4. 
   Deploying the database server.
   
5. 
   Deploying the federation server.
   
6. 
   Preparing the Internet-facing computer.
   
7. 
   Deploying the rights management server.