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:
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.
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.
This has been corrected. I appreciate it.
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.
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.
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
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)?
To my knowledge yes.
@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.