Some organizations are small, but they still require enterprise-class availability. For example, consider Contoso, Ltd., a fictitious company that regards e-mail as a critical service. Contoso has several small branch office sites consisting of 250 users. Contoso wants to keep their e-mail environment on premises for legal reasons, and they want to have a fully redundant e-mail system. Contoso’s users have average user messaging profiles with 2 GB mailboxes.

To achieve full redundancy for all Exchange server roles using physical hardware, Contoso would have to deploy seven servers: two servers for Active Directory and DNS, one server for file and print services, two servers running both the Client Access and Hub Transport server roles, and two servers running the Mailbox server role in a cluster continuous replication (CCR) environment. These servers are assumed to have two quad-core processors and the amount of RAM is based on the Microsoft recommendations for each installed role. Each CCR node has 4 GB of RAM, and each of the other servers has a minimum 2 GB of RAM to support the users and traffic patterns. With average user messaging profiles, the typical load should be 35%-45% of CPU on a server that has eight cores.

By using virtualization, Contoso can give the same level of redundancy and availability with only three servers. Each physical server would run multiple virtualized servers as guest machines. In this scenario, three physical servers with two quad-core processors and 16 GB of RAM would have sufficient capacity to serve Contoso’s users. Each of the virtual servers would be configured with two virtual CPUs. Along with RAM and processors, the servers also need to have multiple network adapters and redundant paths for storage. Because Contoso still has the same number of Exchange servers to manage, they haven't benefitted from an operations and maintenance perspective, but there are benefits from a space, power, and cooling perspective.

The following diagram illustrates the scenario.

In this scenario, when moving from seven physical servers to three physical servers and seven virtual servers, there is a potential savings of 25,754 kWh and $22,516 per year. The Microsoft Virtualization Tool was used to gather these numbers.

Sizing Exchange for a hardware virtualization environment is no different from sizing Exchange for physical servers. Whether you are using physical or virtualized servers, each CCR node needs 4 GB of RAM and storage capable of supporting 48 IOPS for the databases and 19 IOPS for the transaction logs. In this scenario, the IOPs requirements are very low and should be maintainable in a virtualized environment. Using fixed virtual hard drives would be sufficient for this solution, given the small amount of users that are hosted on virtualized Exchange servers. For higher user counts, Microsoft recommends that you use external storage.

Return to top

In the past, some organizations required local Exchange servers in remote or branch offices to provide sufficient performance for the users in those offices. With improvements such as Cached Exchange Mode and Outlook Anywhere, consolidating those servers to a central datacenter became the recommended approach.

In some situations, however, poor network connectivity to remote offices still requires some organizations to have a local Exchange server in those offices. Often the user populations at these locations are so small that it doesn’t make sense to dedicate a physical server to the Exchange environment. The technical considerations in this scenario are the same as described in the “Small Office with High Availability” scenario above. For an example of this scenario where a company used Exchange 2007 SP1 in a Hyper-V environment, download this Windows Server 2008 Customer Solutions Case Study about the Caspian Pipeline Consortium.

To provide site resilience and redundancy for a production site, some organizations may require a warm site that contains a duplicate of the primary production Exchange 2007 infrastructure. The intent of this warm site is to provide as near to the same level of functionality of the primary site as possible, in the event of the loss of the primary site. However, keeping a duplicate infrastructure for standby purposes, although useful for high service level agreement (SLA) requirements, can be prohibitively expensive for some organizations.

To reduce these costs, it's possible to provide a duplicate of the entire primary site using guest machines in a Hyper-V environment. A typical warm site configuration using physical Exchange 2007 servers would include one or more servers configured together as a standby cluster, and one or more other servers configured as the Client Access and Hub Transport server roles. To achieve redundancy of just the messaging services within the warm site, four physical servers would be needed. By contrast, a virtualized solution with only three physical servers can provide an organization with a warm site that includes two Mailbox servers in a CCR environment, as well as redundant Client Access and Hub Transport servers. Thus, by virtualizing Exchange in this scenario, you can provide a higher level of services to your users while saving on space requirements and hardware, power, and cooling costs when compared to a similarly configured solution deployed on physical servers.

The following diagram illustrates this configuration.

The Primary Site uses physical hardware due to the demanding size and messaging profile of the user population. In this scenario, the Warm Site is designed to support the entire user population from the Primary Site. Even though use of the Warm Site is for a temporary period and at reduced performance, careful consideration must still be given to the configuration of the environment that will support the user population.

The diagram illustrates that the Warm Site would contain a standby cluster, with one of its nodes configured as a standby continuous replication (SCR) target for the production CCR environment. A pair of domain controllers is also deployed. The SCR target is a two-node standby cluster. In the event of a site failure, the standby cluster would be activated by using Restore-StorageGroupCopy, and then the clustered mailbox server (CMS) would be recovered by using the Setup /recoverCMS switch. The same procedures for recovering from a disaster using a standby cluster still apply despite the fact that the standby cluster is a guest machine in a hardware virtualization environment. After the standby cluster is online and hosting the CMS from the failed site, client access to messaging services and data will be restored after DNS and Active Directory replication has occurred.

The virtual Warm Site must be able to provide an adequate level of service to users in the event of the loss of the Primary Site, with the understanding that there will probably be a reduced level of service due to the WAN/Internet link(s) to the Warm Site. However, because the site is designed to provide emergency functionality, and only for a brief period, this reduced level of service should be acceptable. It would be understood, however, that while the Primary Site is down, there is no site resilience for the Warm Site.

In this scenario, when moving from eight physical servers to three physical servers and eight virtual servers, there is a potential savings of 33,005 kWh and $28,225 per year. The Microsoft Virtualization Tool was used to gather these numbers.

Return to top

Sometimes a company, agency, or governmental department may need a complete network infrastructure that can be deployed to specific locations at a moment’s notice. This infrastructure is then connected to the organization’s network via satellite or other remote WAN technology. For example, a non-governmental organization (NGO) may need to respond to a disaster and set up local servers to serve an affected community. This subset of servers would need to be completely self-contained and able to provide all necessary services to the personnel located in the target location.

In such situations, the mobile LAN must be easy to transport. It must have a small and highly efficient form factor, providing all of the local users’ necessary services while taking up the smallest amount of space possible. Given the probable remoteness of the locations in which the Mobile LAN would be deployed, it must also provide fault-tolerant capabilities to ensure that there is no single point of failure in a location where spare parts may be hard to come by.

In this scenario, a Hyper-V server can be used to host Exchange services, file server services, and domain infrastructure services in a compact form factor.

The following diagram illustrates a possible configuration for a Hyper-V server hosting the Exchange 2007 and domain infrastructure systems. Due to the nature of this scenario, none of the Exchange server roles have been combined on the same guest machine.

The diagram illustrates a comprehensive network solution for an organization that requires all necessary server services to be provided locally regardless of location. The solution is as small as possible while also allowing for a high degree of fault tolerance and system availability.

In the rack, you would also need enough network infrastructure equipment to support the hypervisor root servers and the workstations. The hypervisor root systems would use either an iSCSI or Fiber Channel SAN. The SAN should give enough spindles to provide the necessary performance for the guest systems. In this scenario, everything needed would fit in a single 42U rack.

In this scenario, when moving from 14 physical servers to three physical servers and 14 virtual servers, there is a potential savings of 91,012 kWh and $73,891 per year. The Microsoft Virtualization Tool was used to gather these numbers.

Return to top

The following checklist outlines performance counters to monitor that may indicate whether your Exchange environment is underutilized. These counters need to be gathered from physical Exchange servers, not virtualized Exchange servers. Because the planning for the Exchange infrastructure is based on the Mailbox server role, the checklists below use mostly Mailbox server metrics.

We recommend that you collect each of these counters at regular intervals for a minimum of one week. After the data has been gathered, you can compare the results to the expected values. If the observed values are less than the expected values below, then your server hardware is being underutilized.

The counters in the checklist are from Monitoring without System Center Operations Manager. You will need to make sure that you monitor your servers after they're put into production.

Performance counter checklist

Category	Indicator	Expected value	Present
Common Performance Counters (All Exchange Servers)	Processor% Total	Should be less than 40 % average.	[ ]
	System\Processor Queue Length (all instances)	Should not be greater than 5 per processor.	[ ]
	Network Interface(*)\Bytes Total/sec	For a 1000-Mbps network adapter, should be below 30-35 Mbps.	[ ]
Mailbox Server-Specific Performance Counters	MSExchangeIS Client (*)\RPC Average Latency	Should be less than 30 ms on average.	[ ]
	Process(Microsoft.Exchange.Search.ExSearch)\% Processor time	Should be less than 1% of overall CPU typically and not sustained above 3%.	[ ]
	MSExchange Store Interface(_Total)\RPC Latency average (msec)	Should be less than 100 ms at all times.	[ ]
	MSExchange Store Interface(_Total)\RPC Requests outstanding	Should be 0 at all times.	[ ]
CCR, LCR, and SCR Mailbox Server -Specific Performance Counters	MSExchange Replication(*)\CopyQueueLength	Should be less than 10 at all times for CCR and SCR. Should be less than 1 at all times for local continuous replication (LCR).	[ ]

Return to top