In a recent project of mine, I had the following task:

  • we are to migrate a small company (whom is using an outdated, Microsoft SBS forest domain, with Exchange 2010 on-prem)
  • to a new AD 2019 (running on 2012 forest level for compatibility) forest; in this post I will focus on their mailbox migration

The current setup:

  • the forest/domain for the company is currently CompanyA.local. The email domain is
  • as has already been added to our O 365 tenant – without emails as of yet, only a handful of users using it for software licenses, we could not just create the new domain, sync, and move – as that would have prevent internal DNS, since O 365 would have taken over the internal MX records – undesirable.

The plan

  • I have created in our normal production forest – which is trusted to company-A.local – a new domain, with netbios COMPANY-A and FQDN
  • This domain should be populated with identically named users from the company-A.local domain (they are named the same, but completely independent from the original users, but would have the same email address )
  • This should be synced to AAD – but only at the day of migration, ro prevent email routing issues; users should be allocated fresh mailboxes / licenses
  • We would then export the .pst files from the on-prem Exchange server for each user to a shared drive
  • Upload these based on the email addresses to the new email accounts
  • Users then should be instructed to log in to the new Windows accounts and find their mailboxes migrated
  1. Exporting PST files

1. Exporting the mailboxes

It was a relatively easy task to write a script, that creates a few functions and uses these to do the export. The code had to run on the Exchange server (or another server in the same domain with the exchange module loaded…I used a domain controller in fact)

It is arguably not my most sophisticated work, but it is serviceable.
For those whom might need details:
– I first create 3 function, then the run the first two.
– one generates a .csv file – used latter for the .pst upload – and exports all the .pst files
– the second function is started right after the export request, and it starts a loop to monitor the export requests, until there is no more in Queued/In progress status
– the third is for the admin to clean up at the end, to remove the completed requests

2. Importing the mailboxes

Now the more complex part. Reference link.

I will walk trough a dry-run.

  • First we install AzCopy. Then we go to it’s install folder. (by default: C:\Program Files (x86)\Microsoft SDKs\Azure\AzCopy\)
  • Next, we need an import URL. Log in here.
Note, you want to tick the mapping file, which is the .csv we created earlier
  • We construct a few parameters.
  • Next, we run the upload.
  • We can verify the log file too
These were just test mailboxes, with minimal size – hence the very short time.
  • Also you can check the AZURE storage explorer
  • Continue on the Office portal with the validation using the .csv

After this the import job should be done by Azure. As in our case I detailed the test run – and the mailboxes are not yet present in 0365 – I can’t show this now, but it is very straightforward.