I have posed this question on the internet and have been ridiculed. Sometimes company policies go against common sense but it’s not in my paygrade to debate company policies. My job is to enforce it even if it’s counterintuitive.

Question: How do you prevent a creator of a document, protected by Azure Rights Management Service, from printing their document.

Turns out you cannot prevent the creator of the document from performing actions on their own documents. The creator has a separate set of permissions, not affected by the protection level/sensitivity label on the document.

However, you can change the creator / owner of the document through Power Shell via the Protect-RMSFile cmdlet. Azure Information Protection knows two PowerShell modules:

AIPService (formerly AADRM- used to administer the protection service)

Install-Module -Name AIPService
Import-Module AIPService

Confirm the version of the installed module

(Get-Module AIPService -ListAvailable).Version 

To see which cmdlets are available, type the following:

Get-Command -Module AIPService

AzureInformationProtection cmdlet – part of the Azure Information Protection Client used to protect files, label files and get information about files. You can download it here: but know this app is now in maintenance mode.

Issue #1: I installed both and got the same outcome as this individual. Protect-RMSFile was missing!

The following cmdlets were missing:

Get-RMSFileStatus - Gets the RMS protection status of a specified file.
Get-RMSServer     - Gets a list of RMS servers that can issue templates.
Get-RMSServerAuthentication   - Gets the server mode status that is used for authentication to RMS.
Get-RMSTemplate   - Gets a list of RMS templates.
New-RMSProtectionLicense      - Creates an ad-hoc rights policy for RMS protection.
Protect-RMSFile   - Protects a specified file / files in a specified folder by using RMS.

Further googling showed that these cmdlets were deprecated for use in Azure Information Protection Unified Labelling client which I am using. This table shows the upgraded cmdlets:

Issue #2: What was interesting was that I was still getting error messages (Invalid Operation) running Get-AIPFileStatus on a folder and file. I found the solution here. My admin account that was connected to AIPService was not configured to use the label policy. Once I published the policy to my admin account, I was able to run these cmdlets. And the hole deepens.

Previously, I had remote desktop (as myself) unto another a computer and created a word document. Microsoft Office 365 on the remote computer is licensed to DLP2 and DLP2 was signed into the account. When I ran the Get-AIPFileStatus against this file, it showed DLP2 as the RMSOwner but RMSIssuer was me.

Another hole to research at another time…

The label is encrypted as displayed [IsRMSEncrypted = True]. I can change the RMSOwner which was my intention to begin with. Run the following with new cmdlets:

Connect-AIPService

$permissions = New-AIPCustomPermissions -Users "blahblah@blah.com" -Permissions CoOwner

Set-AIPFileLabel '\\Path\Original\WhoIsTheOwner.docx'  -CustomPermissions $permissions

Get-AIPFileStatus -Path '\\Path\\WhoIsTheOwner.docx'

The last line will now display the new RMSOwner as myself. Since this document was protected by using custom permission (RMSTemplateName = Restricted Access), you have to re-protect the document again.

Via remote desktop, DLP2 no longer can open the file. To re-protect document manually, I opened and resaved the file(via the network, not via remote desktop). The default sensitivity label was applied (disables print).

or

just run the above in this order and it will automatically re-protect the document.

Connect-AIPService

$permissions = New-AIPCustomPermissions -Users "blahblah@blah.com" -Permissions CoOwner

Set-AIPFileLabel '\\path\WhoIsTheOwner.docx'  -RemoveLabel -RemoveProtection -JustificationMessage 'Reason for Removal'

Set-AIPFileLabel '\\path\WhoIsTheOwner.docx'  -LabelId 650b58d3-778c-46fc-8326-00e569d9ba24

Get-AIPFileStatus -Path '\\Path\\WhoIsTheOwner.docx'

DLP2 can now open the file and VOILA – print is disabled! (Because DLP2 is no longer the owner)