Funky mail routing after cross-site mailbox moves

  • Article

When you move mailboxes across mixed-mode site boundaries with the Exchange 2003 SP1 feature, there is a period of time where mail will have trouble routing properly to these moved mailboxes. There are a couple of ways you may see this presented, as I’ll discuss in this post.

The most common case is the Non Delivery Report (NDR) scenario. That is to say that after you move a user’s mailbox across administrative group boundaries in mixed mode, mail sent to this user may be returned non deliverable. This is discussed in KB.841659. The short explanation is that:

  • Mailbox is moved from Site1 to Site2 (so the data is now in Site2, not Site1)
  • 5.5 directory in Site1 is updated to make the original mailbox a “stub” object which cannot receive email
  • AD is updated to reflect that the object exists in Site2
  • 5.5 directory in Site2 is not updated until ADC replicates from AD->Site2 (so there is not yet a directory object for the mailbox in the Site2 5.5–world)

While we’re in this transitioning phase, if someone on a 5.5 server tries to send to the moved mailbox the 5.5 directory will be referenced. The 5.5 directory is not completely updated at this point, so the message will eventually hit a 5.5 server that doesn’t know how to deliver mail to this mailbox object (for instance, the 5.5 directory in Site2 hasn’t yet had the ADC create the new object, so it has no knowledge of this mailbox from a directory perspective).

This happens right up until the ADC replicates, directory replication completes, and the stub object is removed – see this post for more details on this process.

There’s also another scenario I’ve seen that has slightly different results. The scenario is that you have no RPC connectivity between the server that is the source of the move and the server that is the target of the mailbox move. A common way this may be the case is for the two sites to be connected by X400 connectors, and not share a common service account.

During the mailbox move (as in all mailbox moves, see my EHLO post for more info), the PR_IN_TRANSIT property is set on the mailbox to prevent new messages delivering to the mailbox while it is moving. In most cases, the source of the mailbox move is a 5.5 server, so when the move completes, any messages that had queued up during the move are released back into the MTA for delivery.

The MTA isn’t really smart about cross-site mailbox moves, so it makes the assumption that (of course) the target of the mailbox move has to be in the same site, which means that (of course) we will have RPC connectivity to the server where the mailbox now resides.

Except in the scenario I’ve described above. With X400 connectors and no shared service-account, there’s no guarantee we’ll be able to make an RPC connection to the destination server. Enter the problem: The MTA short-cuts the mail routing, and just drops these queued messages into an RPC queue, destined for the servername of the destination server. The typical symptom is that you’ll see a mail queue on the source 5.5 server destined for the (netbios) name of the target server with queued items in it, even though new mail destined for this target server is flowing just fine across the appropriate connector. You may also see events logged from the MTA indicating a failure to connect to the server in the other site.

This doesn’t affect all environments, as RPC connections are often possible between sites. If you have a site connector between the sites, this behavior is totally transparent and the mail will route just fine. That’s the suggested workaround – just create (even temporarily) a site connector between the two sites so that these mail items can drain out of the queue and deliver.