Planning for Mailbox Servers
Microsoft Exchange Server 2007 will reach end of support on April 11, 2017. To stay supported, you will need to upgrade. For more information, see Resources to help you upgrade your Office 2007 servers and clients.
Applies to: Exchange Server 2007, Exchange Server 2007 SP1, Exchange Server 2007 SP2, Exchange Server 2007 SP3
The Microsoft Exchange Server 2007 Mailbox server role hosts mailbox databases and provides e-mail storage and advanced scheduling services for Microsoft Office 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. For example, you will host a public folder database if you have Office Outlook 2003 clients in your organization or if your Exchange server will interoperate with Lotus Notes. This section will help you decide whether you want to use public folders in your organization.
Cohosting with other server roles Provided that you are not deploying clustered Mailbox servers, 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.
Planning for clustered Mailbox servers If you plan on deploying clustered Mailbox servers, this section will help you decide which of the two Exchange clustering solutions is best for your organization.
Sizing Databases
The recommended maximum database size for Exchange 2007 is greater than the recommended maximum size in previous versions of Exchange Server. For information about recommended database sizes in Exchange 2007, see "Continuous Replication and Database Size" in Planning Storage Configurations.
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.
Online maintenance For optimal database efficiency, it is important to make sure that online maintenance, which includes online defragmentation and other tasks, is completed for each database at least once every two weeks.
In addition to the significant architecture changes found in Exchange 2007, another feature, called continuous replication, also affects our recommendation for maximum database size. Exchange 2007 has two forms of continuous replication: local continuous replication (LCR) and cluster continuous replication (CCR). LCR and CCR completely change the database size recommendations in previous versions of Exchange Server. For more information about the impact of LCR and CCR on database size, see Planning for Local Continuous Replication and Planning for Cluster Continuous Replication.
For more information about disk storage, see Planning Storage Configurations.
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 Set-MailboxDatabase and Set-Mailbox.
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.
You must use public folders if your Exchange 2007 organization meets the following criteria:
You have Outlook 2003 clients in your organization.
Your Exchange server will interoperate with Lotus Notes.
Public folders are generally used for the following purposes:
Shared communication. For example, public folders can be used for discussions through message posts, shared e-mail messages, contacts, group calendars, and archiving of distribution list posts.
Shared content management. Similar to file shares, public folders can be used to store content, such as documentation. Public folders are also helpful for sharing content if you do not require versioning.
Repository purposes. If you require offline storage of information or replicated storage of information, public folders are an ideal repository.
However, public folders were not designed for the following functions:
Archiving data. Users who have mailbox limits sometimes use public folders, instead of personal folder (.pst) files, to archive data. We do not recommend this practice because it increases storage on public folder servers and undermines the goal of mailbox limits.
Document sharing and collaboration. Public folders do not provide versioning or other document management features, such as controlled check-in and check-out functionality and automatic notification of content changes.
In addition to evaluating the features and functionality of Exchange public folders, you should evaluate the features and functionality that are provided by Microsoft Windows SharePoint Products and Technologies for data repositories and collaboration tools. For more information about SharePoint Portal Server 2007, see the Microsoft Office SharePoint Server TechCenter.
Cohosting with Other Server Roles
Provided that you are not deploying clustered Mailbox servers, 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:
Planning for Clustered Mailbox Servers
The decision to deploy clustered Mailbox servers should be based on the availability goals and the available resources of your organization. Exchange 2007 offers two clustered solutions for Mailbox servers: CCR and single copy clusters (SCC). For more information about these solutions, including information about what availability is, how you can improve availability in your organization, and factors to help you decide which solution to use, see High Availability.
Note
Only the Mailbox server role can be installed in a failover cluster. Therefore, if you plan to deploy a clustered Mailbox server, you cannot install any other server roles on the same computer as the Mailbox server role.