Testing the New Windows Server 2012 GenerationID, DC Cloning and

VMware Confidential

Testing the New Windows Server 2012 GenerationID, DC Cloning and DC Safeguards Features on vSphere

Deji Akomolafe

Consulting Architect

Business Critical Applications Practice

VMware Professional Services

Version History

Date Ver. Author Description Reviewers

July 1, 2012 v1.0 Deji Akomolafe Testing the New Windows Server 2012 GenerationID, DC Cloning and DC Safeguards Features on vSphere

© 2010 VMware, Inc. All rights reserved. This product is protected by U.S. and international copyright and intellectual property laws. This product is covered by one or more patents listed at http://www.vmware.com/download/patents.html.

VMware, the VMware “boxes” logo and design, Virtual SMP and VMotion are registered trademarks or trademarks of VMware, Inc. in the United States and/or other jurisdictions. All other marks and names mentioned herein may be trademarks of their respective companies.

VMware, Inc 3401 Hillview Ave Palo Alto, CA 94304 www.vmware.com

http://www.vmware.com/download/patents.html

http://www.vmware.com/


Contents

1. INTRODUCTION ......................................................................... 4

2. PROCESS OVERVIEW ............................................................... 4

3. PERFORMING THE TESTS ........................................................ 5

3.1 How to Test Domain Controller Safeguards Feature on vSphere .................................5

3.2 How to Test Domain Controller Cloning Feature on vSphere. ......................................5

3.3 BEHIND THE SCENE - CHECK THE EVENT LOGS .................................................11


1. INTRODUCTION

The following document is intended to document the steps necessary to configure and validate the functionalities of the newly introduced GenerationID attribute (msDS-GenerationID) in Windows Server 2012 and Windows 8 clients virtualized on the VMware vSphere platform. This document does NOT address detailed functionalities of the Windows Directory Services, except where general references are necessary for our vSphere-focused discussion. Consequently, detailed AD functionalities or replication mechanisms are not provided in this document.

The Microsoft Windows Active Directory uses a distributed database structure in which any Domain Controller (DC) can originate and commit changes to the database (with some technical exceptions – e.g. RODC – which are not the focus of this document.

Because this database is a shared repository, updates to the database are eventually replicated to other DCs in the infrastructure. Where all authorized DCs have learnt of changes in the directory, convergence is said to have occurred. Each DC uses a combination of its own unique identity of the database copy it has (InvocationID) and the Update Sequence Number (USN) given to EVERY transaction originating from that DC. The two elements are what make a write-operation performed on that DC to be unique in the infrastructure. No two write operation will have the same unique identifier within a given Active Directory repository. The Directory Services itself uses this identifier to determine which changes should be replicated to other DCs in the infrastructure.

The situation discussed above is what makes the Domain Controller a “special” computer on the network. Anything that interferes with the DC’s normal state can cause Domain-wide (or even Forest-wide) corruption of the Active Directory infrastructure, requiring expensive administrative intervention to repair – sometimes even resulting in a fatal damage to the whole infrastructure.

Because of the nature of virtualization, the potentials for unintended (or even willful) corruption of the directory are greater than in the physical instances. For example, it is very easy to take snapshot a DC and to restore that DC to a previous state in a virtual environment – even when there is explicit corporate policy against doing so. This action will result in a “USN Rollback” situation – the “corrupted state” referred to in the previous paragraph.

These considerations present great (and grave) challenges to Windows administrators, the effect of which is a great reluctance by such administrators to virtualize their Domain Controllers, or do so with any measure of confidence and sense of security.

To address these concerns, Microsoft has introduced a feature into Windows Directory Services called “Domain Controller Safeguards”. In brief, the feature is based on the following logic:

Accidents happen

Accidents have greater chances of happening in a virtual environment

When they happen, the Directory Services SHOULD be able to protect itself

The protection should involve the Directory Services taking corrective actions against the accident

The Hypervisor SHOULD enable the Directory Services to do this by exposing a new identifier called “VM-

Generation ID” to the Windows Server 2012 or windows 8 VM hosted on that hypervisor.

This is where the VMware vSphere comes into the picture. Newer versions of vSphere will have the ability to expose GenerationID to VMs running these two Operating Systems. The GenerationID, once exposed to the VM, can then be leveraged by the OS to accomplish several objectives. We are going to discuss ONLY the following two possible uses in this document:

Domain Controller Safeguards

Domain Controller Cloning.

2. PROCESS OVERVIEW

Here is a brief discussion of how GenerationID is used to achieve its objectives in a vSphere infrastructure:

On the vSphere platform, GenerationID is represented as a counter with a 128-bit value in a Windows Server

2012 or Windows 8 VM’s memory. This value is written to the VM’s vmx file as a new “vm.genid” variable.

Windows detects the physical address of the counter by looking at the VMware ACPI tables.


This entry is represented as “Microsoft Hyper-V Generation Counter” in Device Manager and can be read by the

OS in its address space.

When a Windows Server 2012 is promoted to a Domain Controller, the value of this GenerationID is read and

stored in Directory Service (DS) as a value for DC’s the “msDS-GenerationID” attribute in its copy of the database

(or DIT), which is then subsequently replicated to other replication partners.

This value is expected to remain the same for the life of the VM/DC. The value is expected to change only under

very specific conditions that will be documented in the applicable KBs when available.

Whenever the DC now processes/initiates any transaction in the Domain/Forest, the value of the DC’s Generation

ID at the time of this operation will be compared to the value stored in the DIT.

Additionally, every time the DC is rebooted and comes back online, its current GenerationID at that time is

compared to the value in the DIT.

If these don’t match, the VM/DC is assumed to have undergone some changes outside of the DS (perhaps, the

VM has been rolled to a previous state by snapshot).

Because vSphere is the authoritative source of the value of GenerationID, the DS does not try to figure out what

happened. It concludes that vSphere is telling it that this VM is no longer the VM it was.

At this point, the following “safeguard” steps are taken by DS to protect itself and correct the VM/DC in question:

o The DC is immediately prevented from updating the DS

o The DC’s invocationID is automatically reset

o The DC is forced to discard its current RID pool and obtain a new pool of RIDs

o The DC is then able to update its GenerationID to the new value in the DIT.

This is how a Windows Server 2012 achieves the “Domain Controller Safeguards” when virtualized on VMware vSphere.

NOTE: The DC Cloning feature of Windows Server 2012 is achieved using the same logic described above. The ONLY difference between the “DC Cloning” operation and the “DC Safeguards” feature is in the amount of upfront preparation that you MUST complete BEFORE DC Cloning can succeed. I will briefly describe the DC Safeguard operation on vSphere first and then provide a detailed description of the DC Cloning operation because that involves more steps.

3. PERFORMING THE TESTS

3.1 How to Test Domain Controller Safeguards Feature on vSphere

For DC Safeguards, the only thing that has to happen is for the personality of the VM to change in any significant way that ALSO changes the value of “vm.genid” in the vmx file. The two most common scenarios are:

VM Clone operation in vSphere Client – simply create a clone of the Windows 8 or Windows Server 2012 VM.

This is sufficient to change the value of “vm.genid”

Snapshot rollback on the VM -take a snapshot, then go back to a previous state instead of doing a “delete” or

“delete all”)

Copy the VMDK files of a VM and use these to create another VM

3.2 How to Test Domain Controller Cloning Feature on vSphere.

NOTE: The following instructions assume that you are performing these steps using a vSphere Client connected to an appropriate versions (or builds) of a vCenter/vSphere pair that have been certified to support the “VM Generation ID” feature.

CHECK FOR APPROPRIATE vSPHERE VERSION


NOTE: In addition to the use of changes in GenerationID value as a trigger, the DC Cloning operation also uses the presence of two specific XML files as input for completing the cloning operation. These files are located in the %windir%\NTDS folder (there is more to this, but we are intentionally keeping things minimal in this document). If DS detects a GenerationID change on a DC but does not see these two files on the DC in question, the DC will be actively prevented from participating in AD DS and will, instead, be quarantined into a Directory Service Restore Mode (DSRM).

While you can manually create these files using a simple text editor, we will use the built-in Powershell cmdlets for our exercise.

3.2.1 STEPS

Create at least two (2) Windows Server 2012 VMs.

Promote these VMs to Domain Controllers (we are going to call them W2K12-DC01 and W2K12-DC02). If these DCs are part of an existing AD infrastructure, you MUST transfer the PDC Emulator FSMO role to W2K12-DC01 for the purpose of this exercise.

NOTE: For our purposes, we will assume that W2K12-DC01 is the first DC you promoted to a Domain Controller in the infrastructure.

We will also assume that W2K12-DC02 is the second DC promoted. Do NOT transfer any FSMO role to W2K12-DC02. Specifically, W2K12-DC02 MUST not be the PDC Emulator FSMO role holder.

VERIFY THAT GENERATION-ID IS EXPOSED

Log into the DCs and verify that you see the items highlighted in the image below (you may need to reboot the VMs at least twice in order to see the msDS-GenerationID value:


After successfully verifying the above, you are ready to proceed.

ADD REFERENCE DC TO AD GROUP

Next, using Active Directory Users and Computers (or the Windows Powershell), add W2K12-DC02 to the “Cloneable Domain Controllers Group” as shown below:

CREATE THE EXCLUSION LIST FILE

Launch a Windows Powershell console with elevated privilege (Runas Administrator) and enter the following command: Get-ADDCCloningExcludedApplicationList –GenerateXml

You should get the response shown in the image below:


NOTE: What this command does is search for services and applications that can be safely cloned, automatically add

these to a file named “CustomDCCloneAllowList.xml “ in the %windir%\NTDS folder and make a recommendation for the

removal of those that are either not cloneable, are not default Windows services or programs or are not included in the DefaultDCCloneAllowList.xml. If you have added any non-cloneable service or programs to W2K12-DC02, the command will

report them and you MUST add these to the “CustomDCCloneAllowList.xml” file if you want them to be part of the cloning process. If you don’t do this, the cloning operation will fail.

The default programs and services included in VMware Tools are safe to clone and they are included in the CustomDCCloneAllowList.xml file created by the above command.

A sample of “CustomDCCloneAllowList.xml” is shown in the image below.

If the Get-ADDCCloningExcludedApplicationList command reports no exception, you are ready to proceed.

CREATE THE CONFIG FILE:

During the DC cloning operation, the new DC requires at least the following configuration information:

Computer name


TCP/IP information

This information is stored in the second xml file that we mentioned above. The filename is “DCCloneConfig.xml” which

should also be placed in the %windir%\NTDS folder. The format for the information contained in the file is shown below:

NOTE:<ComputerName> tells the cloning process what the name of the new DC should be. If this value is empty, the cloning process will use the name of the reference DC and append “-CLxxxx” to it to make a name for the new DC. If you plan to create multiple clone copies of the reference DC, then you MUST leave the value in <ComputerName></ComputerName> empty.

The <IPv4Settings> block is self-explanatory. If you want the new DC to obtain its IP address from a DHCP server, this block should be empty. The cloning process also supports IPv6, but that is beyond our discussion here.

VERY IMPORTANT: IF you are using a DHCP server, make sure that the DNS servers configured in the DHCP scope know about the Windows 2012 Domain that this cloned DC will be part of. The cloned operation REQUIRES that the PDC Emulator for this domain be reachable during the entire process.

As before, you can create this file by hand, or you can use the PowerShell cmdlet as shown below:

Launch Powershell with elevated privilege and type in the following command: o To make a clone DC that will have the NetBIOS name “W2K12-DC03” and other specific TCP/IP

configurations, use this command: New-ADDCCloneConfigFile –Static –Ipv4Address “192.168.11.42” –Ipv4DNSResolver “192.168.11.40” –Ipv4SubnetMask “255.255.255.0” –CloneComputerName “W2K12-DC03” –Ipv4DefaultGateway “192.168.11.1”

o If you plan to clone the reference DC multiple times and deploy multiple DCs from it, then you need to prepare it for “generic cloning”. Use the following command: New-ADDCCloneConfigFile –Ipv4DNSResolver “192.168.11.40” – This will create a Config file that has just the IP address of a DNS server that knows about this domain.

o To use multiple DNS server, the command should look like this: New-ADDCCloneConfigFile –Ipv4DNSResolver “192.168.11.40, 192.168.11.41, 192.168.11.150”

Any one of the commands above will produce an output similar to the one shown below:


This image is self-explanatory, so I will skip a description.

NOTE: If you don’t like the output of the file generated in the previous step, you must delete the xml file before you can

successfully execute the command again. If you run the command while there is an existing copy of the file in the NTDS folder, you will receive an error similar to the one below:

SHUT DOWN W2K12-DC02

We need to shut down the reference DC now for cloning.

CLONE W2K12-DC02

Using the vSphere Client, create as much clones of W2K12-DC02 as you will need before you power it back on.

NOTE: Windows Server 2012 has a security measure to prevent unintended DC cloning. If you power on W2K12-DC02, the “DCCloneConfig.xml” that you created in the previous step will be automatically renamed to something like this: “DCCloneConfig-date-and-time.xml”. If you make a clone of this DC and, instead of finding a “DCCloneConfig.xml”, the DC cloning process finds a “DCCloneConfig-date-and-time.xml”, the cloning operation will fail.

POWER ON BOTH W2K12-DC02 AND THE NEW CLONE


Once you have finished creating as much clones as you want, you are now ready to power on the reference DC as well as the clone. The reference DC does not need to be online for the cloning operation to succeed, it is a good idea to not leave it powered off for too long.

The new clone will boot up and you should see something similar to the one in the image below:

The new DC will reboot multiple times during the cloning process.

Upon completion, you should see an additional DC in the domain. The image below shows two additional DCs cloned into the domain, using each of the two types of “DCCloneConfig.xml” files we described above.

3.3 BEHIND THE SCENE - CHECK THE EVENT LOGS

To get a sense of what went on behind the scene during this process, examine the following event logs on both the new DC and the PDC Emulator:





Documents

Testing the New Windows Server 2012 GenerationID, DC Cloning and