We recommend that you use this method to supplement your regularly scheduled backups that you should be taking from within the virtual machine guest OS itself. Due to its inability to target individual virtual machines for backup and restore, we do not recommend that you use this as your primary method.
When a proper system state restore is performed, the invocation ID attribute of the restored database is reset, which notifies each replication partner that this server has indeed been restored from a previous state. Replication attempts from the restored DC to its partners would include this new invocation ID along with data that it has previously replicated. As long as the partner receives the previously acknowledged USN with a new invocation ID, there are no issues.
USN rollback happens to a domain controller when it replicates previously acknowledged USN with the same invocation ID. In this circumstance, there is no way to ensure that the changes pushed from this particular DC are the latest. When this inconsistency is recognized by its partner, they will notify it. The source server will then pause its netlogon service and disable outbound replication to prevent any changes originating from this servers copy of AD from being pushed out to the domain. At this point, you must remove this server from the existing domain and promote it back in as a clean domain controller. The following KB article goes into greater detail, including the events you will receive and includes all of the recovery steps that are required.
Note: Besides restoring a DC improperly, disconnecting a domain controller from the domain beyond 180 days (tombstone lifetime) and then bringing it back into the network will result in the same scenario.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.