The time has finally come to get our hands dirty.  Welcome to my fourth post on the evolution of Active Directory Rights Management Service (AD RMS) to Azure Information Protection (AIP).  So far in this series I’ve done an overview of the service, a comparison of the architectures, and covered the key planning decisions that need to place when migrating from AD RMS to AIP.  In this post I’ll be performing the preparation and server-side migration steps for the migration from AD RMS to AIP.

Microsoft has done a wonderful job documenting the steps for the migration from AD RMS to AIP within the migration guide.  I’ll be referencing back to the guide as needed throughout the post.  Take a look at my first post for a refresher of my lab setup.  Take note I’ll be migrating LAB2 and will be leaving LAB1 on AD RMS.  Here are some key things to remember about the lab:

• There is a forest trust between the JOG.LOCAL and GEEKINTHEWEEDS.COM Active Directory Forests
• AD RMS Trusted User Domains (TUDs) have been configured on both JOG.LOCAL and GEEKINTHEWEEDS.COM

I’ve created the following users, groups, and AD RMS templates (I’ve been on an 80s/90s movies fix, so enjoy the names).

• GEEKINTHEWEEDS.COM CONFIGURATION
  • (User) Jason Voorhies
    • User Principal Name Attribute: jason.voorhies@geekintheweeds.com
    • Mail Attribute: jason.voorhies@geekintheweeds.com
    • Group Memberships: Domain Users, GIW Employees, Information Technology
  • (User) Theodore Logan
    • User Principal Name Attribute: theodore.logan@geekintheweeds.com
    • Mail Attribute: theodore.logan@geekintheweeds.com
    • Group Memberships: Domain Users, GIW Employees, Information Technology
  • (User) Ash Williams
    • User Principal Name Attribute: jason.voorhies@geekintheweeds.com
    • Mail Attribute: ash.williams@geekintheweeds.com
    • Group Memberships: Domain Users, GIW Employees, Accounting
  • (User) Michael Myers
    • User Principal Name Attribute: michael.myers@geekintheweeds.com
    • Mail Attribute: michael.myers@geekintheweeds.com
    • Group Memberships: Domain Users, GIW Employees, Accounting
  • (Group) Accounting
    • Mail Attribute: giwaccounting@geekintheweeds.com
    • Group Type: Universal Distribution
  • (Group) GIW Employees
    • Mail Attribute: giwemployees@geekintheweeds.com
    • Group Type: Universal Distribution
  • (Group) Information Technology
    • Mail Attribute: giwit@geekintheweeds.com
    • Group Type: Universal Distribution
  • (Group) GIW AIP Users
    • Group Type: Global Security
  • (AD RMS Template) GIW Accounting
    • Users: giwaccounting@geekintheweeds.com
    • Rights: Full Control
  • (AD RMS Template) GIW Employees
    • Users: giwemployees@geekintheweeds.com
    • Rights: View, View Rights
  • (AD RMS Template) GIW IT
    • Users: giwit@geekintheweeds.com
    • Rights: Full Control
• JOG.LOCAL CONFIGURATION
  • (User) Luke Skywalker
    • User Principal Name Attribute: luke.skywalker@jog.local
    • Mail Attribute: luke.skywalker@jog.local
    • Group Memberships: Domain Users, jogemployees
  • (User) Han Solo
    • User Principal Name Attribute: han.solo@jog.local
    • Mail Attribute: han.solo@jog.local
    • Group Memberships: Domain Users, jogemployees
  • (Group) jogemployees
    • Mail Attribute: jogemployees@jog.local
    • Group Type: Universal Distribution

After my lab was built I performed the following tests:

• Protected Microsoft Word document named GIW_LS_ADRMS with GEEKINTHEWEEDS.COM AD RMS Cluster and successfully opened with Luke Skywalker user from JOG.LOCAL client machine.
• Protected Microsoft Word document named GIW_GIWALL_ADRMS with GEEKINTHEWEEDS.COM AD RMS Cluster and GIW Employees template and unsuccessfully opened with Luke Skywalker user from JOG.LOCAL client machine.
• Protected Microsoft Word document named GIW_JV_ADRMS with GEEKINTHEWEEDS.COM AD RMS Cluster using Theodore Logan user and opened successfully with Jason Voorhies user from GEEKINTHEWEEDS.COM client machine.
• Protected Microsoft Word document named JOG_MM_ADRMS with JOG.LOCAL AD RMS Cluster using Luke Skywalker user and opened successfully with Michael Myers user from GEEKINTHEWEEDS.COM client machine.
  Protected Microsoft Word document named GIW_ACCT_ADRMS with GEEKINTHEWEEDS.COM AD RMS Cluster and GIW Accounting template and was unsuccessful in opening with Jason Voorhies user from GEEKINTHEWEEDS.COM client machine.

These tests verified both AD RMS clusters were working successfully and the TUD was functioning as expected.  The lab is up and running, so now it’s time to migrate to AIP!

Our first step is to download the AADRM PowerShell module from Microsoft.  I went the easy route and used the install-module cmdlet.

Back in March Microsoft announced that AIP would be enabled by default on any eligible tenants with O365 E3 or above that were added after February.  Microsoft’s migration guide specifically instructs you to ensure protection capabilities are disabled if you’re planning a migration from AD RMS to AIP.  This means we need to verify that AIP is disabled.  To do that, we’re going to use the newly downloaded AADRM module to verify the status.

As expected, the service is enabled.  We’ll want to disable the service before beginning the migration process by running the Disable-Aadrm cmdlet.  After running the command, we see that the functional state is now reporting as disabled.

While we have the configuration data up we’re going to grab the value (minus _wmcs/licensing) in the  LicensingIntranetDistributionPointUrl property.  We’ll be using this later on in the migration process.

In most enterprise scenarios you’d want to perform a staged migration process of your users from AD RMS to AIP.  Microsoft provides for this with the concept of onboarding controls.  Onboarding controls allow you to manage who has the ability to protect content using AIP even when the service has been enabled at the tenant level.  Your common use case would be creating an Azure AD-managed or Windows AD-synced group which is used as your control group.  Users who are members of the group and are licensed appropriately would be able to protect content using AIP.  Other users within the tenant could consume the content but not protect it.

In my lab I’ll be using the GIW AIP Users group that is being synchronized to Azure AD from my Windows AD as the control group.  To use the group I’ll need to get its ObjectID which is the object’s unique identifier in Azure AD.  For that I used the Get-AzureADGroup cmdlet within Azure AD PowerShell module.

Microsoft’s migration guide next suggests come configuration modifications to Windows computers within the forest.  I’m going to hold off on this for now and instead begin the server-side migration steps.

First up we’re going to export the trusted publisher domains (TPDs) from the AD RMS cluster.  We do this to ensure that users that have migrated over to AIP are still able to open content that was previously protected by the AD RMS cluster.  The TPD includes the Server Licensor Certificate (SLC) keys so when exporting them we protect them with a password and create an XML file that includes the SLC keys and any custom AD RMS rights policy templates.

Next we import the exported TPD to AIP using the relevant process based upon how we chose to protect the cluster keys.  For this lab I used a software key (stored in the AD RMS database) so I’ll be using the software key to software key migration path.  Thankfully this path is quite simple and consists of running another cmdlet from the AADRM PowerShell module.  In the first command we store the password used to protect the TPD file as a secure string and use the Import-AadrmTpd cmdlet to pull it into AIP.  Notice the resulting data provides the cluster friendly name, indicates the Cryptographic Mode was set to 1, the key was a Microsoft-managed (aka software key) and there were three rights policy templates attached to the TPD.

Keep in mind that if you have multiple TPDs for some reason (let’s say you migrated from Cryptographic Mode 1 to Cryptographic Mode 2) you’ll need to upload each TPD separately and set the active TPD using the Set-AadrmKeyProperties cmdlet.

Running a Get-AadrmTemplate shows the default templates Microsoft provides you with as well as the three templates I had configured in AD RMS.

The last step of the server side of the process is to activate AIP.  For that we use the Enable-Aadrm cmdlet from the AADRM PowerShell module.

At this point the server-side configuration steps have been completed and AIP is ready to go.  However, we still have some very important client-side configuration steps to perform.  We’ll cover those steps in my post.

Have a great week!