Tim McMichael

Navigating the world of high availability...and occasionally sticking my head in the cloud...

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

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

  • Comments 9
  • Likes

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;

 

===================================================

===================================================

10/2/2011

Updated second paragraph where I referenced homeMDB instead of homeMTA.

===================================================

Comments
  • 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.

  • @swally007:

    This has been corrected.  I appreciate it.

    TIMMCMIC

  • 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:Del\blabla)

    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.

  • @Simon:

    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.

    Thanks

    TIMMCMIC

  • 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

    Description:

    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.

  • 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.

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

  • @Gopi:

    To my knowledge yes.

    TIMMCMIC

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

    Clients using ExchangeMapiCDO and using a tool like Redemption (http://www.dimastr.com/redemption/rdo/rdosession.htm#methods) 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.

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment