Exchange 2010: HomeMTA and msExchHomeServerName are not updated on mailboxes.

In Exchange 2003 and Exchange 2007 when clients would attempt to connect to a mailbox it would be based on the server where that mailbox was homed.   Specifically these attributes would contain information about the server where a particular mailbox was homed:


  • HomeMTA
  • msExchHomeServerName


In Exchange 2010 a mailbox object is no longer associated with a server but rather is associated with a database.  A database has copies which are associated with a particular server.  When a client or application attempts to access the mailbox, the active manager process is responsible for locating the server that hosts the active copy of the database and referring mailbox requests to that server.  Although not utilized, the Exchange 2010 mailbox provisioning process still stamps HomeMTA and msExchHomeServerName.  In this case the attributes are stamped based on the server where the database copy was active at the time the mailbox was provisioned. 


Management commandlets like get-mailbox will return the server name stamped in msExchHomeServer.  In many cases this is a valid server within the environment.  In some instances, the server mentioned has been decommissioned and is no longer available.  Although this server name is displayed this is not an issue.   There should be no reason that administrators need to update these values as they are not utilized in Exchange 2010.




[PS] C:\Windows\system32>Get-Mailbox Tim

Name                      Alias                ServerName       ProhibitSendQuota
----                      -----                ----------       -----------------
Timothy J. McMichael      Tim                  dag-4            unlimited

homeMTA: CN=Microsoft MTA,CN=DAG-4,CN=Servers,CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=Organization,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=domain,DC=com;

msExchHomeServerName: /o=Organization/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Configuration/cn=Servers/cn=DAG-4;





Updated second paragraph where I referenced homeMDB instead of homeMTA.


Comments (13)

  1. TIMMCMIC says:


    You are correct.  If memory serves an error will also be logged in the application log about an object that has the homeMTA that references a deleted object.



  2. TIMMCMIC says:


    This has been corrected.  I appreciate it.


  3. TIMMCMIC says:


    To my knowledge yes.


  4. swally007 says:

    There is a Typo in this blog:

    Although not utilized, the Exchange 2010 mailbox provisioning process still stamps HomeMDB and msExchHomeServerName

    I guess you wan to say HomeMTA not HomeMDB.

  5. Simon says:

    We ran into an issue with this a while back actually. If you decomission the server dag-4 in your example above then the homeMTA attribute will reference the AD deleted object (cn=0:Delblabla)

    This is not an issue (AFAIK) for any MS clients but we had some issues with a crappy sync solution called OneBridge that uses CDO. We had to basically script out a new, working, homeMTA attribute for the affected users.

    It is also a little unfortunate that the Get-Mailbox cmdlet resturns ServerName by default.

  6. Tony in MN says:

    What is interesting is why does Exchange 2010 on our font-end servers list this error – stating it should be fixed as soon as possible?

    Log Name:      Application

    Source:        MSExchange ADAccess

    Date:          1/17/2013 2:24:11 PM

    Event ID:      2937

    Task Category: Validation

    Level:         Warning

    Keywords:      Classic

    User:          N/A

    Computer:      EXCH2010SP2.domain.local


    Process w3wp.exe () (PID=4720). Object [CN=Lastname, Firstname,OU=Users,OU=East Coast,DC=domain,DC=local]. Property [HomeMTA] is set to value [domian.local/Configuration/Deleted Objects/Microsoft MTA

    DEL:528c9221-c70e-49bd-a6d6-e23f6553d773], it is pointing to the Deleted Objects container in Active Directory. This property should be fixed as soon as possible.

  7. Jason in the Cornfields says:

    We have a 3 datacenter model and I have been asked to create dynamic distribution lists per server. Management's intention was to email ServerA if we had to move their databases from Site A to Site B (or C). Unfortunately because of the issue we are discussing here I need three dynamic DLs for each server to be sure I reach all the users. This is really clunky and it would be great if I could update those addresses to put them all on one server for the purpose of these lists.

  8. Gopi says:

    Does "Clients" in this context also mean MfcMapi (via ExchangeMapiCdo)?

  9. Tim C says:

    @Gopi and and @TIMMCMIC The answer to your question is NO!

    Clients using ExchangeMapiCDO and using a tool like Redemption ( and calling the GetSharedMailbox method and passing a username
    or email address will find that MAPICDO does not resolve the user to the correct location and the Mailbox will not be mounted.

    You have to get very, very deep in the weeds, but it appears that the MAPI call here is still relying on the HomeMTA to find the correct mailbox server. It shouldn’t be, but it is. Moral to the story, if you have a MAPI tool running in the background against
    your servers, you should update the HomeMTA.

  10. Chris E says:

    If i remove the msExchHomeServerName attribute from the user account via ADSI Edit which is pointing to our old Exchange 2003 server that is currently shutdown the mailbox disappears from the Exchange 2010 managment console.

  11. Paul Voller says:

    I realise that this article has not been updated in a few months but I thought I would share my experiences.

    Like @Simon (above) we rely on a half-baked third party sync system to keep our mailbox folders synced with their databases. This turns out to rely on the HomeMTA value as well so when I replaced a few servers in our DAG with new ones this syncing started to

    Long story short: easiest way to fix this was for me to run: get-mailbox -resultsize unlimited | % {set-mailbox -identity $_.alias -database $_.database }

    This "re-homed" the mailbox into it’s current DB and of course refreshed all the other Server and HomeMTA values which sorted it out.

  12. Travis Smith says:

    Yes the home server is important if it goes offline, then outlook is going to be offline, OWA doesn’t care

  13. mike says:

    If Exchange 2010 does not care about this, why does it log a warning in the event logs indicating it should be fixed as soon as possible?

Skip to main content