The O=Boot NC and the distribution DIT

So every Windows Server has an NTDS.dit file right? Well, All Windows Server – Domain Controllers you mean right? Nope they in fact have two J

There is something referred to as the distribution DIT that works as a template DIT and is used when you promote a machine to a DC (either ADAM/ADLDS or ADDS) either as the first dc in a forest or as a replica.

The distribution DIT can be found at the following location:

Table 1: Distribution DIT Location





ADDS %windir%\system32\ntds.dit N/A Windows 2000 Server


Windows Server 2003

ADDS %windir%\system32\ntds.dit Yes Windows Server 2008


Windows Server 2008 R2

Windows Server 2012

Windows Server 2012 R2

ADAM/ADLDS %windir%\ADAM\adamntds.dit N/A Windows XP * Separate download


Windows Server 2003 * Separate download or R2

ADAM/ADLDS %windir%\ADAM\adamntds.dit Yes Windows Vista * Separate download


Windows 7 * Separate download

Windows 8

Windows Server 2008

Windows Server 2008 R2

Windows Server 2012

Windows Server 2012 R2

Note: SxS means that the files are package in the SxS folder on the disk and isn’t copied into the location until the actual role is installed.

So what is the Distribution DIT and when is it used?

It’s actually the DIT all DCs start out with except one case

  1. IFM promoted replicas; they start with the IFM source DC as there DIT.
    For more information on Install From Media (IFM), see the following post:


The distribution DIT is copied to the database location (DatabasePath) specified in DCPROMO during promotion, we can verify this by checking the JET database signature of the two databases once DCPROMO has completed, in my case I compare between the distribution DIT for ADLDS and my installed ADLDS instance ‘ESEDEV’

  1. Distribution DIT:
  1. Installed/Promoted DIT:

As you can see – They do match.

So what does the Distribution DIT contains?

The distribution DIT contains the base schema for either ADDS or ADLDS (that has a more light weight schema that ADDS) – So here my tool ESEDump comes into play, let’s dump a distribution DIT for ADLDS:

Dumping table datatable:

We can see that the first rows inside the distribution DIT contains O=Boot and CN=Schema,O=Boot, CN=BootMachine,O=Boot and then simpely the schema comes, we can see that all of the schema objects has a PDNT that equals == 5, the DNT of the CN=Schema,O=Boot naming context (NC) – Or wait are they really NCs? – let’s add in ‘instanceType’

Yes they are NCs – InstanceType decoded as follows:

  1. 0x5 (05) == ( IS_NC_HEAD | WRITE );
  2. 0xD (13) = = ( IS_NC_HEAD | WRITE | NC_ABOVE );

More information on the instance-type attribute can be found here:

So what is CN=BootMachine? This is a fake DSA so that the code can use common routines during install (Can’t explain it better than starting an entire new article – might happen someday)

So what happens during install?

So it’s time to determine how the schema in the distribution DIT is used during install (or promotion of a new domain controller) – well it depends – if it’s used at all.

These are the different cases.

  1. Promoting the first domain controller in a forest:


    1. The distribution DIT is copied into the database location (DatabasePath) specified in DCPROMO.
    2. A domain naming context is created in the DIT (except for ADAM/ADLDS)
    3. A configuration naming context is created in the DIT.
    4. A schema naming context is created in the DIT.
    5. The boot schema is moved from CN=Schema,O=Boot to the newly create schema naming context.

      During this move the following happens for all objects that has a PDNT of:4 e.g. the CN=Schema,O=Boot:

      1. Object’s are moved to CN=Schema,CN=Configuration,X=foo
      2. As the object’s are moved their ancestors_col must be updated in the DIT to inheritance from the new CN=Schema,CN=Configuration,X=foo
      3. As the object’s are moved from one naming context (NC) (CN=Schema,O=Boot) to another (CN=Schema,CN=Configuration,X=foo) their NCDNT_col in the DIT needs to be updated as well.
      4. Object’s have their metadata updated , fields updated are:
        1. OriginatingDsa
        2. timeChanged
      5. Give the object a new GUID.
      6. Set a default security descriptor depending on ADDS or ADLDS and depending on if attribute or class.
    6. The prefixMap is read of CN=Schema,O=Boot and saved into the prefixMap of CN=Schema,CN=Configuration,X=foo
      More information on the prefixMap/prefixTable can be found here:


      Note: This allows the distribution DIT to contain schema entries that the DSA doesn’t have knowledge about (e.g. other attributes and classes than the base schema can come pre-loaded) – This used to be the case for Small Business Server that pre-loaded the Exchange Schema.

      1. Removing CN=BootMachine,O=Boot
      2. Removing CN=Schema,O=Boot
      3. Removing O=Boot
  2. Promoting a replica in an already existing forest:
    1. Remove the following as a schema already exists in the enterprise and will be replicated in.
      1. Removing all object’s with a PDNT of 4 == e.g. all objects that have CN=Schema,O=Boot as parent.
      2. Removing CN=BootMachine,O=Boot
      3. Removing CN=Schema,O=Boot
      4. Removing O=Boot


Both in case A (First DC in the forest) and case B (Replica in an existing forest) – the install code will trigger the garbage collector so it can immediately delete all traces of the O=Boot naming context (NC) and its decadent object’s.

For more information on the garbage collector have a look at:

This article started out by a question that was – How can the Schema naming context (NC) has a higher USN than many of the attributes in the schema – Doesn’t the schema container have to be created first, before its child objects? – Well we know the answer to that question already but let’s confirm it.

Let’s get the “usnCreated” on the Schema naming context (NC):

Ok, it’s 4100.

Let’s try an attribute “Account-Expires”

OK, that’s a pretty low “usnCreated” and much lower than the Schema naming context (NC) above.

So let’s look up the “Account-Expires” in the distribution DIT:

Yes , “usnCreated” is 6 in the distribution DIT as well, with other words “usnCreated” will come from the distribution DIT for base schema object’s, hence they have a lower usnCreated than the schema naming context (NC) itself.


3 Replies to “The O=Boot NC and the distribution DIT”

    1. Yes I will consider upgrading, Have you added support for Windows Server 2012 R2 stuff like fBASEONLY, 0x00000800 (2048)? – would be nice in -flagdc and hitting a such attr during a subtree search isn’t that nice?

Leave a Reply

Your email address will not be published. Required fields are marked *