It was a Saturday morning and I was taking care of a few off-hours admin tasks when I got the e-mail message – something had gone wrong with an automated HR process and bad data had been propagated from an HR database into Active Directory.  The bad data had affected thousands of user accounts and subsequently hundreds of Exchange distribution groups.  Not the kind of thing any Exchange or Active Directory administrator wants to hear on any day of the week, let alone at the start of the weekend.

By the time I began working on the issue the source HR data had been fixed and re-synced to Active Directory, but there were still some issues – other automated processes had run causing attributes of objects to change in ways that would not be undone simply by backing out the bad data.

Thoughts of Active Directory restores were going through my mind – how quickly could I get access to the backups, how long would it take to restore, would I have to get tapes loaded, and so on.  Fortunately, some months earlier we had started upgrading our Active Directory domain controllers to Windows Server 2008 R2, and I had set up a scheduled task on one of them to create a nightly snapshot of Active Directory.

Snapshots are a feature of Active Directory introduced in Windows Server 2008.  In order to use them you don’t have to have your domain running in Windows Server 2008 mode but you do need at least one Windows Server 2008 or Windows Server 2008 R2 domain controller.

Snapshots are created and manipulated using the ntdsutil.exe command line utility.  Once you have an Active Directory snapshot you can export it using dsamain.exe (otherwise known as the Active Directory database mounting tool), and you can then interact with it using any Active Directory or LDAP tool.  To work with Active Directory snapshots you need to be a member of either the Domain Admins or Enterprise Admins group.

The process of creating an Active Directory snapshot is reasonably straightforward:

1. Log onto a Windows Server 2008 domain controller
2. Launch an elevated command prompt
3. Type ntdsutil and press enter
4. Type snapshot and press enter
5. Type activate instance ntds and press enter.
6. Type create and press enter.

   The create command will return the following output:

   1	Snapshot set {<GUID>} generated successfully.

7. Type quit and press enter to return to the ntdsutil menu, then type quit again.

   

A snapshot can also be created with a single line ntdsutil.exe command:

The single line command can be used to automate the creation of Active Directory snapshots by putting it in a batch file and using Task Scheduler to automate its execution (with the appropriate credentials).

Once snapshots have been created they can be listed with the ntdsutil.exe list all command:

A snapshot is then mounted using the mount command:

After the snapshot is mounted you can quit ntdsutil.

To export the data we use the dsamain.exe command line utility with the following syntax:

Once the snapshot is exported with dsamain.exe you can connect to the LDAP server which it hosts using the familiar suite of Active Directory tools such as Active Directory Users and Computers or ADSIEdit.  For example, to connect using Active Directory Users and Computers:

1. Launch Active Directory Users and Computers
2. Right-click Active Directory Users and Computers then click Change Domain Controller
3. Click <Type a Directory Server name[:port] here>, type the name of the Directory Server and port, press enter, then click OK

Active Directory Users and Computers is now accessing the snapshot data, and you will notice that the object attributes are read-only.

ADUC is good for browsing data to see the historic state which can be useful for looking at individual changes over time, but in my case I needed to restore attributes to a few hundred broken distribution groups.  I needed a method which would allow me to automate this recovery, and the cmdlets and provider included in the Active Directory PowerShell Module were perfect for what I wanted to do.

The Active Directory PowerShell Module is a new feature included in Windows Server 2008 R2 and Windows 7.  It includes a PowerShell provider for Active Directory, and many cmdlets for manipulating Active Directory objects.  It’s automatically installed on Windows Server 2008 R2 domain controllers and it can be installed as part of the Remote Server Administration Tools (RSAT) feature on Windows Server 2008 R2 or Windows 7.  To use the Active Directory PowerShell Module you must have at least one Windows Server 2008 R2 domain controller in your domain.

To launch the Active Directory PowerShell Module log onto a Windows Server 2008 R2 or Windows 7 machine, click Start, Administrative Tools, Active Directory Module for Windows PowerShell.

As the Active Directory PowerShell module loads it will automatically connect a PSDrive to the ActiveDirectory provider, which gives the shell access to the live Active Directory instance.  It is also possible to connect a PSDrive to an Active Directory snapshot which is exported with dsamain.exe by using the New-PSDrive cmdlet and specifying the server and port on which the exported snapshot is running.  For example:

For more information on using the Active Directory PowerShell module and the ActiveDirectory provider you should read Jonathan Medd’s November 2009 Simple-Talk article on the subject – Active Directory Management with PowerShell in Windows Server 2008 R2

As an alternative to using a PSDriveprovider, individual objects contained in the snapshot can also be accessed directly using the Get-* cmdlets implemented in the Active Directory PowerShell module.  For example, the command will retrieve the details of the user account named “ben” from a snapshot exported on port 10389 of the domain controller server01:

               

So we can see that Active Directory snapshots provide a mechanism for capturing Active Directory state, and the Active Directory PowerShell module provides powerful and flexible tools for working with the snapshot data.

Now back to my problem.  I knew that the data I needed to restore was in an Active Directory snapshot which was taken by a scheduled task the day before the data was corrupted.  All I had to do was mount the snapshot, export it, and then use Active Directory PowerShell to enumerate all the objects I needed to fix, retrieving the good data from the Active Directory snapshot and updating the live objects in Active Directory.

As an example of what I needed to do, imagine that the department and job title attributes of all users have been erased from Active Directory.  You have a snapshot which was taken before the attributes were erased, and it is mounted and exported on port 10389 of a server named server01.example.com.  This short PowerShell script will restore the two missing attributes from the snapshot:

Bear in mind that this is a simple example to illustrate what is possible.  In a real situation you will want to limit the users being retrieved in the initial query by using an appropriate filter, and to avoid errors you should implement checking to ensure that each production object actually exists in the snapshot (to account for objects which were created after the snapshot was taken).

The scenario I’ve illustrated is just one sample of what is possible with Active Directory snapshots.  Because once they are mounted they can be accessed by any LDAP tool which allows the user to specify a host name and port number, they are a very flexible and convenient way of browsing or recovering historic Active Directory data.  My advice is that if you have a Windows 2008 Directory Server in your domain you should create a scheduled task to take regular Active Directory snapshots – you never know when it might save the day.