Office 365 Message Encryption (Part 1)

If you would like to read the other parts in this article series please go to:


A while ago now, Microsoft announced the Office 365 Message Encryption service was available. This is effectively the new version of what was previously called Exchange Hosted Encryption, or EHE. The great thing about Office 365 Message Encryption is that it allows you to send encrypted emails not only to other recipients within your organization, but also to other recipients outside of your organization and hence those users outside of your organization do not have to be running the same messaging system as you. Office 365 Message Encryption makes use of transport rules in Exchange Online to add encryption to messages. As a result it’s relatively easy to implement since transport rules should be very familiar to all Exchange administrators. In addition, the experience for end-users is both easy and friendly. In this article series, I’ll be looking at implementing and using the Office 365 Message Encryption service in my Office 365 lab tenant. The information in this article is my experience of Office 365 Message Encryption at the time of writing this article; you will need to review, understand, modify and test all configuration elements and their resulting actions yourself.

In order for me to test Office 365 Message Encryption, I need two things. First, I need either an Exchange Online or Exchange Online Protection subscription, the latter meaning that Office 365 Message Encryption can be used not only with Office 365 mailboxes, but also with on-premises mailboxes when using Exchange Online Protection. Next, I need to have Azure Rights Management. Since I already have my Office 365 lab tenant setup, I’m not going to cover that process in this article. If you need to setup an Exchange Online subscription, you can follow Henrik Walther’s excellent article series titled Configuring an Exchange 2013 Hybrid Deployment and Migrating to Office 365 (Exchange Online), where the tenant creation process is covered in part 2. In this article on Office 365 Message Encryption, I will be using my Office 365 lab tenant to give me access to Exchange Online to use the encryption capabilities. What I will also cover, however, is setting up Azure Rights Management so that I can use Office 365 Message Encryption in this tenant.

For this article, I’m using an Office 365 E3 Plan tenant. The good news is that according to the Microsoft Office 365 plan options, Azure Rights Management is already included in the E3 plan, as well as the E4, A3 and A4 plans. For a full list of the Office 365 plans, please see the topic titled Office 365 Plan Options. Note that it is also possible to purchase Azure Rights Management as a standalone subscription.

To commence looking at the Office 365 Message Encryption service in my Office 365 lab tenant, I first need to connect to the tenant and then configure Azure Rights Management.

Connect to the Office 365 Tenant

With the Office 365 lab tenant setup, I now need to activate Azure Rights Management for the Office 365 Message Encryption service. To do this, I first need to make a PowerShell connection to our Office 365 tenant, which I can perform via the following steps. Note that I’m not including using the Connect-MsolService cmdlet below to run cmdlets such as Get-MsolUser, since I don’t need such specific cmdlets for this article.

  1. Launch PowerShell on the workstation used to manage Office 365
  2. Run the following PowerShell command: $cred = Get-Credential. This command will simply prompt for the Office 365 administrator credentials and store them in a variable named $cred
  3. In the resulting window, enter the username and password of the Office 365 administrator account. This is shown in Figure 1-1.

Figure 1-1:
Specifying Office 365 Tenant Credentials

  1. Next run the following command: $Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri -Credential $cred -Authentication Basic –AllowRedirection. This creates a session with Office 365 PowerShell via the $Session variable
  2. Now run the following command: Import-PSSession $Session. This command imports the session just created into the local session and so here I will see the various cmdlets available to be imported into my session
  3. If these commands are successful, the screen then looks like the one shown in Figure 1-2. At this point, I now have a PowerShell connection to my Office 365 lab tenant for administering Exchange Online.

Figure 1-2:
Connected to Office 365 Lab Tenant

Configure Azure Rights Management

With a successful connection made to the Office 365 tenant, the next step is to use the Set-IRMConfiguration cmdlet. This cmdlet is used to configure Information Rights Management (IRM) settings and in this particular case I will use it to configure the Rights Management Service online key-sharing location first of all. This location is a URL which varies depending on geographical location. The following list details the geographical locations and the corresponding online key-sharing location, as provided by Microsoft at the time of writing this article.

The URL specifies where the Trusted Publishing Domain (TPD) is to be found; the TPD will be discussed next, but for now the command to run in PowerShell to set the online key-sharing URL in my example for Europe is:

Set-IRMConfiguration –RMSOnlineKeySharingLocation “”

As can be seen from Figure 1-3, the prompt simply drops to the next line if the command has been successful.

Figure 1-3:
Configuring the Rights Management Service Online Key-Sharing Location

Next, I use the Import-RMSTrustedPublishingDomain cmdlet. This is used to import what is known as a Trusted Publishing Domain (TPD), which contains feature settings, into the Exchange Online organization. In fact, the Import-RMSTrustedPublishingDomain command can also be used to import the TPD from an on-premises Active Directory Rights Management Service deployment, where the on-premises TPD is exported to XML file format before importing it in using this command. However, the command I will run is a little more straightforward than the one used to reference an on-premises deployment, since I am importing the TPD from the Rights Management Services Online service. The command I run is:

Import-RMSTrustedPublishingDomain –RMSOnline –Name “RMS Online”

Here you can see I used the –RMSOnline parameter with the command. It is this parameter that instructs the command to import the TPD from the online service, not the on-premises service, using the URL I specified with the –RMSOnlineKeySharingLocation parameter previously.

At this point, I can use the Get-IRMConfiguration cmdlet to check various configuration settings associated with Information Rights Management. For example, I can check here that the –RMSOnlineKeySharingLocation parameter has been set with the correct URL. Also, one of the key parameters to note is the InternalLicensingEnabled parameter, which is currently set to False in this tenant. This is something I will set to True for using Office 365 Message Encryption. To do this, I run the following command:

Set-IRMConfiguration –InternalLicensingEnabled $true

Why did I set this parameter to True? The answer to this is that the transport rules that I will create later to provide message encryption have a dependency on this parameter being set to true. We can see this dependency by attempting to set this parameter back to false when I have already created transport rules for message encryption features. This is shown in Figure 1-4.

Figure 1-4:
Dependency on Transport Rules

Also, if I don’t want the IRM templates to be available to the clients such as Outlook Web App, I will set the –ClientAccessServerEnabled parameter to $false. Once I’ve configured the InternalLicensingEnabled parameter and any other parameters as desired, I can now use the Test-IRMConfiguration cmdlet to test the overall IRM configuration. Since I am using the online service, I need to use the –RMSOnline parameter with this command. The command to run is therefore:

Test-IRMConfiguration –RMSOnline

The result of running this command is shown in Figure 1-5. It looks like everything is good to go, as the overall result is a ‘pass’.

Figure 1-5:
Testing the IRM Configuration


So far in part one of this article series I have introduced the Office 365 Message Encryption service, shown how I can connect to my Office 365 lab tenant and then proceeded to configure the tenant’s Azure Rights Management Services. Now that I have everything configured, I am ready to start creating the transport rules that will allow me to start encrypting messages. I will be looking at those transport rules in part two, along with sending and receiving encrypted messages.

If you would like to read the other parts in this article series please go to:

About The Author

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top