My Exchange 2013 Nightmare

It is a new year, and that means another product update from Microsoft.  This time around, it is Exchange.  Microsoft recently released Microsoft Exchange Server 2013.  It seems that they are keeping the Exchange rotation going on a 3 year span, but do we really need to upgrade our email server every three years?

Here is where you’ll get mixed reviews.  Some IT professionals may say, “If it’s not broke, don’t fix it”, while others may say, “We have to upgrade, Microsoft said so”.  While Microsoft may be pushing businesses to move up to the newly redesigned Exchange 2013 platform, my recommendation would be to hold off as long as possible, or until they at least release some sort of update for Exchange 2013.

In my first attempt to roll out a new Exchange 2013 environment, we had mixed results.  We were building a brand new domain on a new VMware server deployment.  We implemented one server for our domain controller. This was a virtual machine running Windows Server 2008r2 with only Active Directory installed.  We then created another Windows Server 2008r2 virtual server to host our Exchange installation.

After installing the many, and sometimes confusing prerequisites, we were well on our way to the actual installation of Exchange 2013.  We got the Exchange software installed, made the necessary DNS changes, opened the necessary ports on the firewall, and held our breath.  For about the first four hours, everything was great…. or was it?  Internal and external mail tests were running fine.  Users were receiving their mail on their smartphones, via webmail and also in their Outlook clients.  The implementation of Exchange 2013 was too easy.  Well, almost.

Within four hours of the Exchange server being online, one user came to me and stated, “I just received an email from an international client that was sent about 3 hours ago.  The email stated that I was supposed to be a part of a conference call at 4:00pm and it is now 4:30pm.  What happened?”

I started digging through log files, checking the event logs and even started sending some test messages.  The logs offered no insight as to what was taking place.  In fact, there was nothing in the logs that would have indicated any type of mail flow issues. 

Microsoft has ripped out the Exchange Management Console in Exchange 2013, leaving administrators either the Exchange Management Shell, or the new Exchange Management Web Interface for administering the Exchange deployment.  One of the few tools that they did leave us with is the mail queue viewer.  I opened up the viewer and sure enough, there were hundreds of emails sitting in the queues waiting for internal and external delivery.  I thought to myself, “How could this have happened?  Everything was just working great!” 

Flustered and confused, I reconfigured our DNS settings and firewall settings to route mail back to our Exchange 2007 server and promptly called Microsoft.  After discussing the issues with Microsoft, they stated that the issue was caused by the confusion of Exchange 2013 wanting to use IPv6 instead of IPv4. 

Our entire network is based off of IPv4 and we haven’t even discussed the possibilities of changing over to IPv6.  Microsoft acknowledged that they were aware of the problem and that it would be addressed in the first service pack or update package that came out for Exchange 2013.  When I inquired about the amount of time this may take Microsoft to release, they informed me that they did not have a set date, as they were still working on correcting other issues and adding other features.

So here I was, staring at one Exchange server screen seeing hundreds of incoming and outgoing emails stuck in queues that would never reach their final destination and hundreds of other emails that had made it to delivery and are now stuck in another server’s mailbox databases all while watching things run near perfectly on our Exchange 2007 server.

I decided to change the DNS and firewall settings to point back to the new Exchange 2013 server and  reboot the Exchange 2013 server to see if maybe that would clear up the queues, and sure enough, as soon as the server came back online from a reboot, all incoming and outgoing mail was delivered properly.  Why would a server reboot successfully clear the queues?  I was stumped.

For the last time, I changed all of the DNS and firewall settings, updated recipient policies to include all email domains and moved back to the Exchange 2007 server for our email needs.  I exported all contents of the mailboxes from the Exchange 2013 server and imported them into the user’s mailboxes on the Exchange 2007 server.  Everything was back in place, and the Exchange 2013 nightmare had finally come to an end.       

Since this deployment attempt, I have recreated physical and virtual servers to house Exchange 2013.  I have made DNS and firewall updates and changes so many times in the last month; I can do it in my sleep.  It did not matter what platform I installed Exchange 2013 on, the end result was exactly the same.  It would work for some time, and then all of the mail would get stuck in delivery queues.  I would reboot the server, and the mail would be delivered.  It just didn’t make any sense.

Unfortunately, there is no happy ending to this story, nor was there some unforeseen revelation that came upon me to be able to fix the Exchange 2013 deployment.  It simply did not work.  I have heard of other engineers having the exact same issues, and I have heard other engineers claim that they have deployed Exchange 2013 with no issues at all.  I say, if the shoe fits, wear it, unfortunately for me, well, I guess my feet were too big.

While the new release of Exchange 2013 is full of new features, several back end reconfigurations and the redesign of the EMC and OWA modules, the headaches of the initial implementation attempts have left a bad taste in my mouth for Exchange 2013.  I thought maybe we would deploy an Exchange 2010 server and wait for a service pack and do a simple upgrade to 2013, but, oh yeah, you currently can’t migrate from Exchange 2010 to Exchange 2013.  Microsoft intends to fix this in their release of the Exchange Cumulative Update (CU1), which is expected to be released sometime in the first quarter of 2013. 

I’m not holding my breath, and I am in no hurry to deploy Exchange 2013 at all.  Exchange 2007 has been as reliable as it comes, so I will stick to the side who claims, “If it’s not broke, don’t fix it”.  Maybe Microsoft should start to take this approach with future deployments of their existing software packages.