It is nice that Computerworld have come to the same conclusion as I did (January 17) when I advised customers to wait for Exchange 2013 SP1 before they deploy. But some of the logic that Computerworld use to support their case is a tad odd or simply not based on hard data.
The first red flag was when Computerworld said that Exchange 2013 couldn’t run on Windows 2012. This error was quickly corrected, largely because it is so obviously wrong. I’ve always been a big fan of deploying Exchange on the latest version of Windows because you cannot upgrade the operating system once Exchange is on a server. It doesn’t make much sense to use an aging operating system as the base for a new version of Exchange, just like it doesn’t make sense if Microsoft had released Exchange 2013 without Windows 2012 support.
Moving on, the three major areas of concern cited by Computerworld were:
Keeping the services of Exchange running at peak performance can be particularly challenging: I consider this assertion to be curious. My own experience is that the core of Exchange 2013 is stable. You can argue that sufficient production data is not yet available to measure the reliability of Exchange 2013 because customers have not yet deployed the product in large numbers. If this is the case, then the statement cannot be backed up with proof. On the other hand, if lots of customers were running into problems with Exchange 2013, then I would have expected to see many reports of server crashes – and I have not.
Perhaps Computerworld has the hard data to back up this peculiar claim, but I think not. And throwing the discontinuance of the Exchange Best Practice Analyzer (ExBPA) into the mix doesn’t really add much value to the argument. When it appeared some years ago, ExBPA was a useful tool, but the problem with “best practice” is that it is a moving target and the rules and data that ExBPA uses to make recommendations do not always deliver the best result. The lack of the Mail Troubleshooter for Exchange 2013 is regrettable but hardly a mission-critical gap.
There is no support for BlackBerry Enterprise Server: Yep, we are still waiting for the updated CDO/MAPI library to allow BES to be upgraded to communicate with Exchange 2013. However, I hazard a guess that the lack of Exchange 2010 SP3 is of more pressing concern and more important when it comes to ranking deployment blockers.
There is little or no documentation or guidance: TechNet is full of Exchange 2013 documentation. In fact, TechNet is problematic because it pushes Exchange 2013 content whenever possible, an issue that has caused grief for the Exchange community since Microsoft made the switch last November. The real problem is the lack of sizing guidelines. Customers have become accustomed to seeing fairly complete sizing information from Microsoft to help figure out hardware configurations for Exchange mailbox servers (in particular). The much-used and well-regarded Exchange mailbox server role requirements calculator has not been updated for Exchange 2013, probably because of the fundamental changes in architecture such as the updated server roles, switch to HTTP as the protocol of choice, and reduction from 100 to 50 in the maximum number of databases that can be mounted on a server. The current hardware advice in TechNet is just not sufficient. Because of the lack of tools and sizing information, I agree with Computerworld’s view that:
“… it is odd for the documentation to be this incomplete months after RTM and general availability.”
Moving to the core of the matter, Computerworld then go on to say:
“But it is uncommon for so many entire pieces of the product to feel rushed, incomplete, buggy or simply not ready.”
I guess whether something feels rushed, incomplete, or buggy is subjective. I do think that there are parts of the new Exchange Administration Center (EAC) that need to be refined and that EAC is missing quite a few options that were available in the Exchange 2010 Management Console (EMC). However, you can argue that EAC does a better job of some things (like alerts) than EMC ever did. It’s also true that Outlook Web App seems incomplete right now. Again, it brings some interesting new features like offline access to the table, but misses out on things like a moveable reading pane, S/MIME support, and access to public folders (modern or ancient).
Although I have heard that some people have experienced problems sending messages from shared mailboxes, I have not met many bugs in terms of “stuff that just doesn’t work”. The Exchange 2013 bugs that I have reported to Microsoft are mostly fit-and-finish issues like EAC using a list box that’s too small to display the membership of a distribution group. It’s irritating to misuse screen real estate but hardly a critical bug like a memory leak or catastrophic database corruptions.
Although I disagree with many of the assertions made by Computerworld, I think that they are right that Exchange 2013 RTM is a work in progress and that people should wait before deploying. I’m not sure that I would wait 12 to 18 months as I have hope that improvement is on its way soon. Microsoft is working hard on updates to fix many of the fit-and-finish problems that exist now and I expect that EAC and OWA will be in much better shape after they have been updated. After all, if they are not, the problems will be mega-amplified when Exchange 2013 starts to power Exchange Online in Office 365.
All of this still doesn’t answer the question of why Microsoft released Exchange 2013 when EAC and OWA needed more work and some of the essential third-party products were not ready, not to say Microsoft’s own sizing advice. The answer is that sometimes things happen in companies that are for the greater good of a larger whole. In the case of Exchange 2013, the Office Wave 15 product set was good to go and Exchange could not have been a laggard. It’s just the way things happen in the real world.
Follow Tony @12Knocksinna
