Skip to content

Enterprise Mobility + Security


Hi Everyone,

Back in October we blogged about some new and upcoming features we were building into Azure RMS. Today we are excited to announce that we are releasing the Azure RMS migration toolkit, new Azure RMS onboarding controls, new updates to RMS SDK and RMS sharing app for Windows Phone 8.1, and the introduction of departmental templates.

Let’s review each of these in detail.

Reminders: Follow us on twitter (@TheRMSGuy) and join in our community on Yammer.

 

Azure RMS migration toolkit

Many organizations that have been using AD RMS have asked to move to Azure RMS. Some want to benefit from the rapid pace of innovation seen with Azure RMS. Others want to benefit from the new scenarios enabled by this modern platform (e.g.: B2B sharing). Yet others using Windows RMS on Windows Server 2003 need to upgrade anyway and want to make the change during that event. For all these cases, we are now releasing the Azure RMS migration toolkit. This toolkit enables AD RMS and Windows RMS customers to migrate to Azure RMS without losing access to their existing RMS-protected content or their policies.

The Azure RMS migration toolkit includes all the materials necessary for a successful migration, including tools, configuration scripts, and detailed guidance. We’ve worked with over a dozen large organizations already and we expect many more of you will want to make the switch.

Step By Step — Azure RMS migration toolkit

A migration to Azure RMS begins with the creation of an Azure RMS tenant. This can be any Azure AD tenant with RMS activated, including one that is part of an Office 365 subscription. Once the tenant is created and configured to support the organization’s users, the company migrates their keys and templates to the cloud to enable the service to support content that is already protected by their old AD RMS platform.

You can import the AD RMS keys into Azure RMS using the updated PowerShell module:

PS C:> Connect-AadrmService

PS C:> $Password = Read-Host -AsSecureString -Prompt "Password: "

PS C:> Import-AadrmTpd -TpdFile E:MyTPD.xml -ProtectionPassword $Password –Active $true -Verbose

This example imports your AD RMS keys and templates into Azure RMS.

Alternatively, you can migrate your keys using the Bring your Own Key (BYOK) process, which places the keys in a Hardware Security Module inside Microsoft’s hosted environment. This process is designed so that Microsoft can’t see or extract (thus leak) your keys. You, the customer, remain in control of the keys at all times.

This BYOK step is also possible even when the original keys in AD RMS were not stored in a Hardware Security Module. We simply ask that you use the migration tools to first move your keys into a Hardware Security Module on your own premises and then performing a synchronization of the keys to the cloud. This way the design goal of our not seeing your keys is preserved.

During the migration process, the existing AD RMS rights policy templates are also migrated. They are marked as ‘archived’ Azure RMS custom templates. You of course have the ability to change and/or publish the templates you want to use, after they are imported.

For you advanced admins, if your organization is using multiple keys to protect content, you can choose to make one of these keys active, and import the other keys as archived keys, which lets users open previously protected content, but has Azure RMS protect all new content with the key that you designate as active.

An example of how you might import multiple keys and designate which one to be active:

PS C:> Connect-AadrmService

PS C:> $Password = Read-Host -AsSecureString -Prompt "Password: "

PS C:> Import-AadrmTpd -TpdFile E:MyTPD.xml -ProtectionPassword $Password –Active $true -Verbose

PS C:> Import-AadrmTpd -TpdFile E:MyTPD2.xml -ProtectionPassword $Password –Active $false -Verbose

After the tenant is ready with the imported active keys and templates, users can use Azure RMS. In order to do this, their devices need to be reconfigured to use Azure RMS instead of on-premises servers running RMS. To do this, use the configuration scripts and guidance provided with the toolkit. During your migration process your users in Azure RMS can open content from users who use the on-premises RMS [Note: that if the migration is going to be performed over an extended period full two-way exchange of protected content between migrated and non-migrated users may require additional configurations. Pay special attention to the doc if this is the case for you].

An organization using Exchange, SharePoint and FCI integrated with AD RMS can continue to do so. These are features such as Exchange with IRM integration in OWA, or SharePoint libraries that automatically protect documents, or FCI on file servers. To use these workloads you will deploy the Azure RMS connector. This offer ‘connects’ Azure RMS with your on-premises services.

As a final step – after completing these steps and verifying that your AD RMS servers are no longer in use by any clients or servers — you can decommission the AD RMS cluster and remove references in your environment to the old infrastructure. This is done by querying the AD RMS statistics reports.

At that point pop a bottle of bubbly and celebrate your being fully migrated to Azure RMS!

Learn more about migration: Migrating from AD RMS to Azure Rights Management

 

Onboarding Controls

If you’re deploying Azure RMS in a large organization you might feel a little uneasy about turning it on all at once. That’s ok, we listened and now understand… the latest Azure RMS PowerShell module supports a phased deployment of Azure RMS. This lets you designate a subset of users who can start to protect content with Azure RMS. This deployment configuration is useful when first deploying Azure RMS, because it lets an organization build up Azure RMS usage at its own pace. There are many reasons for this. Those who want this already know them.

For example, you can use the following PowerShell command to control which users can use Azure RMS by adding them to a designated group:


Alternatively, you can use the same control to ensure that only users who are correctly licensed to use Azure RMS can protect content. For example:


Learn more about configuring the onboarding controls: Set-AadrmOnboardingControlPolicy  

Departmental Templates

Today we are launching the public preview of a powerful enhancement to custom templates in Azure RMS. This one is a customer favorite / long standing top 3 ask! This feature permits organizations to make some templates available to a subset of their users. We call this option “departmental templates” and it consists of an additional parameter for each template, its “scope”, where you can designate groups that will receive this template.

This enables you to define a much larger numbers of ‘departmental’ templates that meet the needs of users in specific departments, roles, or divisions. Our many Azure RMS partners — Gigatrust, Secure Island, TITUS, and Watchful Software — enable powerful tools to manage these templates just like an IAM solution helps IT manage groups.

The basics are, well, quite basic: the scope controls which users will see the template as available to select when they want to protect new content. The rights within the template continue to control which users can view content that is protected with a particular template.

Example make this easier. An organization might want to define a template specifically for the Engineering department. The configuration of the template is such that it’s applicable to users in the engineering department only and should not be used by other departments. To do so, create a custom template with the required rights in the Azure RMS management portal, navigate to the SCOPE option in the template, and specify a group that includes people in the engineering department only.


One configured, only users in the engineering department will see this new template. This template isn’t visible to other users, so they can’t (incorrectly) select it.

 In this very simplistic example, here’s what an Engineering department user will see:

 

 

Here’s what other users will see:

 

You can also define departmental templates for users in specific employee roles, groups within the organization (e.g. “Executive Board Confidential”), projects, or business accounts, or even for IT processes that are not exposed directly to users. A departmental template can be assigned to anything that can be defined via a group or list of groups.

To display departmental templates according to the user’s identity, an application must support this feature. The RMS Sharing application already supports departmental templates so start with that. Other applications and Office 2013 are being updated over the next few months with this support. Just to make sure you don’t miss this, Office 2013 does not yet support this capability… it will be added shortly in the form of a service pack. Get all your early testing done with RMS sharing app.

Learn more about departmental templates from our Azure RMS Custom Templates documentation

NOTE: If you want to use this feature before Office ships it, you can do so using a template deployment script that downloads regular and departmental templates based on the user’s identity and makes them available to Office and other applications. When all your RMS-enlightened applications are updated to natively support departmental templates, this script is no longer needed and the applications will automatically display the departmental templates according to your configuration.

 

Updates for Windows Phone

A few months ago, we updated the RMS SDK and RMS sharing app for iOS, Android and Mac to support the PPDF scenarios and AD RMS Mobile Device Extensions (MDE). We now have Windows Phone as well. Enjoy! 

An RMS sharing app for Windows Phone is now available in the Windows Phone store.

We have also shipped the RMS SDK 4.1 for Windows Phone. RMS developers for Windows Phone will be able to use the updated RMS SDK 4.1 to provide the functionality that their counterparts on iOS, Android and Mac were able to provide. Primarily this includes:

  • AD RMS support – IT admins can use RMS enabled applications on mobile devices with AD RMS server (MDE). 
  • Offline Consumption – end-users can access RMS protected data offline.
  • Segregated Authentication – developers can use their own authentication library for Azure RMS and AD RMS (or use the recommended Active Directory Auth Library).
  • Segregated UI – developers can build their user interface to protect and consume RMS protected documents.

 Developer documentation is available here. You can download the latest build from here

 

RMS updates for Windows desktops

RMS sharing app has also been updated with many bug fixes in template management, localization, diagnostics, stability and quality. It is being rolled out now. You will soon receive a notification for upgrade when try to use ‘Share Protected’. Learn more about the update in release notes.

Also, the RMS SDK 2.1 is available here. Learn more about the update in release notes.

 

We hope that you will see the above as a commitment to listening to your feedback and adding the features and enhancements you most want. We will keep meeting with you and people like you so stay tuned for further updates and new features in coming months… there are some wicked cool features coming real soon so listen in on @TheRMSGuy and join our advisory board to vote on what should come next

Thanks for your continued support!

    Dan on behalf of our excellent team
    @TheRMSGuy