Hello,

For those of you that have been on email migration assignments, especially from Lotus Notes and Novell Groupwise, you probably know that the TargetAddress attribute is your best friend for basic coexistence. What does that mean? Well, the most basic type of coexistence is when the migrated and not migrated users can send email to each other without any hassles.

The role of the TargetAddress attribute in migrations

So, what is the role of the TargetAddress attribute? For email migrations, the short answer is: Forwarding. Forwarding of a mailbox. If forwarding is set for a mailbox that means that all incoming email bound for that particular mailbox is resent, and routed, to some where else. In the migration case it’s most likely to be sent to either the source or the target email system, depending on the migration status of the mailbox.

The more common use for this attribute is to hold the external address of a MEU or a contact, but that is not a part of this blog post.

In on-premises Exchange systems you can get your hands on the TargetAddress easily by launching Active Directory Users and Computers, switch to Advanced Features and the find the attribute among all other attributes in the “Attribute Editor” tab. When migrating, you most likely have a tool like Migrator for Notes to Exchange from Dell Software (formerly know as NME or Notes Migrator for Exchange from Quest Software) to handle to setting of the TargetAddress attribute.

So, to summarize. The TargetAddress attribute is set on the mailbox that the end user is NOT working in for the moment. For example, for a user that has not already been migrated the TargetAddress is set on the target mailbox, so all email, no matter in what system it arrives, is delivered into the users source email system mailbox. When the user is migrated, we will have the opposite configuration. The TargetAddress attribute is cleaned out in the target email system and it is set in the source email system and all incoming email is delivered to the correct mailbox.

What’s the catch?

Using the TargetAddress attribute is a beautiful solution when you need basic coexistence during migration. However, when migrating to Office 365 you cannot use the TargetAddress attribute because it is not a writable attribute for mailboxes in Exchange Online. What does this mean? Is it impossible to migrate Lotus Notes to Office 365? Of course not, but normally you are lacking the beauty of the basic email coexistence which means that you cannot pre license the mailboxes in front of the migration, which means that you cannot pre stage data. That has been handled by different methods, for example one very common approach is to run the migration over a weekend and only migrate the last two or three months from the source mailboxes. When the migration run is finished you can backfill during the rest of the week.

The above approach is good enough for most customers and it is quite easy to accomplish the migration. You just need to make sure no mailboxes is created for users that are not being migrated yet.

The solution

During my last Lotus Notes to Exchange Online migration i tried a new approach for handling the forwarding. In this case i have created three things. A distribution group, a transport rule and a connector. Have a look at the below powershell commands:

1. New-DistributionGroup -Name “Domino Users”
2. New-OutboundConnector -Name “Mail to Domino” -ConnectorType OnPremises -SmartHosts “the smart host for Domino” -UseMXRecord $false -IsTransportRuleScoped $true
3. New-TransportRule -Name “Domino Users” -SentToMemberOf “Domino Users” -RouteMessageOutboundConnector “Mail to Domino”

This is simply brilliant. When running the migration I followed the below steps:

1. Create AAD identities
2. Run script that license the users and add them to the group “Domino Users”
3. Run script for adding proxyaddresses and migration permissions
4. Run the migration tool to prestage all mailbox data
5. Migrate the pilots, by removing them from the “Domino Users” group and use the migration tool to set forwarding in Lotus Domino
6. Migrate the rest of the mailboxes by using the same approach as for the pilots

By using the above approach there is basically no limit on how many mailboxes you can migrate during one weekend.

How does it work?

It’s quite easy. The transportrule triggers on all email sent to the users in the group “Domino Users”. The transportrule “detour” the email from a local delivery to be delivered by the connector instead. So when the rule is hit (because an email is sent to a member in that particular distribution group) Exchange Online simply routes the email out, using the smart host configured in the connector settings and the email is delivered to the Domino servers.

Thanks,

Magnus Göransson