Exchange Server stores its databases on either local disks (Directly Attached Disks), Network Attached Storage (NAS), or Storage Area Networks (SAN). Either way you go, when you plan to build your new Exchange server, calculating the required disk space for these databases is a crucial part of the design phase.

When calculating the right storage size you should keep in mind the following considerations:

Store size limits - By default, the size limit of each database on a server running Exchange 2000 and Exchange Server 2003 Standard Edition is 16 GB (this limit is also enforced in SBS 2000/2003). Exchange Server 2003 Service Pack 2 (SP2) is supposed to remove this limit and thus allow for further DB size growth.

After installing Exchange Server 2003 Service Pack 2, the default size limit for each Exchange database is 18 GB, but can easily be configured to allow for database size limits of up to 75 GB per database (for the Standard and SBS 2003 versions), or up to 8000 GB (or 8 TB) per database (for the Enterprise version).

Log files accumulation - Exchange log files accumulate on the hard disk. You can control where these log files will be placed (and indeed they should NOT be placed on the same disk arrays as the databases), but nevertheless they will accumulate. Log files are purged after successful online backups of the Information Store (read Backing up Exchange 2000/2003 with NTBACKUP), but in case something goes wrong with the backup job (or tape device) you might find yourself with more log files than you expected. Plan for at least 2 weeks of log file accumulation.

The number of the log files that will be stored between backups can vary depending on the number of transactions performed by Exchange. Small servers can create up to 100 log files each day, while large servers can create thousands of log files.

Number of users per server - Exchange Server 2003 servers can hold up to 4000 mailboxes per server if properly tuned. However that doesn't mean you need to plan for such a number of users. Count the number of users that will have their mailboxes on the server, and multiply them by their mailbox size limits.

Mailbox size limitation - Users need regulations. Users need someone to tell them what to do, and for how long they should be doing it. This may be a somewhat optimistic scenario, and for many IT personnel it may not even be an option, but without setting mailbox limits your users will run amok and just stock everything they get in their mailboxes. Plan for several mailbox limit levels - small mailboxes of up to 50 MB (good for contract and temporary users); medium mailboxes of up to 300-500 MB; and large mailboxes of up to 1.5 - 2 GB. VIP users with little or no mailbox size limitations - No matter how carefully you plan your mailbox limits, there will always be those smart guys that either hold a role that require them to use more storage space, or have some sort of political influence that will allow them to play off limits. You should count these users and plan for the requires storage space.

Note that whatever you do, you won't be able to limit their mailbox size via the ESM or Active Directory Users and Computers snap-ins if the required size is beyond 2GB. Future growth - The current number of users, mailboxes, public folders and other Exchange items are known, but one should plan for future growth. How many users is your company planning to add in the next 3 years? Is your company planning on acquiring another company and bringing their users and data aboard? Although many of these issues cannot always be anticipated in time, they should be taken into account when purchasing the new hardware and when planning for expensive storage devices.

Administrative tasks - Such as store Offline Defragmentation. Such a procedure requires at least 110% free space on the disk (you could change this path, if necessary). Other administrative tasks such as store repair (in case your store became corrupt and restoring from backup is not an option). All these require additional free space on the store's hard disk.

Restore operations - Especially when using the Recovery Storage Group feature to recover an existing store to a production server, while the actual store is still in use. For that you'll need at least the size of the would-be restored store made available on the disk, although I would suggest keeping a larger area free would be better, just in case. Here too, one could point the Recovery Storage Group to a different hard disk, but again, these are things one should keep in mind.