Share via

Exchange 2010 puts TargetAddress in ProxyAddresses?!

  • Article

MMT is the BPOS-D migration tool and it uses Exchange 2010’s built in move service called MRS (Mailbox Replication Service).  MMT, through MRS, analyzes the mailbox, enforces any customer migration rules (such as ignore calendar items older than 2 months), moves the contents of the mailbox, validates the contents, strips mailbox attributes on the customer side, and then adds a target address on the customer side so that email is forwarded to BPOS.  At the end of the move, MRS fires off a “update-recipient” command on the customer side, which basically tells Exchange to apply the recipient policy defined on the customer’s environment.  Because the customer is moving to BPOS, re-applying a customer recipient policy at the end of a migration has detrimental effects, and that is why MMT runs a process that disables the customer recipient policy just before submitting the move-request to MRS. 

But, in customer environments that have slow or “big” replication, we have found that running the script that disables the recipient policy right before the move doesn’t work and we need to add some replication buffer time.  Because of replication issues, one DC will not receive the replicated object that has the disabled recipient policy, but sees that the target address has been populated, and adds the target address to proxyaddresses as the primary SMTP address!  This means that when the migrated user sends email to external recipients, the reply address is something like MMT_johnDoe53232411231221@mgd.customer.com, which may not be routable or exist in the customer’s SPAM/AV solution and is NDR’d.

This doesn’t just apply to BPOS, mergers/acquistions/divestitures that are moving from one forest to another may also experience this problem.  The BPOS team has brought up this issue with the Exchange team to determine the logic of populating ProxyAddresses with TargetAddress if it exists, and why it is set to the Primary SMTP address.   The BPOS team has also requested a change that allows the command to specify a specify DC that will stamp all the changes to avoid replication issues.  I will post any news that I get on this, but for now add some buffer to the script that disables the source recipient policy.

UPDATE: Please note that this information applies to Exchange 2003 and the RUS.  MRS attempts to diasable the RUS for the mailbox that will be migrated, but can be delayed during replication.  So, the RUS can also stamp the proxyaddresses with the targetaddress value if the replication issues occur.

Comments

  • Anonymous
    September 20, 2011
    This happens in remote mailbox moves from Exchange 2003 to Office 365 using an Exchange 2010 SP1 hybrid server for rich coexistence as well, so it appears the BPOS team didn't have immediate success with the Exchange team.  Here's hoping SP2 can clear this up.