Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I am wondering if anyone else has done this and has subsequently ran into any problems or if based on what I describe, anyone could suggest types of problems I may run into:

I have Windows 2008 R2 Datacenter as my Hyper-v host and a Windows 2008 R2 Ent guest VM running on it.

Prior to a major update,I had saved a copy of the VHD file of the guest (this was the C: drive on the guest VM). This was not a snapshot, just a copy/paste of the VHD file.

Upon some difficulties and frustrations with SQL Server 2012 Upgrade I had decided to forgo troubleshooting (I had a short maintenance window to work with) - and instead stopped the VM. Then changed the VHD file to the previous copy I had saved earlier.

The VM booted but was not recognized by the Domain Controller. I removed and re-added it to the domain and afterwards no major issues. I completed my upgrade without previous issues & installed Windows Updates also without a problem.

Is this considered bad practice? Can I keep this VM as is, or do I need to rebuild from scratch to avoid anomalies with the OS? If you were a lead sysadmin & this was a production box, would you allow it? Thank you

share|improve this question
Please specify exactly what you mean by "not recognized by the Domain Controller" (specific log entry/Event ID, if available). I'm pretty sure I know what you're seeing, and that it's generally safe to leave your VM running after rejoining to the domain, but best to make sure before saying that and all. – HopelessN00b Jul 20 '12 at 15:13
I got an error when trying to login - "Trust Relationship Between Workstation and Domain Fails" and followed these steps: (ie: Logged in as local admin, removed OS from domain, restarted, then added it back to domain) Link: – Dina Jul 20 '12 at 15:19
That's what I thought. You're good, and probably safe. The problem is that the domain recognized the backup as a different machine, and rejected its attempt to authenticate itself as the "other" machine, with the same name. Unless your backup is out of date, or you run any security that needs to reference the original/previous machine GIUD, you won't have any problems. (But it is what I'd consider "bad practice.") I'll punch up an answer for you shortly. – HopelessN00b Jul 20 '12 at 15:22
Thanks! I figured it was not designed to be used this way - but I would love to know more about why it's considered bad practice. Which would tell me what I may need to be aware of, if I leave this VM as is. Thanks – Dina Jul 20 '12 at 15:34
up vote 1 down vote accepted

First of all, some basic concepts about Windows machines/domains you need to know (and may or may not already know):

  1. Computers are security principals just like users

  2. Names are just human-friendly references to an underlying SID

  3. Computers authenticate to the domain on startup

  4. Computers accounts have password too (that change every 30 days by default)

Basically, what happened when you jammed the old VHD in your machine is (I'm betting), the local password for the computer account failed to match the password the DC had for the computer account, because the password got changed sometime between the backup you did and the time you restored it. As a result, the Domain Controller wouldn't let the computer authenticate, and the error you see is a failed trust relationship.

This relies on an assumption or two, most notably that your backup and the machine that failed didn't have different SIDs, which will also break the domain trust. That commonly happens when you rename a computer or join a computer to a domain with the same name as an existing account. The newly renamed computer will try to authenticate with its new SID, but the name maps to the old SID, so when AD checks, the SIDs don't match and the authentication fails.

So either way, you basically broke authentication between your VM and the domain when you "restored" the old backup. I trust you can see why that's bad. (It's less bad if it was just the machine password, and not a different SID, which is worth mentioning.)

Why it's "bad practice" to do as you did is subjective and will get different answers (or different specific concerns) from different admins, but my answer would basically be that it's bad practice because there's a better way to do it that doesn't break domain authentication or add complexity and unknowns into the mix. (How old was the backup? What changed on the system between then and now? What's relying on those changes that could break or cause monstrously difficult to troubleshoot issues? etc.) It's also bad practice because it sounds like you don't have actual, effective backups, or a quick process to restore from [a real] backup if/when needed. That's very bad, for reasons I hope you don't need clarification on.

Having said all that, it sounds like you're relatively safe. (Assuming, of course, the old backup isn't missing a bunch of SQL data, or has an older version of something installed, or anything basic like that.) The different computer account password won't be referenced anywhere, and generally your computer's full SID isn't going be referenced by much outside of AD either, so changing it shouldn't cause problems. (But like any admin who's been around the block once or twice, I've seen stuff that would make your blood curdle and results in my qualifying what would otherwise be absolute statements.)

Hope that's helpful.

share|improve this answer
Doesn't seem like anyone else raised concerns other than the ones you did. I'm hoping it is not because the question didn't get noticed. – Dina Jul 23 '12 at 13:21

Domain members sync domain membership credentials periodically. When a system is offline for an extended period the domain no longer recognizes the systems credentials. As long as you don't rename the system you can rejoin the domain without issue note you can also try NLTEST /SC_RESET:domain_name\DC_name rather than rejoin the domain

share|improve this answer

The problem is doing that with a domain controller. It has a database with unique numbers which are shared and kept in sync with the other domain controllers. Suddenly reverting one of them to the old out of sync numbers is a bad idea.

Edit: Maybe I was a bit brief. Let me add three more things:

  1. Because the only case in which you would restore a domain controller from the backup image is when all domain controllers have been lost, authoritative restores should not be needed. Source: Microsoft technet.
  2. A database often has specific needs. If it is a DB with significant use then you want to tune the whole server to it. This includes CPU, RAM (RAM size vs actively used dataset) and drives. (See the SF canonical answer on RAID for the last part. I seem to be referencing that quite a lot lately).
  3. A domain controller does not need much, but you want it snappy. The slowest new server you can buy atm will do just fine, but try running it as sole task on a server. Even if you need to buy a new server for that. Other servers might reboot or go down, but in a ms network you want at least one DC which has the resources to respond quickly.
share|improve this answer
Sorry I should have been more specific. The guest was not a DC. It had problems initially with connecting to the DC. – Dina Jul 20 '12 at 15:09
Ah. I'll wait a bit (so you can read this) then delete my answer since it now is not relevant anymore. – Hennes Jul 20 '12 at 15:12
It's still interesting :) and relevant. I believe you should it leave it here. – Dina Jul 20 '12 at 15:21

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.