Rights Management Template errors are frustrating to come across when you are deploying sensitivity labels. The following errors are most common:

• We were not able to find the Information Rights Management template. Please contact your administrator.
• De Information Rights Management-sjabloon kan niet worden gevonden. Neem contact op met de beheer. (Dutch).
• Failed to get Information Rights Management Template
• Failed to acquire RMS templates

This article explains the role of the Rights Management Service in a sensitivity label deployment and outlines several methods for resolving related errors.

First, some terminology

Let’s start with Azure Rights Management Service (Azure RMS). Think of it as the engine behind encryption: it’s the underlying technology that protects information whenever a sensitivity label with encryption is applied.

Azure RMS handles the actual cryptographic work: encrypting content, issuing usage licenses, and enforcing the rights attached to protected content. In practice, this means it can stop recipients from forwarding or printing a document, or automatically expire access to it after a set period of time.

Azure Information Protection (AIP) was the client and management layer built on top of Azure RMS. The labeling client has since been folded into the Microsoft 365 (Office) apps, giving users a unified experience, so a separate AIP client is no longer necessary. The management layer has likewise been migrated into Microsoft 365 sensitivity labels. One holdout remains, though: the AIP PowerShell module is (unfortunately) still needed for troubleshooting, which we will see in the upcoming section.

Another term you might come across is Information Rights Management (IRM). IRM is largely legacy terminology for protection controls built into services like Exchange Online or SharePoint Online. This older technology dates back to the days of on-premises Active Directory Rights Management Services (AD RMS). Most environments today apply protection through Purview sensitivity labels instead of relying on IRM to contact the AIP (or AD RMS) service.

Since you’re now up to speed on terminology, let’s continue with troubleshooting!

Setting up our tools of the trade

We will troubleshoot using the ExchangeOnlineManagement and AIPService PowerShell Modules. Install them both using the following cmdlets. I recommend using at least PowerShell 7.5 to ensure everything is running smoothly:

Install-Module ExchangeOnlineManagement, AIPService

Do note that the ‘AIPService’ PowerShell Module does not work on ARM-based devices, so you will need to use a device that runs on the x86 architecture.

Troubleshooting Time

Since the management of Exchange Message Records Management (MRM) policies has been moved to the Microsoft Purview console and marked prominently as ‘legacy’, I frequently receive questions from clients asking whether they should migrate their MRM policies to Purview Data Lifecycle Management (DLM). And the answer is: it depends. First of all, Microsoft states the following when navigating to said management console:

We do not recommend using this option except for moving items from a primary to an archive mailbox and applying retention or deletion settings to default folders. We recommend that you use ‘Retention policies’ in Microsoft 365 to protect content in SharePoint, OneDrive, Exchange and Microsoft 365 Groups.

Second, you should look at the functionality Purview DLM offers and whether it matches your requirements.

Common pitfalls

So with that, let’s first take a look at some common pitfalls when migrating Exchange MRM to Purview DLM.

Data does not move by itself; people move data.

This statement may seem simple, but it contains an important insight into data security: technology is only part of the solution. For robust information security, a proper balance is needed between technology that aligns with your organization and employees who know how to handle data securely. In this blog, I’ll share three practical tips to structurally strengthen the human aspect of data security, based on experience in various projects.

1. Form a Diverse Working Group

For your data security initiative, assemble a working group with people from different departments, roles, and backgrounds. Include data owners, department heads, the Chief Information Security Officer (CISO), and representatives from the Central Data Office (CDO), information security, and Document Information Management. This provides insight into information and information flows within your organization. Additionally, expand the group with representatives from IT and functional support.

After all, these are the people that have the real insight on what data is sensitive to your company, and what the specifications or properties of that data are.

2. Make End Users Part of the Design

Automatic detection of sensitive data and targeted alerts for risky actions help raise awareness among end users and support the adoption of data security. However, successful implementation depends on involving users. Start with training that strengthens both knowledge and desired behavior.

Up to now, the ‘Protect Your Microsoft 365 Data in the Age of AI’ series consists of the following posts:

1. Protect your Microsoft 365 data in the age of AI: Introduction
2. Protect your Microsoft 365 data in the age of AI: Prerequisites
3. Protect your Microsoft 365 data in the age of AI: Gaining Insight
4. Protect your Microsoft 365 data in the age of AI: Licensing (This post)

Every series has at least one episode that you feel was the weakest of the bunch; however, the series would not be complete without it. The same applies to this post. Although it is, of course, much more enjoyable to delve into the technical aspects, we must also address the more essential matters, such as licensing in this case. After all, before you begin protecting your data in the age of AI, you naturally want to know what it will cost you, so that you can perhaps draft a business case.

In the case of protecting your Microsoft 365 data in the age of AI, we’ll have to deal with 2 types of licensing models, which we’ll talk about in the next chapters.

Per-user licensing model

This is the actual subscription-based license that grants you the right to use Microsoft 365 services, and in this case, Microsoft Purview and Microsoft Defender for Cloud Apps.

Up to now, the ‘Protect Your Microsoft 365 Data in the Age of AI’ series consists of the following posts:

1. Protect your Microsoft 365 data in the age of AI: Introduction
2. Protect your Microsoft 365 data in the age of AI: Prerequisites
3. Protect your Microsoft 365 data in the age of AI: Gaining Insight (This post)

Now, with the introduction and prerequisites being taken care of, we can focus on the first objective in this blog series which -if you might remember- is the following:

Create insight in the use of GenAI apps in our company.

While this is possible by leveraging Microsoft Defender for Cloud Apps, we’re going to take this one step further and use Microsoft Purview Data Security Posture Management for AI (DSPM4AI) to also create insight on which sensitive data is shared with GenAI apps.

Creating policies

Let’s dive back into the Purview console and start where we also started with our previous article in this series. The DSPM4AI console. While we satisfied all the prerequisites in our previous article, we can see in the screenshot above that 1 tick box is still missing that satisfying green checkmark. And that’s the one we are going to enable right now.

It allows us to extend our insights for data discovery and specifically; the use of generative AI apps in our organization. As can be seen in the screenshot above, it takes the manual creation of policies out of our hands by creating an Insider Risk Management policy that allows us to detect when users use a browser to visit AI sites and also creates an endpoint Data Loss Prevention (eDLP) policy that allows us to capture when and which sensitive information is pasted or uploaded to AI sites. Let’s create both policies and check out what’s under the hood.