Exchange Server 2013 Moves Toward Simplicity

With Exchange Server 2013 Preview available for a few months now and the Microsoft Exchange Conference (MEC) last week, we're getting a clearer picture all the time of what the New Exchange has in store. At MEC, the Microsoft message was pretty strong around the security and compliance story for Exchange 2013, which is good news of course. But overall, what impresses me more and more is the general simplification of Exchange -- all while providing improved performance and new or enhanced functionality.

Exchange 2013's simplicity appears both in its architecture and management tools. For the architecture, the big news is that the number of server roles has been reduced from five to two. You'll have to deploy only Mailbox servers and Client Access servers; the functions of the Hub Transport and Unified Messaging servers have been rolled into one or the other of the two remaining. As for the Edge Transport, while it won't be present in Exchange Server 2013 at launch, I've heard some rumors that it might be reintroduced in some form perhaps along with service pack 1 (SP1). In the meantime, Exchange 2013 can function with Edge servers from Exchange 2010 or Exchange 2007 if you've deployed them in your environment.

On the management front, Exchange 2013 simplification comes by way of the Exchange Administration Console (EAC), the new web-based GUI for running your Exchange environment. EAC combines and replaces the functionality of Exchange Management Console (EMC), which has been around since Exchange 2000, and Exchange Control Panel (ECP), the web-based management interface introduced in Exchange 2010. In keeping with the overall Microsoft trend, the EAC UI is designed with the simplified Windows 8, Metro-style look, making it easy to read, and easy to find what you need with few clicks. (For the PowerShell aficionados, rest assured that Exchange Management Shell is still available for management, too.)

Additionally, EAC is the management interface whether you're running Exchange on premises or using Exchange Online through Microsoft Office 365 -- or a hybrid configuration of both. As Microsoft speaker Julie Xu said during her MEC session on "Manageability in the New Exchange," EAC is "one console to rule them all," with a nice little nod to The Lord of the Rings there. Along the same lines, the Outlook 2013 desktop application interface and the Outlook Web App interface in Exchange 2013 are nearly indistinguishable, giving end users an outstanding experience on either platform.

This trend toward simplification for Exchange will certainly be welcomed by Exchange administrators. There were good reasons to split the server roles apart in the development of Exchange 2007, but the added complexity in deployment and management has been a definite pain point ever since. In fact, in a recent non-scientific Instant Poll on the Exchange & Outlook page of, when asked the question, "Which of the new features in Exchange Server 2013 are you most looking forward to getting into your production environment?" the leading response by a wide margin was "Simplified architecture (i.e., only two server roles, Client Access and Mailbox)."

In addition to admins, the third-party vendors generally also see this move as a win. At MEC, I spoke with vendors such as F5 Networks, KEMP Technologies, Binary Tree, Messageware, Mimecast, and others, all of which offer products or services that directly interact with Exchange. The message I heard repeated in one form or another from each of them was that if their existing solutions weren't already compatible with Exchange 2013, they should be by the time Exchange 2013 is ready for production environments. That's good news for companies considering an upgrade because you might not have to buy all new third-party add-ons as well -- but be sure to check with your specific vendors to make sure.

Not all the news around simplification is necessarily good. Simplifying sometimes means leaving things out, and anytime you do that, you're likely to have someone who's upset about it. For instance, as Tony Redmond pointed out, EAC doesn't provide the PowerShell cmdlets necessary to perform the underlying actions of the GUI commands, meaning that potential avenue of training is gone. Another simplification is the change to use RPC-over-HTTPS for all connections to Outlook clients, which could mean some extra care is necessary for configuration.

Nonetheless, Exchange 2013 should be a welcome change to any admins that feared the upgrade from Exchange 2003 after the server roles were split. Of course, for organizations who are still on Exchange 2003, there's no direct migration path to Exchange 2013; you'll have to move to Exchange 2010 first, and then migrate to Exchange 2013. That's not an ideal situation -- but that's also a problem for another day.

Follow B. K. Winstead on Twitter at @bkwins
Follow Windows IT Pro on Twitter at @windowsitpro

Discuss this Blog Entry 5

on Oct 5, 2012
@murat yildirmoglu: The separation into separate roles was necessary as the limitation was CPU performance, as explained during MEC (and probably other events and via other media). This isn't the case anymore but certainly was during the development of Exchange 2007 and 2010. So, not so stupid, it actually had valid reasons. The official (technical) recommendation today is to use the multi-role Exchange server, which already predicted the reduction in roles for future Exchange versions. On you other points: 1. integration with ADUC. Yeah, I'm used to it now but it was a bit annoying at first. However, this made it very easy to separate AD admins and Exchange admins. For smaller companies not an issue, but there are some that require a strict separation. User provisioning and scripting (agents) could help ease the pain. But yeah, I feel your pain. 2. In-place upgrading: With every version the Database gets an overhaul (less IOPS!!), so it would take a lot of effort to make it work. Furthermore, even if you could in-place upgrade Exchange, you'll still have an older version of Windows. Less efficient, shorter mainstream support etc. etc.. I don't think the effort to make this possible would pay off with significant more Exchange upgrades. 3. No, PowerShell is here to stay and is one of the major improvements in Exchange IMHO. It does have a more steep learning curve, but I can automate a lot more without the use of third party tools. Scripting, bulk management etc. etc.. So, on this I totally disagree with you. 4. Don't know what you mean by that. You can configure Send Connectors with a smarthost (IP or FQDN). You could use FOPE (EOP)/Postini/or any other hoster. You could also implement the Edge role (at 2013 RTM you should use the 2010 Edge), but that does provide extra admin effort.
on Oct 7, 2012
dmstork, separation into roles was never necessary: Performance has never been a problem for the Exchange Servers. Extra roles were just nuisance; nobody can assure me they are useful. In-place upgrade is necessary because our servers are sufficiently powerfull and we shoudn't waste our precious money to buy new hardware. In addition, because we don't have in-place upgrade option, whenever a new Exchange server version is released we have to move mailboxes back and forth. It is just silly! PowerShell is a quantum leap in the wrong direction. ipod, iphone, ipad, and all those android devices over there clearly show that there must be simplicity both in client devices and server devices-software. Powershell is contrary to all current trends. I offer to have smart hosts for our clients. It will simplify on-premise installations. Currently, the clients have to deal with anti-virus, anti-spam software and they must find a way to send messages avoiding enlisting to the blacklists. Microsoft must supply use such smart hosts. The last thing: Do you know that Google and Yandex provides mail hosting services for free? (Google up to 10 mailboxes and Yandex up to 1000 mailboxes).
on Oct 5, 2012
One important thing I think you should add, is the removed need for a Layer7 load balancer when you want an High Available Exchange 2013 implementation. Layer4 is sufficient and reduces the need for session affinity and the like, which was something that generated a lot of issues if not configured correctly. Oh, and another is that Microsoft doesn't mind that you authenticate directly on the CAS instead of the (axed) Threat Management Gateway 2010 reverse proxy. Just my 2 cents :-)
on Oct 5, 2012
It is good to see Microsoft returned to sanity after all those crazy years. Thanks god, There are still wise men in Microsoft. Increasing the server roles was the stupidest thing in the history of Exchange Server. But some additional steps are still necessary: 1) To integrate Exchange management functions with Active Directory tools (ie, AD Users and Computers console). 2) To be able to in-place upgrade the existing Exchange Servers 3) To get rid off the powershell completely. 4) To provide customers with some smart host functionality so that they should'nt deal with black-lists, anti-spam and anti-virus programs.
on Oct 5, 2012
Hi Murat, Thanks for the feedback! Yes, I recall you've been a strong critic of the complexity in Exchange Server over the past couple versions. As for the additional points you mention, I know the Exchange team is always listening to feedback and trying to implement what makes sense to the most people. Perhaps other people are requesting the same types of features. As far as PowerShell goes, however, I wouldn't look for that to go away any time soon. The trend has been for that to be more widely entrenched throughout the Microsoft product stack, and many admins like having that interface as an option. What the Exchange team could do is continue to add more of the shell commands to the GUI, which seems to have been the trend with each release. B. K. Winstead Sr. Associate Editor

Please or Register to post comments.

What's Exchange and Outlook Blog?

Exchanging ideas, news, and reviews about Microsoft Exchange and Outlook, and the wider fields of messaging, mobility, and unified communications.

Blog Archive