Inspired by the article „Exchange Online Tenant to Tenant migration with free Microsoft methods!“ by Alexander Holmset I’ve decided to write this article as a kind of addition to the explained Exchange Content Migration Method.

Even though I think that an Exchange migration using the preview Method Cross-tenant mailbox migration – Microsoft 365 Enterprise | Microsoft Learn is a better approach to get Tenant to Tenant migrations done and fulfill user expectations, there might be situations where you can not use that approach. If you e.g. already have existing mailboxes in both (source and destination tenant) and maybe even content in the target user profiles, you have to choose another migration method.

In this article series I will explain how to use the PST Export / Import method, Alex explains in his article step by step, in a more automated way to also get done more bigger and more complex migrations.

PST Migration downsides

If you have to get the migration done using a pst based approach you were confronted with the downsides of this method. The PST only contains the content of the mailbox and not all the other mailbox-related settings like

Permissions: Mailbox Full-Access and SendAs Permissions for users and groups, Mailbox Folder Permissions

Settings & Configurations: Like E-Mail Aliases, Forwarding-Settings and Message Copies, Like RegionalSettings, Calendar-Processing

Other issues that come up in PST Based Migrations are e.g. scheduling of cohorts, end-user expectations of migration results, pst->user mappings, data integrity of the pst files, automation in exchange online-based pst migration scenarios, etc.

This list and more are reasons why you should prefer another kind of migration. But, as learned from real life, sometimes you don’t have a choice about which methods you are able to use. I will try to explain an approach that helps to mitigate some of the named downsides and make pst based Exchange migration results better.

While starting this article and reviewing my existing scripts etc. I recognized that it will be too much stuff to explain in one article. Furthermore, no migration scenario equals the other. That’s why I’ve decided to make a series from it to make the single components and methods more accessible and modular to fit other requirements.

Prepare PST Migration

In this first part of the article series, I will show you an essential step for the preparation of an automated pst migration approach. To be able to migrate not only mailbox content but also configurations and settings (like permissions, forwarding, regional settings, …) additionally you first need to dump the configuration before.

A PST Migration for a relevant mass of users and data Is nothing you handle in a few hours. So I’ve chosen a pragmatic way to export all settings and configurations in XML files, to be able to actualize &/ reapply them at a later point in time.

After finishing the following you will have files stored in user directories that contain all relevant settings and configurations of mailboxes in your exchange online environment with the aim to be able to reapply them in the destination environment

Exchange Online Migration. Also in that well-matured scenario, some settings and configurations will not be applied (like forwarding settings, some group-based permissions, etc.). I think that this kind of report is usable in a lot of scenarios.

By the way: I developed this approach originally as an addition to an Exchange OnPrem -> Exchange Online Migration. Also in that well-matured scenario, some settings and configurations will not be applied (like forwarding settings, some group-based permissions, etc.). I think that this kind of report is usable in a lot of scenarios.

Besides configurations, we will also report mailbox folder statistics to be able to identify missing content if users complain cause they can not find their folders which they maybe had favorited before.

All you need to get this job done is an Exchange Admin and PowerShell with the Exchange Online module. To be able to just handle named mailboxes I’ve used a CSV which contains the primary E-Mail Address of all mailboxes that should be reported. My CSV looks like this:

EmailAddress

DiegoS@nkq6.onmicrosoft.com

HenriettaM@nkq6.onmicrosoft.com

LeeG@nkq6.onmicrosoft.com

You could generate the CSV e.g. by exporting DistributionGroup Memberships using this command:

Get-DistributionGroupMember MBXToMigrate |select @{Name="EMailAddresses"; Expression={$_.PrimarySMTPAddress}} |export-csv c:\temp\mbxusers.csv -Delimiter ';' -NoClobber -NoTypeInformation

When you have created the CSV you just need to download the following script from GitHub:

thinBlog/Report-MailboxConfiguration.ps1 at main · thinformatics/thinBlog (github.com)

Within the script just need to modify the vars for:

$CSVPath = Path the CSV described above

$ReportBasePath = Path where the XML should be saved

Afterward, run the script, log on to the source Tenant, and sit back while the script is running through all named mailboxes and creates the XML Files.

The result were folders, named like the primary E-Mail Address of the exported users. In these folders, the XML Files were stored which contain the different relevant settings and configurations.

You can prove them by importing and outputting them again into PowerShell with a command like this:

MBXSettings=Import-Clixml -Path 'C:\git\thinBlog\pst ex import\Export\DiegoS@nkq6.onmicrosoft.com\MBXSettings_DiegoS@nkq6.onmicrosoft.com.xml'
$MBXSettings | select *

Now we have stored all relevant settings of the mailboxes which we need to export. You can repeat this as long as you have access to the source environment to be able later to reapply the latest settings again.

Next

In the next articles of this series, I will show you how to export and import the pst files again supported by automation using Azure Blob Storage and New-MailboxImportRequest. Afterward, we will reapply some settings using PowerShell to demonstrate the possibilities of this method.

Part II (Exporting Mailbox Content to PSTs): Tenant-to-Tenant – PST based Exchange Migration automation approach – Part II