Two posts back I did a very brief preamble on setting up Information Rights Management for Exchange 2010 SP1. (Ok, I basically pointed you in the general direction of the TechNet documentation.) Let’s take a couple of further looks, going slightly into more detail on the matter. I assume that an IRM infrastructure is already in place, and that you’ve run the Test-IRMConfiguration cmdlet on Exchange with a passing result. If you’ve already have all that in place lets move on.

IRM should be enabled by default, but let’s verify this.

Run Get-IRMConfiguration. “ClientAccessServerEnabled” should be “True”.

We then verify that it’s enabled for OWA as well (because some of the testing needs to be done on a desktop, and OWA is a nice choice for that).
Get-OwaVirtualDirectory –Identity “FQDN\Owa (Default Web Site)” |fl
You should find “IRMEnabled” somewhere in a long list of settings.

We then verify the same is true for ActiveSync.
Get-ActiveSyncMailboxPolicy –Identity EASPolicyName
If the ActiveSync policy was created originally on a previous release of Exchange you might find it to be disabled.

If this checks out Exchange should be ready. There are a number of other things that could fail of course, but I can’t really cover those here. A very quick tip though is that replicating the IRM policies, and distributing through Group Policies might take a little time. I found that even when doing a gpupdate I will not see changes on the Exchange Server immediately after applying settings on the IRM Server. If the policies seem to be missing just grab a cup of coffee and return to your computer a few sips later.

You can use Outlook 2010 if you like – I use Outlook Web Access for simplicities sake. I’ve created a simple policy called “MobilityDojo.net Default IRM”, which doesn’t enforce any restrictions. For test purposes it’s enough to have a restriction even if it doesn’t do much. To locate the IRM policies click the envelope icon, and you should see a list drop down:

Still keeping it simple I send a mail to myself that has an IRM policy applied.

Notice the stop-sign in your inbox:

I didn’t bother with typing in a body (thus it looks rather empty here), but apart from an extra heading the mail item looks normal:

So, let’s see what this looks like on a device. (This screenshot is taken from an iPhone running iOS 4.1, but will obviously be similar for other devices not supporting this feature.)

Kind of a let down I’d say. Sure, just download a free trial of Outlook on your device – that will solve it

For completeness sake – if I use Safari on the iPhone to access OWA I get the light version. Which does not support IRM…

As I have mentioned before this is a feature introduced in EAS version 14.1, which I am not aware of any device supporting at the moment. (I have of course not tested every ActiveSync implementation on the market so there could exist one or more I am not aware of.)

But if we convince ourselves that we have a device that does support it – how would it work?

EAS supports three “features” of IRM:
- Downloading the available IRM policies from the server. This would for instance be used if you are creating a new mail from the device and want to apply some sort of restriction.
- Downloading mail items protected with IRM, and actually displaying the contents. This would most likely be complemented by altering the UI on the device – for instance removing the “Forward” option if one of the restrictions in the policy doesn’t allow forwarding.
- Removing the IRM policy from the mail item. If you for some reason decide you no longer need a policy applying to the mail item you can remove it. This can of course only be done to items you have the permissions to modify. For instance you can remove all polices from items you originally created and are the owner of.

Important things to be aware of:
- IRM is not a silver bullet. You can protect content from being mistakenly sent out of the organization, but you cannot prevent a user from copying the content by screenshots, copy-paste by a non-compliant EAS client, or writing down by hand.
- All policies are enforced by the Client Access Server. You can probably implement a client that will pull down IRM-protected mails even though it happily ignores the settings in the policy. But if you attempt things like trying to forward a mail whose policy does not allow it you can be sure the Exchange Server will try to prevent you from doing so.
- While the contents of the IRM-protected mail will be available to the EAS client, attachments will not be by default. My understanding is that this still requires the “old-fashioned” method of putting certificates on the device. This I have not done much testing of so I’m just trusting Microsoft on this one. (Attaching a document in OWA does not mean the attachment is IRM-protected. Protecting the attachment would be done in Word/Excel/etc.)

At this point I would of course have loved to show you how it looks on an ActiveSync client that is compliant with IRM, but as I said a few paragraphs up I do not have that client yet. I am looking at implementing something in my EAS MD utility, but it would be targeted at testing that IRM is accessible through EAS and not a complete client letting you perform every task related to IRM.

Do I think IRM “will fly”? Don’t know. I kind of like it in the sense that it’s quite easy to implement server side and doesn’t require all that much effort really. I’d need to get used to using it day-to-day on the desktop first I guess, but if I got into the habit I could like having access on my mobile device as well. As per usual you are free to drop your two cents below