Lights On – For Now
Mergers and Acquisitions (M&A) happen to all sizes of organizations, and when they do, IT needs to be prepared for not only moving assets but also for turning off the lights as they leave. Activities required at the end of the merging process can be overlooked when it comes to cloud services like Microsoft 365. In this article, we will cover what components to concentrate efforts on as well as methods for handling this process. The key component is to have a process to validate, test, and confirm nothing will be lost.
Expectations
While most M&A activities happen one company at a time and this article is focused on that scenario, we can also scale these tasks up to several company consolidations at a time. Limitations here are specifically based on the toolset used to merge data, the support personnel involved, and the complexity and size of the environments. Know these limits and schedule activities based on this, as taking on too much will lead to mistakes and failed migrations. Do not forget the personnel supporting users when the merger is complete, as overwhelming users will lead to bad experiences and feedback or even monetary losses for an organization. Prioritize overall success.
Create a Break Glass Account
The first step in tenant consolidation is to create what is commonly known as a Break Glass account: A user account that can be used to log into a tenant with elevated permissions that is also excluded from all policies applied to users – think MFA, Conditional Access and others – so that administrators would be able to log in even if these other policy services are broken. It is also a protected account where credentials are stored in a safe location (could be physical or digital).
Tenants should always have some sort of Break Glass account during a merger, if not, one should be created. Credential protection should be based on the length and/or security requirements of the Source and Destination tenant owners.
Document Settings
Configuration settings may be a moot point if the destination tenant organization expects to be the final state, so discussions and decisions about transferring settings should happen before turning the lights off in a tenant.
At some point, the source tenant(s) will be unavailable and some time and effort should go into documenting as much information about those tenant(s) as possible. What should be documented? Below are some examples of relevant information that may be needed in the future:
- Exchange Online: Mailbox and Group email addresses, forwarding, holds, and user details.
- Teams/Group Mailboxes: Memberships, ownership, policies.
- Applications: Settings needed to recreate.
- MDO: Use ORCA to export settings (new feature).
- Azure: Subscription info and resources tied to the subscriptions.
- Purview: Labels, DLP, SITs, Communication Compliance, Classifiers and Policies.
- SharePoint: Sites, ownership, and sharing.
- Entra ID: Account details, including guest members and settings.
Tenant Cleanup
Consolidating and merging tenants have many dependencies that need to be dealt with for a smooth operation to occur. Let’s review. An important aspect of the consolidation process is to move over the SMTP domain that is associated with the source tenant and add it to the destination tenant. To do so, any objects in the source that are attached to this domain must be detached or changed.
Vanity Domain: Any domain that the organization owns and is registered with its tenant. Important Microsoft documentation on this can be found here and here.
Change Users Default Domain
You can change the domain in the Microsoft 365 Admin Center by browsing Users –> Active Users. Select all users and choose ‘Change Domains’, making sure to unselect your account which would otherwise block this action, then choose the best domain to change to (typically the tenants’ <tenant>.onmicrosoft.com domain). When the process is completed, we should receive a notification that all the users were converted. However, this is not always the case, and we will get information about the accounts Microsoft 365 was unable to update. If there are any users that do not convert, we can attempt to change the domain again as objects that contain this domain will block the domain’s removal from the tenant.
Consolidate Domain Usage View
In the Microsoft 365 Admin Center, browse to Settings –> Domains and choose a domain to analyze. Within this view, we see tabs for Users, Teams & Groups, and Apps. Each tab lists any dependencies that exist for the selected domain. A Domain cannot be removed until these tabs are empty.
Users Tab
The users tab should clear up with the domain change but may require some manual work. One issue that could occur is a user, with no assigned license, has an IM address or some other reference to the domain. Cleanup may require the assigning of a license which will allow manual removal of domain addresses as well as IM addresses that can be removed once the account is licensed.
Teams and Groups
Migration tools such as AvePoint and Quest can help move over Teams members (and owners) and chat data. However, we might need to recover settings and memberships later. With PowerShell, we can document aspects like Team membership.
Utilize these two great resources for Teams documenting:
Exporting Office 365 Group membership to a CSV file | Practical365
Microsoft 365 Groups Report with the PowerShell SDK (office365itpros.com)
Applications
When considering domain removal, registered apps in Entra may not come to mind, but they too can contain domains that need to be removed. App Settings are available in the App Registrations blade of the Entra admin center. Here we can match the apps from the Apps tab in the Microsoft 365 Admin Center to the Apps listed here. Open the app and look to see where the domain is specified. Typically, the domain is listed as a Scope (Expose the API tab for the app) and we either need to remove the scope or just change the App ID URI to something without the Domain we are removing.
Purview
Microsoft Purview’s plethora of features should be documented as there are moving parts here that may need to be moved over to the new tenant and an efficient way to do this is with PowerShell. Purview encompasses features like Sensitive Information Types, DLP, Priva, Retention and Sensitivity Labels, Communication Compliance, and Insider Risk. Like all aspects of a tenant migration, determine which components of Purview will move over prior to documenting.
In order to perform the below PowerShell code to document we need to connect to the Security and Compliance PowerShell endpoint with Connect-IPPSSession, which is part of the Exchange Online Management PowerShell module. Below are some samples of how to gather high-level data on Purview components.
Why document these features? Custom Sensitive Information Types (SITs) are important as these were created in the source tenant and will not be in the destination tenant. DLP Policies were used to apply SITs in the source tenant and may be needed in the destination tenant as well. Exact Data Match and Keyword Dictionaries are more complex SITs and exporting the settings for each will help recreate them in the destination tenant. The same can be said about Label Policies (Auto as well). Below is some sample code for this effort:
# Custom Sensitive Information Types
Get-DlpSensitiveInformationType | where {$_.Publisher -ne 'Microsoft Corporation'}
# DLP Policies
Get-DlpCompliancePolicy | ft DisplayName,Type,*location,enabled
# Exact Data Match (EDM)
Get-DlpEdmSchema | ft
# Keyword Dictionaries
Get-DlpKeywordDictionary | ft
# Label Policies
Get-AutoSensitivityLabelPolicy
Get-LabelPolicy
Documenting Purview settings will require screenshots or PowerShell. Prior to documenting, verify with the destination tenant administrators and IT management what settings will carry forward. If Labels are needed, make sure to document those settings and copy them into the destination tenant. Advanced planning will be needed to determine what documents were labeled in workloads like SharePoint, OneDrive, Teams, or even local File Servers if utilizing the Microsoft Purview Scanner product. If your organization is heavily invested in labeling, it will take some time to document the files affected and the labels used. Using PowerShell to discover these documents will speed up the process (SharePoint Example).
Sensitivity Labels may require more effort to move to a new tenant if they need to be moved and so documenting them will require a script along the lines documented here. Protected documents will need labels removed prior to moving to another tenant, migrating the files, and then applying labels in the destination tenant. This process should be planned, tested, and then executed prior to Lights Out in the source tenant. Encrypted file decryption can be performed in eDiscovery, but there are limitations to be aware of. Users with locally encrypted files will also need to remove encryption using File Explorer.
Turning Off the Lights
At this point, we should be ready to stop using the original tenant and can turn off the lights. Make sure to get all stakeholders to sign off on their respective areas of this tenant, making copies of this document for yourself and your manager.
Off It Goes
Then remove all licenses/subscriptions and billing information, remove payment methods, and make sure any existing agreements will expire without auto-renewal. With only the Break Glass account with access, carefully secured, the tenant should now be inactive, and all data removed after 30 days By Microsoft. We can also forcibly remove a tenant following the steps in this Microsoft document. Depending on your requirements, performing a backup to capture data is an option provided by third parties such as Veeam.
