Good afternoon. We have an exchange 2010 server that was configured at head office (mailbox, hub transport, cas) and has been running here for roughly 6 months without an issue with the intent to move it to a new large branch we were opening up. The short story is after moving this machine to the new location, which in turn put it into a new AD site, the submission queue was filling up complaining about users mailboxes not being in the same site as their AD user object (I apologize I never got the exact error message, but I can get it if need be). To remedy this situation temporarily I "tricked" the server into thinking it was still in the head office AD site by adding the SiteName registry key to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters. After a reboot the queue cleared and things have been working fine. I tried restarting the hub transport services on the head office exchange servers and removing the registry entry, but the issue persisted. Searching on this has been rather dry, so im hoping some experts here might have an idea what the problem is. Thanks in advance for any suggestions.

Can you post the exact errors in the event logs? I would run ExBpa against the server as well. I assume the mailboxes its trying to deliver to are also homed on that server? Any anti-virus or other 3rd party software running on the server?

Hi Derek_M Per your description, how do you do the mirgration, you can post the detailed the information about your scenario here. As we know, there is a attribute named site membership of the exchange server, and will be used when the message was delivered, please refer to below: http://technet.microsoft.com/en-us/library/aa996299.aspx Some related discussion: http://social.technet.microsoft.com/Forums/en-US/exchangesvrdeploy/thread/5c8f62bd-01ac-407a-bd76-874c2eb4bbf4 http://social.technet.microsoft.com/Forums/en-US/exchangesvrdeploy/thread/5c8f62bd-01ac-407a-bd76-874c2eb4bbf4 Regards! Gavin

Hi Gavin/Andy, Thanks for the suggestions, I do believe the site membership attribute could be playing a role in this issue however I don't know why it is not getting the correct site information. The exact error message that EACH message in the submission queue is seeing is as follows: 432 4.2.0 STOREDRV.Deliver.Exception:WrongServerException.MapiExceptionMailboxInTransit; Failed to process message due to a transient exception with message The user and the mailbox are in different Active Directory sites. I am getting the following concerning error in the event log which I believe is related: Process MSEXCHANGEADTOPOLOGY (PID=1640). The site monitor API was unable to verify the site name for this Exchange computer - Call=DsctxGetContext Error code=8007077f. Make sure that Exchange server is correctly registered on the DNS server. Event ID 2501 I cannot see any issues with DNS, everything looks fine. I worked with the following article and COMPLETELY re-configured networking on the box but it did not help: http://social.technet.microsoft.com/Forums/en-US/exchangesvrmonitoring/thread/2f0e7f45-5f4d-49c9-9a5a-ff53467dd355/ So now if I add the "SiteName" key to the registry and again "trick" the system into thinking its still in the head office site, things will flow again ok. This is obviously not a perminant fix though as the exchange servers here are all under the impression at that point that this server is local and they send huge amounts of data over the wan to it. Any further help on this issue would be greatly appreciated.

After installing a backup hub transport server at the site in question and uninstalling/reinstalling the hub transport server roles on the original server, the same problem occurred. After this we decided to try and hard code the NEW site name in the registry... So instead of using the head office site's name in "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters\SiteName" we put in the NEW site name that the server actually resides in. After a reboot, things started working perfectly. Microsoft doesn't consider this a perminant fix, and there is still an underlying issue on the server however the issue IS fixed for now. We will be looking at this again in the future to try and remove that key and resolve the underlying problem, but we don't have the time to put into it now. If we do end up resolving it completely, I will update this post in the future.

Has anyone tried manually changing the msExchServerSite attribute on the server object in the Exchange organization configuration? This attribute should be updated by the Exchange Topology service but when I had a similar issue moving a staged CAS/HUB server to the production site, I noticed the date-time stamp on the server object was not showing an update. I changed it manually and it solved the problem. This could be a race condition or an error in the service but the manual update of the msExchServerSite attribute seemed to correct it. I am using Exchange 2010 SP2. From Technet: The value for the msExchServerSite attribute is populated and kept up to date by the Microsoft Exchange Active Directory Topology service. When a Windows-based computer starts, the Net Logon service determines site membership for the computer. The Net Logon service uses that information to locate domain controllers that are located in the same Active Directory site as the local computer and then directs authorization and authentication requests to those servers. The Microsoft Exchange Active Directory Topology service uses the DsGetSiteName API call to retrieve the site membership value from the Net Logon service and writes the Active Directory site's distinguished name to the msExchServerSite attribute for the Exchange server object in Active Directory. Nick Cottrell MCITP Enterprise Administrator | MCITP Enterprise Messaging | MCT