I have written several posts providing insight into some technical challenges that I have encountered while helping my customers upgrade to Exchange 2010. Upgrading any technology within a computing environment requires time and effort, and with some of the technical challenges I’ve already documented, some of you may be wondering if upgrading your Exchange environment is worth the effort. For this post, I thought I’d provide some insight into why my customers have been upgrading to Exchange 2010 rather than discussing technical challenges encountered during the upgrade process.
Electronic Messaging Requirements
Whenever I begin an Exchange 2010 Design Session with a customer, I always start by helping my customers define and understand their electronic messaging requirements. While it can sometimes be a challenging exercise, this is an essential part of the design process that cannot be overlooked because the requirements drive the overall design process. As I often tell my customers, once the messaging requirements are understood, the high level architecture practically designs itself. In many instances, I have found that my customers’ electronic messaging requirements have changed since their last deployment or upgrade.
For many of my customers, in years past, email was not considered a mission critical application. My how times have changed. I now find that the majority of my customers classify email as a mission critical application to their business. As a result, they are making investments in the underlying architecture to ensure that their email infrastructure meets their mission critical application standards. For many customers, this typically requires redundant hardware and redundant copies of email data. For my customers who have found themselves in a situation where their email requirements have changed, upgrading to Exchange 2010 has enabled them to deploy a new Exchange architecture to meet their organization’s evolving needs. For many of them, what was an adequate email solution 5 years ago no longer meets their organization’s needs. In several cases, re-evaluating messaging requirements and upgrading to Exchange 2010 were essential to mitigate risk to the organization.
Hardware Redundancy and End User Transparency
As mentioned above, many companies require redundant hardware for their mission critical applications; and many companies are now classifying email as a mission critical application. Microsoft has provided the capability to support redundant Exchange Servers since Exchange 5.5. However, with each new version of Exchange, the ability to support redundant servers and the reliability of such solutions has improved dramatically. As a consultant responsible for deploying highly available solutions for my customers, I take personal responsibility for the solutions that I deploy. I can honestly say that when designed and deployed correctly, I have personally watched customers reboot Exchange 2010 Servers in production and the server reboot has been transparent to end users.
Previous versions of Exchange provided automated and manual failover capabilities, but none of the previous solutions ever provided 100% transparency to end users when failovers occurred. Granted, the end user impact could be minimized to a popup notification in the end users’ System Tray or an informational Outlook dialogue box. Nonetheless, when an Exchange Server failover occurred, someone within the end user community would notice. For many of my customers, organizational requirements dictate 100% transparency to end users when performing automated or manual failovers within the email environment. Anything less than 100% transparency requires scheduled downtime sometimes weeks in advance. When designed and deployed correctly using CAS Arrays, load balancers, Database Availability Groups, and the latest version of Outlook, Exchange 2010 does provide 100% transparency to the end user community when servers go down expectedly or unexpectedly. This capability alone has been reason enough for some of my customers to upgrade to Exchange 2010.
Email Data Redundancy
While previous versions of Exchange supported clustering to provide hardware redundancy, all versions (with the exception of CCR and SCR Clustering in Exchange 2007) only provided a single copy of each Exchange database. Over the years I have had customers experience database corruption within their Exchange databases. Usually this corruption was caused by a hardware failure or an application or administrator mistakenly removing Exchange Log files in an incorrect manner. Whatever the cause, database corruption can happen; and having a duplicate copy of a corrupted database can be a real life saver.
For years, some third party products have been able to duplicate Exchange Server databases from one server to another. Some could even replicate data between datacenters located in different geographic locations. This capability is now built into Exchange 2010 via Database Availability Groups. Having this capability built directly into the product is a tremendous benefit for a couple reasons. First and foremost, the solution uses native Microsoft technology to replicate data. As a result, data replication is fully documented and supported by Microsoft. Also, third party applications are no longer required to provide database redundancy. This creates a less complex and less expensive solution for organizations that require data redundancy. The ability to use native Microsoft technology to replicate Exchange databases to multiple datacenters has been another reason many of my customers have upgraded to Exchange 2010.
Even though it was never officially supported by Microsoft, I have had several customers run Exchange 2007 or even Exchange 2003 in virtualized environments. My customers did this at their own risk, and I did my best to support them when they ran into issues. It was a very happy day for many of my customers when Microsoft announced that Exchange 2010 would be supported on virtualized hardware. Simply being supported virtually was reason enough for some of my customers to upgrade their Exchange environments to 2010.
Since its release, I have helped numerous customers deploy or upgrade their Exchange environments to Exchange 2010. Each deployment has presented some challenges, but every deployment has been successful. If you’re considering an Exchange 2010 upgrade, hopefully you find the rationale behind some of my customers’ reasons for their upgrades helpful in your decision-making process.