Exchange Server and Complexity: Less is Better

Lately I've been thinking a lot about complexity in Microsoft Exchange Server and its surrounding infrastructure. One of my largest customers (I can't say who, but the name rhymes with "US Navy") still has a substantial population of Exchange 2003 servers, and the organization is in the process of moving some of its sites to Exchange 2007. Meanwhile, I work daily with Exchange 2010, and Exchange 15 is right around the corner. Are there any lessons we can draw from the increasing sophistication of these products?

The immediate answer: Yes. I vividly remember a vigorous discussion at a past MVP Summit wherein Andy Webb, former Exchange Server MVP and a great American, pointed out that one certain side effect of the new complexity introduced in Exchange 2007 was that smaller customers wouldn't upgrade or would look for alternatives such as hosted Exchange. I've heard similar complaints -- "this is too complicated," "SMBs won't deploy it," "there needs to be a simpler way" -- levied at Exchange 2010 and Exchange 15 as well.

Only Microsoft knows for sure what its adoption numbers look like when broken down by customer size. I think it's fair to say that some smaller customers have avoided upgrading as long as possible because of their fear that additional complexity in later versions of Exchange would cost them money or reduce their operational efficiency. However, I don't think that's the real issue. The real killer of complexity with Exchange isn't what Microsoft puts in the product; it's what we do with the product after we deploy it.

One case in point: resource forests. A resource forest, you might recall, is what Microsoft calls a dedicated forest that contains only services or applications such as Exchange. User accounts go in one forest and Exchange goes in another. I can honestly say that I've seen only a handful of customers whose business need for a resource forest (and the isolation of accounts and services that it can provide) outweighed the additional cost and complexity of maintaining a separate Active Directory (AD) infrastructure, providing directory synchronization (where necessary), and operating a second forest.

Virtualization is another, perhaps less extreme, example. Microsoft and VMware have tried really hard to tamp down the complexity of maintaining virtualized environments, but the fact remains that they are inescapably more complex than the same number of physical servers. Virtualized environments are more complex simply because they require you to manage not only the virtual machines (VMs) but also their physical hosts and the hypervisor itself -- plus any shared storage you might be using, as many highly virtualized environments depend on shared storage for efficiency and performance.

There are tradeoffs, of course; the increased complexity of virtualized environments comes with the potential for lower operating costs and increased resource utilization. But my suspicion is that many organizations who turn to virtualization for these benefits actually end up realizing little net gain when they include the additional complexity that comes as part of the package.

Microsoft's take on the phenomenon of increasing complexity seems to be that operational maturity is what will save us all. "Operational maturity" is sort of a catch-all phrase that, loosely translated, means that your messaging admins have both knowledge and wisdom. What's the difference? Knowledge is knowing that tomatoes are fruit. Wisdom is knowing that you don't put tomatoes in fruit salad.

In Exchange, operational maturity means having the knowledge of how Exchange works in enough depth to realize what configurations are possible, and what the support and cost effects of different choices are. Wisdom is being able to counterbalance these support and cost effects with business requirements and the overriding "keep it simple, stupid!" philosophy that has been a linchpin of IT operations since the early days of vacuum-tube computers.

That said, what have you done to make your Exchange environment less complex? Drop me a note to let me know. I think this is a pretty fertile topic to explore, given how creative Exchange administrators tend to be with solving problems.

Discuss this Article 5

muraty
on Jun 15, 2012
Paul, my method to make transition less complex is not to upgrade to Exchange 2007-2010 at all. Instead, I recommend the migration to cloud, especially Gmail. Gmail hosts our mail systems while we keep our domain name. It is free for at most 10 users. And you forget servers, licenses, anti-spam and anti-virus software, backup and maintenance tasks. If sufficient number of firms would take this way Microsoft might act wisely and make Exchange simpler again.
twallutis
on Jun 15, 2012
Can you define "small business"? Here in Germany small companies (up to 500 or 1000 users) with only one Exchange 2003 or Exchange 2007 server are more likely to deploy Exchange 2010. Even a one-to-one-server migration from Notes to Exchange is not too complicated. What makes Exchange 2010 complex? High Availability. The need to deploy either four servers (two Hub/CAS and two MBX) or two multi-role servers and two HW-NLBs. I agree with you that a resource forest is something you should only use if it is really necessary. Another thing is security. Mailflow gets complex when your mail goes through several hops (AV, anti-SPAM, Encryption-GW). That makes troubleshooting hard. What annoys me with Exchange 2010 is that i miss some features from 2003 that are removed without any obvious reason. The Message Tracking GUI is really bad. Another good example is Sender based routing; now you need to write your own transport agent or buy a 3rd party product. But beside of that, Exchange 2010 gives you the opportunity to consolidate your servers. I would avoid a migration to Exchange 2007 for several reasons: the HA solutions (CCR, SCR, SCC, LCR) are no longer existing (you have to learn something you dont need in Exchange 2010 and possibly (i hope) not in 2013)) and delegation of administration without RBAC is no fun. I would strongly recommend to move to Exchange 2010! PS: Here in Germany Cloud-based solutions are not really popular; mainly becaue of security concerns. So GMail is not an option (same goes for Office 365)
jjenkins@solidn...
on Jun 14, 2012
It is difficult to take anything you say seriously when you don't even understand how virtualization reduces cost and complexity in Exchange deployments. This article is pretty weak even when overlooking that mistake. I don't see a point. So customers with complex forest have complex exchange server configs? Wow, share more wisdom. You should add " and customers with SBS server have simple, wizard based Exchange that is pretty simple." I would suggest that Exchange has kept Microsoft relevent in these cost cutting cloud migrating days. The iPhones, iPads, RPC-over-HTTPS for laptops make communication easy and productive.

Please or Register to post comments.

IT/Dev Connections Exchange Server

Las Vegas
September 30th - October 4th

Paul ThurottYou'll have the opportunity to experience:
• Future Deopyments
and Integrations
• Hybrid Deployments
• Exchange Online
• Windows 8 Deployment
and much more!

Come See Tony Redmond & Mark Minasi in Person!

Early Registration Now Open

Current Issue

May 2013 - The NameTranslate object is useful when you need to translate Active Directory object names between different formats, but it's awkward to use from PowerShell. Here's a PowerShell script that eliminates the awkwardness.

CURRENT ISSUE / ARCHIVE / SUBSCRIBE

Windows Forums

Get answers to questions, share tips, and engage with the Windows Community in our Forums.