Problem solve Get help with specific problems with your technologies, process and projects.

What you need to know before virtualizing Exchange 2010

Before actually virtualizing Exchange Server 2010, there are a few things admins should know. Prepare yourself with this quick list of need-to-know info.

Many experienced Exchange Server admins balked at the idea of virtualizing Exchange before Microsoft released its support policy in 2008. They worried that performance in a virtualized environment would suffer due to the intense disk I/O demands of the mailbox server.

But with Exchange Server 2007 and Exchange 2010, Microsoft improved how Exchange operates, which made virtualization a more viable option in production environments. Despite this, it’s smart to follow some quick and simple best practices before virtualizing Exchange. Here are the top five:

1. Read and apply the Microsoft support policy.

The Microsoft support policy assists with virtualized deployments of Exchange Server. Not everything in the support policy will apply to your environment, though. For example, you may not be interested in Exchange Server 2003 or 2007. Still, you can glean some points for an Exchange 2010 deployment.

You can choose to ignore the support policy, but do so at your own risk. If you call with a problem regarding something that is unsupported, the Microsoft staff won’t hesitate to tell you to call back when you're doing things their way.

2. Choose a virtualization platform that you feel comfortable with -- and that Microsoft’s Server Virtualization Validation Program supports.

If you pit the major virtualization players up against each other, you’ll see only slight performance variations, so pick a solution that you’re comfortable with. The hypervisor wars are over; it all comes down to support, management tools and price when choosing a product.

3. Don’t cheat your virtual machines.

Admit it -- you’ve probably done it before. You’ve had a server on which you can set up multiple virtual machines (VM). Without realizing it, you skimped on the amount of physical resources being provided to the server. For example, you knew that your server needed 4 GB of RAM to function smoothly, but you assigned it 2 GB because that’s all you had left. That may work for other servers, but doing that in your Exchange environment can compromise performance.

In its support policy, Microsoft states that whatever you’d provide for a physical environment should be provided for a virtual environment. Always be sure that plenty of CPU/RAM is available, especially if you’re going to virtualize the mailbox server role.

There are several disk options available for a virtualized Exchange environment. I recommend using ISCSI pass-through storage. Although this may limit the portability of the virtual system, it provides the best performance for larger production environments that virtualize Exchange. For smaller Exchange environments with a limited number of mailboxes or user profiles, you can usually get away with fixed .VHD disks.

4. You don’t have to virtualize every role.

When it comes to Exchange virtualization, many administrators are against virtualizing the mailbox server role. If you’re just getting your feet wet with virtualization, consider virtualizing your hub transport and client access server roles in a production environment.

You may also want to provide redundancy with virtualized Exchange servers. For example, if your production environment has physical servers running your client access, hub transport and mailbox server roles, think about setting up virtualized systems to run a redundant, high-availability version of the hub transport and client access servers. This setup will provide some load balancing and failover in the event of a physical system failure. It may take a while to embrace production Exchange virtualization, so starting this way will help.

5. Learn the value of database availability groups.

Microsoft recently changed its stance on using vMotion or Live Migration as failover options with Exchange 2010. However, it still considers these methods redundant to database availability groups (DAGs), which create replicas of an Exchange 2010 database for automatic failover for either server or site crashes.

Though DAGs will take some time to learn, design and deploy, they are better at preventing data loss if an outage occurs because of the transport dumpster feature.

J. Peter Bruzzese (Triple-MCSE, MCT, MCITP) an Exchange MVP, is the co-founder of ClipTraining, an Exchange and SharePoint Instructor for Train Signal. He is also a well-known technical author for Que/Sams, SearchExchange and others, a product reviewer for, a technical speaker for Techmentor, Connections and, at times, TechEd. He is the Enterprise Windows columnist for InfoWorld. Follow him on Twitter @JPBruzzese.

Dig Deeper on Exchange Server setup and troubleshooting

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.