Exchange 2010 Server - Domain Trust Relationship Failed

Resolving Exchange Login Issues Due to a Domain Relationship Trust Failure


For many years now, I've used virtual machines quite extensively to build out both production and full development environments, and most of the time it has served me well. There are however, a few occasions, where this virtualization I've come to depend on so heavily, has ended up causing me to lose sleep. In all fairness, there's usually only a naughty administrator to blame.

Snapshots can save quite a bit of time, and make it easier and cleaner to recover from unexpected issues, or configuration mistakes. In many ways, it's akin to reloading a Cisco router without saving the running-config to the startup-config. It can be a life saver when used properly, but there's another side to the story, especially when you're working within a virtualized Active Directory environment.

The Problem

Today, I find myself, for the second time in the past year, staring at an error message on the login screen to my development Exchange 2010 server, telling me I can't login, because the domain trust is broken.

"The trust relationship between this workstation and the primary domain failed."

Most of the information online regarding this article gives you the simple fix, which we all know and dread to hear. Remove the computer from the domain, reboot, remove the machine account from AD, then re-join the domain. (http://support.microsoft.com/kb/162797) It's quick and simple enough, and works... most of the time, but what if you're not talking about a workstation. What if this is your Exchange server, as it is in my case, or SQL, or pretty much any Microsoft server product, which depends on a domain & can not be removed without having to uninstall the server software?

The Solution

The solution is actually pretty easy, assuming you are able to login to the server with a local Administrator account.

  1. Log in to the impacted server with a local administrator account. (You do have your local admin account password right?)
  2. Launch a command window using the Run As Administrator option.
  3. From the command prompt, run:
>netdom resetpwd /s:DC.domain.com /ud:domain\Administrator /pd:"password"


  • /s = FQDN of the domain controller running the PDC Emulator Service.
  • /ud = Domain Administrator Account
  • /pd = Passord for the Domain Administrator Account
Restart your server, and log in using your domain account to verify all the services started properly.

This solution will work with many Windows 2003 and Windows 2008 servers. For Windows 2003 servers, you may need to install the Support Tools from your installation media.

If you need to reset the machine account password for a domain controller, you must first stop the Kerberos Key Distribution Center service on all domain controllers, except your Global Catalog, then remove the Kerberos ticket cache on the domain controller where you receive the errors by rebooting. (Optionally there are a number of utilities you can use, such as KLIST, Kerbtest, or KerbTray, instead of rebooting, however use of these tools are beyond the scope of this article.)


Troubleshooting

When running NETDOM, you might receive an error such as:

The machine account password for the local machine could not be reset.
Logon Failure: The target account name is incorrect.
The command failed to complete successfully.

If you received the error message above, verify the server name, user name and password. If your password is complex, try wrapping it in quotes " ". You may also want to try using a different domain controller. (It should be the one where KDC is running.)



Windows 2008 R2 Server, Exchange 2010 Server, NETDOM, Windows 2003 Server, VMWare, Virtualization, Active Directory, Domain Trust

2 comments :

  1. Thank you very much for sharing this information! My Exchange 2010 was restored from Acronis backup because of failed SP2 Rollup 6. After recovering it produced the mentioned error. Using your post I successfully solved it.
    A small hint for those who experience the same problem: please note that "/s:server.domain.name.com" means DC name, not Exchange server name.

    ReplyDelete
  2. Thank you for the feedback Sergei. I re-read the post after your comment and was able to see how this could be unclear to those who have not used this command before, so I added some clearification about the input for each switch.

    ReplyDelete