[Video] Exchange 2010 Architecture Design with Virtualization- Can I virtualize it all?

In this video post, Justin and I talk a little about Microsoft Exchange 2010 and Virtualization and how architects need to make sure that assumptions they make are not going to catch them out in the end...

[UPDATE: As with all things in the technology world, things have moved on. Exchange 2010 virtualization opportunities have changed dramatically since the posting of this video.]


Please comment- this is my first Video Blog and I welcome your feedback!

Transcript Justin Pirie (JP): So welcome to the Mimecast Blog, I'm here today with Barry Gill one of my fellow bloggers.

And I'm here really to pose the question to Barry as an infrastructure guy, about virtualization, because a lot of the time I hear "well we'll just virtualize it" as a solution to peoples problems when they're thinking about sprawling infrastructure.

So, in particular with relation to Exchange, because that's what we really care about on-premise (at Mimecast). How do you get over those issues when people are talking to you about their sprawling infrastructure?

Barry Gill (BG): Possibly one of the most critical things for anybody to think about these days is to really assess whether or not the software they're looking at, so in this instance Exchange server 2010, whether or not it actually supports virtualization.

You can't just go out there and say every server will go onto our virtual infrastructure. These days it just doesn't quite work like that. You know, Exchange Server 2010 has some severe limitations, some would call them limitations, in the way it handles virtualization. For example it utilises the built in Windows clustering technology and as such cannot be put on top of additional virtual environments.

So you may not deploy a Database Availability Group as an example, onto virtualized hardware. And if you- there is an un-recommended way of doing it- or non recommended way of doing it which says you can deploy but you may not use any of the features or benefits of your virtualization technology, for example high availability, failover, state replication, you just can't use any of these things, so because ultimately Microsoft have built that type of high availability and resilience into the Database Availability Groups themselves and you can't have a duplicated layer of this because it creates complexity in managing the software.

And from what I see this is the type of thing that will often unhinge someone when planning a design, because it's not necessarily surfaced very well in all of the documentation, so it becomes a kind of a gotcha at the end of a design process when you're preparing to deploy.

JP: So you still need physical kit for, Exchange (2010) Database Availability Groups

BG: Yes, absolutely. If you're going to deploy a DAG you need at least three servers, so you know, can't- the recommended minimum by Microsoft is three servers to run a Database Availability Group, any less than that and it's kind of pointless, you might as well stick with traditional backup technologies.