Planning for Mailbox Servers

  • Article

[This is pre-release documentation and subject to change in future releases. This topic's current status is: Editing.]

Applies to: Exchange Server 2010* *Topic Last Modified: 2009-08-12

The Exchange Server 2010 Mailbox server role hosts mailbox databases and provides e-mail storage and advanced scheduling services for Outlook users. The Mailbox server role can also host a public folder database, which provides a foundation for workflow, document sharing, and other forms of collaboration. Servers on which the Mailbox server role is installed are called Mailbox servers.

Before installation, we recommend that you take the time to plan for your Mailbox server role deployment. This topic provides the following planning considerations:

  • **Sizing databases   **You must consider several factors when planning the size of your mailbox databases. This section will help you understand these factors and decide what limit you should enforce on your databases.
  • Planning for public folders   Although you can decide whether you want to host a public folder database, there are some scenarios in which you must host one. This section will help you decide whether you want to use public folders in your organization.
  • Cohosting with other server roles   You can deploy the Mailbox server role on computers that also have any combination of the Client Access, Hub Transport, and Unified Messaging (UM) server roles installed. This section helps you decide what combination of server roles best suits the needs of your organization.
  • System Mailboxes   During Exchange 2010 installation, when preparing Active Directory, there are system mailboxes created that can't be logged in by users or administrators. These system mailboxes are created for Exchange 2010 features such as Message Approval and E-discovery. This section helps tells you about the system mailboxes and how to disable them before you decommission your Mailbox server role.

Sizing Databases

The recommended maximum database size for Exchange 2010 is greater than the recommended maximum size in previous versions of Exchange Server. For information about recommended database sizes in Exchange 2010, see Mailbox Server Storage Design Recommendations.

Generally, there are a few common reasons for limiting the size of individual databases:

  • Streaming backup and restore   When using streaming backups, larger databases take longer to back up and restore, which can adversely affect recovery time objectives (RTOs).
  • Offline database maintenance or repair   It may be necessary to use Exchange Server Database Utilities (Eseutil.exe) to defragment, repair, or check the consistency of a database. The larger the database, the longer these procedures will take.

When planning for the size of your databases, you should also plan for how you will enforce limits on database size, either at the database level or at the individual mailbox level. For more information about mailbox limits, see the following topics:

Planning for Public Folders

Before you deploy public folders, it is important to familiarize yourself with the functionality that public folders provide to make sure that they meet the needs of your organization.

Exchange Server public folders are intended to serve as a repository for information that is shared among many users. You should use public folders when your business requires data replication to multiple servers. Access to public folders is integrated with regular mailbox access through the MAPI protocol. For more information on public folders, see Understanding Public Folders and Managing Public Folders.

Cohosting with Other Server Roles

The Client Access server role, Hub Transport server role, Mailbox server role, and Unified Messaging server role can coexist on the same computer in any combination. When considering what combination of server roles to deploy, you should base your decision on capacity and performance planning and on your security and availability requirements. For more information, see the following topics:

It is also a good idea to validate your plan for how you will position your Exchange servers in a test environment. To help with this validation, you can gather data from your existing messaging environment about how your users use Exchange. You can also use various tools to simulate your actual usage in your test environment. For more information about the tools you can use to test your Exchange solutions, see the following:

System Mailboxes

Here are the common names of these system mailboxes as listed in Active Directory. The mailbox name, CN (common name), and GUID of the system mailboxes:

  • E-discovery - SystemMailbox{e0dc1c29-89c3-4034-b678-e6c29d823ed9}
  • Message Approval - SystemMailbox{1f05a927-xxxx-xxxx-xxxx-xxxxxxxxxxxx} where x is a randomly assigned number
  • FederatedEmail.4c1f4d8b-8179-4148-93bf-00a95fa1e042

When you are ready to decommission the last Exchange 2010 Mailbox server role, you should disable these system mailboxes using the Disable-Mailbox cmdlet before you uninstall the Exchange Mailbox server role. When you are decommissioning an Exchange Mailbox server role with these system mailboxes, you should move them (using New-MoveRequest) to another Mailbox server role to ensure functionality.