Leverage the Mobile Device Extension for ad rms

Deploying the base workloads in Azure

To deploy the base workloads in your Azure subscription, proceed with the following steps:

1. 
   Download the script New-TestLabEnvironment.ps1⁵⁵ and unblock it so that it can comply with the above execution policy and executed in your environment.
   

Note The script New-TestLabEnvironment.ps1 is largely inspired by the sample script Deploy a domain controller and member using Windows Azure Virtual Machines⁵⁶ available on the Microsoft TechNet Script Center⁵⁷.
Note The script Remove-TestLabEnvironment.ps1⁵⁸ enables you to later seamlessly remove the test lab environment from your Azure subscription. Its usage is not covered in this paper since its arguments are almost the same as the ones used by the above script.

2. 
   Open an Azure PowerShell command prompt and navigate to the folder where the above script is located, for example C:\Scripts in our illustration.
   
3. 
   Run the following command to connect to your subscription:
   

PS C:\Scripts> Add-AzureAccount

A Sign in to Windows Azure dialog brings up.

4. 
   Enter your email address and click Continue. You’re redirected to a Sign In page.
   
5. 
   Type the password associated with your account for your Azure (trial) subscription and click Sign in. You should now be connected to your default subscription.
   
6. 
   Run the following command to deploy the base workloads in your subscription:
   

PS C:\Scripts> .\New-TestLabEnvironment.ps1 -ServiceName "mfalab" -Location "North Europe"

7. 
   The script New-TestLabEnvironment.ps1 proceeds with the setup and will prompt you to gather the administrator credentials to use when provisioning the aforementioned VMs. A Windows PowerShell credential required dialog brings up.
   

8. 
   Provide the administrator credentials you want to use. We will use throughout this walkthrough “AzureAdmin” for the username and “pass@word1” for the password.
   

The script New-TestLabEnvironment.ps1 continues with the setup. It executes the following tasks for you:

• 
  Create an affinity group to associate all the workloads to be deployed with.
  

The name of the affinity group is based on the provided service name in the command line, for example “mfalab” in our configuration, with the added suffix "aff”, resulting for example in “mfalabaff” in our configuration.

• 
  Create a cloud service for these workloads.
  

Like with the affinity group name, the name of the cloud service is based on the provided service name in the command line with the added suffix "svc”, for example “mfalabsvc” in our configuration.

• 
  Create an account storage to store the VHDs of the workloads as blobs.
  

The name of the account storage is based on the provided service name in the command line with the added suffix "stor”, for example “mfalabstor” in our configuration.

• 
  Create a VNET for the workloads.
  

The name of the VNET is based on the provided service name in the command line with the added suffix "vnet”, for example “mfalabvnet” in our configuration. The address space is 10.0.0.0/8.

By default, the name of the above Subnet1 is “-subnet1” prefixed by the name of the VNET, for example “mfalabvnet-subnet1” in our configuration. The address space is 10.0.1.0/24 by default.

Likewise, the name of the above Subnet2 is “-subnet2” prefixed by the name of the VNET, for example “mfalabvnet-subnet2” in our configuration. The address space is 10.0.2.0/24 by default.

• 
  Create a DC1 virtual machine of small size based on the latest available Windows Server 2012 R2 image, add a second disk for the AD DS role service, install the AD DS role service, and finally install Active Directory Domain Services (AD DS) to make the DC1 computer a domain controller in Windows Server 2012 R2. This action upgrades the AD DS schema as part of the domain controller creation.
  
• 
  Create a SQL1 virtual machine of medium size based on the latest available Windows Server 2012 R2 image. SQL Server 2012 will be installed later on this machine. This machine will host an SQL Server instance that will be used for the AD RMS deployment on the ADRMS1 machine (see below).
  
• 
  Create a domain-joined ADFS1 virtual machine of small size based on the latest available Windows Server 2012 R2 image, and install the Active Directory Certificates Services (AD CS) role service and install an Enterprise Certification Authority (CA) along with Internet Information Services (IIS). The Active Directory Federation Services (AD FS) role service will be installed later on this machine and referred as to adfs.litware369.com.
  
• 
  Create a domain-joined ADRMS1 virtual machine of small size based on the latest available Windows Server 2012 R2 image, and install Internet Information Services (IIS). The Active Directory Rights Management Services (AD RMS) role service will be installed later on this machine and referred as to adrms.litware369.com.
  
• 
  Create an Internet-facing domain-joined EDGE1 virtual machine of small size based on the latest available Windows Server 2012 R2 image, and install Internet Information Services (IIS). The default web site on this machine will be later referred as to www.litware369.com. As already mentioned, a public endpoint for HTTPS (HttpsIn) is defined for that purpose as part of the script configuration.
  

The script leverages the remote Windows PowerShell capabilities along with the Windows Server automation with Windows PowerShell to setup the above virtual machines.

Note To learn about the Windows PowerShell command line and scripting environment, see the TechNet Script Center⁵⁹.
Note For information about installing, learning, using, and customizing Windows PowerShell, see the Microsoft TechNet article Scripting with Windows PowerShell⁶⁰.
Note For information about what scripts are and how to run them in Windows PowerShell, see the Microsoft TechNet article Running Scripts⁶¹. This article includes basic information about creating scripts and configuring your computer to run scripts.
Note For information on Windows Server Automation with Windows PowerShell, see the eponym Microsoft TechNet article⁶². This article provides references to install and configure the various role services.

If needed to accommodate your own configuration, the script New-TestLabEnvironment.ps1 enables you to customize the VNET and VM details:

PS C:\Scripts> .\New-TestLabEnvironment.ps1 -ServiceName "mfalab" -Location "North Europe" `

-DC1Name "dc1" -DCVMSize "Small" -FQDNDomainName "litware369.com" -NetBIOSDomainName "LITWARE369" `

-ADFS1Name "adfs1" –ADFS1VMSize "Small" `

-ADRMS1Name "adrms1" –ADRMS1VMSize "Small" `

-SQL1Name "sql1" –SQL1VMSize "Small" `

-EDGE1Name "edge1" EDGE1VMSize "ExtraSmall" `

-VNetAddressPrefix "10.0.0.0/8" -Subnet1AddressPrefix "10.0.1.0/24" -Subnet2AddressPrefix "10.0.2.0/24"
At the end of the script, you should have an up and running base configuration that we will leverage in the next steps. The next sections imply that you have in place such an environment.

Furthermore, to externally resolve the adrms.litware369.com, adfs.litware369.com, and www.litware369.com FQDN names and point to the above cloud service in Azure, you will need to create the following CNAME records in your DNS zone (e.g. litware369.com in our configuration) of your domain registrar. The exact method depends on the chosen domain registrar.

You will need to externally resolve these FQDN names for the Web Application Proxy (WAP).

Name	Type	Value	TTL
adrms	CNAME	mfalabsvc.cloudapp.net	3 hours
adfs	CNAME	mfalabsvc.cloudapp.net	3 hours
www	CNAME	mfalabsvc.cloudapp.net	3 hours