15 Tips to Optimize an Exchange 2010 Infrastructure (Part 3)

If you would like to read the other parts of this article series please go to:

11.  Virtualization Best Practices

Since virtualization is becoming popular in Exchange deployments, here are a few guidelines and recommendations:

Here are some more detailed and specific guidelines for the 2 most used virtualization technologies:

Windows Server 2008 R2 Hyper V

The following recommendations are taken from the whitepaper Best Practices for Virtualizing Exchange Server 2010 with Windows Server 2008 R2 Hyper V.

  • The physical root server should run Server Core.
  • Use fixed VHDs for the virtual operating system.
  • Storage used by Exchange should be hosted in dedicated disk spindles. This storage can be virtual storage of a fixed size (for example, fixed VHDs in a Hyper-V environment), SCSI pass-through storage, or Internet SCSI (iSCSI) storage.
  • The following virtual disk requirements apply for volumes used to store Exchange data:

    • Virtual disks that dynamically expand are not supported by Exchange.
    • Differencing VHDs and snapshots are not supported.
    • Configuring iSCSI storage to use an iSCSI initiator inside an Exchange guest virtual machine is supported.

  • Never deploy Mailbox servers that are members of the same Database Availability Groups (DAGs) on the same root.
  • Microsoft Exchange Server 2010 SP1 supports virtualization of the Unified Messaging role when it is installed on the 64-bit edition of Windows Server 2008 R2. Unified Messaging must be the only Exchange role in the virtual machine.
  • Exchange server virtual machines (including DAG nodes) can be combined with host-based failover clustering and migration technology as long as the virtual machines don’t save and restore state on disk when moved or taken offline. All failover activity must result in a cold start when the virtual machine is activated on the target node. All planned migration must either result in shut down and a cold start or an online migration that utilizes a technology such as Hyper-V live migration.
  • Microsoft Remote FX must be disabled for production Exchange servers.


The following recommendations are taken from the whitepaper Microsoft Exchange 2010 on VMware Best Practices Guide.

  • The total number of vCPUs assigned to all the Exchange virtual machines should be equal to or less than the total number of cores on the ESXi host machine.
  • Do not over-commit memory on ESXi hosts running Exchange workloads. For production systems, it is possible to enforce this policy by setting the memory reservation to the configured size of the virtual machine.
  • Do not disable the balloon driver (which is installed with VMware Tools).
  • Enable DRS to balance workloads in the ESXi cluster. DRS and reservations can guarantee critical workloads have the resources they require to operate optimally.
  • It is preferable to deploy virtual machine files on shared storage to take advantage of vMotion, VMware High Availability (HA), and VMware Distributed Resource Scheduler (DRS).
  • The standard VMware networking best practices apply to running Exchange on vSphere:

    • Allocate separate network adapters/networks for vMotion, VMware FT logging traffic, and ESXi console access management.
    • Allocate at least two network adapters for Exchange production traffic to leverage VMware NIC teaming capabilities. Generally, at least four network adapters are recommended per ESXi host.
    • Use the VMXNET3 network adapter – This is a paravirtualized device that works only if VMware Tools is installed on the guest operating system.
    • To support VLANs in vSphere, the virtual or physical network must tag the Ethernet frames with 802.1Q tags using virtual switch tagging (VST), virtual machine guest tagging (VGT), or external switch tagging (EST). VST mode is the most common configuration.

12.  Proactively Monitor the Exchange Environment

Proactively can also mean preventive, as a good monitoring system can detect issues ahead of becoming real problems.

There are many tools available to monitor Exchange Server, ranging from free tools and scripts, to more advanced solutions, like the one I’d recommend: System Center Operations Manager 2012 with the Exchange Server 2010 Management Pack.

The following table provides an overview of the monitoring functionality that is enabled through Operations Manager 2012 (taken from the Exchange Server 2010 Management Pack Guide):

Exchange component

Monitoring functionality

Exchange Client Access

  • ActiveSync and OWA connectivity monitoring including synthetic transactions

  • Performance measuring and alerting

Exchange Edge Transport

Performance measuring and alerting

Exchange Hub Transport

Performance measuring and alerting

Exchange Mailbox

  • Information Store monitoring

  • Mailflow and MAPI connectivity monitoring

  • Performance measuring and alerting

Exchange Unified Messaging

  • Unified Messaging connectivity monitoring including synthetic transactions

  • Performance measuring and alerting

Configuration and Security

Exchange best practices

Exchange Event Log monitoring

  • Comprehensive rules for Exchange

  • ]Detailed product knowledge about events

Table 1

13.  DAG Optimization             

Database Availability Groups (DAG) are the foundation of any Exchange Server 2010 high-availability strategy. Although configuring a DAG has become simpler than the previous Exchange clustered solutions, there are some guidelines you can follow to obtain the best performance and achieving greater reliability at the same time.

  • Use separate network adapters, Public and Private, for user access and dedicated replication, respectively.
  • Change the network adapter binding order, configuring “Public” interface with the highest priority.
  • Network Teaming: Microsoft does not support network teaming as this is hardware vendor supported and designed technology (unless using the newest Windows Server 2012 teaming). When using network teaming, only the client facing network should be teamed and configured for Network Fault Tolerance.  Do not use any type of load balancing between ports.
    For non-client facing networks it is not necessary to implement teaming, as Windows clustering has the ability to balance and use all interfaces on the cluster.
    Microsoft Customer Support Services may require you to disable teaming for troubleshooting efforts. For more information about teaming, see KB article 254101.
  • Disable TCP Chimney Offload and Receive Side Scaling on the network adapters
    netsh int tcp set global chimney=disabled
    netsh int tcp set global rss=disabled
  • Check the network performance/latency and set the correct values to Replay Lag Time and Truncation Lag Time attributes accordingly:
    Set-MailboxDatabaseCopy -Identity ‘MailboxDatabaseName\Exchange2010MainFQDNServerName’ -ReplayLagTime 0.0:5:0 -Verbose
    Set-MailboxDatabaseCopy -Identity ‘MailboxDatabaseName\Exchange2010DRFQDNServerName’ -TruncationLagTime 0.0:5:0
    Verify these settings in a controlled environment before moving to production. Using incorrect values may lead to high downtime. Usually, if the DAG members reside in the same AD site and VLAN, there’s no need to change the settings above.
  • Use a CAS Array to provide a High Availability solution to the CAS role.
  • Lower the TTL value of the CAS Array DNS record and also of the DAG DNS record
  • Configure the Autodiscover Service to Use Site Affinity

If you virtualize DAG members, please follow these key points when performing live migration of DAG nodes:

  • Exchange 2010 SP1, or later, is required.
  • To minimize offline time, use cluster shared volumes instead of pass-through drives where possible. In testing, performed by Exchange Server and Hyper-V engineering teams, offline time associated with moving storage resources was cut in half by using cluster shared volumes.
  • If the server offline time exceeds five seconds, the DAG node will be evicted from the cluster. It is preferable to ensure that hypervisor and host-based clustering technology is able to migrate resources in less than five seconds. If this is not feasible, the cluster heartbeat timeout can be raised, although we don’t recommend raising it to more than 10 seconds.
  • If raising the heartbeat timeout threshold, testing should be performed to ensure that migration succeeds within the configured timeout.
  • Ensure that the latest patches for the hypervisor are deployed to ensure optimal performance:

    • KB 2517329. Performance decreases in Windows Server 2008 R2 when the Hyper-V role is installed on a computer that uses Intel Westmere or Sandy Bridge processors
    • KB 2000977. Hyper-V: Performance decrease in VMs on Intel Xeon 5500 (Nehalem) systems

  • On the live migration network, enable jumbo frames on the network interface for each host and ensure that the switch handling the network traffic was configured to support jumbo frames.
  • On the live migration network, change receive buffers to 8192 on each host.
  • Deploy as much bandwidth as possible for the live migration network.

14.  Try Office 365       

These are the days of the cloud, and e-mail is just one of those workloads that really fit the Software as a Service (SaaS) model. If you want to stop reading optimization articles like this one, why not give it a try to Microsoft Exchange Online in Office 365?

Built to deliver the enterprise-grade security and reliability that businesses require, Microsoft Exchange Online provides the following features:

  • Built-in anti-virus and antispam filters
  • Mobile sync to most of the devices available
  • 99.9% uptime commitment with financially-backed SLA
  • Live phone support 24 hours a day, 7 days a week, 365 days a year
  • Large, 25 GB mailboxes for every user
  • Seamless integration with Outlook
  • Calendar sharing and federation with other companies
  • Email archiving, eDiscovery Search, retention policies, and optional legal hold
  • Security policies let you create approved mobile device lists, enforce PIN lock, and remotely wipe data from lost phones
  • Free tools for migrating IMAP and Exchange Server mailbox data to Exchange Online

15.  Prepare for Exchange 2013

By the time of writing this article, Exchange Server 2013 is in Customer Preview and it’s expected to RTM by the end of 2012. So now is probably the time to start preparing your infrastructure for it, since there are many exciting new features on the way and the architecture has changed dramatically.

  • Start by reading Exchange 2013 System Requirements
  • Coexistence with Exchange 2003 will not be supported, so now is the time to finally remove those obsolete servers.
  • Active Directory must be at Windows Server 2003 forest functionality mode or higher (if you’re using Exchange Server 2010, this is not a problem)
  • Exchange 2013 Preview supports the following minimum versions of Microsoft Office Outlook and Microsoft Entourage for Mac:

    • Outlook 2013 Preview
    • Outlook 2010 SP1 with April 2012 Cumulative Update
    • Outlook 2007 SP3 with July 2012 Cumulative Update
    • Entourage 2008 for Mac, Web Services Edition
    • Outlook for Mac 2011


Optimizing an Exchange Server 2010 infrastructure is all about making it healthier, more stable and more reliable systems.

I always like to make a disclaimer that some of the present recommendations may change in the future, as new service packs, service releases or new versions of the products are made available. The engineering teams can also make some changes on their recommendations, based on experience or due to hardware advances. In either case, the best to do is to keep up with the plethora of technical information and news widely available on the Internet (remember tip #1).

Related Links

If you would like to read the other parts of this article series please go to:

About The Author

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top