Windows Server 2012 R2 introduced two useful updates to checkpoints, which
continue in Windows Server 2016. First, checkpoints can be exported while the virtual
machine is running, which previously was not possible. Additionally, an export of the
Now state of a virtual machine (that is, the running state) is possible, which
effectively creates a clone of the virtual machine. This is useful in debugging
situations where a problem is occurring on a virtual machine, and instead of having to
debug the virtual machine, it is possible to create an export/clone of its current state
and then debug that clone state. The export of the live state includes a copy of the
storage, configuration, and memory dump—all without any impact to the availability
of the virtual machine.
How checkpoints should be used is something often discussed. They are not
replacements for backups, but rather, checkpoints that are useful for development and
testing environments. Imagine in a testing or development environment the ability to
save the state of an operating system, make some changes, and then revert back to a
state before the changes were ever made. For a developer, the ability to freeze a
system at the point of a problem and be able to keep reverting back to that problem
state again and again is invaluable.
The use of checkpoints in production environments is generally discouraged because
their usage can cause problems. This guidance does change in Windows Server 2016,
however, when production checkpoints are utilized because of their integration with
VSS and how they behave essentially like a backup. Additionally, as checkpoint
hierarchies grow, some performance degradation occurs. A virtual machine can have
up to 50 checkpoints. Checkpoints are specifically hazardous and known to cause
problems for some types of services, such as Active Directory domain controllers.
Taking a standard checkpoint of a domain controller and then reverting the domain
controller back to that checkpoint can result in replication problems, duplicate
security identifiers, and therefore security vulnerabilities prior to Windows Server
2012.
Windows Server 2012 introduced “virtualization safe” Active Directory when it’s
running on Hyper-V 2012 or above. Prior to Active Directory running on Windows
Sever 2012 Hyper-V, there was a huge problem using snapshots with domain
controllers. Directory services always expect time to go forward and need some way to
track it, such as a logical clock, and Active Directory uses an update sequencer number
(USN), which is incremented each time a new object is created along with other
incremental values, such as the relative ID (RID). Look at Figure 6.8. Imagine that
you have a domain controller and at USN 2 a snapshot is created, and then the DC
continues using USNs up to number 6 for created users. Then an administrator
applies the snapshot that was created, which puts the domain controller back to USN
number 2. The domain controller has no clue that it has been put back in time, so it
carries on back at USN number 2, creating objects with the same security IDs, which
causes problems with security, and the domain controller will no longer replicate
correctly with the rest of the domain. We have divergence. This is a terrible problem
for organizations and one of the biggest causes of Active Directory issues for Microsoft