Export (0) Print
Expand All
Windows Administration
Active Directory Backup and Restore in Windows Server 2008
Gil Kirkpatrick
At a Glance:
  • NTBACKUP vs. Windows Server Backup
  • Backup tools and options
  • Recovery tools and options
  • Keys to a sound Active Directory backup strategy

You all know that Active Directory Domain Services (ADDS) is a mission-critical component in your Windows infrastructure. If Active Directory goes down, your network is essentially useless. Consequently, your backup and recovery plans for Active
Directory are fundamental to security, business continuity, and regulatory compliance.
Windows Server® 2008 brings many new features to Active Directory®, two of which have a significant impact on your backup and recovery plans: the new Windows Server Backup utility and the ability to take and work with Volume Shadow Copy Service snapshots of Active Directory. In this article I will describe the changes these enhancements bring to the table and how you can take advantage of these changes to streamline your Active Directory backup activities.

NTBACKUP vs. Windows Server Backup
Group Policy Settings
Windows Server Backup provides several Group Policy settings that give you some limited control over how backups work on your servers. With these backup policies, you can mitigate some of the risks associated with people performing unauthorized backups to obtain access to unauthorized data. The options include:
Allow Only System Backup If this is set, Windows Server Backup can only back up critical system volumes. It cannot perform volume backups. Disallow Locally Attached Storage as Backup Target When enabled, this setting does not allow backups to locally attached drives. You can only back up to a network share.
Disallow Network as Backup Target This setting does not allow backing up to any network share.
Disallow Optical Media as Backup Target When this is set, Windows Server Backup cannot back up to any optical device, such as a recordable DVD drive.
Disallow Run-Once Backups This setting does not allow Windows Server Backup to run unscheduled, ad hoc backups. Only backups that are scheduled through the Windows Server Backup MMC snap-in are allowed to run.

The NTBACKUP you've known and loved since Windows NT® 3.5 is gone. Replacing it is Windows Server Backup. And this new tool is not just a gussied-up NTBACKUP; it's a whole new backup technology that will force you to rethink the way you back up your systems.
Although Windows® Server Backup is the only in-the-box backup solution for Windows Server 2008, it is not a feature-for-feature replacement for NTBACKUP. The biggest difference is that Windows Server Backup is a disk-to-disk backup solution; it doesn't support backing up to tape. You can create backup images on direct-attached disk volumes, on network shares, and even on external USB hard drives and multi-volume recordable DVDs. But you cannot back up to tape. Just to be clear, you can still hang a tape drive on a Windows Server 2008 server and copy the Windows Server Backup-generated backup images to the tape drive—but you'll have to use someone else's software to do so.
Whereas NTBACKUP is a file-based backup and restore tool, Windows Server Backup is volume- and block-based. Windows Server Backup deals with its backup source as a set of volumes, with each volume as a collection of disk blocks. This is considerably more efficient than backing up files through the file system. Dealing with backups on a block basis also allows Windows Server Backup to make use of Volume Shadow Copy Service snapshots to perform block-level incremental backups, as well as to create snapshots on the target volume to simplify the use of (and reduce the space used by) multiple backups.
Even if you are doing full backups, Windows Server Backup provides some great space efficiencies on the target disks. For instance, you might perform multiple full backups of the same volume. Since Windows Server Backup uses Volume Shadow Copy Service snapshots on the target disks where it stores the backup images, the snapshots will only store the blocks that have changed. This substantially reduces the space used by multiple full backups. This eliminates the need to perform multiple restore operations to recover an incremental backup. Even though the snapshot only stores the deltas for each backup, Volume Shadow Copy Service makes each backup appear complete.
Be aware, though, that you only get the benefits of Volume Shadow Copy Service snapshots on the target if you back up to a local hard disk—Windows Server Backup can't perform Volume Shadow Copy Service operations on backups stored on DVD or network shares.
As an added bonus, Windows Server Backup stores its backup images in Microsoft® Virtual Hard Disk (VHD) format. You can actually take a backup image and mount it as a volume in a virtual machine running under Microsoft Virtual Server 2005. You can simply mount the VHDs in a virtual machine and browse for a particular file rather than having to perform test restores of tapes to see which one has the file is on it. (A note of caution: you can't take a backup image and boot a virtual machine from it. Since the backed-up hardware configuration doesn't correspond to the virtual machine's configuration, you can't use Windows Server Backup as a physical-to-virtual migration tool.)
There is a downside to Windows Server Backup's volume- and block-orientation. Since this new tool looks at the backup source as a set of volumes and blocks, it doesn't allow you to back up only selected files. You have to back up the entire volume. And even more problematic, by default you cannot store a backup image on one of the volumes being backed up (there are some ways to configure around this; see This has profound implications for system state backup, as I will discuss later in this article.

Installing Windows Server Backup
Windows Server Backup is a "feature" in Windows Server 2008 and is not installed by default. Before you can perform a backup with Windows Server Backup, you have to install the feature, using either Server Manager, or the SERVERMANAGERCMD command-line utility:

C:\> servermanagercmd -install Backup-Features

Windows Server Backup is composed of two sub-features, Windows Server Backup and Command-line Tools. Note that Command-line Tools refers to a set of Windows PowerShellTM cmdlets—not the WBADMIN .EXE command-line tool. Thus, if you choose to install both sub-features, you must install the Windows PowerShell feature.
After installing Windows Server Backup, you can find the Microsoft Management Console (MMC) snap-in under the Storage node in Server Manager and on the Administrative Tools menu. If you are installing Windows Server Backup on a Windows Server 2008 Server Core installation, use the OCSETUP command (it's important to note that the OCSETUP command is case-sensitive):

C:\> ocsetup WindowsServerBackup

A complete description of the installation process is available at
Note that Windows Server Backup can't restore images created with NTBACKUP. For this unlikely scenario, Microsoft has made available a downloadable version of NTBACKUP for Windows Server 2008 (see

The Windows Server Backup Components
The way in which the Windows Server Backup application is architected represents a significant change. This new backup solution consists of four components:
  • MMC user interface (WBADMIN.MCS)
  • Command-line interface
  • Backup service (WBENGINE.EXE)
  • Set of Windows PowerShell cmdlets
Splitting the application into a client and a service has several advantages, the most important being increased reliability. Whether you start a backup from either the MMC client or the command-line interface, the WBENGINE service is doing the heavy lifting. The client programs just report the status of the backup. Thus, terminating the client will not result in a half-baked backup. The client will stop and the service will continue to completion. Of course, if you really want to stop the backup, you can, but you must do so explicitly.
The other advantage of this split architecture is that you can use the client to manage backups on remote machines. This is particularly nice when you have to back up Windows Server 2008 Core machines.
Windows Server Backup supports bare-metal restores using the Windows Recovery Environment, or WinRE, which comes on the Windows Server 2008 installation media. WinRE simplifies the process of recovering a server from scratch. I will discuss performing a bare-metal restore later in this article. It's worth mentioning that Windows Server Backup supports several Group Policy settings for managing backups—these are outlined in the "Group Policy Settings" sidebar.

Volume Shadow Copy Service
Windows Server Backup uses Volume Shadow Copy Service in three different ways. When you start a full backup on Windows Server 2008, the first thing that the application does is make a shadow copy of all of the source volumes. Doing this provides a consistent view of the file system for the backup software to work with. (This is similar to what NTBACKUP did.) Windows Server Backup then copies blocks from the source volume—block by block—to the backup target, building a VHD image for each backed-up volume in the process.
Unless you specify otherwise, Windows Server Backup also creates a snapshot of the source volume so that Volume Shadow Copy Service will keep track of all changed blocks on the volume. This enables Windows Server Backup to create block-level incremental backups that only require reading the changed blocks of the source volume. Rather than reading and writing an entire file because one bit was changed in the file, Windows Server Backup can read and write only the block that has changed.
This makes for very efficient incremental backups, but at the expense of extra disk I/O for write operations on the source volume. If you are backing up a particularly busy or performance-critical volume, you should disable the Volume Shadow Copy Service snapshot on the source volume by selecting the Configure Performance Settings link and then disabling incremental backups on that volume (as shown in Figure 1).
Figure 1 Disable incremental backups on busy volumes (Click the image for a larger view)
When the backup is complete, Windows Server Backup takes a snapshot of the target volume (assuming you are backing up to a locally attached hard disk). During the next backup, the target VHD files are overwritten. But since Volume Shadow Copy Service is maintaining shadow copies of the target volume, there are, in effect, multiple versions of each VHD file corresponding to each of the full backups. You essentially get multiple full backups for the cost of one full backup and the changed blocks.

Backing Up to Network Shares
Backing up to a network share is just as easy as backing up to a local volume. The significant difference is that it can't create a Volume Shadow Copy Service snapshot of the remote volume. Therefore, each full backup will overwrite the previous, leaving you with just the latest full backup image of each server on a network share. Due to this limitation, you can't use the Windows Server Backup scheduler to schedule backups to a network share. You can, however, use the Windows Task Scheduler to run the WBADMIN command-line program to perform full backups to a network share. If you elect to schedule full backups to a network share this way, change the target folder for each backup to avoid overwriting previous backups.

Backing Up to Recordable DVDs
Windows Server Backup also supports backing up to optical media, such as writable DVDs. And you can create backup sets that span multiple volumes, as well. Windows Server Backup always compresses backups to DVDs, which means that you can only perform full system or full volume restores from DVD. Windows Server Backup doesn't support system state or file level backups and restores when using DVDs. And you can't schedule backups to DVD.

System State Backups and Restores
System state backups, which include only select files and some application databases (rather than entire volumes) is handy and often essential. But early builds of Windows Server 2008 didn't support system state backups and restores. Instead, the backup tool just backed up critical system volumes (meaning any volumes necessary for recovering and rebooting the OS and key applications). These critical system volumes were the volume-oriented equivalent of a system state backup.
Acknowledging feedback from customers, Microsoft added system state backup and restore capabilities to Windows Server Backup. The application creates multiple VHD files, one for each volume that hosts the system state data, but it only copies the necessary files and databases to the VHDs. Another issue is that when you perform a system state backup, Windows Server Backup does not create a snapshot of the target volume as it does in the normal backup process. Instead, each system state backup generates an entirely new set of VHD files, which means you don't get the space efficiencies you find with the snapshot-based volume backups.
You can only perform a system state backup using the WBADMIN.EXE command-line program—the MMC snap-in doesn't provide this option. To perform a system state backup, you use this command:

C:\> wbadmin start systemstatebackup

WBADMIN will then back up the critical system files and application databases to the target volume, in a folder reserved for system state backups. The system state backup on a 32-bit Windows Server 2008 domain controller (DC) with a default directory information tree (DIT) runs a little more than 6GB—this is more than 5GB larger than on Windows Server 2003 due in part to the fact that Windows Server Backup is capturing core OS files that NTBACKUP didn't.
The time required to back up the system state is also greater, as you would expect. These initial numbers, of course, are based on a pre-release version of the OS. You'll certainly need to test this in your own environment, but it's likely that you'll need to plan for larger system state backups (and longer backup times) when you move your domain controllers to Windows Server 2008.

Backing Up a Server with the MMC
When you run the Windows Server Backup MMC (see Figure 2), you have the option of either setting up a backup schedule or immediately running an ad hoc backup. In this case, I select Backup once to perform an immediate backup.
Figure 2 Windows Server Backup MMC (Click the image for a larger view)
As you can see in Figure 3, I can choose whether to back up all the volumes on the server or back up just the specific volumes that I choose. If I select Full server, Windows Server Backup will back up all mounted volumes, but I won't have the option of backing up to a mounted hard drive—instead, I will have to back up to a recordable DVD or to a network share.
Figure 3 Using the backup configuration dialog to specify all or select volumes (Click the image for a larger view)
In this example, I want to back up to a local hard drive, so I select the Custom option. A dialog then lets me select the volumes to back up (see Figure 4). By default, Windows Server Backup checks the Enable system recovery box, which causes Windows Server Backup to select the boot volume, the OS volume, and any other volumes with critical system files and application databases. On a DC, this includes the volumes hosting SYSVOL, the Active Directory DIT, and Active Directory logs. This is the equivalent of a system state backup but it backs up all the critical volumes, not just the critical files on those volumes. In fact, I even have the ability to perform a system state recovery from a system recovery backup set.
Figure 4 Selecting specific volumes to back up (Click the image for a larger view)
After I select the destination type (local drive or network share) and specify the destination, Windows Server Backup prompts me to select either a "VSS copy" backup or a "VSS full" backup. The terminology is a little confusing, as both options will back up the selected volumes in their entirety. The difference lies in the way Windows Server Backup handles the source files after they've been backed up. If you select the copy option, Windows Server Backup will leave the backed up files alone. If you choose the full option, Windows Server Backup will then reset the archive.

Backing Up a Server from the Command Line
If you want to script the backup process, or if you are backing up a server on a Server Core installation, you can use the WBADMIN.EXE command-line program. WBADMIN provides a complete set of options that perform essentially the same functions as the MMC snap-in, including managing backup schedules.
Suppose I want to start the WBENGINE service, which will in turn perform the backup process. All I do is enter this command:

C:\> wbadmin start backup –include:c:,d:

Or to back up all critical system volumes, I can enter this command:

C:\> wbadmin start backup -allcritical

After starting the backup, WBADMIN continues to run and show the progress of the backup. If I terminate WBADMIN, the backup will continue in the background. I can then reconnect WBADMIN to a running backup using this command:

C:\> wbadmin get status

And if I want to terminate a running backup, I just enter this:

C:\> wbadmin stop job

Scheduling Backups with the MMC
The backup scheduler that is integrated with the Windows Server Backup is really designed to do one thing: simplify scheduling of daily full-system backups to a local disk volume. You can use the built-in scheduler to automatically rotate backups among multiple target volumes. If you have easily removable hard drives (or you are using USB-attached hard drives), you can use this feature to set up a rotation scheme where you remove the backup disk and store it off-site and return the oldest backup disk to the server for the next scheduled backup.
The Windows Server Backup scheduler only lets you schedule backups that always occur daily. There is no way to schedule backups for, say, Mondays, Wednesdays, and Fridays. So if you don't want to run your scheduled backups daily, you'll have to work directly with the Windows Task Scheduler.
When you set up a scheduled backup to a local disk, Windows Server Backup takes responsibility of the disk, formatting it, setting up a specific folder structure, and making the target disk invisible to Windows Explorer. The target disk must be a basic volume—Windows Server Backup cannot backup to disks configured as dynamic volumes.
Scheduling backups through the MMC snap-in is very easy. In this example, I first select the Backup Schedule link, specify the type of backup and the volumes to back up, and then Windows Server Backup shows the "Specify backup time" dialog (see Figure 5).
Figure 5 Specifying when daily backups should occur (Click the image for a larger view)
After selecting the times at which I want the backup to occur, I can select the volume (or volumes) to which I want to back up. In this case, I select the backup volume E:, as shown in Figure 6. Windows Server Backup tries to select an appropriate target volume for you, but if it happens that the disk you want to back up to doesn't appear, you can use the Show All Available Disks button to view all attached disk devices. After going through a couple of "confirm" dialogs, Windows Server Backup formats the target volume(s) and schedules the backup task using the Windows Task Scheduler.
Figure 6 Specifying the destination disk for a scheduled backup (Click the image for a larger view)
Each time a scheduled backup is completed, Windows Server Backup takes a snapshot of the target volume. And every seven days, it creates a new base image. Activity is logged in the Microsoft/Backup/Operational log. You can check there to see if your backups completed successfully; you can also associate a task, such as sending an e-mail message, with the success and failure events so you will always know the status of your scheduled backups.

Scheduling Backups from the Command Line
If you are scheduling backups on a Server Core installation or you just want to script the process, you can manage the backup schedule using the WBADMIN command-line. To add a scheduled backup, you use the WBADMIN ENABLE BACKUP command, specifying the target, source, and scheduled time, like so:

C:\> wbadmin enable backup –addtarget:e:
-include:c:,d: -schedule:06:00,12:00,18:00

This command would back up the C: and D: drives to the E: drive three times a day, at 6:00 A.M., 12:00 P.M., and 6:00 P.M. (note that all times are specified using a 24-hour clock). To back up all critical system volumes (from which you can perform a bare metal restore or a system state restore), replace the –include switch with –allcritical.
You can also use WBADMIN to disable all scheduled backups, like this:

C:\> wbadmin disable backup

This command will delete all the scheduled backup jobs created by the Windows Server Backup scheduler and release all the backup target volumes for normal use. Note that you can always use the WBADMIN MMC snap-in to remotely manage the backup and restore activities of Server Core servers.

Bare-Metal Recovery of a Domain Controller
One of the most exciting improvements for backup and recovery is how the WinRE has been incorporated into the installation process. When you boot Windows Server 2008 from the installation media, you can choose the Repair your computer option, as shown in Figure 7. I point this out because it is easy to miss if you're not looking for it.
Figure 7 The Repair your computer option is available on the installation screen (Click the image for a larger view)
After I select the repair option on the installation screen, Windows lets me select a recovery option, as shown in Figure 8. In this case, I select Windows Complete PC Restore, which invokes the Windows Recovery Environment.
Figure 8 Specifying system recovery options (Click the image for a larger view)
After you select the operating system you want to repair (there is typically only one choice), WinRE allows you to select the backup from which you want to restore. By default, WinRE selects the most recent complete system backup, but you can specify other backups stored on local disks or search the network for backups that are stored on file shares on other servers.
In my example, I select the most recent complete system backup. The next dialog (shown in Figure 9) lets me format and repartition all the disks before they are restored. This is an appropriate option if the problem you are recovering from was caused by some sort of disk failure or if you've replaced one or more disk drives in the server.
Figure 9 You can easily format and repartition disks before they're restored (Click the image for a larger view)
After a couple of confirming dialogs, WinRE starts the restore process and the server reboots. This is a pretty painless way to perform a bare-metal recovery on a server.

System State Recovery of a Domain Controller
If you need to recover from some sort of Active Directory-related problem—such as recovering a deleted OU from backup—you should restore the Active Directory Domain Services (ADDS) database to an earlier state, rather than restore the entire system. Even though you can stop ADDS like a service in Windows Server 2008, you still need to boot the server into Directory Services Restore Mode (DSRM) to perform a system state restore on a domain controller.
Changing the boot options to make Windows Server 2008 boot into DSRM is not quite as easy as it used to be. The entire Windows boot environment has been re-engineered to support the new Extensible Firmware Interface (EFI) and the old school boot.ini file no longer exists. Instead, Windows Server 2008 uses Boot Configuration Data (BCD) to control the boot process.
The simplest way to manage the BCD is to use the BCDEDIT command line program. A discussion covering all the BCDEDIT commands and options would require its own article, so I'll just show you some useful examples here.
To reboot a Windows Server 2008 DC into DSRM, use the following command:

C:\> bcdedit /set safeboot dsrepair

This will set the safeboot option for the default boot loader entry. In a fresh Windows Server 2008 installation, there is only one boot loader entry, WINLOAD.EXE. To remove the safeboot option and reboot in normal mode, use this command:

C:\> bcdedit /deletevalue safeboot

To make things a little easier for yourself, you can configure two bootloader entries on your DCs—one for a normal boot and one for a DSRM boot. This way, you can change the boot options using the Startup and Recovery settings dialog available under System Settings. To add a new bootloader entry, use this command:

C:\> bcdedit /copy {default}
/d "Directory Service Repair Mode"

This action will create a new bootloader entry by copying the default bootloader entry. BCDEDIT will display something like this:

The entry was successfully copied to

The GUID identifies the new entry. Then use this command to set the safeboot option for the new bootloader entry in the BCD:

C:\> bcdedit /set {<GUID for new entry>}
safeboot dsrepair

You can now switch from normal boot mode to DSRM boot mode using the Startup and Recovery settings (see Figure 10).
Figure 10 Disable incremental backups on busy volumes 
Before you use WBADMIN to start a system state restore, you must identify the backup from which you want to restore. WBADMIN can perform a system state restore from either a full system backup, a backup that contains just the critical system volumes, or a system state backup. In any of these cases, you have to specify the version of the backup you want to use. The easiest way to identify the backup versions that are available is to use the following WBADMIN command:

C:\> wbadmin get versions

WBADMIN will then display the backup versions in a form similar to the info shown in Figure 11. Note that each backup has a backup time, backup target, a version identifier (which, by the way, is the time and date the backup was started in Universal Mean Time), and a list of the types of recovery operations the backup can support.

wbadmin 1.0 - Backup command-line tool
(C) Copyright 2004 Microsoft Corp.
Backup time: 11/30/2007 3:47 PM
Backup target: Fixed Disk labeled E:
Version identifier: 11/30/2007-22:47
Can Recover: Application(s), System State
Backup time: 12/1/2007 10:46 PM
Backup target: Fixed Disk labeled Backup(E:)
Version identifier: 12/02/2007-05:46
Can Recover: Volume(s), File(s), Application(s), Bare Metal Recovery, System State
Backup time: 12/2/2007 5:58 PM
Backup target: Fixed Disk labeled Backup(E:)
Version identifier: 12/03/2007-00:58
Can Recover: Volume(s), File(s), Application(s), Bare Metal Recovery, System State
Backup time: 12/3/2007 11:25 AM
Backup target: Fixed Disk labeled E:
Version identifier: 12/03/2007-18:25
Can Recover: Application(s), System State

In this case, I select the most recent backup and start the system state restore with this WBADMIN command:

C:\> wbadmin start systemstaterecovery

This will perform a non-authoritative restore. If you want to perform an authoritative restore of the SYSVOL, you can just mark the restored SYSVOL replica as being authoritative by adding the authsysvol option to the WBADMIN command. For more information on this process, see

Taking Active Directory Snapshots
One of the most exciting changes in terms of backup for Active Directory has nothing at all to do with Windows Server Backup. In Windows Server 2008, you can take advantage of the fact that Active Directory can provide Volume Shadow Copy Service snapshots. These snapshots are very lightweight, point-in-time backups of the running Active Directory service. And even better, they take only a few seconds of your time to create! You can then mount these snapshots and access them using normal LDAP-based utilities, such as the LDP tool.
You take snapshots of ADDS or Active Directory Lightweight Directory Services (ADLDS) using the NTDSUTIL command, as shown here:

ntdsutil: snapshot
snapshot: activate instance ntds
Active instance set to "ntds".
snapshot: create
Creating snapshot...
Snapshot set {42c44414-c099-4f1e-8bd8-4453ef2534a4} generated successfully.
snapshot: quit
ntdsutil: quit

This sequence of NTDSUTIL commands creates a Volume Shadow Copy Service snapshot of the volumes that contain the Active Directory DIT, logs, and SYSVOL. Even though Active Directory is still being updated, Volume Shadow Copy Service uses a copy-on-write strategy to make sure that the snapshots you've taken are properly maintained. Note that the snapshots are not a complete copy of the DIT. They are really just a collection of disk blocks in the DIT that have been modified since the snapshot was taken. By combining these blocks with the current copy of the DIT, VSS can present the Active Directory DIT just as it appeared at the time of the snapshot. Figure 12 shows how to delete old or unneeded snapshots.

C:\> ntdsutil
ntdsutil: snapshot
snapshot: list all
 1: 2007/12/03:23:18 {42c44414-c099-4f1e-8bd8-4453ef2534a4}
 2:   C: {c0dd71ba-5bcd-4daf-9fbb-5cfbdd168022}
 3:   D: {2bbd739f-905a-431b-9449-11fba01f9931}
snapshot: delete 1
Snapshot {c0dd71ba-5bcd-4daf-9fbb-5cfbdd168022} mounted as C:\$SNAP_200712032318_VOLUMEC$\
Snapshot {2bbd739f-905a-431b-9449-11fba01f9931} mounted as C:\$SNAP_200712032318_VOLUMED$\
snapshot: quit
ntdsutil: quit

Mounting Active Directory Snapshots
In order to use one of these snapshots, you must first instruct Volume Shadow Copy Service to make the snapshot available to the file system. You do this using the ntdsutil command to list the available snapshots and then mount the snapshot you are interested in (see Figure 13).

C:\> ntdsutil
ntdsutil: snapshot
snapshot: list all
 1: 2007/12/03:23:18 {42c44414-c099-4f1e-8bd8-4453ef2534a4}
 2:   C: {c0dd71ba-5bcd-4daf-9fbb-5cfbdd168022}
 3:   D: {2bbd739f-905a-431b-9449-11fba01f9931}
snapshot: mount 1
Snapshot {c0dd71ba-5bcd-4daf-9fbb-5cfbdd168022} mounted as C:\$SNAP_200712032318_VOLUMEC$\
Snapshot {2bbd739f-905a-431b-9449-11fba01f9931} mounted as C:\$SNAP_200712032318_VOLUMED$\
snapshot: quit
ntdsutil: quit

The "list all" command lists all the available Active Directory snapshots that are currently being maintained by Volume Shadow Copy Service. The "mount 1" command mounts the selected snapshots of the Active Directory DIT and log volumes and makes them available in the file system. They are located at C:\$SNAP_200712032318_VOLUMEC$\ and C:\$SNAP_200712032318_VOLUMED$\.
If you look in these folders, you'll see the entire contents of those volumes as they were when the snapshot was taken. Note, however, that the mounted snapshots are read-only—meaning you can't modify any of the files in the mounted snapshot.

Recovering Data from Active Directory Snapshots
The task of mounting the snapshots of the volumes that contain Active Directory seems a bit like magic. How can you get to the Active Directory data contained in those snapshots? The secret is the DSAMAIN command. This is the executable that runs ADLDS. It is essentially a standalone LDAP server that shares almost all of its code with ADDS. You can use DSAMAIN to make the mounted snapshots look like a read-only LDAP server containing the Active Directory data as it was at the time the snapshot was taken.
Consider this command:

C:\> dsamain –dbpath
\ntds.dit -ldapport 10000

This mounts the ntds.dit file located in the c:\$snap_200712032318_volumed$\ntds\dit folder and makes it available to LDAP operations on TCP port 10000 (or whatever open port you specify). DSAMAIN will open the LDAPS port (the port used for LDAP over Secure Sockets Layer) on the port you specified plus one (in this case, 10001), the GC port (the port used for global catalog connections) on the port you specified plus two (10002), and the GCS (Global Catalog over Secure Sockets Layer) port on the port you specified plus three (10003).
You can use any LDAP program (such as LDP) to access the mounted DIT on the specified port. But in Windows Server 2008, Active Directory Users and Computers (ADUC), Sites and Services, and Domains and Trusts, as well as ADSIEDIT, have all been modified to allow you to connect them to a DIT mounted using DSAMAIN. If you right-click on the top-level node in the navigation pane of any ADUC and select Change Domain Controller, you will see the dialog box shown in Figure 14. If you simply type the name or IP address of the server hosting the mounted snapshot, along with the port (in my example, localhost:10000), ADUC will connect to the mounted snapshot, allowing you to browse the contents of the directory as it existed at the time of the snapshot. Pretty amazing, isn't it?
Figure 14 Connecting Active Directory users and computers to a mounted snapshot (Click the image for a larger view)
Being able to access directory data in this way makes many kinds of data recovery tasks much easier than they used to be. For instance, to recover a deleted object from a backup formerly required that you perform a non-authoritative restore of the backup on an existing DC and then perform an authoritative restore of the deleted object. And if the backup you restored didn't have the correct data, you had to start all over again with a different backup. Now, using tombstone reanimation and snapshots, you can quickly find and recover deleted data, and you don't even have to take the domain controller offline to do it.
There are some limitations, however. For instance, each active snapshot increases the disk I/O associated with write operations to the directory, so you probably shouldn't have more than one or two snapshots active at any point in time on a production DC. Also, the longer you keep snapshots active, the larger the Volume Shadow Copy Service delta store becomes—this can also affect performance. And, of course, simply recovering a deleted object is only the first part of the recovery problem. You will probably have to recover the object's linked attributes, such as group memberships, as well. But even in this case, the snapshot can help you identify all the groups the deleted object was a member of.

A Sound Backup and Recovery Strategy for Active Directory
Windows Server 2008 brings an entirely new backup and recovery system to the table. Some of the changes may at first cause weeping and gnashing of teeth. But once IT organizations have accepted these changes and incorporated the new backup technology into their day-to-day operations, they will wind up with a more effective backup and recovery implementation.
Even with all of the changes in the way you back up servers in Windows Server 2008, the basic strategy for backing up and recovering Active Directory doesn't really change that much. So when planning your strategy, be sure to keep these best practices in mind:
  • Schedule periodic full system backups so you can recover a DC after a hardware failure. How frequently you schedule full backups of a DC depends on how frequently your data is updated, your tolerance for downtime and/or data loss, and the effort that may be required to rebuild the DC from scratch.
  • Schedule frequent system state backups to back up changes in Active Directory. How frequently you perform system state backups depends on your tolerance for lost Active Directory data. But you should do this at least once a day. If you have the hardware, keep at least one or two system state backups on a local disk and copy older system state versions to a DVD or to a network share.
  • Be sure to do system state backups on at least two DCs in each domain. This will provide some insurance in case one of the backups is bad or unavailable.
Be sure to back up DCs with application partition replicas if you have defined them. And consider creating a Windows Recovery Environment partition on your DCs so you can boot quickly into WinRE in case a critical system drive fails. 

Gil Kirkpatrick is the CTO at NetPro and has been developing software for Active Directory since 1996. Along with Guido Grillenmeier from HP, he delivers the popular Active Directory Disaster Recovery workshops. Gil is also the founder of the Directory Experts Conference (see
© 2008 Microsoft Corporation and CMP Media, LLC. All rights reserved; reproduction in part or in whole without permission is prohibited.
© 2016 Microsoft