We've had a number of customers ask us whether or not we support virtualized Exchange Server 2010 deployments. The answer is firmly, YES! We know there are many customers running on under-utilized hardware, and can reduce hardware and maintenance costs by consolidating applications onto a virtualized environment (like the Kentucky Community and Technical College System).

And, lastly, are all virtualized Exchange server configurations supported? Microsoft supports Exchange 2010 in production on hardware virtualization software for all Exchange Server roles except the Unified Messaging role. Moreover, we do support running Exchange high availability configurations within a virtualized environment, but do not support combining Exchange high availability with hypervisor-based clustering, high availability or migration solutions which automatically failover mailbox servers.

Detailed Exchange 2010 System Requirements are maintained on TechNet, and represent the most performant and reliable guidance we can offer our customers. We are continuously expanding our test/production coverage of virtualized Exchange 2010 to expand the supported configurations, and will share any new updates on this blog, as well as the system requirements page on TechNet.

While Microsoft embraces virtualizing Exchange servers because virtualization gives organizations additional choice and deployment flexibility to meet business requirements and lower IT costs, we're concerned by deployment guidance that doesn't accurately follow our Exchange best practices and deployment guidelines. For example, we feel VMware's misleading guidance represented in their recent "Exchange 2010 on VMware Availability and Recovery Options" document (and accompanying "Exchange 2010 on VMware Best Practices Guide") puts Exchange customers at risk, and brushes aside important system requirements and supported configurations. Their guidance could also greatly increase the overall cost of managing your Exchange infrastructure. While we do applaud VMware for leveraging core Exchange Server sizing and performance tools to provide guidance to their customers deploying Exchange Server, our specific concerns are as follows:

Deploying for High Availability

VMware specifically recommends combining their VMware HA solution with the Exchange application-aware high availability solution, which is an unsupported configuration. It is important to note that VMware's HA solution only protects from some hardware failures, while the Exchange high availability solution protects against both hardware and application failures (including a process for patching guest virtual machines). It is simply reckless for VMware to recommend customers deploy this configuration, while ignoring important Microsoft system requirements and unsupported scenarios. In addition, VMware also seems to gloss over the fact that combining these HA solutions will result in new storage requirements that increase cost and complexity. Considering that a significant focus of Exchange 2010 is reducing storage costs, promoting a strategy that increases storage costs isn't consistent with our customers' requirements.

There is nothing within the material that explains how combining Exchange database availability groups (DAGs) with VMware HA will provide a faster end-user mailbox recovery than using Exchange DAGs alone. Since Exchange HA protects against hardware and application failures, it is hard to imagine how VMware can provide a faster, and simpler solution than Exchange HA alone.

Microsoft does not support combining Exchange high availability (DAGs) with hypervisor-based clustering, high availability, or migration solutions that will move or automatically failover mailbox servers that are members of a DAG between clustered root servers. Microsoft recommends using Exchange DAGs to provide high availability, when deploying the Exchange Mailbox Server role. Because hypervisor HA solutions are not application aware, they cannot adapt to non-hardware failures. Combining these solutions adds complexity and cost, without adding additional high availability. On the other hand, an Exchange high availability solution does detect both hardware and application failures, and will automatically failover to another member server in the DAG, while reducing complexity.

We love that our customers are excited to deploy Exchange Server within virtualized environments. While VMware leveraged Exchange performance and sizing tools to provide guidance, their recommendations casually tiptoe around Microsoft system requirements, unnecessarily increasing storage and maintenance costs and putting customers at risk. Exchange Server 2010 provides choice and flexibility in deployment options. We are committed to virtualization technology deeply, and will continuously review as the various technologies evolve. We hope to do even more in the future with our roadmap. As we work to test and update guidance pertaining to Exchange running under virtualized environments, our current system requirements are in place to give customers the most reliable email infrastructure possible.

@bday
Actually, they never suggest using 'VMotion' or 'DRS' with DAGs (only with standalone mailbox servers which I believe is still supported by Microsoft).
You are correct they are 'suggesting' that HA may work. Like you said "Ignoring for a moment MS doesn't support hypervisor HA with DAGs": Conceptually, I can see where one could conclude that HA is really no different than something like an ASR technology on hardware. If some sort of hardware problem occurs that causes the machine to ASR, a 'physical' DAG node will simply restart and begin resyncing from another DAG node. I'm assuming there is nothing wrong with that scenario, so I'm not sure of any 'technical' reason Microsoft couldn't support 'basic' HA failover of a VM guest DAG node.
With that said, I totally can understand why it wouldn't be supported at this point as it certainly could increase complexity for many customers. Also, the guidelines for supporting this configuration would probably be very complex, not to mention potential licensing implications.

As VMWare of course are a competitor of Microsoft, I find it very telling that there's no mention in this post of you guys working /with/ VMWare to produce better documentation.

Now tell me, what would your customers want from you? Cranky blog posts, or work together? I know what I'd find more useful, and I certainly expect many customers out there deploying Exchange on vSphere will want assistance not 'should've bought Hyper-V'.

The approach I have taken with this before is to leave Exchange 2010 servers included in any VMWare HA clusters with DRS etc.. enabled (it has worked OK so far when VM's get shunted arround). I then figure that if I need to raise a call with MS for any issues I would first disable VMWare's HA features to ensure they are not part of the issue.

So I think your missing the point. MS & VMware are working together and it is well known that you can't DRS a windows cluster. It looks like whoever wrote the vmware papers didn't talk to the support guys.

In years gone by, MS and VMware would have and did fight each other when it came to supporting various configurations, but now with SVVP they are actually working together and Windows 2008 R2 is fully supported on ESX except then you cluster the OS.

At the end of the day when you design and install a solution, the important thing for a customer is vendor support and that is what SVVP provides. The Exchange team don't really care what virtual platform you use (of course they want you to use Hyper-v) they really just want you to use Exchange and not another product.

They also want your design to be properly configured and I think this is what prompted this blog post. <end of rant>

"Complexity" seems a pretty limp argument for forcing people to choose between live migration/vmotion and DAG.

Instead of trying to argue about which HA technique is better, cheaper, or shinier, wouldn't it be better not to make people choose between valuable technologies?

I'm also confused by how that VMHA/parent clustering increase storage cost. One copy costs less than two copies in this instance of our universe. You can argue that DAG is more robust in some respect, but you can't argue that it's cheaper.

Yeah, you can't VMotion a cluster node of any sort, including a DAG sync/CCR member. So exlude it from DRS. Old news.

You can subject them to VMWare HA, which simply auto-restarts the VM on a different host in case of host failure. You want this, of course, so that you don't have to manually bring up the node at 4am when it's passive in the first place. Also, there is no risk or hardware costs involved!

I've talked to enough people at VMware to know that HA and vMotion WORK with DAG. Not only that, they can't get DAG to fail when using HA and vMotion.

The question is: Why hasn't it been tested? Does the Exchange team just like having this FUD to throw at virtualization? Why not give the risk a fair assessment before asserting that the risk actually exists?

The Exchange Product Group is maniacal about storage - probably because it is one of the single biggest cost for the platform. Keep in mind, however, that they are not experts in storage technologies, have NEVER produced a commerically-viable storage platform (who is running Windows Storage Server?), and their solutions are not tested against real-world operating environments. It's facinating that they did a JBOD implementation with slow laptop-quality SATA drives for some poor unsuspecting customer. But what you won't read about are scalability, expandability, and operational complexity that the solutions involve. This current crop of "pundits" needs to fade back into the woodwork.

Putting DRS aside for a moment, can someone explain to me how vmware HA + any Exchange Server 2010 + DAG is any different from that same Exchange Server server going down because of a power outage and a human being restarting the server ? am I missing something ?

Even if mixing vmotion and DAG technically works, their point seems to be "Combining these solutions adds complexity and cost, without adding additional high availability."
The cost and complexity are the licenses required for vmotion and the work to configure it. This work may be trivial if you are already running a vmware environment that uses vmotion for other things but if you are learning it just for Exchange... why.

Frustratedwiththeseposts,
"Experts in storage technologies" and anything called a "storage platform" seem to be on their hit list.

Agreed Pennino. The VMware docs are discussing VMware HA, not DRS or vMotion. To be clear, HA is not the same as DRS and does not leverage vMotion. I can understand MS's concern around vMotion in a DAG environment but the concern around HA escapes me. Does this mean MS does not support rebooting a DAG member (which is essentially all HA is)?

Don't leverage DRS or vMotion with DAG (though as some have mentioned they do work), but I think you need to reread your own support statement regarding the VMware HA feature. If you don't support HA (which is a crappy name for the product, because it isn't really HA) then I find it hard to believe you support recovering a server from backup onto new hardware. There seems to be a fundamental missunderstanding of what VMware HA actually is.

"Even if mixing vmotion and DAG technically works, their point seems to be "Combining these solutions adds complexity and cost, without adding additional high availability."
The cost and complexity are the licenses required for vmotion and the work to configure it. This work may be trivial if you are already running a vmware environment that uses vmotion for other things but if you are learning it just for Exchange... why."

That's not for Microsoft to decide, IMHO, and it's symptomatic of an arrogance that seems rampant. The ONLY valid reason for Microsoft not to support something is if it doesn't work or is unreliable. To not support a feature implementation because of cost is like saying that they won't support Intel processors because AMD processors are cheaper and sufficient for the workload.

This is a thinly veiled attempt to remove value from a cloud model (server virtualization) that the Exchange team doesn't approve of.

There is obviously some confusion here about the differences between VMotion, DRS, and HA. Nowhere does VMware ever suggest to use VMotion or DRS with DAGs. Nor is Microsoft complaining about VMware suggesting this. This is only a conversation about HA and DAGs (which does NOT include or use VMotion).

Thx for the article. I have a drought abut VMware and exchange 2010 DAG deployment. One of my customers is going to deploy one Exchange 2010 DAG member on VMware. They are going to install One DAG member on physical server and other DAG member on VMware. IS this recommended? Any disadvantages?

HA in the dictionary or industry sense would make me think of a product like VMotion. Microsoft's support statements say they don't support hypervisor-based "high availability or migration" and personally I would interpret these in the dictionary sense.
In other words, and basically echoing what others have said, VMWare decided to rename their "VMWare HA" feature, would it be ok?
Hardware vendors have features that allow servers to automatically power back on after a blue screen or accidental button push., which is almost the same.
I do agree that its redundant with the DAG model and more complex, but then again I can think of situations where cluster failovers didn't quite work for some random reason and it would have been fine if the original server just came back alive.

So, you're saying that YES you support ALL virtualized Exchange 2010 environments except for environments using vMotion, HA, DRS, FT, and as long as the Unified Messaging role and the DAG's are not virtual. With all these exceptions you should simply state, while we know Exchange 2010 works just fine on Vmware, we will not support it because Vmware offers services that MS cannot provide.

Why is everybody so riled up? The solution is for VMware to stand up and support what is essentially a third-party solution. If they support you, problem solved. This is no different than anything else that plugs into windows/clustering/filesystems or unsupported APIs. It's not wrong for Microsoft to choose what they support and recommend. Maybe you should be pissed that they don't support it on Hyper-V HA, at least then you could say they were hypocritical.

There's no technical reason not to support VMHA and Hyper-V parent clustering with DAGs. There may be reason not to support vmotion and DAG, but even there, it's all rumors and innuendo.

So people are riled up because the Exchange team is using this support statement as leverage to prevent people from using Hyper-V and VMware features, and as a result, limit the number of people virtualizing Exchange.

I can only speculate as to why they would go to this length and alienate their customers, but my money's on the fact that Exchange uses a very different cloud model than VMWare and Hyper-V.

The VMware response pretty much sums it up - it's amazing that the Exchange team throws such FUD and completely false/contrary assertions (more storage, more complex blah blah) and try and hide behind a veil of fictitious 'customer requirements'. Pathetic is all I can say.

I think both vmware and Microsoft have valid points, but everything comes down to the SLA's, RPO's and RTO's.
If you have 100 people on an exchange, it can be down for 48 hours and you only are going to be recovering from last backup, then I think HA is a very good low cost solution for someone with a HA environment already built.

If, on the other hand, a company is running 1000 users and only rely's on HA and needs quick recovery from failure and data corruption, well then they would be idiots to only have a single server and think HA is going to help them when they bluescreen the O/S.

I thin Microsoft absolutely stating they do not support HA is a load of Crap. They better update their documents to ensure the ASR (as mentioned above) needs to be disabled on all Exchange 2010 servers since its 100% the same thing...Server goes down...Server starts up...simple as that.
Guess the solution is to just leave your server offline until you feel like pushing the button to start it up...but if you pay for twice the licensing, then you don't have to do that because you will have another node running.

I can understand not supporting DRS and vmotion if they want..thats fine...peg the VM to a single box...big deal.

Really it comes down to 2 things...Microsoft can only do HA with clustering so it has different limitation then vmware HA AND more importantly, if you don't pay for extra licensing to get those 2 exchange servers you hit microsoft in the pocketbook.

Mark Hodges -- but if you aren't paying for the licensing for 2 (or more) Exchange servers then it follows that you aren't making a DAG, and in that case Microsoft doesn't care what you do with HA. This statement is about mixing their clustering with virtualization HA.

I think you're overestimating the downtime associated with VMHA in most environments. VMHA requires shared storage. Every major shared storage platform I can think of offers snapshot functionality with very quick restore, and most of them offer VMWare and Exchange integration.

If you lose either the database or the OS, you can be up and running in far less than an hour using snapshot, clone, or CDP functionality. To be sure, recovery from corruption is not automatic, but it's definitely not a 2 day operation. In many cases, customers feel the possibility of a little extra downtime is better than having to procure, provision, maintain, and monitor 2-3 copies of the database and the requisite 2-3 servers.

Speculation: I think the phrase "new storage requirements that increase cost and complexity" points to the root of the line taken in this blog post: an aversion to SAN storage. I suspect whoever wrote it understands exactly what HA is and how it works.

Since Exchange 2007, the team's been agressive about driving down storage costs to increase user mailbox capacity - which is a good thing. However it seemed at the time that the Exchange team was trying to prove a point and some totally lost the plot saying "SAN is bad" or "we don't care if you already have one, replace it." Things have mellowed a bit since then.

I think that thread still runs through this response, it smacks of "we don't like what you're doing because it *requires* a SAN, therefore we won't allow or promote it."

The questions for any organization come down to:
-What is/are the goal(s) of virtualizing in your environment?
-If availablility is the primary goal of your virtualization, then compare the cost of procuring and supporting your virtualization software + your SAN vs 2-3 or more Windows/Exchange licenses and some servers with big local disks ... and the availability of each. (Look for single points of failure)

Who owns 90% of VMWare? A big storage company. VMWare also owns a product that strives to be an Exchange competitor in the groupware space. Not that this means anything other than we are talking about competitors here.

For over 15 years our team has focused on defining system requirements and support guidelines which ensure our customers have the best possible experience deploying and managing their Exchange environments. We strongly advise customers against deploying in unsupported configurations on the promise of support from a 3rd party. We do recognize, however, that many of our customers see virtualization as an increasingly important component of their Exchange deployment plans and will continue to work with our own Hyper-V team and VMWare to provide responsible guidance which is in the best interests of our mutual customers. Despite our disagreements, we are happy to see VMWare’s enthusiasm for doing what is best for our mutual customers and look forward to working with Alex, Scott, and others at VMWare who share this common commitment.

My guess is that Microsoft is fanatical and a little schizophrenic about storage is because they are a huge consumer of storage.

My organization utilizes Windows Storage Server, primarily for Storage, backups, and static data. We don't use it as an iSCSI data target for Exchange but have explored it with Dell and HP. We don't use it as a target for vSphere but use some mid tier SANs with appropriate drives and RDMs configured where possible.

My understanding from my Microsoft rep and the few times I have been invited into the Microsoft technology locations, a lab my organization used in North Carolina, and the Redmond Executive Briefing Center (hint - it's not limited to executives), I have seen dozens of different vendors including all the major SAN vedors. I used to work for a major hardware manufacturer and I believe we had about 300 people assigned to Microsoft including disk specialists to include SAN as well as server chasis based storage.

From what our Microsoft TAM says the Hotmail and BPOS solution track drive failures down to the serial number, lot number, and work with the drive manufacturers on a monthly basis. They won't provide us any numbers or manufacturer information no matter what our lawyers agree to sign to swear us to secrecy but apparently have worked with drive and chasis vendors to improve their products.

Exchange 2010 has allowed us to use cheaper storage; $150 for a 2TB SAS 7200RPM drive instead of $900 for a 15K 2TB SAS adds up after a few drive array enclosures. No, we haven't taken the SATA jump or DAS jump for Exchange with an all-in-one server but that may be next if we can prove it would be cost effective. We love the flexibility Hyper-V and VMWare provides and once Hyper-V R2 SP1 has memory overcommit we may cut our VMWare maintenance investment. The blocker for the AIO servers are the HLB requirement to load balance the AIO servers because of the CAS role.

Thus, I reiterate, Microsoft seems fanatical and a little schizophrenic because they appear to be a huge consumer of storage even though they have never manufactured a single disk. They also write the software which resides on these industry standard disks.

I find the argument of complexity is ironically inverted in the case of virutal hardware and it's guests in a way that I think MS is still figuring out, partilly becuase it's still new to the space.

They make the arguement that adding additional layers of failover to a solution adds complexity which can make individual pieces easier to fail ... this is an old, well proven concept .... on physical hosts when everythign is at one layer.

However in the virtual world that "extra layer of HA" happens in a world removed form the guest ... so often there is litterally zero introduced complexity. HA is the equivelant of ... say .. someone tripping a power cord and accidentally cutting off a server then turing it right back on.

In contrast, making special exceptions for a single VM that force you to reorganize your virtualization pool .... that indroduces _much_ moer complexity on the day to day. "nope can't vmotion that box, or put HA or DRS on it, guess it needs to sit on its own dedicated sub-pool .... so it should have bee n physical anyway ....".

Final irony is building around the support limitations introduce MUCH MUCH MUCH more complexity than including them as it's simply part of your virtualization layer.

Microsoft's entire internal mail solution as well as thier customer facing BPOS solution is running under the DAG/JBOD philosphy. Saying thier ideas are not real-world tested is simply FUD to the degree that I wonder if you're a storage reseller.

"Paul G
I'm also confused by how that VMHA/parent clustering increase storage cost. One copy costs less than two copies in this instance of our universe. You can argue that DAG is more robust in some respect, but you can't argue that it's cheaper."

The arugment that it's cheaper comes from the fact that you're not buying a SAN.

I have gotten quotes for customers and shown how they could buy four 1TB hard disks for less money than it takes them to buy two fiber controllers .... and that's assuming they already invested in the fabic, SAN switches, and the SAN itself. If not .... there's another 5 figures heading thier way.

The new JBOD scenario is much much MUCH cheaper than any SAN configuration unless your company already has the infrastructure lying around.

Remember: Just becuase you virtualize doens't mean you need a SAN. Though I will admit it does make things nicer.

So back to the cost arguement: MS is actually right here. A SAN solution will always be more expensive than a JBOD/copy model. HA will force a SAN into the mix .... therefore will drive up costs.

To be clear: I'm not saying i am against using HA/DRS with Exchange. Just clarifying thier stance.

"The ONLY valid reason for Microsoft not to support something is if it doesn't work or is unreliable. To not support a feature implementation because of cost is like saying that they won't support Intel processors because AMD processors are cheaper and sufficient for the workload."

So you're saying Microsoft has to support and test everything in the world (everything that uses their products), unless it doesn't work!? What about combinations of things that work independently and break each other? Do you realise that Microsoft and VMWare may BOTH refuse to support clusters on clusters? It's in the VMWare documentation, you know. Your comparison is invalid too but I think you know that anyway.

Also take a look at the best practices guide. 4,000 users, with 2GB quotas, on ~130 x 300GB 10K FC disks. That could be supportable on non-RAID SATA 1TB disks, >200 users per disk, that's 80 database disks. Say 240 drives maximum, if you had 3 copies. The SATA will likely still be cheaper to buy, plus you get lagged copies and the DAG (HA+) effectively for free.

So let's recognise that the VMWare document is just as biased as the Microsoft one.

Also ... does no-one else have any VMWare DRS/VMotion horror stories? I sure do (incl on sites designed, configured and supported by VMWare PS themselves). There's definitely a higher chance of stuff going bad when you add more layers. It doesn't matter where those layers are.

In all seriousness, did the writer even take the time to read the VMware document he is critiquing in this post?

Because I did, and I came across this not-so-hidden gem from the said document:

--------
Note VMware does not currently support VMware VMotion or VMware DRS for Microsoft Cluster nodes; however, a cold migration is possible after the guest OS is shut down properly.

With VMware High Availability (HA), Exchange virtual machines on a failed ESX host can be restarted on another ESX host. This feature provides a cost-effective failover alternative to expensive third-party clustering and replication solutions. If you use VMware HA, be aware that:
• VMware HA handles ESX host hardware failure and does not monitor the status of the Exchange services—these must be monitored separately.
-----------

with that caveat, why is the writer resorting to such histrionics. Is the writer claim that there configuring DAG in a clustered-Host environment is technically impossible? No. All the writer screams about is the fact that MS does not "Support" it. Well, why EXACTLY does MS not support it? Because your virtualization product is inferior and, therefore, lacks the intelligence to support such configurations? Or because MS just haven't gotten around to conducting the necessary test to "pass" or "fail" such configuration? In either case, is it not to the customer's benefits to make the options known to the customer and let the customer make an informed decision, after doing the due diligence and testing? Is it MS' objective to HIDE technical possibilities from its customers and threaten them with "sanctions" or scream "unsupported!" at them as if we are engaged in a game of "peek-a-boo!"?

Does the writer even know that, with VMware's virtualization technologies, it is possible to EXEMPT clustered guests from the effects of clustered hosts, even if such guests reside on the hosts so clustered.

The writer should have presented his/her argument against guest and host clustering combination by specifically telling his/her (ostensibly) matured audience WHAT it is that will break in a cluster-guests-and-hosts configuration instead of engaging in a hyperventilating episode of FUD.

The reason it's unsupported is much less nefarious than most people want to admit... mostly because we all love a good conspiracy theory.

It really comes down to this: Microsoft has made a very simple argument that "stacking" High Availability scenarios compounds complexity and will therefore be unsupported.

Now lets be clear on what that means: In Microsoft terms it means that if you call their Tech Support up _they_will_still_help_you_. It simply means they will use "best effort" and wont guarantee success or stay with the call for more than a specific length of time (I forget he exact terms of best effort, but it's defined out there somewhere).

At the same time Ill be first to agree that taking the hard stance when it comes to VMware HA is a little silly ... but let's also be clear on what kind of a market Microsoft plays with: the entire market. No one comes close to the market penetraion Microsoft has, and the can of worms that get opened when you "support these two HA solutions stacked even tough they are from two completely seperate vendors" is a can of worms I dont think anyone is giving nearly enough credit to.

Why doesn't VMware step up with their own Exchange team that will back the solution? Why is the responsibility squarely on MS's shoulders? This is VMware's solution and recommendation after all .... shouldn't THEY back it up?

I may disagree with MS taking the hard no stance here .... but I completely understand it. I said it was ironic that I felt this stance made things harder, no easier in the long run. I also find it ironic that no one has gotten upset at VMware for suggesting something completely unsupported (and documented as unsupported sense 2010's release a year ago) .. instead willing to take all said as gospel.

I understand that running HA on the actual VM's running Exchange 2010 is unsupported, however if these VM's are running on a VMWare HA Cluster but with HA/DRS disable on the individual VM's so that they tied to only single ESX Host, is this supported by MS?

So, if we follow the guidelines in this article on how to disable DRS for vm's and disable restarts for vm's can we still run the Exchange Cluster nodes on a HA cluster and expect support from Microsoft as the VM's themselves will be excluded from HA/DRS etc.

Until someone can convince me that MS's solution will catch all silent bit error on JBOD storage and not replicate any resulting corruption I will not be switching my companies most valuable data off of purpose built and widely tested SAN storage with background disk scrubbing. I think it's a giant leap of faith to buy into the Exchange teams koolaid that using SATA JBOD storage is the way to go just because they got the IOPS down low enough.

Overall I've enjoyed the conversation and can appreciate both sides of it here. I find it surprising that a failover solution isn't supported or even listed as an issue if it doesn't change anything except what physical system it is running on. I can grok that it might not be a "Good Idea" for this that or another reason though that doesn't stop anybody from doing things that help drive better savings, stability, uptime etc.

Personally I am a bit more biased to the VMware side right now as they are sharing information, not just marketing statements. At the end of the day I read this blog and others for the technical information added to the conversation.

Jim,

Can we get some reasoning why you won't support it? Is there a known bug? Is there an issue with migration? What is the reasoning behind this statement? Is it because you simply haven't tested it yet? What breaks or doesn't work?

"Microsoft does not support combining Exchange high availability (DAGs) with hyper-visor based clustering..."

Along with HA, DAG's are the recommended backup method for Exchange 2010 so the result of this policy is that deployments will not virtualize the mailbox role. It’s unfortunate that MS use their support agreements to slow down non-MS infrastructure deployments until their own product is ready but let’s wait and see what happens when Hyper-V can technically run DAG's on a clustered hyper-visor; likely we will see a change in support policy. Remember visualization support for Exchange 2007; none until MS released Hyper-V then they broadened their support policy to include 3rd party virtualization products; let’s hope so as Exchange 2010 on a clustered hyper-visor (any brand) looks to be a great solution for both HA capabilities and lowering operations requirementscosts