Applications Server

Optimizing Exchange 2007 Servers & Monitoring Exchange Server 2007

- Free product key for windows 10
- Free Product Key for Microsoft office 365
- Malwarebytes Premium 3.7.1 Serial Keys (LifeTime) 2019
11/17/2011 9:09:30 AM

Optimizing Exchange 2007 Servers

With the separation of various roles in Exchange 2007, individual optimimizations vary from role to role. The following sections address the various roles in Exchange 2007 and how to optimize the performance of those roles.

Optimizing Mailbox Servers

Of all the servers in an Exchange 2007 environment, the Mailbox server role is the one that will likely benefit the most from careful performance tuning.

Mailbox servers have traditionally been very dependent on the disk subsystem for their performance. Although this has changed in Exchange 2007, it is important to understand that this change in disk behavior is very dependent on memory. As such, the general rule for performance on an Exchange 2007 Mailbox server is to configure it with as much memory as you can. For example, in Exchange 2003, if you had a load of 2,000 users that generated an average of 1 disk I/O per second and you were running a RAID 0+1 configuration, you would need 4GB of memory and 40 disks (assuming 10k RPM disk and 100 random disk I/O per disk) to get the performance you’d expect out of an Exchange server. In Exchange 2007, you could reduce the number of disks required by roughly 70% if you increased the system memory to 12GB of memory.

As you can see, with a Mailbox server, the trick is to balance costs against performance. In large implementations, it is less expensive to replace high-performance disks with memory. This makes direct attached disks a viable choice for Exchange 2007 Mailbox servers.

Another area where a Mailbox server benefits in terms of performance is the disk subsystem. Although you’ve just seen that the disk requirements are lower than previous versions of Exchange, this doesn’t mean that the disk subsystem is unimportant. This is another area where you must create a careful balance between cost, performance, and recoverability. The databases benefit the most from a high-performance disk configuration. Consider using 15k RPM drives because they offer more I/O performance per disk; generally 50% more random I/O capacity versus a 10k RPM disk. Given the reduction in disk needed to support the databases, you should consider using RAID 0+1 rather then RAID 5 so as not to incur the write penalties associated with RAID 5. The log files also need fast disks to be able to commit information quickly, but they have the advantage of being sequential I/O rather than random. That is, the write heads don’t have to jump all around the disk to find the object to which they want to write. The logs start at one point on the disk and they write sequentially without having to modify old logs.

In a perfect world, the databases and logs are all on their own dedicated disks. Although this isn’t always possible, it does offer the best performance. In the real world, you might have to occasionally double up databases or log files onto the same disk. Be aware of how this affects recoverability. For performance, always separate the logs from the databases as their read/write patterns are very different. It also makes recovery of a lost database much easier.

Mailbox servers also deal with a large amount of network traffic. Email messages are often fairly small and as a result, the transmission of these messages isn’t always as efficient as it could be. Whenever possible, equip your Mailbox servers with Gigabit Ethernet interfaces. If possible, and if you aren’t clustering the Mailbox servers, try to run your network interfaces in a teamed mode. This improves both performance and reliability.

As Mailbox servers also hold the public folder stores, consider running a dedicated public folder server if your environment heavily leverages public folders. Public folder servers often store very large files that users are accessing, so separating the load of those large files from the Mailbox servers results in better overall performance for the user community.

For companies that only lightly use public folders, it requires some investigation of the environment to see if it is better to run a centralized public folder server or if it is better to maintain replicas of public folders in multiple locations. This is usually a question of wide area network (WAN) bandwidth versus usage patterns.

Optimizing Mailbox Clusters

Mailbox servers in Exchange 2007 offer a new function known as Cluster Continous Replication. Mailbox servers clustered in this way can be optimized in much the same way as standalone Mailbox servers. One of the key differences is that network interfaces should not be teamed on a Windows cluster. This is because the small amount of latency introduced in the load-balancing algorithm of the teaming can cause the cluster to believe that a node is not available and trigger an unnecessary failover of resources.

Mailbox clusters in Exchange 2007 should always be configured with multiple network interface cards (NICs) and a NIC should be dedicated to cluster traffic only. This helps ensure that the cluster heartbeat is always working properly. In the case of “local clusters,” you should always use a hub between the heartbeat NICs, so that link state is not lost if you reboot a system.

On a mailbox cluster, it is very important that the log files be placed on a fast disk subsystem. This is because in addition to storing transactions for the database, the logs are also shipped to the remote node for reprocessing. This is how the two nodes maintain similar information so that a failover can be accomplished without the need for shared storage.

Optimizing Client Access Servers

Client Access servers (CASs) tend to be more dependent on CPU and memory than they are on disk. Because their job is to simply proxy requests back to the Mailbox servers, they don’t need much in the way of local storage. The best way to optimize the Client Access server is to give it enough memory that it doesn’t need to page very often. By monitoring the page rate in the Performance Monitor, you can ensure that the CAS is running optimally. If it starts to page excessively, you can simply add more memory to it. Similarly, if the CPU utilization is sustained above 65% or so, it might be time to think about more processing power.

Unlike Mailbox servers, Client Access servers are usually “commodity” class servers. This means they aren’t likely to have the capacity for memory or CPU that a Mailbox server might have. It is typical to increase the performance of the Client Access servers by simply adding more servers into a load-balanced group.

This is a good example of optimizing a role as opposed to a server that holds a role. As you start to add more services to your Client Access servers, such as Outlook Anywhere or ActiveSync, you will see an increase in CPU usage. Be sure to monitor this load because it allows you to predict when to add capacity to account for the increased load. This prevents your users from experiencing periods of poor performance.

Optimizing Hub Transport Servers

The goal of the Hub Transport server is to transfer data between different Exchange sites. Each site must have a Hub Transport server to communicate with the other sites. Because the Hub Transport server doesn’t store any data locally, its performance is based on how quickly it can determine where to send a message and send it off. The best way to optimize the Hub Transport role is via memory, CPU, and network throughput. The Hub Transport server needs ready access to a global catalog server to determine where to route messages based on the recipients of the messages. Placing a global catalog (GC) in the same site as a busy Hub Transport server is a good idea. Ensure that the Hub Transport server has sufficient memory to quickly move messages into and out of queues. Monitoring available memory and page rate gives you an idea if you have enough memory. High-speed network connectivity is also very useful for this role. If you are running a dedicated Hub Transport server in a site and you find that it’s overworked even though it has a fast processor and plenty of memory, consider simply adding a second Hub Transport server to the site because they automatically share the load.

Optimizing Edge Transport Servers

The Edge Transport server is very similar to the Hub Transport server, with the key difference being that it is the connection point to external systems. As such, it has a higher need for processing power because it needs to convert the format of messages from Simple Mail Transfer Protocol (SMTP) to Messaging Application Programming Interface (MAPI) for internal routing. Edge Transport servers are often serving “double duty” as antivirus and antispam gateways, thus increasing the need for CPU and memory. The Edge Transport role is one where it is very common to optimize the service by deploying multiple Edge Transport servers. This not only increases a site’s capacity for sending mail into and out of the local environment, but it also adds a layer of redundancy.

To fully optimize this role, consider running Edge Transport servers in two geographically disparate locations. Utilize multiple MX records to balance out the load of mail coming into the company. Use your route costs to control the outward flow of mail such that you can reduce the number of hops needed for mail to leave the environment.

Keep a close eye on CPU utilization as well as memory paging to know when you need to add capacity to this role. Utilizing content-based rules or running message filtering increases the CPU and memory requirements of this role.

Optimizing Unified Messaging Servers

The Unified Messaging server is a new role in the Exchange world. In the past, this type of functionality was always performed by a third-party application. In Exchange 2007, this ability to integrate with phone systems and voice mail systems in built in. As you might expect, to optimize this role, you must optimize the ability to quickly transfer information from one source to another. This means that the Unified Messaging role needs to focus on sufficient memory, CPU, and network bandwidth. To fully optimize Unified Messaging services, strongly consider running multiple network interfaces in the Unified Messaging server. This allows one network to talk to the phone systems and the other to talk to the other Exchange servers. Careful monitoring of memory paging, CPU utilization, and NIC utilization allows you to quickly spot any bottlenecks in your particular environment.

General Optimizations

Certain bits of advice can be applied to optimizing any server in an Exchange 2007 environment. For example, the elimination of unneeded services is one of the easiest ways to free up CPU, memory, and disk resources. Event logging should be limited to the events you care about and you should be very careful about running third-party agents on your Exchange 2007 servers.

Event logs should be reviewed regularly to look for signs of any problems. Disks that are generating errors should be replaced and problems that appear in the operating system should be addressed immediately.

Optimizing Active Directory from an Exchange Perspective

As you likely already know, Exchange 2007 is very dependent on Active Directory for routing messages between servers and for allowing end users to find each other and to send each other mail. The architecture of Active Directory can have a large impact on how Exchange performs its various functions.

When designing your Exchange 2007 environment, consider placing dedicated global catalog servers into an Active Directory site that contains only the GCs and the local Exchange servers. Configure your site connectors in AD with a high enough cost that the GCs in this site won’t adopt another nearby site that doesn’t have GCs. This ensures that the GCs are only used by the Exchange servers. This can greatly improve the lookup performance of the Exchange server and greatly benefits your OWA users as well.

In the case of a very large Active Directory environment, for example 20,000 or more objects, consider upgrading the domain controllers to run Windows Server 2003 64-bit. This is because a directory this large can grow to be larger than 3GB. When the Extensible Storage Engine database that holds Active Directory grows to this size, it is no longer able to cache the entire directory. This increases lookup and response times for finding objects in Active Directory. By running a 64-bit operating system on the domain controller, you can utilize the larger memory space to cache the entire directory. The nice thing in this situation is that you retain compatibility with 32-bit domain controllers, so it is not necessary to upgrade the entire environment, only sites that will benefit from it.

Monitoring Exchange Server 2007

A variety of built-in Microsoft tools are available to help an administrator establish the baseline of the Exchange Server 2007 environment. Among these, the Performance Monitor Microsoft Management Console (MMC) snap-in is one of the most common tools used to measure the capacity requirements of Exchange Server 2007. This MMC tool is built in to Windows Server 2003.

Using the Performance Monitor Console

The Performance snap-in enables an in-depth analysis of every measurable aspect of the Exchange server. The information that is gathered using the Performance snap-in can be presented in a variety of forms, including reports, real-time charts, or logs, which add to the versatility of this tool. The resulting output formats enable an administrator to present a baseline analysis in real time or through historical data. The Performance snap-in, shown in Figure 1, can be launched from the Start, Administrative Tools menu.

Figure 1. The Performance snap-in.

Using Network Monitor

The Network Monitor, as illustrated in Figure 2, is a reliable capacity-analysis tool used specifically to monitor network traffic. Two flavors of the Network Monitor are available: one that is built in to Windows Server 2003 and one that is provided in Systems Management Server (SMS). The one included with Windows Server 2003 is a more downscaled version. It is capable of monitoring network traffic to and from the local server on which it runs. The SMS version monitors network traffic coming to or from any computer on the network and enables you to monitor network traffic from a centralized machine. This facilitates gathering capacity-analysis data, but it is also important to note that it could present possible security risks because of its ability to promiscuously monitor traffic throughout the network.

Figure 2. The Network Monitor interface.

The one built in to Windows can be installed via the Add/Remove Programs interface and is accessible via the Administrative Tools.

There are also third-party network monitoring tools, such as Ethereal, that are very useful for monitoring network performance because they pick up things such as excessive retransmits between hosts, CRC errors, or odd protocol transmissions that could affect the performance of Exchange 2007 servers.


Ethereal is a free tool that can be downloaded from

Using Task Manager

Task Manager displays real-time performance metrics, so an administrator can quickly get an overall idea of how the Exchange 2007 server is performing at any given time. Its biggest downfall, however, is that it does not store any historical data, so it not a suitable tool for capacity-analysis purposes. Task Manager is typically used as a quick check to see if anything is out of the ordinary. If a server appears to be running slow, using Task Manager and using the Processes tab allows you to sort the processes by CPU or Memory use and quickly see if something is noticeably different from its baseline value. This is a quick way to spot common issues like an antivirus scanner taking up all the CPU time or an lsass.exe process using an excessive amount of memory.

Other -----------------
- Optimizing an Exchange Server 2007 Environment : Analyzing Capacity and Performance
- Exchange Server 2010 : Planning Certificates for Autodiscover (part 2) - Deploying Exchange Certificates
- Exchange Server 2010 : Planning Certificates for Autodiscover (part 1) - The X.509 Certificate Standard
- Exchange Server 2010 Autodiscover : Autodiscover Concepts
- Active Directory 2008 : Proactive Directory Maintenance and Data Store Protection (part 5) - Protecting DCs as Virtual Machines
- Active Directory 2008 : Proactive Directory Maintenance and Data Store Protection (part 4) - Performing Proactive Restores
- Active Directory 2008 : Proactive Directory Maintenance and Data Store Protection (part 3) - Relying on Windows Server Backup to Protect the Directory
- Active Directory 2008 : Proactive Directory Maintenance and Data Store Protection (part 2) - Relying on Built-in Directory Protection Measures
- Active Directory 2008 : Proactive Directory Maintenance and Data Store Protection (part 1) - Twelve Categories of AD DS Administration
- BizTalk 2009 : The BizTalk Management Database
- BizTalk 2009 : Handling Failed Messages and Errors
- Microsoft Dynamics GP 2010 : Dynamics GP Utilities (part 3) - Additional steps
- Microsoft Dynamics GP 2010 : Dynamics GP Utilities (part 2) - Loading sample company data & Creating a new Dynamics GP company
- Microsoft Dynamics GP 2010 : Dynamics GP Utilities (part 1) - Completing the Dynamics GP installation
- Microsoft Dynamics GP 2010 : Creating an ODBC data source
- Microsoft Dynamics AX 2009 : Working with Forms - Storing last form values
- Microsoft Dynamics AX 2009 : Creating modal forms & Changing common form appearance
- Exchange Server 2010 : Performing Tracking and Logging Activities in an Organization (part 2) - Using Protocol Logging & Using Connectivity Logging
- Exchange Server 2010 : Performing Tracking and Logging Activities in an Organization (part 1) - Using Message Tracking
- Exchange Server 2010 Maintenance, Monitoring, and Queuing : Understanding Troubleshooting Basics
Top 10
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Finding containers and lists in Visio (part 2) - Wireframes,Legends
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Finding containers and lists in Visio (part 1) - Swimlanes
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Formatting and sizing lists
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Adding shapes to lists
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Sizing containers
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 3) - The Other Properties of a Control
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 2) - The Data Properties of a Control
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 1) - The Format Properties of a Control
- Microsoft Access 2010 : Form Properties and Why Should You Use Them - Working with the Properties Window
- Microsoft Visio 2013 : Using the Organization Chart Wizard with new data
- First look: Apple Watch

- 3 Tips for Maintaining Your Cell Phone Battery (part 1)

- 3 Tips for Maintaining Your Cell Phone Battery (part 2)
programming4us programming4us