Microsoft Exchange Server 2007 will reach end of support on April 11, 2017. To stay supported, you will need to upgrade. For more information, see Resources to help you upgrade your Office 2007 servers and clients.
Applies to: Exchange Server 2007, Exchange Server 2007 SP1, Exchange Server 2007 SP2, Exchange Server 2007 SP3
Topic Last Modified: 2016-11-10
When running Microsoft Exchange Server 2007, particularly with respect to the Mailbox server role, it is important that the storage solution be designed correctly at the partition level. For example, although a logical unit number (LUN) (as shown in the Windows Disk Management snap-in) can be subdivided into multiple partitions, it is a best practice to create a single partition on a LUN for Exchange data. Other best practices and recommendations are listed later in this topic, such as using a specific partition type, a specific partition alignment setting, and a specific partition allocation unit size.
It is a best practice to use a single partition on a LUN that is correctly aligned and formatted. When creating a partition on a data volume on Windows Server 2003 and on all x64-based Windows platforms, a new partition type called a GUID partition table (GPT) is available. GPT partitions allow larger than 2-terabyte partitions and up to 128 primary partitions. Replication and cyclic redundancy check (CRC) protection of the partition table adds reliability.
For Exchange log and database LUNs, either master boot record (MBR) or GPT partitions can be used. However, because of their capability for much larger partitions, maintenance procedures on a GPT partition, such as a Windows Chkdsk.exe operation, could take a significant amount of time to complete.
A disk initialized for basic storage is called a basic disk. A basic disk contains basic volumes, such as primary partitions, extended partitions, and logical drives. A disk initialized for dynamic storage is called a dynamic disk. A dynamic disk contains dynamic volumes, such as simple volumes, spanned volumes, striped volumes, mirrored volumes, and RAID-5 volumes.
Dynamic disks do offer some advantages over basic disks; however, because of some of the limitations of dynamic disks, it is a best practice to use basic disks for all server roles. For example, if you move dynamic disks between systems, you may not be able to move the dynamic disks back to the original host. For additional information about dynamic disks, see Microsoft Knowledge Base article 816307, Best practices for using dynamic disks on Windows Server 2003-based computers.
|Dynamic disks are not supported on single copy clusters without using a third-party software application, such as Veritas Storage Foundation for Windows. For more information on Veritas Storage Foundation for Windows, see the Symantec Web site. The third-party Web site information in this topic is provided to help you find the technical information you need. The URLs are subject to change without notice.|
Most partitions are misaligned when they are created by using the Disk Management tool. Therefore, we recommend that you create partitions by using the Diskpart.exe tool instead. Aligning sectors to track boundaries can have performance benefits, depending on the storage. Always use the storage vendor's recommended setting, but if your storage vendor does not have a recommended setting, use 64 kilobytes (KB). When running Exchange 2007 on Windows Server 2003, we recommend that you use Diskpart to align the storage track boundaries on all Mailbox servers (including clustered mailbox servers), Edge Transport servers, and Hub Transport servers, regardless of the partition type you are using. For detailed steps about how to use Diskpart to align input/output (I/O) with storage track boundaries, see How to Align Exchange I/O with Storage Track Boundaries. You do not need to use Diskpart when running Exchange 2007 Service Pack 1 (SP1) on Windows Server 2008.
In Exchange 2007, we recommend that you configure the NTFS file system volumes hosting databases with an NTFS allocation unit size of 64 KB. This recommendation is based on performance improvements seen with large sequential read operations. This type of profile is typically seen with streaming backup and Exchange Server Database Utilities (Eseutil) tasks.
In some scenarios, there is a benefit with sequential I/O, particularly when performing a streaming backup, or when running Eseutil for a Volume Shadow Copy Service (VSS) checksum integrity or database repair. Always use your storage vendor's recommended setting, but if your storage vendor does not have a recommended setting, use 64 KB.
Testing has shown that changing the NTFS allocation size from 4 KB to 64 KB does not result in any increase in transaction log sequential throughput. Therefore, you can utilize the default NTFS allocation size (4 KB) for NTFS volumes hosting transaction log files.