Server virtualization is a very common trend in almost all corporate data centers. In many cases virtualization provides a lot of benefits. Today I am going to talk about why virtualization is almost never the best option for Exchange 2013. I’ll address several aspects; supportability, hardware utilization, economy, and high availability.

You’ve decided to upgrade to Exchange 2013. You’ve heard that Exchange 2013 causes “Mailbox bloat.” You’ve got tons of different mailbox quotas, and there does not seem to be any real rhyme or reason as to why they are applied.

So you’ve deployed Exchange 2013 in a highly available configuration. Now it’s a couple of days after “patch Tuesday,” and you’re ready to update your servers. You’ve applied the patches in question to a test server, and you’re confident that they will not have adverse effects on your Exchange servers.
Now what? Do you just apply the patches, and let the high availability features in Exchange keep your users connected? What is the proper order in which to patch your servers? Do all of your servers need to be running at the same patch level, or can you apply some patches to one server, but not another?

Exchange 2013 has reached RTM, and is now available for sale. In late February, we expect the Service Packs to be available that allow us to deploy Exchange 2013 into existing Exchange environments. With Exchange 2013, we will have several new options for load balancing the Client Access servers and I would like to quickly go over those options now.

Exchange 2013 Architecture

Exchange 2013 has been designed with some architecture changes from the previous versions of Exchange. One of the biggest changes is that Exchange 2013 has been released with only 2 server roles. Those roles are the Client Access Server and the Mailbox Server. The functionality of the Hub Transport and Unified Communications roles from the previous two versions has been added into these two roles. Additionally the CAS role been redesigned so that its only job is to proxy connections to the proper Mailbox Server. (There is a single instance where the CAS server redirects connections instead of proxying them, but that is not relevant to this post). In doing this redesign, one of Microsoft’s major goals was to enable better High Availability options for the CAS role.