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.

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.