What to do on a lazy Saturday afternoon? Ah, let’s go and update some Exchange 2013 servers with a new build. Just the thing to do so as to be able to avoid the plaintive cries of “the grass needs to be cut” or “that hedge needs trimming.”

So off I go to reacquaint myself with my good friend Setup,cmd. Of course, I’m only upgrading some virtual servers that I use for lab work here – upgrading production servers on a whim, even if it is to avoid any element of gardening, is not recommended.

All goes well initially, until I notice that my domain controller has announced that it is about to reboot itself following some critical updates. “No worry.” you say, “pause the reboot.” Until that is you notice that Microsoft has not provided Windows 2012 Server with a convenient button to stop a server rebooting itself. And searching the Internet for a solution isn’t a great answer either because a) by the time you’ve found a solution, the server will have rebooted itself and b) most of the pages that I found (like this one) indicate that an attempt to stop a reboot will probably fail.

The problem here is not really the reboot. After all, the reboot will do some good as files that cannot be replaced when the server is running will be moved into place post reboot. All manner of bugs will be fixed and I should be a happier camper. Unless you’re updating an Exchange server because the Exchange installation program is extraordinarily fond of consulting Active Directory for anything and everything. This is understandable to a point because Exchange stuffs away lots of configuration data in Active Directory. Nevertheless, a casual browse of an Exchange setup log post-installation will show that the installation just loves to chat with Active Directory.

I don’t have a problem with the installation program communicating with Active Directory, as long as Active Directory is available. On the other hand, if the one and only domain controller has been taken offline by the need of the server to reboot itself, all manner of bad things can happen to an Exchange installation. It’s not good when Exchange attempts to contact Active Directory only to be met with a void. The installation program doesn’t like that – at all.

Fortunately, the reboot happened right at the point when the installation program is least likely to want to reach out and connect to a domain controller – the “Copying Exchange Files” phase. The domain controller came back online after the reboot and was available when Exchange next needed to communicate with Active Directory, so all was well.

This experience added yet another thing to the list of things that should be done before embarking on an Exchange update – to make sure that servers won’t be rebooted automatically during the update.

No damage was caused (except to my blood pressure). All servers were upgraded smoothly. On to the next update – after checking for imminent reboots of course!

Follow Tony @12Knocksinna