The more I think about the subject, the more I am convinced that Microsoft has dodged a support bullet by not making Exchange 2013 more deployable than it has been since its formal release last year. Of course, you can absolutely put Exchange 2013 into production today, but realistically speaking this just hasn’t happened. People are waiting for Microsoft to release Exchange 2010 SP3 and whatever update for Exchange 2007 is going to be necessary to co-exist alongside Exchange 2013 in an existing organization or they have decided to wait until Exchange 2013 SP1 appears.
But getting back to the point in hand, the longer that I work with Exchange 2013, the stronger my opinion that this is software that was released before its time. The fit and finish of a truly well-rounded product is not there and too many flaws are evident to make anyone believe that Exchange 2013 is ready for prime time.
All software has bugs. New major releases of software products will have some areas that aren’t quite as well sorted as the parts that are present in previous releases. Exchange 2013 makes a big change in its management story as the old MMC-based console is replaced by the browser-based Exchange Administration Center (EAC). I genuinely like this approach. It makes sense to provide an interface to manage Exchange that can run on iPads, Android tablets, and Windows Surface devices as well as many smartphones. It makes sense to junk MMC and remove a dependency that has caused Exchange problems in the past. I get all that. But what’s causing some heartburn is the number of places where EAC is functionally deficient when compared to its predecessor or where it seems like the user interface was created by someone who has zero knowledge of what it’s like to manage Exchange for more than twenty or so mailboxes. Just look at the space allowed to populate the membership of a distribution group to see what I mean. This should not happen for the management tools of a product that’s been in production for 17 years. To be balanced, I acknowledge that there are places where EAC has better coverage of a feature than EMC provides, but that list is pretty short.
EAC’s close kissing cousin Outlook Web App (OWA) can hardly be regarded as feature complete either, even if it boasts the nice new feature of offline access. OWA provides zero access to public folders (modern or ancient). It has no support for S/MIME messages. No spell checker, perhaps because we don’t need one anymore. There’s no way to move the reading pane. And OWA includes an awful implementation of “People” that wastes an enormous amount of screen real estate and once again makes me suspicious that the design center for Exchange 2013’s browser-based interfaces is misplaced. Or that Microsoft signed off OWA after testing against a GAL containing 20 people. Exchange 2010 SP1 contained a completely redesigned and much better version of OWA. I think that the same will have to happen in Exchange 2013 SP1.
The signs are that the Exchange ecosystem is incomplete or not prepared for prime time too. The anti-virus and anti-spam story is still being sorted out after Microsoft decided to exit the on-premises AV market (and of course, Exchange 2013 doesn’t support the VSAPI interface). The backup story is immature and not clear (maybe we should all consume the Kool-Aid touted by those who say that you don’t need to run backups for Exchange). There’s no Edge server built for Exchange 2013 so you have to use the older Exchange 2010 version. And RIM is still figuring out how to support BlackBerries with Exchange 2013.
Little experience with public folder migration is yet available because, as far as I can tell, no one has yet attempted a migration. And we have no great experience with the wonders of site mailboxes and the integration between Exchange 2013 and SharePoint 2013 either. Finally, I don’t see any great enthusiasm in the third party software vendor community to push out updated versions of their products to work alongside Exchange 2013.
Microsoft has not built a good quality record for RTM versions of Exchange. Going back as far as Exchange 2000 (1999), the mantra has always been to wait for the first service pack before doing anything serious in terms of deployment. The generally accepted wisdom is that it takes time for bugs to be sorted, new functionality made ready, and knowledge to build before jumping into deployment and migration. I think Exchange 2013 RTM joins its Exchange 2000, Exchange 2003, Exchange 2007, and Exchange 2010 RTM predecessors in extending the record for poor-quality RTM releases.
The bottom line is that if Microsoft had released all the bits necessary for older versions of Exchange to co-exist alongside Exchange 2013 when Exchange 2013 reached general availability, I think they’d now be suffering some significant increase in support incidents caused by the fit and finish problems that are so evident across the product.
I have great hopes for Exchange 2013 because I see many things in the product that are done well. But for now I am telling people to keep their powder dry and wait for Exchange 2013 SP1 before commencing real work on this version. That isn’t to say that you won’t get value today by deploying test installations of Exchange 2013, but why jump into the alligators when Exchange 2010 SP2 is so well sorted at this stage?
Follow Tony @12Knocksinna