Microsoft Exchange Server 2007: Tony Redmond's Guide to Successful Implementation

9.10 Virtual Exchange 925

Chapter 9

harder to make for larger and more complex servers where better manage-

ment and automation practices are required to deal with larger databases.

It is also the case that continuous replication is a relatively new technol-

ogy for both Exchange and administrators. We do not know how it will

react in the chaos and confusion that surrounds any database failure. Best

practice is still evolving in terms of how to manage continuous replication

effectively, whether on a single server or in an MNS cluster. We do not

know where the edge of the performance envelope lies for LCR—what

the real performance impact in terms of CPU and memory use on pro-

duction systems and at what point continuous replication runs out of

steam in terms of the number of mailboxes that it can support on a single

server. Until the technology is better proven, traditional shared copy clus-

ters may be a better bet for those who want the most resilient Exchange

configuration, and indeed, a strong case can be made for blade servers

that are grouped around a SAN, especially when coupled with good server

provisioning and data recovery procedures.

Whatever you may think of LCR and CCR, there is no doubt that

they mark an important and fundamental evolution for the Exchange

Store and that Microsoft will evolve this technology over time to improve

automation and manageability and to remove the inevitable kinks that

creep into a first release.

9.10 Virtual Exchange

Virtualization is a relatively new deployment option for Exchange. Hard-

ware virtualization lets you run multiple virtual operating systems and

application instances (the guests) concurrently on a single physical com-

puter (the host). When Exchange 2003 appeared, Microsoft would not sup-

port any installation of Exchange on a virtual server. You could certainly

install Exchange 2003 on a virtualization platform such as VMware ESX,

but Microsoft would not support any problems that you encountered, so

the only way that you could get support was to reproduce the problem on a

“normal” Exchange server. Flipping back and forth between standard and

virtual servers to solve problems was not a good approach for running a

production email service, so virtualization remained in the back room and

was used mainly for testing new versions of software and patches.

Microsoft’s stance was understandable because the test matrix that they

have to go through to test new versions of Exchange, service packs, and

patches becomes a lot more complex when you have to test on both stan-

dard and virtual servers. Microsoft never had the inclination to take on the