Microsoft Exchange can be a great platform to build your organizations email infrastructure around, but getting it to work at peak efficiency can be a challenge. Fortunately, with a few tricks, you can squeeze a few extra drops of performance out of your Exchange server. Here are 6 tips to help get you on the way.
Of all of the resources that Exchange Server uses, few are taxed as hard as the disk subsystem. It is therefore critical to arranged both the databases and the Exchange system files in an optimal manner. Doing so not only affects performance, but also has an effect on your ability to recover from a hard disk failure.
I could easily write an entire series of articles, if not a book on disk optimization techniques. Since I don't have that kind of space though, I will briefly give you my recommendations for Exchange Server file placement.
The server's C: drive should be used to store the Windows operating system and the Exchange system files. I recommend using a dedicated physical disk (not just a dedicated partition) as the D: drive. You should use this disk to store the server's pagefile.
Assuming that your Exchange Server is not connected to a SAN, then I recommend creating three volumes on a RAID 0+1 array. One volume would be used for the server's SMTP and MTA queues. A second volume would be used for the log files for the first storage group. The third volume to be used for the databases for the first storage group. If your server has additional storage groups, then you should use a separate volume for each set of storage group logs and a dedicated volume for each database.
Create aligned partitions
I already explained that Exchange Server is a serious disk resource hog. In some cases though, it is possible to increase the performance of your disk subsystem by as much as 20% by creating aligned partitions.
Before I show you how this technique works, I need to give you several words of caution. First, this technique will only work on drives that use 64 sectors per track. You can find out how many sectors per track your hard disks use by looking at the disks labeled.
The next thing that you need to know is that this is a destructive procedure. Any drives that you run this technique against will be completely erased. It's therefore best to reserve this technique for setting up new servers rather than trying to use it on existing servers.
Another thing that you need to know is that this technique can only be used on basic disks. Don't even think about trying to use this on a dynamic disk. Finally, because of the nature of the technique you can not use it to align the partition that contains your Windows operating system. Furthermore, the server must be running Windows Server 2003 with Service Pack 1 or higher.
Normally, when Windows creates a partition on a drive with 64 sectors per track it places the beginning of the partition on the drive 64th sector. This wouldn't normally be a big deal, but it has a major impact on drives containing Exchange Server databases. Exchange Server reads database files in 32 KB chunks. 32 KB is a multiple of four KB, which is the size of an exchange database page. If a partition begins on a disk's 64th sector contracts on the partition cannot contain an even multiple of 4 KB. This means that many of the chunks of data that exchange will read span multiple tracks. If you can configure the partition so that it contains an even multiple of 4 KB then there will be fewer times when Exchange needs to read chunks of data that span multiple tracks. This in turn increases Exchange Server's performance.
To realign a disk partition, you'll have to use the DISKPART utility that comes as a part of the Windows Server 2003 Support Tools. Begin by opening a Command Prompt window and entering the DISKPART command. Next, enter the LIST DISK command. This will cause DISKPART to display a list of the server's hard drives. Make note of the number that is assigned to the drive that you want to realign. Now enter the SELECT DISK XÂ command where X is the number corresponding to the drive that you want to align. Finally, enter the following command: CREATE PARTITION PRIMARY ALIGN=64
If this command does not work, try substituting the number 128 for 64. Some drives require you to use a value of 128. The next step is to assign the partition a drive letter. To do so, enter the ASSIGN LETTER=X command where X is the desired drive letter. Finally, enter the EXIT command to close the DISKPART utility. The drive now has an aligned partition. You must now simply format the partition to prepare it for use.
If you have worked with Exchange Server for a long time, you've probably noticed that Exchange Server 2003 is much less prone to database corruption than previous versions were. Part of the reason for this is that Exchange Server 2003 is designed to perform database maintenance on a nightly basis.
There are 11 tasks that Exchange Server 2003 attempts to run each night. These tasks are:
- Purge the indexes on the mailbox and public folder stores
- Perform tombstone maintenance on mailboxes and public folders
- Remove expired messages from the dumpster for the mailbox and public folder stores
- Remove expired messages from public folders
- Remove deleted public folders with tombstones over 180 days old
- Clean up message conflicts within public folders
- Update server version information on public folders
- Check for and remove duplicate site folders on public folder stores
- clean up deleted mailboxes on mailbox stores
- Check the message table for orphaned messages (messages with a reference count of 0).
- Perform an online defragmentation of the store
Exchange Server treats the first 10 tasks on the list with equal importance. When the maintenance period begins, Exchange starts by running the first task on the list. It then moves to the second and third task and so on. Depending on the size of the Exchange databases, it might not be possible for all of these tasks to complete within the allotted amount of time. If this occurs, then Exchange picks up where it left off the next night.
The 11th task on the list, performing an online defragmentation of the store, is considered to be more important than the other tasks. It is therefore run each night whether the other tasks have completed or not.
Because the maintenance cycle is very resource intensive, it is scheduled by default to run nightly from midnight to 4:00 AM. You can however change this. The reason why you might want to change the maintenance period is because they can interfere with your nightly backup. If the backup is running at the same time as database maintenance, it won't keep the backup from completing, but it will slow down both the backup and at the maintenance cycle. This means that fewer maintenance tasks will be completed within the allotted amount of time.
I recommend scheduling the maintenance cycle so that it does not occur at the same time as the server backup or as the maintenance cycle for other stores on the server. To do so, open the Exchange System Manager and navigate through the console tree to Administrative Groups | your administrative group | Servers | your server | First storage Group | the store that you want to adjust. Now, right-click on the store that you want to adjust and select the Properties command from the resulting shortcut menu. When you do, you will see the store's properties sheet. Select the properties sheet's Database tab and click the Customize button. You will now see a window that you can use to schedule the maintenance cycle.
It's worth noting that Exchange spends the last 15 minutes of the maintenance cycle performing an online defragmentation. If the online defragmentation does not complete, Exchange can spend up to one-hour beyond the end of the maintenance cycle completing the defragmentation process. You should take this into account when establishing a maintenance schedule.
Reduce the performance impact of spam
One of the complaints that I hear the most often from Exchange administrators is that there mail servers are overburdened. Although I can't deny the importance of having adequate hardware and an optimal configuration, it is almost equally important to deal with spam in an effective manner.
Experts disagree on what percentage of the e-mail in an average organization is spam. I have seen estimates as low as 60% and as high as 95%. In my own organization spam makes up about 90% of the incoming e-mail. Think about that for a minute. Only one out of every ten e-mails is legitimate. The others are all spam. If the spam could be somehow magically eliminated then my Exchange Server's workload can be reduced by over 90%. Do you think that might help increase performance?
In the paragraph above I said that the server's workload can be reduced by over 90% by eliminating spam. That statement might seem a little weird being that spam only makes up about 90% of my total inbound e-mail. The reason why are say that the server's workload could be reduced by over 90% is because if the spam were gone then there would be no need to run ant spam software. After all, even if there were no spam over ant spam software would still be hard at work scrutinizing legitimate messages. This activity has an impact on your server's performance.
Of course in the real world, spam isn't going anywhere. It's here to stay. You can still gain some of the benefits that I have talked about by offloading spam filtering from your Exchange Server to an anti-spam appliance that sits between your perimeter firewall and your Exchange Server.
To see what kind of differences would make, imagine that spam only accounted for about 80% of the mail flowing into your organization. Let's also pretend that you installed an ant spam appliance, but it was only able to intercept about half of the spam that's flowing into your organization. The other half is still being taken care of by the spam filtering software on your Exchange Server.
If this were the case, it would mean that you have decreased the volume of mail flowing into your Exchange Server by about 40%. This would dramatically reduce the server's workload, thus increasing its performance.
Indexing folder content
If your Exchange organization makes use of public folders, then you may have enabled public folder indexing. Indexing public folders makes it much easier to locate specific items within the folder structure. Even so, indexing public folders is often a bad idea because indexing can be so resource intensive.
Indexing can be very processor and disk intensive. The more often the contents of the folder change, the harder the CPU and the disk subsystem must work to keep up. Although indexing is most commonly performed on public folders, mailboxes can be indexed as well. However, mailbox contents are almost constantly changing which means that the index must work very hard to keep up. This can bring an Exchange Server to its knees.
Even if your Exchange Server has enough processing power, memory, and disk resources to be able to run indexing, the size of the index is still an issue. Typically the size of an index is about 20% of the size of the folder being indexed. For example, if you're indexing a 10 GB store than the index could be a whopping 2 GB in size. Keep in mind though that Exchange Server uses single instance storage. If a user posted a message to multiple folders, then the message is only committed to disk once. However that message is indexed separately for each folder. This means that an index could theoretically grow to be larger than expected.
There are some legitimate reasons for using indexing, but if you are concerned about performance or about resource utilization then I would recommend not using indexing on an Exchange Server. If the nature of your business requires you to index public folders, then I would recommend installing a SharePoint Portal Server. SharePoint Portal Server is capable of indexing Exchange public folders, and in doing so off loads the imaging burden from the Exchange Server, freeing those resources for other uses.
Load-balance front-end Exchange servers
So far, most of the performance tips that I had given you focus around the Exchange Server databases and of the disks that they reside on. Although the disk subsystem plays a huge role in the way that Exchange Server performs, there are many other elements that affect performance. For example, if a user is accessing their Exchange mailbox using OWA, then the performance of the Exchange front end server could potentially impact the user's experience just as significantly as the disk subsystem that is supporting the databases on the backend.
If there are a lot of users accessing their Exchange mailboxes through OWA, then the front end Exchange Server could potentially become a bottleneck. Keep in mind though that a front end Exchange Server is really nothing more than an IIS server that just happens to be hosting the OWA Web site. What this means is that you can use the Network Load Balancing (NLB) service to balance the workload on an Exchange Server front end in the same way that you would balance the workload on other types of Web sites.
In case you're not familiar with the NLB service, it works by distributing inbound requests across multiple IIS servers, each with its own copy of the site that is being hosted. The reason that this can work is because the front end servers do not contain a copy of the Exchange Server databases. All of the Exchange Server databases reside on the backend where they can be accessed by any of the OWA servers.
The process of installing the NLB service is fairly simple and straightforward, so I won't bore you with the details. The one thing that you do need to know though is that consistency is extremely important. Each front end server in an NLB cluster must be running the same version of Windows, the same version of Exchange Server, and of the same service pack levels for both Windows and Exchange. Unlike true Exchange Server clusters, NLB clusters do not require any specialized hardware beyond what would be found on any other front end Exchange Server.