Blog

Microsoft Purview Information Protection and Sensitivity Labels

In today’s post I will write about Microsoft Purview and especially about one particular part – Information protection and sensitivity labels. I will clarify a specific configuration when deploying your sensitivity labels.

As you know Microsoft Purview combines solutions and services together into a unified platform , as visualized below . My focus is on Protect Your Data:

What Are Sensitivity Labels?
Sensitivity labels are used to classify and protect your organization’s data. They help ensure that sensitive information is handled appropriately, whether it’s stored in documents, emails, or other types of content. Sensitivity labels can apply various protection settings, such as encryption, content markings (e.g., watermarks, headers, footers), and access restrictions.

Let’s get to the point 🙂

Recently I have participated in a tech event here in Belgium and had an interesting discussion about configuring sensitivity labels.

There are some new settings that are important and must be understood correctly by the M365 administrators configuring them.

In the screenshot above you can see the Access Control option – Assign permissions.

The two sometimes confusing options are:

  • Add all users and groups in your organization – all authenticated users to your Tenant(all tenant members) , let’s say all users authenticated with [email protected]. This option excludes Guest users!
  • Add any authenticated user, which is different and gives access to your data to anyone that:
    • Has an email account that’s authenticated by Microsoft Entra ID or a federated social provider.
    • Is authenticated by a Microsoft account.
    • Uses a one-time passcode for email only

For more information , check out this article:

Apply encryption using sensitivity labels | Microsoft Learn

If you have any questions or just want discuss the topic further, please reach out to me!

Have a great day 🙂

How such an active person migrated 15k+ Inactive mailboxes :)

What is an Inactive mailbox?

Employee movement – be it transfers, resignations, or retirement – is an inevitable aspect of each new work era. Microsoft 365 provides a seamless way to manage this process , for example, admins can make the mailboxes of these employees inactive, effectively preserving the data for legal, compliance or historical reasons.

An inactive mailbox is an email account that is still holding valid email data but is not actively being used anymore.

To make a mailbox inactive requires a hold on the mailbox and special licensing (minimum Exchange Online Plan 2 or a separate Exchange Online archiving license,if the mailbox is assigned an Exchange Online Plan 1 license). Then the mailbox or the user account is deleted and the active mailbox becomes inactive. Afterwards the inactive mailbox can be found by authorized people who have been granted eDiscovery permissions for compliance or legal reasons.

Why and how can these mailboxes be affectively migrated as part of merges and acquisitions projects?

Whether you outsource or integrate an existing enitity into a new company, most probably the new environment will be authorized to preserve former employees’ data for legal and compliance reasons (eDiscovery investigations if required).That’ s why most of the time Inactive mailboxes must be migrated like all other active mailboxes. In my situation ,the business decided to migrate all inactive mailboxes from Exchange Hybrid environment – 15k+ to a new tenant.

You need to start by discovering the inactive mailboxes by some unique criteria, for example based on a special email custom attribute showing to which entity the mailboxes belong, example: any exchange (custom)attribute holding the Company Name. To achieve this , you must rely on a consitent Identity provisioning process(the naming convention is a key). It will be useful to have also mailbox size statistics and if archives are present on the mailboxes,etc.

In the example below ,I am giving you a starting point 🙂 ( I personally created a custom script giving a detailed overview of the total data size and important Exchange attributes like I mentioned above and in the example below).

———————————————————————————–
$Litigationhold = Get-Mailbox -ResultSize Unlimited -Filter {LitigationHoldEnabled -eq $True} -IncludeInactiveMailbox | Select DistinguishedName,Name,FirstName,LastName,Alias,DisplayName,RecipientTypeDetails,PrimarySMTPAddress,LitigationHoldEnabled,LitigationHoldDate, LitigationHoldOwner, LitigationHoldDuration

###Getting all Recipients types of mailboxes in order to build up our hashtable with the Manager and Company details later.

$HashTableCompanyUserMailbox = @{}

$CompanyInfoUserMailbox = Get-Recipient -RecipientTypeDetails “UserMailbox”,”SharedMailbox”, “RoomMailbox”, “EquipmentMailbox”  -ResultSize Unlimited | Select Company,Alias, @{n=”Manager”;e={$_.ManagedBy -join “;”}} | ForEach-object {$HashTableCompanyUserMailbox.Add($_.Alias, [PSCustomObject]@{Company = $_.Company; Manager = $_.Manager})}

NOTE: You can combine the above objects and create a PSCustomObject consisting of all the needed Exchange stats and attributes and export it into a csv,which you can customize in excel.

———————————————————————————————————————-

Next, you must decide which migration solution to use based on an available budget and if you have an Enterprise agreement with Microsoft. In my case, I used the Microsoft Tenant to Tenant migration feature. It requires a per user license (one-time fee) and can be assigned either on the source or target user object.

There are also third party tools and  you can also perform a content search from the Microsoft Purview compliance portal and export results to a PST file,but if the number of inactive mailboxes is not too big (like in my case).

What is the process of migrating an Inactive mailbox with MS Tenant to Tenant migration feature?

This is how the high level process looks like. Bear in mind that there are some specifics when building the automation process which I won’t mention here in details! In a nutshell , you must test a lot before proceeding with real mailboxes.

Note: The Inactive mailbox normally is Reconnected to a temporary Entra ID account or sometimes a Restore to an empty mailbox is needed!

How can you create your T2T migration factory?

You can start with a simple CSV file and PowerShell scripts,covering the different steps of the migration, then evolve with Azure automation Runbooks or a function app. The second and third option require a lot of developing and scripting ,so you will need some advanced Powershell scripting skills 🙂

Reporting and monitoring

If you use a simple CSV file to control the whole process, you can add an error handling loging into your script and report the errors into the CSV.

If you use Azure automation , you can connect it to an Azure SQL database and then to a PowerBI dashboard, making sure that the business is informed about the different migration waves.

Some further tips and tricks

  • Use a very specific naming convention for the email addresses, displayname, alias etc when reconnecting the inactive mailbox.
  • Create cloud-only accounts with complex passwords.
  • Disable the accounts for security reasons.
  • As the purpose of an inactive mailbox is to preserve data and not for email forwarding scenarios , remove any unessarry email aliases after the mailbox is restored. It will ease the process of creating the dedicated mail users on the target tenant (if you use the MS Tenant to Tenant migration feature!).
  • Requires at least an Exchange Online Plan 2 or a separate Exchange Online archiving license to cover the mailbox size and litigationhold requirements.
  • The number of inactive mailboxes that can be migrated in parallel is limited by the number of licenses available on the source & target tenants, ideally it should be around the number of each wave you handle , let’s say 200 per wave.
    • You can re-use the licenses on the Source Tenant after execuitng the last step of the process – removing the temporary ENTRA ID accounts in the source tenant.
  • There is a risk for ambiguity in any of the email addresses or alias used by the InactiveMailbox, in that case we will need to open a Support Case with Microsoft to have those removed!
    • If you plan to cutover a domain to the target tenant, do it after the Inactive mailboxes (containing aliases with this domain) have been restored and migrated. Otherwise you will need Microsoft’s help to handle the inactive mailbox as it won’t be able to restore properly with the email alias connected to a domain that is no longer present on the current (source) tenant.

Conclusion

Inactive mailboxes are important because of the legal requirements for perserving data in every company and country.

The migration of inactive mailboxes is the same as normal mailboxes but they must be brought back properly into ‘active’ state and with an automated process that will ensure that there is no data loss!

If you have any questions, please reach out to me.

Have a great day ahead 🙂