Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

There is a Microsoft KB article that talks about best practices for running a DC on a VM. One of the notes is "Do not use the Export feature on a virtual machine that is running a domain controller". In order to export a VM, the VM needs to be turned off. If you turn off a DC VM, export it, import it on another server and then power the VM back on, there should be no risk as long as the original (exported) VM is never powered back on. Can someone explain to me why this isn't supported? After doing some searching on Google, the sites I found just regurgitated this line from the KB article, but didn't offer any explanation as to why this isn't supported.

share|improve this question
add comment

2 Answers

up vote 5 down vote accepted

The core of the issue lies around the way each domain controller is uniquely identified by the domain, and how domain information is replicated through the system.

It's vital that:

A) Each domain controller retain its own unique ID, unchanged, at all times. Operations that clone a DC or alter its SID will break this.

B) New DCs are only added to the domain via the DCPROMO process. The domain depends on the information that this process adds into the domain, to identify a DC on the network. Any operation which brings a machine online which appears to be a valid DC, but has not been uniquely promoted in the domain, is going to cause all kinds of headaches.

C) A DC is never restored to a point backwards-in-time. So no snapshots etc. This is because the domain relies on an increasing ticket number type system to identify changes to the domain. A DC reverted to a previous state will have a lower ticket ID while the domain is on a higher ticket ID. this gets you into the USN rollback scenario that Grizly described.

So summary: Running virtual DCs is possible but you must take extra care not to perform VM operations which will violate DC operational requirements.

share|improve this answer
1  
I don't see how there would be a USN rollback on a DC that's exported and imported. Exporting a VM doesn't change the SID, disk signatures, ect. Since the VM has to be turned off in order to export, there is no possibility of a USN rollback. This is why I'm trying to understand why this can't be done. Exporting a VM doesn't change anything because the VM setting are part of the export. If I were to just copy the VHD to another server and add it to Hyper-V, then the VM settings would be reset which could result in a USN rollback. But not when the VM is exported. –  AndyM Apr 9 '10 at 15:06
    
Good point. But then these are broad recommendations, and there are exceptions where you can perform some of the other 'dangerous' VM-related tasks on a DC without bad things happening. For example, reverting snapshots on a DC happens to work fine if it's the only DC in the domain. Perhaps it's just for brevity. –  Chris Thorpe Apr 11 '10 at 10:23
add comment

I think I found the KB you are referring to,http://technet.microsoft.com/sv-se/library/dd348452%28WS.10%29.aspx

All these recommendations are made to help avoid the possibility of an update sequence number (USN) rollback.

USN Info: http://technet.microsoft.com/sv-se/library/dd348479%28WS.10%29.aspx

share|improve this answer
add comment

Your Answer

 
discard

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.