Rights Management Server and Exchange 2010 (Part 5)

By / September 9, 2017

If you would like to read the first part in this article series please go to:

Introduction

So far in parts one to four of this article, we have installed and configured the Rights Management Server (RMS) role, performed the additional configuration steps required to support RMS integration within Outlook Web App (OWA), tested the configuration and then gone on to look at RMS integration in action within OWA. Here in part five of this article we will be taking a look at how you can enable or disable RMS integration within OWA. I will follow that by taking a minute to talk about RMS integration within Outlook before moving on to cover Outlook protection rules.

Enabling/Disabling RMS Integration

Having RMS integration within OWA is obviously great but so far it looks like the feature is available to all users. What if you want to disable the feature for all users, or a subset of users? To answer this question, let’s first turn our attention to the information given to us when using a cmdlet called Get-IRMConfiguration. We saw in part four how to set the InternalLicensingEnabled parameter to a value of true using the Set-IRMConfiguration cmdlet so it follows that we can examine the configuration using the Get-IRMConfiguration cmdlet. An example of the output is shown below in Figure 37. In fact, the parameter settings shown in Figure 37 are default settings with the exception of the InternalLicensingEnabled parameter, since earlier in this article we set it to true from its default setting of false.


Figure 37: Results of Get-IRMConfiguration

One of the parameters of interest is the ClientAccessServerEnabled parameter which, as you might guess from its name, controls whether the IRM features are enabled on the Client Access Server roles across the organization; this will obviously affect RMS functionality in OWA and Exchange ActiveSync. I used the phrase ‘across the organization’ because the Set-IRMConfiguration cmdlet modifies the IRM configuration across the Exchange organization.

In previous articles here on MSExchange.org I have covered how to configure the virtual directories on a Client Access Server for areas such as the authentication method, or the GZip compression level. This is achieved using the Set-OwaVirtualDirectory cmdlet with the relevant parameter. By running the Get-OwaVirtualDirectory cmdlet to list all the available parameters, I noticed a parameter called IRMEnabled which can be used to enable or disable the IRM functionality on a specific virtual directory.

You can even take things one step further and make use of OWA mailbox policies to enable or disable IRM functionality on a per-user basis. Although a default OWA mailbox policy is created in Exchange 2010, it isn’t assigned to any mailboxes by default as you can see from Figure 38.


Figure 38: No Default OWA Mailbox Policy

By using the same IRMEnabled parameter that we have already seen used with the Set-OwaVirtualDirectory cmdlet, we can enable or disable the IRM functionality on the default OWA mailbox policy. We can then assign that policy to a mailbox as shown in Figure 39. Note that I have achieved this using the Exchange Management Shell this time, using the Set-CASMailbox cmdlet to apply the policy to a single mailbox. Of course, you can also create a new OWA mailbox policy rather than modify the default policy.


Figure 39: Disabling IRM Functionality For a Single Mailbox

RMS and Outlook

In part four we saw how a user was able to apply the RMS Do Not Forward template to a message using Outlook Web App (OWA). I covered OWA first mainly because, as you saw, there is extra configuration work required in order to allow RMS functionality from within OWA. RMS functionality also works within Outlook of course, and in actual fact the application of the RMS template is performed at the client level; the Exchange server has no awareness of whether a message has been protected by Outlook. There are, however, ways that Exchange can RMS-protect messages as we shall see later in part six of this article.

Outlook 2003 and later is capable of using RMS templates but in this article I will be focusing on Outlook 2010. When creating a new message from within Outlook, a user can select the Options tab on the ribbon and then click the Permissions button. From there, the Do Not Forward RMS template should be visible as you can see from Figure 40.


Figure 40: Applying RMS Templates in Outlook 2010

Outlook Protection Rules

As you have just seen, a user is able to apply the RMS Do Not Forward template to a message in Outlook such that the recipient is unable to forward, print or copy that message. Obviously this system relies on the user choosing to enable this feature and it’s therefore possible that the user will either choose not to do this or perhaps forget entirely.

To combat this problem, Outlook protection rules can be used. These rules ensure that the relevant RMS template is applied to the message in Outlook. The fact that the template is applied within Outlook is important, as this differentiates Outlook protection rules with transport protection rules which we will cover later in part six of this article. Note also that Outlook protection rules only apply to Outlook and not Outlook Web App. To clarify this further, Outlook protection rules only apply to Outlook 2010 when used with Exchange 2010 and not any previous versions.

Let’s take the example case where we wish to ensure that the RMS Do Not Forward template is applied to messages that have been sent by members of the Human Resource department. This is based on the assumption that these users have their Active Directory department attributes populated with the string Human Resources. To create an Outlook protection rule to achieve this, we have to use the Exchange Management Shell as it is not possible to create an Outlook protection rule using the Exchange Management Console. Specifically, we require the New-OutlookProtectionRule cmdlet which does have quite a few parameters available for use. To achieve our simple rule, we only require the Name, FromDepartment and ApplyRightsProtectionTemplate parameters. The full command to use is as follows:

New-OutlookProtectionRule –Name “HR No Forward” –FromDepartment “Human Resources” –ApplyRightsProtectionTemplate “Do Not Forward”

You can see the results of running this command in Figure 41.


Figure 41: Creation of a New Outlook Protection Rules

The Name parameter simply assigns a name to the Outlook protection rule so that it can be easily identified when using the Get-OutlookProtectionRule or Set-OutlookProtectionRule cmdlets. The FromDepartment parameter allows us to scope the rule to only fire if the user sending the message has an Active Directory department attribute that matches the value we specified in the command. Finally, the ApplyRightsProtectionTemplate parameter allows us to specify the name of the RMS template we wish to apply to this rule. As discussed previously in this article, only the Do Not Forward template is supplied with Exchange and hence this is the value that has been specified. You can use the Get-RMSTemplate cmdlet to retrieve a list of available templates, which was covered in part four of this article.

With the Outlook protection rule configured, a user that has an Active Directory department attribute set to Human Resources will find that the RMS Do Not Forward template is automatically applied to their messages. If you need to temporarily disable the Outlook protection rule, you can use the Disable-OutlookProtectionRule cmdlet. Similarly, the Enable-OutlookProtectionRule cmdlet can be used to re-enable it.

One other very important parameter of the New-OutlookProtectionRule cmdlet is the UserCanOverride parameter, which as its name suggests, controls whether the user can override the application of the rule within Outlook. This parameter is set to a value of true by default as you can see from our sample Outlook protection rule shown in Figure 42. If the user just sends a message in this scenario, the RMS template will be applied as expected. However, the user can override the application of the RMS template by selecting the No Restrictions option from the ribbon, which you can see immediately above the Do Not Forward option in Figure 40 above. Naturally, setting the UserCanOverride parameter to a value of false prevents the user from disabling the RMS template application.


Figure 42: Outlook Protection Rule Parameters

There are other parameters available for the New-OutlookProtectionRule cmdlet but I’ll leave that to you, the reader, to investigate further. It’s also important to note that the Outlook Protection Rules are available offline as they are evaluated and applied by Outlook and not by the Exchange server.

Summary

You have seen here in part five of this article that enabling and disabling RMS integration can be performed at various levels such as the Client Access Server, virtual directory or individual mailbox. We have also covered Outlook protection rules and how they can be used to automatically apply an RMS template to a message. We’ll be covering another form of protection rule, namely the transport protection rule, in part six.

If you would like to read the first part in this article series please go to:

Read Next

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