This is the last article of my Exchange Online PST Migration automation approach. In the first parts we’ve reported the Mailbox Configuration, exported the mailbox content to PST’s, uploaded the PST’s and imported them into the destination mailboxes. So, the content migration is done now. Now, as a final step, I will show you a way and share the functions and scripts you can use to enrich our PST Migration with a downstream configuration migration.

I’ve already spoilered this in the first part of the series because the steps we’ve done there are the base of the reapplying I will show you today. We’ve used the cmdlet Export-Clixml in the source environment to report all the settings and configurations of named users. Now we use these XML-Files to reapply some of the configurations.

I don’t have the ambition to reapply every lit bit of the mailbox configuration, but the ones I will share with you are the ones with which I often deal in this or similar migration scenarios.

What you need

MappingTable: You need the PST Import Table which we’ve generated in the last part. It should contain a line for every mailbox that should be handled in the following script. We translate the Mailbox Access Entries etc from the Source Mailbox Settings using this table by finding the matching DestinationUserPrincipalName for our SourceUserPrincipalName.

Report Files: The Report XML-Files we’ve generated in the first part. They contain all the settings of the source mailboxes which we will reapply now. Maybe you want to refresh them now if you want to reapply the latest state.

Reapply Settings

What I’ve already included within the shared script are functions for the following:

Mailbox Regional Settings (function reapply-mailboxRegionalSettings): We will replace the mailbox regional settings (Language, Timeformat, DateFormat & Timezone) of the mailbox in the destination with the regional settings of the source mailbox (MBXRegionalConfiguration_….XML). If no regional setting was defined in the source we apply a new default for the mailboxes.

Full Access Permissions (function reapply-fullAccessPermissions): We will check if there were full access permission for mailboxes defined in the MBXPermissions_….XML. If so we use the mapping table to find the counterpart of the permitted user within the destination environment and use this counterpart for a new permission-entry.

Send-As Permissions (function reapply-sendAsPermissions): Similar to the full access permissions. We will check the MBXRecipientPermissions_….XML for Send-As entries and reapply them.

Forwarding Settings (function reapplyMailboxForwardingSettings): If there were found configured mailbox forwarding settings (e.g. forward every mail to a delegate with inbox-copy to the original mailbox) they are stored in the MBXSettings_….XML.

MessageCopy Settings function (reapply-MailboxMessageCopyConfiguration): If an admin has configured e.g. all sent emails from a shared mailbox should be stored in the sent items if the shared mailbox, we reapply this setting also in the new environment. We read it out from the MBXSettings_….XML.

You can now download the following script from Github: thinBlog/Reapply-SettingsAndPermissions.ps1 at main · thinformatics/thinBlog (github.com). With that collection of functions, you will be able to loop through all mailboxes defined in the CSV and apply the „translated“ settings to the mailboxes in the destination.

To do so just replace the values for the report files and a transcript output path in the lines 1-6:

In lines 9-217 the functions were defined we use to reapply all the settings. If you need additional settings to be reapplied (like send on behalf, e-Mail Aliases …) you could easily copy a similar function here and adjust it to your needs.

It is all very straightforward. We import the relevant XML of the processed mailbox(, look up a counterpart using the mapping table,) and apply the settings from the XML to the new mailbox.

What you should do in every case is to review the default/failover mailbox regional settings which are defined in lines 28-40.

Now that the functions are defined we’re ready to use them. To do so I loop through the MappingTable CSV and start every defined function for every entry in the CSV. I use try/catch statements to do some error handling.

Furthermore, a transcript will be stored for every mailbox which contains the output for every task. You could use the transcript later if there have been issues in the reassignment.

The script also generates some output to let you know what is done right now. To debug stuff you could use the transcription logs.

You could reapply all settings as often as you want. Just export the settings from the source environment again and reapply them again. The settings will be overwritten with the actual values which were stored in the XML files. New Permission Entries will be added, but existing ones will not be touched.

Conclusion

That’s it! Let me repeat what I said in my first article of this series. I hope you can use the native T2T Migration Method that Microsoft offers (https://learn.microsoft.com/en-us/microsoft-365/enterprise/cross-tenant-mailbox-migration?view=o365-worldwide) to migrate Exchange Mailboxes and more from one Tenant to another.

But if there are circumstances that prevent you from doing it, and you need to fall back on a content-only migration like a PST Migration, then I think the might found the described methods useful. They can help you to optimize the migration performance and quality. With the last step, I’ve shared today you can also mitigate some of the migration pains which are primarily relevant to the end user. They will help you to reduce user frustration and keep your support calls lower.