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.

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.

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:

• Planning Processor Configurations
  
  
• Planning Storage Configurations
  
  
• Security and Protection
  
  
• High Availability Strategies
  
  

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:

• Microsoft Exchange Server Jetstress Tool
  
  
• Microsoft Exchange Load Generator
  
  

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.