If you would like to read the first part in this article series please go to The Azure RMS Connector (Part 1).
Introduction
In part one of this article, I first briefly discussed what the RMS connector is used for and then went onto looking at how it was installed into my lab ready for use by the on-premises Exchange 2013 server. Before the Exchange 2013 server can use the RMS connector, both the RMS connector and the Exchange 2013 server itself need to be configured appropriately. Here in part two I will look at these two tasks as performed in my lab, followed by checking the Exchange 2013 transport rules to ensure that they can take advantage of the Azure Rights Management Service.
That last point is obviously important, as without the RMS connector being present and configured appropriately the Exchange 2013 transport rules could not see and therefore use any RMS templates in my lab. Before commencing any of the configuration in this article within my lab, I first attempted to enable the Information Rights Management (IRM) feature in Exchange 2013 to see what error I would get if I didn’t have either an on-premises or cloud-based RMS deployment. The Exchange Management Shell command I used is detailed below, and note the error that it gave me:
[PS] C:\>Set-IRMConfiguration -InternalLicensingEnabled $true
No RMS server was found. This setting requires an RMS server to be configured to communicate with Hub Transport server. Please ensure this is set up correctly to enable IRM features.
Similarly, I noted that running the Get-RMSTemplate cmdlet produced no results as there were no RMS templates to use. With that in mind, I will now look at how I configured the RMS connector to enable the required functionality.
Configuring the RMS Connector
In Figure 1-8 in part one of this article, there was an option to launch the RMS connector administration console right after the installation of the RMS connector had completed. Since I elected to launch the administration console straight away after installation, I was presented with the administration console screen shown in Figure 2-1. I noted that when I was launching the administration console from the desktop icon created, I needed to authenticate again.
Figure 2-1: RMS Connector Administration Console
At this point, I was ready to add my Exchange 2013 on-premises server to the list of servers that are authorized to use the RMS connector. To do this, I performed the following sequence of events:
- In the RMS connector administrator console screen shown previously in Figure 2-1, I clicked the Add button.
- The resulting screen shown below in Figure 2-2 was shown. In the Role drop-down field, I selected the Exchange Server option since I was adding an Exchange server. The other options listed were SharePoint Server and FCI Server, since the RMS connector also permits connections to SharePoint and Windows file servers. Note in Figure 2-2 the Updates must be installed… warning that is also displayed on this screen. This relates to the script that I downloaded earlier. I will discuss this later in the article.
Figure 2-2: Adding an Exchange Server
Note:
I wanted to separately discuss the Account or group field in Figure 2-2. This is an important configuration area to understand due to the security implications of this configuration. Since I only needed to add a single Exchange server to the RMS connector, that’s exactly what I did: just add a single server name to the list of authorized servers. However, in addition to a computer account, it’s also possible to specify a group or a service account so it’s important to understand which objects are being authorized. For more information, see the area Authorizing servers to use the RMS connector in the topic titled Deploying the Azure Rights Management Connector.
- Once I had correctly identified my Exchange 2013 on-premises server, I clicked OK in Figure 2-2 to add the Exchange 2013 server to the list of authorized servers permitted to use the RMS connector. The result is shown in Figure 2-3.
Figure 2-3: Exchange Server Authorized
Configuring the Exchange Server
Once the RMS connector had been installed and my Exchange 2013 on-premises server authorized in the RMS connector administration console, it was time to configure the Exchange 2013 server to complete the overall configuration process. This is where the script that I downloaded earlier came into effect. The reason for this is because registry changes are required on the Exchange 2013 server to complete the overall configuration process and tell Exchange 2013 where to find the RMS service in the cloud. Although it’s possible to manually configure these registry changes, I chose to use the supplied script. Let’s see what happened during this process:
- First I ensured the script was available locally on the Exchange 2013 server. Remember, this is the GenConnectorConfig.ps1 script downloaded earlier and this must be run from the Exchange 2013 server, not the server running the RMS connector.
- When I ran the script, it required two parameters for my particular scenario:
- –ConnectorUri. This is used to specify the URL of the connector that I had installed. In a load-balanced scenario, this would be the load-balance name such as https://rmsconnector.contoso.com or similar, where the rmsconnector hostname would point to the load balancer. In my lab scenario, I was only using a single connector server so my URL was simply https://nghuk-rmsconn.nghcloud.uk as can be seen from Figure 2-4. Note that I did not specify anything else for the –ConnectorUri parameter, such as virtual directory names for example, since the script appeared to add these to the various registry keys as required
- –SetExchange2013. This is required to configure the local Exchange 2013 server’s registry with the correct values.
Figure 2-4: Running the GenConnectorConfig.ps1 Script
As can be seen from Figure 2-4, the script did not give me any feedback on any errors encountered, so I assumed that it had run successfully. In order to confirm this, I decided to open the script to examine what configuration changes it makes. I noted from the script that using the –SetExchange2013 parameter appeared to instruct the script to create and execute a registry update file that made changes to the following registry keys:
- HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ExchangeServer\V15\IRM\CertificationServerRedirection
- HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ExchangeServer\V15\IRM\LicenseServerRedirection
Opening the registry on my Exchange 2013 server, I navigated to those registry key locations and found the data values had been set to the URI that I had specified in the –ConnectorUri parameter when running the script. An example is shown below in Figure 2-5.
Figure 2-5: Script Registry Change Example
The script is very much more powerful than the simple example I’ve used in this article. For example, the script contains a CreateGPOScript parameter that causes the script to create a PowerShell script to create a Group Policy Object (GPO) to be used with the Group Policy Editor. It is a good idea to check out the script features and operation in full.
Enabling IRM for the Exchange Server
At this point, it now looked like I was ready to enable Information Rights Management on my on-premises Exchange 2013 server via the Set-IRMConfiguration cmdlet. The full command that I used to do this was:
Set-IRMConfiguration –InternalLicensingEnabled $true
The moment that this command had completed successfully, I was then also able to run the Get-RMSTemplate command and retrieve the base RMS templates. As a final test, I created a new transport rule to use one of the RMS templates via the following procedure:
- I opened the Exchange Administration Console on the on-premises Exchange 2013 server
- Next, I navigated to Mail Flow and selected the Rules tab
- By clicking the plus (+) symbol to create a new transport rule, I then chose Apply rights protection to messages from the resulting menu
- In the New Rule screen, I clicked the Select one… link which then allowed me to select one of the RMS templates now available, which in this case was the Do Not Forward template. The results can be seen in Figure 2-6
Figure 2-6: Transport Rule Using RMS Template
Summary
That completes this two-part article looking at the Azure RMS Connector that permits use of Azure Rights Management Services with on-premises Exchange, SharePoint and Windows file servers. Hopefully as seen with my experiences in the lab in this article, it was a fairly quick process to get the RMS connector deployed and configured to the point where the RMS templates were visible to the on-premises Exchange 2013 server.
If you would like to read the first part in this article series please go to The Azure RMS Connector (Part 1).
