Migrating from AD RMS to the Azure
Rights Management service
Overview Technical Article
Microsoft France
Published: January 2015
Version: 1.1a
Author: Philippe Beraud (Microsoft France)
Reviewer/Contributor: Enrique Saggese, Sergey Simakov (Microsoft Corporation)
For the latest information on RMS, please see
www.microsoft.com/rms
Copyright © 2015 Microsoft Corporation. All rights reserved.
Abstract: Some organizations that already have existing on-premises AD RMS deployment in place are
interested in migrating to the Azure Rights Management service due to its lower operational costs to deliver
the service, the ability to better interoperate with other cloud services such as Office 365, and the high
availability.
This document provides information on how to plan an end-to-end migration process from an existing onpremises AD RMS deployment to an Azure Rights Management service tenant while preserving access to
existing protected content.
Any transition to the cloud is a complex process not to be taken lightly if the objective is to provide the end
users with a seamless experience. The planning and processes involved in transitioning from an established
on-premises infrastructure to a cloud environment are indeed a major undertaking for IT.
This document aims at providing an understanding of the end-to-end migration process, the related
procedures for each of the key steps, along with the available tools to make this migration as smooth as
possible. It also highlights the possible options related to the AD RMS deployment architecture and cluster(s)
configuration.
This document is intended for IT professionals and system architects who are interested in understanding
the migrating process for their existing on-premises AD RMS deployment to the Azure Rights Management
service.
Table of Contents
NOTICE ............................................................................................................................................................... 3
FEEDBACKS ......................................................................................................................................................... 3
INTRODUCTION ................................................................................................................................................. 4
OBJECTIVES OF THIS PAPER ..................................................................................................................................................... 5
NON-OBJECTIVES OF THIS PAPER ........................................................................................................................................... 6
ORGANIZATION OF THIS PAPER .............................................................................................................................................. 6
ABOUT THE AUDIENCE ............................................................................................................................................................. 6
UNDERSTANDING THE END TO END MIGRATION PROCESS ..................................................................... 7
MAKING THE HIGH LEVEL PLAN FOR THE MIGRATION .......................................................................................................... 7
REVIEWING THE PRE-REQUISITES FOR THE MIGRATION........................................................................................................ 8
UNDERSTANDING THE LIMITATIONS FOR THE MIGRATION ................................................................................................ 10
DOWNLOADING THE MIGRATION TOOLING AND DOCUMENTATION ................................................. 11
DOWNLOADING THE RIGHTS MANAGEMENT ADMINISTRATION CMDLETS ..................................................................... 11
DOWNLOADING THE BYOK TOOLSET ................................................................................................................................. 12
EXPORTING CONFIGURATION DATA FROM AD RMS ............................................................................... 13
EXPORTING ACTIVE AND ARCHIVED TRUSTED PUBLISHING DOMAINS ............................................................................ 13
PROVISIONING AN AZURE RIGHTS MANAGEMENT SERVICE TENANT ................................................. 17
CREATING THE AZURE RIGHTS MANAGEMENT SERVICE TENANT ..................................................................................... 17
CONFIGURING THE AZURE RIGHTS MANAGEMENT SERVICE TENANT .............................................................................. 18
MIGRATING ON-PREMISES KEY AND POLICIES TO THE AZURE RIGHTS MANAGEMENT SERVICE ... 20
PREPARING AN INTERNET-CONNECTED WORKSTATION TO DO THE IMPORT .................................................................. 20
IMPORTING THE TPD INTO THE AZURE RIGHTS MANAGEMENT SERVICE TENANT......................................................... 22
UNDERSTANDING THE PROCESSING OF THE TPD IMPORTS IN THE AZURE RIGHTS MANAGEMENT SERVICE ............. 38
ACTIVATING THE AZURE RIGHTS MANAGEMENT SERVICE TENANT.................................................................................. 40
RECONFIGURING THE RIGHTS-ENABLED COMPUTERS AND DEVICES .................................................. 41
RECONFIGURING THE RICH CLIENTS ..................................................................................................................................... 41
RECONFIGURING THE MOBILE DEVICES BASED ON THE REST CLIENTS ............................................................................ 43
RECONFIGURING EXISTING ON-PREMISES WORKLOADS ........................................................................ 45
DEPLOYING THE RIGHTS MANAGEMENT CONNECTOR ON-PREMISES ............................................................................. 46
RECONFIGURING EXCHANGE SERVER WORKLOADS TO USE THE CONNECTOR................................................................ 46
RECONFIGURING SHAREPOINT SERVER WORKLOADS TO USE THE CONNECTOR ............................................................ 50
RECONFIGURING FILE SERVERS FOR FCI TO USE THE RMS CONNECTOR ........................................................................ 53
DE-PROVISIONING THE ON-PREMISES AD RMS INFRASTRUCTURE ...................................................... 55
RENEWING KEYS AFTER MIGRATION IS COMPLETE ................................................................................. 56
2
Migrating from AD RMS to the Azure Rights Management service
Notice
This paper is provided as part of the AZURE RMS MIGRATION GUIDANCE1 resources on the Microsoft Download
Center. For the latest information that pertains the migration as covered in this document, please refer to
the Microsoft TechNet article MIGRATING FROM AD RMS TO AZURE RIGHTS MANAGEMENT2.
This article constitutes the reference article on this capability.
Feedbacks
For any feedback or comment regarding this document, please send a mail to AskIPteam@microsoft.com.
1
AZURE RMS MIGRATION GUIDANCE: http://www.microsoft.com/en-us/download/details.aspx?id=45505
2
MIGRATING FROM AD RMS TO AZURE RIGHTS MANAGEMENT: https://technet.microsoft.com/en-us/library/dn858447.aspx
3
Migrating from AD RMS to the Azure Rights Management service
Introduction
First shipped in Windows Server 2003 timeframe as Windows Rights Management Services (WRMS), Active
Directory Right Management Services (AD RMS)3 is, in the latest release of Windows Server, a server role
designed to help organizations protect their digital information - such as confidential email messages,
financial reports, product specifications, customer data, etc. - from unauthorized use, both online and offline,
inside and outside of the organization’s boundaries through persistent encryptions and usage policies (also
known as usage rights and conditions).
With Rights Management Services, the usage policies remain with the information no matter where it goes,
even while in transport, rather than the rights merely residing on an organization’s corporate network. This
also enables usage rights to be enforced after the information is accessed by an authorized recipient, both
online and offline, inside and outside of the organization.
Over the last two years, this technology has become available a Software-as-a-Service (SaaS) solution in the
Cloud with additional features. The resulting Azure Rights Management service is primary focused on
organizations that do not have existing on-premises AD RMS infrastructure.
Note
For an overview of Azure Rights Management service, see the whitepaper MICROSOFT RIGHTS
MANAGEMENT SERVICES4, the online documentation5 on Microsoft TechNet, the series of whitepapers6 on RMS to which
the current document belong as well as the posts on the RMS Team blog7.
As a highly scalable and available cloud-based solution run by Microsoft in data centers strategically located
around the world that can be subscribed and activated in a couple of minutes, the Azure Rights Management
service:
3

Provides the ability to enable the use of rights management technology for those organizations
who choose to subscribe to Microsoft Office 365 Enterprise: Exchange Online, SharePoint Online,
and Microsoft Office 365 ProPlus.

Helps providing an alternative to a full on-premises deployment of AD RMS via the Rights
Management connector to interact with existing on-premises Exchange Server, SharePoint Server
servers, and File Classification Infrastructure (FCI) deployments,

Enables organizations of any size to minimize the effort required to implement an effective
Information Protection and Control strategy to support the collaboration inside and outside of the
organization’s boundaries,

Works with any document type and all the common devices seen in IT environments.
Microsoft Active Directory Right Management Services (AD RMS): http://go.microsoft.com/fwlink/?LinkId=84726
MICROSOFT RIGHTS MANAGEMENT SERVICES: http://blogs.technet.com/b/rms/archive/2013/07/31/the-new-microsoft-rightsmanagement-services-whitepaper.aspx
4
5
Microsoft Rights Management services: http://www.microsoft.com/rms
6
Microsoft Rights Management service (RMS) whitepapers: http://www.microsoft.com/en-us/download/details.aspx?id=40333
7
RMS Team blog: http://blogs.technet.com/b/rms
4
Migrating from AD RMS to the Azure Rights Management service
Similarly to AD RMS, the Azure Rights Management service (Azure RMS) is built to work in conjunction with
RMS-enlightened applications, i.e. applications that are enhanced to consume or publish RMS-protected
files such as Microsoft Word, Excel and PowerPoint, Foxit Enterprise Reader8, SECUDE End-to-End
Information Security for SAP9, etc. to name a few. These applications offer data protection and rights
enforcement capabilities by leveraging the RMS clients and Software Development Kits (SDK) that are
available on the most important platforms: Windows and Mac OS X computers, Windows RT and Windows
Phone devices, iOS, and Android devices.
Even though RMS on-premises and in the cloud share many common features and will tend to offer the
same functionality over time – the recently introduced mobile device extension for AD RMS being one
illustration of this trend - some organizations that already have existing on-premises AD RMS infrastructure
in place are interested in migrating to the Azure Rights Management service due to:

Its reduced acquisition cost for many customers that have already purchased other cloud services,

Lower operational costs,

Easier cross-organization collaboration,

The ability to better interoperate with other cloud services to which they are already subscribed or
intend to such as Office 365.
With the competitive global economy every organization is faced with, the productivity imperative with the
ambient credo to “do more with less, with a better agility and time to market”, organizations have no other
choice left than becoming leaner and better focused. This leads IT departments to find new ways of
delivering and operating their infrastructure and systems and, in particular, utilize off-premises public cloud
services as more cost-efficient add-ons to existing IT assets. Such dynamic often results in substituting inhouse on-premises systems with public cloud services when they provide the same functionality or more at
a lower cost.
The migration to the Azure Rights Management service is a move that aligns with this strategy.
Objectives of this paper
This document provides information on how to plan end-to-end migration process from an existing onpremises AD RMS or WRMS deployment to the Azure Rights Management service while preserving access
to existing content.
Any transition to the cloud is a process that cannot be taken lightly if the objective is to provide end users
with a seamless experience. The planning and processes involved in transitioning from an established onpremises infrastructure to a cloud environment are indeed a major undertaking for IT.
This document aims at helping smoothing the whole migration process for organizations of any size by
highlighting and discussing each of the required steps for such a transition to the cloud. This document also
presents in this context the tooling that is available to support the migration.
8
Foxit Enterprise Reader with the RMS Plug-in Module: http://www.foxitsoftware.com/landingpage/2012/07/Reader-Ads-RMS/
SECUDE End-to-End Information Security for SAP: http://www.secude.com/company/partners/end-to-end-information-security-forsap/
9
5
Migrating from AD RMS to the Azure Rights Management service
Non-objectives of this paper
This document does not provide a full description of AD RMS. It focuses on the important technical topics
in the context of the migration to the Azure Rights Management service.
Note
For additional information on AD RMS, see the Microsoft TechNet article ACTIVE DIRECTORY RIGHTS
MANAGEMENT SERVICES OVERVIEW10, as well as the several posts of the AD RMS Team Blog11.
It does not provide neither guidance for setting up and configuring AD RMS in a production environment
nor a complete technical reference for AD RMS.
This document does not offer a full description of the Azure Rights Management service either. It aims at
providing the readers with an understanding of the key concepts of interest in the context of the migration.
Organization of this paper
To cover the aforementioned objectives, this document is organized in accordance to the steps required for
migration to the Azure Rights Management service, starting by a high-level overview of the end-to-end
process, its pre-requisites and implications, and then drills down in the required step-by-step processes.
About the audience
This document is intended for IT professionals and system architects who are interested in understanding
the migrating process for their existing on-premises AD RMS infrastructure to the Azure Rights Management
service and how to leverage the available tooling for that purpose.
10
ACTIVE DIRECTORY RIGHTS MANAGEMENT SERVICES OVERVIEW: http://go.microsoft.com/fwlink/?LinkId=84726
11
AD RMS Team Blog: http://blogs.technet.com/b/rms/
6
Migrating from AD RMS to the Azure Rights Management service
Understanding the end to end migration
process
Making the high level plan for the migration
In order to get the best of the Azure Rights Management service offerings as part of the transition, you need
to plan the migration to this service carefully for which you need to understand all the steps required by the
migration process and their limitations and/or implications if any.
The end-to-end migration is a ten step process as summarized below:
1.
Downloading the Azure RMS Migration tooling and documentation.
2.
Exporting configuration data from AD RMS.
3.
Provisioning an Azure Rights Management service tenant for your organization.
4.
Migrating on-premises keys and policies to your Azure Rights Management service tenant.
5.
Activating your Azure RMS tenant.
6.
Removing existing Service Connection Point (SCP) and, is AD RMS mobile device extension was
used, DNS-based service discovery registrations.
7.
Reconfiguring the rights-enabled computers and devices to use Azure RMS.
8.
Reconfiguring existing on-premises server workloads (Exchange Server, SharePoint Server, and FCI)
to use the Azure Rights Management service via the Rights Management connector.
9.
Decommissioning the on-premises AD RMS infrastructure once migration is finished.
10. Optionally, renewing keys after migration is complete.
This document will guide you through these steps to equip you with all the necessary materials to
successfully plan the migration and conduct the migration.
At the end of the migration process:
7

Your RMS-compatible clients can transparently consume -protected content created in AD RMS
using your Azure Rights Management service tenant.

Your RMS-compatible clients can protect/consume new content using your Azure Rights
Management service tenant.
Migrating from AD RMS to the Azure Rights Management service
Reviewing the pre-requisites for the migration
Azure Rights Management tenant
Even though the Azure Rights Management service is much easier to deploy and use than previous solutions
for Information (Rights) Protection (IRM), you still need to meet certain pre-requisites and follow certain
steps in order. In particular, in the context of the migration, you need to plan to:

Create your tenant. You need to provision an Azure Rights Management service tenant for your
organization, either as part of an Office 365 tenant or a stand-alone Azure RMS tenant.

Configure your tenant. This includes enabling the Azure Rights Management service in your tenant,
setting up directory synchronization and/or federation to make your users experience seamless,
optionally configuring the logging service to receive near real-time usage logs from Azure Rights
Management service, etc.
Note
For additional information on directory synchronization and/or federation, please refer to the
Microsoft TechNet online documentation and/or the series of whitepapers ACTIVE DIRECTORY FROM ON-PREMISES TO THE
CLOUD12.
Supported AD RMS and Windows RMS configurations
All releases of AD RMS in Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, and
Windows Server 2012 R2 are directly supported by the Azure RMS migration toolkit.
More particularly, the available migrations tools run on the following environments:

Windows Server 2008 x86 or x64 AD RMS servers.

Windows Server 2008 R2 x64 AD RMS servers.

Windows Server 2012 x64 AD RMS servers.

Windows Server 2012 R2 x64 AD RMS servers.
Some organizations are still running Windows RMS server (a.k.a. RMS v1, based on Windows Server 2003),
which will reach the end of its support lifecycle during 2015. You can migrate your keys and policies from a
Windows RMS server to Azure RMS, but if performed after the end of the support lifecycle for Windows
server 2003, the process will not be directly supported by Microsoft. So you may need to import your trusted
publishing domain (TPD) into a supported AD RMS server and then re-export it without the RMS 1.0
compatibility option so it can be properly supported.
Note
For information on trusted publishing domains (TPD), see the eponym Microsoft TechNet article
TRUSTED PUBLISHING DOMAIN13.
12
ACTIVE DIRECTORY FROM ON-PREMISES TO THE CLOUD: http://www.microsoft.com/en-us/download/details.aspx?id=36391
13
TRUSTED PUBLISHING DOMAIN: http://technet.microsoft.com/en-us/library/dd996639(v=ws.10).aspx
8
Migrating from AD RMS to the Azure Rights Management service
Furthermore, organizations may be storing on-premises keys in four different modes:
1.
Password-protected in the AD RMS database whether it is the Windows Internal database or
database hosted by a full-pledged SQL Server instance,
2.
In a Thales nShield Hardware Security Module (HSM) 14,
3.
In a Hardware Security Module from a different supplier,
4.
In a software-based external cryptographic provider.
The reason why Thales nShield Hardware Security Modules are singled out is because the Azure RMS
platform utilizes these Hardware Security Modules internally, so if the key is in one of these HSMs in your
infrastructure, the migration of the keys can be done directly, just as it can if the key is password-protected
in your RMS database. If using a software-based CSP or a different type of HSM, you will need to extract the
key from its container first and place it into a file in PKCS#12 format for the tooling to be able to import it
into Azure RMS.
On-premises RMS supports two different RSA key lengths for its root keys: "Cryptographic Mode 1” uses
1024 bit long RSA keys, while “Cryptographic Mode 2” uses 2048 bit long RSA keys. Even though Azure RMS
supports creating tenants only in Cryptographic Mode 2 keys, if your RMS infrastructure is using 1024-bit
keys you will be able to import your Mode 1 keys. It is recommended though that you upgrade your clusters
to Mode 2 before the migration so you ensure you are not protecting content with 1024-bit long keys once
in the cloud. This requires a version upgrade if you are running your RMS infrastructure on Windows Server
2008.
Note
For information on upgrading between versions of AD RMS see the RMS TO AD RMS MIGRATION AND
UPGRADE GUIDE15.
If you decide to migrate to the cloud your Mode 1 keys, it is recommended that after the migration you
create a new Mode 2 keys and make it the active key in Azure RMS by following the Bring your own Key
process, to ensure only Mode 2 keys are actively used once you are in the cloud.
Note
For additional information on Cryptographic Mode 2, please refer to the Microsoft TechNet article
ACTIVE DIRECTORY RIGHTS MANAGEMENT SERVICE CRYPTOGRAPHIC MODES16 and the post AD RMS AND CRYPTOGRAPHIC SUPPORT
FOR SHA-2/RSA 204817 on the RMS Team blog.
Supported on-premises topologies and configurations
While IT departments have deployed AD RMS in a large number of possible topologies - combining multiple
clusters of different types, with different trusts – to accommodate requirements that vary significantly from
one organization to another, the migration process provides support for the most common topologies used
Thales Hardware Security Modules: http://www.thales-esecurity.com/products-and-services/products-and-services/hardwaresecurity-modules
14
15
RMS TO AD RMS MIGRATION AND UPGRADE GUIDE: http://technet.microsoft.com/en-us/library/cc754277(v=ws.10).aspx
16
ACTIVE DIRECTORY RIGHTS MANAGEMENT SERVICE CRYPTOGRAPHIC MODES: http://go.microsoft.com/fwlink/p/?LinkID=241989
AD RMS AND CRYPTOGRAPHIC SUPPORT FOR SHA-2/RSA 2048: http://blogs.technet.com/b/rms/archive/2012/04/29/ad-rms-andcryptographic-support-for-sha-2-rsa-2048.aspx
17
9
Migrating from AD RMS to the Azure Rights Management service
by organizations of all sizes. Special considerations may be required for organizations that have
implemented topologies not covered in this guide.
Understanding the limitations for the migration
Exchange Online currently does not support RMS instances on-premises or in the cloud using HSMbased keys.
The migration tool supports converting Password-protected keys into HSM-based keys in the cloud if
desired. This option should not be utilized if IRM integration in Exchange Online is desired until Exchange
Online offers support for HSM-based keys. If already using HSM-based keys in AD RMS, you will not be able
to enable Exchange Online IRM integration for the previously existing content. Though if you import your
keys without designating them as Active, newly protected content will be protected using software-based
keys, and Exchange Online will support IRM integration for this content.
After the migration, clients that are not compatible with Azure RMS will not be able to consume or
protect content with RMS.
At the time of this writing, this includes Mac computers running Office 2011, Windows Phone devices that
need to consume protected Office documents and Windows Mobile devices, as well as some third party
software designed for AD RMS but not for Azure RMS. It is recommended that you check the online Azure
RMS documentation to find out the current list of supported applications at the time of your migration.
After the migration, external partners with which you collaborate on protected content may not be
able to access previously protected content without making specific client configuration changes.
Content protected before your migration will contain the URLs pointing to your original AD RMS platform.
While after following the migration steps indicated in this document you will have configured your internal
clients to automatically redirect their requests to your cloud-based infrastructure, your partners may need
to make the similar changes on their computers to access content protected before the migration.
Note
For additional information, see section § IMPORTING THE TPD INTO THE AZURE RIGHTS MANAGEMENT SERVICE
later in this document, as well as the whitepaper Information Protection and Control (IPC) in Microsoft
Exchange Online with AD RMS18.
TENANT
INFORMATION PROTECTION AND CONTROL (IPC) IN MICROSOFT EXCHANGE ONLINE WITH AD RMS: http://www.microsoft.com/enus/download/details.aspx?id=30139
18
10
Migrating from AD RMS to the Azure Rights Management service
Downloading the migration tooling and
documentation
You must start by downloading the Azure RMS Migration toolkit and supporting scripts.
To complete the migration you will also need to download:
1.
The
Azure
Rights
Management
Administration
tool
from
http://go.microsoft.com/fwlink/?LinkId=257721. This requires at least .Net Framework 4.0 and
Online Services Sign-In Assistant installed.
2.
Supporting RMS client configuration scripts from http://go.microsoft.com/fwlink/?LinkID=524619.
3.
The Bring-Your-Own-Key (BYOK) toolset (if
http://go.microsoft.com/fwlink/?LinkId=335781.
HSM-protected
keys
are
used)
from
The next sections depict the steps.
Downloading the Rights Management administration cmdlets
The Azure Rights Management Administration tool contains the Azure Rights Management administration
module for Windows PowerShell, a set of Windows PowerShell cmdlets19 that provide administrative
(advanced) capabilities for the Azure Rights Management service.
Note
Windows PowerShell is a task-based command-line shell and scripting language that is designed for
system/service administration and automation. It uses administrative tasks called cmdlets. Each cmdlet has required
and optional arguments, called parameters, that identify which objects to act on or control how the cmdlet performs
its task. You can combine cmdlets in scripts to perform complex functions that give you more control and help you
automate the administration of Windows, applications and services in the Cloud. It has become a common way to
manage the latest generation of Microsoft products and services.
For more information about Windows PowerShell, please see the Windows PowerShell Web site20, the Windows
PowerShell online help21, and the Windows PowerShell Weblog22 Windows PowerShell Software Development Kit
(SDK)23 that includes a programmer’s guide along with a full reference.
You will need these cmdlets on an on-going basis to manage the organization’s Azure Rights Management
service tenant, so this is a good time to get this done with.
19
WINDOWS AZURE RIGHTS MANAGEMENT CMDLETS: http://msdn.microsoft.com/library/windowsazure/dn629398.aspx
20
Windows PowerShell Web site: http://www.microsoft.com/powershell
21
Windows PowerShell online help: http://technet.microsoft.com/en-us/library/bb978526.aspx
22
Windows PowerShell Weblog: http://blogs.msdn.com/powershell
23
Windows PowerShell SDK: http://msdn2.microsoft.com/en-us/library/aa830112.aspx
11
Migrating from AD RMS to the Azure Rights Management service
To download the Rights Management administration cmdlets, proceed with the following steps:
1.
Open a browsing session and navigate to the following link: Azure Rights Management
Administration Tool24 click Download.
2.
In the Choose the download you want page, select the appropriate version
(WindowsAzureADRightsManagementAdministration_x64.exe
for
64
bit
or
WindowsAzureADRightsManagementAdministration_x86.exe for 32 bit) and save it locally.
This toolset includes a cmdlet named Import-AadrmTPD that will be used as part of the migration
process.
3.
Copy the .exe file to a USB drive or other portable storage, for example the E: drive in our illustration.
Also, copy offline the Microsoft .NET Framework 4.025 if it is not installed on the computer.
You will need to install this by plugging the USB drive on an Internet-connected workstation as discussed
later in this document.
Downloading the BYOK toolset
Note that you only need the BYOK toolset if HSM-protected keys are used. To download the BYOK toolset,
proceed with the following steps:
1.
Open a browsing session and download the BYOK toolset26 from the Microsoft Download Center.
This toolset includes a command line executable named KeyTransferRemote.exe and associated
DLLs that will used in the next steps. It also contains package files for regions supported by Azure
RMS.
2.
Copy the toolset content to a USB drive or other portable storage, for example the E: drive in our
illustration. Also, copy offline the Microsoft .NET Framework 4.527 if it is not installed on the
computer.
You will need to install this by plugging the USB drive on a disconnected workstation as discussed later in
this document.
24
Azure Rights Management Administration Tool: http://go.microsoft.com/fwlink/?LinkId=257721
25
Microsoft .NET Framework 4.0: http://www.microsoft.com/en-us/download/confirmation.aspx?id=42642
26
BYOK Toolset: http://go.microsoft.com/fwlink/?LinkId=335781
27
Microsoft .NET Framework 4.5: http://www.microsoft.com/en-us/download/confirmation.aspx?id=42642
12
Migrating from AD RMS to the Azure Rights Management service
Exporting configuration data from AD RMS
If your organization has AD RMS deployed in multiple forests, you may need to perform exporting more
than once. Keep in mind that you only need to perform this process for AD RMS clusters that have been
used to protect content, i.e. clusters used for licensing and not only for certification. You will import the keys
of all the clusters that have been used to protect content and marked one of them as active. This key will be
used to protect all new content. All the other keys will be archived and used to consume previously protected
content. There is currently a limit of 10 keys imported into an Azure RMS tenant.
Exporting active and archived Trusted Publishing Domains
The export process must be repeated for each TPD that needs to be exported on an AD RMS cluster and
each AD RMS cluster that is used for licensing new or old content. If there are multiple TPDs, you can perform
the export as described for each of the TPDs.
When the TPD is exported from an AD RMS cluster, the Server Licensor Certificate (SLC) key will be included
in the TPD package file if AD RMS centrally-managed key is used. If the cluster was using CSP-protected
keys (e.g. a Hardware Security Module is used to protect the keys), the exported TPD only contains SLC and
rights policy templates, and the identifier for the key protected with the CSP.
Note
The SLC28 that is issued to licensing servers grants the right to issue: publishing licenses (PL), end users
licenses (UL), client licensor certificates (CLC), rights policy templates. The SLC that is issued to the root certification
cluster contains the public key of the root certification cluster. The SLC that is issued to a licensing server contains
the public key of the licensing server. For additional information on the user activation, see the post LICENSES AND
CERTIFICATES, AND HOW AD RMS PROTECTS AND CONSUMES DOCUMENTS29 on the AD RMS Team Blog.
Exporting TPDs from on-premises AD RMS cluster
The first step of the cluster’s key data and policies (templates, URLs) migration process consists in exporting
the trusted publishing domain(s) to an XML package file.
Note
For information on trusted publishing domains, see the eponym Microsoft TechNet article TRUSTED
PUBLISHING DOMAIN30.
Perform all steps outlined in this section on an AD RMS cluster that has been used to protect content.
28
UNDERSTANDING AD RMS CERTIFICATES: http://technet.microsoft.com/en-us/library/cc753886.aspx
29
UNDERSTANDING INFORMATION RIGHTS MANAGEMENT: http://technet.microsoft.com/en-us/library/dd638140.aspx
30
TRUSTED PUBLISHING DOMAIN: http://technet.microsoft.com/en-us/library/dd996639(v=ws.10).aspx
13
Migrating from AD RMS to the Azure Rights Management service
Note
For Windows RMS please follow the steps in the Microsoft TechNet article EXPORT SLC, TUD, TPD AND
RMS PRIVATE KEY31.
To export a TPD as an XML package file, proceed as follows:
1.
Log-on to the on-premises AD RMS cluster as a user with AD RMS administration permissions.
2.
Launch Server Manager from the Administrative Tools program group.
3.
Expand Roles\Active Directory Rights Management Services.
4.
From within the MMC snap-in (console), expand the AD RMS cluster server name.
5.
In the console tree, expand Trust Policies and then click Trusted Publishing Domains to select the
TPD that needs to be exported.
6.
In the Results pane, select the certificate for the domain you want to export, in this case the ADRMS
certificate.
7.
In the Actions pane, click Export Trusted Publishing Domain. The Export trusted Publishing
Domain dialog box opens up. A file location, name, and password need to be provided to export
the TPD into the XML file.
MIGRATING FROM WINDOWS RMS TO AD RMS IN A DIFFERENT INFRASTRUCTURE: http://technet.microsoft.com/enus/library/jj835767(v=ws.10).aspx#bkmk_ExportSlcTudTpdRmsPrivateKey
31
14
Migrating from AD RMS to the Azure Rights Management service
8.
In Publishing domain file, type the name of the publishing domain file you are exporting, for
example “Test.xml”, or click Save As to export it to a special location. Make sure you specify the .xml
file name extension.
9.
In Password and Confirm password, type a strong password that will be used to encrypt the trusted
publishing domain file, for example “Pa$$w0rd”. Make note of this password since it will be needed
for the import process. Remember that these password protects the TPD file which contains the root
keys for your cluster. Anyone that gets a hold of this file and the password will have the ability to
decrypt all your data so make sure to use a strong password that is not known by other untrusted
people.
10. Leave Saved trusted publishing domain file in RMS version 1.0 (including version 1.0 SP1 and
1.0 SP2) format unchecked.
Important note
To minimize any confusion, the exported package file will be accepted in the organization’s
Azure Rights Management service tenant either the above checkbox is checked or not.
11. Click Finish to create the trusted publishing domain file.
12. Plug the USB drive (or other portable storage), for example the E: drive in our illustration, copy the
file to an USB drive, and safely remove the USB drive.
15
Migrating from AD RMS to the Azure Rights Management service
Note
The export process and task syntax is described in more detail in the Microsoft TechNet article EXPORT
A TRUSTED PUBLISHING DOMAIN32. This step can also be performed by using Windows PowerShell and the AD RMS
Export-RmsTPD cmdlet. Please refer to the documentation of Export-RmsTPD33 for additional information.
Exporting TPDs from on-premises Windows RMS cluster
Note: You can migrate your keys and policies from a Windows RMS server to Azure RMS, but if performed after
the end of the support lifecycle for Windows server 2003, the process will not be directly supported by Microsoft,
so you may need to import your trusted publishing domain (TPD) into a supported AD RMS server and then reexport it without the RMS 1.0 compatibility option so it can be properly supported.
To export a TPD from Windows RMS:
1.
Log on to Windows RMS Cluster with a user account that is a member of the local Administrators
group.
2.
Open the Global Administration page. To open the Global Administration page, click Start, point
to All Programs, point to Windows RMS, and then click Windows RMS Administration.
3.
Next to the Web site on which you want to add a trusted publishing domain, click Administer RMS
on this Web site.
4.
In the Administration links area, click Trust policies.
5.
In the Trust Policies page, in the Trusted publishing domains area, click Export next to the key
container for this RMS cluster.
The Trusted publishing domain export dialog box appears.
6.
Type the password that will be used to encrypt the trusted publishing domain file.
You will need this password to import this file onto another RMS cluster. The password must be a
strong password.
7.
Enter the password again to confirm that you entered the password you wanted to use.
8.
Type the path and file name to be used for the trusted publishing domain .xml file. Make sure you
specify the .xml file name extension.
9.
Click Export to create the trusted publishing domain file.
10. Plug the USB drive (or other portable storage), copy the file to an USB drive, and safely remove the
USB drive.
32
EXPORT A TRUSTED PUBLISHING DOMAIN: http://technet.microsoft.com/en-us/library/cc731228.aspx
33
EXPORT-RMSTPD: http://technet.microsoft.com/en-us/library/ee617275.aspx
16
Migrating from AD RMS to the Azure Rights Management service
Provisioning an Azure Rights Management
service tenant
In order to enable the migration to the Azure Rights Management service, your company must acquire an
Azure Rights Management service subscription first. During this process, the tenant configuration will be
provisioned with default tenant information in the Azure Rights Management service.
Creating the Azure Rights Management service tenant
You can do this by using one of the following options.
1.
Signing up to a Microsoft Office 365 Enterprise tenant.
2.
Signing up to the Microsoft Rights Management stand-alone service.
-or-
Option 1 - Signing up to a Microsoft Office 365 Enterprise tenant
To sign up to a Microsoft Office 365 Enterprise tenant,
http://www.microsoft.com/office/preview/en/office-365-enterprise.
Note
34
17
follow
For more information, see the article SIGN IN TO OFFICE 36534.
SIGN IN TO OFFICE 365: http://onlinehelp.microsoft.com/en-us/office365-enterprises/ff637600.aspx
Migrating from AD RMS to the Azure Rights Management service
the
instructions
at
Once you have signed up35 and established your organization with an account in Office 365 Enterprise,
enabling the Azure Rights Management service capabilities within the Office 365 Enterprise just takes a few
additional steps to enable and configure for use. See later in this document.
Option 2 - Signing up to the Azure Rights Management stand-alone
service
To sign up to an Azure Rights Management stand-alone service, proceed the sign-up steps described in the
Microsoft TechNet article ACTIVATING AZURE RIGHTS MANAGEMENT36. Please do not activate the Azure RMS
subscription right now.
Configuring the Azure Rights Management service tenant
Once the Azure Rights Management service is created, you must setup Azure Active Directory to work with
the users and groups in the on-premises identity infrastructure such as Active Directory. While it is possible
to use Office 365 with manually created accounts in Azure Active Directory, the use of the Azure Rights
Management service along with the Rights Management connector – as later covered in this document requires that the accounts in Azure Active Directory are synchronized with Active Directory.
Note
For instructions on how to configure your Azure Active Directory tenant, see Microsoft TechNet article
ADMINISTERING YOUR WINDOWS AZURE AD TENANT37.
Note
For instructions on how to enable directory synchronization with Azure Active Directory using DirSync,
see Microsoft TechNet article DIRECTORY SYNCHRONIZATION ROADMAP38.
Optionally enabling federation between your Active Directory and
Azure Active Directory
You have the option of enabling identity federation between your on-premises directory and Azure Active
Directory, which enables a seamless user experience through single sign-on to the Azure Rights
Management service.
35
Office 365 Enterprise E3: http://www.microsoft.com/office/preview/en/office-365-enterprise
36
ACTIVATING AZURE RIGHTS MANAGEMENT: http://technet.microsoft.com/en-us/library/jj658941.aspx
37
ADMINISTERING YOUR WINDOWS AZURE AD TENANT: http://technet.microsoft.com/en-us/library/hh967611.aspx
38
DIRECTORY SYNCHRONIZATION ROADMAP: http://technet.microsoft.com/en-us/library/hh967642.aspx
18
Migrating from AD RMS to the Azure Rights Management service
Note
For instructions on setting up federation with AD FS between Active Directory and Azure Active
Directory, see Microsoft TechNet article CONFIGURE SINGLE SIGN-ON39.
Certain on-premises configurations, such as access to SharePoint 2013 protected libraries from Office 2013
clients, require – once the migration is complete - that federation is enabled.
39
19
CONFIGURE SINGLE SIGN-ON: http://technet.microsoft.com/en-us/library/hh967628.aspx
Migrating from AD RMS to the Azure Rights Management service
Migrating on-premises key and policies to the
Azure Rights Management service
After provisioning an Azure Rights Management service tenant for the organization, you must migrate the
AD RMS cluster’s key data and policies (rights policy templates, URLs) to the organization’s tenant in order
to preserve access to content that has already been protected by this cluster.
This section covers the steps to follow and related tools to use so that you can prepare and upload them.
The on-premises key and policies migration, which is at the heart of the end-to-end migration process, is a
two steps process:
1.
Preparing an Internet-connected workstation to do the import.
2.
Importing the TPD into the provisioned Azure Rights Management service tenant.
The next sections covers in details the required steps, the possible options if any, how to use the dedicated
tools if any, etc.
Preparing an Internet-connected workstation to do the import
To upload the exported TPD(s) and related key over the Internet, an Internet-connected workstation will be
needed. The tools require .Net Framework version 4.5 or newer and Microsoft Online Services Sign-In
Assistant (MOS SIA) 7.2 that provides sign-in capabilities to the Azure Rights Management service.
Note
The MOS SIA is used to authenticate users to the service through a set of dynamic link library files
(DLLs) and a Windows service as described in the community article DESCRIPTION OF MICROSOFT ONLINE SERVICES SIGNIN ASSISTANT (MOS SIA)40.
To install the Microsoft Online Sign-In Assistant (MOS SIA) version 7.2 or later, proceed with the following
steps:
40
1.
Open a browsing session and navigate to the following link Microsoft Online Services Sign-In
Assistant for IT Professionals RTW 41 and click Download.
2.
In the Choose the download you want page, select the appropriate version x64 or x86
(msoidcli_64bit.msi or msoidcli_32bit.msi) regarding the workstation configuration and save it locally.
3.
Double-click the downloaded file. The Microsoft Online Services Sign-in Assistant Setup wizard
opens.
DESCRIPTION OF MICROSOFT ONLINE SERVICES SIGN-IN ASSISTANT (MOS SIA): http://community.office365.com/en-us/w/office/534.aspx
Microsoft Online Services Sign-In Assistant for IT Professionals RTW:
http://www.microsoft.com/download/en/details.aspx?id=41950
41
20
Migrating from AD RMS to the Azure Rights Management service
4.
On the license terms page, select I accept the terms in the License Agreement and Privacy
Statement and click Install. A User Account Control dialog pops up.
5.
In the User Account Control dialog, click Yes to execute the setup.
6.
On the completion page, click Finish.
To install Azure AD Rights Management Administration tool, proceed with the following steps:
Note
Even if you have installed the Azure Rights Management Administration Tool before, please upgrade
to the latest version as it includes new cmdlets that we will need for this procedure. For additional information and
instructions, see the Microsoft TechNet Article INSTALLING WINDOWS POWERSHELL FOR AZURE RIGHTS MANAGEMENT42.
1.
Plug the USB drive (or other portable storage) on your workstation.
2.
Open an elevated command prompt if none, and run the previously downloaded Azure AD Rights
Management Administration tool (WindowsAzureADRightsManagementAdministration_x64.exe or
WindowsAzureADRightsManagementAdministration_x86.exe) from the USB drive, for example E: in
our illustration:
c:\Users\Administrator>E:\WindowsAzureADRightsManagementAdministration_x64.exe
A Microsoft Rights Management Administration Setup wizard opens up.
42
21
INSTALLING WINDOWS POWERSHELL FOR AZURE RIGHTS MANAGEMENT: http://technet.microsoft.com/en-us/library/jj585012.aspx
Migrating from AD RMS to the Azure Rights Management service
1.
On the Welcome page, select the Next option.
2.
On the End-User License Agreement page, select I accept the terms in the License Agreement
and click Next.
3.
On the Ready to Install page, click Install.
4.
On the completion page, click Finish.
Importing the TPD into the Azure Rights Management service
tenant
Once all the TPDs in your organization that have been used to protect content are exported to XML package
files, they can be imported into the organization’s Azure Rights Management service tenant. For that
purpose, IT uploads each TPD and its private key to the organization’s Azure Rights Management service
tenant.
The import of the TPD into the Azure Rights Management service tenant depends on the "nature” of the
TPD, i.e. the keys were centrally managed and password-protected in AD RMS versus CSP-based key (keys
protected with a Hardware Security Module, or software-based external cryptographic provider). The next
sections describe the related steps in accordance.
Importing a TPD that has a password-protected key
If the TPD is based on centrally-managed password-protected key, you have two main options at this stage:
1.
Uploading the TPD with software-based key or
2.
Uploading the TPD with an HSM-protected key:
a.
either directly from HSM key or
b. by converting existing software key to hardware-protected key.
The decision regarding which option to use should be based on the needs of the organization and their plan
to use Office 365 or on premises Exchange servers.
Note. Since as of this writing Exchange Online does not support hardware protected keys, so customers planning
to use this service and expecting information rights management integration in features like OWA or exchange
ActiveSync, should upload their TPD’s as software-based keys. For organizations that plan to use Microsoft
Exchange on premises via the RMS connector, uploading the keys as HSM protected keys should be the best
option.
These two options are further discussed in the next sections.
Option 1 - Uploading TPD with software-based key
You may prefer to continue to use the same SLC key type. The exported TPD will be imported to the
organization’s Azure Rights Management service tenant directly with the new Azure Rights Management
Administration cmdlet Import-AadrmTPD.
22
Migrating from AD RMS to the Azure Rights Management service
This tool supports the following command line syntax to upload the TPD in to the organization’s Azure
Rights Management service tenant:
PS C:\> Import-AadrmTpd -TpdFile <PathToTpdPackageFile> -ProtectionPassword <Password> [-Active] [-Force] [Verbose] [-Confirm] [-WhatIf] [<CommonParameters>]
The table hereafter lists the input parameters for this command line:
Input Parameter Name
Value
Required
-TpdFile
Exported TPD file path. The value can be full file path or relative one
located in current folder.
Yes
-ProtectionPassword
Password used to decrypt the TPD package file and the SLC key blob
inside the TPD. If the password is not given, the tool will prompt user
to type in password and display the password as “****” for giving
password.
Note that this parameter is SecureString, so use $Password = ReadHost -AsSecureString -Prompt “Password:” to acquire it.
Yes
-Active
The flag to indicate the TPD should be imported as active. That is, it can
be used to protect documents. Default is false, but for migration you
want to import the TPD as active, so use true.
No
-Verbose
Verbose reporting. This flag is recommended for migration.
No
To upload the key package, proceed with the following steps:
1.
Plug your USB drive (or other portable storage) onto an Internet-connected computer.
2.
Open an (elevated) Windows PowerShell command prompt, and run the following commands to
connect to the organization’s Azure Rights Management service tenant:
PS C:\Users\Administrator> Connect-AadrmService
Enter the Azure Rights Management service tenant administrator credentials at the prompt.
3.
Upload the TPD from your plugged USB drive or other portable storage with the following
command:
PS C:\Users\Administrator> Import-AadrmTpd -TpdFile <PathToTpdPackageFile> -ProtectionPassword –Active $true –
Verbose
23
Migrating from AD RMS to the Azure Rights Management service
For example:
PS C:\Users\Administrator> Import-AadrmTpd -TpdFile E:\Test.xml –ProtectionPassword –Active $true -Verbose
Important note
This action cannot be undone.
The cmdlet will prompt the following confirmation when "-Force" is not given to avoid unintended action:
Are you sure you want to perform this action?
Performing the operation "Import-AadrmTpd" to import package as active TPD with centrally-managed key.
[Y] Yes [A] Yes to All [N] No [L] No to All [S] Suspend [?] Help (default is "Y"):
Important note
4.
This action cannot be undone.
Press "Y".
When succeeded, the followings are output of results:
FriendlyName
:
CryptoMode
:
Hierarchy
:
KeyProtectionType:
RightsTemplateIds:
Contoso.com
Mode1
Production
Hardware
{GUID1, GUID2, …}
Option 2 - Uploading TPD with HSM-protected key
You may prefer instead to convert the SLC key from centrally-managed password-protected one to HSMprotected SLC-key if your organization requires higher security, wish to comply with best practices and
security standards, and you want to ensure that there is no single point of compromise within the key
management environment.
Note
At the moment of this writing this option will not be compatible with the current implementation of
Exchange Online, which only supports software-based keys in Azure RMS.
Azure RMS internally uses Thales nShield Hardware Security Modules to protect its keys, so importing a key
through a compatible HSM is somewhat simpler than importing keys protected with other mechanisms.
When using an HSM to perform the import of the keys into the cloud, you can assure that custody of the
key is maintained according to the strictest industry best practices without breaking the budget. Since the
HSM will only be utilized for key import operations and not for any active cryptographic load, a low-end
HSM is a valid option for this process as no particular performance characteristics are required, so an
organization can take advantage of affordable USB connected HSMs such as the nShield Edge43.
This type of device combines a full-featured HSM with a smart card reader, which you can use to securely
store and access your organization’s high-value occasional-use keys. The nShield Edge device has been
designed and tested for deployments where one device is used with one workstation or virtual machine
(VM).
Thales nShield Edge: http://www.thales-esecurity.com/products-and-services/products-and-services/hardware-securitymodules/general-purpose-hsms/nshield-edge
43
24
Migrating from AD RMS to the Azure Rights Management service
You will have to import the key material in an on-premises Thales HSM provisioned for the circumstances.
Thales e-Security provides industry proven, FIPS compliant44 HSMs45.
For that purpose, the command-line tool KeyTransferRemote.exe - available as part of the Bring Your Own
Key (BYOK) package for RMS - enables you to extract the encrypted SLC key from the exported TPD XML
package file and import it to the Thales HSM. Once the command completes, and as further later described,
the now Thales-based SLC key is exported in a HSM key file, and a keyless TDP is then created.
The new Azure Rights Management Administration cmdlet Import-AadrmTPD is then used to upload the
HSM key along with the keyless TPD to the organization’s service tenant.
Preparing a disconnected workstation with a Thales HSM
To upload TPD with HSM-protected key, a disconnected secure workstation is needed in addition to previous
the Internet-connected workstation. The disconnected workstation will be used in conjunction with a
compatible Thales HSM.
You should follow on a disconnected secure workstation the instructions highlighted in the eponym section
of the Microsoft TechNet article PLANNING AND OPERATIONS FOR YOUR WINDOWS AZURE RIGHTS MANAGEMENT
TENANT KEY46 and the whitepaper BRING YOUR OWN KEY (BYOK) WITH AZURE RIGHTS MANAGEMENT47 for:

Installing the nCipher (Thales) support software on a Windows computer, and then attach a Thales
HSM to that computer.
Note
Please make sure that you have the latest Thales support software installed on the computer, version
11.62 or newer.

Creating a "Security World" by running the Thales new-world.exe program.

Installing the Thales CNG provider with the Thales cngregister.exe program as described in the Thales
documentation and point it to the new Security World.
Note
Thales nShield HSMs use a common key management framework: the Thales’ Security World. Thales’
security world framework delivers cryptographic key management features that can scale, are robust and are
flexible enough to handle real-world deployments. This powerful solution gives the ability to handle an unlimited
number of keys and provides the functions necessary to manage keys throughout the entire key lifecycle from
creation to operational use, back-up, recovery, archival and finally destruction. Security World delivers a common
set of features across all Thales nShield HSMs: security, scalability, fine grained control of key usage, and resilience.
For more information, see the user guide included with the Thales HSM, or visit the Thales website for Azure Rights
Management service48.
Perform all the above steps on a disconnected workstation.
44
Thales nShield HSMs Certifications: http://www.thales-esecurity.com/company/certifications
45
Thales nShield HSMs: http://www.thales-esecurity.com/products-and-services/products-and-services/hardware-security-modules
PLANNING AND OPERATIONS FOR YOUR WINDOWS AZURE RIGHTS MANAGEMENT TENANT KEY: http://technet.microsoft.com/enus/library/dn440580.aspx#BKMK_DisconnectedPrepareWorkstation
46
47
BRING YOUR OWN KEY (BYOK) WITH AZURE RIGHTS MANAGEMENT: http://www.microsoft.com/en-us/download/details.aspx?id=40333
48
Thales website for Azure Rights Management service: http://www.thales-esecurity.com/msrms/cloud
25
Migrating from AD RMS to the Azure Rights Management service
By using Thales’ Security World, the root of trust belongs to the entity, e.g. the organization who
owns the Security World. This ownership is instantiated technically in several system objects:

The Security World master keys. AES 256 keys randomly generated by the HSM upon creation of
the Security World.

The World File. A disk file that contains strongly encrypted key tokens for all of the Security World
infrastructure keys.

The Administrative Card Set (ACS). A set of smart cards that contains the tokens that allow an
nShield to load the infrastructure keys. The ACS tokens are split with a K of N scheme.
During this initialization step, you will be prompted to enter blank cards and pins for each. These cards will
become the Administrator Card Set (ACS) for the new security world. Administrator card sets are crucial:
an unusable card set will render the security world unusable, therefore all keys protected by that
security world would become unusable as well.
Each card set consists in a number of smart cards N, for example 3, of which a smaller number K, 2 for
example, is required to authorize an action. The required number K is usually referred as the quorum.
Note
As illustrated in the example below, the value for K should be less than N. We do NOT recommend
creating card sets in which K is equal to N in so far as an error encountered on one card would render the whole
card set unusable. If your ACS became unusable through such an error, you would have to replace the Security
World and generate new keys.
In many cases, it is desirable to make K greater than half the value of N (for example, if N is 7, to make K 4 or
more). Such a policy makes it harder for a potential attacker to obtain enough cards to access the Security World.
Choose values of K and N that are appropriate to your situation.
The total number of cards used in the ACS must be a value in the range 1 – 64.
It is advised to clearly identify the card set with stickers indicating for each smartcard, its id, the security
officer it belongs to and any additional information you may consider useful in your own specific situation.
Note
You can use Thales’ nkminfo utility to get information about the Security World, keys, and card sets.
Installing the BYOK toolset on the disconnected workstation
Perform all steps in this section on your disconnected workstation.
To install the BYOK toolset, proceed with the following steps:
1.
Plug the USB drive (or other portable storage) on your workstation, for example the E: drive in our
illustration.
2.
Copy the previously downloaded BYOK toolset from the USB drive into any folder on the
workstation, for example C:\Program Files\BYOK_TOOLSET in our illustration. Open a command
prompt ant run the following commands:
c:\Users\Administrator>cd %ProgramFiles%
c:\Program Files>mkdir BYOK_TOOLSET
c:\Program Files>robocopy /mir E:\ "%ProgramFiles"
The USB drive correspond to the E: drive letter in our illustration. Adapt the command to reflect your
current configuration.
3.
26
From the previous folder, run vcredist_x64.exe to install the Visual C++ runtime components for
Migrating from AD RMS to the Azure Rights Management service
Visual Studio 2012. A Microsoft Visual C++ 2012 Redistributable (x64) opens up. Click I agree
to the license terms and conditions, and then click Install. Click Close to finish setup.
4.
If .Net Framework version 4.5 or newer is not installed on the computer, please setup it from the
USB drive.
Converting the software SLC key to a Thales HSM-protected key (software keys only)
Note: This section only applies to software SLC keys that you want to convert to HSM keys before upload to Azure
RMS. You can skip it for ADRMS originally created in HSM.
As mentioned before, the command-line tool KeyTransferRemote.exe enables to extract the encrypted SLC
key from exported password-protected TPD XML package file and import it to Thales HSM on-premises.
The tool takes in the TPD exported from an AD RMS cluster, decrypt the TPD XML package file, extract out
key blob, convert the blob to suitable object and import on that basis the key to the Thales HSM.
After importing successfully, it also strips the key blob from original TPD package and save it to different file
for the Azure Rights Management Administration cmdlet to upload.
This tool supports the above process to import CAPI key with the following command line:
PS C:\> KeyTransferRemote.exe -ImportRmsCentrallyManagedKey –TpdFilePath <TPD> -ProtectionPassword <password>
-KeyIdentifier <KID> -ExchangeKeyPackage <keypackage> -Verbose -Trace
The table hereafter lists the input parameters for this command line:
Input Parameter Name
Value
Required
-ImportRmsCentrallyManagedKey
Indicate the operation is for importing the SLC key.
Yes
-TpdFilePath
Previously exported TPD XML package file path that contains
the AD RMS SLC CAPI key.
Yes
-ProtectionPassword
Password used for encrypting TPD. If the password is not
given, the tool will prompt user to type in password and
display the password as “****” for giving password.
Note that this is SecureString, so please use Read-Host AsSecureString to acquire it in the script.
No
-KeyIdentifier
Key identifier or key friendly name, for example
“contosormskey”. It is used for composing the key file name
(the input characters need to be converted to lower case ASCII ones).
Yes
-ExchangeKeyPackage
Path to the key exchange key (KEK) package.
Yes
-NewSecurityWorldPackage
Path to the region-specific Security World package
-V
Verbose.
No
-T
Trace.
No
The tool proceeds with the following input parameter validation:
27

TPD package file path.

TPD package file can be decrypted with password.

TPD package file can be de-serialized.
Migrating from AD RMS to the Azure Rights Management service


Key Exchange Key Package for your region:

BYOK-KEK-pkg-EU-1 for Europe.

BYOK-KEK-pkg-NA-1 for North America.

BYOK-KEK-pkg-AP-1 for Asia-Pacific.
Thales Security World Package.
Once the above command line completes, the tool generates the following outputs:

HSM key file path such as %NFAST_KMDATA%\local\key_mscapi_<KeyIdentifier>

Altered TPD file path such as %NFAST_KMDATA%\local\no_key_tpd_<KeyIdentifier>.xml. This is a
copy of the exported TDP but without the key: the key blob has been stripped out in this file.
Perform all steps outlined in this section on the disconnected secure workstation prepared in the previous
section.
To import the critical SLC key to the Thales HSM, proceed with the following steps:
1.
Open an elevated command prompt if needed and navigate to the folder where you’ve copied the
BYOK toolset from the USB drive, for example C:\Program Files\BYOK_TOOLSET in our illustration.
2.
From the elevated command prompt, run the following command, replacing test with whatever you
chose as your key identifier. This utility reduces the permissions on the key.
C:\Program Files\BYOK_TOOLSET> KeyTransferRemote.exe -ImportRmsCentrallyManagedKey –TpdFilePath E:\Test.xml ProtectionPassword -KeyIdentifier contosormskey –ExchangeKeyPackage BYOK-KEK-pka-NA-1 –NewSecurityWorldPackage
SecurityWorld
When the command runs, you will be asked to plug in your security world admin cards for the Thales HSM.
When the command completes, you will see "Result: SUCCESS":
This will create in your %NFAST_KMDATA%\local folder:

A copy of your HSM-based key in a file named key_mscapi_contosormskey, replacing contosormskey
at the end of the filename with whatever you chose as your key identifier.

A keyless copy of the input TPD no_key_tpd_contosormskey.xml.
The former key file needs to be re-packaged by following the Bring-Your-Own-Key (BYOK) process before
being uploaded to the organization’s Azure Rights Management service tenant.
The latter output TPD file can be uploaded to the organization’s service tenant directly since it does not
contain key material anymore.
28
Migrating from AD RMS to the Azure Rights Management service
Retrieving your Azure Rights Management service tenant ID
Perform all steps outlined in this section on the Internet-connected workstation.
To retrieve the organization’s Azure Rights Management service tenant ID, proceed with the following steps:
1.
Open an (elevated) Windows PowerShell command prompt, run the following command:
PS C:\Users\Administrator> Connect-AadrmService
You will be prompted for your credentials.
2.
In the Windows PowerShell Credential Request window that opens up, enter your Azure Rights
Management service tenant administrator credentials and wait to be authenticated.
3.
View the current configuration for the tenant by running Get-AadrmConfiguration cmdlet:
PS C:\Users\Administrator> Get-AadrmConfiguration
This will display information about your Azure Rights Management service tenant configuration.
29
Migrating from AD RMS to the Azure Rights Management service
PS C:\Users\Administrator> Get-AadrmConfiguration
BPOSId
: 2971a9f9-454c-4be2-9b86-5b3513ecb22e
RightsManagementServiceId
: 6c8e9100-1168-4085-90f0-22293f9e5a0d
LicensingIntranetDistributionPointUrl
: https://6c8e9100-1168-4085-90f022293f9e5a0d.rms.eu.aadrm.com/_wmcs/licensing
LicensingExtranetDistributionPointUrl
: https://6c8e9100-1168-4085-90f022293f9e5a0d.rms.eu.aadrm.com/_wmcs/licensing
CertificationIntranetDistributionPointUrl : https://6c8e9100-1168-4085-90f0-22293f9e5a0d.rms.eu.aadrm.com/
_wmcs/certification
CertificationExtranetDistributionPointUrl : https://6c8e9100-1168-4085-90f0-22293f9e5a0d.rms.eu.aadrm.com/
_wmcs/certification
AdminConnectionUrl
: https://admin.eu.aadrm.com/admin/admin.svc/Tenants/6c8e9100-11684085-90f022293f9e5a0d
OnPremiseDomainName
:
Keys
: {22327901-6fdd-4dfc-81c7-04a1eb3c1afb}
CurrentLicensorCertificateGuid
: 22327901-6fdd-4dfc-81c7-04a1eb3c1afb
Templates
: {72fb2c43-cc9d-43ba-a02a-3320b2a869be, 9567b5c8-217d-46d2-b52928c3a0d1ca7d}
FunctionalState
: Disabled
SuperUsersEnabled
: Disabled
SuperUsers
: {}
AdminRoleMembers
: {}
KeyRolloverCount
: 0
ProvisioningDate
: 12/20/2013 2:57:14 PM
IPCv3ServiceFunctionalSate
: Enabled
DevicePlatformState
: {Windows -> True, WindowsStore -> True, WindowsPhone -> True,
Mac -> True…}
FciEnabledForConnectorAuthorization
: True
4.
Save the GUID from the first line (BPOSId). This is your Azure Rights Management service tenant ID.
You will need this information in the next steps. Considering the above output, our Azure Rights
Management service tenant ID is in our illustration 2971a9f9-454c-4be2-9b86-5b3513ecb22e.
Re-packaging the Thales HSM-based key
The re-packaging of the Thales HSM-based key is needed at this stage for maintaining security. More
specifically, security is maintained by the following methods:
30

The Thales HSM-based key is encrypted in this step with a Key Exchange Key (KEK), which stays
encrypted until it is transferred to the Azure Rights Management service’s HSMs. Only the encrypted
version of the key will leave the original workstation.

The Key Exchange Key (KEK) that is used to encrypt the key is generated inside the Azure Rights
Management service’s HSMs and is not exportable. The HSMs enforce that there can be no clear
version of the KEK outside the HSMs. In addition, the toolset includes attestation from Thales that
the KEK is not exportable and was generated inside a genuine HSM that was manufactured by
Thales.

Microsoft uses separate KEKs as well as separate security worlds in each geographical region, which
ensures that the key can be used only in data centers in the region in which IT encrypted it. For
example, a tenant key from a European customer cannot be used in data centers in North America
or Asia-Pacific.

The BYOK toolset sets properties on the key that binds the key to the Azure Rights Management
service’s security world. Therefore, after the Azure Rights Management service’s HSMs receive and
decrypt the key, only these HSMs can use it. The organization’s tenant key cannot be exported. This
binding is enforced by the Thales HSMs.

The BYOK toolset includes attestation from Thales that the Azure Rights Management service’s
security world was also generated on a genuine HSM manufactured by Thales. This proves to IT that
Microsoft is using genuine hardware.
Migrating from AD RMS to the Azure Rights Management service
Note
The SLC key can safely move through untrusted computers and networks because it is encrypted and
secured with access control level permissions, which makes it usable only within the organization’s HSMs and
Microsoft’s HSMs for the Azure Rights Management service. IT professionals can use the scripts that are provided
in the BYOK toolset to verify the security measures and read more information about how this works from Thales:
HARDWARE KEY MANAGEMENT IN THE RMS CLOUD49.
Perform all steps outlined in this section on the disconnected secure workstation.
To re-package the Thales HSM-based key, proceed with the following steps:
1.
From the elevated command prompt, run the following command, replacing test with whatever you
chose as your key identifier.
c:\Program Files\BYOK_TOOLSET> KeyTransferRemote.exe -Package -KeyIdentifier test -ExchangeKeyPackage <KEK> NewSecurityWorldPackage <SecurityWorldpackage> -TenantBposId <GUID> -KeyFriendlyName <FirstKeyLabel>
Where:



<KEK> is the Key Exchange Key (KEK) package for your region:

BYOK-KEK-pkg-EU-1 for Europe.

BYOK-KEK-pkg-NA-1 for North America.

BYOK-KEK-pkg-AP-1 for Asia-Pacific.
<SecurityWorldpackage> is the Security World package for your Azure RMS region:

BYOK-SecurityWorld-pkg-EU-1 for Europe.

BYOK-SecurityWorld-pkg-NA-1 for North America.

BYOK-SecurityWorld-pkg-AP-1 for Asia-Pacific.
<GUID> is your Azure Rights Management service tenant ID that you retrieved in previous section,
for example 2971a9f9-454c-4be2-9b86-5b3513ecb22e in our illustration.

<FirstKeyLabel> with a label that will be used for your output file name (see below) and will be
visible on the key properties in Azure RMS after the import.
This correspond to the following command in our illustration:
C:\Program Files\BYOK_TOOLSET>KeyTransferRemote.exe -Package -KeyIdentifier contosormskey -ExchangeKeyPackage
BYOK-KEK-pkg-NA-1 -NewSecurityWorldPackage BYOK-SecurityWorld-pkg-NA-1 -TenantBposId 2971a9f9-454c-4be2-9b865b3513ecb22e -KeyFriendlyName “ContosoRMSKey”
When the command runs, you will be asked to plug in your security world admin cards.
When the command completes, you will see "Result: SUCCESS".
This will create in your %NFAST_KMDATA%\local folder a file called KeyTransferPackage<FirstKeyLabel>.byok, for example KeyTransferPackage-TestFirstkey.byok in our illustration.
HARDWARE KEY MANAGEMENT IN THE RMS CLOUD: https://www.thales-esecurity.com/knowledge-base/white-papers/hardware-keymanagement-in-the-rms-cloud
49
31
Migrating from AD RMS to the Azure Rights Management service
Note
For additional information, see the Microsoft TechNet article PLANNING AND OPERATIONS FOR YOUR
WINDOWS AZURE RIGHTS MANAGEMENT TENANT KEY50 and the whitepaper BRING YOUR OWN KEY (BYOK) WITH AZURE RIGHTS
MANAGEMENT51.
Plug the USB drive on your disconnected workstation and copy the files named KeyTransferPackageTestFirstkey.byok and no_key_tpd_test.xml from %NFAST_KMDATA%\local folder, replacing test at the end
of the filenames with whatever you chose as your key identifier. Safely remove the USB drive.
Importing the keyless TPD and the Thales HSM-based key
As noticed above, the new Azure Rights Management service Admin PowerShell Import-AadrmTPD
enables to import the keyless TPD along with the on-premises HSM key to the organization’s service tenant.
Note
The existing BYOK process uses cmdlet Add-AadrmKey to upload tenant HSM key to cloud service.
To minimize the confusion to users, it stays as it is and is not combined with this new cmdlet here.
This tool supports the following command line syntax:
PS C:\> Import-AadrmTpd -TpdFile <String> -ProtectionPassword <SecureString> -HsmKeyFile <String> [-Active] [Force] [-Verbose] [-Confirm] [-WhatIf] [<CommonParameters>]
The table hereafter lists the input parameters for this command line:
Input Parameter Name
Value
Required
-TpdFile
Keyless TPD file path, such as no_key_tpd_<KeyIdentifier>.xml.
Yes
The value can be full file path or relative one located in current folder.
-ProtectionPassword
Password used to decrypt the TPD package file. If the password is not
given, the tool will prompt user to type in password and display the
password as “****” for giving password.
Yes
Note that this is SecureString, so please use Read-Host -AsSecureString
to acquire it in the script.
-HsmKeyFile
Packaged HSM key, such as KeyTransferPackage-<FirstKeyLabel>.byok.
Yes
The value can be full file path or relative one located in current folder.
-Active
The flag to indicate the keyless TPD should be imported as active.
Default is false.
No
-Verbose
Verbose reporting. This flag is recommended for migration.
No
To import the keyless TPD and the Thales HSM-based key, proceed with the following steps:
50
1.
Plug the USB drive (or other portable storage) on your workstation, for example the E: drive in our
illustration.
2.
Open an elevated command prompt if none.
PLANNING AND OPERATIONS FOR YOUR WINDOWS AZURE RIGHTS MANAGEMENT TENANT KEY: HTTP://TECHNET.MICROSOFT.COM/EN-
US/LIBRARY/DN440580.ASPX#BKMK_INTERNETPREPARETRANSFER1
51
32
BRING YOUR OWN KEY (BYOK) WITH AZURE RIGHTS MANAGEMENT: http://www.microsoft.com/en-us/download/details.aspx?id=40333
Migrating from AD RMS to the Azure Rights Management service
3.
Run the following command, replacing test with whatever you chose as your key identifier:
PS C:\Users\Administrator> $Password = Read-Host -AsSecureString -Prompt “Password:”
PS C:\Users\Administrator> Import-AadrmTpd -TpdFile E:\contosokey.xml -ProtectionPassword $Password HsmKeyFile E:\KeyTransferPackage-TestFirstkey.byok –Active $true –Verbose
The cmdlet will prompt the following confirmation when "-Force" is not given to avoid unintended action:
Are you sure you want to perform this action?
Performing the operation "Import-AadrmTpd" to import package as archived TPD with HSM key.
[Y] Yes [A] Yes to All [N] No [L] No to All [S] Suspend [?] Help (default is "Y"):
Important note
5.
This action cannot be undone.
Press "Y".
Note
All imported templates are marked as archived in the Azure Rights Management service tenant. IT
professionals can log into Azure Right Management service portal and sets up as Published the templates they
want displayed to the clients. Imported templates are indistinguishable from those created in the Azure Rights
Management service tenant.
Importing a TPD that has a CSP-based key
An exported TPDs that has a CSP-based key offers two options for the upload in the Azure Rights
Management service depending if a Thales HSM is used or not as described in the supported configurations
for the migration (see section § SUPPORTED AD RMS AND Windows RMS configurations).
Cluster using a Thales HSM
If AD RMS service’s SLC key is stored in a Thales HSM - in compliance with the organization’s own security
and IT policies in place, IT professionals need to export the Thales-based key via the aforementioned BYOK
process:

You securely transfer the key from the HSM to HSMs in Microsoft’s possession for the Key
Management Service (KMS) of the Azure Rights Management service. The key never leaves the
hardware protection boundary thanks to reliance on industry proven, FIPS compliant HSMs from
our partner Thales. HSMs provide a hardened, tamper-resistant environment for performing secure
cryptographic processing, key protection, and key management.

While in Microsoft’s possession, the organization’s key stays protected by Thales HSMs. Microsoft
and Thales have worked together to ensure your key cannot be recovered from Microsoft’s HSMs.
Considering the above, IT professionals are promised assurance that Microsoft operators cannot see or leak
the key during the import as well as during the running steady state.
33
Migrating from AD RMS to the Azure Rights Management service
Note
For additional information, see the Microsoft TechNet article PLANNING AND OPERATIONS FOR YOUR
WINDOWS AZURE RIGHTS MANAGEMENT TENANT KEY52 and the whitepaper BRING YOUR OWN KEY (BYOK) WITH AZURE RIGHTS
MANAGEMENT53.
As previously described, the new Azure Rights Management service Admin PowerShell cmdlet ImportAadrmTPD then enable IT professionals to upload TPD and HSM key to the organization’s Azure Rights
Management service tenant.
Understanding Thales HSMs and Microsoft additions
The Azure Rights Management service uses Thales FIPS 140-2 level 354 validated hardware security modules
(HSMs) to protect the organization’s keys in its possession meaning that Microsoft Azure based HSMs have
been independently validated to the world’s most widely recognized benchmark for cryptographic modules.
Thales solutions currently protect data for 19 of the 20 largest banks (and secure more than 80 percent of
worldwide payment transactions), 4 out of the top 5 aerospace companies, and 22 NATO countries.
Historically, key management privileges in an HSM have been an all-or-nothing model. The privileges to
generate/import a key, to authorize who can use it, to scale out your key across HSMs, and to recover
imported keys go hand-in-hand. This model breaks if you have to let a cloud service such as the Azure Rights
Management service use your key at scale.
Microsoft has worked with Thales to separate these, design and implement a secure key import process that
would accomplish several goals:

Spare IT the necessity of purchasing their own HSM and co-locating it in the Azure Rights
Management service data center. Organization’s keys can be loaded into the Azure Rights
Management service’s Thales nShield HSMs and used on the organization’s behalf without regard
to which HSM is doing the work.

Securely import the organization’s generated key without exposure of key plaintext during the
import process outside of the boundary of a Thales nShield HSM.

Elimination to the greatest degree possible of the ability for Microsoft to recover plaintext copies of
customer keys.
This results today in an effective secure key import process where IT professionals can import the
organization’s key into our HSMs, we can scale out the key across the Microsoft’s HSMs and manage the
Microsoft’s HSMs, and nobody, not even Microsoft, has the right to recover the keys from the Microsoft
HSMs. This is enforced inside the HSMs. This let the Azure Rights Management service scale up at short
notice to meet the organization’s usage spikes. In addition, IT retain control over the key lifecycle since IT
professionals generate the key and transfer it the Microsoft’s HSMs.
Together these enhancements create a unique and powerful offer that enables IT to get the benefits of
hosted services without relinquishing control over your keys. This required a heavy investment on the part
of Microsoft in using the aforementioned Thales’ Security World features.
PLANNING AND OPERATIONS FOR YOUR WINDOWS AZURE RIGHTS MANAGEMENT TENANT KEY: http://technet.microsoft.com/enus/library/dn440580.aspx#BKMK_ImplementBYOK
52
53
BRING YOUR OWN KEY (BYOK) WITH AZURE RIGHTS MANAGEMENT: http://www.microsoft.com/en-us/download/details.aspx?id=40333
54
More information on the FIPS 140-2 certification scheme can be found at http://csrc.nist.gov/groups/STM/cmvp/standards.html
34
Migrating from AD RMS to the Azure Rights Management service
Creating a copy of the Thales HSM-based key with reduced permissions
Perform all steps in this section on your disconnected secure workstation.
To reduce the permissions on the Thales HSM-based key, proceed with the following steps:
1.
Open an elevated command prompt if needed and navigate to the folder where you’ve copied the
BYOK toolset from the USB drive, for example C:\Program Files\BYOK_TOOLSET in our configuration.
2.
From the elevated command prompt, run the following command, replacing test with whatever you
chose as your key identifier. This utility reduces the permissions on the key.
c:\Program Files\BYOK_TOOLSET> KeyTransferRemote.exe -ModifyAcls -KeyAppName simple -KeyIdentifier test ExchangeKeyPackage <KEK> -NewSecurityWorldPackage <SecurityWorldpackage>
Where:


<KEK> is the Key Exchange Key (KEK) package for your region:

BYOK-KEK-pkg-EU-1 for Europe.

BYOK-KEK-pkg-NA-1 for North America.

BYOK-KEK-pkg-AP-1 for Asia-Pacific.
<SecurityWorldpackage> is the Security World package for your region:

BYOK-SecurityWorld-pkg-EU-1 for Europe.

BYOK-SecurityWorld-pkg-NA-1 for North America.

BYOK-SecurityWorld-pkg-AP-1 for Asia-Pacific.
This correspond to the following command in our configuration:
c:\Program Files\BYOK_TOOLSET>KeyTransferRemote.exe -ModifyAcls -KeyAppName simple -KeyIdentifier
contosormskey -ExchangeKeyPackage BYOK-KEK-pkg-EU-1 -NewSecurityWorldPackage BYOK-SecurityWorld-pkg-EU-1
When the command runs, you will be asked to plug in your security world admin cards.
When the command completes, you will see "Result: SUCCESS".
This will create in your %NFAST_KMDATA%\local folder a copy of the key with reduced permissions in a file
named key_xferacId_test, replacing test at the end of the filename with whatever you chose as your key
identifier.
Packaging the Thales HSM-based key
As noticed before, the re-packaging of the Thales HSM-based key is needed at this stage for maintaining
security. More specifically, Security is notably maintained by encrypting the Thales HSM-based key with a
Key Exchange Key (KEK). The Thales HSM-based kay stays encrypted until it is transferred to the Azure Rights
Management service’s HSMs.
Please follow on the disconnected workstation the steps outlined earlier in this document in the subsection
§ RETRIEVING YOUR AZURE RIGHTS MANAGEMENT service tenant ID
Perform all steps outlined in this section on the Internet-connected workstation.
To retrieve the organization’s Azure Rights Management service tenant ID, proceed with the following steps:
35
Migrating from AD RMS to the Azure Rights Management service
Open an (elevated) Windows PowerShell command prompt, run the following command:
PS C:\Users\Administrator> Connect-AadrmService
1.
2.
You will be prompted for your credentials.
3.
4.
In the Windows PowerShell Credential Request window that opens up, enter your Azure Rights
Management service tenant administrator credentials and wait to be authenticated.
View the current configuration for the tenant by running Get-AadrmConfiguration cmdlet:
PS C:\Users\Administrator> Get-AadrmConfiguration
This will display information about your Azure Rights Management service tenant configuration.
5.
36
Migrating from AD RMS to the Azure Rights Management service
6.
PS C:\Users\Administrator> Get-AadrmConfiguration
7.
8.
9.
BPOSId
: 2971a9f9-454c-4be2-9b86-5b3513ecb22e
10.
11. RightsManagementServiceId
: 6c8e9100-1168-4085-90f0-22293f9e5a0d
12. LicensingIntranetDistributionPointUrl
22293f9e5a0d.rms.eu.aadrm.com/_wmcs/licensing
:
https://6c8e9100-1168-4085-90f0-
13. LicensingExtranetDistributionPointUrl
22293f9e5a0d.rms.eu.aadrm.com/_wmcs/licensing
:
https://6c8e9100-1168-4085-90f0-
CertificationIntranetDistributionPointUrl : https://6c8e9100-1168-4085-90f022293f9e5a0d.rms.eu.aadrm.com/
14.
_wmcs/certification
15. CertificationExtranetDistributionPointUrl
22293f9e5a0d.rms.eu.aadrm.com/
16.
:
https://6c8e9100-1168-4085-90f0-
_wmcs/certification
AdminConnectionUrl
4085-90f0OnPremiseDomainName
Keys
CurrentLicensorCertificateGuid
Templates
b529-28c3a0d1ca7d}
FunctionalState
: https://admin.eu.aadrm.com/admin/admin.svc/Tenants/6c8e9100-116822293f9e5a0d
:
: {22327901-6fdd-4dfc-81c7-04a1eb3c1afb}
: 22327901-6fdd-4dfc-81c7-04a1eb3c1afb
: {72fb2c43-cc9d-43ba-a02a-3320b2a869be, 9567b5c8-217d-46d2: Disabled
SuperUsersEnabled
SuperUsers
: Disabled
: {}
AdminRoleMembers
KeyRolloverCount
ProvisioningDate
IPCv3ServiceFunctionalSate
DevicePlatformState
: {}
: 0
: 12/20/2013 2:57:14 PM
: Enabled
: {Windows -> True, WindowsStore -> True, WindowsPhone ->
True,
Mac -> True…}
FciEnabledForConnectorAuthorization
: True
Save the GUID from the first line (BPOSId). This is your Azure Rights Management service tenant ID. You will
need this information in the next steps. Considering the above output, our Azure Rights Management service
tenant ID is in our illustration 2971a9f9-454c-4be2-9b86-5b3513ecb22e.
Re-packaging the Thales HSM-based key of the section § IMPORTING A TPD THAT HAS A PASSWORD-PROTECTED
KEY.
You’ll be invited to use the tool KeyTransferRemote.exe and to run a command like the following one,
replacing test with the identifier you used to generate the key:
c:\Program Files\BYOK_TOOLSET>KeyTransferRemote.exe -Package -KeyIdentifier contosormskey ExchangeKeyPackage
BYOK-KEK-pkg-EU-1 -NewSecurityWorldPackage BYOK-SecurityWorld-pkg-EU-1 -TenantBposId 2971a9f9-454c-4be2-9b865b3513ecb22e -KeyFriendlyName “ContosoRmsKey”
37
Migrating from AD RMS to the Azure Rights Management service
When the command completes, this will create a file called KeyTransferPackage-<FirstKeyLabel>.byok, for
example KeyTransferPackage-TestFirstkey.byok in our illustration.
You’ll need to copy the output file KeyTransferPackage-<FirstKeyLabel>.byok to your USB drive or other
portable storage.
Importing the keyless TPD and the Thales HSM-based key
As noticed above, the new Azure Rights Management Administration cmdlet Import-AadrmTPD enables
to import the keyless TPD along with the on-premises HSM key to the organization’s Azure Rights
Management service tenant.
Please follow on the disconnected workstation the steps outlined earlier in this document in the eponym
subsection § IMPORTING THE KEYLESS TPD AND THE THALES HSM-BASED KEY of the section § IMPORTING A TPD THAT
HAS A PASSWORD-PROTECTED KEY.
You’ll be invited to use the cmdlet Import-AadrmTPD and to run for that purpose a command like the
following one, replacing test with the identifier you used to generate the key:
PS C:\Users\Administrator> Import-AadrmTpd -TpdFile E:\no_key_tpd_contosormskey.xml -ProtectionPassword HsmKeyFile E:\KeyTransferPackage-TestFirstkey.byok
Cluster using keys protected with a non-Thales HSM or a software-based CSP
Given that Azure RMS uses Thales HSMs internally, and that different HSM providers use protocols and file
formats that are not compatible with each other, the key must be transferred through a compatible Thales
HSM. If your organization is using AD RMS with a different HSM implementation or with a software-based
CSP, you must first extract the key from this CSP or HSM and make it available to the tools in a way in which
it can then be imported into a Thales HSM for upload.
This can be achieved by using HSM or CSP-specific tools to place the key directly into a TPD file, transferring
the key directly to a Thales HSM, or making the key available in a file format that can be directly imported
into a Thales HSM. Work with your HSM or CSP vendor to identify the most effective way of extracting the
keys from your current HSM in order to be able to perform these processes.
In either case, after these steps are completed you can follow the instructions in the previous sections to
import your keys and policies into Azure RMS.
Understanding the processing of the TPD imports in the Azure
Rights Management service
After the active or achieved TPD plus keys are imported into the organization’s Azure Rights Management
service tenant, the tenant configuration will be re-provisioned according to uploaded SLC information, key
type and rights policy templates. The updated tenant configuration data will used for licensing in SOAP and
REST services (rich clients vs. mobile clients).
For that purpose, Azure Rights Management service processes the active or achieved TPDs as follows:
1.
38
Takes as input the TPD and, optionally, the AD RMS licensing URL (default is URL in TPD).
Migrating from AD RMS to the Azure Rights Management service
2.
Archives existing Azure Rights Management service templates (usually two templates are
automatically created during provisioning).
3.
Uploads all rights policy templates in TPD as archived and with all existing properties (name,
description, etc.).
4.
Processes key of TPD:
a.
If TPD contains a password-protected key, imports the key as a software key.
b. If TPD is keyless (paired with an HSM key), records key identifier of HSM key.
5.
Records AD RMS URLs and SLC for service redirection.
This concludes this section on how to migrate the on-premises keys and policies to the organization’s Azure
Rights Management service tenant.
The highlighted process to fulfil the migration is synthesized hereafter:
AD-RMS
with password protected key
AD-RMS
with HSM
Export active and
archived TPDs & SLC key
Thales HSM
Convert SLC
key to HSM?
Export TPD & HSM-based key
Yes
Import SLC key via
KeyTransferRemote.exe
No
Repackage and export the HSM-based
key via KeyTransferRemote.exe
Run Import-AadrmTPD PowerShell cmdlet
39
Migrating from AD RMS to the Azure Rights Management service
Activating the Azure Rights Management service tenant
After the key and TPDs have been transferred into the organization’s Azure Rights Management service
tenant, you must activate the Azure Rights Management service. Adding keys should ideally be done before
you active the Azure Rights Management service.
Note
If you have an Office 365 subscription, you can activate Azure RMS from the Office 365 admin center
or the Azure Management Portal. We recommend that you use the Azure Management Portal because you will
use this management portal to change the migrated templates.
You can do this by following steps described in the Microsoft TechNet article ACTIVATING AZURE RIGHTS
MANAGEMENT55.
55
40
ACTIVATING AZURE RIGHTS MANAGEMENT: http://technet.microsoft.com/en-us/library/jj658941.aspx
Migrating from AD RMS to the Azure Rights Management service
Reconfiguring the rights-enabled computers
and devices
This step relates to the licensing redirection mechanisms available depending on the type of clients. As
noticed at the beginning of this document, existing clients are either Azure Rights Management servicecompatible clients or not.
Moreover, depending on the existing clients, RMS-enlightened applications leverage one of the four
available generations of the Rights Management protection:
1.
The AD RMS SDK56, which leverages functionality exposed by the client in Msdrm.dll. Msdrm.dll is
available for use in Windows Server 2008, Windows Vista, Windows Server 2008 R2, Windows 7,
Windows Server 2012, and Windows 8. Such applications for rich clients are further referred as to
MSDRM-based applications.
2.
The Microsoft RMS SDKs 2.0 and 2.157 for Windows desktop applications, which leverages
functionality exposed by the client in Msipc.dll. Such applications for rich clients are further referred
as to MSIPC-based applications.
3.
The Microsoft Rights Management SDK 4.158, a simplified, next-generation tool set that enables a
lightweight development experience in upgrading Android, iOS, and Mac OS X device applications
with information protection via AD RMS, thanks to the aforementioned Mobile Device Extension for
AD RMS. This SDK is later referred as to a RMS Mobile SDK.
Reconfiguring the rich clients
Rich clients capable of using registry-based redirections (MSDRM and
MSIPC Windows clients)
You can redirected MSDRM-based Office applications and MSIPC-based applications (Office and non-Office
like the RMS Sharing application on Windows desktop) through the existing License Redirection registry
entries so that these applications can consume content with their imported keys.
56
Active Directory Rights Management Services SDK: http://msdn.microsoft.com/en-us/library/cc530379(v=vs.85).aspx
Active Directory Rights Management Services SDK 2.1: http://msdn.microsoft.com/enus/library/windows/desktop/hh535290(v=vs.85).aspx
57
58
41
Microsoft Rights Management SDK 4.1: http://msdn.microsoft.com/en-us/library/dn758244(v=vs.85).aspx
Migrating from AD RMS to the Azure Rights Management service
Note
For some scenarios, IT may also consider to change the organization’s extranet on-premises licensing
URLs so they point to the cloud so during a coexistence period all new content is protected in the cloud and only
content protected before this period would require this type of redirection once the on-premises platform is shut
down.
Scripts are available at http://go.microsoft.com/fwlink/?LinkID=524619 to:
1.
Clean the existing configuration in these clients - CleanUpRMS.cmd.
2.
Set up client redirections – Redirect_OnPrem.cmd.
These scripts can be deployed to clients using GPO, software deployment solutions, logon scripts or a similar
process according to your practices.
Cleanup script
The CleanUpRMS.cmd script performs the following changes to the computer:

Deletes the contents of the %userprofile%\AppData\Local\Microsoft\DRM and
%userprofile%\AppData\Local\Microsoft\MSIPC folders, including any subfolders and any files with
long file names.

Deletes the contents of the following registry keys:
HKLM\Software\Microsoft\Office\(11.0|12.0|14.0)\Common\DRM
HKCU\Software\Microsoft\Office\(11.0|12.0|14.0)\Common\DRM
HKLM\Software\WoW6432Node\Microsoft\Office\(11.0|12.0|14.0)\Common\DRM
HKCU\Software\WoW6432Node\Microsoft\Office\(11.0|12.0|14.0)\Common\DRM
HKLM\SOFTWARE\Microsoft\MSIPC\ServiceLocation
HKLM\SOFTWARE\WoW6432Node\Microsoft\MSIPC\ServiceLocation
HKLM\Software\Microsoft\MSDRM\ServiceLocation

Deletes the following registry values:
HKCU\Software\Microsoft\Office\15.0\Common\DRM\DefaultServerURL
HKCU\Software\Microsoft\Office\15.0\Common\DRM\DefaultServer
Redirection script
Note
If your organization currently uses group policy object, software deployment solution, logon script, or
other solution to configure the registry keys mentioned below then you need to update this solution to use the
new Azure RMS settings, so the solution do not override registry keys with legacy settings.
The separate Redirect_OnPrem.cmd licensing redirection scripts creates the following registry values for
each URL supplied as a parameter under each of the following locations:
HKCU\Software\Microsoft\Office\(11.0|12.0|14.0)\Common\DRM\LicenseServerRedirection
HKCU\Software\WoW6432Node\Microsoft\Office\(11.0|12.0|14.0)\Common\DRM\LicenseServerRedirection
HKLM\Software\Microsoft\Office\(11.0|12.0|14.0)\Common\DRM\LicenseServerRedirection
HKLM\Software\WoW6432Node\Microsoft\Office\(11.0|12.0|14.0)\Common\DRM\LicenseServerRedirection
HKCU\Software\Classes\Local Settings\Software\Microsoft\MSIPC\LicensingRedirection
These values should each be in the following form:
REG_SZ: https://OldRMSserverURL/_wmcs/licensing"=https://YourTenantURL/_wmcs/licensing
Where your tenant URL is in the form: {GUID}.rms.[Region].aadrm.com, where GUID is
RightsManagementServiceId from your tenant’s configuration. Please note that this is NOT your BPOSid.
42
Migrating from AD RMS to the Azure Rights Management service
You can obtain this URL with the Azure RMS administration PowerShell cmdlets, for example using GetAadrmConfiguration:
PS C:\Users\Administrator> Get-AadrmConfiguration
BPOSId
: 2971a9f9-454c-4be2-9b86-5b3513ecb22e
RightsManagementServiceId
: 6c8e9100-1168-4085-90f0-22293f9e5a0d
LicensingIntranetDistributionPointUrl
: https://6c8e9100-1168-4085-90f022293f9e5a0d.rms.eu.aadrm.com/_wmcs/licensing
This script also contains temporary override for the Service Connection Point (SCP) in AD to enable new pilot
clients to initiate RMS client configuration against Azure RMS. Please follow the steps in section § DEPROVISIONING THE ON-PREMISES AD RMS INFRASTRUCTURE to remove the SCP after the pilot migration is finished.
You can remove SCP redirection from the script after that.
Rich clients incapable of using registry-based redirection
Such clients include Mac Office 2011 clients, Office mobile on Windows Phone devices and non-Office
MSDRM-based applications. None of these clients is currently compatible with the Azure Rights
Management service. You must migrate off these applications to compatible versions before deprovisioning your on-premises RMS infrastructure.
Reconfiguring the mobile devices based on the REST clients
If you were utilizing AD RMS with mobile devices utilizing applications based on the RMS Mobile SDKs, you
had deployed the Mobile Device Extension for AD RMS. While removing Mobile Device Extension is not
necessary for completing the migration, removing certain configurations implemented during the
deployment of Mobile Device Extension is.
The Mobile Device Extension for AD RMS enables Windows Server 2012 and Windows Server 2012 R2-based
AD RMS clusters to support the important devices in the same way with mobile RMS-enlightened
applications.
Note
For additional information, see the Microsoft TechNet article ACTIVE DIRECTORY RIGHTS MANAGEMENT
SERVICES MOBILE DEVICE EXTENSION59 and the whitepaper LEVERAGE THE MOBILE DEVICE EXTENSION LEVERAGE THE MOBILE DEVICE
EXTENSION FOR AD RMS ON YOUR PREMISES WITH AD FS60.
To operate in the on-premises, the mobile device extension requires the creation in DNS one or more DNS
SRV service discovery records in the organization’s domain(s) as per RFC 6763 DNS-BASED SERVICE DISCOVERY61:

One record for each email domain suffix that users will use.
ACTIVE DIRECTORY RIGHTS MANAGEMENT SERVICES MOBILE DEVICE EXTENSION: http://technet.microsoft.com/enus/library/dn673574(v=ws.10).aspx
59
LEVERAGE THE MOBILE DEVICE EXTENSION LEVERAGE THE MOBILE DEVICE EXTENSION FOR AD RMS ON YOUR PREMISES WITH AD FS:
http://www.microsoft.com/en-us/download/details.aspx?id=40333
60
61
43
RFC 6763 DNS-BASED SERVICE DISCOVERY: http://www.ietf.org/rfc/rfc6763.txt
Migrating from AD RMS to the Azure Rights Management service

One record for every FQDN used by the AD RMS clusters in place to protect content.
The service discovery record that relates to the email domain suffix has the following format:
_rmsdisco._http._tcp.<email suffix><port number><AD RMS cluster FQDN>
Where:

<email suffix> is the email domain suffix that users will use,

<port number>is the port number used by an on-premises AD RMS cluster,

<AD RMS cluster FQDN> is the FQDN used by an on-premises AD RMS cluster.
The service discovery record that relates to the FQDN used by an AD RMS cluster in place to protect content
has the following format:
_rmsdisco._http._tcp.< AD RMS cluster FQDN><port number><AD RMS cluster FQDN>
Where:

<AD RMS cluster FQDN> is the FQDN used by an on-premises AD RMS cluster (minus the cluster
name),

<port number>is the port number used by an on-premises AD RMS cluster.
For example, if an AD RMS cluster deployed on-premises is adrms.contoso.com, a DNS SRV record that has
the following value must be created in DNS:
_rmsdisco._http._tcp.contoso.com 443 adrms.contoso.com
The above SRV records - if created in the organization domain(s) to sustain a previous deployment
of the mobile device extension for AD RMS – must be removed by IT so that any forthcoming mobile
device’s queries dynamically point to the organization’s Rights Management service tenant.
Once this task is performed, mobile applications utilizing the RMS SDK will automatically find the right tenant
based on the URLs contained in the TPDs you imported to the service, and applications should be able to
consume content protected with your on-premises RMS cluster.
44
Migrating from AD RMS to the Azure Rights Management service
Reconfiguring existing on-premises workloads
Many pre-existing on-premises workloads that provide Information Rights Management (IRM) functionality
such as Exchange Server and SharePoint Server leverage for that purpose RMS SDKs.
Since the ability to interact with the Azure Rights Management service has only been introduced in later
versions of the RMS SDK, these existing on-premises workloads consequently do not natively support direct
communication with Azure Rights Management service, which resides outside the organization’s
boundaries.
Note
Microsoft Office 2013 utilizes the RMS SDK 2.0 and fully supports interacting with the Azure Rights
Management service without the need for additional software.
To help address this situation, and more especially in the context of the migration to the cloud, the Rights
Management connector (RMS connector) can be used to quickly enable such existing on-premises
workloads to use their IRM functionality with the newly enabled organization’s Azure Rights Management
service tenant.
For that purpose, the Rights Management connector is implemented as a small-footprint service that is
installed on-premises on a Windows Server 2008 R2 or Windows Server 2012 server.
Once installed and configured, the Rights Management connector will act as a communications interface
between the on-premises IRM-enabled servers and the cloud service. In other words, the Rights
Management connector will act as a pass-through to the Azure Rights Management service for IRM calls.
The Rights Management connector is like a cloud proxy/relay, and will behave as an on-premises AD RMS
server and relay any related call to the Azure Rights Management service.
Azure Active Directory/
Office 365 tenant
Active Directory Federation
Services (AD FS)
Active Directory
Azure Active Directory
Directory Synchronization Tool
Exchange Server
Rights Management
connector
Activated by tenant
administrator
Azure Rights Management service
SharePoint Server
File Server
When on-premises IRM-enabled servers call one of the exposed Web services (as it will with a classic AD
RMS server), the Rights Management connector checks the identity of the caller, verifies that it is authorized
to use the connector and performs an identical call against the Azure Rights Management service, and after
obtaining the results returns the results to the calling server.
45
Migrating from AD RMS to the Azure Rights Management service
When verifying that the caller is authorized, the Rights Management connector checks that the identity of
the caller is present in the local list of authorized identities (specified as either an AD user account, service
account, computer account or AD group). This list also contains accounts (called Service Principals) that are
specifically created as each authorized entity is added in the Administration tool and that will be used to
perform all operations in Azure Rights Management on behalf of the servers that are authorized.
Deploying the Rights Management connector on-premises
The Rights Management connector is not included in the migration tools. This constitutes a separate tool
that can be downloaded from http://go.microsoft.com/fwlink/?LinkId=314106.
Note
For additional information, see the Microsoft TechNet article DEPLOYING THE AZURE RIGHTS MANAGEMENT
CONNECTOR62 and the whitepaper LEVERAGE THE RIGHTS MANAGEMENT CONNECTOR FOR YOUR PREMISES63.
Reconfiguring Exchange Server workloads to use the connector
This section applies to Exchange Server 2010 and Exchange Server 2013.
The reconfiguration of the Exchange Server workloads implies the following steps:
1.
Cleaning up any prior IRM configuration.
2.
Fulfilling the technical prerequisites for the connector.
3.
Utilizing the connector in lieu of AD RMS.
The next sections depict each of these steps.
Cleaning up any prior IRM configuration
As indicated above, Exchange Server workloads can provide IRM functionality, and more specifically offer
IRM-protected e-mail messages and attachments functionality including AD RMS protection for Unified
Messaging voice mail messages and Outlook protection rules that can automatically apply IRM-protection
to messages in Outlook client before they leave the Microsoft Outlook client.
Note
To learn more about IRM and how to deploy it in Exchange Server, see the articles UNDERSTANDING
INFORMATION RIGHTS MANAGEMENT64 and UNDERSTANDING INFORMATION RIGHTS MANAGEMENT IN EXCHANGE ACTIVESYNC65 on
Microsoft TechNet.
If IRM was already configured in the Exchange Server workloads servers, it needs to be disabled and the
configuration cleaned prior to following the rest of the reconfiguration steps listed above.
62
DEPLOYING THE AZURE RIGHTS MANAGEMENT CONNECTOR: http://technet.microsoft.com/en-us/library/dn375964
63
LEVERAGE THE RIGHTS MANAGEMENT CONNECTOR FOR YOUR PREMISES: http://www.microsoft.com/en-us/download/details.aspx?id=40333
64
UNDERSTANDING INFORMATION RIGHTS MANAGEMENT: http://technet.microsoft.com/en-us/library/dd638140.aspx
65
UNDERSTANDING INFORMATION RIGHTS MANAGEMENT IN EXCHANGE ACTIVESYNC: http://technet.microsoft.com/en-us/library/ff657743.aspx
46
Migrating from AD RMS to the Azure Rights Management service
To do the IRM cleanup, proceed with the following steps:
1.
Once IRM is enabled on a server, the machine certificate and other DRM certificates and artifacts
are located under C:\ProgramData\Microsoft\DRM\Server\S-1-5-18. Delete all these certificates
under this location on each server in the organization.
2.
From the Start screen of one the server of the organization, click Exchange Management Shell.
An eponym Exchange Management Shell command prompt appears.
3.
When the prompt [PS] C:\Windows\system32> appears, disable IRM as follows:
a.
Run the following command:
[PS] C:\Windows\system32> Set-IRMConfiguration –InternalLicensingEnabled $false
With this configuration change (which is immediate), IRM features for messages sent to
internal recipients are now disabled.
Note
For additional information the Set-IRMConfiguration cmdlet, see the Microsoft TechNet article SETIRMCONFIGURATION66.
b. Run the following command to disable IRM features for messages sent to external
recipients:
[PS] C:\Windows\system32> Set-IRMConfiguration –ExternalLicensingEnabled $false
c.
Run the following command to disable IRM in Microsoft Office Outlook Web App and in
Microsoft Exchange ActiveSync:
PS] C:\Windows\system32> Set-IRMConfiguration –ClientAccessServerEnabled $false
d. Exchange Server caches the server certificate internally for a period of time independent of
the DRM cache. In addition to the above step 1, run the following command to clears the
cached certificates.
[PS] C:\Windows\system32> Set-IRMConfiguration –RefreshServerCertificates
66
47
SET-IRMCONFIGURATION: http://technet.microsoft.com/en-us/library/dd979792(v=exchg.150).aspx
Migrating from AD RMS to the Azure Rights Management service
4.
Open an elevated command prompt on each server of the organization and reset IIS:
C:\Windows\system32> iisreset
Once the above steps are completed, IT professionals can now proceed with the configuration to use the
connector.
Fulfilling the technical prerequisites for the connector
In order to connect to the Azure Rights Management service via the Rights Management connector, an onpremises Exchange server must be running one of the following software versions:

Exchange Server 2010 with Exchange 2010 Service Pack 3 Rollup Update 667.

Exchange Server 2013 with Exchange 2013 Cumulative Update 368.
The server running Exchange Server requires to use the advanced mode known as "Cryptographic Mode 2”
for Rights management operations which might require an update to the RMS client in your server.
Note
To enable the use of this Cryptographic Mode 2 for computers not running Windows Server 2012,
the computer must have the appropriate hotfix applied to the operating system. For computers running
Windows Server 2008, install the hot fix associated with the article 2627272 RSA KEY LENGTH IS INCREASED TO 2048
BITS FOR AD RMS IN WINDOWS SERVER 2008 R2 AND IN WINDOWS SERVER 200869. For computers running Windows Server
2008 R2, install the hotfix package associated with the article 2627273 RSA KEY LENGTH IS INCREASED TO 2048 BITS FOR
AD RMS IN WINDOWS 7 OR IN WINDOWS SERVER 2008 R270.
Utilizing the connector in lieu of AD RMS
In order to utilize the Rights Management connector, the following registry values need to be added to the
server running the Exchange environment.
For Exchange Server 2010, the following registry values need to be added to configure the server to utilize
the connector:
HKLM\Software\Microsoft\MSDRM\ServiceLocation\Activation
REG_SZ: [Default] = "https://<MicrosoftRMSURL>/_wmcs/certification"
HKLM\Software\Microsoft\MSDRM\ServiceLocation\EnterprisePublishing
REG_SZ: [Default] = "https://<MicrosoftRMSURL>/_wmcs/Licensing"
HKLM\SOFTWARE\Microsoft\ExchangeServer\v14\IRM\CertificationServerRedirection
REG_SZ:"https://<MicrosoftRMSURL>/_wmcs/certification" = "http(s)://<connectorName>/_wmcs/certification"
HKLM\SOFTWARE\Microsoft\ExchangeServer\v14\IRM\LicenseServerRedirection
REG_SZ: "https://<MicrosoftRMSURL>/_wmcs/licensing" = "http(s)://<connectorName>/_wmcs/licensing"
67
Update Rollup 6 For Exchange 2010 SP3 (KB2936871): http://www.microsoft.com/en-us/download/details.aspx?id=43101
68
Cumulative Update 3 for Exchange Server 2013 (KB2892464): http://www.microsoft.com/en-us/download/details.aspx?id=41175
RSA KEY LENGTH IS INCREASED TO 2048 BITS FOR AD RMS IN WINDOWS SERVER 2008 R2 AND IN WINDOWS SERVER 2008:
http://support.microsoft.com/kb/2627272
69
RSA KEY LENGTH IS INCREASED TO 2048 BITS FOR AD RMS IN WINDOWS 7 OR IN WINDOWS SERVER 2008 R2:
http://support.microsoft.com/kb/2627273
70
48
Migrating from AD RMS to the Azure Rights Management service
For Exchange Server 2013, the following registry values need to be added:
HKLM\Software\Microsoft\MSDRM\ServiceLocation\Activation
REG_SZ: [Default] = "https://<MicrosoftRMSURL>/_wmcs/certification"
HKLM\Software\Microsoft\MSDRM\ServiceLocation\EnterprisePublishing
REG_SZ: [Default] = "https://<MicrosoftRMSURL>/_wmcs/Licensing"
HKLM\SOFTWARE\Microsoft\ExchangeServer\v15\IRM\CertificationServerRedirection
REG_SZ:"https://<MicrosoftRMSURL>/_wmcs/certification" = "http(s)://<connectorName>/_wmcs/certification"
HKLM\SOFTWARE\Microsoft\ExchangeServer\v15\IRM\LicenseServerRedirection
REG_SZ: "https://<MicrosoftRMSURL>/_wmcs/licensing" = "http(s)://<connectorURL>/_wmcs/licensing"
Where:

<MicrosoftRMSURL> is your organization’s Azure Rights Management service URL (generally in the
form {GUID}.rms.<region>.aadrm.com.

<region> is the region of your organization’s Azure Rights Management service:


ap. Asia region.

eu. European Union region.

na. North America region.
<connectorName> is the name you defined in DNS for the connector. The https prefix needs to be
utilized for <connectorName> if you have configured IIS in the connector servers to use this
protocol. The Azure Rights Management service URLs should always be entered in the registry
indicating the use of HTTPS.
These registry settings tell Exchange that whenever a Rights Management operation must be performed the
calls must be made through the Rights Management connector.
You can obtain the Azure Rights Management service URL for your organization by using the Microsoft
Rights Management administration tools available on the Microsoft Download Center71.
Note
You can also get your Azure Rights Management service URLs tenant by using the cmdlet GetAadrmConfiguration as described later.
Once these steps are performed you can enable IRM functionality in Exchange Server.
Note
To learn how to configure IRM in Exchange, see Microsoft TechNet article INFORMATION RIGHTS
MANAGEMENT PROCEDURES72.
To ease the above configuration, you can use the Rights Management connector server configuration tool
available on the Microsoft Download Center73. This tool can be utilized to automatically configure Exchange
Server to utilize the Rights Management connector by configuring the above settings in the registry and
checking for pre-requisites.
Windows Azure AD Rights Management Administration Tools and Utilities: http://www.microsoft.com/enus/download/details.aspx?id=30339
71
72
INFORMATION RIGHTS MANAGEMENT PROCEDURES: http://technet.microsoft.com/en-us/library/dd351212(v=exchg.150).aspx
73
RMS connector server configuration tool: http://go.microsoft.com/fwlink/?LinkId=314106
49
Migrating from AD RMS to the Azure Rights Management service
Note
The tool can be run on an Exchange server to configure it to use the Rights Management connector,
or it can be run on a different computer to create .reg files that can be then deployed to the computers for the
same purpose.
The tool can also create a Group Policy Object (GPO) script that can be later run by a domain administrator to create
GPOs that apply the necessary settings on the target computers. Once created, the GPOs need to be linked, targeted
and filtered as desired so these settings are applied to the computers that need to be configured to use the
connector.
To use the tool, you need to launch an elevated Windows PowerShell command prompt and navigate to the
directory where you have download the tool and type “help .\GenConnectorConfig.ps1” for usage. You can add “examples” to the Help command line to see examples of the usage of the tool in different scenarios.
Please refer to the Microsoft TechNet article CONFIGURING AN EXCHANGE SERVER TO USE THE CONNECTOR74 for
detailed instructions.
Reconfiguring SharePoint Server workloads to use the
connector
This section applies to SharePoint Server 2010 and SharePoint Server 2013.
By using IRM in SharePoint Server workloads, IT professionals can control which actions users can take on
documents when they open them from IRM protected libraries in SharePoint Server.
CONFIGURING AN EXCHANGE SERVER TO USE THE CONNECTOR: http://technet.microsoft.com/enus/library/dn375964#BKMK_ExchangeServer
74
50
Migrating from AD RMS to the Azure Rights Management service
Note
For more information about how to use IRM with document libraries, see the article PLAN DOCUMENT
LIBRARIES (WINDOWS SHAREPOINT SERVICES)75.
The following reconfiguration must be done while there are no documents in RMS protected libraries
checked out so they don’t become inaccessible after the change.
In order to connect to the Azure Rights Management service via the Rights Management connector, an onpremises SharePoint server must be running one of the following software versions:

SharePoint Server 2010

SharePoint Server 2013
SharePoint servers must be running the latest version of the RMS client. For SharePoint Server 2013 that is
the MSIPC 2.1 client version available from the Microsoft Download Center at http://www.microsoft.com/enus/download/details.aspx?id=38396.
Important note
There are multiple versions of the MSIPC 2.1 client, so make sure to install the above version
from the Download Center. Or, install a later version of the client.
You can verify the client version by checking the version number of MSIPC.dll, which is located in \Program
Files\Active Directory Rights Management Services Client 2.1. The properties dialog box should show version
1.0.622.34 or later.
For SharePoint 2010 the same MSDRM client version is required as for Exchange servers
(http://support.microsoft.com/kb/2627273 or http://support.microsoft.com/kb/2627272 depending on the
Operating System used for the server).
Furthermore, if using SharePoint Server 2013, the following registry setting needs to be configured on the
server:
HKLM\SOFTWARE\Microsoft\MSIPC\ServiceLocation\LicensingRedirection
REG_SZ: "https://<MicrosoftRMSURL>/_wmcs/licensing"="http://<connectorName>/_wmcs/licensing"
Where:

<MicrosoftRMSURL> is your organization’s Azure Rights Management service URL (generally in the
form {GUID}.rms.<region>.aadrm.com.

<region> is the region of your organization’s Azure Rights Management service:

75
51

ap. Asia region.

eu. European Union region.

na. North America region.
<connectorName> is the name you defined in DNS for the connector. The https prefix needs to be
utilized for <connectorName> if you have configured IIS in the connector servers to use this
protocol. The Azure Rights Management service URLs should always be entered in the registry
indicating the use of HTTPS.
PLAN DOCUMENT LIBRARIES (WINDOWS SHAREPOINT SERVICES): http://go.microsoft.com/fwlink/p/?LinkId=183051
Migrating from AD RMS to the Azure Rights Management service
To ease the above configuration, you can use the RMS connector server configuration tool available on the
Microsoft Download Center76. This tool can be utilized to automatically configure SharePoint Server to utilize
the Rights Management connector by configuring the above settings in the registry and checking for prerequisites.
Note
The tool can be run on an SharePoint server to configure it to use the Rights Management connector,
or it can be run on a different computer to create .reg files that can be then deployed to the computers for the
same purpose.
The tool can also create a Group Policy Object (GPO) script that can be later run by a domain administrator to create
GPOs that apply the necessary settings on the target computers. Once created, the GPOs need to be linked, targeted
and filtered as desired so these settings are applied to the computers that need to be configured to use the
connector.
To use the tool, you need to launch an elevated Windows PowerShell command prompt and navigate to the
directory where you have download the tool and type “help .\GenConnectorConfig.ps1” for usage. You can add “examples” to the Help command line to see examples of the usage of the tool in different scenarios.
Once the right software is installed and the necessary registry changes have been made, IRM needs to be
enabled in SharePoint by following the instructions in the Microsoft TechNet article PLAN INFORMATION RIGHTS
MANAGEMENT (SHAREPOINT SERVER 2010)77.
Note
If IRM was enabled on the SharePoint server prior to this change, it needs to be disabled for the whole
server first. In order to do this you need to:
1. On the SharePoint Central Administration Web site, in the Quick Launch, click Security.
2. On the Security page, in the Information Policy section, click Configure information rights management.
3. On the Information Rights Management page, in the Information Rights Management section, select Do not
use IRM on this server, then click OK.
4. On each of the servers, delete the contents of the folder C:\ProgramData\Microsoft\MSIPC\Server\<SID of the
account running SharePoint>.
These steps will leave the SharePoint server in a state where IRM is disabled and ready to be enabled again through
the connector.
When enabling IRM in SharePoint Server as per the steps in the article linked above, you have to point
SharePoint Server to the Rights Management connector by utilizing the option Use this RMS server and
entering the Rights Management connector URL as defined by you. Only the protocol prefix (http:// or
https://) and the server name of the connector must be entered.
After IRM has been enabled on a SharePoint farm, you can enable IRM in on individual libraries by using the
Information Rights Management option in the Library Settings page for each of the libraries.
76
RMS connector server configuration tool: http://go.microsoft.com/fwlink/?LinkId=314106
PLAN INFORMATION RIGHTS MANAGEMENT (SHAREPOINT SERVER 2010): http://technet.microsoft.com/enus/library/hh545608(v=office.14).aspx
77
52
Migrating from AD RMS to the Azure Rights Management service
Please refer to the Microsoft TechNet article CONFIGURING A SHAREPOINT SERVER TO USE THE CONNECTOR78 for
detailed instructions.
Reconfiguring File servers for FCI to use the RMS connector
The Rights Management connector recently adds the support of the File Classification Infrastructure (FCI) as
available in Windows Server 2012 and above versions.
Note
FCI is controlled and exposed through the File Server Resource Manager (FSRM). FSRM is a feature of
the File Services role in Windows Server. It can be installed as part of the File Services role, using Server Manager.
For more information on the FCI technology, see the white paper FILE CLASSIFICATION INFRASTRUCTURE79, videos on
Channel 980 and of course the Storage Team Blog’s81 post’s on FCI.
FCI is a capacity that enables the server to scan local files and assess their content to determine if they
contain sensitive data, and if they do classify them accordingly by tagging them with classification properties
you define. Once files are classified, FCI can also automatically take action on these files, such as applying
adequate rights management protection to the files to prevent them from leaking beyond their intended
audience.
In order to connect to the Azure Rights Management service via the Rights Management connector, an onpremises File server for FCI must be running one of the following operating system versions:

Windows Server 2012

Windows Server 2012 R2
CONFIGURING A SHAREPOINT SERVER TO USE THE CONNECTOR: http://technet.microsoft.com/enus/library/dn375964#BKMK_ConfiguringSharePoint
78
WINDOWS SERVER 2008 R2 FILE CLASSIFICATION INFRASTRUCTURE TECHNICAL WHITE PAPER:
http://download.microsoft.com/download/D/D/3/DD3FB42C-D3C7-47C0-9431-40D80256FB0A/FCI_TDM_WP_May_09.pdf
79
80
FCI videos on Channel 9: http://channel9.msdn.com/tags/FCI/
The Storage Team at Microsoft – File Cabinet Blog:
http://blogs.technet.com/filecab/archive/tags/File+Classification+Infrastructure+_2800_FCI_2900_/default.aspx
81
53
Migrating from AD RMS to the Azure Rights Management service
Furthermore, the following registry setting needs to be configured on the File server:
HKLM\Software\Microsoft\MSDRM\ServiceLocation\EnterprisePublishing
REG_SZ: [Default] = "https://<MicrosoftRMSURL>/_wmcs/licensing"
Where:

<MicrosoftRMSURL> is your organization’s Azure Rights Management service URL (generally in the
form {GUID}.rms.<region>.aadrm.com.

<region> is the region of your organization’s Azure Rights Management service:


ap. Asia region.

eu. European Union region.

na. North America region.
<connectorName> is the name you defined in DNS for the connector. The https prefix needs to be
utilized for <connectorName> if you have configured IIS in the connector servers to use this
protocol. The Azure Rights Management service URLs should always be entered in the registry
indicating the use of HTTPS.
Please refer to the Microsoft TechNet article CONFIGURING A FILE SERVER FOR FILE CLASSIFICATION INFRASTRUCTURE
TO USE THE CONNECTOR82 for detailed instructions.
CONFIGURING A FILE SERVER FOR FILE CLASSIFICATION INFRASTRUCTURE TO USE THE CONNECTOR: http://technet.microsoft.com/enus/library/dn375964#BKMK_FileServer
82
54
Migrating from AD RMS to the Azure Rights Management service
De-provisioning the on-premises AD RMS
infrastructure
After confirming that there is no remaining activity in the existing on-premises AD RMS cluster(s) by
analyzing the AD RMS logs, and that all clients can work successfully against the cloud, and more particularly
the organization’s Rights management service tenant, the AD RMS servers can be shut down and eventually
de-provisioned by following steps in http://technet.microsoft.com/en-us/library/cc771332.aspx. Note that
decommission is not requires as you moved keys and TPDs to Azure RMS.
If you decides to leave on-premises AD RMS server for some time it is strongly recommended to remove
the AD RMS Service Connection Point object from AD by following steps in
http://social.technet.microsoft.com/wiki/contents/articles/710.the-ad-rms-service-connection-point.aspx,
so all new RMS rich clients can initiate using Azure RMS.
You can conduct this activity once migration is finished after all clients are Azure Rights Management
service-compatible.
Note
You should keep in mind that non-Azure Rights Management service-compatible clients – Mac Office
2011 clients, Office 2007 clients, Office mobile on Windows Phone devices, etc. - consume Azure Rights
Management service-protected content using AD RMS. The list of client devices and applications supported by
Azure RMS is available at http://technet.microsoft.com/en-us/library/dn655136.aspx.
55
Migrating from AD RMS to the Azure Rights Management service
Renewing keys after migration is complete
This final step of the end-to-end migration constitutes an optional steps. It applies for organization’s that
uploaded HSM-based keys.
You can perform a new BYOK to roll your key to a new one using steps in http://technet.microsoft.com/enus/library/dn592126.aspx. This is recommended for any organization that migrated with a cryptographic
mode 1 key and that is not using Exchange Online. The original key is retained for legacy content access.
After this point, all clients must be configured to utilize the Azure Rights Management service tenant,
since all clients configured to use the on-premises AD-RMS cluster(s) will be unable to open newly
protected content.
This concludes this guide.
56
Migrating from AD RMS to the Azure Rights Management service
The information contained in this document represents the current view of Microsoft Corporation on the
issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions,
it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the
accuracy of any information presented after the date of publication.
This white paper is for informational purposes only. Microsoft makes no warranties, express or implied, in this
document.
Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under
copyright, no part of this document may be reproduced, stored in, or introduced into a retrieval system, or
transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or
for any purpose, without the express written permission of Microsoft Corporation.
Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights
covering subject matter in this document. Except as expressly provided in any written license agreement from
Microsoft, the furnishing of this document does not give you any license to these patents, trademarks,
copyrights, or other intellectual property.
© 2015 Microsoft Corporation. All rights reserved.
The example companies, organizations, products, domain names, e-mail addresses, logos, people, places, and
events depicted herein are fictitious. No association with any real company, organization, product, domain
name, e-mail address, logo, person, place, or event is intended or should be inferred.
Microsoft, list Microsoft trademarks used in your white paper alphabetically are either registered trademarks or
trademarks of Microsoft Corporation in the United States and/or other countries.
The names of actual companies and products mentioned herein may be the trademarks of their respective
owners.
57
Migrating from AD RMS to the Azure Rights Management service