Exchange 2010 Roadmap Series: Virtualization

Transcription

1 Exchange 2010 Roadmap Series: Virtualization Produced by SearchExchange.com Presenter: Lee Benjamin, Messaging Architect, ExchangeGuy Consulting Sponsored by Copyright 2010 Dell and Intel. All Rights Reserved. Reproduction, adaptation, or translation without prior written permission is prohibited, except as allowed under the copyright laws. Design Copyright 2010 TechTarget. All Rights Reserved. Dell and Intel_01_2010_0002P

2 Exchange 2010 Roadmap Series: Virtualization This document is based on a Dell/Intel/TechTarget webcast entitled, Exchange 2010 Roadmap Series: Virtualization. Lee Benjamin: We re working today on our Exchange 2010 Roadmap Series. This is the Virtualization session in our series. My name is Lee Benjamin. I work with ExchangeGuy Consulting. I ve been working with Exchange, since before it had a name and before it even knew which operating systems it was going to run upon, so lots of history there. OK, so this is the fourth session in our Roadmap Series. There are already webcasts recorded and available on SearchExchange.com for Transition and Migration, Backup and Availability, Performance and Sizing, and Virtualization. For each of the webcasts, we basically follow the same agenda, so a roadmap of the issues to Exchange We ll go back and look at architecture, some of the basics. If you ve been watching the whole series, I apologize. I ll try to do it quickly, but just for someone who is coming in and not on the same playing field. We ll talk about new Exchange features for the virtualization world. We ll talk about virtualization scenarios that place it on how you might use it with Exchange. Our Roadmap to Exchange 2010 for Virtualization, so first and foremost, a rise of the hypervisors, not quite the same as the rise of the Transformer movies that kids are watching today but similar. So, obviously the two big players out there are Microsoft, with its Hyper- V, and also VMware. Technically, I m going to be talking about Hyper-V specifically but both work fine. The important thing for you is really about what is supported by Microsoft, on what operating system platforms, what applications. Is there anything special you need to do to install. And, we ll talk a little more about it but vendors who have past the certification for Microsoft virtualization platform. VMware and others are also supported for Exchange Exchange 2010 Roadmap Series: Virtualization 1

3 Roadmap to Exchange 2010 Rise Of The Hypervisors Consolidation & Resilience Microsoft Hyper V Supported VMware, Other Within Datacenter, Branch Office Green Computing Redundancy For CAS, HUB, and EDGE Virtual DR External DR Site Infrastructure, AD, DNS, Exchange When Not To Virtualize Same CPU And Memory Requirements As Physical UM Not Supported As Virtual, Same For Most Of OCS Primary Mailbox Servers Consolidation and resilience, there are a number of different scenarios where you might want to think about using virtualization and others not to use virtualization, but a lot of things around the data is about consolidation, that is bringing things to more focused locations, bringing things to the centralized data center. You might be pulling from various offices and really into the data center environment. Green computing, less computing power requirements, computer servers that can spin down part of their functionality, maybe letting go of some of their cores when they re not needed so that the computer doesn t get as hot, doesn t need to do as much cooling. If you really want to get kind of neat about this, live migration, that is pulling virtual images that might be running on let s say three different servers during the day but at night pulling those images on the fly, live migration in the Hyper-V terminology, moving those virtual images live at night, all onto one server and power down the other two servers because the load is so much less at night. So, green computing is a driver here as well, and power requirements and so on. And, also redundancy requirements, resilience and redundancy, that is so that your.the function of the the roles within Exchange are duplicated so that I ve got multiple CAS, client access servers, multiple HUBs, multiple Edge Servers and unified messaging as well, though UM doesn t play as much of a role in the virtual world, and we ll talk about that. Exchange 2010 Roadmap Series: Virtualization 2

4 Exchange Server Roles Exchange 2003/2000 Exchange 2010/ Front End Server SMTP, POP3/IMAP4 HTTPS Outlook Web Access Exchange ActiveSync Hygiene (AV/AS) Optional 1. CAS Client Access Server 2. HUB Hub Transport Role Client Connection Point, Required Including Outlook/MAPI In 2010 More Load, = More CPU + Memory All Message Routing, Required Shadow/Resiliency In MBX Mailbox Role 64 Bit ESE Database Scalability And Performance 2. Back End Server Mailbox Databases Routing MAPI/Outlook Includes Front End 4. UM Unified Messaging 5. EDGE Edge Transport Role Voic , Voice Access, Voic Preview Routing and Hygiene Lives Alone, Optional Virtual DR is a real thrust. A real trend for what I expect is going on in the next year will continue to be this push towards availability and recovery, in that I could have hardware and software in a disaster recovery site, but less hardware than I might have in the past. And, if I need a DR site I already know that it s going to be crowded, I already know that it might be a little bit slow, but it s OK. So, if I build in not just replicated copies of Exchange using the technology that s in there but less of replicating and virtualizing Exchange itself, the different Exchange flows, and by way of that I mean also think about the infrastructure roles to do that as well. How would I cut over? What else do I need over there for other people, infrastructure, Active Directory, DNS, to make all of that happen? Because I m much more cost available for an organization to put a larger server. I can do disaster recovery, so a big trend to do that. There are some reasons not to virtualize, and we ll go through and we ll look at those as well. You need to understand Exchange is a heavy resource user, always has been. It does a lot for us. It s a very large database. It s handling from hundreds to thousands of users on server environments, and we need to understand that the same CPU and memory requirements are needed in the virtual world. It s not a savings, if you will. Yes, there may be a savings by pulling it all together and having less servers, but those servers are going to be way beefier because of the number of processor cores within those processors, the amount of memory requirement. So, those don t go away. So, we ll need to look at those deeper as we move along. Unified messaging is not supported in the virtual environment. That s the bottom line, the unified messaging role, because of the real-time codecs of the real-time translation of voice to digital, is not suited to the virtualization world. The same is true of local OCS. So, the core components of OCS are not intended and they re not supported in the virtual world, though some of the pieces are. How about mailbox servers? It s possible. We ll talk about it a little more. It s possible to virtualize your mailbox servers. I m always hesitant to do that. I would rather see that my dedicated hardware that I know can support those users is running Exchange 2010 Roadmap Series: Virtualization 3

5 the mailbox server. That s one thing we ll talk about a little bit more, and see if that matches your environment. Exchange 2010 Architecture Phone system (PBX or VOIP) Edge Transport Routing & AV/AS Hub Transport Routing & Policy External SMTP servers Mobile phone Mailbox Storage of mailbox items Unified Messaging Voice mail & voice access Web browser Outlook Anywhere (remote user) Outlook (local user) Client Access Client connectivity Web services Line of business application Let s go back and talk a little bit about architecture, just to get everybody on the same page. In Exchange 2003 and 2000, we had two roles within our Exchange environments: a backend server that handled the mailboxes and the routing, and MAPI and Outlook connected there as well, and the finance server components that could be split apart or included in the back end as well, but really those were our Internet standard protocols, where POP, SMPT, IMAP, and HTTPS would connect. Now, on your HTTPS, we have Outlook Web Access, we have Exchange ActiveSync, as well as some other pieces. You could put antivirus and antispam there. Exchange 2007 and 2010 introduced five new roles for Exchange, the first four that could run together in a small environment. You might run a bunch of these on a single server. In a larger environment, you would split these apart onto larger servers. The client access server is the piece that handles the incoming client connections, that we ll talk deeper about, but the real big shift in the CAS is a change to where MAPI connects, and we ll go deeper into that, but that s a big change to our architecture. Also, you ve got the other client connection points, so MAPI, POP, and IMAP come into that environment. By putting MAPI and Outlook there, more load, more CPU, and more memory. The HUB is very much like it was in The HUB handles all message routing. It s a required component, as is the CAS. Some new pieces in the HUB role give us some shadow transport capabilities that give us resiliency so that we can now duplicate net gates that we have multiple HUBs and multiple CAS. But, in the area of HUBs, the architecture is such that messages are kept track of and if a message does not go through, if it doesn t get a confirmation back that the message made it to its next HUB, it is routed through another transport, and that would happen in the background, so that level of resiliency is built-in, no matter what. So, we ve got some redundancy built into the HUB. Exchange 2010 Roadmap Series: Virtualization 4

6 The mailbox role, we ll talk more about, the 64-bit database, and the scalability and the performance. Obviously, for each mailbox you also need to have a CAS and a HUB. That s the minimum Exchange configuration. Unified messaging, I mentioned a few minutes ago, handles the voic , voice access, and voic preview. Voic preview is a much larger resource of CPU because it s looking at and converting, transcribing voic messages from audio to text, including those messages. The unified messaging, again, is not supported for virtualization. We also have an H-transport role. This is a separate component. It lives on a server by itself. It is an Exchange server but it s highly specialized, the hardened SMTP role for routing and hygiene coming from the Internet. It is something that we can virtualize. You may be using this, you may not be. It s an optional component. Some of you have got other messaging hygiene servers that handle this functionality. Moreover, Exchange 2010 architecture, so starting from the upper left-hand corner, we ll work our way around. External SMTP servers come in and talk either through our Edge transport, again routing, antivirus, antispam, or coming in through messaging hygiene servers, or an appliance that you re using. They come in and they talk to the incoming SMTP messages, come in and talk to the HUB transport, which again routes everything internally. You may have multiple HUB transport servers that route, transport and then pass those messages into the mailbox server. If you re using unified messaging, over on the right-hand side of the screen, the unified messaging role, perhaps with a gateway in between, talks to your phone system, PBX. The gateway voice-over-ip talks natively. And, below, we have the client access service, the client access role. Now, client access role handles not just our incoming users but also external users, mobile phones, Web browsers, and Outlook Anywhere, formerly called RPC over HTTPS. So, the client access is the point where all of the client connectivity happens. Web Services, Exchange Web Services, is also an API set of provider interfaces that your line of business applications can talk directly to as well. Continuity Curve Seconds Hours /Days Time To Recover Disaster Recovery Operational Continuity Backup and Restore Investment High Availability Exchange 2010 Roadmap Series: Virtualization 5

7 Now, continuity curve, for a moment. I talked more about this in our Backup and Availability session, but as we think about costs, in order to present high availability or higher availability, there s always a tradeoff here between the dollars you re willing to invest and how quickly you would like to recover, or failover, or crossover, depending on where the recovery servers are, and then we sort of have our continuity from backup, and operational, and disaster recovery, and high availability. It s useful thinking, and it s always in the discussion, when somebody says, I want high availability. How much high availability do you want, do you need? Are you willing to pay for it? Now, the ability that we re talking about here, the ability to virtualize a disaster recovery environment helps bring the cost down. So, high availability, or as I always try to say higher availability, becomes much more costeffective or accessible for organizations. So, this is a much broader topic but useful to look at. Virtualization Support Windows Server 2008 And R2 With Hyper V Microsoft Hyper V Server And R2 Any Third Party Hypervisor Validated Under The Windows Server Virtualization Validation Program VMware, Other Any Exchange 2010 Role Except Unified Messaging (UM) Fixed Size Virtual Storage Disks, or SCSI Pass Through Physical Disks, or iscsi SAN Disks No Differencing Disks, No Hypervisor Snapshots Only Virtualization And Management SW On Host Alright, so let s look at some of the things that have changed. Virtualization is supported. You can put Exchange 2010 on top of your virtual server, which is Windows Server 2008 and Windows Server 2008 R2 with Hyper-V. There is also a Microsoft Hyper-V Server and an R2 of that Hyper-V Server. Third-party hypervisors are validated under the Windows Server Virtualization Validation Program. What does that mean? Well, companies like VMware and others that have tested and shown that their applications work and work correctly, and are architected such to use virtualization and to protect your application, your application unit, can be certified to work on top of Windows servers, or using their own functionality to provide those. The other fine wording here that one needs to look at is if ever you get into such a support issue that really proves difficult to figure out where it is, what s going on, if necessary you may need to try to move that to physical hardware and prove that it s happening there. This is a rare kind of instance. I was dealing with a customer literally two weeks ago. The organization was using a hypervisor technology, a virtualization technology, that it had been purchased. That Exchange 2010 Roadmap Series: Virtualization 6

8 company had been purchased by another company and thrown out to pasture. Hypervisor virtualization software was going to go away and so there was no longer any support for that virtualization and my particular customer, who we we re dealing with, still out of luck. Microsoft will not support you on an environment that is not validated through the program that I just talked about and that has reached its end of life, so that s very important for you. If you are working with a virtualization technology, make sure that it is supported. If you search for the Windows Server Virtualization Validation Program, you will find those companies that are supported. OK, on the Exchange side, any Exchange 2010 will accept unified messaging, and again this is because of the needs for real-time voice, the translation, the codecs do not handle the virtual environment well at all, and that is an unsupported role on virtualization. If you re going to do virtualization, you have an option to do virtual storage disks, or VHDs in the Microsoft terminology. If you re going to do VHDs, virtual storage, make sure that they are a fixed size, it s supported. Or, better yet, SCSI or iscsi pass through to physical disks, that is I may virtualize the server itself but point those out to physical disks. You ll get better throughput and better use of your resources. That is how you would do iscsi SAN disks as well. You can use technologies such as differencing disks. You cannot use hypervisor builtin snapshots. Those are unsupported. And, on the virtualization machine, only virtualization and management software are on the host machine. If you re going to do virtualization that machine should be dedicated to virtualization on that host machine, and then what you re putting on top is virtual computers, the guest operating systems with Exchange on top of those guest operating systems. Virtual Concerns 9 12% Overhead For Hypervisor Plan For 10% Less Users Same CPU and Memory Requirements As Physical Savings May Not Be There Scale Out Rather Than Scale Up Conscious Decision From Exchange Team Spread The Load And Risk More Servers And Replicated Copies (DAGs) Some of the virtual concerns, if you will, some of the things to really think about: typically 9% to 12% overhead for hypervisors. You need resources on that machine, on the host machine that are overhead, and that s probably one or two processor cores and just for overhead, for the operating system itself, as well as a gigabyte of memory. So, plan for and recognize it can have a level of overhead. Also, plan for that 10% less users than you might have planned for, have calculated on that system, again because of the overhead for the Exchange 2010 Roadmap Series: Virtualization 7

9 operating system and the hypervisor itself. Don t forget, same CPU and memory requirements as physical, and I ve already said it once and now I ve said it twice. The real thing is that the savings may not be there for you when you start looking at the full role of an Exchange mailbox server, the number of cores, the processor, the net amount of memory that it needs. It may not make sense to virtualize that piece, and I ve already told you that s where I am with a mailbox server anyway. If you re putting multiple CAS and multiple HUBs on that machine, you ve got to add up all of those physical requirements, all of the memory and all of the cores, the CPU requirements, and those are additive, and you re not going to see the savings just because you re putting them on the same machine. So, again, Exchange is a healthy consumer of resources. Scale out rather than scale up. The Exchange team, in designing Exchange 2010, looked at it and said, We re not going to go for absolutely massive, approaching mainframe kind of size, environments. We re going to spread that load out. We re going to spread the risk of losing a server into multiple servers. More servers, more replicated copies. Putting all of your eggs in one basket is never a good idea. I d like to split some of that apart. Database Availability Groups CCR and SCR Evolve No Clustering Knowledge Required Up To 16 Replicas Recommend 3 4 Node DAGs, Or Larger Allows Lower Cost SAS and SATA Disks in DAS So, with that said, we move on to data availability groups. This is really about the evolution of two features that were added in Exchange 2007: CCR, cluster continuous replication, and SCR, standby continuous replication. The idea is that we ve got multiple servers. We place those servers in what s called the DAG, the database availability group, and the DAG is responsible for handling all of the replication between the databases that you have chosen to replicate within that DAG environment. You don t need to worry about how exactly the replication occurs. You don t need to worry about whether you need it before CCR was cluster-based. You don t need any clustering knowledge. In Exchange 2010, the DAG manages a tiny bit of cluster resources, more for heartbeat, and so on. It manages all of that in the background. You manage Exchange, including the DAG, inside the Exchange Management Console and the Exchange Management Shell. We ve got so many versions of Exchange sometimes I pick the wrong wording. So, inside of the Exchange Management Console and Exchange Management Shell you actually manage the database availability Exchange 2010 Roadmap Series: Virtualization 8

10 group. Anything that needs to occur with clustering, even when you set up a DAG and when you add a server to a database availability group, it goes out and it configures, and it pulls in the little bit of clustering that it needs, but you don t manage it through the normal clustering administrator. You don t even see it as clustering, and that s a big change because people needed a Ph.D. in clustering. The other issue around clustering that was fairly significant was that you needed that expertise within your organization, and not just one person because you need to deal with the proverbial what if that person gets hit by a bus scenario, and getting that clustering expertise was sometimes more expensive in order to find that and acquire that technology. Database availability groups give us up to 16 replicas. I see most people doing three or fournode DAGs, that really give us a good level of availability and disaster recovery capability. Larger are possible, again splitting that load and setting up those databases, adding the databases and where do I want a primary, where do I want a replica of that data, also the ability to have what are called lag copies. Other major change is database availability groups can use lower cost SAS and SATA disks that are connected with direct attached storage. Because of the performance improvements that we talked about in the third webcast in this series, I don t need as fast disks in order to support Exchange. The I/O improvements in the database are rather phenomenal at 70% over Exchange 2007, and Exchange 2007 over 2003 was another 70%, so rather phenomenal improvement there. That s background stuff we re going to need. Single Exchange 2010 Server Exchange Server Running CAS, HUB, and MBX Roles Deploy This Critical Server On Physical Hardware Resource Intensive On Its Own Direct Attached Storage, Redundancy Through Raid Lower Cost SAS And SATA Drives Acceptable Though Use Storage Calculator Consider Virtualization For Low Availability 2 nd Copy of Mailbox Role In DAG Not Actively Supporting Users Virtualize CAS and HUB For Redundancy Regardless Of Mailbox Role In DAG Size Accordingly Let s talk about some virtualization scenarios. A single Exchange 2010 server can run for a smaller organization, say 500 users. With a single server running the CAS, and the HUB and the mailbox roles, this critical server is the life of your organization. We know how critical Exchange is. This is a resource-intensive application on its own. My recommendation is to put this on physical hardware for the mailbox server at least. Direct attached storage, redundancy through RAID, again RAID is important for us. This server might not be even in a DAG. A DAG does raise some other requirements. I need Windows Server Enterprise underneath, and that s more costly because I need a little bit of that clustering technology that Exchange 2010 Roadmap Series: Virtualization 9

11 Exchange will pull in. Again, you could use lower cost arrays. In the last webcast I talked a lot about storage calculator and that s the way you need to configure and understand what drives you would be using, if any. For simplification, there are a couple of places you might use it. You could put a second copy of a mailbox role in the database availability group and maybe then support users there as a local but a setup for disaster recovery. To really get the benefits out of database availability groups, you need three or four nodes to do that. Virtualizing CAS and HUBs for redundancy, that makes a lot of sense. So, I d like to have a secondary path for users coming in with Web access, or Exchange ActiveSync, or Outlook Anywhere. I d like to always have that be up, if I can. I could do virtualization of the HUB roles as well. We also need to start being smart about where do I put those. So, ideally, you would put those on two separate host machines that are running virtualization, so that you separate those out if there are particular hardware problems. Larger environment, a threenode database availability group. I think we re going to see a lot of three- and four-node DAGs. Exchange Node DAG 3 Exchange Servers Running MBX Role Two In Data Center, One At Secondary DR Location Could Also Be Running CAS And Hub Roles* DAG Created and 3 Mailbox Servers Added to DAG Mailboxes Split Between 2 Mailbox Servers DR Copy Is Candidate For Virtualization Set Lagged Copies on 3 rd DAG Node In DR Site Replicated DAG Will Failover or Crossover As Needed 3 Copies Allows Both Intra and Cross Site Protection Virtualize CAS and HUB For Redundancy Size Accordingly So, a typical scenario might be three servers running mailboxes, two of those in the data center, and one of those out at a secondary DR location. So, I ve got a DAG. I ve added those three servers, but I m going to split the load in the headquarters building between the two hardware mailbox servers. Over in my disaster recovery site, whether that s threequarters of a mile down the road or whether that s in another city, county, state, whatever, if I ve got decent bandwidth then I always have another copy there. Now, one of the neat things you can do with a DR copy is set what are called lagged copies. Lagged copies are upto-date copies of the transaction logs, which is how replication or the database availability groups work, but instead of deploying those replicated copies right away, we re going to hold those replicated transaction logs for a period of time. You may measure that time in hours or even days, just so that if you do have a physical corruption problem that happens on your primary or your primary and secondary nodes because of something that hit the database, you can go over to that remote node and before you bring that node up to date by replaying the logs, you can find the transaction log that was causing trouble, delete it, pull it out of the Exchange 2010 Roadmap Series: Virtualization 10

12 stream, and Exchange is smart enough now that when it replays transaction logs if it notices one that s missing it will say, Oops, there s one missing, and it can go on and move along, and you won t record certain things that happened in that transaction log. Transaction logs are smaller than 1 MB, so in most locations you re going to lose very little data. But better to have that lagged copy so that you can pull out this level of corruption we all know has gotten rarer and rarer with Exchange, and with 2010 it s going to be rarer still because of the fact that it can handle page file corruptions. If they would have happened, it can go and it can pull that page from another database, another replica copy, really neat. This customer three-node DAG is also going to virtualize their CAS and HUBs for redundancy. They re going to duplicate those so that they ve got at least two CASs and two HUBs, but on different virtualization hosts, so that they re really splitting that apart. You re also going to want CAS and HUB in the disaster recovery environment, also your infrastructure, Active Directory, DNS, DHCP, and so on. Other Exchange 2010 Virtualization Scenarios Branch Office Streamlined Provisioning To Smaller Offices Distributed DR Sites Around The World DR Sites With Lagged Copies Log Files Are Replicated Delayed Insert Into Database (Hours, Days) If Major Corruption, Remove Troubled Log Before Transition Helper CAS/HUB 2007 And CAS/HUB 2010 Here are a couple other scenarios that are worthy of thought and using Exchange 2010 in a virtualized environment. Branch office scenarios, you may want to put an Exchange server there rather than have them come over the wire, so again a lot of organizations are consolidating down to as few data centers as possible and the branch offices coming in over the wire. But, if you have a requirement, you can streamline the provisioning to those branch offices by building a larger set of virtualized hardware to support Exchange file systems, SharePoint, SQL, business applications, and so on, and really streamline the delivery of that into smaller and more efficient rack space, so that s a good use for virtualization. Distributed DR sites we ve talked about, but having those DR sites available for different areas around the world as well. We talked about lagged copies, and again that s a real useful capability, and we went through what the troubles were there, also a transition helper, if you will. One of the things that we talked about in the first webcast in this series, on transition or migration for Exchange, was the fact that CAS and HUBs for 2007 are different than the CAS and HUBs for Each version talks to its own database. So, coming in and I want to talk to Exchange 2007 via CAS, via the coming in from the Internet, Outlook Web Access, I need to Exchange 2010 Roadmap Series: Virtualization 11

13 go through the CAS for Exchange 2007 in order to get to the 2000 mailbox server. So, the versions are specific to the mailbox servers. CAS will talk to other CAS. It can talk out past the version boundary. HUBs can talk to other HUBs, across the version boundary. But, only the CAS specific for 2010 can talk to the mailbox server. So, that sort of says that I m going to have additional requirements. If you ve already migrated to Exchange 2007, one of the ways to utilize some of the hardware in the transition time is to look at separate CASs and HUBs in the virtual environment for those different versions. Roadmap Summary Exchange 2010: Change In Your Backup Strategy? Tapes > Disk Backups > DAGs Database Availability Groups: Don t Have To Know Clustering 2 16 Copies Of Database / Backup From Any DAG Member Plan For 3+ Node DAGs, Within and Between Data Centers That brings us to the end of our Roadmap Session for Virtualization of Exchange We ve looked at the big changes that are occurring within the rise of the hypervisors, whether that s Hyper-V, VMware, or another validated virtualization product, but we re going to see more and more use there, and in some places it makes sense and some that it doesn t. Consolidations and resilience are going to be key drivers as people move towards Exchange 2010, again continuing the trend of less locations for Exchange, bringing more people over the wire, consolidating less servers to put more users and also to protect those servers and to build resilience in, and that s where we re going to get into the capabilities for database availability groups and other technologies that we ve talked about. Exchange is a heavy resource application, no matter how you re using it, whether virtual or not, and because of that you need to be keenly aware of the resources that it requires and, if you re going to be building a physical server, that physical server requires the number of cores that were talked about in more detail in our Sizing webcast. The same requirements are going to be there for the virtual environment. So, as you start adding up those requirements, in terms of cores, the CPU s cores, and memory, you may find that, Gee, that s a big a server as I was going to buy for the server anyway, so you need to balance that out a little bit. Obviously, servers get more and more efficient, but Exchange is a heavy user. We talked about some scenarios when not to virtualize: for unified messaging, when you don t have enough CPU or memory, or when you re using a hypervisor that s not validated. You really want to be careful about that, and I have the recent horror story I shared with you Exchange 2010 Roadmap Series: Virtualization 12

14 about a customer that had a hypervisor virtualization environment that had been validated but was no longer, and they got into serious trouble and they were unable to get support through Microsoft. And, we went through a number of different scenarios where hypervising, Hyper-V and other hypervisors virtualization makes sense, virtual disaster recovery, branch office scenarios, building in redundancy, particularly for transport capabilities, green computing, using less power more efficiently, also as potentially a transition helper, as you re moving from one version to another with Exchange. With that, I want to thank you for your time! My name is Lee Benjamin with ExchangeGuy Consulting. This concludes number four in our Exchange Roadmap Series for SearchExchange.com, and I want to thank you very much for your time! Kyle LeRoy: Thank you, Lee, for your presentation! That concludes today s presentation, Exchange 2010 Roadmap Series: Virtualization. If you d like to review today s material at some later date, an archived version of this event will be made available on the SearchExchange webcast library. I d like to thank Lee Benjamin for taking the time to be a part of today s presentation and, as always, thank you all so much for joining us today. This is Kyle LeRoy wishing you all a great day! Exchange 2010 Roadmap Series: Virtualization 13