Using dsamain to browse disconnected ntds.dit

If you want to peek into the past contents of your Active Directory, you used to have to perform a complete server restore. (By used to, I mean server 2003)

Server 2008 has a tool that allows you to mount the ntds.dit file from your backup as an LDAP server, which can then be browsed using ADSI Edit. Once you get it to work, it is much quicker than a full backup if you are able to extract just the database files. The first step is to install the AD DS role on a member server – I would not recommend doing this on a domain controller proper. This will get you the tools you need to proceed.

As usual, I am posting this because the internet demonstrated epic fail when it came to debugging the process.
When I first attempted to use dsamain.exe on the ntds.dit file, I received the following errors:

dsamain /dbpath ntds.dit /ldapport 1492
EVENTLOG (Error): NTDS General / Internal Processing : 1168
Internal error: An Active Directory Domain Services error has occurred.
Error value (decimal): -550
Error value (hex): fffffdda
Internal ID: 40878
EVENTLOG (Error): NTDS General / Internal Processing : 1003
Active Directory Domain Services could not be initialized.
The directory service cannot recover from this error.

Because my AD database copy was taken in a “naughty” manner, the solution to this issue is to use the esentutl utility to recover the database (apply the log files) then repair the database.
I had a heck of a time with esentutl not working at first – it complained about missing references and such. The solution:
1. Make sure you have the database file AND the log files. Sometimes these are placed on separate volumes
2. the ESENTUTL recovery command takes a 3-character logfile prefix as the parameter, NOT the database file name
3. The utility determines the database file path from the logfiles. You need to place all the files from your original Domain Controller into the same folder on your member server (eg: C:\windows\NTDS). If esentutl complains, you may need to check your paths.
4. Open an elevated command prompt, change the folder containing your files, and run “esentutl /r edb” It should just work

Next, check the integrity of the database. It will probably find some errors
“esentutl /g ntds.dit”

Finally, run a repair on the database, and be sure to click “Yes” (or OK) on the prompt
“esentutl /p ntds.dit”

Now you can use dsamain to try mounting the database:
“dsamain /dbpath ntds.dit /ldapport 1492”

If you are like me, you will get an error along the lines of 1809 JET_errPermissionDenied, Permission denied
(meta note: the phrase “JET_errPermissionDenied” was painfully absent from any meaningful pages in the internet before now.)

The solution to this error: use the allowupgrade option when running dsamain. (I’m guessing this is happening because the member server is not running the same exact version of AD DS as the Domain Controller).

Using this command:
“dsamain /dbpath ntds.dit /ldapport 1492 /allownonadminaccess /allowupgrade”

It updated the database, and mounted the sucker. (I do receive an error about exclusive access to a port – haven’t resolved it, but as long as your LDAP port is ok, you should be fine)

Now run ADSI Edit, connect to localhost:1492 (or your port of choice) select your desired naming context, and enjoy the time travelling experience!

Group policy application errors

I recently encountered a server that was having problems applying group policy. I encountered the following errors:

Log: Application
Source: Group Policy Registry
Event ID: 8194
Message:The client-side extension could not remove user policy settings for 'GPONAME {n-n-n-n-n}' because it failed with error code '0x8007000d The data is invalid.' See trace file for more details.
Log: System
Source: GroupPolicy
Event ID: 1085
Message: Windows failed to apply the Group Policy Registry settings. Group Policy Registry settings might have its own log file. Please click on the "More information" link.


The More info link is useless -don’t waste your time. Also, it would appear there is no trace file. Searching for these errors on Google will get you suggestions about deleting GPOs on the Domain controller, but the thing is, I need this GPO.

To diagnose this issue, you will first need to enable Group Policy tracing. On the machine having the problems, open up the local group policy editor (run gpedit.msc) and browse to:

Computer Policy \ Administrative Templates \ System \ Group Policy \ Logging and tracing

This contains a list of all the Group Policy Modules / extensions. Select the one that matches the error message in the system event log. (In my case, it was Registry Policy Processing)
enable the policy, change Tracing to “On” and click Ok.

Now open an elevated (Run as Administrator) command prompt, and type gpupdate. This should get the errors to throw again, but this time it will write out a trace file.

You should be able to find that trace file in C:\ProgramData\GroupPolicy\Preference\Trace\User.log. Open it up and look for a line containing “The data is Invalid”. You should see something like the following:

GPH data file : C:\ProgramData\Microsoft\Group Policy\History\{...-...-...-...-...}\S-1-5-21-...-...-...-...\Preferences\Registry\Registry.xml
Completed parse of GPH XML. [ hr = 0x8007000d "The data is invalid." ]
Completed remove GPH. [ hr = 0x8007000d "The data is invalid." ]
Leaving ProcessGroupPolicyExRegistry() returned 0x8007000d

The filename after GPH data file is the corrupt file. Most likely is is an empty XML File. I just renamed the folder C:\ProgramData\Microsoft\Group Policy\History\{guid}\{sid} to be {sid}.bak.

(Note: you may need to change your folder options to be able to access the file)

Now run gpupdate again, and it should recreate the history file with the correct contents. Problem solved!

Finally, remember to disable the tracing.