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:
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.
We have some sites that we have not yet migrated and the have X400 connectors only. All sites have the same service account. Should we bother to create a site connector?
My recommendation is to closely monitor the mail queues while you're moving these mailboxes and only create a site connector if you see mail building up in the manner I described.