Migrating AD RMS to Azure RMS: A Step-by-Step Guide

Assessing Your Environment, Licences, and AIP Readiness

Thorough pre-migration planning is the single most important factor in a successful migration. Rushing into the technical steps without a comprehensive assessment of your current environment frequently leads to content inaccessibility, user disruption, and compliance gaps. Allocate adequate time for this phase — for large enterprises, this assessment can take several weeks.

Inventory AD RMS Infrastructure

Document all AD RMS cluster nodes, service connection points (SCPs) in Active Directory, and any AD RMS-dependent applications. Use the Get-AIPServerConfiguration PowerShell cmdlet and the AD RMS Health Check tool to capture a complete picture. Record all rights policy templates in use and which business units or systems rely on them.

Audit Protected Content

Identify all protected content across file shares, SharePoint on-premises, Exchange, and endpoint devices. Determine which templates were used to protect each content class. Content protected with AD RMS will need to remain accessible post-migration — the TPD import process ensures this, but only if all active templates are exported correctly.

Validate Licence Entitlements

Azure RMS is included in Microsoft 365 E3/E5, EMS E3/E5, and standalone AIP P1/P2 licences. Confirm that all users who will consume or publish protected content hold an appropriate licence. Unlicensed users will be unable to decrypt or apply protection, causing immediate productivity impact post-cutover.

Check AIP Unified Labelling Readiness

Ensure your Microsoft 365 tenant has Azure RMS activated. Navigate to the Microsoft Purview compliance portal and confirm that sensitivity labels are available. Verify that your Azure Active Directory (now Microsoft Entra ID) is properly synchronised with on-premises AD using Azure AD Connect, and that UPN suffixes for all users are verified domains within the tenant.

Key Prerequisites Checklist

• Global Administrator or Compliance Administrator role in Microsoft 365
• AD RMS with SP2 or later installed and operational
• Azure AD Connect configured and synchronisation verified
• PowerShell modules: AIPService, AADRM, MSOnline
• Network connectivity between AD RMS servers and Azure endpoints

Recommended Pre-Migration Tools

• RMS Analyser — scans protected content and reports template usage
• Azure Information Protection Scanner — discovers on-premises content eligible for labelling
• AD RMS Migration Scripts — Microsoft-provided PowerShell toolkit for TPD export and import
• Microsoft 365 Licensing Diagnostics — validates per-user licence assignments at scale

Export TPD

Export TPD from AD RMS

Configure Key

Set BYOK or Microsoft-managed

Import to Azure

Use PowerShell to import TPD

The import process bridges your on-premises key material with Azure's cloud infrastructure. Once complete, Azure RMS becomes the authoritative rights management service for your organisation — capable of both issuing new use licences and honouring legacy AD RMS-protected content.

Import Procedure (Step by Step)

1. Install the AIPService PowerShell module: Install-Module AIPService
2. Connect to Azure RMS: Connect-AipService using Global Admin credentials
3. Import the TPD file: Import-AipServiceTpd -TpdFile "C:\export\tpd.xml" -ProtectionPassword $pwd -Verbose
4. Repeat for each additional TPD if multiple were exported from AD RMS
5. Set the imported TPD as active: Set-AipServiceKeyProperties -KeyIdentifier <KeyId> -Active $true
6. Enable the Azure RMS service if not already active: Enable-AipService

Tenant Key Topology Options

After import, you must decide on your tenant key topology. This is a significant architectural decision with compliance implications:

• Microsoft-Managed Key (default): Microsoft generates and manages your Azure RMS tenant key in Azure Key Vault. Simplest option; appropriate for most organisations not subject to strict data sovereignty requirements.
• Bring Your Own Key (BYOK): Your organisation generates the key on-premises (using an HSM) and transfers it to Azure Key Vault, where Microsoft manages operations but your organisation retains key ownership. Required for regulated industries such as financial services and healthcare.
• Double Key Encryption (DKE): Your organisation holds one key on-premises; Microsoft holds the other in Azure. Both keys are required to decrypt content — even Microsoft cannot access it. For the highest-sensitivity workloads only.

Verify Migration Readiness

Confirm that all clients have been updated with Azure RMS configuration, that the AIP client is deployed, and that a sample of protected documents can be accessed successfully via Azure RMS. Run usage logs from both AD RMS and Azure RMS to verify traffic has shifted.

Remove the AD RMS SCP

The Service Connection Point (SCP) in Active Directory tells Windows clients where to find the RMS service. Use the AD RMS Administration Console or PowerShell (Set-AdObject) to remove the SCP. This prevents new clients from registering with AD RMS after the cutover date.

Update DNS SRV Records

Create or update the _rmsredir._http._tcp DNS SRV record to point to Azure RMS endpoints. This ensures legacy Office clients that discover RMS via DNS are automatically redirected to Azure RMS without requiring manual reconfiguration on each device.

Decommission AD RMS Servers

Once DNS SRV redirection is confirmed working and no traffic is reaching AD RMS servers, set AD RMS cluster nodes to "decommissioned" state via the console. Retain the servers in a powered-off state for at least 30 days before deprovisioning, in case rollback is required.

DNS SRV Record Configuration Details

The DNS SRV record for RMS redirection should be configured in your internal DNS zone as follows. The record instructs Office clients to redirect all RMS licensing requests to Azure RMS automatically:

Enabling Protection for On-Premises Exchange and SharePoint Workloads

Many organisations running AD RMS also have on-premises Exchange Server and SharePoint Server deployments that integrate directly with RMS for email protection, IRM libraries, and document protection. These workloads cannot communicate natively with Azure RMS — they require the Microsoft Rights Management (RMS) Connector, a lightweight relay service that bridges on-premises servers with the Azure RMS cloud service.

What is the RMS Connector?

The RMS Connector is a Windows Server role that acts as a secure proxy between your on-premises servers and Azure RMS. It translates the proprietary AD RMS communication protocol used by Exchange and SharePoint into the REST-based API used by Azure RMS. The connector itself does not process or store content — it simply relays licensing requests and use licence responses between the on-premises application and Azure.

The connector supports the following on-premises workloads:

• Exchange Server 2013, 2016, and 2019 (for IRM-protected email, transport rules, and OWA)
• SharePoint Server 2013, 2016, and 2019 (for IRM-protected document libraries)
• Windows Server File Classification Infrastructure (FCI) with the RMS Protection tool

Installation and Configuration Steps

1. Download the Microsoft RMS Connector installer from the Microsoft Download Centre and install it on a dedicated Windows Server 2016 or later VM — use at least two servers for high availability
2. Run the RMS Connector Administration Tool and authenticate with Global Administrator credentials to authorise the connector with your Azure RMS tenant
3. Add the computer accounts of your Exchange and SharePoint servers to the authorised servers list within the connector administration tool
4. On each Exchange Server, run the ServerCertificationTool.exe to configure the connector URL: https://<connector-fqdn>:443
5. On SharePoint, navigate to Central Administration → Security → Information Rights Management and point it at the connector URL
6. Validate connectivity using the Test-RMSConnector PowerShell cmdlet

High Availability

Deploy a minimum of two RMS Connector instances behind a network load balancer (NLB) or Azure Load Balancer. Both instances connect to the same Azure RMS tenant. Configure your DNS round-robin or NLB VIP as the connector URL used by Exchange and SharePoint to ensure failover with no single point of failure.

Firewall Requirements

The RMS Connector requires outbound HTTPS (port 443) access to *.aadrm.com, *.informationprotection.azure.com, and Azure AD authentication endpoints. Inbound access from Exchange and SharePoint servers on port 443 must also be permitted. Ensure SSL inspection is either disabled for these endpoints or uses certificate pinning exceptions.

Monitoring the Connector

The RMS Connector writes detailed event logs to the Windows Event Viewer under Applications and Services Logs → Microsoft → RMS. Enable verbose logging during initial configuration to capture licensing request flows. Integrate with Azure Monitor or your SIEM for ongoing health alerting — connector failures will immediately break Exchange IRM and SharePoint library protection.

Using the AIP Unified Labelling Client

The final technical migration step involves updating all end-user devices to use the Azure Information Protection (AIP) Unified Labelling Client and ensuring that sensitivity label policies are correctly configured in the Microsoft Purview compliance portal. This step has the broadest organisational impact, touching every user who works with protected content — it demands careful change management and staged rollout planning.

Client Deployment Strategy

The AIP Unified Labelling Client replaces the legacy AIP Classic Client and the built-in Office sensitivity label experience with a richer, more configurable interface. It installs as an Office add-in and a File Explorer extension, enabling users to apply and view labels across Office applications, Windows File Explorer, and the AIP Viewer for non-Office file types.

Recommended deployment approach:

1. Package the AIP client MSI using Microsoft Endpoint Configuration Manager (MECM/SCCM) or Microsoft Intune for MDM-enrolled devices
2. Deploy silently using: AzInfoProtection_UL.exe /quiet /norestart OFFICE_INTEGRATION=1
3. Target a pilot group of 50–100 users representing all departments and document types first
4. Monitor for issues via Azure AD sign-in logs and AIP audit logs for 1–2 weeks before broad deployment
5. Roll out in waves by department or site, with IT support available during each wave

Migrating Rights Policy Templates to Sensitivity Labels

AD RMS rights policy templates do not migrate automatically — they must be recreated as sensitivity labels with equivalent protection settings in Microsoft Purview. For each AD RMS template:

• Create a corresponding sensitivity label in the Microsoft Purview compliance portal under Information Protection → Labels
• Configure the label's encryption settings to mirror the AD RMS template permissions (e.g., co-author rights for specific groups, viewer rights for external domains)
• Set the same content expiry and offline access duration settings as the original template
• Publish the labels via a Label Policy to the same user groups that previously had access to the AD RMS template
• Use the Set-Label PowerShell cmdlet for bulk label creation from a CSV mapping the old template GUIDs to new label configurations

User Communication & Training

Publish clear guidance explaining the transition from AD RMS templates to sensitivity labels. The visual interface changes significantly — users accustomed to the AD RMS template names in the Office ribbon will see sensitivity label names instead. Provide short video walkthroughs and a FAQ document addressing the most common questions around labelling behaviour changes.

Auto-Labelling Policies

Configure auto-labelling policies in Microsoft Purview to automatically apply sensitivity labels to documents and emails that match specific conditions — for example, content containing financial data patterns or personal information. This reduces reliance on manual labelling and ensures consistent protection posture across the organisation without end-user action.

Default Label Policies

Set a default sensitivity label for all new documents and emails via Label Policy settings. This ensures that all newly created content receives at least a baseline level of classification from day one, even before users actively choose a label. Align the default label with your organisation's data classification policy — typically "General" or "Internal Use Only".

Testing Document Access, User Permissions, and Audit Logs in Azure

Migration validation is not a single checkpoint — it is a structured testing programme that must be completed before decommissioning AD RMS and before communicating a "migration complete" status to the business. A rigorous validation process protects against silent failures where content appears accessible but permissions have drifted, or where audit trails are incomplete.

Document Access Testing

Retrieve a representative sample of documents protected under each AD RMS template — ideally spanning different file types (Word, Excel, PDF, email), different protection templates, and different creation dates (including content protected years ago). Attempt to open each document using the AIP Unified Labelling Client from both domain-joined devices and non-domain-joined devices. Verify that the correct permissions are enforced — a user with "Viewer" rights should be unable to edit or print; a user with "Co-Author" rights should be able to edit but not forward.

User Permissions Verification

Test permission enforcement systematically across user groups. Use test accounts representing each permission level defined in your sensitivity labels. Verify that permissions are enforced consistently across Office applications (Word, Outlook, Excel), the AIP Viewer, and SharePoint Online. Test external user access — invite a guest user from a partner tenant and verify they can open shared protected documents through the Azure RMS guest access flow without requiring an AD RMS licence or VPN connection.

Audit Log Review in Microsoft Purview

Navigate to the Microsoft Purview compliance portal → Audit and search for AIP-related activities: SensitivityLabelApplied, SensitivityLabelChanged, SensitivityLabelRemoved, and ProtectionApplied. Confirm that all protection events are being captured. Cross-reference with the AIP Usage Log available via Get-AipServiceUserLog PowerShell cmdlet to ensure usage data is complete and attributable to individual users.

RMS Connector Health Check

If you deployed the RMS Connector for on-premises Exchange and SharePoint, validate that IRM-protected emails round-trip correctly through Exchange transport rules, that Outlook Web App (OWA) correctly displays and enforces protection, and that SharePoint document library IRM restrictions are functioning. Use the Test-RMSConnector cmdlet and review Windows Event Logs on connector servers for any warning or error events during the test period.

Validation Sign-Off Criteria

• 100% of sampled legacy documents successfully decryptable via Azure RMS
• All sensitivity labels applied correctly in Office applications across pilot user group
• Audit logs capturing all protection/unprotection events with correct user attribution
• External guest access working for at least two partner domains
• RMS Connector health checks passing with no errors in 72-hour monitoring window
• Help desk ticket volume stabilised at baseline after client deployment wave

Ongoing Monitoring Post-Migration

After go-live, establish a regular monitoring cadence using the following tools:

• Microsoft Purview Activity Explorer — real-time visibility into label activity across all users and content locations
• Azure AD Sign-In Logs — identify failed authentication attempts to Azure RMS endpoints
• AIP Analytics Dashboard — aggregated view of label usage trends, top labelled file types, and geographic distribution
• Azure Monitor Alerts — configure alerts for RMS Connector availability and Azure RMS service health events