In“Optimizing Exchange Server, part 1,” I explained that there are three basic areas you need to address when optimizing an Exchange Server environment. These include the organization’s topology, the configuration of the individual servers, and the way the workload is balanced. In part one, I discussed the ideal topology of an Exchange organization. In this Daily Drill Down, I’ll continue the discussion by focusing on some techniques you can use to optimize the individual Exchange servers within your organization.
Before I get started, I need to point out that if you’re planning on trying these techniques in a production environment, you should exercise extreme caution. Although the procedures are designed to be relatively safe, Exchange can be (and often is) a temperamental monster with a nasty disposition. Therefore, before trying any of the techniques discussed in this series, please make sure you have a good backup of every Exchange server in your organization. Remember that making certain types of changes to even a single Exchange server can adversely affect the entire organization.
Windows NT
When it comes to optimizing Exchange Server, it’s important to remember that Exchange isn’t a stand-alone product. Exchange resides on top of a Windows NT Server. Therefore, if Windows NT is performing poorly, Exchange will also perform poorly.

As you might have guessed, the number one rule when it comes to optimizing an Exchange Server is you should make sure Windows NT is healthy and happy. Unfortunately, space limitations prevent me from discussing the methods behind optimizing Windows NT. However, there are numerous articles on the subject on the TechRepublic Web site (such as “Turbo-charging Windows NT”) and at Microsoft’s Support Web site.

The disk subsystem
In case you hadn’t noticed, Exchange Server is an absolute hog when it comes to disk space. In fact, optimizing your server’s hard disks is the single best technique for making Exchange perform better (next to making sure Windows NT is functioning well).

Before you can understand the best way to configure Exchange Server’s disk usage, you need to understand a little about the way Exchange Server uses your server’s hard disks. When it comes to Exchange’s hard disk usage, there are several files at work at any given time.

First, remember that Windows NT Server is the platform on top of which Exchange Server rides. Windows NT doesn’t just stop using the hard disk because it detects Exchange. In fact, it uses the hard disk more than ever. Windows NT routinely accesses various system files from the %Systemroot% directory (usually this is the \WinNT directory) and its subdirectories. Windows NT also uses a page file.
A page file is sometimes referred to as virtual memory. Basically, any time Windows NT begins running low on physical RAM, some of the contents of the system’s memory are written to a file on the hard disk. This file is used in the same way as physical memory, except for the fact that it’s much slower. The page file is usually huge. On most systems, it’s at least as large as the system’s physical RAM. Therefore, if your server has 512 MB of RAM, there’s a good chance your page file will also be at least 512 MB, if not larger.
Aside from the Windows NT system files, Exchange Server uses some of its own files. First, there are the Exchange Server system files, which the system needs to access on occasion. These files make up the actual Exchange Server program. They tend to function in a similar manner to the Windows NT system files. The files are accessed only occasionally and don’t place much of a load on the system in most cases.

Another Exchange component is the Exchange databases. Exchange uses three main databases. These databases make up the directory service, the private information store, and the public information store. The databases are stored in the Jet database format. Although they reference one another, each functions as an independent entity.

The final set of Exchange Server files that deserves to be addressed is the transaction logs. The transaction logs are a series of 5-MB database files. The transaction logs are provided to ensure database integrity. Any time a change is made to an Exchange database, the change is first recorded in a transaction log. For example, if a user receives a message, a record of the message is recorded in a transaction log and then posted to the appropriate database.

During some types of failure situations, in which the database is corrupted, it’s possible for Exchange to use the transaction logs to rebuild the database. For example, suppose your public information store had become corrupted. You could restore it from backup, and then Exchange would use the transaction logs to rebuild the information that had been added since the last backup.

As you can imagine, transaction logs can consume a lot of space. Each transaction log is 5 MB. As soon as one fills up, Exchange creates another one.

There are also two empty transaction logs that consume 10 MB of empty space. If the server runs out of disk space, the empty logs can be deleted to give you enough free space to take care of business. The only thing that keeps transaction logs from totally taking over your server is the fact they are deleted every time you successfully back up the databases.

The engineers who developed Exchange discovered you don’t need transaction logs to recover data that had already been written to a backup device. It’s easier and less time consuming to simply restore the entire database and then just process the relatively few transactions that have occurred since the time of the last backup.

Optimizing hard disk configurations
Now that you know something about the way Exchange uses the hard disk, let’s look at the optimal hard disk configuration. The suggestions listed below are simply things that have worked well for me in the past. Obviously, it’s impossible to implement this exact configuration on every server, but it gives you something to shoot for.

When setting up a new Exchange Server, I usually try to totally isolate Windows NT from the Exchange Server environment. I prefer to have two physical hard drives (not just partitions on the same hard disk) for Windows NT. I use the first hard drive to store the Windows NT system files and the second hard drive to store the page file.

If such an arrangement isn’t possible, it won’t hurt anything. Windows NT just runs faster when the page file resides on a separate physical disk from the operating system. If space permits, I usually also include the Exchange Server system files on the same hard disk as the Windows NT system files. These files don’t take up much room and aren’t heavily used, so putting them with Windows NT is no big deal.

I also like to use a separate physical hard disk for the transaction logs. If you’re worried about fault tolerance, you can mirror this hard drive, but it should definitely be reserved exclusively for the transaction logs. Remember that the transaction logs exist for disaster-recovery purposes. Therefore, you never want them to be on the same partition, or even the same physical disk as the database files. If the partition (or physical disk) containing the database files were to become corrupted, you could easily lose the transaction logs, too, if they existed in the same location as the databases. In such a situation, your server would be forced to go back to the time of your last backup.

With some systems, this is no big deal, but you don’t want this to happen to your e-mail server. It’s easy to lose track of which notes were sent out successfully and which notes are still waiting to be sent. Likewise, you don’t want to lose critical messages others have sent to you or other employees. Remember that a database failure also affects your calendar and appointment schedule. I could go on, but I’m sure you get the point.

Once you’ve isolated the transaction logs, I recommend placing the Exchange databases on a RAID 5 stripe set. A RAID 5 stripe set offers high performance combined with fault tolerance. Basically, a RAID 5 array uses a minimum of three equally sized hard disks to provide the capacity of two hard disks. Each file written to the partition is spread across the hard disks in a way that records a portion of the file on each disk. Each hard disk in the array records enough of the file that if any one drive in the array were to fail, enough information exists on the other drives to rebuild the lost data.

Most RAID 5 arrays are designed to keep functioning after a failure until you have time to replace the failed drive. RAID 5 arrays also provide much more speed than a standard hard disk. Because the array is writing a portion of any given file to each drive, file reads and writes increase in speed based on the number of drives in the array.

For example, if you had five hard drives in an array, data could be read from the array roughly five times faster than the same file could be read from a single hard disk (assuming all of the hard disks were created equally). Such performance gains are perfect for a disk-hungry program like Exchange.

Doing the deed
So far, I’ve discussed how to set up a sort of Exchange Server hard disk utopia. However, all of the theory in the world doesn’t do much good if you already have an Exchange server running in a production environment and don’t know how to move things around. Fortunately, with the exception of the Windows NT system files, it’s easy to move around the other files I’ve discussed to provide your system with an optimal configuration.

Before you move anything, though, remember that the operations I describe in the remainder of the Daily Drill Down require you to stop the Exchange services and, in some cases, reboot the server. Depending on the speed of your machine, the size of your hard drives, the size of your databases, and other factors I won’t even try to explain, some of the processes I’ll describe may take several hours to complete. Therefore, don’t tell your users to sign out for five minutes and expect to have the server back up by then. Your best bet is to do these processes at night or on the weekend.

The first thing you may want to move is the Windows NT page file. To do so, open Control Panel and double-click the System icon. When you see the System Properties sheet, select the Performance tab. This tab includes a section devoted to virtual memory. You can click the Change button to change the virtual memory settings. All you have to do is create a sufficiently large page file on another drive and then remove the current page file.

Two words of caution: First, the changes won’t take effect until you reboot the server. Second, don’t even think about trying to run Windows NT without a page file.

Moving around the Exchange-related files tends to be considerably easier but is much more time consuming. To do so, you’ll have to use a utility called the Microsoft Exchange Optimizer, found on the Microsoft Exchange menu. The Microsoft Exchange Optimizer is a wizard-style utility that asks you some questions about your system, does some analysis, provides recommended file locations, and ultimately allows you to move the files wherever you want.

The Microsoft Exchange Optimizer will stop all the Exchange-related services and then take a look at your system. It will consider the number of hard disks on your system and the free space available on each. The tool will also take into account such factors as the number of users who use the server and the total number of users in the organization. It will compare this information to your existing databases and recommend locations for each type of Exchange-related file. You can see an example of these recommendations in Figure A.

Figure A
The Exchange Optimizer program will recommend file locations based on its analysis of your server.

It’s important to point out that the Exchange Optimizer tool won’t always give you the best possible configuration. Therefore, don’t be afraid to ignore the recommendations and set your own configuration.

Conclusion
In this Daily Drill Down, I discussed some techniques you can use to optimize the disk subsystem that Exchange Server depends on so heavily. In upcoming Daily Drill Downs, I’ll discuss more techniques you can use to optimize individual Exchange servers.

Brien M. Posey is an MCSE who works as a freelance technical writer and as a network engineer for the Department of Defense. If you’d like to contact Brien, send him an e-mail. (Because of the large volume of e-mail he receives, it’s impossible for him to respond to every message. However, he does read them all.)

The authors and editors have taken care in preparation of the content contained herein but make no expressed or implied warranty of any kind and assume no responsibility for errors or omissions. No liability is assumed for any damages. Always have a verified backup before making any changes.