It’s a bizarre blog title I know, but I was in the process of trying to spin up Exchange 2013 in a test environment with Exchange 2010 already existing and found that none of the services across any of these 3 servers would start. So the following details my day’s worth of diving into resolving this, and how quick/easy it was in the end. No fun pictures or how to’s this time, just some useful troubleshooting commands and concepts 🙂

First I looked in the Application event log. The MSExchangeADAccess event logs would return Error 2120 (ERROR_TIMEOUT) or Error 2014 (LDAP_SERVER_DOWN).
I tried the standard netdom /resetpwd /s:<dcname> /ud:domain\User /pd:* on the machines in question with no change (Note: full command details at: http://support.microsoft.com/kb/325850)
Then I used the nltest /SC_QUERY:<domain> command, which came back saying the domain didn’t exist
Another great command that you can use via Powershell, Test-ComputerSecureChannel -server <dcname>, also came back saying the domain didn’t exist.

I checked the lastlogon & lastlogontimestamp attributes of these “problem” servers in AD – all showed 4 months before today – even with a reboot of the server. And of course the netdom /resetpwd registers properly in the pwdLastSet attribute in AD – but does me no good.

Then I became concerned it was the actual domain controller not correctly handing out Kerberos tickets or renewing the computer password accounts. I went as far as to reset the domain controller password against another working one using the netdom /resetpwd commands and other steps in Method 6 at http://support.microsoft.com/kb/837513 with no luck.

But in stepping back and seeing of the 12 VMs in my environment 8 of them (most of which were recently built) had no problems, so I gave in to the notion that these older VMs must have had some hiccup when I was dealing with tombstoning from when a former counterpart built the environment and didn’t keep an eye on things.

I then stumled across this blog post:
http://smtp25.blogspot.com/2007/10/what-happens-when-computer-account-for_8054.html

In a production environment who in their right mind would disjoin a computer with an AD-tied role from the domain, reset the computer account, and join it back to resolve the problem? Well, it works for workstations, so why not servers – even if they are running Exchange 🙂

After working thru the apprehension, I had nothing to lose and did just this.

Guess what? Everything started working again. So while I’m still somewhat baffled on what would have caused this issues, nonetheless I had to admin – THIS WORKS!!!!!