If you are planning a consolidation of multiple Exchange organizations, you will need to move mailboxes from one organization to another. For those of you who use third party tools like Quest (or others) will probably never face the issue with the legacyExchangeDN attribute in the user mailbox. This because these tools do a conversion of the legacyExchangeDN during and after the consolidation.
But if you are planning to do the mailbox migration (or user migration for that matter) by using the Microsoft provided tools Powershell and ADMT. This article might turn out very useful.
But if you are planning to do the mailbox migration (or user migration for that matter) by using the Microsoft provided tools Powershell and ADMT. This article might turn out very useful.
Now what is this LegacyExchangeDN attribute and what is it used for?
For that information i would like to point you to following websites where the attribute is fully Explained by people who have far more better writing skills than me.
http://www.msexchange.org/tutorials/Understanding-LegacyExchangeDN.html
OK, migrating users and moving their mailboxes isn't that big of an issue after all.
You make sure that DNS is in order to make the trusts between the multiple Active Directory forests. Create a two way trust between the forests, and start moving users with ADMT.
Once you have provisioned the target forest with the user accounts from the source organization you can start moving some mailboxes. After moving a mailbox you start testing the moved mailbox. You check the mail routing (which you probably tested before) to see if the moved user is able to send mails. That looks OK, you ask the user to check his/her data. And everything looks fine. Suddenly you receive a call from the moved user telling you that when he replies to mails which where in his/her mailbox prior to the move, he/she gets an NDR.
You start to investigate the issue and you discover a nice Gotcha. When replying to mails Exchange uses the attribute ExchangeLegacyDN in stead of the SMTP address. As this is the legacyExchangeDN from the source forest it cannot be resolved in the target forest, and therefore resulting in a NDR.
The resolution for this issue is simple, but has to be noted before you move the mailboxes. This because you need the ExchangelegacyDN from the source forest. If you chose to remove the mailbox enabled user in the source forest in the move-mailbox script (which you use to move the mailboxes) the LegacyExchangeDN will be a bit harder to retrieve.
To make sure that you won't run into the ExchangeLegacyDN issue, you will need to make sure that the DN can be resolved in the target forest. This is required during and after the migration as long as user tend to reply to mails which originate from the old source organization (prior to the mailbox move).
For mailboxes which have been moved, you will need to add the LegacyExchangeDN from the source domain as a custom x400 address to the mailbox in the target organization. To ensure coexistence during the migration period, you will need to create contacts for all mailboxes in the source organization (which haven't been migrated). You will than add the LegacyExchangeDN from the source forest to the contact also as a custom x500 address. This makes sure that when a moved user replies to a mail (originating before the move) in his/her mailbox to a user the legacyExchangeDN can be resolved to a valid SMTP address.
If you plan to move the next batch of user mailboxes, you know you will need to remove the contacts for these users in the target forest prior to moving the mailboxes. During the time frame between the removal of the contacts, the move of the mailbox and adding the LegacyExchangeDN to the move mailbox, the LegacyExchangeDN will not be resolved in the target forest. To minimize this period it is best to put the procedure in one script and specify a domain controller. By doing so, you will not have to await replication prior to moving the mailboxes and therefore shorten the time in which the LegacyExchangeDN cannot be resolved in the target forest.
Jim Mcbee wrote about it too, and even provided a usefull script.
http://mostlyexchange.blogspot.com/2007/08/exchange-2007-legacyexchangedn-and-mail.html
http://www.msexchange.org/tutorials/Understanding-LegacyExchangeDN.html
OK, migrating users and moving their mailboxes isn't that big of an issue after all.
You make sure that DNS is in order to make the trusts between the multiple Active Directory forests. Create a two way trust between the forests, and start moving users with ADMT.
Once you have provisioned the target forest with the user accounts from the source organization you can start moving some mailboxes. After moving a mailbox you start testing the moved mailbox. You check the mail routing (which you probably tested before) to see if the moved user is able to send mails. That looks OK, you ask the user to check his/her data. And everything looks fine. Suddenly you receive a call from the moved user telling you that when he replies to mails which where in his/her mailbox prior to the move, he/she gets an NDR.
You start to investigate the issue and you discover a nice Gotcha. When replying to mails Exchange uses the attribute ExchangeLegacyDN in stead of the SMTP address. As this is the legacyExchangeDN from the source forest it cannot be resolved in the target forest, and therefore resulting in a NDR.
The resolution for this issue is simple, but has to be noted before you move the mailboxes. This because you need the ExchangelegacyDN from the source forest. If you chose to remove the mailbox enabled user in the source forest in the move-mailbox script (which you use to move the mailboxes) the LegacyExchangeDN will be a bit harder to retrieve.
To make sure that you won't run into the ExchangeLegacyDN issue, you will need to make sure that the DN can be resolved in the target forest. This is required during and after the migration as long as user tend to reply to mails which originate from the old source organization (prior to the mailbox move).
For mailboxes which have been moved, you will need to add the LegacyExchangeDN from the source domain as a custom x400 address to the mailbox in the target organization. To ensure coexistence during the migration period, you will need to create contacts for all mailboxes in the source organization (which haven't been migrated). You will than add the LegacyExchangeDN from the source forest to the contact also as a custom x500 address. This makes sure that when a moved user replies to a mail (originating before the move) in his/her mailbox to a user the legacyExchangeDN can be resolved to a valid SMTP address.
If you plan to move the next batch of user mailboxes, you know you will need to remove the contacts for these users in the target forest prior to moving the mailboxes. During the time frame between the removal of the contacts, the move of the mailbox and adding the LegacyExchangeDN to the move mailbox, the LegacyExchangeDN will not be resolved in the target forest. To minimize this period it is best to put the procedure in one script and specify a domain controller. By doing so, you will not have to await replication prior to moving the mailboxes and therefore shorten the time in which the LegacyExchangeDN cannot be resolved in the target forest.
Jim Mcbee wrote about it too, and even provided a usefull script.
http://mostlyexchange.blogspot.com/2007/08/exchange-2007-legacyexchangedn-and-mail.html
X500 ;-)
ReplyDeleteDoesn't matter if you specify it as a X400 or X500. Works both ways.
ReplyDeleteHi Shrimp
ReplyDeleteI'm finding it's working with the legacyExchangeDN copied across to the destination contact, but not when it's copied to the X500 proxy address only (get a bounceback when sending to GAL entry).
In your experience, are both legacyExchangeDN and x500 needed on the contact to enable routing to source Exchange org.
You mention .. "You will than add the LegacyExchangeDN from the source forest to the contact also as a custom x500 address", but I'm not sure if this suggests both are required, or only x500.
Thanks in advance.
Hi Irobot8, you need to add the legacyexchangeDN of the source forest to the contact in the forest. In order to add the address you need to define a custom address and specify type x400 or x500. To my experience both work. If the address is added the address can be resolved an mail will flow back to the source forest using the primary address of the contact.
ReplyDeleteSo i have moved user A from 2007 cross forest - after doing prepare move, ADMT and new-move request. User A goes to reply to old email from user B and it fails - so I create a mail contact in new Exch 2010 server with a x500 of userB legacyExchDN -- reply to old email still fails - any ideas?
ReplyDeletewhat do you mean by
"To make sure that you won't run into the ExchangeLegacyDN issue, you will need to make sure that the DN can be resolved in the target forest"
I have a forest trust and can ping by dns across forest