When thinking about hardware requirements for new or replacement Exchange servers, there are several elements you must consider.
Click here for a printer-friendly version of this step-by-step guide on how to spec Exchange server hardware requirements.
In this step-by-step guide, expert Lee Benjamin (a.k.a. Exchange Guy) walks you through a methodology you can (and should) use to identify your organization's specific Exchange server hardware needs.
Step 1: Identify Exchange server roles
Before you can actually determine the Exchange server hardware specifications, you need to identify what the server will be used for. The basic roles are:
- Mailbox servers that will be directly handling user requests.
- Front-end servers for Web, remote and mobile access.
- Connector servers, which might handle the routing of messages between Routing Groups or to the Internet via SMTP.
Of course, any Exchange server can play multiple roles; but as the environment gets larger, it is useful to separate the functions. A mailbox server is most concerned with disk performance and memory while front-end and connector servers need horsepower in the form of .
Step 2: Estimate the projected Exchange mailbox server size
Formal mailbox sizing tools are available to estimate the expected load for your type of users (light, medium, heavy and insane amount of email) on your planned hardware. Such tools, available from the major server vendors and Microsoft, are useful for large and very large environments. For most Exchange implementations, it is possible to use the following sizing guidelines:
- A small Exchange server might support up to 100 mailboxes.
- A medium Exchange server might support up to 500 mailboxes.
- A large Exchange server might support up to 1,000 mailboxes.
It is quite possible to have an Exchange mailbox server supporting 2,000 to 3,000 mailboxes, but that is beyond the scope of a checklist such as this.
Step 3: Exchange server processors: single, dual or quad?
Any new Exchange server today will be equipped with a healthy Pentium 4 or similar processor. Exchange does not characteristically stress out typical CPUs. A small server is probably fine with a single CPU, but purchasing a server that can support a second CPU later is a good idea (we do want the company to grow). Dual processor systems are the norm for medium servers. Large servers would typically be dual or quad processors.
Step 4: Exchange server memory considerations
Microsoft Exchange uses lots of memory, particularly the information store process (store.exe). Given the low cost of memory today, even the smallest Exchange server has 1 GB of memory installed. A medium or large Exchange server should be configured with 2-4 GB of memory.
And this is where we stop.
Exchange Server 2003 cannot use more than 3-4 GB of physical memory, so don't buy it. Spend your money on faster disks, as discussed in the next section.
Step 5: Calculate the Exchange server disks needed
Estimating the size to which your Exchange server database will grow can usually be estimated from its current size. For small and medium (and some large) installations, the following methodology can be used to figure out how much disk you will need in three years (figuring that to be the life span of a server).
Look at the current size of all your Exchange server databases on the single server. For Exchange 5.5, this would be the two PRIV files and two PUB files (.edb and .stm). With Exchange 2000, you might have additional databases. Total these up; do not include the transaction logs from the other disk. Hopefully you know or can estimate what the size of those databases was a year ago. Figure out the growth ratio from last year to this year and extend that forward three years.
Now, for the occasional need to run utilities such as ESEUTIL, you need a little more than twice the size of your largest database. Exchange allows you to split apart databases to keep them a manageable size and back them up in a reasonable amount of time. You might break the database apart over the course of the three years. Make sure you have 110% of the size of your largest database available as free space (or a little more). Also, I highly recommend acquiring and formatting all the disk when you purchase the computer. Disk space is cheap compared to the labor to upgrade it later.
Example Exchange database sizing
Year - 1 30 GB Year Zero (now) 36 GB (a 20% increase) Year + 1 43 GB Year + 2 52 GB Year + 3 62 GB Free Space 35 GB (110% of the database if split in two) ----- 97 GB
Note: When you get into large and very large scale Exchange servers, your calculations must change from 'disk space based on usage' to 'disk performance based on IOPS' (I/Os per second).
As guidelines, you should use separate physical disks -- and for large servers, different RAID channels -- for operating system, databases and transaction logs. This assures you good performance and recoverability in case of failure. Your disk configuration should be fault tolerant using RAID (redundant array of independent disks) in either RAID 1 (a pair of disks in a mirror), RAID 5 (three or more striped disks), RAID 0+1 (six or more disks both striped and mirrored), or on a Storage Area Network (SAN) that uses RAID. If you have a few extra dollars to spend, get faster disks for your transaction logs. Unless you have extremely large amounts of traffic flowing through your servers, the standard SCSI disk size of the day (36 GB) will be more than enough for your logs (RAID 1 mirror as above).
All: Operating system and Exchange software on RAID 1 Small: Databases on RAID 5 or RAID 1 Transaction logs on different RAID 1 Medium: Databases on RAID 5 Transaction logs on different RAID 1 Large: Databases on SAN, RAID 0+1, or RAID 5 Transaction logs on SAN, RAID 0+1 or RAID 1
Step 6: Acquire Exchange server hardware quality
It is extremely important that you acquire server-class hardware from a brand-name vendor. Most Exchange server installations use hardware from the top server vendors. If the server hardware is not on the Windows HCL (Hardware Compatibility List), you shouldn't run Exchange on it. Microsoft won't provide support if Exchange has a problem and software and patches are not tested on these platforms.
In all but the smallest Exchange Servers or Windows Small Business Servers (SBS), the server should be dedicated to Microsoft Exchange. Exchange-related utilities, such as antivirus and antispam software, should reside on the server (though you may also handle that at the perimeter). If it is not related to Exchange or server management, it does not belong on the box.
Step 7: Requirements for Exchange front-end and connector servers
Exchange front-end servers and connector servers have minimal disk requirements and are often smaller in physical size, like a 1U rack mount server. Front-end servers supporting Outlook Web Access (OWA), Outlook Mobile Access (OMA) and Exchange ActiveSync should have a pair of mirrored disks in a RAID 1 configuration for the operating system and Microsoft Exchange software.
For the needs just listed, additional disks are not necessary for Exchange databases and log files. The data passing through these servers does not get written to the disk (in fact the information store service can be disabled in this scenario).
In the case of a connector server, particularly an SMTP connector to the Internet or an Exchange hub/routing server, data passing through the system does touch down on the disk, and the Exchange database needs to be running. However, the data is transitory and the database should not grow in size (if it does, something is wrong). While a no-no for a mailbox server, a pair of mirrored RAID 1 disks for the Exchange database and logs is sufficient in this case and allows the server to remain small, supporting only four disks.
For these Exchange front-end and connector servers, CPU and memory are more important than the disk. Exchange Server uses multiple processors quite well, particularly for this purpose, and a dual-CPU system is the norm. A memory configuration of 2 GB is often adequate for servers in these roles.
ABOUT THE AUTHOR: Lee Benjamin has over 20 years experience in the messaging industry. As ExchangeGuy Consulting, he specializes in migration and upgrade advice, technical writing and evaluation, product strategy and training and courseware development. He has delivered international training tours for Microsoft, and is a regular trainer for Pinnacle Training. Lee is also Chairman of ExchangeServerBoston and Director for BostonUserGroups, an umbrella organization of over 50 user groups in New England. He is also an analyst at Ferris Research.