Tips for virtualizing Exchange Server with vSphere 4

Virtualizing Microsoft Tier 1 applications such as Exchange Server 2010 with vSphere 4 will help VARs avoid some roadblocks posed by physical deployment, including performing host upgrades without downtime. Knowing how to virtualize server roles in 2010’s Exchange Edge server, for instance, can help make your services more flexible as well.

Solution provider’s takeaway: Save yourself some time by virtualizing Microsoft Tier 1 applications such as Exchange Server 2010 with vSphere 4 and sidestep physical deployment complications, including performing host upgrades without downtime.Check out the different types of server roles, such as Exchange Edge server role, when virtualizing Exchange 2007 or 2010.

Download this free guide

Could Securing Your Channel Business Be Easier? We Can Help.

Download our latest guide to the top strategies solution providers can leverage for starting up and securing a cloud practice, successful approaches to selling and marketing cloud, and why it is urgent for partners to transition now.

Virtualizing Exchange ServerMessaging and collaboration have become critical components in most if not all business operations. In businesses, email is integrated into most business processes, including the help desk, bug tracking, archiving, document management, and monitoring operations. When email is unavailable, business productivity decreases, and foot traffic in the break room increases dramatically. Escalations and calls to the help desk increase dramatically. There are many reasons for an Exchange server outage to include server hardware failure, database corruption, and performance degradation because of server storage over-subscription. Virtualizing Exchange Server can help mitigate most of the issues associated with a physical deployment by doing the following:

Allowing you to right-size your Exchange Server deployment by adding resources as needed with just a reboot.

Moving your Exchange Server to a more capable host to perform host upgrades without downtime to your end users through the use of VMotion.

Providing simplified availability through the use of VMware HA if your Exchange Server virtual machines hang or you get a blue screen.

Allowing you to create simplified disaster recovery scenarios without the requirement of similar hardware. A virtual machine can run on any VMware-supported physical server that has the ESX hypervisor installed.

Over the past 10 years, the Microsoft Exchange Server product team has managed to create a messaging and collaboration product that captures more than 50 percent of the messaging and collaboration market share all while dominating this space.

Microsoft has worked very hard on this release to make the product easier to design, deploy, manage, and recover. With all the new features and enhancements, Microsoft Exchange 2010 is threatening to dominate even more of the messaging and collaboration market. There are a lot of compelling reasons to transition from an Exchange Server 2003 or 2007 environment to an Exchange 2010 environment.

Exchange Server 2010 is totally virtualization friendly, more so than Exchange 2003 and Exchange 2007. We will briefly cover some of the more important features and reasons you might want to start planning for a virtualized Exchange 2007 or 2010 environment.

Exchange Server virtualization trendsPrior to 2007, not many medium to large organizations were even thinking about virtualizing Exchange Server, let alone actually doing it. These were the major objections to virtualizing this application:

Lack of Microsoft support for the virtualized Exchange Server application

Virtualization overhead

Poor application performance when virtualized

Poor storage I/O performance when virtualized

The “If it ain’t broke, don’t fix it” mentality

Fear of loss of employment

Some experimented with virtualizing Exchange Server 2003 but abandoned the effort when they experienced severe performance issues with Mailbox server virtualization.

Microsoft also didn’t make it easy to virtualize its applications, which created some major barriers to the virtualization of tier-1 applications. In the fall of 2008, Microsoft announced the Server Virtualization Validation Program (SVVP) and, in doing so, took a major step forward into the virtualization journey.

With this program, Microsoft announced support for its major applications, and Exchange was one of the first. Before this announcement of support, some brave and daring customers took a modular approach and virtualized the bridgehead servers and front-end servers and left the back-end Mailbox servers on physical servers.

Despite the warnings from Microsoft that they would not be supported or that they would be required to reproduce the issue on physical hardware in order to receive support, customers continued to pursue virtualization.

With the maturity of the VMware virtualization platforms and the formation of the tier-1 applications performance team within VMware, VMware was able to extensively test Exchange Server 2003 and Exchange 2007 and produce recommendations and guidance for virtualizing the Exchange products. After producing these recommendations and guidance, VMware started to see an uptick in the virtualization of the Exchange Server product. Most of this virtualization was being done on Exchange Server 2007 with minimal efforts being applied to the Exchange Server 2003 platform.

VMware then started to work with the engineering folks to enlist the various server and storage manufacturing partners to improve the performance of virtualized tier-1 applications. Microsoft Exchange Server was one of the first tier-1 applications with which VMware did extensive performance testing and performance optimizations on the VMware virtualization platform.

To prove to the information technology world that the virtualization of Exchange was entirely possible, VMware took on the challenge of virtualizing its internal Exchange environment.

Two authors of this book, Alex Fontana and Charles Windom, were the principal architects for the design and implementation. During this process, the architects worked directly with VMware engineers, members of the file system group, and the high-availability folks within VMware to ensure that the virtualization project would meet or exceed the performance of the existing Exchange Server 2003 implementation.

Tip: For more information on the VMware Internal Exchange virtualization design and implementation, please visit the VMware website at www.vmware.com/solutions/business-critical-apps/exchange/resources.html.

In an effort to improve the performance for the virtualized Exchange deployments, VMware started working with its server and storage partners to create real-world Exchange 2003 and 2007 configurations. Today, work is still being done to constantly improve the performance of the vSphere platform as it pertains to running the Microsoft 2010 suite of tier-1 applications.

Exchange Server comparisonsAs the Microsoft Exchange Server platform has continued to evolve over the years, it has changed from the typical all-in-one message server to a more distributed environment.

Exchange Server 2003Exchange Server 2003 offered the following distributed server roles; some of these server roles were more difficult if not impossible to virtualize:

Front-end server:This is responsible for external client connectivity (Outlook Web Access, POP3, IMAP, RPC/HTTP, SMTP, and Outlook Mobile Access, to name a few). This server role was easy to virtualize because it wasn’t very demanding on storage resources, and the VMware platform provided more than adequate CPU, memory, and network resources for these roles to perform as well as a physical server.

Exchange bridgehead server:This is responsible for delivering messages to Mailbox servers outside the client sender site. Exchange Server 2003 utilizes routing groups to send and receive messages between Exchange sites, such as a local Exchange site in Palo Alto and a remote site in Japan. This was another server role that could be virtualized, although you needed to pay more attention to the configuration of the virtual machine for this role because it required more CPU, memory, network, and storage resources than the Exchange front-end server role.

Back-end server: This server role contains the database(s) used to hold the mail databases. This is also the server role that provides mailbox and public folder access. It can also (optionally) provide NNTP, POP, and IMAP4 access. This server role required careful design and planning when virtualizing.

Virtualizing this server role in large to very large organizations proved daunting if not impossible. Because of the demanding CPU and storage requirements for this role, these organizations would have to deploy more virtual machines and increase the management overhead associated with managing those virtual machines. This proved to be a major obstacle in virtualizing this server role.

Exchange Server 2007 and 2010 server rolesWith the introduction of Exchange 2007, Microsoft changed the configuration and naming convention of the server roles. Instead of the typical three server roles, Microsoft introduced five new server roles; three of the five had somewhat identical functions to the previous server roles.

There are no longer the Exchange front-end, bridgehead, and back-end server roles. The new names of the roles going forward are as follows:

Exchange Edge server role (EDGE)

Exchange Client Access server role (CAS)

Exchange Hub Transport server role (HUB)

Exchange Mailbox server role (MBX)

Exchange Unified Messaging server role (UM)

Each Exchange server role performs a specific function in the Exchange organization. For each role, only the Exchange server services get installed and started for that role. You no longer have to worry about disabling multiple Exchange services and deleting databases on server roles that do not require them.

In the next sections, we will give a brief explanation for each role’s responsibility in the Exchange organization.

Edge server roleThis server must be deployed at the perimeter of the network. It should not be a member of the domain.

Figure 6.1 highlights the Exchange 2007/2010 Edge server role. As you can see in the figure, there are two Edge servers deployed in the demilitarized zone (DMZ) of the network.

You can deploy multiple Edge servers in the perimeter network. When you do deploy multiple Edge servers, they will provide redundancy and failover capabilities for inbound email.

You also have the ability to load balance your SMTP traffic to multiple Edge servers by defining multiple mail exchanger (MX) records with the same priority in the DNS database for your mail domain.

The Edge server also provides messaging hygiene known as antispam and antivirus control for email incoming to your Exchange organization and outgoing to the Internet.

Edge transport servers can also prevent information that could be confidential to your organization from being sent outside the organization through the use of edge transport rules.

You can create and assign rules to control message flow out of the Exchange organization, and if a message meets the criteria of the created rule, that message will be blocked from being sent outside the organization.

The Edge transport server can also perform inbound and outbound SMTP address rewriting on messages. This can be especially useful to provide a consistent appearance of SMTP addresses in email organizations that perform lots of acquisitions.

Virtualizing this role is easy because it is not very demanding on CPU, memory, and disk resources. However, be mindful of your network resources when deploying multiple servers because this places additional demand on the physical network adapters in the ESX host. Ensure that you provide adequate network resources and redundancy through the use of ESX network teaming.

Figure 6.1: Edge server role

Client access server roleThe Client Access server (CAS) role hosts all client protocols such as Outlook Web Access (Outlook Web App for 2010), POP3, IMAP4, Outlook Mobile Access (OMA), and Outlook Anywhere (formerly known as RPC over HTTPS). The Client Access server role must be installed in every Active Directory site that has a Mailbox server installed.

Figure 6.2 shows the CAS role deployed as a CAS array on the internal network protected by the firewall.

The Client Access server is also responsible for providing access to the Exchange free/busy data and also allows Exchange 2007 and greater clients to download automatic configuration settings using the Autodiscover service.

Figure 6.2: Client Access server array

To increase the scalability, availability, and redundancy of the Client Access server, in 2010 there were changes made to the Client Access server role. These are some of the fundamental changes:

New client access server arrays (CAS arrays) provide availability and load balancing. The failure of a member of the CAS will automatically connect the client to another member of the CAS array.

CAS arrays allow a higher number of concurrent connections per server and a higher number of mailboxes per server.

The new RPC endpoint on the Client Access server role replaces the RPC endpoint on the Mailbox server role.

New business logic routes Outlook clients to the CAS server to access a mailbox instead of logging onto the Mailbox server.

Exchange 2010 CAS server roles use RPC encryption by default, so Outlook 2007 and greater clients are compatible with Exchange 2010 CAS servers. Outlook 2003 clients will need to modify their settings to force RPC encryption in order to connect to a 2010 CAS server or array. Exchange Server or Windows Server administrators can also create a group policy to force Outlook 2003 to use RPC encryption.

This server role in Exchange 2007 can be easy to virtualize because you can also deploy multiple servers to provide load balancing and redundancy capabilities for the CAS server role. With Exchange Server 2010, be mindful that the CAS server role has taken on additional responsibilities (mentioned earlier in this section) and requires more server resources in the form of CPU, memory, disk, and network resources. The same rule of deploying multiple servers to provide load balancing and redundancy applies, but now you have the CAS array option. In actual production scenarios, we have seen that IMAP places additional demand on physical server resources than MAPI and could mean that you will have to deploy additional virtual machines to meet this additional demand.

Tip: If your Outlook 2003 users cannot connect to an Exchange 2010 CAS server, or receive the error messages “Cannot start Microsoft Office Outlook. Unable to open the Office Window. The set of folders cannot be opened or unable to open your default email folders. The information store cannot be opened,” then try enabling the Encrypt Data Between Microsoft Office Outlook And Microsoft Exchange Server option in the Outlook 2003 security settings.

Hub transport roleThe Hub Transport role is responsible for moving messages through the Exchange organization. When we say “through the Exchange organization,” we mean inside and outside the Exchange organization.

The Hub Transport role uses Active Directory sites to route email messages to local and remote Exchange sites in the email organization. Deploying multiple Hub transport servers in the same Active Directory site will provide availability as well as load balancing. There must be at least one Hub Transport server installed in every Active Directory site that has the Mailbox server role installed.

In the absence of the Edge server role, the Hub Transport can be configured to send and receive messages to and from the Internet as well as provide messaging hygiene, messaging policy, and compliance using compliance and transport rules.

Enhancements to the Hub Transport server role in Exchange Server 2010 include the following:

Shadow redundancy provides redundancy for messages the entire time that they are in transit.

Write I/O is reduced by about 50 percent.

The transport server becomes stateless.

The Hub Transport dumpster has been enhanced to use a database replication feedback mechanism to control what messages remain in the dumpster.

Messages are deleted from the dumpster once it has been replicated to all database copies.

Larger messages are supported without triggering back pressure.

In Exchange Server 2007, this server role is fairly simple to virtualize, but you must take into consideration the disk I/O requirements for the Hub Transport server, because it maintains the queue database. We recommend using RAID 1 or RAID in larger environments. With Exchange Server 2010, this server role becomes easier to virtualize because of the reduction in disk I/O and the stateless database. It is safe to utilize RAID 5 for the database, and we recommend that you deploy at least two Hub Transport servers in every site that hosts an Exchange server.

Figure 6.3 shows a deployment of three Hub Transport servers on the internal or private network. This will facilitate load balancing as well as redundancy for the Hub Transport server.

Figure 6.3: Exchange 2007/2010 Hub Transport server role

Mailbox server roleThis server role will be the heavy lifter of your Exchange 2010 deployment. Its sole responsibility is to play host to the mailbox and public folder databases. In Exchange 2007 and 2010 Server editions, the public folder is optional and has been provided for backward compatibility.

All connections with the exception of the public folders are accomplished through the Client Access server role. Connections to the public folder databases are still handled by the RPC endpoint on the Mailbox server role, so clients must still connect directly to the Mailbox server role to access the public folders.

Figure 6.4 shows three Exchange 2010 Mailbox servers deployed as a database availability group (DAG). We will get into DAGs later in the chapter.

Figure 6.4: Exchange Server 2010 Mailbox servers

The Mailbox server role is also the logical unit in a high-availability configuration. Because the Mailbox role performs the database hosting role only, you must have installed a Client Access server and a Hub Transport in any Active Directory site that will host Exchange messaging services.

As mentioned earlier, the CAS role will handle all client connections for mailbox access, and the Hub Transport role will route message throughout the Exchange organization.

New for the Exchange 2010 platform, the concept of the storage group has been deprecated. The term database has been redefined to mean an Exchange database and its transaction log files; they are now thought of as a single unit. In the Exchange 2010 Enterprise edition, each Mailbox server role can host up to 100 databases.

The Exchange 2010 Standard edition can host only five databases per server, but now you can also use DAGs on the Standard edition when installed on Windows Server 2008 Enterprise. It is important to note that Exchange Server 2010 Standard edition can upgraded to Enterprise edition without reinstalling the product. Because DAGs use Windows clustering services, Windows Server 2008 Enterprise edition is required for implementing DAGs.

Exchange databases are no longer pinned to the Exchange server. Because of this fundamental configuration change, all databases created on the Exchange Mailbox role must have a unique name.

Real-World Lesson LearnedWhen first testing the Exchange 2010 platform with the new LoadGen 2010 tool, a colleague of ours created four individual mailbox databases and then copied the databases and renamed them manually to create a total of twelve databases for testing. When he tried to run the LoadGen 2010 tool, he experienced many errors, one of which was a feedback loop.

We were asked to troubleshoot the configuration and after googling for the specific error, we decided to dismount the last eight databases of the twelve and rerun the LoadGen test tool.

To our surprise, all of the errors disappeared, and we were able to run a successful test. We then deleted the last eight databases, created eight new mailbox databases, and proceeded to run the tool again. All tests completed successfully.

This was a lesson learned for our colleague as well as ourselves. Exchange databases must be truly unique, or you will experience undocumented issues. There was no information anywhere regarding this error message.

Unified messaging server roleThis provides the ability to access mail messages via phone or computer. This role is not currently supported under virtualization. Although there are some customers actively virtualizing the Unified Messaging (UM) server role with success, Microsoft explicitly states that it will not support this role virtualized and recommends that you deploy this role on physical servers. You should install the UM server role in an Active Directory site after the Hub Transport role is installed.

Not much testing has been done internally to prove whether this role is a viable candidate for virtualization. Apart from this, we will discuss only some of the capabilities of this role under the Exchange 2010 platform. These are some of the features and enhancements for Exchange 2010:

Auto Attendant:Allows for the creation of custom menu prompts to navigate the UM system. The user can then use their voice or touchtone keypad to navigate the system.

Call Waiting light:Alerts user of waiting messages.

Subscriber Access:Allows a user access to their mailbox, calendar items, and messages using a regular phone line.

Text-to-Speech:Allows user to listen to messages in their Outlook mailbox.

To date, Microsoft does not support the Unified Messaging server role virtualized because of heavy demands on server CPU and memory. With the introduction of vSphere, however, you can have an eight-vCPU 255 GB memory virtual machine. With these new virtual machine capabilities, some customers have started to virtualize this role. We recommend that you follow the Microsoft Support guidelines about virtualizing Exchange Server 2010 to ensure that you get the best support that Microsoft has offer for virtualized Exchange deployments.

These roles could be deployed on a single server or on multiple servers for modularity. Even though you could install your Exchange 2003 server roles onto multiple servers, you would still get all the Exchange Server services installed and started on each of the server roles. This became a real point of frustration with Exchange and Windows server administrators when trying to secure the various server roles.

Exchange Server 2003 and prior versions were all 32-bit environments, and the maximum addressable memory that Exchange Server 2003 and prior versions could handle was 4 GB. You could increase this limit by using various boot.ini switches, but under heavy usage scenarios, you could exhaust the Windows kernel resources and fragment the usable memory address space. The only way to recover from these issues was to reboot the server. Table 6.1 describes some of the differences among the various Exchange Server versions since Exchange Server 2003.

Table 6.1: Comparison of Exchange Server Versions

Exchange Server 2003

Exchange Server 2007

Exchange Server 2010

32-bit environment.

64-bit environment. 32-bit version (not supported in production).

64-bit environment.

4 GB max addressable memory.

Multiterabyte max addressable memory.

Multiterabyte max addressable memory.

About 932 GB addressable database cache.

Multigigabyte database cache for better performance.

Multigigabyte database cache for better performance.

4 storage groups

50 storage groups

Storage groups removed from Exchange 2010. Databases and logs still remain, but both are now referred to as just a database. 100 databases per server max.

Storage I/O very heavy because of small block size (about 4 KB) and database cache. Very difficult to scale beyond 2,500 users per Mailbox server and maintain large mailboxes and good end-user experience.

Larger database cache, increased block size and write coalescing to increase performance, and reduction in storage I/O to about 50 to 70 percent.

Schema changes along with sequential database access and large database cache allow for even more storage I/O reduction (around an additional 50 to 70 percent) and larger mailboxes.

Administrative groups used to delegate control and access to Exchange organization. Routing groups used to send and receive mail to nonlocal Active Directory sites.

Routing changes in Exchange 2007 and the introduction of the Hub Transport server role. With Exchange Server 2007, routing is now performed using Active Directory sites.

Routing remains pretty much the same with enhancements to the Hub Transport server role. Shadow messaging is introduced. Shadow messaging ensures that messages are delivered to each hop in the delivery path. If delivery fails anywhere in the delivery path, the message is re-sent from the previous hop to where the message failed. Role-Based Access Control (RBAC) is introduced in Exchange 2010. RBAC provides the ability to granularly grant access permissions to the Exchange 2010 organization.

Active Directory security groups are used to grant access and delegate access to the Exchange 2007 organization.

The database page size has been increased to 32 KB.

Database mobility means that databases are no longer pinned to a specific server.

DAGs allow you to maintain multiple copies of your Exchange databases and provide immediate failover in the case of server or database corruption.

Microsoft removed the server as the dependency for the Exchange Server databases. Databases have been moved to the organization level of the Exchange Server.

These are just some of differences that make Exchange 2007 and 2010 extremely virtualization friendly. There are whole hosts of other enhancement and improvements, and we invite you to examine these features and improvements to the Exchange 2007 and 2010 platforms.

About the authors:

Charles A. Windom is a solutions architect at VMware on the Zimbra messaging and virtualization teams.

0 comments

Register

Login

Forgot your password?

Your password has been sent to:

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy