Exchange 2019: Setting up a hybrid environment (part 5)

The Exchange 2019 Hybrid environment has already been Part 4 set up. I actually wanted to go into more detail about migration batches in this article, but decided against it. The migration batches and their options are usually only relevant in larger environments. In smaller environments, migration batches can be easily managed via the Exchange Online Admin Center. Only when there are many mailboxes do you need to think about scripts, migration endpoints and CSV files.

I assume that most people reading this series of articles want to migrate a manageable number of mailboxes to Microsoft 365. Also, probably very few want to operate a hybrid environment permanently, but want to migrate completely to Microsoft 365. This last article on the Exchange 2019 hybrid environment therefore deals with the necessity of the "last Exchange server" and a few special features that need to be taken into account. There will then be another article: Exchange 2019 Hybrid to Cloud Only (i.e. the dismantling of the hybrid environment to Microsoft 365 without Exchange Hybrid).

Migration Batches

The migration batches can be used to plan the migration of mailboxes quite well. It should be noted that the user is prompted to restart Outlook after the mailbox has been moved. So that users are not inconvenienced by an Outlook restart in the middle of the day, the completion of the migration batches can be scheduled and postponed to the weekend, for example:

If you want to include a large number of mailboxes in a migration batch, you do not have to select and add each mailbox manually. A CSV file can be used to conveniently split the mailboxes into different batches and automate the migration of the data.

For example, the following command can be used to create a CSV file with all mailboxes:

get-mailbox -ResultSize unlimited | Select-Object -Property @{Name = 'EmailAddress'; Expression = {$_.PrimarySmtpAddress}} | Export-Csv c:\install\batch.csv -NoTypeInformation

If necessary, the mailboxes can also be filtered along the way, or the CSV file can be edited with an editor.

The CSV files for the migration batches can also be created via the Exchange Admin Center:

Only the "e-mail address" attribute is required here:

In the CSV created via the Exchange Admin Center, however, the first line must be changed once to "EmailAddress":

AADConnect and the last Exchange Server

The topic of AADConnect and the last Exchange Server is already quite old and still causes frustration. Actually, it is a rather trivial problem, but unfortunately it has still not been solved by Microsoft (as of December 2021). The problem is as follows: If AADConnect is used to synchronize the local AD accounts to Azure Active Directory, the local Active Directory is the "leading system".

The big problem

Certain changes to the objects synchronized via AAConnect (e.g. groups and user accounts) must be made in the local AD and cannot be changed in Azure Active Directory. For example, changing or adding an e-mail address to a mailbox is not possible in Exchange Online, but only in the local AD. If, for example, an attempt is made to add an email address in Exchange Online to a user synchronized via AADConnect, this is not possible and the following error message appears:

In this case, the new e-mail address for the mailbox must be added to the local Exchange server (or in the local AD):

Adding the address is actually just a change to the local AD attribute "ProxyAddresses", this change is then synchronized to AzureAD via AADConnect and Exchange Online can use the new address.

The consequence of the problem

For example, to add an e-mail address to a user account synchronized via AADConnect, a local Exchange Server is required as a "GUI" or "Administrative Exchange Server". Without the local Exchange Server, it is simply not possible to add an email address via the Exchange Management Shell or Exchange Admin Center. Even if all mailboxes have already been migrated to Microsoft 365, a final Exchange Server is required to manage the Exchange Online mailboxes, simply because the change must take place in the on-prem AD and only then is it transferred from the local AD to AzureAD using AADConnet.

Now you could come up with the idea of simply changing the attribute directly in the local AD, without Exchange Shell or Exchange Admin Center. However, this is exactly what Microsoft does not support. In practice, this is also likely to be quite cumbersome, as it is not just about the mail addresses, but also about many other settings. Who knows exactly which attribute is responsible for which setting and what the exact syntax is?

So as long as AADConnect is in use and local AD accounts are synchronized to AzureAD, a lone local Exchange server is needed to manage the settings. Exactly this problem has been on Microsoft's roadmap for some time (years), but has not yet been solved.

By the way: With Exchange 2016, the Hybrid Configuration Wizard came with a free Exchange 2016 license for precisely this reason. The condition is that the local Exchange Server may no longer store any mailboxes, i.e. it may only be used for administration. However, an Exchange Server license was no longer required for this. This was changed again with Exchange 2019: The last Exchange Server, which is only used for administration, must also be licensed. A "Lone Exchange 2019 Hybrid Management Server without mailboxes" requires an Exchange Server license.

In order to enable the administration of mailboxes in the Exchange Online Admin Center, the synchronization of user accounts via AADConnect must be abandoned.

What happens next?

The transition from a hybrid environment to "cloud only" is not far away. The next article will therefore focus on dismantling the hybrid environment, shutting down AAD Connect and uninstalling the last Exchange server.