2012-10-29

IT/TECH: Exchange 2013 - First installation impressions...





This is a first, just written down, impression of the new Exchange 2013 server - especially some weird stuff I experienced with the installation. During the next weeks, I will provide a more in deep article.

Last night I started my first installation of the final (TechEd) version of Exchange 2013. The idea I had was to create the same installation as with typical Exchange 2010 scenarios, meaning a Exchange 2013 for mailbox (and backend) and a Exchange 2013 for Client access.


So far, so good: My first thought was: Couldn't be slower than installing Exchange 2010 - well, if you have the same thoughts, forget about it. In my best times, a clean Exchange 2010 SP2 installation took all over two hours, with Exchange 2013, especially due to some stupid installation issues I had, it took so far more than four hours. 

This isn't because there is no documentation, indeed, the initial Exchange 2010 documentation was worse in comparison to the today existing Exchange 2013 documentation (which can be found here: http://technet.microsoft.com/en-us/library/bb124558%28v=exchg.150%29.aspx).

It is more due to a very stupid issue that arose during my installation: 
  1. The switch from summer to winter time on my systems
  2. A problem with the initial Administrator mailbox I could reproduce twice by now. 
For 1) the installation broke on the system I wanted to install the Client Access with a message stating that the certificate is invalid. A problem which arises from time to time on virtual machines that haven't their local time set correctly, but in in my case, a problem that simply occurred since I was starting the installation short before 0300 MEZ and - how should it be more stupid - the installation procedure did create a certificate that started at 0258 today and ends somewhere in 2017 - however, of course my system did set it's time one hour back 0158... and consequently the setup procedure failed.

After trying forth and back I finally decided to change the system time one hour forward and guess what, the installation went through - even the system did work as expected from that point on. However, as a beginner, that was only the ramp-up of problem 2).

After calling https://localhost/owa and trying to login as domain admin, the problem 2) the administrator mailbox didn't exist, arose. As if this wasn't devastating enough, the error message was cryptic:

WARNING: The object domain.local/_Domain/Users/Administrator has been corrupted, and it’s in an inconsistent state.

Well, the page at least suggested to refresh the side which I did and I got a better hint on the error:

The following validation errors happened:
WARNING: Database is mandatory on UserMailbox.






At this point, the complete system is rendered useless since you can't access the Webinterface - and with Exchange 2013 - herewith you are dead!

Since I know my previous Exchange versions and had some stupid issues like that I decided to install the Client Access role on the mailbox system. In opposition to the documentation as is right now, you can't change the features or setup by opening "Programs and Features" but need to run setup.exe from the installation media - so far so good.

Adding the Client Access role is no issue as well - and surprisingly I could login with the admin account even though the mailbox was still defect!

However, since I had a similar issue some years ago with Exchange 2007, this was what I expected (honestly: hoped for). After log-in successful, I decided to give an old trick a try and delete the administrator mailbox - which didn't succeed via web interface. The good thing is: There is still the Exchange PowerShell. Important: Don't Panic and you !must not! log-out before you are doing the following:

Disable-Mailbox Administrator does the trick. After refreshing the web-interface list of recipient mailboxes, the Administrator mailbox disappears and you can simply create a new mailbox for the Administrator.

Finally, on the original Client Access system, the login does work as well - and oh surprise - https://localhost/ecp (the new admin- interface) does run on the intended Client Access system as well (dance).

1 comment:

Anonymous said...

Awesome!!!!!! Thank you!!

Thought I nuked it for sure. lol.... you little trick worked well and now I can start to configure. Whew!!