Virtualize Business Critical Applications

by Jeff Szastak

Enhancing Exchange 2010’s Security Profile

In this post we will discuss using vShield to bolster the protection profile of Exchange 2010. We will start off with a brief discussion on vShield, and then move on to discussing the Exchange 2010 architecture, and then finally how we implemented vShield around Exchange 2010.  

vShield 5.0 Overview

The VMware vShield product family is the foundation for trusted cloud infrastructures.  vShield enables adaptive and cost-effective security services within a single management framework. vShield is a suite of products comprised of vShield Edge, vShield App, vShield Data Security, and vShield Endpoint. For purposes of this post, we will focus on two of the four products, vShield Edge and vShield App.

vShield Edge provides network edge security and gateway services to isolate VMs in a port group, vDS port group, or Cisco Nexus 1000v. vShield Edge is a stateful inspection firewall that can provide NAT, DHCP, IPsec Site to Site VPN VPN, and Web load balancing services for the virtual data center.

vShield App is a layer 2 / layer 3 virtualization aware, hypervisor based firewall that protects applications in the virtual datacenter from network based attacks. A major benefit to vShield App is configuring access control polices are based on logical and physical constructs versus purely physical constructs that a traditional firewall leverages. An example of this would be the ability to create rules based on a vApp (logical) versus IP Address (physical).

Exchange 2010 Architecture Overview

We built Exchange 2010 within the construct of a vApp. A vApp allows you to group VMs together and perform management functions against those VMs, such as power on, power off operations. vApp provide the ability to create ‘nested’ vApps. We leveraged this ability to create a multi-tier vApp for Exchange.

We created a root vApp labeled Exchange and then nested three different containers, based on Exchange 2010 roles (CAS, HUB, Mailbox). We then explicitly configured boot order within the CAS, HUB, and Mailbox vApps and at the Exchange Level.

 

We separated out the individual Exchange 2010 roles into individual VMs for the CAS, HUB, and mailbox roles. We used Exchange 2010 SP1 installed on Windows Server 2008 R2 Standard / Enterprise.  We also configured the SAMESUBNETDELAY setting to 2000ms since we are using HA, DRS, and vMotion with DAG. More information on running DAG on the vSphere platform, see the whitepaper Using VMware HA, DRS, and vMotion with Exchange 2010 DAGs. The VMware software used in this configuration was vSphere 5.0 and vShield 5.0.

For networking we used the vSphere Distributed Switch with one Port Group for production traffic  and a second Port Group dedicated to DAG replication traffic. In addition, we limited the number of ports in the DAG replication network to 2 so we would not have to worry about addition VMs being plugged into this Port Group. In the screen shot below, you can see the HUB01 and MBX01 VMs both using the Production dvPortGroup and the second vNIC on MBX01 using the ExchangeDAG dvPortgroup.

Once we got Exchange up and running we installed vShield. vShield installs default open so we were able to leverage the traffic flow reports inside vShield to assist us in creating the rules around Exchange 2010.

 Building the Rules

As stated earlier, vShield installs default open which allows us to leverage the traffic flows within vApp to better understand communication activity amongst systems. We decided to gradually lock down Exchange 2010 by first configuring VM to VM rules, and then implementing port based rules based on the TechNet post detailing ports used by Exchange 2010: http://technet.microsoft.com/en-us/library/bb331973.aspx.

We built our rule sets using logical constructs within vCenter Server.  For example, we built a rule stating the Mailbox vApp is allowed to communicate with the HUB vApp. By creating the rule against these logical constructs, any VMs placed into these containers will inherit the rules of that container.

As we built the rules we monitored traffic flows between Exchange 2010 systems, which was key in validating we correctly configured the rule sets and also identified other key traffic activities that were not documented in the aforementioned Ports Used by Exchange 2010 article. An example of this was UDP 139 from the Exchange vApp to our Domain Controller vApp.  

Closing Remarks

Configure an external syslog server for vShield. As you build your rules, enable logging of the rule in order to validate enforcement of the rule. Start with general rules, like VM to VM rules and if necessary move down to port specific rules. Both of these will provide better protection, be sure to implement the appropiate level for your enviornment. Be aware that as the rules become more granular you must be more diligent to ensure all ports required by the application and OS are available. When you have validated your configuration is correct, change the default allow rule to deny.

For a few years now we've been providing guidance on virtualizing Exchange on vSphere. Although not fully supported at the time, customers were looking for guidance to virtualizing Exchange 2003 and 2007 and so we created best practices guides and performance studies. Today we continue to provide best practices, design and sizing, and availability guides for Exchange 2010 on vSphere. With all of those resources out there one could ask, "What else is there to cover?" In this first posting of two I wanted to take a step back and look at some of the pre-requisites for designing an Exchange environment on vSphere. In Part 2 of this series I'll jump forward to some design considerations to keep in mind when virtualizing Exchange on vSphere. What about the technical details in between pre-reqs and design considerations? We've got those well covered and I'll provide links at the end of this article.

Microsoft Exchange Server, for most organizations, is the central communications stream and as such becomes critical to the daily operations of the business, or a business critical application. Unlike the typically virtualized workloads of days past, these business critical applications typically require a dedicated project staff and budgets, and are highly visible throughout the organization. Because of the importance of such a project to the organization proper planning is vital to ensure a successful outcome.

To aide in successful planning consider the following pre-requisites when beginning an Exchange design for deployment on vSphere.

Understand the business and technical requirements

Among the many technical requirements that must be followed when deploying Exchange and vSphere it is important to understand any technical and non-technical requirements placed by the organization. A few of the most common business requirements we encounter when designing a virtualized Exchange environment are listed below.

• High availability – What level of availability needs to be designed into the environment? Is there an SLA in place that requires services to be restored within a certain time period? With Exchange 2010 this is one of the most important decisions to be made at the beginning of the design process. The use of Database Availability Groups will dictate the amount of storage needed to house active and passive databases, as well as how many mailboxes can be supported per mailbox server. Is disaster recovery in scope?
• Supportability of the design – Those of us that have worked for large organizations know the importance of designing a supported solution, and more importantly the frustration of having support calls closed due to an unsupported configuration. When building the design keep support in mind and be sure to consult with your hardware and any other software vendors to make sure they will take your calls when problems arise.
• Scalability – Is the goal of the company to continue to grow or does the nature of the business keep the organization size stable? If this is a large environment do we need to consider deploying fewer larger virtual machines, or is it preferable to scale-out with smaller virtual machines. If this is a volatile environment do we need to have the capability to scale-out or up on demand using templates or hot-add technologies?
• Mailbox Size – Are there currently quotas in place or will they be introduced as part of this new design? Is there a limit to the amount of data that the proposed solution can handle? Does archiving need to be factored into the solution?
• Performance – What bolt-on accessories are in use in the current messaging environment and does their functionality need to be carried over? Many of these solutions will add overhead to the environment and their use needs to be accounted for when it comes time to size.

Analyze the current messaging environment

An Exchange 2010 sizing exercise is mostly based on the assumption that there is an understanding of the current usage of the messaging environment. If this is a greenfield environment it will be necessary to estimate what the usage will be and this can be very difficult. Typically I would recommend beginning with a medium to heavy workload, around 150 messages per day, per mailbox. The beauty of building on vSphere is that if it turns out that the environment was over-provisioned you can easily scale back and regain some compute resources for other projects.

If there is an existing Exchange environment you can download the Exchange Server Profile Analyzer to help understand the current messaging requirements. This tool can look at a single Exchange mailbox database or across an entire organization and report on user activity. Other ways to analyze the messaging activity within an organization include:

• Exchange message tracking logs
• Sendmail or Postfix logs
• Statistics from email anti-virus tools
• Logs from SPAM gateways
• Third-party email statistics tools

Regardless of which method is chosen, the desired outcome is to determine the average number of messages sent and received per mailbox per day. This is the primary method used by Microsoft to determine the amount of processor and storage resources each mailbox uses and the recommended amount of physical RAM that should be allocated for mailbox database cache. The table below from TechNet can be used to determine the amount of database cache, IOPS, and CPU estimates based on user activity.

Table 1. IO Profile Resource Utilization Estimate

Source: TechNet - Mailbox Server Processor Capacity Planning

Analyze the health of the current messaging and vSphere Environment

Before beginning an Exchange migration project, a full health check of the current Exchange environment, the vSphere environment, and any infrastructure dependencies should performed. Often times a new environment can help bring an underlying issue to the surface. Being able to identify these issues and resolve them before going into production can make a migration much smoother for the implementation team as well as the end users.

A number of tools are available to help make sure there are no glaring issues in the current environment.

• VMware HealthAnalyzer – captures data from the vSphere environment including configuration and utilization information to provide a health report card. Ask your VMware representative for more details on obtaining a health check using HealthAnalyzer.
• Exchange Best Practices Analyzer – The ExBPA is installed with the Exchange Management Console and can be used to quickly scan a particular server or the entire organization's configuration against best practices. The report lists details about the configuration and offers explanations and guidance on how to fix common issues. Running the ExBPA is a must before placing any Exchange server into production and is recommended to run as part of routine maintenance.

Identify support and licensing options

With a business critical application like Exchange it is key to understand support and licensing considerations. Support for virtualizing Exchange has come a long way over the past few years. The Server Virtualization Validation Program provides mainstream support for running Exchange 2007 and 2010 on vSphere. Prior to going down the road of building a design it is a good idea to walk through the Support Policy Wizard on the Windows Server catalog web site to validate that the solution you are putting together is supported.

Figure 1. SVVP Support Policy Wizard

No matter the hypervisor used to virtualize Exchange 2010, the support requirements remain the same. The Exchange team at Microsoft outlines the requirements for virtualizing Exchange very well on the Exchange System Requirements TechNet page. These requirements must be reviewed and understood to be sure that the design meets Microsoft's support guidance and to help avoid any confusion during a support request.

Exchange 2010 is licensed per server and client-access license, just as it is on physical. This is important to note as it may help determine whether you design using a scale-up or scale-out approach. Another licensing consideration is that of license mobility. Previously application licenses tied to a physical server could only migrate between physical servers once every 90 days. This was updated to allow application licenses to migrate between physical hosts within a server farm as needed. More information can be found in the Application Server License Mobility document. As always, we suggest you consult with your Microsoft representative to obtain the most accurate licensing information for your situation.

Thanks for making it this far. I hope you found the often overlooked pre-requisites for virtualizing Exchange 2010 on vSphere helpful. In Part 2 I will dive into some additional design considerations to keep in mind when virtualizing Exchange 2010 on vSphere. If you've missed any of the great resources we have on virtualizing Exchange 2010 on vSphere check out our resources page at the link below.

http://www.vmware.com/solutions/business-critical-apps/exchange/resources.html

-alex

One of the hottest topics I get into when talking to customers about virtualizing Exchange is storage. Not surprising considering the number of options available when we virtualize Exchange on vSphere. If you are not familiar with the common methods for provisioning storage in vSphere a brief description of each follows:

• VMFS based virtual disk (VMDK) – VMFS is a high performance, clustered file system that allows concurrent access by multiple hosts to files on a shared volume. VMFS offers high I/O capabilities for virtual machines and is optimized for large VMDK files. VMFS volumes can be Fibre Channel or iSCSI attached.
• Raw-device mappings (RDM) – RDM is a mapping file in a VMFS volume that acts as a proxy for a raw physical device, sometimes called a pass-thru disk. The RDM file contains metadata used to manage and redirect disk access to the physical device. RDMs can be Fibre Channel or iSCSI attached.

In early versions of ESX the virtualization overhead associated with deploying virtual disks (VMDK files) was much higher than it is today and why it was considered a best practice to place Exchange data files on physical mode raw-device mappings (RDM). As ESX and vSphere have evolved the performance difference between RDMs and virtual disks has become almost nonexistent. This leaves some questioning why we might choose to deploy RDMs for Exchange storage.

Some reasons for deploying RDMs today might include:

• Backups are being performed using a hardware based VSS solution using array based clones or snapshots - When talking to customers I typically see backups as being the number one reason for deploying RDMs. The ability to take array based backups quickly using hardware VSS makes RDMs very attractive for large organizations with massive amounts of email data. So, if we want to take advantage of array based backups are we limited to only using RDMs? Not quite, but more on that in a minute.
• Volumes larger than 2TB are required - With Microsoft supporting mailbox databases up to 2TB (when database resiliency is in use) volumes may need to be larger than 2TB. In vSphere 5 only physical mode RDMs support volume sizes up to 64TB, VMDK files are limited to 2TB.
• Require the ability to swing a LUN between a native Windows host and a virtual machine – Some deployments may choose to deploy on physical mailbox servers and later migrate to virtual machines. This migration could be expedited by swinging the LUNs from the physical mailbox server and attaching them to the Exchange mailbox VM using RDMs. With database portability only the user objects would need to be updated thus avoiding the time to move mailbox data over the network.
• Management purposes – Some environments may require greater control over the relationship between LUNs and virtual machines. An RDM is assigned to a single VM (unless using a shared-disk cluster) guaranteeing that the I/O capabilities of the LUN are dedicated to a single VM.

The good news is, if you're not limited by any of the reasons above you can deploy on VMDKs with confidence. I tend to prefer VMDKs for the portability, manageability, and scalability. By portability I mean the ability to use features like Storage vMotion, Storage DRS, and vSphere Replication to provide storage load balancing and disaster recovery. Improved management comes with the native tools available in the vSphere client for working with VMDKs. Some storage vendors have very slick plug-ins for the vCenter client if you must use RDMs, but it's always nice using the native tools. From a scaling point of view larger VMFS volumes can be used to consolidate VMDKs if dedicated RDMs are pushing the 256 LUN limit in ESXi. vSphere 5 supports VMFS volumes of up to 64TB, VMDK files are limited to 2TB.

Now that we can make some better informed choices for our storage format let's get back to the backups. If you are looking to deploy a hardware based VSS backup solution it used to be that the only option was to use physical mode RDMs. Today some storage vendors have made progress in giving customers the ability to deploy on storage other than physical mode RDMs. This comes in the following forms:

• In-guest iSCSI – Using iSCSI initiators from within the guest operating system an administrator can directly mount storage LUNs to the virtual machine. Connecting storage in this manner can still provide the ability to backup using array based snapshots and clones. This does put additional load on the virtual machine as it is now doing the storage processing, but will allow you to avoid using RDMs and can mitigate the 256 LUN limit of ESXi. At VMworld this year (both in the US and Europe) many customers shared their success stories of using in-guest iSCSI with Exchange.
• NFS based VMDKs – Some storage vendors have added the ability to perform hardware based VSS backups of VMDKs housed on NFS based networked-attached storage. I've also had many customers tell me of their success using this solution. My only comment here is that Microsoft has been pretty clear on their lack of support for housing Exchange data files (mailbox and queue databases and transaction logs) on network-attached storage (Premier customers check with your Microsoft rep). That said, I'm a huge fan of NFS based storage.

Whether to choose VMDK or RDM for your Exchange storage should be based on technical and business requirements and not on any preconceived notions of performance or supportability. All storage protocols discussed here have proven to perform well within the requirements of Exchange and support for each is well documented on Microsoft's TechNet site. I've included some helpful links below for your reading enjoyment. With that I'll wrap up this post which hopefully has given you a bit to think about and maybe presented some new options for your deployment.

As always, we look forward to hearing from you so please join the discussion!

-alex

Alex Fontana, Sr. Solutions Architect

Performance Best Practices for VMware vSphere 5: http://www.vmware.com/pdf/Perf_Best_Practices_vSphere5.0.pdf

Virtualized Exchange Server on NFS, iSCSI, and Fibre Channel: http://www.vmware.com/files/pdf/vsphere_perf_exchange-storage-protocols.pdf

Performance Characterization of VMFS and RDM: http://www.vmware.com/files/pdf/performance_char_vmfs_rdm.pdf

Exchange 2010 System Requirements: http://technet.microsoft.com/en-us/library/aa996719.aspx

Those of us embarking on a new virtualization project like to learn from others. At the very least we want to be sure that if someone else has done something similar we can learn from any lessons encountered along the way. Over the past year and a half we've had many conversations with customers who were in the process of evaluating Exchange 2010 or designing a logical environment with a decision on whether or not to virtualize still pending. Many of these customers wanted to hear from other customers.

We're now getting to the point where we have full deployments that we can begin to talk about. Some we may not be able to mention by name but can speak to specifics around size and design. Others have allowed us to come in and create case studies based on their success story.

Today we released our latest case study on Raymond James. As a financial company managing about 1.9 million accounts, email is one of the most critical applications the Raymond James IT organization supports. Read how Raymond James successfully virtualized an Exchange 2010 environment on vSphere to support over 18,000 mailboxes, provide high availability without the use of Database Availability Groups, and how they use VMware Site Recovery Manager to provide disaster recovery capabilities and proactively test site failover.

Case Study, Video

-alex

The VMware performance team is constantly working to show how virtualizing tier 1 applications on vSphere can provide comparable performance to physical deployments. With the release of vSphere 5 we can now provide up to 32 vCPUs and 1TB of memory per VM! That kind of scale-up capability means there are very few (if any) workloads that we can't accommodate.

When dealing with Exchange 2010 designs there are recommended maximums that should be followed to achieve the best performance. Those recommendations are published by Microsoft on TechNet. For stand-alone mailbox servers the recommended maximum is 12 CPU cores, when working with six core CPUs. For multi-role servers the recommended maximum is 24 CPU cores, again when working with six core CPUs. For those customers that prefer to run very large instances (>8 vCPUs) of Exchange servers vSphere 5 now makes this possible.

In keeping with tradition the VMware performance team has published a whitepaper examining how Exchange 2010 performs on vSphere 5 in terms of scaling up (adding more vCPUs) and scaling out (adding more VMs). This paper shows that vSphere 5 can provide flexibility in deployment while maintaining a positive user experience.

For the full paper see Microsoft Exchange Server 2010 Performance on vSphere 5.

-alex

Alex Fontana, Sr. Solutions Architect

The wave of VMware customers looking to virtualize Exchange 2010 on vSphere continues to accelerate. While there have been customers who have chosen not to virtualize the DAG nodes, the reasons were not those we heard of in years past. Today it's not because of performance or high storage IO, in fact most customers believe that the majority of their applications can be virtualized, including their business critical applications. VMware customers who chose to postpone virtualization of their Exchange 2010 DAG nodes mostly did so for one reason: lack of support for vSphere advanced features from Microsoft. Those customers will be pleased to know that this is now a thing of the past.

With Microsoft's latest announcement of enhanced hardware virtualization support for Exchange 2010 customers looking to deploy a virtualized Exchange 2010 environment and take advantage of vSphere features such as vMotion, VMware HA and DRS can do so with full support from Microsoft and VMware. VMware has been officially supporting the use of these vSphere features along with Exchange 2010 DAGs for some time now, as described in our KB article here. The additional support by Microsoft simply validates what we've been promoting since the release of our Exchange 2010 on VMware documentation available here.

As news of this validation and support begins to pick up steam we anticipate that questions will come up as to what are the best practices for making sure your deployments are successful. To help provide our customers with some insight into using these features with their production Exchange 2010 DAG clusters we've put together a whitepaper outlining testing we performed in our labs earlier this year. The purpose of testing outlined in Using VMware HA, DRS and vMotion with Exchange 2010 DAGs was to:

• Validate the use case of combining VMware HA with Exchange DAGs to reduce the time required to re-establish DAG availability.
• Validate the use of vMotion with Exchange DAGs to allow the use of DRS and proactive workload migration while maintaining database availability and integrity.
• Provide guidance and best practices for taking advantage of these vSphere features.

The whitepaper can be found here: http://www.vmware.com/files/pdf/solutions/VMware-Using-HA-DRS-vMotion-with-Exchange-2010-DAGs.pdf

It shouldn't come as much surprise that the results we came up with and documented are in line with what Microsoft themselves are recommending, further validating our results. Additionally this whitepaper will provide guidance for customers looking to use features such as DRS to allow their vSphere environment to efficiently balance workloads and manage resources and VMware HA to provide even higher levels of availability.

This will no doubt begin driving up the number of virtualized DAGs out there, so help out your fellow vSphere and Exchange administrators. Join the Exchange, Domino and RIM VMware User Community!

-alex

Alex Fontana, Technical Solutions Architect

With the release of Exchange 2010 the native clustering feature (Database Availability Group) is a significant improvement over what was available with all previous versions. Be that as it may, there will still be customers that simply don't want to cluster. Typically, not clustering the application would mean no high availability. VMware changed that with the introduction of VMware HA. By simply enabling this feature (which is literally a check box) all virtual machines, regardless of operating system or application, would be provided protection from an ESX host failure. To take it a step further you could enable VM Monitoring to protect against guest OS failures by monitoring VMware Tools running within the virtual machine. Agnostic protection of the guest OS and application is great, but the question that was consistently asked by our customers was "…what if my application fails?" vSphere 4.1 helps answer that.

With vSphere 4.1, we introduced an application programming interface (API) to provide third-party vendors the ability to integrate with VMware HA. The capability to allow application monitoring agents to interact with VMware HA is enabled per vSphere cluster with additional configuration options available per virtual machine. When enabled, this feature allows application monitoring agents to send application heartbeats to VMware HA. In the event of an application-level failure the application monitoring agent can take action to either bring the application back online, or stop the application heartbeat, causing VMware HA to initiate a restart of the virtual machine. Prior to vSphere 4.1, only VMware tools heartbeats could trigger VMware HA restarts.

To take advantage of the new API Symantec has released ApplicationHA. Using ApplicationHA Exchange administrators can provide application monitoring and availability without having to deploy an Exchange 2010 DAG.

ApplicationHA consists of three components:

• ApplicationHA Console provides the interface between the Guest Component and vCenter Server. This component will be installed on a dedicated server (virtual or physical).
• Guest Component is installed in the virtual machine where the application to be protected is running.
• vSphere Client plug-in enables administrators to view the status of a monitored application and make basic configuration changes.

The Symantec Application HA agent for Exchange 2010 can monitor databases and bring them online and offline. In addition to protecting databases, Exchange 2010 services are also monitored. When an agent detects that a database or service has failed that component will be restarted. If the restart fails multiple times (configurable by the administrator) the agent reports the failure to VMware HA. VMware HA can then restart the virtual machine. The following Exchange 2010 services are monitored by the ApplicationHA agent:

• Microsoft Exchange AD Topology Service
• Microsoft Exchange Replication Service
• Microsoft Exchange System Attendant
• Microsoft Exchange Information Store
• Microsoft Exchange Mail Submission

After the installation of the Guest Component in the Exchange 2010 mailbox VM the vSphere client can be used to configure application monitoring. The ApplicationHA Configuration Wizard allows the administrator to select the installed application to protect (one application per VM), and for Exchange 2010, databases to monitor.

With the application configured for monitoring administrators can use the vSphere client to display the status of the application, start and stop the application, re-configure monitoring, and enter maintenance mode.

.

The Settings link on the ApplicationHA tab allows the administrator to set additional configuration options.

• App.RestartAttempts – the number of times that ApplicationHA must try to restart an application before declaring it faulted.
• App.ShutdownGraceTime – maximum time in seconds that ApplicationHA will wait for an application to gracefully shutdown before declaring it faulted.
• App.StartStopTimeout – maximum time in seconds that ApplicationHA will wait for an application to start or stop, after which an informational message is displayed stating that the operation is in progress in the background.

Deploying clustering technologies such as Microsoft Clustering Services within virtual machines is a supported configuration. Many customers have chosen not to take this approach for their critical applications due to limitations around using vSphere features such as VMware vMotion, DRS and in some cases HA. Using vSphere 4.1 and Symantec ApplicationHA can provide the needed application awareness in VMware HA while continuing to provide vSphere features in a supported fashion.

For more information about Symantec ApplicationHA including additional application support see the links below.

http://www.symantec.com/business/application-ha

http://sfdoccentral.symantec.com/appha/5.1/windows/pdf/appha_exch_agent.pdf

http://www.symantec.com/content/en/us/enterprise/white_papers/b-virtualizing_business_critical_apps_WP.en-us.pdf

-alex

Alex Fontana, Technical Solutions Architect

Hello and welcome to the new VMware Business Critical Applications blog, a source for information, insight, and updates to help you virtualize your business critical applications on the VMware platform.

The blog will cover the following applications/functional areas and we will continue to add more over time:

• Microsoft Applications
  • Exchange
  • SQL Server
  • SharePoint
• SAP
• Oracle
• Java Applications 

We intend to use this blog to:

• Communicate best practices for deploying on the vSphere platform.
• Provide Updates on current solution projects and activities including solution rollouts, new collaterals etc.
• Provide Update on various product and solution enablement activities including events, webinars, partner engagements, trainings etc.
• Publish results of lab testing in the aforementioned functional areas.  Testing and results will include functional and technical use cases, workload characterization study and deployment  "how-to".  For official performance test results, please refer to the VROOM! Blog at http://blogs.vmware.com/performance/.
• Communicate general application design principles that we've discovered through research and work with our customers.
• Communicate step-by-step procedures for common application and infrastructure management tasks.
• Highlight VMware and partner products or features than can enhance the overall solution.
• Provide links to relevant online documentation.
• Provide insight on optimizing software licensing costs for virtualization.

We plan on posting regularly so grab the RSS feed or sign up for an e-mail alert to receive notification of new entries as they are posted.

For published whitepapers, including technical whitepapers and customer success stories, please visit our Business Critical Applications website at http://www.vmware.com/solutions/business-critical-apps/.  On the right-hand side, you'll find links to the individual application pages.

Thanks for reading!

Scott Salyer

Solutions Manager, VMware