Overcoming common issues when installing Exchange 2013 Preview

Every new version of Exchange brings its own tweaks and peculiarities for the installation process. Exchange 2013 Preview is no different. For one thing, its progress is as slow as a wet week in a caravan on the west coast of Ireland. Of course, this is based on perception and we all know how accurate a gauge that is. My feeling is that Exchange 2013 installs a lot slower than its predecessors, but perhaps that’s due to the hypnotic effect of looking at the stark installation GUI now mandated by the Microsoft style gurus. I’m sure that Microsoft will speed up the installation procedure before Exchange 2013 finally ships. At least, I sure hope that they do.

Slowly, slowly, slowly, the Exchange 2013 Preview installation procedure works away

In any case, Exchange 2013 Preview has been “in the wild” for about six weeks and there seems to be many instances of people running into problems installing the software, especially in a test forest that’s been used to host previous versions. Microsoft doesn’t yet support the deployment of Exchange 2013 into an existing Exchange 2007 or Exchange 2010 organization (forget about Exchange 2003, these servers will not be supported alongside Exchange 2013), so an installation into a test forest is necessary if you want to gain an insight into what’s coming down the tracks. Here are three of the most common problems and how to solve them. See my post on WindowsITPro.com for more details on how to install Exchange 2013 Preview, including how to apply the Active Directory schema update that’s required to support the new features included in Exchange 2013.

The first, and most fundamental thing to get right, is to install all of the prerequisite software, from .NET Framework 4.5 to Microsoft Management Framework, the Office Filter 2.0 kit and its SP1 update, and various hot fixes specified by the Exchange developers. You also have to make sure that servers are updated with all the Windows features that Exchange 2013 requires. Make sure that you follow the order of installation described in the Exchange 2013 On-Premises Help file.

The next issue only occurs if you receive a non-public beta release of Exchange from the development group. For instance, as a customer or other third party who participate in Microsoft’s Technology Adoption Program (TAP), a program that the Exchange development group makes extensive use of in order to ensure that the product receives real-life use over a sustained period during its development, something that can only be deemed to be a very good thing.

Non-public betas don’t go though the same kind of full release cycle as public betas and it’s common to find people forgetting to run the “strong name tool” (sn.exe). In this instance, the “strong name” refers to a combination of elements (text name, version number, a public key, and digital signature) that Windows can use to validate that the code is valid and acceptable to run.  You have to run sn.exe on servers that support non-public Exchange 2013 beta code to indicate that it’s OK to run its binaries without verification as otherwise installations are likely to fail due to “unhandled exceptions”. Letting code run without proper checks is not a step that you should ever take on a production server, but it’s OK here. The correct command is:

Sn.exe –Vr *

Running the strong name tool

Based on a quick survey of online forums, it seems that the most common issue encountered when installing Exchange 2013 Preview is when Setup solemnly reports “Couldn’t find the Enterprise Organization container”. Examining the setup log (c:\ExchangeSetupLogs\ExchangeSetup.log)reveals that this error is provoked after setup attempts to validate the state of Active Directory and that blank values are apparently returned for the domain controller and global catalog server chosen for the installation. The same message is issued if you run Setup in command-line mode or use the GUI; it’s issued whether you attempt to install the schema update, prepare Active Directory, or install the first server in an organization. In other words, Setup is emphatic that it cannot proceed. End of story.

Anything to do with an Active Directory problem is likely to make an administrator break out in a cold sweat. Or at least seek consolation in a cold drink, preferably containing some alcohol (if you have that bad habit). In fact, the problem is usually caused by Setup detecting some lingering artefact of a previous Exchange deployment, such as the presence of the Microsoft Exchange System Objects OU in Active Directory. Setup doesn’t seem to have a specific test for this circumstance or the error message that it generates is so opaque that it covers a whole range of problems that an installation might encounter. The solution is to make sure that any traces of previous Exchange deployments are eradicated before you attempt to install Exchange 2013.

Of course, there’s no formally documented and approved method to eradicate Exchange from an Active Directory forest so a fair amount of pruning is necessary with ADSIEdit to eliminate all of the various configuration data that Exchange stuffs in Active Directory. As each version of Exchange goes by, the task gets a little harder because Exchange stores more and more information in Active Directory. Generally this is a very good thing because it means that Exchange isn’t stuffing settings into the system registry or other server-specific files, such as the XML configuration files used to control the transport subsystem. So some care and attention is required to go through Active Directory to track down and remove everything that belongs to a previous version of Exchange, including system and arbitration mailboxes, before you can install Exchange 2013.

Assuming that you manage to install the pre-requisite software, run the strong name tool, and update the Active Directory schema, you should find that the installation of Exchange 2013 proceeds smoothly (if slowly) to a successful conclusion.

Good luck!

Follow Tony @12Knocksinna