If the server is a Simple Mail Transfer Protocol (SMTP) bridgehead server, generally the best disk layout is to create one partition. Messages arrive on the SMTP interface, are written to the Mailroot directory (which should be on an NTFS file system-formatted system), and then are passed to the next computer. To get the best performance, span the Mailroot directory over as many disks as possible. If you have more than one partition on an SMTP bridgehead server, relocate the SMTP Mailroot directory to the fastest partition. For detailed instructions about how to move the Mailroot directory, see How to Move the Mailroot Directory in Exchange Server 2003.

A single spindle should yield a transfer rate of approximately 30 small messages per second. Therefore, when you increase the number of spindles performance also increases.

Your hardware redundant array of inexpensive disks (RAID) configuration is largely dictated by the number of disk spindles available, as shown in the following table.

RAID recommendations

Number of disks	Recommended hardware RAID level and partitioning
2	RAID1, mirroring, one partition
4 or more	RAID0+1, data striping and mirroring, one partition

If your hardware RAID controller has a mirrored, battery-backed, write-back cache, and it allows you to tune the read/write cache ratio, set the ratio to 100 percent write because the server can only acknowledge receipt of a message after it has been written to the disk. Therefore, the faster the server can write to the disk, the more responsive the server is to other computers. Although the message contents must be reread before being relayed to the next computer, the SMTP service has an open file handle to the data, and it can retrieve the contents from the NTFS cache.

If your Exchange 2003 server contains many X.400 connectors, or if it connects to other messaging systems (such as Lotus cc:Mail, Lotus Notes, Novell GroupWise, or Microsoft Mail), create a separate disk partition for transaction logs if you have sufficient spindles. Messages that use these Exchange connectors move data through the Store.exe process and, if the server is under a heavy load, additional performance is gained by splitting the transaction logs from the database.

When a message is received by the message transfer agent (MTA), the data is written to the Mtadata directory on an NTFS partition and passed to the Store.exe process through an MTS-IN virtual queue. Because the message goes to the Store.exe, data is written to the transaction log files. The message then goes through the categorization and routing process. If routing has determined that the message should be sent out through an X.400 connector, the data is moved to the MTS-OUT virtual queue. Other messaging connectors use a similar process.

The number of disk spindles available affects your hardware RAID configuration (see the following table).

RAID recommendations

Number of disks	Recommended hardware RAID level and partitioning
2 - 4	RAID1, mirroring, two partitions (operating system and pagefile on partition 1 and Exchange on partition 2)
5	RAID5 (drive C) for three disks; binaries and database RAID1 (drive D) for two disks; log files
6	RAID5 (drive C) for three disks; binaries and database RAID1 (drive D) for two disks; log files No RAID (drive E) for one disk; pagefile

Although the 6-disk configuration does not use a RAID partition for the pagefile, if high availability of the server is critical, locate the pagefile on a protected partition.

If your hardware RAID controller has a mirrored, battery-backed, write-back cache, and it allows you to tune the read/write cache ratio, set the ratio to 100 percent write for configurations that use a single partition, and 100 percent write on the transaction log partition when you use five or more disks. You will see a better performance gain by using write cache on the transaction logs instead of read cache on the database drive.

If you configure a single database server, your disk design is similar to that of Exchange Server 5.5 and Exchange 2000 Server. Your first priority is to split the transaction logs and database onto separate disk spindles. Not only should the logs be on a different spindle set, but that spindle set should be dedicated only to logs. For example, you do not receive the performance benefits of the split if you put the pagefile or the Windows® 2000 Server or Windows Server™ 2003 operating system on the same spindle set as the logs.

If you intend to create multiple storage groups on the server, your number one priority, again, is to split the logs on to dedicated spindles. However, to gain any performance, you must have a dedicated spindle set for each storage group. After you have a dedicated spindle set, determine how many spindles you have left. On the majority of servers, not many disk slots will be available. Therefore, your best option may be to put all databases on the same partition.

If you spread databases from multiple storage groups over the same array and that array becomes unavailable, all databases from those storage groups (even those databases located on other arrays) temporarily become unavailable. The bad database is marked as down, and the good databases reconnect. The outage should last only a few minutes, and then MAPI clients such as Microsoft Outlook® recover their connections.

With sufficient disks, you can split the properties database (.edb) files from the streaming database (.stm) files. The types of clients that your server accommodates dictate the performance benefit of splitting these files. For example, if you expect to service only Internet Message Access Protocol version 4rev1 (IMAP4) and Post Office Protocol version 3 (POP3) users with large attachments, the read/write size might be larger than the 4 KB that is typically seen with MAPI users on an .edb database. In this case, splitting these files is recommended. You can optimize your disks for .stm files to support the large attachments.

MAPI and Microsoft Outlook Web Access clients read and write data to and from the .edb file. Technically, clients communicate to the Store.exe process. Therefore, they have no understanding of .edb files versus .stm files. All other clients use the .stm file. The following table shows the preferred location that is used by different clients.

Preferred client storage locations

Client type	Submitting data	Retrieving data
Outlook in MAPI mode	.edb files	.edb files
POP3	.stm files (through SMTP)	.stm files
IMAP4	.stm files (through SMTP)	.stm files
Outlook Web Access	.stm files (but full promotion to .edb files)	.edb files
Installable File System (IFS)	.stm files	.stm files
SMTP	.stm files	Not applicable
SMTP (with MAPI data)	.stm files (but full promotion to .edb files)	Not applicable
Microsoft ActiveX® Data Objects (ADO) or OLE DB	.stm files	.stm files
Collaboration Data Objects (CDO) for Exchange 2000 Server	.stm files	.stm files
CDO 1.21	.edb files	.edb files

Although this table indicates the preferred file type, cross conversions may occur. For example, if a POP3 client submits a message, the message data is physically stored in the .stm file. There is some automatic property promotion to the .edb file of the message header and other data. However, now assume that a MAPI client attempts to read the message. In this scenario, the message data in the .stm file is fully promoted to the .edb file (attachments are left in the .stm file and converted in memory). Promotion only occurs from the .stm file to the .edb file. There are no circumstances where data is promoted to the .stm file; all client conversions are performed in memory in these scenarios (with the aid of temporary files).

In the majority of scenarios, there is no real benefit to splitting the .edb files and .stm files on separate spindles. For example, if you have six disks, you must decide whether creating two RAID5 partitions over three disks each would give better performance than a single RAID0+1 (stripe and mirror) partition. In this case, RAID0+1 provides better write performance.

As disks become larger, it is tempting to purchase fewer larger disks to handle user data. Unfortunately, the speed of disks is not relative to the size. Therefore, you may have sufficient physical disk space, but the performance may not be sufficient for the user load. Allocate sufficient physical disk spindles for mailbox servers. It should be noted that specialized storage subsystems that use gigabytes of cache and many racks of hard disks typically have their own partition management and fault-tolerant operating system. When you work with these devices, seek specialist assistance from the hardware vendor.

In summary, the following are your best guidelines for configuring mailbox servers:

• Create a RAID1 partition for Windows and Exchange binary files.
  
• Put the pagefile on a separate RAID1 spindle. For mailbox servers, you should never put the pagefile on a non-RAID partition because the loss of the volume causes the server to stop.
  
• Create one dedicated fault-tolerant partition for each storage group for the transaction logs (for example, RAID1 or RAID 0+1). A two-disk RAID1 partition should yield approximately 300 sequential write I/O operations a second. This capacity should be more than sufficient for a busy five-database storage group.
  
• Create at least one fault-tolerant partition for your databases. If you have only one array, put all databases on this array. If you have multiple arrays, use one array for each storage group (databases only).
  

Databases, SMTP queues, and transaction log files can be moved to different partitions by using Exchange System Manager.

For more information about moving databases and logs, see Microsoft Knowledge Base article 257184, "XADM: How to Move Exchange Databases and Logs in Exchange 2000 Server."

With a physical disk that maintains 64 sectors per track, Windows always creates the partition starting at the sixty-forth sector, therefore misaligning it with the underlying physical disk. To be certain of disk alignment, use Diskpart.exe, a disk partition tool. Diskpart.exe is a utility provided by Microsoft in the Windows Server 2003 Service Pack 1 Support Tools. Diskpart.exe is a command-line utility that can explicitly set the starting offset in the master boot record (MBR). By setting the starting offset, you can track alignment and improve disk performance. Exchange Server 2003 writes data in multiples of 4 KB I/O operations (4 KB for the databases and up to 32 KB for streaming files). Therefore, make sure that the starting offset is a multiple of 4 KB. Failure to do so may cause a single I/O operation spanning two tracks, causing performance degradation.

For detailed instructions, see How to Align Exchange I/O with Storage Track Boundaries in the Optimizing Storage for Exchange Server 2003 guide.