Leverage the Mobile Device Extension for ad rms

Building an evaluation environment

This section guides you through a set of instructions required to build a representative lab environment to evaluate the Mobile Device Extension.

For the sake of simplicity and in order to focus on the key aspects that relate to the Mobile Device Extension deployment, the chosen test topology is a single cluster in a single forest.

The guidance in this lab can also be utilized to deploy the Mobile Device Extension in a production environment, but adjustments to the process will be necessary depending on the target environment’s topology, configuration and state.

It must be noted that this guide not only covers the deployment of the Mobile Device Extension, but also that of AD RMS and its databases, the Active Directory domain, AD FS and other pre-requisite software. When applying this guide to a preexisting environment most of the detailed steps have to be adapted or omitted accordingly.

Beyond the AD RMS cluster with its SQL Server database, the environment includes:

• 
  A single AD FS server integrated with Active Directory for authentication,
  
• 
  A single WAP proxy to publish on the Internet the Mobile Device Extension service endpoints,
  
• 
  A single Active Directory Certificate Services (AD CS) based certification authority to issue the required certificates,
  

The following diagram provides an overview of the overall test lab environment with the software and service components that need to be deployed / configured.

In this environment we have simplified as much as possible the environment to reduce the number of actions needed.

Building an Azure-based lab environment

A challenge in creating a useful lab environment is to enable its reusability and extensibility. Because creating a test lab can represent a significant investment of time and resources, your ability to reuse and extend the work required to create the test lab is important. An ideal test lab environment would enable you to create a basic lab configuration, save that configuration, and then build out multiple test lab scenarios in the future by starting with the base configuration.

For that reason and considering the above objectives, this guide will use for the corporate on-premises infrastructure the Microsoft Test Lab Guides (TLGs) available on Microsoft TechNet to build the lab environment.

The Microsoft Test Lab Guides (TLGs) allow you to get valuable hands-on experience with new products and technologies using a pre-defined and tested methodology that results in a working configuration.

Microsoft Test Lab Guides (TLGs) are a set of documents that step you through the configuration and demonstration of a Microsoft technology or product in a standardized test lab environment, which starts with a common base configuration that mimics a simplified intranet and the Internet. TLGs are designed to be modular, extensible, and stackable to configure complex, multi-product solutions. TLGs make learning about products, technologies, and solutions easier by providing that crucial hands-on, “I built it out myself” experience.

Note For more information, see Test Lab Guides³¹ on Microsoft TechNet.

Moreover, another potential challenge relates to the hardware needed to run such a base configuration that involves several (virtual) machines.

For these reasons and considering the above objectives, this guide will leverage Microsoft Azure environment with Azure-based virtual machines (VM). Consequently, the setup of the on-premises environment for this evaluation of the Mobile Device Extension will be based on the Test Lab Guide: Base Configuration in Azure³². It will also leverage the Test Lab Guide: Deploying an AD RMS Cluster³³.

Finally, to streamline as much as possible the setup of this Azure-based test lab environment, and to test and evaluate the Mobile Device Extension for AD RMS, this guide will also leverage the Microsoft Azure PowerShell and Windows PowerShell cmdlets to configure the required services.

Introducing virtual machines in Azure

Azure Virtual Machines³⁴ provides support for virtual machines (VMs) provisioned from the cloud. At a glance, a VM consists of a piece of infrastructure available to deploy an operating system and an application. Specifically, this includes a persistent operating system (OS) disk, possibly some persistent data disks, and internal/external networking “glue”/connectivity to hold it all together. With these infrastructure ingredients, it enables the creation of a platform where you can take advantage of the reduced cost and ease of deployment offered by Azure.

To mimic an on-premises deployment with a multi-VM workload as needed here, virtual networks are also required. This is where Azure Virtual Networks come into play. Azure Virtual Network³⁵ let you provision and manage virtual networks (VNET) in Azure. A VNET provides the ability to create a logical boundary and place VMs inside it. VNET also provides the capability of connecting Azure Cloud Services³⁶ (VMs, web roles, and worker roles) that are in the same affinity group directly with them.

Note An affinity group is a container where you choose the location (Azure region) where you place your Azure resources. An affinity group represents also a convenient way to designate an Azure data center region with the name of your choice. (As of this writing, Azure Cloud Services can be added to an affinity group only at the time of creation of the service.).

Azure Virtual Network provides control over network topology, including configuration of IP addresses, routing tables and security policies. A VNET has its own private address space. The address space is IPv4 only (but could be extended to IPv6 in a future release).

Note Azure Virtual Network also allows to securely extend on-premises networks into the cloud. With the ability to assign a private address range for its VNET, you can indeed treat it as an extension of your own corporate private network address space by establishing appropriate gates (VPN gateway) between your on-premises corporate private network and virtual network(s) in Microsoft Azure. For that purpose, Azure Virtual Network enables to set up secure site-to-site connectivity between the organization’s corporate VPN gateway and Azure, and then to connect the organization’s on-premises corporate network to the organization’s Azure tenant by using a VPN gateway along with the industry-standard IPsec protocol. 

With such a capability, IT administrators can easily create a logically isolated private environment in Azure, and connect it to the organization’s on-premises IT infrastructure by using a secure VPN tunnel. Once set up, the isolated Azure environment can be viewed as a natural extension of the on-premises corporate network.

To synthetize, Azure Virtual Network allows you to create private network(s) of VMs in your Azure tenant environment that you can assign IP addresses to (and then optionally connect to your data center through a VPN gateway). Using this method, you can seamlessly connect on-premises (virtual) machines to VMs running in your Azure tenant.

The fundamental requirements for deploying AD DS on VM(s) in Azure differ very little from deploying it in VMs (and, to some extent, physical machines) on-premises. For example, if the domain controller that you deploy on VMs are replicas in an existing on-premises corporate domain/forest, then the Azure deployment can largely be treated in the same way as you might treat any other additional AD DS site. That is, subnets must be defined in AD DS, a site created, the subnets linked to that site, and connected to other sites using appropriate site-links. There are, however, a number of differences that are common to all Azure deployments and some that vary according to the specific deployment scenario.

Note For more information, see the Microsoft TechNet articles Install a new Active Directory forest in Windows Azure³⁷ and Guidelines for Deploying Windows Server Active Directory on Windows Azure Virtual Machines³⁸ that cover the fundamental differences and explain in great detail how successfully deploy and operate AD DS in Azure. The former deals with a standalone configuration in the cloud as we will deploy later in this document whereas the latter highlights the requirements for deploying AD in a hybrid scenario in which AD DS is partly deployed on-premises and partly deployed on VMs in Azure.

Understanding the ongoing costs of virtual machines in Azure

Virtual machines in Azure incur an ongoing monetary cost when they are running. This cost is billed against your free trial, MSDN subscription, or paid subscription.

Note For more information about the costs of running Azure virtual machines, see Virtual Machines Pricing Details³⁹ and Azure Pricing Calculator⁴⁰ on the Azure Web site.

To minimize the cost of running the test lab virtual machines, you can do one of the following:

• 
  Create the test lab environment and perform your needed testing and demonstration as quickly as possible. When complete, delete the test lab virtual machines from the VIRTUAL MACHINES page of the Azure management portal.
  
• 
  Shut down your test lab virtual machines into a de-allocated state from the VIRTUAL MACHINES page of the Azure management portal as covered later in this document. However, you should start your virtual machines in a specific order.
  

Signing up for an Azure trial

If you do not already have an Azure account, you can sign up for a free one month trial⁴¹. If you have an MSDN Subscription, see Azure benefit for MSDN subscribers⁴² on the Azure Web site.

Note Once you have completed your trial tenant signup, you will be redirected to the Azure account portal⁴³ and can proceed to the Azure management portal by clicking Portal at the top right corner of your screen.

At this stage, you should have an Azure trial subscription to proceed with the steps in this guide.