Microsoft Exchange and Remote Desktop Services Specialists


Microsoft Exchange Server and
Blackberry Enterprise Server news, views and fixes.

Hardware Configuration for Exchange 2003

Despite Exchange 200x being around for over seven years, the question of hardware configuration is still frequently asked and discussed on forums and message boards around the internet.

Exchange is a high transactional database, which means it is constantly writing to its hard disks. Therefore, when you are considering what hardware to purchase for Exchange, you need to remember that you get the best performance from Exchange by prioritising its storage needs.

From a processing power point of view, you can large numbers of users on low end hardware. A single processor with a 1 gb of RAM will support 100s of users on a dedicated machine.

If you have one eye on a possible Exchange 2007 deployment later on, then get the smallest number of RAM modules that you can afford, so that you can put more RAM in place later. Although remember that you cannot in place upgrade to Exchange 2007, so you will need another machine to do a swing migration.

Also remember that Exchange 2007 is 64 bit only, but Exchange 2003 doesn't install on to 64 bit. Therefore you could purchase a machine with a Windows 2003 64 bit license, but you would need a 32 bit media kit to install Windows for use with Exchange 2003.

The rules with hardware selection on Exchange 2007 will change anyway, as it is 64 bit and can make better use of more processing power and memory. Despite these advances in the use of the processor and memory, the storage configuration outlined here will still be valid with Exchange 2007.

Array Selection

At a minimum, even with a small number of users, you should be looking to use at least two arrays.

- A mirrored array of two disks for the OS, application files and logs.
- A RAID 5 array of at least three disks for the database.

If you have a machine that can take six disks, then another disk as a hot spare can ensure that the server is able to run at optimum levels most of the time.

Remember that hard disks will fail, it is just a matter of when.

Partitioning the Disks

Partition wise, the mirrored array would be split. Usually 20gb and then the rest. So if you have 72gb of space you would have a 52gb second partition.
The transaction logs would then go in to a folder on this partition.

The files go in to a folder on the partition rather writing to the root of the partition for a number of reasons.
- it makes it easy to keep track of what they are
- it ensures that the server keeps running - Windows doesn't like lots of files in its root.
- it allows you to put something else on to this partition. I often share it with the message tracking logs.

Why partition the drive?
Partitioning isn't done for performance reasons, but for data protection.
If something happens, for example a mail loop or some kind of attack, the transaction logs will grow very quickly, using all the space that is available.
By having a restriction on the drive, there will be a point where no more logs can be written. At that point Exchange will dismount the stores.
However, the machine will still be running, giving you access to troubleshoot the problem.
If the logs had been on the same partition as the OS, then you may have a crashed server as well to deal with. Windows doesn't like having no free hard disk space.

The other array for the database would be a single partition.

More Disks Means No Partitions

If you have the budget, then go for something that can take at least eight disks.

2x mirrored OS
2x mirrored transaction logs
3x RAID 5 database
Hot spare.

If you are on Enterprise edition, then you can further increase the performance by having multiple arrays - with each array housing a separate storage group or mailbox store. The bottleneck at that point would then be the drives housing the transaction logs. At that point you could even go as far as having two arrays for each storage group - one for the database and one for its logs. It all depends on what your budget is like.

What about disk space?

The disk space required for the OS and transaction logs isn't really an issue. The smallest drives you easily purchase now are 72gb, which will be fine for a combined OS/Logs array or for separate arrays for the OS and logs.

The database array provides much more scope and very much depends on which version of Exchange you are installing.

If you are installing Enterprise edition, which is theoretically unlimited in storage space, then you need to make a guess at how much space you will need. If you already have Exchange, look at your current store size, double it and add at least 30%. If you have the users mailbox sizes restricted, then your life is a little easier as you can ask HR for a predicated population growth. However you are still taking an educated guess.

If you are installing Standard edition of Exchange 2003, then things are much easier, as there is a hard limit.
Standard edition of Exchange 2003 with Service Pack 2 can support up to 75gb in the mailbox store and the public folder store. This gives you a maximum use of 150gb.
Allowing for the use of the recovery storage group, recovering a store at the maximum size you would need another 75gb.
While Public Folders cannot use the RSG you should probably allow enough space for them to be recovered as well, meaning a total capacity of around 300gb.
Therefore 3x 146gb drives would be enough (giving you about 250gb of space) or if available, three 300gb drives.


Don't forget to purchase a good fast RAID card. If you have decided to make the investment in the storage, then ensure that the RAID card is up to the job. Don't put a small 64mb RAID card in and hope it will support your large database and high transactions. At least a 128mb RAID card and if your budget will take it, go for something even faster. You should aim to get the data to the disks as quickly as possible.


When faced with a choice between RAM/Processor and storage, storage wins every time. That is where the most can be gained from the investment on an Exchange server.