- Planning for Exchange Server 2007
- Understanding AD Design Concepts for Exchange Server 2007
- Determining Exchange Server 2007 Placement
- Configuring Exchange Server 2007 for Maximum Performance and Reliability
- Securing and Maintaining an Exchange Server 2007 Implementation
- Summary
- Best Practices
This chapter is from the book
This chapter is from the book
This chapter is from the book
Configuring Exchange Server 2007 for Maximum Performance and Reliability
After decisions have been made about AD design, Exchange server placement, and client access, optimization of the Exchange server itself helps ensure efficiency, reliability, and security for the messaging platform.
Designing an Optimal Operating System Configuration for Exchange
As previously mentioned, Exchange Server 2007 only operates on the Windows Server 2003 operating system, and is scheduled to be able to run on the next version of the Windows Server operating system, currently referred to as Windows Longhorn. The enhancements to the operating system, especially in regard to security, make Windows Server 2003 the optimal choice for Exchange. Unless clustering (including Cluster Continuous Replication) is required, which is not common for smaller organizations, the Standard Edition of Windows Server 2003 can be installed as the OS.
Avoiding Virtual Memory Fragmentation Issues
The previous iterations of Windows Server have suffered from a problem with virtual memory (VM) fragmentation. The problem would manifest itself on systems with greater than 1GB of RAM, which run memory-intensive applications such as SQL Server or Exchange. The Advanced Server Edition of Windows 2000 Server enabled a workaround for this problem, in the form of a memory allocation switch that allocated additional memory for the user kernel.
Windows Server 2003 includes the capability of using this memory optimization technique in both the Standard and the Enterprise Editions of the software, so that the switch can now be used on any Windows Server 2003 system with more than 1GB of physical RAM. The switch is added to the end of the boot.ini file.
The /3GB switch tells Windows to allocate 3GB of memory for the user kernel, and the /USERVA=3030 switch optimizes the memory configuration, based on tests performed by Microsoft that determined the perfect number of megabytes to allocate for optimal performance and the least likely instance of VM fragmentation. This setting only applies to the 32-bit version of Windows 2003, so it would not apply to Exchange 2007 servers but would apply to 32-bit domain controllers and any other supporting 32-bit servers in an Exchange 2007 environment.
Configuring Disk Options for Performance
The single most important design element, which improves the efficiency and speed of Exchange, is the separation of the Exchange database and the Exchange logs onto a separate hard drive volume. Because of the inherent differences in the type of hard drive operations performed (logs perform primarily write operations, databases primarily read), separating these elements onto separate volumes dramatically increases server performance. Keep these components separate in even the smallest Exchange server implementations. Figure 3.3 illustrates some examples of how the database and log volumes can be configured.
)
Figure 3.3 Database and log volume configuration.
On Server1, the OS and logs are located on the same mirrored C:\ volume and the database is located on a separate RAID-5 drive set. With Server2, the configuration is taken up a notch, with the OS only on C:\, the logs on D:\, and the database on the RAID-5 E:\ volume. Finally, Server3 is configured in the optimal configuration, with separate volumes for each database and a volume for the log files. The more advanced a configuration, the more detailed and complex the drive configuration can get. However, the most important factor that must be remembered is to separate the Exchange database from the logs wherever possible.
Working with Multiple Exchange Databases and Storage Groups
The Enterprise Edition of Exchange Server 2007 not only enables databases of larger than 75GB, it also enables the creation of multiple separate databases on a single server. This concept gives great flexibility in design while enabling reduced downtime and increased performance.
A storage group is a logical grouping of databases that share a single set of logs. Each Exchange Server 2007 Enterprise system can handle a maximum of 50 storage groups per server. Each storage group can contain a maximum of five databases each, although the total number of databases on a server cannot equal more than 50.
In practice, however, each instance of a storage group that is created uses a greater amount of resources, so it is wise to create additional storage groups only if absolutely necessary. Multiple databases, on the other hand, can solve several problems:
- Reduce database restore time—Smaller databases take less time to restore from tape. This concept can be helpful if there is a group of users who require quicker recovery time (such as management). All mailboxes for this group could then be placed in a separate database to provide quicker recovery time in the event of a server or database failure.
- Provide for separate mailbox limit policies—Each database can be configured with different mailbox storage limits. For example, the standard user database could have a 200-MB limit on mailboxes, and the management database could have a 500-MB limit.
- Mitigate risk by distributing user load—By distributing user load across multiple databases, the risk of losing all user mail connectivity is reduced. For example, if a single database failed that contained all users, no one would be able to mail. If those users were divided across three databases, however, only one third of those users would be unable to mail in the event of a database failure.
Understanding Clustering for Exchange Server 2007
Exchange Server 2007 is configured to use Windows Server 2003 clustering for enhanced redundancy and increased uptime. Clustering is an expensive option, but one that will increase reliability of the Exchange Server 2007 implementation.
Clustering options with Exchange Server 2007 have significantly changed over those available in previous versions. Traditional, shared storage clustering is now referred to as a Single Copy Cluster. New options for clustering databases across geographical locations automatically using asynchronous synchronization of log files is now available and is referred to as Cluster Continuous Replication (CCR). More information on clustering with Exchange 2007 can be found in Chapters 4, "Architecting an Enterprise-Level Exchange Environment," and 31, "Continuous Backups, Clustering, and Network Load Balancing in Exchange Server 2007."
Monitoring Design Concepts with Microsoft Operations Manager 2005
The enhancements to Exchange Server 2007 do not stop with the improvements to the product itself. New functionality has been added to the Exchange Management Pack for Microsoft Operations Manager (MOM) that enables MOM to monitor Exchange servers for critical events and performance data. The MOM Management Pack is preconfigured to monitor for Exchange-specific information and to enable administrators to proactively monitor Exchange servers. For more information on using MOM to monitor Exchange Server 2007, see Chapter 20, "Using Microsoft Operations Manager to Monitor Exchange Server 2007."