Virtualization Updates to Active Directory 2012

As part of the many updates to Active Directory, one of the most interesting is virtualization safeguarding in Windows Server 2012.

Active Directory Domain Controllers running Windows Server 2012 can now identify if they are virtualized and have been improperly restored or cloned (copied). Windows Server 2012 introduces a new feature called the VM Generation ID which is used to track the virtual machine (VM) on which the OS is running. When a new VM is created in a hypervisor that supports the feature (Hyper-V 2012 & VMWare vSphere 5.1), a VM Generation ID is created by the hypervisor and associated with the VM as the unique VM guest identifier. The VM Generation ID is a 128-bit cryptographically random  integer that changes when the VM’s configuration file changes. The virtual machine’s BIOS provides the VM Generation ID to the OS in an 8-byte aligned buffer in guest RAM, ROM, or device memory space which can be queried via ACPI namspace with a compatible ID of “VM Gen Counter” (also a DOS Device Name of “VM_Gen_Counter”. When the generation ID changes, there is an ACPI Notify operation on the generation ID device ID device using notification code 0x80 (an ACPI GPE can triger this notification).

Each Domain Controller has a unique identifier called the Invocation ID for the Active Directory database instance on that DC. When a DC is backed up and restored, the Invocation ID changes. Each DC tracks changes it makes to its local AD database, NTDS.dit, using an incremental counter called the Update Sequence Number (USN). Active Directory replication leverages a combination of the InvocationID and the USN in order to determine what data a DC requests from other DCs. The USN normally only increases in value; however, there are circumstances where a “USN rollback” occurs such as when a DC’s VM snapshot is restored. With a USN roollback, the DC is improperly restored to a point in time “rolling back” the USN to a previous value. The DC doesn’t have AD data that other DCs have and believe that it has (for more information, read my article on the subject: USN rollback). The new VM Generation ID protects against this scenario.

At first boot-up, a virtualized Windows Server 2012 Domain Controller queries the hypervisor for the VM Generation ID and stores it in in the Active Directory database file (NTDS.dit). Each time the DC is rebooted, the VM’s current VM Generation ID is compared with the value in the DC’s NTDS.dit file (ms-DS-Generation-Id). If the values are different, the DC resets the invocation ID, discards the RID pool, and updates the value in the DC’s NTDS.dit file.  The DC also non-authoritatively synchronizes the SYSVOL folder to ensure proper operation and replication.

NOTE: The ms-DS-Generation-Id computer attribute does not replicate – to view a specific DC’s Generation ID, query for it on that DC.

Here’s the value when viewed in ADUC on the DC:

Powershell command to view the VM Generation ID associated with a 2012 DC:
Import-module activedirectory ;
(Get-ADObject “CN=MCLABDC01,OU=Domain Controllers,DC=MCLAB,DC=net” -server -property msds-generationid).’msds-generationid’


You may notice in the graphic above that when querying DC02 for DC01’s msds-generationid attribute value, it is blank. Since this value does not replicate, you have to query for the value on the DC that stores the value.

This feature also provides the capability to clone (copy) Domain Controllers.

Scenarios where the VM Generation ID is changed:

  • Virtual machine starts executing a snapshot.
  • Virtual machine is recovered from a backup.
  • Virtual machine is failed over in a disaster recovery environment.
  • Virtual machine is imported, copied, or cloned.
  • Virtual machine’s configuration changes (depending on change).
  • Virtual machine is moved from a hypervisor host not supporting VM Generation ID to one that does.

Only Domain Controllers running Windows Server 2012 on a Hyper-V 2012 or VMWare vSphere 5.1 VM support this feature.

VMWare VM-Generation-ID support:

  • VMware vSphere 5.0 Update 2 (vCenter Server and ESXi must both be at 5.0 Update 2)
  • VMware vSphere 5.1 (ESXi must be at least 5.0 Update 2)

Some key caveats:

With this new capability come several requirements and limitations:

* A restored domain controller must be able to contact a writable DC.

If restored, a domain controller must have connectivity to a writable domain controller; a read-only domain controller cannot send the delta of updates. The topology is likely correct for this already, as a writable domain controller always needed a writable partner. However, if all writable domain controllers are restoring simultaneously, none of them can find a valid source. The same goes if the writable domain controllers are offline for maintenance or otherwise unreachable through the network.

* All domain controllers in a domain must not be restored simultaneously.

If all snapshots restore at once, Active Directory replication works normally but SYSVOL replication halts. The restore architecture of FRS and DFSR require setting their replica instance to non-authoritative sync mode. If all domain controllers restore at once, and each domain controller marks itself non-authoritative for SYSVOL, they all will then try to synchronize group policies and scripts from an authoritative partner; at that point, though, all partners are also non-authoritative.

* Any changes originating from a restored domain controller that have not yet replicated outbound since the snapshot was taken are lost forever.

Here’s an excerpt from Microsoft Article: Introduction to Active Directory Domain Services (AD DS) Virtualization (Level 100):

Safe virtualization of domain controllers:

Virtual environments present unique challenges to distributed workloads that depend upon a logical clock-based replication scheme. AD DS replication, for example, uses a monotonically increasing value (known as a USN or Update Sequence Number) assigned to transactions on each domain controller. Each domain controller’s database instance is also given an identity, known as an InvocationID. The InvocationID of a domain controller and its USN together serve as a unique identifier associated with every write-transaction performed on each domain controller and must be unique within the forest.

AD DS replication uses InvocationID and USNs on each domain controller to determine what changes need to be replicated to other domain controllers. If a domain controller is rolled back in time outside of the domain controller’s awareness and a USN is reused for an entirely different transaction, replication will not converge because other domain controllers will believe they have already received the updates associated with the re-used USN under the context of that InvocationID.

For example, the following illustration shows the sequence of events that occurs in Windows Server 2008 R2 and earlier operating systems when USN rollback is detected on VDC2, the destination domain controller that is running on a virtual machine. In this illustration, the detection of USN rollback occurs on VDC2 when a replication partner detects that VDC2 has sent an up-to-dateness USN value that was seen previously by the replication partner, which indicates that VDC2’s database has rolled back in time improperly.

How replication can become inconsistent

A virtual machine (VM) makes it easy for hypervisor administrators to roll back a domain controller’s USNs (its logical clock) by, for example, applying a snapshot outside of the domain controller’s awareness. For more information about USN and USN rollback, including another illustration to demonstrate undetected instances of USN rollback, see USN and USN Rollback.

Beginning with Windows Server 2012, AD DS virtual domain controllers hosted on hypervisor platforms that expose an identifier called VM-Generation ID can detect and employ necessary safety measures to protect the AD DS environment if the virtual machine is rolled back in time by the application of a VM snapshot. The VM-GenerationID design uses a hypervisor-vendor independent mechanism to expose this identifier in the address space of the guest virtual machine, so the safe virtualization experience is consistently available of any hypervisor that supports VM-GenerationID. This identifier can be sampled by services and applications running inside the virtual machine to detect if a virtual machine has been rolled back in time.

During domain controller installation, AD DS initially stores the VM GenerationID identifier as part of the msDS-GenerationID attribute on the domain controller’s computer object in its database (often referred to as the directory information tree, or DIT). The VM GenerationID is independently tracked by a Windows driver inside the virtual machine.

When an administrator restores the virtual machine from a previous snapshot, the current value of the VM GenerationID from the virtual machine driver is compared against a value in the DIT.

If the two values are different, the invocationID is reset and the RID pool discarded thereby preventing USN re-use. If the values are the same, the transaction is committed as normal.

AD DS also compares the current value of the VM GenerationID from the virtual machine against the value in the DIT each time the domain controller is rebooted and, if different, it resets the invocationID, discards the RID pool and updates the DIT with the new value. It also non-authoritatively synchronizes the SYSVOL folder in order to complete safe restoration. This enables the safeguards to extend to the application of snapshots on VMs that were shutdown. These safeguards introduced in Windows Server 2012 enable AD DS administrators to benefit from the unique advantages of deploying and managing domain controllers in a virtualized environment.

The following illustration shows how virtualization safeguards are applied when the same USN rollback is detected on a virtualized domain controller that runs Windows Server 2012 on a hypervisor that supports VM-GenerationID.

Example of how virtualization safeguards work

In this case, when the hypervisor detects a change to VM-GenerationID value, virtualization safeguards are triggered, including the reset of the InvocationID for the virtualized DC (from A to B in the preceding example) and updating the VM-GenerationID value saved on the VM to match the new value (G2) stored by the hypervisor. The safeguards ensure that replication converges for both domain controllers.

With Windows Server 2012, AD DS employs safeguards on virtual domain controllers hosted on VM-GenerationID aware hypervisors and ensures that the accidental application of snapshots or other such hypervisor-enabled mechanisms that could ‘rollback’ a virtual machine’s state does not disrupt the AD DS environment (by preventing replication problems such as a USN bubble or lingering objects). However, restoring a domain controller by applying a virtual machine snapshot is not recommended as an alternative mechanism to backing up a domain controller. It is recommended that you continue to use Windows Server Backup or other VSS-writer based backup solutions.


Microsoft BlueHat Resources

Microsoft has their own internal employee security conference called “BlueHat“.
Here are session links from the past few years:

Continue reading

Group Policy Preferences Password Vulnerability Now Patched

Looks like Microsoft finally removed the ability to set admin account passwords through GPP due to the Group Policy Preferences password  exposure vulnerability.

More information on how Group Policy Preferences are attacked is in the post “Finding Passwords in SYSVOL & Exploiting Group Policy Preferences“.

Because of the security concerns with storing passwords in Group Policy Preferences, Microsoft just released a security patch, MS14-025: Vulnerability in Group Policy Preferences could allow elevation of privilege, that removes this functionality. Any passwords that were in Group Policy Preference xml files stored in SYSVOL before the patch are still in SYSVOL after MS14-025.

Note that this doesn’t remove the ability for Windows to perform this functionality, it only removes the ability to configure passwords in Group Policy Preferences through the GUI. In other words, the patch is for the RSAT – Server Admin Tools. This is impressive since it actually removes functionality which is something Microsoft is traditionally not fond of doing.

In July 2013,  I wrote about the vulnerability of managing passwords with Group Policy Preferences. Here’s the information:

Using Group Policy Preferences for Password Management = Bad Idea OR “How to Get Your Network Owned in Several Simple Steps”

Continue reading

Active Directory Changes in Windows Server 2012

Active Directory, aka Directory Services, has been updated quite a bit in Windows Server 2012.

Here are some of the major updates:

Microsoft article: “What’s New in Active Directory Domain Services (AD DS)”

Microsoft WhitePaper: Windows Server 2012 Evaluation Guide (pdf download)

How to Clean up the WinSxS Directory and Free Up Disk Space on Windows Server 2008 R2 with New Update

It’s finally here! After pages and pages of comments from you requesting the ability to clean up the WinSxS directory and component store on Windows Server 2008 R2, an update is available.

As a refresher, the Windows Server 2008 R2 update is directly related to my previous blog post announcing a similar fix for Windows 7 client.

The Windows 7 version of this fix introduced an additional option to the Disk Cleanup wizard that would cleanup previous versions of Windows Update files. KB2852386 adds a Disk Cleanup option on Windows Server 2008 R2, similar to the Windows 7 update.

What does this mean for Windows Server 2008 R2? After installing this update and prior to being able to perform the cleanup, the Desktop Experience feature must be installed. Why you ask? Disk Cleanup is not installed by default on Windows Server 2008 R2. It is instead a component installed with the Desktop Experience feature.

Why was the update not included as a DISM switch like Windows Server 2012 R2? 

This was evaluated, however, due to the amount of changes required and the rigorous change approval process, it was not feasible to back port the functionality this way. Knowing that it would be some time before everyone could upgrade to Windows Server 2012 R2 and based on feedback from an internal survey taken of a subset of enterprise customers, it was determined that this update would still be useful in its Disk Cleanup form, even with the Desktop Experience prerequisite. We hope you agree. However, we are aware that for some of you, the Desktop Experience requirement will be a deal breaker, but decided to release it anyway hoping it will help in some instances.

How can I get the update?

The update is available on Windows Update. It can also be manually downloaded from the Microsoft Update Catalog. The KB article listed above will also direct you to a download link in the Microsoft Download Center.

Script It!


My super knowledgeable scripting cohort Tom Moser wrote a PowerShell script that automates THE ENTIRE PROCESS. Can I get a cheer? Ok. So maybe it is a bit much to expect IT admins to cheer, but can I get an appreciative grunt?  The script certainly beats the alternative of doing this all manually.

You can find the script on the TechNet Script Center here:

What does the script do? 

In short, the script does the following:

1) Installs Desktop Experience, if not previously installed, and performs a reboot.

2) Sets the appropriate registry keys to automate the cleanup. The script will cleanup not only previous Windows Update files as well as Service Pack files.

3) The script then initiates the cleanup.

4) If Desktop Experience was not previously installed, the script uninstalls it.

5) Performs final reboot.




Active Directory FSMO Placement Guidance

FSMO Placement Guidance Summary:

  • Make sure the PDC is highly available and connected.
  • Place the PDC on your best hardware in a reliable hub site that contains replica domain controllers in the same Active Directory site and domain.
  • Place the Forest FSMOs on the forest root PDC (schema master & domain naming master).
  • Place the RID master on the domain PDC in the same domain.
  • If you have a single domain environment, all DCs are GCs, OR you have enabled the recycle bin (see MSDN note below), place the infrastructure master on the PDC (which likely contains the other FSMO roles as well).
  • Don’t move FSMOs around regularly. The PDC is targeted for a number of operations and network connections. It is best to not force clients to rediscover the PDC on a regular basis.

This means, in a single domain environment, it makes sense to place all the FSMOs on a single DC. Pick one that is highly available and well-connected. You may decide that selecting a virtual DC is the way to go since it can usually be moved to different hosts for DR/COOP reasons. Note that if you do go virtual for this DC, consider disabling VM host time synchronization.Though, there may be valid reasons for not doing so.

In a multiple domain environment, place the Forest FSMOs on the forest root PDC (schema master & domain naming master) and select one DC per domain on which to place all of the FSMOs – the PDC is a good choice assuming they are all GCs or the AD Recycle Bin is enabled.


When the Recycle Bin optional feature is enabled, every DC is responsible for updating its cross-domain object references in the event that the referenced object is moved, renamed, or deleted. In this case, there are no tasks associated with the Infrastructure FSMO role, and it is not important which domain controller owns the Infrastructure Master role.

From MSDN: “ Infrastructure FSMO Role


FSMO Role Information:
Continue reading

Windows Server 2012 MCSM Reading List

Here’s a link to download the MCM/MCSM Directory Services Reading List document that I developed for the MCSM Directory Services (Windows Server 2012) program and was created after the MCSM Directory Services (Windows Server 2012) test questions were written.

It is based on the original one created for the MCM DS program provided to candidates.


The AD Reading Library on this site also has Active Directory references worth reading and is updated occasionally.

Enabling and Managing the Active Directory Recycle Bin

So, you have upgraded all your DCs in the forest to Windows Server 2008 R2 and raised the domain and forest functional levels to Windows Server 2008 R2. Congratulations!
Now what?

Yes, you have to enable the AD Recycle Bin manually by running the following PowerShell commands:

Import-Module ActiveDirectory

Enable-ADOptionalFeature –Identity ‘CN=Recycle Bin Feature,CN=Optional Features,CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=DOMAIN,DC=com’ –Scope ForestOrConfigurationSet –Target ‘’

Note that this effectively removes the importance of the Infrastructure Master FSMO since all DCs will perform that role. From MSDN: Continue reading

Facebook increases privacy on all new posts by default

Looks like Facebook might be coming to its senses…


AD Reading: How Key Active Directory Components Work

The following links provide in-depth information on how key Active Directory components work.