My colleague (Alex Fontana – @AlexFontana_vmw) and I presented the “VAPP5618 – Virtualize Active Directory – The Right Way!” sessions at the 2013 VMworld Conference in San Francisco.
The focus of our presentation was to provide guidance for optimally virtualizing Windows Active Directory Domain Controllers on the vSphere platform. As expected, the main attraction was talking about (and demonstrating) how vSphere supports the newly-introduced VM-GenerationID features of Windows Server 2012 and Windows 8 (OK, so we didn’t mention Windows 8, not even once, but…. yeah). We received a number of questions during and after the sessions, and quite a few of them were very interesting enough that I thought they deserve to be revisited. So, here goes:
What happens when you clone a DC that is ALSO a FSMO role-holder?
Alex and I have spent a lot of time working on VM-GenID on vSphere and, honestly, this question was one that we actually never wondered about.
This was such a good one that Alex gifted a signed copy of his new book to the questioner, for creative stumping. We suspected that all the other FSMO roles are fair game because, in all our testing, validations and researches, we never came across any Microsoft material mentioning anything other than the RID Master and the PDC emulator (PDCe) roles being “special cases” in a DC cloning operation. While the PDCe is “special” only within the context of its being “available” during a cloning process, the RID Master is especially “special”. As far as actually knowing “what happens” if those roles themselves are present in the reference DC that is being cloned? As they say in our line of business …. THAT is a good question. And here is the, shall we say, “professional answer”: IT DEPENDS.
It’s a given that the PDC emulator role holder MUST be available in order for the cloning operation to complete successfully. Outside of this consideration, the DC cloning operation doesn’t appear to give a rat’s patootie about whether or not the PDCe is hosted on the reference DC.
The RID Master is different. Logic dictates that the RID master needs to be reachable in order for the new clone to obtain new set of RID Pool – after all, it had had to throw away the one it inherited from the reference DC because it had detected a change in its VM-GenerationID. That much we know. What we also know is that the RID Master doesn’t merely have to be “available” during the process. It CANNOT be present as a FSMO on the reference DC. It appears that the Microsoft “Obeah man” who conjured up “DC Safeguards” inserted a trip-wire somewhere in the cloning logic to actively defeat any attempt to clone a DC which holds the RID Master FSMO role.
So, in a nutshell, IF the source (reference) DC holds any of the FSMO roles other than the RID Master role, the roles are not cloned as part of the DC cloning process. And, they do not need to be excluded in the config files. The roles remain with the reference DC and are not automagically transferred to the new clone. The DC can be cloned to your heart’s content. Just don’t clone the DC holding the RID Master role as that will be an exercise in futility. What’s more interesting is that the cloning operation will APPEAR to succeed. The original RID Master will even tell you that the cloning completed successfully. It will be lying of course, because the new DC will end up in the DSRM jail and the Directory Service (and all other dependent services) will refuse to start. QED.
There’s a potential monkey wrench in cloning a PDCe role-holder, though. Since neither VMware nor Microsoft supports hot-cloning a Domain Controller (at this point), even with all the “safety” juju added into Windows Server 2012, you are required to shut down the reference DC before you clone it. Now, there is a checkbox in the “Clone VM” process in vSphere where you can have the new clone power on as soon as it is cloned. It looks like this:
IF you check that box (as seen in the image above), then the new clone DC will power on while the reference DC is still powered off. Now, because the powered-off DC holds the FSMO roles that are REQUIRED to be available during the DC clone operation, the DC cloning operation will fail and your new spawn will be booted into DSRM mode.
How do you escape from the DSRM jail? You can either follow this – Domain controller cloning fails and the server restarts in DSRM in Windows Server 2012 or you can simply discard this copy and perform the VM cloning again in vSphere, ensure that you don’t check the “Power on this virtual machine after creation” checkbox, power on the reference DC FIRST and make sure that it finishes booting BEFORE you power on the new clone.
Can you use one dccloneconfig.xml file to spawn off multiple DC clones?
This one is worth revisiting, not because it was a stumper, but simply because I feel like the “Yes, you can. And it is supported” response was insufficient. It was sufficient AT THE TIME, given the time constraints and the fact that this was a presentation and not a training. So, here is the fuller answer:
A change in the VM-GenerationID (GenID) of a virtual domain controller triggers a number of responses from the Operating System (OS). In vSphere, a clone operation WILL change the VM-GenerationID of the resultant clone VM and this new GenID is what the hypervisor will surface to the OS once the new clone boots up. Bear in mind that the original (reference DC) had a GenID value stored in its DIT file BEFORE it was cloned. Upon successful boot up, OS is able to determine that the stored GenID is different from the one that the hypervisor presents to it. At this point, the DC is required to reset its invocationID and discard its current RID Pool (bonus point at this juncture if you see why Microsoft doesn’t want you to be cloning the RID Master :)). This is the “safeguard” that you hear about so much when talking about GenID. Because the DC effectively has no identity and no passport to create objects, the old problem of USN re-use is avoided.
Still with me?
Now that the DC has been so neutered, the OS then tries to determine the appropriate next course of action. The availability of the dccloneconfig.xml is one of the things that the DC Cloning process checks for when making a decision as to whether or not a cloning operation should be initiated. So, if GenID has been changed AND a valid dccloneconfig.xml is found in the right place by the OS, the new VM will be taken through the process of cloning based on the values contained in the dccloneconfig.xml file. This file is what tells the cloning process what identity the new DC should assume. Here is a sample contents of a “standard” dccloneconfig.xml file
As you can see, we gave the new DC a name (“55-2K12-DC03”), an IP address, a DNS, etc. Here is the command that generated that xml file:
New-ADDCCloneConfigFile –Static –Ipv4Address “10.129.139.189” –Ipv4DNSResolver “10.129.139.190” –Ipv4SubnetMask “255.255.255.0” –CloneComputerName “55-2K12-DC03” –Ipv4DefaultGateway “10.129.139.253”
So, now we know how the dccloneconfig.xml file fits into the DC cloning operation. Let’s then go back and answer the original question – How do we create an army of clones using one dccloneconfig.xml file? Or, in other words, how can we simplify the DC cloning operation and not have to execute a “New-ADDCCloneConfigFile” command every time we need a new clone? Or, to put it in management-speak – how can we software-define our DC-baby-making factory?
If you look at the sample file and command above, you will notice some common attributes that are particular to THE clone DC that we INTEND to spawn – the “-CloneComputerName” and the “-Static -IPv4Address” (which could be “IPv6Address” if we are in an IPv6 environment). Those two switches are what we use for branding a spawn of DC.
To be able to re-use the same file over and over and over in multiple DC clone operations, all you need to do is NOT specify them in either your dccloneconfig.xml file or your “New-ADDCCloneConfigFile” command. IF those values are missing, the cloning operation will do the following:
No “-CloneComputerName”?
The cloning operation will assign a random computer name for the new DC. Well, not totally random. The name will be partly based on the name of the reference DC (the one that you have added to the “Cloneable Domain Controller” security group). This will be padded with “-CLxxx” where CL stands for “Clone” (duh) and xxx is a sequentially incrementing number from “001” through “999”. Got it?
Say your reference DC is (as in our example, “55-2K12-DC02”), the DC cloning process will assign the names “55-2K12-CL001”, “55-2K12-CL002”, “55-2K12-CL003”, “55-2K12-CL004”, “55-2K12-CL005” to the first 5 clones that you spin off from a copy of that dccloneconfig.xml file.
What about the IP?
It gets a little bit trickier (or ridiculously easier, depending on your perspectives) from here on. In order to create an assembly-line of DC clones, you will need a facility to automatically give the clones new VALID IP addresses. That is called DHCP. You will have to make sure that you are provisioning the clones into an infrastructure where DHCP is available and confirmed to be functional. As previously mentioned, the clones will need to be able to reach the RID Master (to obtain a new stash of RIDs) and the PDCe in order for the clone operation to succeed. Of course, it also needs to be able to resolve names across the board – this is why it is always a good idea to hard-code the DNS server IP(s) into the dccloneconfig.xml file, even when doing mass clonage. If the reference DC is a DNS server, the new clone will inherit that role. However, the DNS service is disabled on the new clone during the cloning process, so you better make sure that it is able to reach an operational DNS server throughout the process.
Here is an example of a dccloneconfig.xml file for inducing a massive gestation of Domain Controllers:
Here is the “New-ADDCCloneConfigFile” command that generated that file:
New-ADDCCloneConfigFile –Ipv4DNSResolver “10.129.139.190, 10.129.139.191”
Putting it all together:
To create a re-useable clone of a reference domain controller for the purpose of deploying multiple clones from that single configuration, or to be able to perform on-demand DC cloning operation without having to repeatedly prep the reference DC, you do the following:
- Follow all required DC-preparation steps (add source DC to “Cloneable DC” group, create “excluded application list”, etc, etc)
- Create a dccloneconfig.xml file that does NOT include the “-CloneComputerName” or the “–Static –Ipv4Address” switches
- Shut down the reference DC and clone the VM
- IF the reference DC is ALSO the PDCe, power on the reference DC immediately after you finish the VM cloning operation in vSphere – BEFORE you power on the new clone VM.
- Make a clone of the new VM BEFORE you power it on, just for safe-keeping. Once you power on the VM, you will not be able to make valid copy of it again without going through the preparation steps discussed above. This is because the dccloneconfig.xml file is automatically renamed as soon as Windows starts. This is a “safety net” measure to prevent unintended spawning and proliferation of bastard Domain Controllers in an enterprise.
- Convert the clone into a template.
- Deploy your new army of DCs from this template henceforth (see “caveats” below)
- Open a DC-as-a-Service operation. Go IPO. Have fun
Caveats
You knew those were coming, no?
- Mass-producing DC clones is not much different from mass-producing other …. stuff. The output tend to look alike. So, in your case, you will not be able to control the names of your resultant Domain Controllers. They will be named “-CLxxx” and you will have to invest additional administrative effort to correct them individually if the names distress you.
- The re-usable clone is only as good as the Tombstone Lifetime value of the domain.
- At least the PDCe in the domain of the reference DC MUST be on running Windows Server 2012.
- You can’t mass-produce DCs IF your DHCP server is not functional. You may even end up causing either your reference DC or the new clone to go into DSRM – because the clone will be using the reference DC’s IP address and “Safeguard” will detect an IP address conflict and go bonkers and start throwing chairs and …. stuff
- Mass production will require you to leave the reference DC in the “Cloneable Domain Controllers” security group for the duration of the mass production. This is against best practices. This group is expected to be populated on an as-needed basis. If your intention is to “make things easy”, you may end up making things too easy and quite disruptive. You want your Domain Admin to be consulted before a new DC is spawn. You want the action of adding the reference DC to the security group to be a conscious decision.
- When cloning a reference Domain Controller VM in vSphere, ALWAYS choose “Do Not Customize” option (the default, shown below) for the resultant VM. Performing Guest Customization (aka “Sysprep”) interferes with the DC Cloning process.
