Advanced Recovery Strategies
Each Microsoft® Exchange 2000 Server and Exchange Server 2003 mailbox must be linked to an Active Directory® directory service user account in order for the mailbox to be accessible to end users. This linking is implemented by setting several Exchange-specific attributes on the Active Directory user account object.
When an administrator uses the Exchange Task Wizard to mailbox-enable a user account, the necessary attributes are added in a two-step process:
Several core attributes are immediately set on the user account, including mailNickname, homeMTA, homeMDB, and msExchHomeServerName.
To complete the mailbox-enabling process, the Recipient Update Service sets additional attributes based on the recipient policies that apply to the user account.
Active Directory user accounts can also be mailbox-enabled without using the Exchange administrative interfaces. If an administrator sets the mailNickname attribute along with any one or more of the homeMDB, homeMTA, or msExchHomeServer attributes, the Recipient Update Service will configure all other attributes required to fully mailbox-enable the account.
Important
An Exchange server can host up to 20 Exchange mailbox databases. The homeMDB attribute designates the specific database that hosts a mailbox. If you do not specify the homeMDB attribute, but instead specify either the homeMTA or the homeMDB attribute, then you cannot control which database will be chosen to host the mailbox. The Recipient Update Service will automatically assign the mailbox to a database on the server, which is typically the first database configured on the server.
Administrators can also disable or bypass the Recipient Update Service, and set all Exchange mailbox-enabling attributes manually or with scripts.
For a comprehensive list of mailbox-enabling attributes, see Microsoft Knowledge Base article 296479, "XADM: Requirements for Disabling the Recipient Update Service".
Important
Prior to Exchange 2000 Server Service Pack 3 with the post-Service Pack 3 rollup for August 2003, the Recipient Update Service did not correctly enable all security attributes for a user account if you enabled the account by directly setting the mailNickname and the homeMDB, homeMTA, or msExchHomeServer attributes, allowing the Recipient Update Service to add the remaining attributes. This situation caused issues with mailbox delegation and access to remote public folder servers.
If you are using a version of Exchange prior to Exchange 2000 Service Pack 3 with the post-Service Pack 3 rollup for August 2003, the supported methods for mailbox-enabling user accounts are:
The Exchange Task Wizard
The Collaboration Data Objects for Exchange Management (CDOEXM) APIs
Disabling the Recipient Update Service and directly setting all attributes, including security attributes, on each user account
Regardless of the Exchange version, direct manipulation of security attributes may require use of scripting interfaces rather than simple modifications of object attributes. If default permissions are not suitable for your purposes, see the following Knowledge Base article and topic in this guide for more information about advanced manipulation of mailbox permissions:
Not only can you create Exchange mailboxes by directly manipulating Active Directory attributes, you can also delete and re-home them to different databases.
You can delete a mailbox by removing all the Exchange mailbox-enabling attributes from a user object. When you do this, actual mailbox contents previously associated with the user account will not be immediately deleted from the database. Instead, the mailbox will be marked as Disconnected by the Mailbox Cleanup Agent, which runs periodically for each Exchange database. By default, the contents of disconnected mailboxes are hard deleted 30 days after they have been marked Disconnected. Before actual mailbox deletion occurs, it is possible to re-link the mailbox to the same account or to a different Active Directory user account.
It is also possible to re-home a mailbox by changing the values of the homeMDB, homeMTA, and msExchHomeServer attributes for a user object. If you do this, a user’s current mailbox contents are not moved. Instead, another mailbox for the user will be generated in the database location defined by the changed attributes, and the previous mailbox will be marked Disconnected. Re-homing can be done to a different database, a different storage group, or even a different Exchange server in the same administrative group.
Re-homing a mailbox by changing the homeMDB, homeMTA, and msExchHomeServer attributes can have several serious short-term side effects:
In transit messages may not be delivered, or may be returned to the sender as non-deliverable. Any messages queued on any Exchange server in the same routing group will be returned undeliverable. This situation may be mitigated to some extent by forcing re-categorization of messages on each server that is running Exchange. For more information about re-categorizing messages, see Knowledge Base article 279616, "XCON: Adding a Registry Key to Re-Categorize Messages".
Client connectivity may be adversely affected. It may be necessary to reboot client workstations before connectivity can be re-established in the new mailbox location, or it may even be necessary to completely regenerate client Microsoft Office Outlook® profiles.
Latencies in Active Directory and DNS name resolution replication may result in looping messages, loss of messages, non-delivery reports, client connectivity problems, or all of these problems.
Current mailbox contents will not be re-homed. They will be lost unless you salvage items using ExMerge or another tool, or you move the original database to the new location. For more information about re-homing mailboxes, see Using Active Directory Attributes to Enable, Disable, and Re-Home Mailboxes.
When you use the Move Mailbox tool that is part of Exchange to re-home mailboxes, all of the above problems are avoided. Move Mailbox not only handles the rewriting of Active Directory attributes, but it also interacts with the Exchange database and transport subsystems to correctly re-route mail, move current mailbox contents to the new location, and update client configurations.
Therefore, it is not recommended that you manipulate raw Active Directory attributes to re-home mailboxes as part of your normal administrative processes. Move Mailbox is the recommended tool to use for re-homing Exchange mailboxes. Initial provisioning of mailboxes by setting Active Directory attributes is not subject to the problems listed earlier that occur when re-homing an existing mailbox.
As a best practice in developing an Exchange disaster recovery or site resilience plan, it is recommended that you design the plan to avoid re-homing mailboxes by changing homeMDB, homeMTA, and msExchHomeServer attributes. Re-homing existing mailboxes not only makes it likely that in transit messages will be lost, but it also introduces additional complexity into a recovery plan by requiring updates or reconfiguration of infrastructure services such as routing tables, Active Directory, and DNS.
For more information about designing a disaster recovery or site resilience plan that does not require re-homing mailboxes, see Using Standby Clusters.
For Exchange servers that are not clustered, see Knowledge Base article 822945, "How to move Exchange 2003 to new hardware and keep the same server name". This article discusses use of the /DisasterRecovery setup mode to move an Exchange installation to new hardware while retaining the current Exchange configuration.
There may be unusual circumstances in which the Move Mailbox tool cannot be used. For example, a server may have been destroyed and it becomes necessary to bring users up a different server that is running Exchange.
Important
Subject to the cautions and limitations described in this topic, re-homing Exchange mailboxes by manipulating raw Active Directory attributes is supported by Microsoft, but it is not recommended as part of normal administrative, operational, or recovery procedures.
What Information Does This Section Provide?
This section covers advanced recovery strategies for servers that are running Microsoft® Exchange, such as:
Using Active Directory Attributes to Enable, Disable, and Re-Home Mailboxes This set of topics discusses several methods that you can use to enable, disable, and re-home Exchange mailboxes by directly manipulating Active Directory® directory service attributes.
Moving an Exchange Mailbox Database to Another Server or Storage Group This set of topics discusses how to move mailbox databases between servers that are running Exchange and storage groups, as well as how to re-link each mailbox in the database to an Active Directory user account.
Detecting and Correcting msExchMasterAccountSid Issues This set of topics discusses how to check for and, if necessary, correct problems with the msExchMasterAccountSid attribute of a user account.
Using Standby Clusters This set of topics discusses the recovery options for the loss of the entire Exchange cluster, including a standard cluster recovery and using a standby cluster.
You can also use Active Directory Services Interfaces (ADSI) scripting to re-home Exchange mailboxes for recovery purposes. For a sample script that illustrates how to do this, see Sample Script Using ADSI to Re-Home Exchange Mailboxes. For an example of how you might use the Lightweight Directory Access Protocol (LDAP) Data Interchange Format (LDIF) directory export tool (LDIFDE) to re-home mailbox accounts, see How to Re-Home Exchange Mailbox Accounts.