Get a Grip on Exchange Data Management

Effectively managing Microsoft Exchange Server data is no easy job. Striking a balance between user demands and Exchange performance and stability has never been fun, but these days, it's a must. Email has become a critical business application, current regulatory demands are putting administrators in the hot seat, and you've gone from spinning plates to juggling knives. To get a grip on your Exchange data, you need a multidisciplinary approach that combines clearly defined policies and appropriate technologies (e.g., storage hardware, monitoring and reporting tools, data-management applications). Where do you begin?

First, let me clarify what I mean by effective data management. I define it as the practice of securely handling stored Exchange data in a way that optimizes the data's storage while providing adequate access to the data. That said, the best way to get started is to examine the financial, technical, and regulatory constraints that apply to your organization. These factors will influence your options for managing the Exchange data that resides in storage groups (SGs), databases, and user mailboxes (including offline folder stores—OSTs—and personal folder stores—PSTs) while providing efficient backup, recovery, and archiving capabilities.

Financial constraints. As messaging traffic continues to grow (in terms of both volume and size) and as more businesses decide to retain messages in online Exchange databases or verifiable offline stores, data storage requirements—and the associated costs—increase. Financial considerations involve more than the cost of extra disks to support larger databases. You must also pay for the required storage infrastructure (e.g., additional storage arrays, backup devices, Storage Area Networks—SANs) and personnel to manage increased data volumes. These costs vary based on the size and nature of your organization. Small organizations of several hundred users might get by with simply increasing storage to satisfy demand, but larger organizations of several thousand users might incur significant costs.

If demand for storage outstrips your capacity to pay for additional resources, you might consider implementing stricter backup policies that retain less unnecessary data, or archiving solutions that help optimize your retention policies. The costs associated with these approaches can often be significantly less than the costs incurred to add more storage in a frantic attempt to satisfy demand.

Technical constraints. Even when your company is able and willing to throw money at data storage, unchecked data growth impairs your ability to maintain effective backup and recovery solutions. Even though tape technology (for example) continues to improve, increased data volumes take longer to back up and restore. Thus, the attempt to meet one need (e.g., easy access to data) can reduce your ability to meet other needs (e.g., quick recovery).

Look for a technical solution that balances these requirements. Such balanced solutions combine the management of online Exchange data with nearline or offline archiving solutions. This approach is appealing because it lets you cap the growth of your primary Exchange storage subsystems and archive critical data according to agreed policy limits, but still keeps that data within easy reach.

Regulatory constraints. Many organizations have implemented policies that mandate the archiving of email communications. In companies that implement archiving solutions to meet internal standards (rather than external requirements), adherence to these policies is largely a matter of internal corporate governance. Organizations that are regulated by external agencies have much stricter requirements for archiving—or more accurately, compliance (a topic that I will discuss in more detail in an upcoming article). A solid regulatory-compliance system intercepts all email that enters, leaves, or circulates within your organization. When you implement such a system, you can guarantee the archiving of all the data in your environment, wherever it may ultimately reside (e.g., in PSTs, on mobile devices).

Once you know which constraints apply to your organization, you can begin to determine the types of guidelines that you need to place on the data that resides in your Exchange server database files, Microsoft Outlook cache files (i.e., OSTs), and PSTs. You'll also be able to decide which backup, recovery, and archiving solutions will work best in your environment.

Dealing with Server–Based Data
Exchange stores email data in databases on the Exchange server (or servers). These databases are arguably the best repository for email content, not least because of the single-instance storage mechanism that exists within each database (though not between databases). In general, data located on the server is more accessible than data in PSTs, at least from a management perspective. Shared information is best stored in Exchange public-folder databases. An Exchange Server 2003 or Exchange 2000 Server machine can contain as many as five databases within an SG and can hold as many as four SGs; thus, one server can contain as many as 20 databases. Established best practice advises against letting your databases exceed 40GB each so that backups—and more importantly, restores—can occur within acceptable time limits.

Storage capabilities determine the maximum number of active users that can be served by a single Exchange system. Exchange storage subsystems must be capable of dealing with the I/O load that the user population will place on the system. The Microsoft guide "Optimizing Storage for Exchange 2003" (http://www.microsoft.com/technet/prodtechnol/exchange/2003/library/optimizestorage.mspx) suggests that you implement a subsystem that can provide an average of about 0.75 I/Os per second per active user. For most subsystems—even those on high-end SAN platforms—this guideline dictates a practical maximum of just less than 4000 active users per server.

You have to keep the guidelines for database size and user limits, along with other performance factors (e.g., transaction log volumes), in balance when sizing your servers, allocating storage, and setting mailbox limits. Figure 1 shows a typical spreadsheet tool that I use to calculate storage requirements. For example, a disk quota of 200MB is achievable for a server that hosts approximately 4000 mailboxes.

Aside from using mailbox quotas (which you can apply on a per-database as well as on a per-user basis) to manage Exchange server–based data, you can use Group Policy to configure the Exchange Mailbox Manager to detect and delete old or large messages from users' mailboxes. This approach can help keep mailbox sizes in check before users run up against the dreaded mailbox quota exceeded message. If you're worried about accidental deletions, Exchange's Deleted Items Recovery feature, when enabled, lets users recover messages even after the Deleted Items folder has been emptied. You can use this great administrative feature to combat user errors that otherwise would result in costly restore operations, but be careful—it can increase the size of your databases. I've seen empirical evidence suggesting that a deleted-items retention period of just 7 days can cause a database bloat of 10 to 30 percent.

   Previous  [1]  2  Next