Shared SMTP Name Space between Exchange 2010 org and Exchange 2003 org
HI All,
Here is my scenario:
New Forest: xyz.local (Exchange 2010, Windows 2008 R2 domain controller)
Old Forest: abc.local (Exchange 2003, Windows 2003 domain controller)
Shared SMTP domain (for example): contoso1.com, contoso2.com and contoso3.com
Trust: There is a full trust established between forests.
My old exchange organization is authoritative for “contoso1.com, contoso2.com and contoso3.com” and the user uses one of the SMTP domain “users@contoso.com” as their primary email address. I want to migrate users from old forest to new forest. During the migration phase user will use contoso.com as their primary email address in the New Forest too.
To resolve the logical boundary limitation of Exchange. This is my plan:
1) Configure contoso.com to be non-authoritative on both new and old exchange org.
2) Create connector in Old Exchange org to relay unresolved user’s email with “contoso.com” SMTP namespace to Hub transport server in New Forest.
3) Create connector in New Exchange org to relay unresolved user’s email with “contoso.com” SMTP namespace to Bridgehead server in Old Forest.
4) Decrease the hop count to minimum to avoid message loop.
Questions:
1) In above scenario, I am confused about NDR generation. What happens to NDR and who will generate it?
2) Configuring NON-Authoritative domain will or will not impact on what primary email address users uses. I need users in both Forest to use “contoso.com” as their Primary.
Please let me know if my thinking process is wrong and am I heading for a disaster with above plan.
Here is my scenario:
New Forest: xyz.local (Exchange 2010, Windows 2008 R2 domain controller)
Old Forest: abc.local (Exchange 2003, Windows 2003 domain controller)
Shared SMTP domain (for example): contoso1.com, contoso2.com and contoso3.com
Trust: There is a full trust established between forests.
My old exchange organization is authoritative for “contoso1.com, contoso2.com and contoso3.com” and the user uses one of the SMTP domain “users@contoso.com” as their primary email address. I want to migrate users from old forest to new forest. During the migration phase user will use contoso.com as their primary email address in the New Forest too.
To resolve the logical boundary limitation of Exchange. This is my plan:
1) Configure contoso.com to be non-authoritative on both new and old exchange org.
2) Create connector in Old Exchange org to relay unresolved user’s email with “contoso.com” SMTP namespace to Hub transport server in New Forest.
3) Create connector in New Exchange org to relay unresolved user’s email with “contoso.com” SMTP namespace to Bridgehead server in Old Forest.
4) Decrease the hop count to minimum to avoid message loop.
Questions:
1) In above scenario, I am confused about NDR generation. What happens to NDR and who will generate it?
2) Configuring NON-Authoritative domain will or will not impact on what primary email address users uses. I need users in both Forest to use “contoso.com” as their Primary.
Please let me know if my thinking process is wrong and am I heading for a disaster with above plan.
I think you nailed the issue in your question 1. there will be no NDR generation as per say rather emails will be bounced with a "mail loop" error.
you can have primary email address even if it is not authoritative nothing to worry about here
you can have primary email address even if it is not authoritative nothing to worry about here
Having done a similar kind of thing years ago, I would suggest you leave the OLD system as authoritive, and pass all mail first into the new system. Any failed matches then get passed to the old system to be delivered or NDR'd.
By using this method, you provide the best performance for the new system - so the users do not see the new system as being slower than the old. In addition, at the end of the process you don't have to break the delivery process - you just make the new system authoritive and the old system gets closed out.
By using this method, you provide the best performance for the new system - so the users do not see the new system as being slower than the old. In addition, at the end of the process you don't have to break the delivery process - you just make the new system authoritive and the old system gets closed out.
Premium Content
You need an Expert Office subscription to comment.Start Free Trial