Cross site moves in Exchange Native Mode

  • Article

Since I’ve posted a bunch of information on cross-site moves in mixed mode (using the Exchange 2003 SP1 feature), I’ve also had a number of folks ping me with questions about cross-site moves in Exchange native mode. There are a couple of points about these sorts of moves that are useful to understand:

Cross AG moves in native mode (intentionally) don’t change the LegacyExchangeDN

When you move mailboxes cross-site in mixed mode with the SP1 feature, part of the process (described in a bit more detail here) is to actually create a new mailbox in the target site. This new mailbox in the target site will have a new Object Distinguished Name in 5.5, which means it will have a different LegacyExchangeDN in the AD. Because it has a different LegacyExchangeDN in the AD, Outlook will no longer 100% associate any existing profile with the correct user — thus, why you have to run ExProfRe after doing cross-site moves in mixed-mode.

When you move a mailbox cross-site in native mode (cross-AG, we should actually say to be technically correct), the process is much more simple. We don’t change the LegacyExchangeDN on a mailbox/user during a native mode move. Since there’s no 5.5 in a native mode organization, there’s a line of thinking that LegacyExchangeDN is not important to the server anymore. This is sort of true — the Exchange server won’t care that you’re now in an AG that doesn’t match your LegacyExchangeDN, for instance — but it isn’t 100% true.

For instance, Outlook still uses LegacyExchangeDN. It uses it for things like Free/Busy updates.

Here’s an example scenario:
Two sites: Site1 and Site2. In Exchange native mode. User1 starts out in Site1 (Legdn: /o=Org/ou=Site1/cn=Recipients/cn=User1). User1 is moved cross-AG into Site2. Although all of the other Site2 mailboxes have LegacyExchangeDN of /o=Org/ou=Site2/cn=Recipients/cn=<useralias>, User1 retains the same LegDN after the move.

This can cause problems with Free/Busy updates

If you’ve moved mailboxes cross-AG as in the above Exchange native mode example, Outlook will still try to publish its Free/Busy updates to the system folder for the old site (“Site1”, in our example). This isn’t a problem — all free/busy updates can continue to work just fine in this case, as all references to the moved mailbox will still point to the old LegacyExchangeDN. Where it can be a problem is if you don’t realize this and decommission the source site (Site1).

If you finish migrating all of the mailboxes and get rid of Site1, you will need to make sure you have pushed a replica of the Site1 “SCHEDULE+ FREE BUSY” system folder to a site that your moved mailboxes have access to (probably Site2). It may look a little strange, putting a replica of the Site1 F/B information onto a server in Site2, but if you don’t do this your mailboxes will not be able to update Free/Busy information and when Site1 disappears you’ll have hash-marks as Free/Busy information for all of the users moved from Site1!

It can also cause problems anywhere else you’re using LegacyExchangeDN

A good example of this is Recipient Policies. If you’ve defined recipient policies based on LegacyExchangeDN (and in Exchange mixed mode, that’s exactly how recipient policies are defined!), these will not work exactly as you might like when you start to comingle non-matched LegacyExchangeDNs within the same site. If you’ve moved mailboxes from Site1 to Site2, you’ll find that your LegacyExchangeDN-based recipient policies that used to map one-to-one with your 5.5 sites will not consider the mailbox to belong to the Site2 recipient policy. Be sure you consider if there is anywhere else you’ve explicitly tied things to LegacyExchangeDN…

You don’t need to run ExProfRe

Another thing to consider is that if you don’t change the LegacyExchangeDN on these moved users, there’s nothing to update in the Outlook profile. There’s no need in that case to run ExProfRe, and if you do it will just tell you there’s nothing to update.