Export (0) Print
Expand All

Issues with the System Attendant Mailbox When Moving an Exchange Mailbox Database

 

Topic Last Modified: 2005-10-13

Each server that is running Microsoft® Exchange has a single system attendant mailbox. This mailbox is created in the first database configured on the server. The system attendant mailbox is required for multiple tasks. These include, but are not limited to:

  • Processing server monitor messages

  • Updating free/busy calendar information for Microsoft Office® Outlook Web Access users

  • Processing Mailbox Manager notifications

  • Moving mailboxes to other databases

If the system attendant mailbox is inaccessible, a server running Exchange continues to run and perform basic mail processing. However, many system features and tasks will not function correctly.

The system attendant mailbox for each server is unique and is not interchangeable with the system attendant mailbox on other servers. You cannot move the system attendant mailbox for one server to a different server. If you move the database files that contain the system attendant mailbox from one server that is running Exchange to a different server, this action will disconnect the system attendant mailbox and add it permanently to the mailbox tombstone table. If you were to then move the database back to the original server, the original system attendant mailbox could not be re-created in that database. Instead, the following error will appear frequently in the application log:

 

Event Type:

Error

Event Source:

MSExchangeIS Mailbox Store

Event Category:

Logons

Event ID:

1022

Description:

Logon Failure on database "DATABASE_NAME" - Windows 2000 account NT AUTHORITY\SYSTEM; mailbox /o=Microsoft/ou=First Administrative Group/cn=Configuration/cn=Servers/cn=EXCHANGE_SERVER/cn=Microsoft System Attendant.

Error:

1292

This error is equivalent to error 0x50c, ecMailboxInTransit, which is the error generated when a delivery attempt is made for a mailbox that is listed inside a database’s mailbox tombstone table. Mailboxes listed in the tombstone table cannot be created or reconnected to Active Directory® directory service objects. For more information about the behavior of mailboxes when they are inside a tombstone table, see Move Mailbox Operations and the Mailbox Tombstone Table.

The following scenarios describe the circumstances under which the system attendant mailbox can and cannot be generated in a database.

Scenario 1

Server Exchange1 hosts Database1, which contains the system attendant mailbox. Server Exchange2 hosts Database2, which contains the system attendant mailbox for Exchange2.

You swap the database files for Database1 and Database2 between Exchange1 and Exchange2. After the databases have been mounted in their new locations, the following two things happen after several minutes, but not necessarily in the order listed:

  • The Mailbox Cleanup Agent, which runs automatically and periodically for each Exchange database, will mark the previously existing System Attendant mailbox in each database as Disconnected. This designation is made because the mailbox no longer matches the server running Exchange on which each database is running. When this mailbox is marked as Disconnected, it is added to the mailbox tombstone table for the database. This addition prevents any possibility that the mailbox could be enabled or connected to the system attendant on the wrong server.

  • A system attendant task will run that requires delivery of a message to the system attendant mailbox, and this task will create a new system attendant mailbox that matches the system attendant mailbox that is on the current server that is running Exchange.

Creation of an Exchange mailbox is a two-stage process. In the first stage, an Active Directory object is assigned ownership of a mailbox when you set appropriate mailbox-enabling attributes on that object. In the second stage, the first client logon or message delivery attempt to the mailbox causes space in the database to be allocated, and the mailbox is then actually created in the database.

The second stage will fail if a mailbox is already listed in a database’s mailbox tombstone table. However, in this scenario, creation of a new system attendant mailbox succeeds because neither database has ever hosted a system attendant mailbox for the current server. The databases have only hosted system attendant mailboxes for their previous servers, and each system attendant mailbox is unique to an individual server.

Scenario 2

Continuing from Scenario 1, you swap the database files back, putting the files for Database1 back on Exchange1 and the files for Database2 back on Exchange2. After you mount the databases, the following two things will happen, but not necessarily in the order listed:

  • The Mailbox Cleanup Agent will mark the previously existing System Attendant mailbox in each database as Disconnected, and the mailbox will be added to the mailbox tombstone table. There are now two System Attendant mailboxes listed on the tombstone table for each database.

    Addition of a system attendant mailbox to a mailbox tombstone table is permanent. Neither of these databases can ever be used again to host a system attendant mailbox for either of these servers. However, either database could be transferred to a third Exchange server, and could host that server’s system attendant mailbox.

  • A system attendant task will run that requires delivery of a message to the system attendant mailbox. The server will be unable to connect or create a system attendant mailbox for delivery of this message because of the tombstone table entry. Therefore, delivery will fail, and errors will be logged in the application log each time the server tries to create the system attendant mailbox.

Scenario 3

Continuing from Scenario 2, you re-enable the system attendant mailbox for server Exchange1 by doing this:

  • Relocate the tombstoned database to another storage group or database location on Exchange1. A single database per server is designated to host the system attendant mailbox. Thus, even if a database contains tombstoned system attendant mailboxes, it can be mounted and run in any storage group or database location except the one that is designated to host the system attendant mailbox. Typically, the first database configured on a server is the system attendant mailbox database.

  • Mount the system attendant mailbox database with no database files present. This action will force generation of new database files that do not contain the system attendant mailbox in the mailbox tombstone table. The system attendant mailbox will be automatically created the first time message delivery is attempted to it.

When moving mailbox databases between servers, it is recommended that you consider the following:

  • You cannot use Move Mailbox to recover from a disabled system attendant mailbox. This restriction is because a functioning system attendant mailbox is required on both source and destination servers that are running Exchange for the Move Mailbox task to work.

  • Purging a disconnected system attendant mailbox from a database will not allow the mailbox to be re-created. Even after the physical mailbox has been purged, the mailbox tombstone entry will remain and will prevent re-creation of the mailbox.

  • If you move a system attendant mailbox database to a different database or storage group location on the same server, the mailbox will not be added to the tombstone table. However, the Mailbox Cleanup Agent will run and disconnect the mailbox, and the mailbox may even be purged. It is possible, however, to move the database back to its original location and the mailbox will be re-created or re-connected automatically.

  • It is possible to change the database that hosts the system attendant mailbox. If you use Exchange System Manager to completely delete the system attendant mailbox database object, Exchange will automatically designate one of the other databases on the server to host the system attendant mailbox. You cannot control the assignment of the new database unless there are only two databases configured on the server.

  • You cannot mount two copies of the same physical database in the same storage group simultaneously. Exchange will fail to mount one of the databases with error -1222, JET_errDatabaseSignInUse. This error indicates a collision of database signatures. If two databases sharing the same signature were allowed to be mounted against the same set of transaction logs, transaction log replay would become impossible.

For more information about moving Exchange mailbox databases, see Moving an Exchange Mailbox Database to Another Server or Storage Group.

For more information about issues with transaction log files when moving Exchange mailbox databases, see Issues with Transaction Log Files When Moving an Exchange Mailbox Database.

 
Was this page helpful?
(1500 characters remaining)
Thank you for your feedback

Community Additions

ADD
Show:
© 2014 Microsoft