Monthly Archives: February 2014

Office 365 Message Encryption

Today Microsoft announced the generally availability of Office 365 Message Encryption

This is the replacement for Exchange Hosted Encryption (EHE).  Customers who are currently using EHE will be upgraded to Office 365 Message Encryption beginning in the first quarter of 2014.

The service promises “Send encrypted email messages to anyone, regardless of the recipient’s email address”

While this is by far the biggest selling point and improvement over RMS, it could also be a slight drawback because the recipient must have an Office 365 organizational ID or a Windows LiveID associated with the email address that you send to. Although not everyone will have a Windows LiveID, you can still send the encrypted email blindly and hope that they will click the link to enroll in a new Live ID account and then subsequently decrypt the email you send them. The enrollment process is pretty quick and straight forward (if you can sign up for an email account then you can figure out the Live ID enrollment process).

In contrast with RMS, the end-user doesn’t have direct control over which messages will be encrypted with a button. It is up to the Office 365 Administrator to enforce a rule that will apply the encryption. With some creativity, an Administrator can allow the user to indirectly control whether a message is encrypted by filtering on a key word. IMHO, this limitation is also a strength because it doesn’t have any client requirements, as all mail clients can immediately benefit from encryption whether it is enforced by an Admin, or permitted by an Admin using an indirect keyword.

“Easily Set up Encryption”

Yes, the setup is very fast and easy for an Office 365 Administrator. Simply create a new rule in the mail flow section of the Exchange Admin Center inside the Office 365 Portal:


Select ‘Apply rights protection to messages’


There are dozens of ways you could apply encryption based on the variety of rules available. +1 for the flexibility here.


Here is an example of applying encryption to a message where the subject line contains ‘’Encrypted” (Perhaps this could be the key word you tell your users to use when they want to encrypt an email).


The next step is where you provide the rule action, ex: Apply Office 365 Message Encryption.


Next you can configure whether you want to enforce the rule immediately or whether you want to test it out first with a policy-tip notification (for OWA or the Outlook clients that support message tips).


The rules are particularly useful for automatically encrypting emails if they contain sensitive information such as a Social Security Number, Credit Card Number or Drivers License Number.


That’s it for the setup! Nice and easy, right? It’s impressive that such an awesome encryption technology is so easy to setup. You could have full blown message encryption in minutes!

Adding custom branding

You can add custom branding by connecting to Exchange Online powershell and using the get-OMEConfiguration and set-OMEConfiguration



So what about the end-user experience?


An email that bears an encrypted message arrives in the recipient’s Inbox with an attached HTML file that lets the recipient to sign-in to view the encrypted message.


When opening the HTML attachment, the user has the option to view the encrypted message. You can see evidence of the custom branding which can help give credibility to the message.


Recipients follow instructions in the message to authenticate by using a Microsoft account or an organizational account. If recipients don’t have either account, they’re directed to create a Microsoft account that will let them sign in to view the encrypted message.

After being authenticated, recipients can view the decrypted message and reply to it with the same style of an encrypted attachment, so the whole back and forth will remain encrypted.

For additional screen shots of the end-user experience, click here:


How much does it cost?

For $2 per user per month you can get a complete solution for internal and external information protection: traditional Rights Management capabilities like Do Not Forward for internal users, plus the new ability to encrypt outbound messages to any recipient. If you already have an Office 365 tenant, you can try it for free by adding a trial license here:

The great news is that if you already have an E3 or E4  license, then you get Message Encryption for free!

(Note: The trial enables you to try Information Rights Management capabilities as well as the capabilities of Office 365 Message Encryption)

So do you still need Rights Management if you use Message Encryption? Perhaps… because Windows Azure Rights Management in Office 365 prevents sensitive information from being printed, forwarded, or copied by unauthorized people inside the organization. That is why Message Encryption is labeled a companion service with RMS, not a replacement.

If you are using Exchange 2013 on-premise, you can also benefit from Message Encryption by configuring Hybrid mailflow.

Thank you Microsoft! This is great stuff!!


The official site for Office 365 Message Encryption is here:

IT Pro’s can get more technical information about Message Encryption here:

Recommendations for reducing the impact to mobile devices during a hybrid migration to Office 365

One of the features available during a Hybrid / “rich-coexistence” migration to Office 365 is the friendly URL redirect that users can receive if they try using the old OWA URL that was pointing to the old Exchange server.

However many people may not be aware that using that feature requires establishing a legacy namespace with Exchange 2007, as the Exchange 2013 cannot proxy all workloads for Exchange 2007.



For example, would be redirected to the Hybrid server, and then it could proxy the request to a back-end legacy Exchange server.

However, if it is more important to an organization that the impact to mobile phones is reduced, then you can leave the pre-existing namespace (ex: intact and instead introduce a new external namespace for the Hybrid server (ex: so that it exists side by side with the previous environment.

The benefit is that users only have to change their mobile phone setting once.

The downside with this approach is after a user’s mailbox migration completes, if the user attempts to logon to the old Exchange OWA URL then they will get an error message that their mailbox cannot be found.

This can be mitigated with a communication plan that provides the new OWA URL so that users don’t try to go to the old URL. To me, that’s worth the tradeoff of having to make the user change their mobile device twice: once to and a second time when their mailbox migrates to Office 365.

For example, among the things you can communicate to an end-user prior to their mailbox being migrated:

• You will get a pop-up to restart outlook

• You will be prompted to enter credentials, please use your email address as your username.

• The new URL for Outlook Web Access is

• Follow these instructions for re-attaching your mobile device to Office 365