Back Up All Azure Rights Management Templates via PowerShell

I need to update properties of several custom templates in my tenant. After reading the warning in Set-AadrmTemplateProperty (see excerpt below), I want to ensure that I have at least a last-known-good set of these templates.

Excerpt from article:

Important: When you update properties of a custom template, the existing settings for those properties will be overwritten (not supplemented) without warning, so be sure to specify all the settings that you need for the properties that you are updating.

As a best practice, back up the existing template before you run this cmdlet, by using the Export-AadrmTemplate cmdlet. Then, if you need to revert to the original configuration, you can use the Import-AadrmTemplate cmdlet to restore the template.

The Export-AadrmTemplate article provides an example of how to export (back up) one template. Well, I don’t want to do this (one at a time) for all the templates I have in my tenant. So, I wrote the following script to export all templates that I need.

$ShortDate = Get-Date -Format yyyyMMdd

$OutPath = “C:\Azure RMS\Backup\”

$OutFolder = New-Item -ItemType Directory -Force -Path $OutPath$ShortDate

Foreach ($Template in ($Templates = Get-AadrmTemplate))


    $TemplateName = $Template.Names[0]

    $TemplateStatus = $Template.Status

    If ($TemplateName -match “1033” -and $TemplateStatus -match “Published”)


        $RMSTemplateFileName = ($TemplateName.Value.Substring(0) -replace ” “,“” -replace “\\”,“” -replace “-“,“”)

        $OutFile = $($OutFolder)\$($RMSTemplateFileName).xml”

        Export-AadrmTemplate -TemplateId $Template.TemplateId -Path $OutFile -Force



Get-Variable | Remove-Variable -EA 0

Get-PSSession | Remove-PSSession


The script creates a new directory and writes the export files to it in case I need to run this frequently.

Obviously, the If statement and any of the variables can be changed to meet your needs.

This script works well for me.

Thanks for reading!


Password-protected and Azure Information Protection

As you read Azure Information Protection client administrator guide on file types supported section, it is clearly stated that ‘Any file that is password-protected cannot be natively protected by the Azure Information Protection client. It lists a workaround by changing the default protection level via registry keys. If you’re not onboard with changing the default protection level and changing everyone’s registry keys, perhaps you would consider the following as a workaround.

Before I get to the workaround, it is necessary that I provide a bit of background on how I got here.

I classify an Excel file with RMS (Co-Author) rights, encrypt it with a password, and attach it to an email.

The recipient opens the attachment and sees this error:

“Excel cannot open the file <FileName>.xlsx because the file format or file extension is not valid. Verify that the file has not been corrupted and that the file extension matches the format of the file.”


Here’s the workaround I came up with.

  1. I classify the document with RMS enabled (same as before)
  2. I rename the file to <FileName>.pxlsx
  3. I attach the file to an email
  4. The recipient saves the file locally
  5. The recipient opens Excel, then opens the <FileName>.pxlsx
  6. The recipient provides the password to the file


7. The recipient selects ‘Yes’ in the dialog box


8. The file opens successfully

This is my workaround on this issue. I’m hoping that Microsoft will include password-protected files as one of the supported file formats in the near future.

Thanks for reading!

Persistent Permissions with Azure Rights Management

We all know that embedded classification and protection follow the data regardless of where it is stored when using Azure Information Protection (AIP) and Azure Rights Management (Azure RMS), but what happens when the classification label is deleted from AIP portal.

Today, I had to create a scoped policy to test automatic classification for a group of pilot users. One of the requirements was to delete the scoped label after the pilot users completed their testing.

I created a scoped label (sub-label), under ‘Confidential’, called ‘Privacy – Read’ which is configured with Azure RMS with View, Reply, and Reply All rights. The label was configured to automatically apply when a Belgium National Number is detected. As you can see in the following two images that automatic classification was applied when the document was created and when it was attached to an email

I deleted the label from my tenant, and reopened the document I created earlier to check its classification label. The document was automatically reclassified as its parent label ‘Confidential’ which has no RMS nor any automatic classification configured. The same document was resent as an attachment to an email.

As you can see, permissions associated with the document persist even though the document was automatically defaulted to the parent label (Confidential) which is not configured for RMS protection.


Thanks for reading!