Getting error while activating Azure RMS for integrating with purview sensitivity labels encryption settings

Hi @Purview Engineer ,

You've already ruled out the usual first answers — five admin accounts, 3–4 machines, both PowerShell and Cloud Shell — so let me skip those and focus on what a failure that's identical across all of them points to.

First, one thing to check before anything else

Do you have AD RMS deployed on-premises? If so, stop — the documentation is explicit: "Do not activate the Azure Rights Management service if you have Active Directory Rights Management Services (AD RMS) deployed for your organization." There's a separate migration path.

Your error is not the Cloud Shell / PowerShell 7 error.

Worth clearing up, since that's the standard first suggestion. Cloud Shell genuinely can't run this — AIPService needs Windows PowerShell 5.1 and the full .NET Framework — but it fails with a distinctive message:

the module could not be loaded due to the following error:
[Could not load file or assembly 'System.Web.Services, Version=4.0.0.0...']

Yours is ApplicationFailedException from ConnectAipServiceCommand, meaning the module loaded and authentication failed. So on your Windows machines the version isn't the problem. Just confirm with $PSVersionTable.PSVersion that you're on 5.1 (not 7, not ISE) and move on.

Most likely cause #1 — the role, not the account

Five Global Admins failing identically is a systematic condition, not five credential problems. And Global Admin may not be the role being checked. The activation documentation says:

"Run Connect-AipService and sign in with a role that has permissions to activate the Azure Rights Management service for your tenant. For example, the compliance administrator role, or compliance data administrator role."

Check whether any of your five accounts hold Compliance Administrator or Compliance Data Administrator as an active assignment. If your tenant uses PIM, an eligible-but-not-activated role won't work — activate it first, then retry.

Most likely cause #2 — TLS inspection on your network

This is my strongest candidate for a failure that reproduces on every machine. Required endpoints:

• *.aadrm.com
• *.cloudapp.net (specifically rmsoprod*-b-rms*.cloudapp.net)
• Outbound TCP 443

But open ports aren't sufficient. Connection fails if HTTPS traffic is blocked, TLS inspection is enabled, or proxy authentication breaks certificate pinning. A corporate proxy doing SSL inspection on *.aadrm.com breaks this identically on every machine and for every account — which matches your symptoms exactly.

Test this decisively: run Connect-AipService from a Windows machine on a completely different network — a mobile hotspot, or a home connection off the corporate VPN. If it succeeds there, it's TLS inspection/proxy, and the fix is a bypass rule for those endpoints.

One preemptive note: *.aadrm.com and *.cloudapp.net are not pingable by design. ICMP isn't required and ping failure alone doesn't indicate a problem — don't let that mislead your network team.

About the Set-IRMConfiguration attempt

That's the wrong lever, and it's worth knowing why. Set-IRMConfiguration -InternalLicensingEnabled $true configures Exchange Online IRM; it doesn't activate the tenant RMS service. Activation is Enable-AipService, and IRM settings largely auto-configure once RMS is active.

That said, it gives you a useful read on tenant state without needing Connect-AipService to succeed:

Connect-ExchangeOnline
Get-IRMConfiguration
Test-IRMConfiguration -Sender <your-address>

If you see InternalLicensingEnabled: False, AzureRMSLicensingEnabled: False, and an empty LicensingLocation, that confirms RMS was never activated at the tenant level. Test-IRMConfiguration will also flag licensing gaps — watch for a missing BPOS_S_Enterprise capability, which blocks encryption features regardless of everything above.

Also check whether you need to activate at all

"If your subscription... was obtained towards the end of February 2018 or later: The service is automatically activated for you."

If your tenant is post-Feb-2018, RMS should already be on unless someone deactivated it. Get-AipService returning Enabled means you're done and the real issue is elsewhere in your label configuration.

References

• Activating the Azure Rights Management encryption service — roles, automatic activation, AD RMS warning
• Administering the Azure Rights Management service by using PowerShell
• Rights Management requirements — network endpoints

Kind Regards,
Microsoft Support Team.