This white paper provides an overview of the benefits of deploying large mailboxes with Microsoft Exchange Server 2007. It also provides planning guidance to help you successfully implement the deployment of large mailboxes.

Note:
To print this white paper, click Printer Friendly Version in the Web browser.

When you deploy large mailboxes with Exchange 2007, in most cases users can have access to a year or more of their e-mail, voice mail, and fax messages natively from either Microsoft Office Outlook 2007 Service Pack 1 (SP1) or the version of Outlook Web Access that is included with Exchange 2007. Consider the following benefits that users can leverage by maintaining mail in their Exchange mailbox:

• Improved access to Exchange information from anywhere and from any device   By retaining mail in the user's mailbox, a seamless experience can be maintained for accessing data that would previously have been moved to .pst files, archived via a third-party archiving solution, or deleted to stay under a storage quota. By retaining this data in Exchange, users can leverage Windows Mobile powered devices, Outlook 2007, and Outlook Web Access to easily access and act on this data from anywhere.
  
• Improved search   There have been significant improvements to the search functionality offered with Exchange 2007 and Outlook 2007. Additionally, users with Windows Mobile 6 devices now have the ability to search their entire mailbox. Users who must search in .pst file archives and third-party archiving solutions must perform the same search multiple times. Although Windows Desktop Search works well to improve search capability on .pst files, this is only useful at a user's primary workstation. By retaining more mail in a user's inbox, the improvements in content indexing and search with Exchange 2007 can be leveraged by any client, making rapid discovery of user information possible.
  
• Reduced mailbox management   By allowing users to have large mailboxes, they are able to spend less time managing their mailboxes to clean up old items.
  
• Increased productivity for remote workers   Having Exchange-based access to more e-mail data allows remote workers to securely access their Exchange data from Internet kiosks, computers at remote client locations, their Windows Mobile 6 devices, and from home. When e-mail data is stored in a secure location (Exchange) and is accessed in a secure fashion (Outlook Web Access, Outlook Anywhere, and Windows Mobile), security risks inherent in storing information in non-IT managed locations are reduced.
  
• Eliminated .pst files   From an end-user perspective, the ability to live without .pst files offers a significant increase in the usability of the e-mail system. Users no longer need to concern themselves with having to regularly purge e-mail from their mailboxes to stay under low storage quota limits. There is no longer the risk that critical e-mail stored in a .pst file will be lost due to corruption of the .pst file or a disk failure. Elimination of .pst files also ensures that client performance issues due to accessing .pst files over the network are removed. Traveling workers will no longer be unable to retrieve a critical e-mail from a .pst file that is stored on their desktops. Additionally, traveling workers no longer need to worry about e-mail data loss if their portable computer is lost or stolen.
  
• Eliminated third-party archiving stub files   The primary end-user benefit of eliminating stub files when using third-party archiving solutions is providing a consistent mailbox experience from multiple clients (including Windows Mobile). The deployment and management of additional third-party Outlook add-ins are required to make the use of stub solutions work with Outlook. Although some solutions offer access to the archive through Outlook Web Access, none of those solutions offer Windows Mobile device access. In most cases, stub file item size is from 10 to15 kilobytes (KB). The amount of usable data contained in a stub file of that size is minimal, usually a few paragraphs or less. Some of the archival solution providers recommend a stub file size from 1 to 2 KB, which only contains the message header information. If you are retaining a few months of stub files, the number of search hits to review them is relatively low. Therefore, locating the desired message without having to make too many searches through the archive is realistic. However, if several hundred thousand messages are retained, the probability of successfully locating a specific message is challenging when you do not have a significant portion of the message body available. As a result, users probably need to go to the archive multiple times and retrieve many messages to find the desired message. Third-party archiving solutions solve the problem of supporting mailboxes that cannot be bound by size limits and regulatory compliance requirements for archival of all e-mail traffic. However, when deployed, these solutions should be configured to move the e-mail content out of the mailbox without retaining stub files in the mailbox.
  

Return to top

By designing an environment to support large mailboxes with Exchange 2007, administrators take steps to reduce costs and improve IT department agility. Deploying large mailboxes with Exchange 2007 offers the following benefits to administrators:

• Positions IT for high availability and rapid recovery   High availability and disaster recovery have been complex areas in earlier versions of Exchange. The Exchange 2007 CCR feature easily allows administrators to offer a high availability solution to their organization while also moving away from time consuming and complex recovery procedures. CCR offers asynchronous replication of a backup copy of the production data that can be rapidly enabled should a failure of the production server occur. When CCR is deployed, standard recovery times as fast as two minutes are now possible.
  
• Positions IT to reduce or eliminate .pst usage   Because .pst files are not generally managed by IT pros, these files are located ultimately on knowledge workers portable computers, desktops, or file shares; or even in public folders. The .pst files can become a significant burden to organizations by impacting server and network performance, reducing usability, and increasing support costs. Generally, .pst files are not backed up, thereby increasing the risk of data loss. Microsoft does not support access to .pst files over networks. A large percentage of knowledge worker performance issues involve accessing .pst files stored on files servers. Additionally, because .pst files are inherently portable, they pose a data security risk with lost or stolen portable computers as well as providing an easy mechanism for employees to take corporate e-mail with them when they leave the company. Finally, .pst files add an expensive manual step when fulfilling compliance requirements and legal discovery requests because they must first be identified and analyzed by administrators.
  
• Utilizes today's high capacity disk drives efficiently   Performance is the primary constraint when designing Exchange storage subsystems. Because disk capacity tends to increase at a significantly higher pace than disk performance, Exchange storage subsystems have traditionally been designed with under utilized capacity. Designing Exchange solutions with larger mailboxes allows the customer to efficiently and more fully utilize the capacity of these high capacity disk drives.
  
• Reduces end user support overhead   By eliminating .pst files and third-party archiving Outlook add-ins, and by reducing the amount of manual mailbox maintenance that is required with small mailbox size quotas, administrators are able to reduce the number of support calls that must be handled. The amount of time that administrators must spend working with users to reduce mailbox data to stay under low mailbox quotas is significant. Administrators must also spend a large amount of time troubleshooting performance issues due to .pst files stored on the network, recovery of data from corrupt .pst files, and other performance-related issues caused by add-ins and .pst files.
  
• Eliminates stub files when using third-party archiving solutions   Third-party archiving solutions have become popular as corporate compliance requirements and mailbox quota management have gained importance. Many of these archiving solutions offer the ability to leave a small stub file in place of the archived message that can be used by end users to retrieve archived messages from the archival system. Some organizations use the stub file solution as a workaround to offering large mailboxes. One of the goals of stub archiving solutions is to reduce the aggregate mailbox and database size, thereby reducing recovery time objectives (RTOs). On the surface, this appears to be a good idea. However, stub-based archiving solutions have the following technical problems:
  
  • Server performance   Removing the message bodies and attachments from Exchange reduces the mailbox size, but it does not significantly change the server performance for users accessing Exchange via Outlook in online mode and Outlook Web Access. Item counts are the primary performance driver for the Exchange store, and not aggregate size. For example, server performance with a folder containing 100 KB of full e-mail message items is similar to a folder containing 100 KB of stub files.
    
  • Client complexity   Because the use of stub files with a third-party archiving solution requires the deployment and use of Outlook add-ins, a significant amount of time must be spent by administrators to deploy and manage these add-ins. Administrator time is also required to assist end users with technical difficulties using the add-ins. Not deploying stub files removes all of this additional administrative work that must be performed, thereby allowing more time to administrators and end users.
    

Return to top

Large mailboxes require a reduced input/output (I/O) footprint to be a viable option. Exchange 2007 provides I/O reduction features to meet this need by leveraging a new 64-bit architecture and introducing significant changes to the Exchange store and Extensible Storage Engine (ESE).

The larger 64-bit addressable space allows Exchange servers to utilize more memory thereby reducing the required input/output per second (IOPS), enabling the use of larger disks, and allowing lower cost storage solutions such as SATA2 drives. These changes have shown an IOPS decrease of approximately 70 percent with Exchange 2007 on 64-bit hardware when comparing servers with 4,000 user mailboxes.

The database engine and cache in Exchange 2007 has been optimized for scalability resulting in reduced I/O throughput. Larger memory systems allow for a larger amount of cache to be allocated to the Exchange store. This allows for the allocation of more cache on a user-by-user basis. More cache per user increases the probability that data requested by the client will be serviced via memory instead of by the disk subsystem.

In addition, the database page size has been increased from 4 KB to 8 KB. An 8-KB page size means a greater probability that the contents of an entire message will be read during a single I/O operation from a single page in the database.

For more information about these performance improvements, see New Performance and Scalability Functionality.

For detailed planning information for Exchange 2007, see Planning Your Server and Storage Architecture.

There are a few key considerations with respect to the establishment of a maximum mailbox size for Exchange servers that support large mailboxes. These include:

• Maximum database size
  
• Database growth factor
  
• Maintenance capacity
  

Database size limits need to be balanced with other factors including backup and recovery time and the complexity of operations management issues related to the increased number of logical unit numbers (LUN) that must be managed to support the high number of databases. Maximum database size should always be calculated as follows: Number of mailboxes × Maximum mailbox size = Database size.

When evaluating the maximum database size that your organization can support, we recommend that servers that do not use continuous replication have 100-GB database size limits. On servers that use continuous replication, we recommend that you limit the database size to 200 GB. You can use the Exchange 2007 ability to support 50 storage groups to scale up with large mailboxes while still meeting these database size criteria.

For more information about planning your Exchange storage configuration, see Planning Storage Configurations.

When optimizing storage for an Exchange Server 2003 database, size was not a core disk performance issue. The number of items in your core folders (for example, Calendar, Contacts, Inbox, and Sent Item folders), as well as the client type, were primary causes of disk performance issues. This is also true with Exchange 2007. Understanding how item count impacts performance is critically important when planning for the deployment of large mailboxes.

Running Outlook 2007 in cached mode can help reduce server I/O by as much as 70 percent when compared to Exchange 2003. The initial mailbox sync is an expensive operation from a performance perspective, but over time, as the mailbox size grows, the disk subsystem burden is shifted from the Exchange server to the Outlook client. This means that having a large number of items in a user's Inbox will have little effect on the performance of the server. However, this also means that cached mode users with large mailboxes may need faster computers than those with small mailboxes (depending on the individual user perception of acceptable performance).

Recommended minimum client hardware configurations

Note:
If using Outlook 2007 release to manufacturing (RTM) in cached mode, download and install the The 2007 Microsoft Office Suite Service Pack 1 ( SP1 ).

Note:
It is important to keep .ost files free of fragments. You can use the Windows Sysinternals utility Contig to defragment .ost files. To download the latest version of Contig, see Contig v1.54.

Both Outlook Web Access and Outlook in online mode store indexes on, and search against, the server's copy of the data. For moderate size mailboxes, this results in approximately double the IOPS per mailbox of a comparably sized cached mode client. The IOPS per mailbox for very large mailboxes is even higher. The first time you sort in a new way, such as by size, an index is created, causing many read I/Os to the database disk. Subsequent sorts on an active index are inexpensive.

For more information about high item counts and restricted views, see Understanding the Performance Impact of High Item Counts and Restricted Views.

There are a few methods that can be used to maintain an acceptable item count level that should be evaluated when planning for large mailboxes. Creating more top level folders, or subfolders underneath the Inbox and Sent Items folders, greatly reduces the performance impact associated with this index creation, so long as the number of items in any one folder does not exceed 5,000. To achieve this, users can manually create these folders and personally manage their core folders, or administrators can implement an automated management process using Exchange 2007 messaging records management (MRM) feature. We highly recommend that the automated management process be used. For more information about automating mailbox management using MRM to manage core folders, see "Client Usability and Mailbox Management" later in this white paper and the Exchange 2007 documentation topic Managing Messaging Records Management.

Return to top

One of the biggest challenges for end users when working with e-mail generally, and large mailboxes specifically, is structuring and managing the data so that messages can be found quickly and easily. Relying on the end user to manually manage this mail in a way that will result in the best server performance is unrealistic. Automation is the key to maintaining a usable and high performance large mailbox experience. MRM is the records management technology in Exchange 2007 that helps organizations reduce the legal risks associated with e-mail and other communications. MRM replaces, and improves upon, the Exchange 2003 tool called Mailbox Manager. MRM makes it easier to keep messages that are needed to comply with company policy, government regulations, or legal needs, and to remove content that has no legal or business value. This is accomplished through the use of managed folders, which are folders in the user's mailbox to which managed content settings have been applied. The administrator or the user places these managed folders in the user's mailbox, and then the user sorts individual messages or entire folders into the managed folders according to organization policy. Messages in managed folders are then periodically processed by Exchange according to the folder content settings. When a message reaches a retention limit, it is archived, deleted, or flagged for user attention, or the event is simply logged. MRM can be leveraged to help administrators to provide an automated system to assist users with the job of managing their e-mail. MRM can be used by administrators to create policies to help manage user mailbox data in an automated fashion. To illustrate what is possible, consider the following sample policy:

• Move any e-mail older than one year to the Managed Folders\Will Expire folder.
  
• Configure the rule to wait 90 days before deletion so users can choose to move any e-mail in this folder to another managed folder with a longer expiry policy before it gets deleted.
  
• Configure a managed folder similar to Managed Folders\Retain and set a no expiry policy on it. This folder can be used to retain mail that users want to keep longer than a year. To help organize this folder, create subfolders based on the year:
  

                     Managed Folders

                           Retain (No Expiry)

                                 2004

                                 2005

                                 2006

                                 2007

The management of subfolders can be done manually by having users move old messages from the Retain (No Expiry) folder to the correct managed subfolder (for example, messages from the year 2005 are placed in the 2005 folder). Alternately, MRM can be configured to do this automatically. The MRM policies can be set for individual users or for everyone in the organization. Having MRM automate the management of users' old mail ensures that old mail is moved to archive folders in a timely fashion. However, this automation does not provide any flexibility for selecting which messages get moved to the managed folders. If you want to move all messages of a specific age, for all users, to a specific managed folder, an MRM policy can easily be configured to do this. This is ideal for organizations that have unlimited expiry policies and want to provide the ability to easily bulk move old items out of the primary folders and into a managed folder hierarchy.

The .ost file performance is also another factor to consider if there are mailboxes in your organization that exceed 2 GB in size. If users of those mailboxes are running Outlook in cached mode, those users may experience degraded performance as the size of their .ost file grows above 2 GB. To mitigate this issue and improve performance, we recommend that folders containing mail that is accessed infrequently be configured to not synchronize to the .ost file.

Because Outlook 2007 has the flexibility to limit what folders get synchronized to a user's .ost file, you can reduce the size of an .ost file by configuring synchronization policies on a per folder basis. Users can configure their .ost file to only sync folders that contain data they need to regularly access. By configuring the .ost files in this way, users can have mailboxes that exceed 2 GB while still having an acceptable user experience when using cached mode. For those infrequent times when users need to access data that is older than what is configured to synchronize to their .ost file, they can open Outlook in online mode or use Outlook Web Access or Outlook Mobile.

Developing rule sets that will effectively maintain manageable item counts in the core folders is important to maintaining high levels of performance for your Exchange servers. This will require analysis of your user environment and how the MRM rules effect that environment. As you gain an understanding of how the rules impact folder item counts, you can tune the rules to achieve the item count levels that are supportable in your environment.

To learn more about the areas of client usability and mailbox management with Exchange 2007, see the following:

• Managing Messaging Records Management
  
• Using PFDAVAdmin to get the item count within the folders on mailboxes on an exchange servers.
  
• Optimizing Outlook 2007 Cache Mode Performance for a Very Large Mailbox.
  

Return to top

With the release of Exchange 2007, a new feature called remote procedure call (RPC) client throttling is available to administrators to help manage the end-user performance experience and reduce the possibility of server monopolization by a small number of highly active users. RPC client throttling can help prevent client applications from sending too many RPC operations/sec to the Exchange server, which could degrade overall server performance. These client applications include desktop search engines searching through every object inside a user's mailbox, custom applications written to manipulate data located in Exchange mailboxes, enterprise class e-mail archiving products, and customer relationship management (CRM)-enabled mailboxes with e-mail auto-tagging enabled. When a client is identified by the Exchange server as causing a disproportionate impact on the server, the server sends a back-off request to the client to reduce the performance impact on the server. This feature is particularly important when large mailboxes are deployed and in situations where high item counts exist. When users with large mailboxes and with high item counts are very active with their mailboxes, these users can disproportionately impact server performance. When this happens, the server sends a back-off request to those clients thereby minimizing their impact on the server and the rest of the users on the server.

For more information about Exchange 2007 client throttling functionality, see Understanding Exchange 2007 Client Throttling.

Historically, the disaster recovery duration has been one of the biggest issues impacting the ability to deploy large mailboxes. Large mailboxes equate to large databases, which equate to long backup and restore times. Large mailboxes make it more challenging to design a solution that has an acceptable RTO. In the event of a failure or disaster where a database, or entire server, needs to be restored from backup, meeting an acceptable RTO goal is critical. Exchange 2003 provides Volume Shadow Copy Service (VSS) support to address this, but VSS solutions are complicated and expensive because they rely on storage area network (SAN)-based storage with at least two copies of the data (clones). To illustrate this challenge, consider a server with 4,000 user mailboxes that are each 2 GB in size. This is 8 terabytes of database data and 128 GB of logs per day. The best case restore process in this example would be to provision new storage, initiate the restore process, replay the log files, and allow content indexing to crawl the recovered databases. Assuming a Fibre Channel tape device capable of 192 megabytes (MB) per second is used, recovery time would be approximately 12 hours, log replay time would add about two hours, and content indexing would take an additional 12 days. That means the best case to return a server to its state prior to the failure is 12 days and 14 hours. With Exchange 2007, other lower cost options are now available to help meet RTOs and bring services back online rapidly, inexpensively, and with a low level of complexity.

Exchange 2007 now offers the ability to deploy a simple, inexpensive, and fast recovery solution that scales well for use with large mailboxes and also provides high availability. This solution is CCR on direct attached storage.

CCR is a non-shared storage failover cluster solution that uses built-in asynchronous log shipping technology to create and maintain a copy of each storage group on a second server in a failover cluster. CCR is designed to be either a one or two data center solution, providing both high availability and site resilience. CCR is different from clustering in previous versions of Exchange. For details about some of the differences, see Cluster Continuous Replication Resource Model and Cluster Continuous Replication Recovery Behavior.

When CCR is deployed with large mailboxes, it should be the primary recovery and restore mechanism, combined with a weekly full, and daily incremental, off server backup schedule. This solution is effective for either SAN or direct attached storage solutions. We recommend evaluating direct attached storage as a storage option due to its reduced complexity and inexpensive nature.

The following are new Exchange 2007 features that provide additional recovery options, high availability, and backup and restore functionality, which can be used as part of your large mailbox deployment strategy:

• Local continuous replication (LCR)   LCR is a single-server solution that uses built-in asynchronous log shipping technology to create and maintain a copy of a storage group on a second set of disks that are connected to the same server as the production storage group. LCR provides log shipping, log replay, and a quick manual switch to a secondary copy of the data.
  
• Standby continuous replication (SCR)   SCR is a new feature introduced in Exchange 2007 SP1. SCR is designed for scenarios that use, or enable the use of, standby recovery servers. SCR extends the existing continuous replication features and enables new data availability scenarios for Exchange 2007 Mailbox servers. SCR uses the same log shipping and replay technology used by LCR and CCR to provide added deployment options and configurations by providing the administrator with the ability to create additional storage group copies. SCR can be used to replicate data from stand-alone Mailbox servers and from clustered mailbox servers. For further details about SCR, see Standby Continuous Replication.
  
• Improved backup and restore   When you use LCR or CCR, Exchange 2007 enables you to offload Exchange-aware VSS backups from the active copy of a database to a passive copy of a database. Taking a VSS snapshot on the passive copy removes the disk load from the production disks during both the checksum integrity (Eseutil), and subsequent copy to disk or tape. This also frees up more time on the production disks to run online maintenance, MRM, and other tasks.
  

  Note:
  The Windows Server Backup tool is not capable of performing backups using VSS. A VSS-enabled backup product such as Microsoft System Center Data Protection Manager is required.

• Database portability   Database portability provides several features, including the ability to port and recover a database on another server in the Exchange organization. Database portability enables faster disaster recovery strategies to be implemented for both site-level disasters and hardware failures for Exchange 2007 servers. For additional information about database portability, see Database Portability.
  
• Dial tone portability   When a database, server, or data center is lost, you can use dial tone portability to provide access to a new dial tone database on another server in the Exchange organization. For additional information about dial tone portability, see Dial Tone Portability.
  

If you are not using a VSS backup solution, we highly recommend that disk to disk (D2D) or disk to disk to tape (D2D2T) be considered to increase the speed, efficiency, and reliability of your non-VSS backup solution. If your organization does not have legal or policy obligations requiring long-term retention of tape backups, consider eliminating tape from your backup strategy.

Microsoft System Center Data Protection Manager 2007 offers a fast backup solution with smart technology that can help meet your D2D or D2D2T needs by offering seamless data protection for Exchange by leveraging integrated disk and tape media. For more information about DPM, see System Center Data Protection Manager 2007.

For more information about the high availability and disaster recover features of Exchange 2007, see:

• High Availability
  
• Mailbox Server Storage Design
  
• Disaster Recovery Strategies
  
• Best Practices for Minimizing the Impact of a Disaster
  
• What Needs to Be Protected in an Exchange Environment
  
• Using Backup to Back Up and Restore Exchange Data
  

For more information about using Microsoft System Center Data Protection Manager with Exchange 2007, see:

• Protecting Exchange Data with DPM
  
• System Center Data Protection Manager 2007 Protects Exchange Server Datasheet
  
• Protecting Exchange Server with DPM 2007 White Paper
  
• On-demand TechNet Webcast: Protecting Exchange Server with System Center Data Protection Manager 2007
  

Return to top

Large mailboxes bring with them operational challenges that must be evaluated and mitigated to ensure that the health of your Exchange environment is easily maintained over time. Some areas that have historically been problematic with regard to large mailboxes include:

• Long backup times   Performing daily full backups to disk or tape with large mailboxes may not fit in the backup window (too much data in the allowable time).
  
• High log generation during move mailbox operations   Moving large mailboxes around an organization due to massive log file creation can be challenging.
  
• Long database maintenance times   Performing both offline and online database operations may take much longer and possibly exceed maintenance windows. Examples include:
  
  • Online maintenance (online defragmentation)
    
  • Offline defragmentation
    
  • Offline repair
    

Long Backup Times

High Log Generation During Move Mailbox Operations

Long Database Maintenance Times

Online Maintenance (Online Defragmentation)

New ESE features in Exchange 2007 SP1 reduce the time required for online maintenance to run while also providing better events and Performance Monitor counters to track online maintenance completion and value over time. These SP1 changes include:

• Removal of page dependencies
  
• Disablement of partial merges
  
• Passive node I/O improvements
  
• Online defragmentation
  
• Checksumming databases
  
• Page zeroing
  

For more information about these new ESE features, see Exchange Server 2007 SP1 ESE Changes - Part 1 and Exchange 2007 SP1 ESE Changes - Part 2.

Note:

MRM is a scheduled operation that runs against the database in a synchronous read operation similar to backup and online maintenance. The disk cost of MRM depends upon the number of items requiring action (for example, delete or move). We recommend that MRM not run at the same time as either backups or online maintenance. Internal testing at Microsoft shows that MRM can crawl 100,000 items in five minutes. If you use CCR and VSS backups, you can offload the VSS backups to the passive copy, which allows more time for online maintenance and MRM so that neither impacts the other.

Offline Defragmentation

Offline Repair