This post has been republished via RSS; it originally appeared at: New blog articles in Microsoft Tech Community.

Some time after having introduced MIP for classifying and protecting content, an organization may find that it needs to merge with another company also using MIP or to spin off parts of the organization as part of their business plans.

In either case, preexisting content still needs to be accessible for users holding the appropriate roles and access rights in the corresponding organization. This blog post proposes methods for handling the configuration of AIP tenants during mergers and spinoffs in order to allow continued access to protected content.

With regards to labeled, but unprotected content, we refer to the blog post Cross-Tenant Label Visualization which allows the AIP client to interpret labels from other organizations. This blog post focuses on handling protected content during these processes.

Merger / Acquisition

In this section, we cover the required steps for combining the information protection platforms when one organization acquires another one. For instance, Contoso Inc. takes over Fabrikam Associates, both organizations already used AIP before the acquisition.

In case Fabrikam Associates still uses Azure RMS protection without AIP labels, the methods described below have to be understood the following way:

Everything involving AIP labels with predefined permissions is applicable to RMS templates.
Anything related to User Defined Permissions refers to ad-hoc protected content.

Assumptions for merger / acquisition

With regards to classification taxonomy and existing protected documents, we make the following assumptions:

Former Fabrikam users are getting an Azure AD account in the Contoso tenant (i.e. the acquiring entity).
The whole new entity will use labels of the acquiring entity. After the merger, all new content will be labelled/protected with labels defined in the Contoso tenant.
Former users of the Fabrikam tenant will either keep their old email addresses (with the @fabrikam.com email domain) or they get a @contoso.com address, but maintain the old address as a proxy address in the Azure AD of the Contoso tenant. In other words, migrated users can still be recognized by their old email addresses.
Protected content will need to be opened by users from either part of the organization. At least the users that were formerly allowed to open protected content are still allowed to do so after the merger. I.e. the capability to open some content may depend on where the content was originally protected.
Labels of old unprotected content from Fabrikam will only be visible on clients with the AIP plugin installed (see blog post Cross-Tenant Label Visualization).

Potential methods for merger / acquisition

«All roads lead to Rome» - there are multiple ways to keep existing content accessible to the original owners.

Since the AIP tenant of the acquiring organization (Contoso) continues to be used by the combined organization, no extra steps are needed for old Contoso content. The following methods allow continued consumption of content protected by the acquired organization, i.e. Fabrikam.

1) Keep the old AIP tenant in a «read-only» configuration

After the merger, the migrated users are no longer kept in the Azure AD tenant associated to the AIP tenant formerly belonging to Fabrikam and no AIP licenses will need to be assigned to end users in this tenant. This is possible since no new content is being protected with this tenant’s AIP infrastructure and as per above all new content will be protected with the Contoso policies.

This means, with minimal cost and effort it’s possible to keep the original tenant running with minimal licensing (as required to be able to administer it).

As part of the user migration, the DNS domain for these users (i.e. fabrikam.com) will need to be transferred to the new tenant. This is required in order to preserve the original email addresses for the migrated users either as main email addresses or as proxy addresses. This involves removing it as a verified domain from the original tenant, and adding it as a verified tenant in the target organization’s tenant. This will enable users in the target tenant to continue consuming content that grants rights to their original email addresses.

Mail-enabled groups with their members will also be migrated to the new tenant – maintaining their email addresses. This allows users to open content protected for specific groups as well.

Depending on how data was protected, some configuration steps will be needed:

Documents protected with an ad-hoc policy (e.g. User Defined Permissions) and emails protected with “Do Not Forward” will continue to be accessed by the same users that had access before.
This applies to content where individual email addresses were used to grant rights to documents or as recipients of a DNF email. It also applies to content that was ad-hoc protected using distribution lists.
Content protected using labels with admin-defined rights (templates) will continue to work, but some labels in the old tenant may need to be updated since references to “Fabrikam – All users” (i.e. the whole tenant) need to be replaced with a new DL in the Contoso tenant holding all the migrated users.
(Since groups have been migrated to the new tenant, group references in labels do not need to be updated.)

With these steps, the original tenant can be kept running and serving licenses to the content using the original keys and policies. Since this method requires minimal effort, it is often used as an initial step to get things up and running quickly, even if other options are planned to be implemented later.

2) Export / delete key from old tenant, import in new (joint) tenant

This option ensures the key and all labels with admin-defined rights from the old Fabrikam tenant are available in the Contoso tenant after the merger. Be aware that if the key in the Fabrikam tenant was based on BYOK, this option is only available when the key was originally prepared with an AD RMS infrastructure capable of supporting a cloud exit scenario (see blog post How to prepare an Azure Information Protection “Cloud Exit” plan).

The transfer of the key and the associated labels with predefined rights can be accomplished by the following three steps, which need to be arranged with Microsoft technical support:

Export Trusted Publishing Domain (TPD) from the Fabrikam tenant. This requires opening a support case with Microsoft so the support engineers can request the key export. Be aware that this process might take weeks due to the need to perform thorough verifications of the legitimacy of the request.
Delete the TPD in the Fabrikam tenant. This step can only be performed by Microsoft support operations, also requested through technical support.
Import TPD in the joint Contoso tenant after the original key was deleted.

It’s crucial to get at least steps 2) and 3) done in a synchronized way to ensure uninterrupted access to protected content. Depending on the load on support and operations and other time constraints, this combined change might need to be planned months ahead. Also, this change needs to be coordinated with the transfer of the DNS domain for the source tenant’s email addresses to the new domain (de-verifying the domain in the original tenant and verifying it in the target tenant) since both changes are critical to continued access to protected content.

Afterwards, the labels with predefined rights can be adapted to ensure the right groups are being referenced.

3) Rekey all content

The last option is to rekey all content, i.e. unprotect and classify/protect all content. The following prerequisites and limitations apply to this approach:

AIP super user rights on the source tenant are required for unprotecting content. Ensure the AIP super user feature is enabled and the user running the unprotecting / reclassifying operation has been granted respective rights.
Finding all content, especially old protected mails might be a challenging task for an organization.
Ad-hoc protected emails and documents cannot be easily re-protected after removing protection so third party tools might be required for these cases. For instance there’s no PowerShell tool available to determine which users have been granted which rights on the old content.

The following PowerShell commands are available both for the AIP client (classic) and the AIP unified labeling client. They may be used to determine and set/remove labels to documents:

The following commands are limited to the AIP client (classic), they allow you to determine and unprotect content:

This option might be combined with keeping the old AIP tenant in a «read-only» configuration. That way the old tenant is kept running while working on re-protecting content. By monitoring analytics in the source tenant, pockets of content missed during reprotection can be discovered. Eventually the original tenant may be turned off.

4) Create an AD RMS cluster (in «read-only mode») with the key of the old tenant

This is a temporary measure, only required until legacy data is no longer needed or another migration method has been completed successfully.

This option assumes the Trusted Publishing Domain (TPD) can be exported from the old Fabrikam AIP tenant and imported in a newly provisioned AD RMS server. If the old tenant used a BYOK and, this would work only if an AD RMS infrastructure was created for the source tenant beforehand in order to allow a cloud exit scenario (see blog post How to prepare an Azure Information Protection “Cloud Exit” plan).

Similar to a cloud exit scenario, registry overrides on Contoso Windows clients will ensure clients are redirected to the AD RMS cluster when opening content protected in the former Fabrikam tenant.

All local AD groups referenced in templates or in ad-hoc protected content need to be available in the AD of the joint organization to ensure content can be opened with the same rights.

The AD RMS server needs to be kept operational as long as protected content still needs to be opened - usually until one of the other migration methods described here has been implemented.

Please observe that access to content is limited to Windows clients with registry overrides.

Spinoff

This section describes how an organization spins off a business unit. For instance Contoso Inc. sells of their insurance branch into a separate legal entity «Woodgrove Insurance». Both organizations will continue to use AIP, but in separate tenants.

In case Contoso Inc. still uses Azure RMS protection without AIP labels, the methods described below have to be understood the following way:

Everything involving AIP labels with predefined permissions is applicable to RMS templates.
Anything related to User Defined Permissions is also applicable to ad-hoc protected content.

Assumptions for spinoff

With regards to classification taxonomy and existing protected documents, we make the following assumptions:

Remaining users will label/protect content with labels defined in the Contoso tenant. Members of Woodgrove Insurance will label/protect content with new labels defined in their new tenant.
Some of the existing protected content will continue to be opened by Woodgrove Insurance users.
Spinoff users will see old labels from old unprotected content only on clients with the AIP addin installed (see blog post Cross-Tenant Label Visualization).
Former users of the Contoso tenant migrated to the Woodgrove Insurance tenant are not keeping their old email addresses (ending with @contoso.com) – not even as a proxy address in the Azure AD of the Woodgrove tenant since the same DNS domain cannot be assigned to both tenants. Therefore, migrated users can no longer be recognized by their old email address.

Potential methods for spinoff

Three approaches may be taken to ensure content continues to be accessible both to users staying with Contoso and users migrated to Woodgrove Insurance.

1) Keep labels from the Contoso tenant accessible to Woodgrove users

In the Contoso tenant, keep some labels/templates with predefined permissions accessible for Woodgrove users. This can be achieved by adding the whole domain of Woodgrove Insurance or individual users of the new tenant to the predefined permissions of the respective labels.

Keep in mind that this option is only available for labels with predefined permissions.

2) Rekey all content

Another option is to rekey all content which needs to be transferred to the Woodgrove tenant. Thereby all content is unprotected and classified. The following prerequisites and limitations apply to this approach:

AIP super user rights are required for unprotecting content. Ensure the AIP super user feature is enabled and the user running the unprotecting / reclassifying operation has been granted respective rights.
Finding all content, especially old protected mails might be a challenging task for an organization.
Ad-Hoc protected emails and documents cannot be easily re-protected after removing protection.
PowerShell commands may be used to unprotect documents and mails.

The following PowerShell commands are available both for the AIP client (classic) and the AIP unified labeling client. They may be used to determine and set/remove labels to documents:

The following commands are limited to the AIP client (classic), they allow you to determine and unprotect content:

3) Create an AD RMS cluster (in «read-only mode») with the key of the Contoso tenant

This option assumes the Trusted Publishing Domain (TPD) can be exported from the Contoso AIP tenant and imported in a newly provisioned AD RMS server in the Woodgrove environment. If the old tenant used a BYOK and, this would work only if an AD RMS infrastructure was created for allowing a cloud exit scenario (see blog post How to prepare an Azure Information Protection “Cloud Exit” plan).

Similar to a cloud exit scenario, registry overrides on Woodgrove Windows clients will ensure clients access the AD RMS cluster when opening content protected in the Contoso tenant.

All local AD groups referenced in templates or in ad-hoc protected content need to be available in the AD of Woodgrove to ensure content can be opened with the same rights.

The AD RMS server needs to be kept operational as long as protected content still needs to be opened.

To prevent Woodgrove users from accessing new content protected in the Contoso tenant, Contoso may implement BYOK or switch to a newly created BYOK respectively.

One limitation of this aproach is that Woodgrove Windows clients with these registry overrides cannot open any content Contoso protects with the new key – even if such content is meant to be shared with Woodgrove.
By removing the registry overrides, Woodgrove clients would be able to access the content protected with the new key – but would lose access to the key protected with the old key.

Mergers and Spinoffs