Restore and Backup of Active Directory Server 2012

In the lines (and posts) that follow, I want to examine three Active Directory restore methods.

 

1. System State restore. This implies a System State backup.

2. Active Directory Recycle Bin.

3. Third-party software.

System State backup and restore

The first step, quite logically, is to perform a system state backup of the domain controller.

 

In fact, we have the option of performing a "Full Server Backup" which includes the System State as well.

 

The Full Server Backup has the advantage of allowing a bare metal restore of the domain controller. We would boot from the Windows Server 2012 media and essentially restore the image of the entire server from a .VHD file (since Windows 2008, the backup file exists in that format). A simple System State backup does not allow such a restore.

 

In any event, both types of backups can be performed in either the GUI or at the command line.

 

I'm going to choose the command line option:

PS C:\> wbadmin start backup -backuptarget:E: -allcritical -systemstate -vssfull -quiet

wbadmin is the Windows Server command line tool for backups since Windows 2008.

 

wbadmin start backup is the basic command to start a backup (self-explanatory).

 

We need to designate a target for the backup. This can be a local or external hard drive or a network share. I'll use an external hard drive for this post.

 

-backuptarget:E:

 

The following command is the equivalent of the "Bare Metal" option in the Windows Server Backup graphical interface. In summary, it backs up all volumes necessary for the complete restoration of the server. This would be, at minimum, the C: drive and then any other drives housing elements such as the Active Directory database or logs files, if these where stored elsewhere.

-allcritical 

I have added the following parameter after having read that without it, we could not perform a simple system state restore from a Full Server Backup.

-systemstate

Bare Metal backup versus -allcritical

I have not tested the command without the -systemstate parameter to confirm that the assertion is exact but I can confirm that the command works just fine with the parameter, necessary or not.

As for the last two parameters...

-vssfull

This configures the backup so that all files are marked as backed up and that logs of previous backups may be deleted. It should be added if Windows Backup is the only backup software in use.

-quiet

This simply suppresses some of the prompts that would otherwise display.

The resulting output (edited here) should look something like this:


Retrieving volume information...
This will back up System Reserved (350.00 MB),(C:) to E:.
The backup operation to E: is starting.
Creating a shadow copy of the volumes specified for backup...
Creating a backup of volume System Reserved (350.00 MB), copied (0%).
Creating a backup of volume System Reserved (350.00 MB), copied (62%).
The backup of volume System Reserved (350.00 MB) completed successfully.
Creating a backup of volume (C:), copied (0%).
Creating a backup of volume (C:), copied (2%).
Creating a backup of volume (C:), copied (4%).
Creating a backup of volume (C:), copied (7%).
[snip]
Creating a backup of volume (C:), copied (94%).
Creating a backup of volume (C:), copied (96%).
Creating a backup of volume (C:), copied (99%).
The backup of volume (C:) completed successfully.
Summary of the backup operation:
------------------
The backup operation successfully completed.
The backup of volume System Reserved (350.00 MB) completed successfully.
The backup of volume (C:) completed successfully.
Log of files successfully backed up:
C:\Windows\Logs\WindowsServerBackup\Backup-01-01-2014_02-36-34.log


Now we have a backup.


Next, I'm going to delete three users: Aisha Bhari, Alannah Shaw and Alan Reid:

Note that they are also members of the "Marketing" group. After the restore, we will want to verify that group membership was re-established:

 

I won't waste space by posting another screenshot, but once the users are deleted they not only disappear (as expected) on DC5 but no longer appear in ADUC on DC2 less than a minute later. So replication acts immediately.

 

Now we learn that those users were not supposed to be deleted! Now we are in a predicament!

 

What can we do?

 

 

1. Boot into "Directory Service Restore Mode"

 

First we have to boot into what is called "Directory Service Restore Mode" (DSRM) on the server on which we performed the backup.

Tapping the F8 key should display a boot menu but it does not - not with a Windows Server 2012 guest in VMware. There might be a trick to this and I might succeed if I tried some more but there is another option.

At the command line, we enter the following (and then restart the computer):

bcdedit /set safeboot dsrepair

restart-computer


Note: to return to a normal boot, once the restore operation is complete, we enter this command:

bcdedit /deletevalue safeboot



Once the server restarts and we login, the screen should look like this:

Note the words "Safe Mode" in the corners of the desktop. I only show the upper left-hand corner above, but the indication is present in all four corners. That informs us that the boot into DSRM was successful.


2. Restore the System State


The next step is to restore the system state.

I would like to point out that in this practice scenario, there can be no confusion about the backup to restore since we only have one and created it only minutes ago. Likewise, we only backed up one server. In reality, the backup media could contain not only several backups but backups of several servers. Therefore, we have to identify the backup we want with the following command:

 

wbadmin get versions -backuptarget:E: -machine:DC5


Among other information, this command produces an entry for:

Version Identifier: 01/01/2014-2:36

This output is important because we must indicate the backup version (even if there is only one) in the command that restores the system state:


wbadmin start systemstaterecovery -version:01/01/2014-2:36 -backuptarget:E: -machine:DC5

At this point we are all set... or so it seems. Our three user accounts have been restored - as well as the rest of Active Directory and all the other elements of the "System State".

 

But there is a problem. The three user accounts have been marked as deleted. These deleted accounts, though "invisible" to the administrator, still have a certain form of existence in Active Directory (for a while) and are replicated as deleted accounts to the other domain controller(s). The replication of what is called a "tomb-stoned" object is necessary so the other domain controllers are aware of the deletion and can update their copy of the Active Directory database accordingly. Now, these deleted user accounts, even though they are deleted, have a higher version number than the user accounts that were backed up earlier. The correct term for this "version number" is "USN" or "update sequence number" and it helps govern replication:

Newer versions of an object, updated on a given domain controller,  replace older versions of an object that exist on other domain controllers.

 

So what will happen once the domain controller reboots and begins to replicate with the other domain controller? The "invisible" deleted user account, since it has a higher "version number", or USN, will replace the newly restored (but technically older) user account.

We need to mark the restored object(s) as "authoritative" which essentially increases their USN number so it is (much) higher than that of the deleted user account (the tomb-stoned object) that continues to represent it in Active Directory.


3. Mark the restored objects as authoritative (authoritative restore)


We manage the authoritative restore at the command line using the ntdsutil tool. We'll start by restoring the user Alan Reid, entering the commands as follows:

C:\Users\admin>ntdsutil

ntdsutil: activate instance ntds

Active Instance set to "NTDS".

ntdsutil: authoritative restore

authoritative restore: restore object "cn=Alan Reid,ou=ExchangeUsers,dc=mynet,dc=lan"

 When prompted for confirmation, I select "Yes":

 
I repeat the process for the other users.

The restore is successful. Once again, the users appear as they do in the screenshots above. What's more, the group membership is re-established as well. This was always a complex element in the restore process since membership in a group is not a property of the user, but rather of the group, and something known as the "back link" had to be restored, possibly in a second authoritative restore. Since group membership is restored here, at least in this rather simple scenario - single domain, single site, I'm led to believe that a Windows 2012 authoritative restore is able to process this element successfully.

The restore can be even more complex. If we had deleted the entire ExchangeUsers OU we could attempt to restore it with the "restore subtree" command in ntdsutil (instead of a single "object"):

authoritative restore: restore subtree "ou=ExchangeUsers,dc=mynet,dc=lan"

***

So the restore is successful but some might perceive it as cumbersome. In my next blog post, I'll examine the "Active Directory Recycle Bin" option, first introduced with Windows 2008 R2 and improved in Windows 2012 Server, notably by the addition of a graphical user interface.