Prior to Exchange Server 2003 SP2, Microsoft Exchange wasn't certified to run in a virtualized environment. Only
with that version did Microsoft offer support for virtualized Exchange instances. And even then, it was only allowed under rigidly constrained circumstances, the most apparent being a hardware virtualization OS on Virtual Server 2005 R2 or later. Anyone using a non-Microsoft virtualization option such as VMware was out of luck.
Fast forward to 2013. Microsoft now supports third-party virtualization providers' products. And although Exchange can be virtualized in broad environments, support requirements have tightened, not loosened. This is because Microsoft now has about a decade of history with virtualization products and virtual containers and knows what works and what doesn't.
Some of those restrictions deal with Exchange when it's run in a given virtualized environment and when it's moved between virtualized environments. Here are a few things to keep in mind if you're planning to move Exchange servers among virtualization hosts.
Don't live-migrate an active Exchange server. Even with Exchange-aware virtualization products, don't live-migrate a running instance of Exchange to another virtual container. Here are a few reasons why.
- Data corruption in the Exchange mailboxes and Database Availability Groups can happen if you live-migrate a running instance while user sessions are open. The only way to guarantee that user sessions aren't open is to take Exchange offline before the migration.
- Users who don't expect downtime will be unhappy about having their Exchange connection interrupted without warning, possibly causing them to lose work.
Live migration is intended to take the hassle out of manually moving a virtualized machine to another virtual container. It isn't meant to take the place of setting up a window for downtime, especially since a freshly moved instance of Exchange should be tested before being put back into production.
In its notes about Exchange 2013 in virtualization, Microsoft says Exchange server virtual machines (VMs) can combine with host-based failover clustering and migration technology. This can happen as long as the VMs are configured so they won't save and restore state when they're moved or taken offline. These migrations are supported as long as the VMs never come up from the saved state on disk. It's best to make sure no state is saved to disk before the migration -- take the server down first.
Microsoft recommends using cluster-shared volumes instead of pass-through drives to minimize the downtime during a live migration. You can stick with using pass-through drives if you're setting up a maintenance window to take Exchange offline, especially if you chose the latter for the sake of performance.
Don't attempt to live-migrate an Active Directory domain controller either. Given the sheer number of other processes that depend on AD, you'll have more than a busted Exchange Server installation to contend with if things go wrong.
Rather than live-migrate a domain controller (DC), the best strategy is to build an entirely new server right in its target virtual container, add it to the existing domain as a member server, then promote the newly added server to DC status with DCPromo. Admins should actually get into the habit of using PowerShell instead, since DCPromo will be deprecated in future Windows Server versions, then migrate the Flexible Single Master Operations and decommission the old domain controller once everything is working. Stephane Thirion has a good tutorial about doing all of this with PowerShell, which can be found here.
This is a bit more roundabout, and safer, way in some cases since you don't have to mess with the original server in the process.
Make sure the virtualization hosts can handle live migration. Live migration moves a tremendous amount of data across the network, so much so that Microsoft recommends having a dedicated NIC of 1 GB [bandwidth] or higher for such operations. You should also enable jumbo frames for the network interface and its entire attendant switches, and change the receive buffer size to 8192 at each end.
Any one instance of Hyper-V cannot support more than one live migration action at a time, either to or from the server. Make sure your planned downtime for Exchange migrations takes this into account.
Virtualization has eased many aspects of IT, including the management of multiple machines via tools like live migration. But they're not meant to substitute the due diligence you need to take when managing systems, especially Exchange installations. Treat the whole process with the same care as you would with a physical migration -- it'll pay off.
About the author
Serdar Yegulalp has been writing about computers and information technology for more than 15 years. Check out his blog at GenjiPress.com.