Rich Peckham's Technical Blog https://docs.microsoft.com/archive/blogs/richpec/feed.xml Active Directory, Group Policy, Disaster Recovery, DNS, DFS, and other Directory Services issues. Wed, 17 Apr 2019 03:51:58 GMT en-US hourly 1 The Authoritative Restore Explained https://docs.microsoft.com/archive/blogs/richpec/the-authoritative-restore-explained Thu, 06 Oct 2011 21:22:00 GMT https://blogs.msdn.microsoft.com/richpec/2011/10/06/the-authoritative-restore-explained/  (....well... in more detail)

This blog posting is for the purposes of explaining the mechanism behind the authoritative restore within Active Directory. While there are many documents out there explaining step-by-step instructions of how to perform authoritative restores and the logic behind it, I feel there’s some information missing from these documents and, hence, this blog posting.

To start off, let’s define some logistics.

This blog does not delve into the mechanics behind Active Directory Replication. It is assumed certain concepts such as USNs, high-watermark, or up-to-dateness vector are already understood. The following article explains these concepts in great detail.

How the Active Directory Replication Model Works
https://technet.microsoft.com/en-us/library/cc772726(WS.10).aspx

Although I don’t dive into how replication works I’d like to start with some definitions as I feel it is important to this blog.

Update Sequence Number (USN)
For every change that occurs on a domain controller (whether replicated inbound or an originating write) the update sequence number is incremented by one.

Highest Committed USN
This is held within RootDSE on every domain controller and is the highest USN committed to the database for that server. This is an attribute of RootDSE and is not replicated to the other domain controllers.

Originating Update
A domain controller that sets an attribute or builds an object performs an originating update of that attribute or object. The originating update can be seen within the metadata of the object and is used for interpreting which domain controller performed the change to an object.

High-Watermark
Each destination DC contains a high-watermark value of its interpretation of the upstream (or source) DC’s highest committed USN. If DC2’s high-watermark for DC1 is 3000 then DC1 can assume that DC2 already has knowledge of all changes less than or equal to USN 3000. The high-watermark is per replication link and knowledge a DC has of each direct replication partner. Although there may be hundreds of DCs within a domain, it’s possible DC2 only replicates with a handful of them and, therefore, would only have knowledge of the high-watermark of those DCs. The high-watermark prevents irrelevant objects from being considered by the source domain controller with respect to a single destination.

Up-to-Dateness Vector
Any DC that has ever made an originating update will have an entry in the up-to-dateness vector. This is per partition. We use the up-to-dateness vector to determine (rather filter out) attributes to objects that a downstream replication partner may have already received from a different source DC. Each DC has its own copy of the up-to-dateness vector for all domain controllers that replicate a specific partition.

Version
For the purposes of this blog, the term “version” refers to the version number of an attribute. As discussed within this blog, an authoritative restore of an object will increment the version number of every attribute by a specific value (discussed later).

DSA Object GUID
The Globally Unique Identifier of a domain controller.

DSA Invocation ID
The GUID of the Active Directory database (ntds.dit). The Invocation ID is used to uniquely identify a database and it changes during the restore process of Active Directory.

 

The Beginning

The environment, discussed in this blog, consists of only two domain controllers (DC1 and DC2) for a domain called contoso.com.

After creating the environment, repadmin /showrepl /v against each DC shows:

DC1

Default-First-Site-Name\DC1
DSA Options: IS_GC
Site Options: (none)
DSA object GUID: 9628bc8f-fa40-4c72-ac57-99ef34fe3f4f
DSA invocationID: 9628bc8f-fa40-4c72-ac57-99ef34fe3f4f

(Notice the DC GUID and Invocation ID GUID are the same for DC1. This is because it was the first domain controller promoted into the forest and, therefore, gets the same GUID for both.)

DC2

Default-First-Site-Name\DC2
DSA Options: IS_GC
Site Options: (none)
DSA object GUID: 5ad77be3-1e89-4bba-bd7c-c78a03860204
DSA invocationID: e7d0d6bb-056c-45b1-b752-1d6900e3b9e5

 

Out of the box, the up-to-dateness vector for the DC=contoso,DC=com partition on DC1 showed:

Caching GUIDs.

Default-First-Site-Name\DC1          @ USN     13190 @ Time 2011-10-04 21:11:39
Default-First-Site-Name\DC2          @ USN     12755 @ Time 2011-10-04 21:07:39

Out of the box, the up-to-dateness vector for the DC=contoso,DC=com partition on DC2 showed:

Caching GUIDs.

Default-First-Site-Name\DC1          @ USN     13185 @ Time 2011-10-04 21:10:14
Default-First-Site-Name\DC2          @ USN     12778 @ Time 2011-10-04 21:11:58

One thing to note is that it’s likely that interrogating the up-to-dateness vector on both domain controllers at the same time won’t show the same USN values. This is due to convergence within Active Directory. There’s always something going on. Active Directory replication is loosely consistent and we assume we’ll eventually converge.

 

First things first, let’s demote DC2. Why? This would be to illustrate a change in Invocation ID. Before the demotion, let’s look at the replication status of DC1:

Repadmin /showrepl DC1 /v shows:

Default-First-Site-Name\DC1
DSA Options: IS_GC
Site Options: (none)
DSA object GUID: 9628bc8f-fa40-4c72-ac57-99ef34fe3f4f
DSA invocationID: 9628bc8f-fa40-4c72-ac57-99ef34fe3f4f

==== INBOUND NEIGHBORS ======================================

DC=contoso,DC=com
    Default-First-Site-Name\DC2 via RPC
        DSA object GUID: 5ad77be3-1e89-4bba-bd7c-c78a03860204
        Address: 5ad77be3-1e89-4bba-bd7c-c78a03860204._msdcs.contoso.com
        DSA invocationID: e7d0d6bb-056c-45b1-b752-1d6900e3b9e5

(Notice the DSA invocation ID for the inbound partner DC2.)

 

After a demotion of DC2 and another DCPromo promotion of DC2, the repadmin /showrepl /v configuration of DC2 shows:

Default-First-Site-Name\DC2
DSA Options: IS_GC
Site Options: (none)
DSA object GUID: 8913255f-89c3-4954-ab3f-3148f7303320
DSA invocationID: 43c7f173-db0f-4ddb-aff0-ad50717729c9

Notice the DC GUID and Invocation ID both changed. This comes into play later.

 

The up-to-dateness vector for the DC=contoso,DC=com partition on DC1 now shows:

Caching GUIDs.

Default-First-Site-Name\DC2          @ USN     12399 @ Time 2011-10-04 21:26:04
Default-First-Site-Name\DC1          @ USN     13414 @ Time 2011-10-04 21:30:22
e7d0d6bb-056c-45b1-b752-1d6900e3b9e5 @ USN     12778 @ Time 2011-10-04 21:12:08

(Recall that the database GUID of DC2 used to be e7d0d6bb-056c-45b1-b752-1d6900e3b9e5. It is still in the up-to-dateness vector.)

 

The command repadmin /showrepl DC1 /v shows the following information about DC2:

Default-First-Site-Name\DC1
DSA Options: IS_GC
Site Options: (none)
DSA object GUID: 9628bc8f-fa40-4c72-ac57-99ef34fe3f4f
DSA invocationID: 9628bc8f-fa40-4c72-ac57-99ef34fe3f4f

==== INBOUND NEIGHBORS ======================================

DC=contoso,DC=com
    Default-First-Site-Name\DC2 via RPC
        DSA object GUID: 8913255f-89c3-4954-ab3f-3148f7303320
        Address: 8913255f-89c3-4954-ab3f-3148f7303320._msdcs.contoso.com
        DSA invocationID: 43c7f173-db0f-4ddb-aff0-ad50717729c9
        SYNC_ON_STARTUP DO_SCHEDULED_SYNCS WRITEABLE
        USNs: 12329/OU, 12329/PU
        Last attempt @ 2011-10-04 21:26:07 was successful.

(The above values for USNs represent DC1’s high-watermark knowledge of DC2 for the partition DC=contoso,DC=com.)

(The remainder of the repadmin /showrepl command has been snipped.)

 

So we just discussed that the up-to-dateness vector keeps records of domain controllers that have been demoted. This is to maintain history of DCs we’ve replicated with in the past. What if I were to restore a backup of DC2 at this point? We’ll cover that in a bit.

First, let’s talk about where this up-to-dateness vector is stored. The up-to-dateness vector is per partition and, therefore, is stored as attributes of a particular partition. In this case, the partition of interest is DC=contoso,DC=com. The attribute we query for is replUpToDateVector. This attribute is not a replicated attribute and looks different depending on which DC is interrogated.

To illustrate this I used LDP and searched for the replUpToDateVector attribute for each DC.

LDP connection to DC1:

***Searching...

ldap_search_s(ld, "DC=contoso,DC=com", 2, "(replUpToDateVector=*)", attrList,  0, &msg)
Getting 1 entries:
Dn: DC=contoso,DC=com
replUpToDateVector: dwVersion: 2, dwReserved1: 0, V2.cNumCursors: 2, V2.dwReserved2: 0, rgCursors:
               {uuidDsa: 43c7f173-db0f-4ddb-aff0-ad50717729c9, usnHighPropUpdate: 12459, timeLastSyncSuccess: 10/04/2011 21:31:32},
               {uuidDsa: e7d0d6bb-056c-45b1-b752-1d6900e3b9e5, usnHighPropUpdate: 12778, timeLastSyncSuccess: 10/04/2011 21:12:08},;

LDP connection to DC2:

***Searching...

ldap_search_s(ld, "DC=contoso,DC=com", 2, "(replUpToDateVector=*)", attrList,  0, &msg)
Getting 1 entries:
Dn: DC=contoso,DC=com
replUpToDateVector: dwVersion: 2, dwReserved1: 0, V2.cNumCursors: 2, V2.dwReserved2: 0, rgCursors:
               {uuidDsa: 9628bc8f-fa40-4c72-ac57-99ef34fe3f4f, usnHighPropUpdate: 13435, timeLastSyncSuccess: 10/04/2011 21:40:17},
               {uuidDsa: e7d0d6bb-056c-45b1-b752-1d6900e3b9e5, usnHighPropUpdate: 12778, timeLastSyncSuccess: 10/04/2011 21:12:08},;

Notice both domain controllers have knowledge of the original DC2 (uuidDsa e7d0d6bb….) as well as knowledge of the highest propagated update (12778) and the last time it synchronized (10/04/2011 at 9:12:08 p.m.).

Each DC also has knowledge in the up-to-dateness vector for all other domain controllers that replicate a partition. In the up-to-dateness vector for the partition DC=contoso,DC=com on DC1 you will see it does not hold knowledge of its own uuidDsa. The same is true for DC2.

 

Domain Controller Restore Process and the Invocation ID

So now that we’ve discussed the mechanics behind it, let’s discuss what happens when a domain controller is restored from backup.

As you may have read, when a restore operation of a domain controller is performed, we keep the DSA Object GUID the same but the DSA Invocation ID is recreated with a random GUID. This process informs downstream replication partners that a DC restore operation has been performed. When the backup was created, the highestCommittedUSN value was at a lower number than what every other domain controller remembered of DC1 before the restore process.

By modifying the Invocation ID it informs the downstream replication partners of this restore operation and we can get around USN rollback scenarios. It also instructs DC1’s replication partners to send all updates from highestCommittedUSN (x) to highestCommittedUSN (y) where X is the value at the time of the backup and Y is the value at the time DC1 went down to perform the restore.

So let’s look at this. I took a system state backup of DC1 and then restored the backup.

Repadmin /showrepl DC2 /v

Default-First-Site-Name\DC2
DSA Options: IS_GC
Site Options: (none)
DSA object GUID: 8913255f-89c3-4954-ab3f-3148f7303320
DSA invocationID: 43c7f173-db0f-4ddb-aff0-ad50717729c9

==== INBOUND NEIGHBORS ======================================

DC=contoso,DC=com
    Default-First-Site-Name\DC1 via RPC
        DSA object GUID: 9628bc8f-fa40-4c72-ac57-99ef34fe3f4f
        Address: 9628bc8f-fa40-4c72-ac57-99ef34fe3f4f._msdcs.contoso.com
        DSA invocationID: 1f4b741a-6409-4eb6-996b-0f5f7417646a
        SYNC_ON_STARTUP DO_SCHEDULED_SYNCS WRITEABLE
        USNs: 24637/OU, 24637/PU
        Last attempt @ 2011-10-05 20:11:14 was successful.

(The rest of the repadmin /showrepl output has been snipped.)

Repadmin /showrepl DC1 /v

Default-First-Site-Name\DC1
DSA Options: IS_GC
Site Options: (none)
DSA object GUID: 9628bc8f-fa40-4c72-ac57-99ef34fe3f4f
DSA invocationID: 1f4b741a-6409-4eb6-996b-0f5f7417646a

==== INBOUND NEIGHBORS ======================================

DC=contoso,DC=com
    Default-First-Site-Name\DC2 via RPC
        DSA object GUID: 8913255f-89c3-4954-ab3f-3148f7303320
        Address: 8913255f-89c3-4954-ab3f-3148f7303320._msdcs.contoso.com
        DSA invocationID: 43c7f173-db0f-4ddb-aff0-ad50717729c9
        SYNC_ON_STARTUP DO_SCHEDULED_SYNCS WRITEABLE
        USNs: 14407/OU, 14407/PU
        Last attempt @ 2011-10-05 20:11:20 was successful.

 (The rest of the repadmin /showrepl output has been snipped.)
 

Looking at the /showrepl output from both domain controllers, you can see that the DSA InvocationID for DC1 has changed; however, the DSA Object GUID remains the same.

DSA object GUID: 9628bc8f-fa40-4c72-ac57-99ef34fe3f4f
DSA invocationID: 1f4b741a-6409-4eb6-996b-0f5f7417646a

 

Repadmin /showutdvec DC1 DC=contoso,DC=com /nocache

1f4b741a-6409-4eb6-996b-0f5f7417646a @ USN     24668 @ Time 2011-10-05 20:15:09
43c7f173-db0f-4ddb-aff0-ad50717729c9 @ USN     14452 @ Time 2011-10-05 20:11:16
9628bc8f-fa40-4c72-ac57-99ef34fe3f4f @ USN     13972 @ Time 2011-10-05 18:17:27
e7d0d6bb-056c-45b1-b752-1d6900e3b9e5 @ USN     12778 @ Time 2011-10-04 21:12:08

Repadmin /showutdvec DC2 DC=contoso,DC=com /nocache

1f4b741a-6409-4eb6-996b-0f5f7417646a @ USN     24663 @ Time 2011-10-05 20:14:04
43c7f173-db0f-4ddb-aff0-ad50717729c9 @ USN     14482 @ Time 2011-10-05 20:14:58
9628bc8f-fa40-4c72-ac57-99ef34fe3f4f @ USN     13972 @ Time 2011-10-05 18:17:27
e7d0d6bb-056c-45b1-b752-1d6900e3b9e5 @ USN     12778 @ Time 2011-10-04 21:12:08

 

Here’s the recap:

9628bc8f…. was the original DC1 that was just restored.
E7d0d6bb… was the original DC2 that was demoted at the beginning.
1f4b741a… is the new DC1.
43c7f173… is DC2.

 

Using LDP, I again performed a search on both domain controllers for the replUpToDateVector.

 

DC1

***Searching...

ldap_search_s(ld, "DC=contoso,DC=com", 2, "(replUpToDateVector=*)", attrList,  0, &msg)
Getting 1 entries:
Dn: DC=contoso,DC=com
replUpToDateVector: dwVersion: 2, dwReserved1: 0, V2.cNumCursors: 3, V2.dwReserved2: 0, rgCursors:
               {uuidDsa: 43c7f173-db0f-4ddb-aff0-ad50717729c9, usnHighPropUpdate: 14452, timeLastSyncSuccess: 10/05/2011 20:11:16},
               {uuidDsa: 9628bc8f-fa40-4c72-ac57-99ef34fe3f4f, usnHighPropUpdate: 13972, timeLastSyncSuccess: 10/05/2011 18:17:27},
               {uuidDsa: e7d0d6bb-056c-45b1-b752-1d6900e3b9e5, usnHighPropUpdate: 12778, timeLastSyncSuccess: 10/04/2011 21:12:08},;

 
DC2

***Searching...

ldap_search_s(ld, "DC=contoso,DC=com", 2, "(replUpToDateVector=*)", attrList,  0, &msg)
Getting 1 entries:
Dn: DC=contoso,DC=com
replUpToDateVector: dwVersion: 2, dwReserved1: 0, V2.cNumCursors: 3, V2.dwReserved2: 0, rgCursors:
               {uuidDsa: 1f4b741a-6409-4eb6-996b-0f5f7417646a, usnHighPropUpdate: 24679, timeLastSyncSuccess: 10/05/2011 20:17:41},
               {uuidDsa: 9628bc8f-fa40-4c72-ac57-99ef34fe3f4f, usnHighPropUpdate: 13972, timeLastSyncSuccess: 10/05/2011 18:17:27},
               {uuidDsa: e7d0d6bb-056c-45b1-b752-1d6900e3b9e5, usnHighPropUpdate: 12778, timeLastSyncSuccess: 10/04/2011 21:12:08},;

 
So, in a nutshell, that’s how the restore process works. There is an additional feature of NTBackup that adds some registry settings during a restore process of the system state. When performing a system state restore using NTBackup, a new key is created called Restore in Progress. This is located under:

HKLM\System\CurrentControlSet\Services\NTDS\Restore In Progress

Information about this key can be found in the following support article:

Description of the “Restore in Progress” Registry Key in Active Directory
https://support.microsoft.com/kb/814167

An important registry setting for the restore operation is called New Database GUID located in HKLM\System\CurrentControlSet\Services\NTDS\Parameters. This registry setting supplies the new DSA InvocationID to be used after the restore process is complete.

 

 

Authoritative Restore of Joe User

Next let’s create a user (Joe User) and then do some authoritative restores.

Created Joe User (sAMAccountName joeuser) on DC2.

Repadmin /showobjmeta DC2 “CN=joe user,CN=Users,DC=contoso,DC=com”

     26 entries.

     Loc.USN       Originating DSA                       Org.USN       Org.Time/Date              Ver       Attribute
     =======    ===============      =========   =============       ===   =========
       14550          Default-First-Site-Name\DC2     14550         2011-10-05 20:26:16         1     objectClass
       14550          Default-First-Site-Name\DC2     14550         2011-10-05 20:26:16         1     cn
       14550          Default-First-Site-Name\DC2     14550         2011-10-05 20:26:16         1     sn
       14550          Default-First-Site-Name\DC2     14550         2011-10-05 20:26:16         1     givenName
       14550          Default-First-Site-Name\DC2     14550         2011-10-05 20:26:16         1     instanceType
       14550          Default-First-Site-Name\DC2     14550         2011-10-05 20:26:16         1     whenCreated
       14550          Default-First-Site-Name\DC2     14550         2011-10-05 20:26:16         1     displayName
       14550          Default-First-Site-Name\DC2     14550         2011-10-05 20:26:16         1     nTSecurityDescriptor

(The rest of the output has been snipped.)

From here I need to explain what happens when an object is authoritatively restored from a system state backup. There are many documents on the Internet stating that the version number of each attribute for an object will increase by 100,000 versions. Some state the version of each attribute will increase 100,000 versions total while others state the version will increase by 100,000 versions per day since the last backup was taken.

Neither of these statements are true.

Without creating a backup at all, using Windows Server 2008, I stopped the Active Directory Domain Services (NOT supported; always reboot into Directory Services Restore Mode) and performed these actions on DC1:

Net stop ntds
Changed the date ahead 2 days
Ntdsutil
Activate instance NTDS
Authoritative restore
Restore object “CN=Joe User,CN=Users,DC=contoso,DC=com”
Restored the object
Net start ntds

Repadmin /showobjmeta DC1 “CN=joe user,CN=users,DC=contoso,DC=com”

     27 entries.

     Loc.USN       Originating DSA                       Org.USN       Org.Time/Date              Ver       Attribute
     =======    ===============      =========   =============       ===   =========
       14612          Default-First-Site-Name\DC1     28675         2011-10-07 20:29:35    300001    objectClass
       14611          Default-First-Site-Name\DC2     14611         2011-10-07 20:30:23              2    cn
       14612          Default-First-Site-Name\DC1     28675         2011-10-07 20:29:35    300001    sn
       14612          Default-First-Site-Name\DC1     28675         2011-10-07 20:29:35    300001    givenName
       14612          Default-First-Site-Name\DC1     28675         2011-10-07 20:29:35    300001    instanceType
       14550          Default-First-Site-Name\DC2     14550         2011-10-05 20:26:16              1    whenCreated
       14612          Default-First-Site-Name\DC1     28675         2011-10-07 20:29:35    300001    displayName
       14612          Default-First-Site-Name\DC1     28675         2011-10-07 20:29:35    300000    isDeleted

(The rest of the output has been snipped.)

Notice that the version number has increased by 300,000. This is equal to “today + 2 days” or 3 days total.

Deleted Joe User
Changed the date back to the correct date
Created Joe User on DC2
Output of showobjmeta is similar to original Joe User object
Net stop ntds
Changed the date forward 11 days
Ntdsutil
Activate Instance NTDS
Authoritative restore
Restore object “CN=joe user,CN=Users,DC=contoso,DC=com”
Restored the object
Net start ntds 

Repadmin /showobjmeta DC1 “CN=joe user,CN=Users,DC=contoso,DC=com”
 

     27 entries.

     Loc.USN       Originating DSA                       Org.USN       Org.Time/Date              Ver       Attribute
     =======    ===============      =========   =============       ===   =========
      14691          Default-First-Site-Name\DC1     32772        2011-10-18 20:33:30   1200001   objectClass
      14690          Default-First-Site-Name\DC2     14690        2011-10-05 20:34:37              2    cn
      14691          Default-First-Site-Name\DC1     32772        2011-10-18 20:33:30   1200001   sn
      14691          Default-First-Site-Name\DC1     32772        2011-10-18 20:33:30   1200001   givenName
      14691          Default-First-Site-Name\DC1     32772        2011-10-18 20:33:30   1200001   instanceType
      14647          Default-First-Site-Name\DC2     14647        2011-10-07 20:31:33               1   whenCreated
      14691          Default-First-Site-Name\DC1     32772        2011-10-18 20:33:30   1200001   displayName
      14691          Default-First-Site-Name\DC1     32772        2011-10-18 20:33:30   1200000   isDeleted

(The remainder of the output has been snipped.)

Notice the version number increase is now 1,200,000 (100,000 x 12 days…. “today plus 11 days”).

Here’s where I mention another “feature” of this process. The version number increase is capped at 60 days. I assume this is because the original Tombstone Lifetime was set to 60 days and backups can only be restored < TSL.

Deleted Joe User
Changed the date back to the correct date
Created Joe User on DC2
Output of showobjmeta is similar to original Joe User object
Net stop ntds
Changed the date forward to 2/1/2012
Ntdsutil
Activate Instance NTDS
Authoritative restore
Restore object “CN=joe user,CN=Users,DC=contoso,DC=com”
Restored the object
Net start ntds

Repadmin /showobjmeta DC1 “CN=joe user,CN=Users,DC=contoso,DC=com”

     27 entries.

     Loc.USN       Originating DSA                       Org.USN       Org.Time/Date              Ver       Attribute
     =======    ===============      =========   =============       ===   =========
      14824          Default-First-Site-Name\DC1     36869           2012-02-01 20:42:11   6000001   objectClass
      14823          Default-First-Site-Name\DC2     14823           2012-02-01 20:42:37               2   cn
      14824          Default-First-Site-Name\DC1     36869           2012-02-01 20:42:11   6000001   sn
      14824          Default-First-Site-Name\DC1     36869           2012-02-01 20:42:11   6000001   givenName
      14824          Default-First-Site-Name\DC1     36869           2012-02-01 20:42:11   6000001   instanceType
      14742          Default-First-Site-Name\DC2     14742           2011-10-05 20:37:28               1   whenCreated
      14824          Default-First-Site-Name\DC1     36869           2012-02-01 20:42:11   6000001   displayName
      14824          Default-First-Site-Name\DC1     36869           2012-02-01 20:42:11   6000000   isDeleted

(The rest of the output has been snipped.)
 
Notice that the version increase was capped at 60 days (or 6,000,000 version increases).
 
I hope this has helped clear up the understanding of the logic behind the authoritative restore, where we store knowledge of the Invocation ID for the database, and how DC restore process works.

One point to note is that the version increase default is 100,000 versions per day since the last time a change was committed to the database (not since the last backup). This version increase is a default value and can be manipulated using the verinc parameter during the authoritative restore.
 
Restore object “CN=Joe User,CN=Users,DC=contoso,DC=com” verinc 1000

This would increase the version number of every attribute for Joe User by 1,000 each day since the last time a change was committed to the database.

]]> Windows Server 2008 and 2008 R2 LDF Schema Extensions https://docs.microsoft.com/archive/blogs/richpec/windows-server-2008-and-2008-r2-ldf-schema-extensions Wed, 04 May 2011 23:21:00 GMT https://blogs.msdn.microsoft.com/richpec/2011/05/04/windows-server-2008-and-2008-r2-ldf-schema-extensions/ Windows Server 2003 R2 extended the Windows Server 2003 schema from schema version 30 to 31.  The update from 30 to 31 was schema file sch31.ldf which included support for DFS Replication (DFSr).  An upgrade from Windows Server 2003 to Windows Server 2008 schema transitions the schema to schema version 44.  This includes sch32.ldf through sch44.ldf. 

If an upgrade is performed from a domain that is currently schema version 30, the Windows Server 2008 ADPREP /forestprep command will include sch31.ldf in the schema update process.

Note: Windows Server 2008 R2 transitions the Active Directory Schema to schema version 47.

The updates to the Active Directory schema are:

Sch32.ldf

This adds new attributes of:

  • msDS-KrbTgtLink: Used with RODCs to define which krbtgt_XXXX account corresponds to each RODC
  • msDS-RevealedUsers: Used with RODCs to identify the user objects whose secrets have been disclosed to that RODC
  • msDS-RevealedList: Identifies security principals whose current computer account passwords have been replicated to the RODC
  • msDS-hasFullReplicaNCs: Identifies the partitions held as full replicas
  • msDS-NeverRevealGroup: Used with RODCs to define which users, computers, and groups are not allowed to have their passwords cached on a RODC
  • msDS-RevealOnDemandGroup: Used with RODCs to define which users, computers, and groups are allowed to have their passwords cached on a RODC
  • msDS-SecondaryKrbTgtNumber: Identifies the protocol identification number associated with the secondary domain
  • msDS-RevealedDSAs: Backlink For ms-DS-Revealed-Users and identifies which RODC holds that user's secret
  • msDS-KrbTgtLinkBl: Backlink for the KrbTgtLink attribute
  • msDS-IsDomainFor: Backlink for ms-DS-Has-Domain-NCs and identifies which DCs hold that partition as their primary domain
  • msDS-IsFullReplicaFor: Backlink for ms-Ds-Has-Full-Replica-NCs and identifies which DCs hold that partition as a full replica
  • msDS-IsPartialReplicaFor: Backlink for has-Partial-Replica-NCs and identifies which DCs hold that partition as a partial replica

After the addition of these attributes, Sch32.ldf then modifies the systemMayContain values of certain objects that may contain any or all of these new attributes.

The schema version is then increased to schema version 32.

 

Sch33.ldf

This adds new attributes of:

  • msDS-isGC: Identifies the state of the Global Catalog on the DC
  • msDS-isRODC: Shows whether a DC is a RODC
  • msDS-SiteName: Lists the site name that corresponds to the DC
  • msDS-AuthenticatedAtDC: Forwardlink for ms-DS-AuthenticatedTo-Accountlist and identifies which DC a user has authenticated to
  • msDS-PromotionSettings: For a Computer, contains a XML string to be used for delegated DSA promotion
  • msDS-SupportedEncryptionTypes: The encryption algorithms supported by user, computer or trust accounts
    • Note: The KDC uses this information while generating a service ticket for this account. Services/Computers may automatically update this attribute on their respective accounts in Active Directory, and therefore need write access to this attribute.
    • msDS-AuthenticatedToAccountlist: Backlink for ms-DS-AuthenticatedAt-DC and identifies which users have authenticated to this Computer

After the addition of these attributes, Sch33.ldf then modifies the msDS-Never-Reveal-Group and the msDS-Reveal-OnDemand-Group attributes and marks them as multi-valued.  It then modifies the systemMayContain values of certain objects that may contain any or all of these new attributes.

The schema version is then increased to schema version 33.

 

Sch34.ldf

Sch34.ldf adds the following attributes to the Schema:

  • msDFSR-ReadOnly: Specifies whether the content is read-only or read-write
  • msDFSR-Priority: Priority level
  • msDS-AzObjectGuid: The unique and portable identifier of AzMan objects
  • msDS-AzGenericData: AzMan specific generic data
  • msDFSR-CachePolicy: On-demand cache policy options
  • msDFSR-DeletedPath: Full path of the Deleted directory
  • msFVE-RecoveryGuid: Contains the GUID associated with a Full Volume Encryption (FVE) recovery password
  • msDS-SeniorityIndex: Contains the seniority index as applied by the organization where the person works
  • msTPM-OwnerInformation: This attribute contains the owner information of a particular TPM
  • msPKIDPAPIMasterKeys: Storage of encrypted DPAPI Master Keys for user
  • msDS-PhoneticLastName: Contains the phonetic last name of the person
  • msPKIRoamingTimeStamp: Time stamp for last change to roaming tokens
  • msDFSR-DeletedSizeInMb: Size of the Deleted directory in MB
  • msDS-PhoneticFirstName: Contains the phonetic given name or first name of the person
  • msFVE-RecoveryPassword: Contains the password required to recover a Full Volume Encryption (FVE) volume
  • msDS-PhoneticDepartment: Contains the phonetic department name where the person works
  • msPKIAccountCredentials: Storage of encrypted user credential token blobs for roaming
  • msRADIUS-FramedIpv6Route: Provides routing information to be configured for the user on the NAS
  • msDS-PhoneticDisplayName: The phonetic display name of an object. In the absence of a phonetic display name the existing display name is used
  • msDS-PhoneticCompanyName: Contains the phonetic company name where the person works
  • ms-net-ieee-8023-GP-PolicyData: Contains all of the settings and data which comprise a Group Policy configuration for 802.3 wired networks
  • ms-net-ieee-8023-GP-PolicyGUID: Contains a GUID which identifies a specific 802.3 Group Policy object on the domain
  • msDFSR-MaxAgeInCacheInMin: Maximum time in minutes to keep files in full form
  • ms-net-ieee-80211-GP-PolicyData: Contains all of the settings and data which comprise a Group Policy configuration for 802.11 wireless networks
  • msRADIUS-FramedIpv6Prefix: Indicates an IPv6 prefix (and corresponding route) to be configured for the user
  • ms-net-ieee-80211-GP-PolicyGUID: Contains a GUID which identifies a specific 802.11 Group Policy object on the domain
  • msRADIUS-FramedInterfaceId: Indicates the IPv6 interface identifier to be configured for the user
  • msDS-NC-RO-Replica-Locations: A linked attribute on a cross ref object for a partition and lists the DC which should host the partition in a readonly manner
  • msDS-NC-RO-Replica-Locations-BL: Backlink attribute for ms-DS-NC-RO-Replica-Locations
  • msDFSR-MinDurationCacheInMin: Minimum time in minutes before truncating files
  • ms-net-ieee-8023-GP-PolicyReserved: Reserved for future use
  • msRADIUS-SavedFramedIpv6Route: Provides routing information to be configured for the user on the NAS
  • ms-net-ieee-80211-GP-PolicyReserved: Reserved for future use
  • msRADIUS-SavedFramedIpv6Prefix: Indicates an IPv6 prefix (and corresponding route) to be configured for the user
  • msRADIUS-SavedFramedInterfaceId: Indicates the IPv6 interface identifier to be configured for the user
  • samDomainUpdates: Contains a bitmask of performed SAM operations on active directory

Sch34.ldf then adds the following classes to the Active Directory Schema:

  • ms-net-ieee-8023-GroupPolicy: This class represents an 802.3 wired network Group Policy object. This class contains identifiers and configuration data relevant to an 802.3 wired network
  • ms-net-ieee-80211-GroupPolicy: This class represents an 802.11 wireless network Group Policy object. This class contains identifiers and configuration data relevant to an 802.11 wireless network
  • msFVE-RecoveryInformation: This class contains a Full Volume Encryption recovery password with its associated GUID
  • nTDSDSARO: A subclass of Directory Service Agent which is distinguished by its reduced privilege level

After the addition of these attributes and classes, Sch34.ldf then modifies the systemMayContain values of certain objects that may contain any or all of these new attributes.

The schema version is then increased to schema version 34.

 

Sch35.ldf

Sch35.ldf adds the following attributes to the Schema:

  • msDS-LastSuccessfulInteractiveLogonTime: The time that the correct password was presented during a Ctrl+Alt+Delete logon
  • msDS-FailedInteractiveLogonCountAtLastSuccessfulLogon: The total number of failed interactive logons up until the last successful Ctrl+Alt+Delete logon
  • msDS-FailedInteractiveLogonCount: The total number of failed interactive logons since this feature was turned on
  • msDS-LastFailedInteractiveLogonTime: The time that an incorrect password was presented during a Ctrl+Alt+Delete logon

After the addition of these attributes, Sch35.ldf then modifies the systemMayContain values of the object CN=User,CN=Schema,CN=Configuration,DC=X (where DC=x is the Distinguished Name of the forest root domain) to include these new attributes.

The schema version is then increased to schema version 35.

 

Sch36.ldf

Then Sch36.ldf makes the following addition to the Schema:

  • msDS-RevealedListBL: Backlink attribute for ms-DS-Revealed-List

After the addition of this one attribute, Sch36.ldf modifies the Search Flags value of the following attributes:

  • CN=From-Server,CN=Schema,CN=Configuration,DC=X
  • CN=msNPAllowDialin,CN=Schema,CN=Configuration,DC=X
  • CN=msNPCallingStationID,CN=Schema,CN=Configuration,DC=X
  • CN=msNPSavedCallingStationID,CN=Schema,CN=Configuration,DC=X
  • CN=msRADIUSCallbackNumber,CN=Schema,CN=Configuration,DC=X
  • CN=msRADIUSFramedIPAddress,CN=Schema,CN=Configuration,DC=X
  • CN=msRADIUSFramedRoute,CN=Schema,CN=Configuration,DC=X
  • CN=msRADIUSServiceType,CN=Schema,CN=Configuration,DC=X
  • CN=msRASSavedCallbackNumber,CN=Schema,CN=Configuration,DC=X
  • CN=msRASSavedFramedIPAddress,CN=Schema,CN=Configuration,DC=X
  • CN=msRASSavedFramedRoute,CN=Schema,CN=Configuration,DC=X
  • CN=ms-RADIUS-FramedInterfaceId,CN=Schema,CN=Configuration,DC=X
  • CN=ms-RADIUS-SavedFramedInterfaceId,CN=Schema,CN=Configuration,DC=X
  • CN=ms-RADIUS-FramedIpv6Prefix,CN=Schema,CN=Configuration,DC=X
  • CN=ms-RADIUS-SavedFramedIpv6Prefix,CN=Schema,CN=Configuration,DC=X
  • CN=ms-RADIUS-FramedIpv6Route,CN=Schema,CN=Configuration,DC=X
  • CN=ms-RADIUS-SavedFramedIpv6Route,CN=Schema,CN=Configuration,DC=X
  • CN=ms-FVE-RecoveryPassword,CN=Schema,CN=Configuration,DC=X
  • CN=ms-FVE-RecoveryGuid,CN=Schema,CN=Configuration,DC=X
  • CN=ms-TPM-OwnerInformation,CN=Schema,CN=Configuration,DC=X

The schema version is then increased to schema version 36.

 

Sch37.ldf

The LDF file Sch37.ldf modifies adds the following attributes to the schema:

  • msDS-UserPasswordExpiryTimeComputed: Contains the expiry time for the user's current password
  • msDS-PrincipalName: Account name for the security principal (constructed)
  • msDFSR-OnDemandExclusionDirectoryFilter: Filter string applied to on demand replication directories
  • msDFSR-DefaultCompressionExclusionFilter: Filter string containing extensions of file types not to be compressed
  • msTSHomeDrive: Terminal Services Home Drive specifies a Home drive for the user
  • msTSProperty01: Placeholder Terminal Server Property 01
  • msTSProperty02: Placeholder Terminal Server Property 02
  • msTSAllowLogon: Specifies whether the user is allowed to log on to the Terminal Server. The value is 1 if logon is allowed, and 0 if logon is not allowed.
  • msTSExpireDate: TS Expiration Date
  • msTSManagingLS: TS Managing License Server
  • msDFSR-Options2: Object Options2
  • msTSProfilePath: Terminal Services Profile Path specifies a roaming or mandatory profile path to use when the user logs on to the Terminal Server. The profile path is in the following network path format: \\servername\profiles folder name\username
  • msTSMaxIdleTime: Terminal Services Session Maximum Idle Time is maximum amount of time, in minutes, that the Terminal Services session can remain idle
  • msTSHomeDirectory: Terminal Services Home Directory specifies the Home directory for the user
  • msTSRemoteControl: Terminal Services Remote Control specifies the whether to allow remote observation or remote control of the user's Terminal Services session
  • msTSWorkDirectory: Terminal Services Session Work Directory specifies the working directory path for the user
  • msTSInitialProgram: Terminal Services Session Initial Program specifies the Path and file name of the application that the user wants to start automatically when the user logs on to the Terminal Server
  • msTSLicenseVersion: TS License Version
  • msTSMaxConnectionTime: Terminal Services Session maximum Connection Time is Maximum duration, in minutes, of the Terminal Services session
  • msTSReconnectionAction: Terminal Services Session Reconnection Action specifies whether to allow reconnection to a disconnected Terminal Services session from any client computer
  • msTSConnectClientDrives: Terminal Services Session Connect Client Drives At Logon specifies whether to reconnect to mapped client drives at logon
  • msDFSR-CommonStagingPath: Full path of the common staging directory
  • msTSMaxDisconnectionTime: Terminal Services Session Maximum Disconnection Time is maximum amount of time, in minutes, that a disconnected Terminal Services session remains active on the Terminal Server
  • msTSDefaultToMainPrinter: Terminal Services Default To Main Printer specifies whether to print automatically to the client's default printer
  • msTSConnectPrinterDrives: Terminal Services Session Connect Printer Drives At Logon specifies whether to reconnect to mapped client printers at logon
  • msTSBrokenConnectionAction: Terminal Services Session Broken Connection Action specifies the action to take when a Terminal Services session limit is reached
  • msDFSR-DisablePacketPrivacy: Disable packet privacy on a connection
  • msDFSR-CommonStagingSizeInMb: Size of the common staging directory in MB
  • msDFSR-OnDemandExclusionFileFilter: Filter string applied to on demand replication files
  • msDFSR-StagingCleanupTriggerInPercent: Staging cleanup trigger in percent of free disk space

 

After these attributes have been added, Sch37.ldf modifies security on Terminal Services objects and then updates the mayContain values of Terminal Services and DFSr objects.

The schema version is then increased to schema version 37.

 

Sch38.ldf

Sch38.ldf only makes one change.  This change is to the CN=ms-DS-AuthenticatedAt-DC,CN=Schema,CN=Configuration,DC=X attribute.  The modification that is made to this attribute is to mark this attribute as systemOnly.

After this change, the schema version is still increased to version 38.

 

Sch39.ldf

Sch39.ldf begins by modifying the following attributes:

  • msFVE-KeyPackage: Contains a volume's BitLocker encryption key secured by the corresponding recovery password
  • msFVE-VolumeGuid: Contains the GUID associated with a BitLocker-supported disk volume
  • msDS-HABSeniorityIndex: Contains the seniority index as applied by the organization where the person works

Sch39.ldf then modifies the adminDescription, searchFlags, and rangeUppper of the attributes:

  • CN=ms-FVE-RecoveryPassword,CN=Schema,CN=Configuration,DC=X
  • CN=ms-FVE-RecoveryGuid,CN=Schema,CN=Configuration,DC=X
  • CN=ms-TPM-OwnerInformation,CN=Schema,CN=Configuration,DC=X
  • CN=ms-FVE-RecoveryInformation,CN=Schema,CN=Configuration,DC=X
  • CN=msSFU-30-Posix-Member,CN=Schema,CN=Configuration,DC=X

Lastly, Sch39.ldf also updates the systemMayContain and mayContain values of additional objects in the Schema which could contain any of these attributes.

The schema version is then increased to schema version 39.

 

Sch40.ldf

The LDF file Sch40.ldf adds many attributes to the schema.  Half of these attributes are used with Fine Grained Password policies and the other half are used with Terminal Server Licensing.  This list is all of the attributes that are added to the Active Directory schema:

  • msDS-PasswordReversibleEncryptionEnabled: Password reversible encryption status for user accounts
  • msDS-NcType: A bit field that maintains information about aspects of a NC replica that are relevant to replication
  • msDS-PSOAppliesTo:  Links to objects that this password settings object applies to
  • msDS-PSOApplied: Password settings object applied to this object
  • msDS-ResultantPSO: Resultant password settings object applied to this object
  • msDS-LockoutDuration: Lockout duration for locked out user accounts
  • msDS-LockoutThreshold: Lockout threshold for lockout of user accounts
  • msDS-MinimumPasswordAge: Minimum Password Age for user accounts
  • msDS-MaximumPasswordAge: Maximum Password Age for user accounts
  • msDS-MinimumPasswordLength: Minimum Password Length for user accounts
  • msDS-PasswordHistoryLength: Password History Length for user accounts
  • msDS-LockoutObservationWindow: Observation Window for lockout of user accounts
  • msDS-PasswordComplexityEnabled: Password complexity status for user accounts
  • msDS-PasswordSettingsPrecedence: Password Settings Precedence
  • msTSManagingLS2: Issuer name of the second TS per user CAL
  • msTSManagingLS3: Issuer name of the third TS per user CAL
  • msTSManagingLS4: Issuer name of the fourth TS per user CAL
  • msTSExpireDate2: Expiration date of the second TS per user CAL
  • msTSExpireDate3: Expiration date of the third TS per user CAL
  • msTSExpireDate4: Expiration date of the fourth TS per user CAL
  • msTSLSProperty01: Placeholder Terminal Server License Server Property 01
  • msTSLSProperty02: Placeholder Terminal Server License Server Property 02
  • msTSLicenseVersion2: Version of the second TS per user CAL
  • msTSLicenseVersion3: Version of the third TS per user CAL
  • msTSLicenseVersion4: Version of the fourth TS per user CAL
  • msDS-IsUserCachableAtRodc: For a Read-Only Domain Controller (RODC), Identifies whether the specified user's secrets are cacheable

It is important to note that these password policy related attributes (i.e. msDS-LockoutDuration, msDS-LockoutThreshold, msDS-MinimumPasswordAge, etc.) are not simply an update to the existing Lockout Duration, Lockout Threshold, Minimum Password Age, etc. settings that administrators are used to see in a Password Policy.  Password Policy settings on a Windows 2000 and Windows Server 2003 domain controller are contained in the registry of the domain controller, not as attributes held within Active Directory.

Windows Server 2008 in Domain Functional Level 2008 allows for multiple Fine Grained Password Policies per domain.  For this to exist, attributes that correspond to each setting needed to be introduced to the schema.

Sch40.ldf then modifies attributes that have been created during the schema update and also updates various objects in the schema.  These modifications are searchFlags, mayContain, systemMayContain, and possPosition values.

After these changes, sch40.ldf then creates two new classes that pertain to Fine Grained Password Policies.  These classes are:

  • msDS-PasswordSettingsContainer: Container for password settings objects
  • msDS-PasswordSettings: Password settings object for accounts
    • Note: This classSchema object is created with a list of systemMustContain OIDs.  This is a list of attributes that a Password Settings Object (PSO) must contain or else the creation of the PSO will fail.

After the classes are created, the sch40.ldf file then modifies more systemMayContain values of other objects.

The schema version is then increased to schema version 40.

 

Sch41.ldf

Sch41.ldf makes only a few changes to objects that exist in the schema.  First, modifications are made to the systemMayContain values of the objects:

  • CN=NTDS-DSA,CN=Schema,CN=Configuration,DC=X
  • CN=NTDS-DSA,CN=Schema,CN=Configuration,DC=X
  • CN=NTDS-DSA,CN=Schema,CN=Configuration,DC=X
  • CN=ms-DS-PSO-Applied,CN=Schema,CN=Configuration,DC=X
  • CN=ms-DS-Resultant-PSO,CN=Schema,CN=Configuration,DC=X

Second, modifications are made to the rightsGUID values of the objects:

  • CN=MS-TS-GatewayAccess,CN=Extended-Rights,CN=Configuration,DC=X
  • CN=Terminal-Server-License-Server,CN=Extended-Rights,CN=Configuration,DC=X

The schema version is then increased to schema version 41.

 

Sch42.ldf

Schema update 42 makes modifications to over 360 objects in the schema.  The modifications that are made to these objects are adding the schemaFlagsEx attribute to each object and setting a value of 1.  The code for each modification looks like this:

changetype: ntdsSchemaModify

add: schemaFlagsEx

schemaFlagsEx: 1

Only the operating system can modify the SchemaFlagsEX value and this value specifies whether an attribute can be part of the filtered attribute set.

After the update to all 360+ attributes, the schema version is increased to schema version 42.

 

Sch43.ldf

Sch43.ldf adds the following attributes to the Active Directory Schema:

  • msDFS-SchemaMajorVersion: Major version of schema of DFS metadata
  • msDFS-SchemaMinorVersion: Minor version of schema of DFS metadata
  • msDFS-GenerationGUIDv2: To be updated each time the entry containing this attribute is modified
  • msDFS-NamespaceIdentityGUIDv2: To be set only when the namespace is created. Stable across rename/move as long as namespace is not replaced by another namespace having same name
  • msDFS-LastModifiedv2: To be updated on each write to the entry containing the attribute
  • msDFS-Ttlv2: TTL associated with DFS root/link. For use at DFS referral time
  • msDFS-Commentv2: Comment associated with DFS root/link
  • msDFS-Propertiesv2: Properties associated with DFS root/link
  • msDFS-TargetListv2: Targets corresponding to DFS root/link
  • msDFS-LinkPathv2: DFS link path relative to the DFS root target share (i.e. without the server/domain and DFS namespace name components). Use forward slashes (/) instead of backslashes so that LDAP searches can be done without having to use escapes
  • msDFS-LinkSecurityDescriptorv2: Security descriptor of the DFS links's reparse point on the filesystem
  • msDFS-LinkIdentityGUIDv2: To be set only when the link is created. Stable across rename/move as long as link is not replaced by another link having same name
  • msDFS-ShortNameLinkPathv2: Shortname DFS link path relative to the DFS root target share (i.e. without the server/domain and DFS namespace name components). Use forward slashes (/) instead of backslashes so that LDAP searches can be done without having to use escapes
  • msDFS-NamespaceAnchor: DFS namespace anchor
  • msDFS-Namespacev2: DFS namespace
  • msDFS-Linkv2: DFS Link in DFS namespace
  • msDFS-DeletedLinkv2: Deleted DFS Link in DFS namespace
  • addressBookRoots2: Used by Exchange. Exchange configures trees of address book containers to show up in the MAPI address book. This attribute on the Exchange Config object lists the roots of the address book container trees
  • globalAddressList2: This attribute is used on a Microsoft Exchange container to store the distinguished name of a newly created global address list (GAL)
  • templateRoots2: This attribute is used on the Exchange config container to indicate where the template containers are stored. This information is used by the Active Directory MAPI provider

Once these attributes have been created the schema version is incremented to schema version 43.

 

Sch44.ldf

Schema Update 44 only does modifications to some objects that already exist.  These modifications are changing systemMayContain, showInAdvancedViewOnly, searchFlags, and adminDescription.  Once this is complete, the schema version is incremented to schema version 44.  At this point, the Windows Server 2008 ADPREP /forestprep is complete


Additional LDF files for Windows Server 2008 R2 ADPREP /forestprep

 

Sch45.ldf

Sch45.ldf adds the following attributes to the Active Directory schema:

  • msDS-USNLastSyncSuccess: The USN at which the last successful replication synchronization occurred
  • isRecycled: Is the object recycled (for use with AD Recycle Bin)
  • msDS-OptionalFeatureGUID: GUID of an optional feature
  • msDS-EnabledFeature: Enabled optional features
  • msImaging-PSPString: Schema Attribute that contains the XML sequence for this PostScan Process
  • msDS-OIDToGroupLink: For an OID, identifies the group object corresponding to the issuance policy represented by this OID
  • msDS-OIDToGroupLinkBl: Backlink for ms-DS-OIDToGroup-Link; identifies the issuance policy, represented by an OID object, which is mapped to this group
  • msImaging-PSPIdentifier: Schema Attribute that contains the unique identifier for this PostScan Process
  • msDS-HostServiceAccount: Service Accounts configured to run on this computer
  • msDS-HostServiceAccountBL: Service Accounts Back Link for linking machines associated with the service account
  • msDS-RequiredDomainBehaviorVersion: Required domain function level for this feature
  • msDS-RequiredForestBehaviorVersion: Required forest function level for this feature
  • msPKI-CredentialRoamingTokens: Storage of encrypted user credential token blobs for roaming
  • msDS-LocalEffectiveRecycleTime: Recycle time of the object in the local DIT
  • msDS-LocalEffectiveDeletionTime: Deletion time of the object in the local DIT
  • msDS-LastKnownRDN: Holds original RDN of a deleted object
  • msDS-EnabledFeatureBL: Scopes where this optional feature is enabled
  • msDS-DeletedObjectLifetime: Lifetime of a deleted object
  • msDS-OptionalFeatureFlags: An integer value that contains flags that define behavior of an optional feature in Active Directory
  • msPKI-Enrollment-Servers: Priority, authentication type, and URI of each certificate enrollment web service
  • msPKI-Site-Name: Active Directory site to which the CA machine belongs
  • msTSEndpointData: This attribute represents the VM Name for machine in TSV deployment.
  • msTSEndpointType: This attribute defines if the machine is a physical machine or a virtual machine.
  • msTSEndpointPlugin: This attribute represents the name of the plugin which handles the orchestration.
  • msTSPrimaryDesktop: This attribute represents the forward link to user's primary desktop.
  • msTSSecondaryDesktops: This attribute represents the array of forward links to user's secondary desktops.
  • msTSPrimaryDesktopBL: This attribute represents the backward link to user.
  • msTSSecondaryDesktopBL: This attribute represents the backward link to user.
  • msImaging-PSPs: Container for all Enterprise Scan Post Scan Process objects.
  • msDS-OptionalFeature: Configuration for an optional DS feature.
  • msImaging-PostScanProcess: Enterprise Scan Post Scan Process object.
  • msDS-ManagedServiceAccount: Service account class is used to create accounts that are used for running Windows services.

Then, modifications are made to various objects in the schema which contain values such as systemMayContain and appliesTo.  Lastly, the objects CN=Optional Features,CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=X and CN=Recycle Bin Feature,CN=Optional Features,CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=X are created as optional features that can be enabled with Windows Server 2008 R2.

When this is complete the schema version is incremented to 45.

 

Sch46.ldf

The LDF file Sch46.ldf makes one change to the object CN=ms-DS-Managed-Service-Account,CN=Schema,CN=Configuration,DC=X.  The change that is made is to modify the defaultHidingValue and configure it with a value of FALSE.

When this is complete the schema version is incremented to 46.

 

Sch47.ldf

Sch47.ldf modifies only two objects in the schema.  These objects are CN=NTDS-DSA,CN=Schema,CN=Configuration,DC=X and CN=ms-DS-Managed-Service-Account,CN=Schema,CN=Configuration,DC=X.  The modification to the first is a modification to the systemMayContain value.  The modification to the second object is a deletion of the systemPossSuperiors value.

When this is complete the schema version is incremented to schema version 47 and the ADPREP /forestprep for Windows Server 2008 R2 is complete.

 

 

 

]]> UserEnv Debugging Line by Line https://docs.microsoft.com/archive/blogs/richpec/userenv-debugging-line-by-line Mon, 20 Jul 2009 17:07:00 GMT https://blogs.msdn.microsoft.com/richpec/2009/07/20/userenv-debugging-line-by-line/ There aren’t a lot of documents on the Internet about how to interpret UserEnv debugging logs.  I’ll admit that I do not have a dictionary for every single line that anyone could possibly see in a UserEnv log.  This blog is an attempt to decipher the UserEnv log line by line.  There are some lines that have been removed because of redundancy.

 

The Environment:

 

Windows Server 2003 Domain Controller for contoso.com (RootDC)

Two client machines that are both Windows XP (XPClient1 and XPClient2)

Two user accounts during the lab reproduction (HQUser and RemoteUser)

 

Let’s take a look at the boot process of a Windows XP machine before we start breaking things.  This UserEnv log is taken from a client machine located in the OU named Laptops.  The full distinguished name of this computer is CN=XPCLIENT2,OU=Laptops,OU=Company Computers,DC=contoso,DC=com.  At first, during the boot up process, the client machine begins by starting winlogon service.

USERENV(16c.170) 12:03:10:268 LibMain: Process Name:  \??\C:\WINDOWS\system32\winlogon.exe

USERENV(16c.170) 12:03:10:498 Entering CUserProfile::Initialize ...

USERENV(16c.170) 12:03:10:498 CUserProfile::Initialize called by winlogon

USERENV(16c.170) 12:03:10:498 CUserProfile::Initialize: critical section initialized

USERENV(16c.170) 12:03:10:498 CSyncManager::Initialize: critical section initialized

USERENV(16c.170) 12:03:10:498 CUserProfile::Initialize: registry key Software\Microsoft\Windows NT\CurrentVersion\ProfileList opened

As we can see, this log contains the time of each event but does not contain the date.  Because of this, a good troubleshooting step would be to remotely delete the userenv.log file prior to performing whatever action you want to troubleshoot such as GPO processing during boot or GPO processing during logon.

Another point to note is the process itself.  In the above snippet, we see the process 16c.170.  This information is in HEX and the first part of this HEX value is the process itself and the second part corresponds to the thread.  Using a converter, 16c translates to 364.  If you then run either task manager or task list and view the Process ID (PID) of the Winlogon process it will be process ID 364.  This is the PID of my Winlogon process and would change on each client.

So now the Winlogon process has initialized and the computer then starts a cleanup process of profiles that exist on the machine.  This section is rather long and has been truncated so that it doesn’t include each and every SID/Profile cleanup process.

USERENV(16c.170) 12:03:10:508 CUserProfile::Initialize: Proccessing S-1-5-21-3817846394-4251116553-2531831203-1106

USERENV(16c.170) 12:03:10:508 CSyncManager::EnterLock <S-1-5-21-3817846394-4251116553-2531831203-1106>

USERENV(16c.170) 12:03:10:508 CSyncManager::EnterLock: No existing entry found

USERENV(16c.170) 12:03:10:508 CSyncManager::EnterLock: New entry created

USERENV(16c.170) 12:03:10:508 CHashTable::HashAdd: S-1-5-21-3817846394-4251116553-2531831203-1106 added in bucket 7

USERENV(16c.170) 12:03:10:508 CUserProfile::CleanupUserProfile: Enter critical section.

USERENV(16c.170) 12:03:10:508 CUserProfile::GetRefCountAndFlags: Ref count is 0, state is 00000000

USERENV(16c.170) 12:03:10:508 CSyncManager::LeaveLock <S-1-5-21-3817846394-4251116553-2531831203-1106>

USERENV(16c.170) 12:03:10:508 CSyncManager::LeaveLock: Lock released

USERENV(16c.170) 12:03:10:508 CHashTable::HashDelete: S-1-5-21-3817846394-4251116553-2531831203-1106 deleted

USERENV(16c.170) 12:03:10:508 CSyncManager::LeaveLock: Lock deleted

USERENV(16c.170) 12:03:10:508 CUserProfile::CleanupUserProfile: Leave critical section

USERENV(16c.170) 12:03:10:508 CUserProfile::Initialize: Proccessing S-1-5-21-3817846394-4251116553-2531831203-1105

USERENV(16c.170) 12:03:10:508 CSyncManager::EnterLock <S-1-5-21-3817846394-4251116553-2531831203-1105>

USERENV(16c.170) 12:03:10:508 CSyncManager::EnterLock: No existing entry found

USERENV(16c.170) 12:03:10:508 CSyncManager::EnterLock: New entry created

USERENV(16c.170) 12:03:10:508 CHashTable::HashAdd: S-1-5-21-3817846394-4251116553-2531831203-1105 added in bucket 6

USERENV(16c.170) 12:03:10:508 CUserProfile::CleanupUserProfile: Enter critical section.

USERENV(16c.170) 12:03:10:508 CUserProfile::GetRefCountAndFlags: Ref coulnt is 0, state is 00000000

USERENV(16c.170) 12:03:10:508 CSyncManager::LeaveLock <S-1-5-21-3817846394-4251116553-2531831203-1105>

USERENV(16c.170) 12:03:10:508 CSyncManager::LeaveLock: Lock released

USERENV(16c.170) 12:03:10:508 CHashTable::HashDelete: S-1-5-21-3817846394-4251116553-2531831203-1105 deleted

USERENV(16c.170) 12:03:10:508 CSyncManager::LeaveLock: Lock deleted

USERENV(16c.170) 12:03:10:508 CUserProfile::CleanupUserProfile: Leave critical section

USERENV(16c.170) 12:03:10:518 CUserProfile::Initialize: RpcServerRegisterIfEx successful

USERENV(16c.170) 12:03:10:528 Exiting CUserProfile::Initialize, successful

We then start services.exe and lsass.exe:

USERENV(198.19c) 12:03:10:588 LibMain: Process Name:  C:\WINDOWS\system32\services.exe

USERENV(1a4.1a8) 12:03:10:628 LibMain: Process Name:  C:\WINDOWS\system32\lsass.exe

Now we check to see whether the computer is flagged with the need to do a Synchronous Foreground refresh of Group Policy. 

USERENV(16c.170) 12:03:10:669 IsSyncForegroundPolicyRefresh: Asynchronous, Reason: NoNeedForSync

An example of a scenario when this line would read differently is in a situation where we created a Group Policy that assigned software to the computer.  In that case, because of the way Windows XP works with Asynchronous processing of Group Policy, the original pass-through of the Group Policy processing would recognize that it needed to install software, flag the system for a Synchronous processing of Group Policy at next boot, and would install the software synchronously at next Foreground Group Policy processing (i.e. at next boot).

Now we start the Network Service. 

USERENV(248.24c) 12:03:10:999 LibMain: Process Name:  C:\WINDOWS\system32\svchost.exe

Group Policy runs under the System context.  The Network Service also has a profile.  This can be seen by configuring explorer to display hidden files and browsing to C:\Documents and Settings\.  Inside there is a NetworkService profile.  In order for Group Policy to open the profile and perform tasks as a user (in this case a service), it must impersonate the user.  In the next line, the system checks to see if it can impersonate the NetworkService user account yet we have not begun to impersonate the user and are still running as the System context.

USERENV(198.19c) 12:03:11:139 LoadUserProfile: Yes, we can impersonate the user. Running as self

USERENV(198.19c) 12:03:11:139 =========================================================

Computer starts loading the NetworkService profile.  You’ll see that it switches from self to client and back numerous times:

USERENV(198.19c) 12:03:11:139 LoadUserProfile: Entering, hToken = <0x29c>, lpProfileInfo = 0x7fcf8

USERENV(198.19c) 12:03:11:139 LoadUserProfile: lpProfileInfo->dwFlags = <0x9>

USERENV(198.19c) 12:03:11:139 LoadUserProfile: lpProfileInfo->lpUserName = <NetworkService>

USERENV(198.19c) 12:03:11:139 LoadUserProfile: NULL central profile path

USERENV(198.19c) 12:03:11:139 LoadUserProfile: NULL default profile path

USERENV(198.19c) 12:03:11:139 LoadUserProfile: NULL server name

USERENV(198.19c) 12:03:11:139 GetInterface: Returning rpc binding handle

USERENV(16c.270) 12:03:11:139 IProfileSecurityCallBack: client authenticated.

USERENV(16c.270) 12:03:11:139 DropClientContext: Got client token 00000348, sid = S-1-5-18

USERENV(16c.270) 12:03:11:139 MIDL_user_allocate enter

USERENV(16c.270) 12:03:11:139 DropClientContext: load profile object successfully made

USERENV(16c.270) 12:03:11:139 DropClientContext: Returning 0

USERENV(198.19c) 12:03:11:139 LoadUserProfile: Calling DropClientToken (as self) succeeded

USERENV(16c.184) 12:03:11:139 IProfileSecurityCallBack: client authenticated.

USERENV(16c.184) 12:03:11:139 In LoadUserProfileP

USERENV(16c.184) 12:03:11:139 LoadUserProfile: Running as client

USERENV(16c.184) 12:03:11:139 =========================================================

-----SNIP------

USERENV(16c.184) 12:03:11:139 GetExistingLocalProfileImage:  Local profile image filename = <%SystemDrive%\Documents and Settings\NetworkService>

USERENV(16c.184) 12:03:11:139 GetExistingLocalProfileImage:  Expanded local profile image filename = <C:\Documents and Settings\NetworkService>

Here we’re checking for a Mandatory profile.  There isn’t one so we get an error of 2.

USERENV(16c.184) 12:03:11:139 GetExistingLocalProfileImage:  No local mandatory profile.  Error = 2

Continuing:

USERENV(16c.184) 12:03:11:139 GetExistingLocalProfileImage:  Found local profile image file ok <C:\Documents and Settings\NetworkService\ntuser.dat>

USERENV(16c.184) 12:03:11:139 Local Existing Profile Image is reachable

USERENV(16c.184) 12:03:11:139 Local profile name is <C:\Documents and Settings\NetworkService>

Now the computer looks for a Roaming Profile.  There isn’t one so it loads the local profile:

USERENV(16c.184) 12:03:11:139 RestoreUserProfile:  No central profile.  Attempting to load local profile.

USERENV(16c.184) 12:03:11:139 MyRegLoadKey: Returning 00000000

USERENV(16c.184) 12:03:11:139 GetUserDNSDomainName:  Domain name is NT Authority.  No DNS domain name available.

USERENV(16c.184) 12:03:11:139 MyRegLoadKey: Returning 00000000

USERENV(16c.184) 12:03:11:139 CreateClassHive: existing user classes hive found

USERENV(16c.184) 12:03:11:139 RestoreUserProfile:  About to Leave.  Final Information follows:

USERENV(16c.184) 12:03:11:139 Profile was successfully loaded.

----- More profile loading SNIP -----

More impersonating user and back:

USERENV(16c.184) 12:03:11:179 LoadUserProfile: Impersonated user: 0000034c, 00000358

USERENV(1a4.1e4) 12:03:11:179 GetUserDNSDomainName:  Domain name is NT Authority.  No DNS domain name available.

USERENV(1a4.1e4) 12:03:11:179 GetUserDNSDomainName:  Domain name is NT Authority.  No DNS domain name available.

USERENV(16c.184) 12:03:11:209 LoadUserProfile: Reverted to user: 00000000

USERENV(16c.184) 12:03:11:209 LoadUserProfile: Reverted back to user <00000000>

USERENV(16c.184) 12:03:11:209 LoadUserProfile: Leaving with a value of 1.

USERENV(16c.184) 12:03:11:209 =========================================================

USERENV(16c.184) 12:03:11:209 LoadUserProfileI: returning 0

USERENV(198.19c) 12:03:11:209 LoadUserProfile: Running as self

USERENV(198.19c) 12:03:11:209 LoadUserProfile: Calling LoadUserProfileI (as user) succeeded

----- Snipping the rest of the NetworkService profile loading -----

Starting other processes (note the different HEX for the process ID):

USERENV(328.32c) 12:03:13:372 LibMain: Process Name:  C:\WINDOWS\system32\svchost.exe

USERENV(380.384) 12:03:13:623 LibMain: Process Name:  C:\WINDOWS\system32\spoolsv.exe

Now let’s process some Group Policy:

USERENV(16c.300) 12:03:23:076 ApplyGroupPolicy: Entering. Flags = f

USERENV(16c.300) 12:03:23:076 ProcessGPOs:

USERENV(16c.300) 12:03:23:076 ProcessGPOs:

Informing that we’ll be applying Group Policy asynchronously:

USERENV(16c.300) 12:03:23:076 ProcessGPOs:  Starting computer Group Policy (Async forground) processing...

USERENV(16c.300) 12:03:23:076 ProcessGPOs:

USERENV(16c.300) 12:03:23:076 ProcessGPOs:

USERENV(16c.300) 12:03:23:076 EnterCriticalPolicySectionEx: Entering with timeout 600000 and flags 0x0

USERENV(16c.300) 12:03:23:076 EnterCriticalPolicySectionEx: Machine critical section has been claimed.  Handle = 0x728

USERENV(16c.300) 12:03:23:076 EnterCriticalPolicySectionEx: Leaving successfully.

USERENV(16c.300) 12:03:23:076 ProcessGPOs:  Machine role is 2.

Next is where the computer pings the domain controller during slow link detection.  By default, a slow link is defined as 500 kb per second or slower.  That number can be configured for the user, computer, or both.

USERENV(16c.300) 12:03:23:076 PingComputer: PingBufferSize set as 2048

USERENV(16c.300) 12:03:23:086 PingComputer: Adapter speed 100000000 bps

USERENV(16c.300) 12:03:23:086 PingComputer:  First time:  3

USERENV(16c.300) 12:03:23:086 PingComputer:  Fast link.  Exiting.

The query proved to be a fast link and, therefore, exited the slow link detection.  If the ping would have resulted in a slow link, by default, certain policy settings would not be applied.  These are settings such as Folder Redirection and Software Installation.  These are settings that we wouldn’t want to configure across a slow link.  That would not be optimal.

Again we check to see if we can impersonate the user, which we can.  The computer reports that it’s able to impersonate the user and that it’s currently running as the system and not the user.

USERENV(198.430) 12:03:23:297 LoadUserProfile: Yes, we can impersonate the user. Running as self

USERENV(198.430) 12:03:23:297 =========================================================

USERENV(198.430) 12:03:23:297 LoadUserProfile: Entering, hToken = <0x1b8>, lpProfileInfo = 0x9bf6e8

USERENV(198.430) 12:03:23:297 LoadUserProfile: lpProfileInfo->dwFlags = <0x9>

USERENV(198.430) 12:03:23:297 LoadUserProfile: lpProfileInfo->lpUserName = <LocalService>

USERENV(198.430) 12:03:23:297 LoadUserProfile: NULL central profile path

USERENV(198.430) 12:03:23:297 LoadUserProfile: NULL default profile path

USERENV(198.430) 12:03:23:297 LoadUserProfile: NULL server name

----- Snip (Some other processes start up but I’ve removed them) -----

Back to the GPO Processing.  We provide the client network address as well as the user name (in this case the computer name):

USERENV(16c.300) 12:03:23:737 ProcessGPOs: network name is 10.0.0.0

USERENV(16c.300) 12:03:23:747 ProcessGPOs:  User name is:  CN=XPCLIENT2,OU=Laptops,OU=Company Computers,DC=contoso,DC=com, Domain name is:  CONTOSO

USERENV(16c.300) 12:03:23:747 ProcessGPOs: Domain controller is:  \\ROOTDC.contoso.com  Domain DN is contoso.com

The client then queries for a RSOP entry point for the client side extensions.  This occurs every time GPO is processed.   

USERENV(16c.300) 12:03:23:747 ReadGPExtensions: Rsop entry point not found for gptext.dll.

USERENV(16c.300) 12:03:23:747 ReadGPExtensions: Rsop entry point not found for dskquota.dll.

USERENV(16c.300) 12:03:23:747 ReadGPExtensions: Rsop entry point not found for gptext.dll.

USERENV(16c.300) 12:03:23:747 ReadGPExtensions: Rsop entry point not found for iedkcs32.dll.

USERENV(16c.300) 12:03:23:747 ReadGPExtensions: Rsop entry point not found for scecli.dll.

USERENV(16c.300) 12:03:23:747 ReadGPExtensions: Rsop entry point not found for C:\WINDOWS\System32\cscui.dll.

USERENV(16c.300) 12:03:23:747 ReadGPExtensions: Rsop entry point not found for gptext.dll.

The Winlogon GPO process then looks for the previous status of each client side extension.  The purpose of this query is to determine whether or not any settings have changed for the client side extension.  The previous status for each client side extension is read and then the Winlogon process determines whether or not a client side extension setting has changed and if so, determines the settings that need to change based on that.

USERENV(16c.300) 12:03:23:747 ReadExtStatus: Reading Previous Status for extension {35378EAC-683F-11D2-A89A-00C04FBBCFA2}

USERENV(16c.300) 12:03:23:747 ReadStatus: Read Extension's Previous status successfully.

USERENV(16c.300) 12:03:23:747 ReadExtStatus: Reading Previous Status for extension {0ACDD40C-75AC-47ab-BAA0-BF6DE7E7FE63}

USERENV(16c.300) 12:03:23:747 ReadStatus: Read Extension's Previous status successfully.

USERENV(16c.300) 12:03:23:747 ReadExtStatus: Reading Previous Status for extension {25537BA6-77A8-11D2-9B6C-0000F8080861}

USERENV(16c.300) 12:03:23:747 ReadExtStatus: Reading Previous Status for extension {3610eda5-77ef-11d2-8dc5-00c04fa31a66}

USERENV(16c.300) 12:03:23:747 ReadExtStatus: Reading Previous Status for extension {426031c0-0b47-4852-b0ca-ac3d37bfcb39}

USERENV(16c.300) 12:03:23:747 ReadExtStatus: Reading Previous Status for extension {42B5FAAE-6536-11d2-AE5A-0000F87571E3}

USERENV(16c.300) 12:03:23:747 ReadStatus: Read Extension's Previous status successfully.

USERENV(16c.300) 12:03:23:747 ReadExtStatus: Reading Previous Status for extension {4CFB60C1-FAA6-47f1-89AA-0B18730C9FD3}

USERENV(16c.300) 12:03:23:747 ReadExtStatus: Reading Previous Status for extension {827D319E-6EAC-11D2-A4EA-00C04F79F83A}

USERENV(16c.300) 12:03:23:747 ReadStatus: Read Extension's Previous status successfully.

USERENV(16c.300) 12:03:23:747 ReadExtStatus: Reading Previous Status for extension {A2E30F80-D7DE-11d2-BBDE-00C04F86AE3B}

USERENV(16c.300) 12:03:23:747 ReadExtStatus: Reading Previous Status for extension {B1BE8D72-6EAC-11D2-A4EA-00C04F79F83A}

USERENV(16c.300) 12:03:23:747 ReadStatus: Read Extension's Previous status successfully.

USERENV(16c.300) 12:03:23:747 ReadExtStatus: Reading Previous Status for extension {B587E2B1-4D59-4e7e-AED9-22B9DF11D053}

USERENV(16c.300) 12:03:23:747 ReadExtStatus: Reading Previous Status for extension {C631DF4C-088F-4156-B058-4375F0853CD8}

USERENV(16c.300) 12:03:23:747 ReadExtStatus: Reading Previous Status for extension {c6dc5466-785a-11d2-84d0-00c04fb169f7}

USERENV(16c.300) 12:03:23:747 ReadStatus: Read Extension's Previous status successfully.

USERENV(16c.300) 12:03:23:747 ReadExtStatus: Reading Previous Status for extension {e437bc1c-aa7d-11d2-a382-00c04f991e27}

USERENV(16c.300) 12:03:23:747 ReadStatus: Read Extension's Previous status successfully.

After the Winlogon process reads the previous status of each CSE, it’s time to start evaluating what GPOs exist:

USERENV(16c.300) 12:03:23:747 ProcessGPOs: Calling GetGPOInfo for normal policy mode

USERENV(16c.300) 12:03:23:747 GetGPOInfo:  ********************************

USERENV(16c.300) 12:03:23:747 GetGPOInfo:  Entering...

USERENV(16c.300) 12:03:23:757 GetGPOInfo:  Server connection established.

USERENV(16c.300) 12:03:23:787 GetGPOInfo:  Bound successfully.

We search the entire hierarchy to look to see if any Group Policies are linked to any OU in the tree, the domain, or the Active Directory site:

USERENV(16c.300) 12:03:23:787 SearchDSObject:  Searching <OU=Laptops,OU=Company Computers,DC=contoso,DC=com>

USERENV(16c.300) 12:03:23:787 SearchDSObject:  No GPO(s) for this object.

USERENV(16c.300) 12:03:23:787 SearchDSObject:  Searching <OU=Company Computers,DC=contoso,DC=com>

USERENV(16c.300) 12:03:23:787 SearchDSObject:  No GPO(s) for this object.

USERENV(16c.300) 12:03:23:787 SearchDSObject:  Searching <DC=contoso,DC=com>

USERENV(16c.300) 12:03:23:787 SearchDSObject:  Found GPO(s):  <[LDAP://cn={AF5C4ACE-C8FD-4574-A9E4-07B77EED376E},cn=policies,cn=system,DC=contoso,DC=com;0][LDAP://CN={31B2F340-016D-11D2-945F-00C04FB984F9},CN=Policies,CN=System,DC=contoso,DC=com;0]>

USERENV(16c.300) 12:03:23:787 ProcessGPO:  ==============================

USERENV(16c.300) 12:03:23:787 ProcessGPO:  Deferring search for <LDAP://cn={AF5C4ACE-C8FD-4574-A9E4-07B77EED376E},cn=policies,cn=system,DC=contoso,DC=com>

USERENV(16c.300) 12:03:23:797 ProcessGPO:  ==============================

USERENV(16c.300) 12:03:23:797 ProcessGPO:  Deferring search for <LDAP://CN={31B2F340-016D-11D2-945F-00C04FB984F9},CN=Policies,CN=System,DC=contoso,DC=com>

USERENV(16c.300) 12:03:23:797 SearchDSObject:  Searching <CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=contoso,DC=com>

USERENV(16c.300) 12:03:23:797 SearchDSObject:  No GPO(s) for this object.

USERENV(16c.300) 12:03:23:797 EvaluateDeferredGPOs:  Searching for GPOs in cn=policies,cn=system,DC=contoso,DC=com

After each GPO is located, the a check is performed to determine whether or not the user account (in this case the client) has access to the Group Policy and then performs a WMI filter check against any WMI filters applied to each Group Policy.

USERENV(16c.300) 12:03:23:797 ProcessGPO:  ==============================

USERENV(16c.300) 12:03:23:797 ProcessGPO:  Searching <cn={AF5C4ACE-C8FD-4574-A9E4-07B77EED376E},cn=policies,cn=system,DC=contoso,DC=com>

USERENV(16c.300) 12:03:23:797 ProcessGPO:  Machine has access to this GPO.

USERENV(16c.300) 12:03:23:797 ProcessGPO:  GPO passes the filter check.

The next line is where the client looks for the functionality version of the Group Policy.  This version will always be 2 because of the version of the GPEdit tool that was used to create the Group Policy.

USERENV(16c.300) 12:03:23:797 ProcessGPO:  Found functionality version of:  2

Now it’s time to locate the Group Policy within SYSVOL to determine what settings are configured within registry.pol:

USERENV(16c.300) 12:03:23:797 ProcessGPO:  Found file system path of:  <\\contoso.com\SysVol\contoso.com\Policies\{AF5C4ACE-C8FD-4574-A9E4-07B77EED376E}>

USERENV(16c.300) 12:03:23:807 ProcessGPO:  Found common name of:  <{AF5C4ACE-C8FD-4574-A9E4-07B77EED376E}>

USERENV(16c.300) 12:03:23:807 ProcessGPO:  Found display name of:  <All Domain Systems>

This next line, below, is a check that’s performed to determine what version number exists for the Group Policy Template (GPT) within SYSVOL.  The check against the version number inside of GPT.ini within SYSVOL is then compared to the Group Policy Container (GPC) within Active Directory.  These should match but there are certain situations in which they wouldn’t match.  The GPT is replicated through FRS Replication whereas the GPC is replicated through Active Directory Replication.  If one of the two replication mechanisms is behind in replication, this check will not be in sync.

Under this circumstance, in Windows 2000, an error message would be generated that there was a version mismatch and Group Policy processing for that GPO would cease at that point.  This was not efficient for a number of reasons.  Take, for instance, an environment where Change Notification is enabled on the site link between two Active Directory sites.  In this scenario, Active Directory replication between the two sites would act as though they were in the same site and would use Intra-site Replication standards.  Change notification across site links only works for AD Replication and not FRS.  In this scenario, if a change is made to a Group Policy, Active Directory would replicate the change to another site almost instantaneously whereas FRS would have to wait the normal Site Link Replication schedule before the change was replicated resulting in a version mismatch between GPC and GPT and Group Policy processing of that one GPO would fail.  This was changed in Windows XP and Windows Server 2003.

USERENV(16c.300) 12:03:23:807 ProcessGPO:  Found machine version of:  GPC is 1, GPT is 1

Then a check is performed on the Group Policy to look for any specific flags such as Enforcement (No Override):

USERENV(16c.300) 12:03:23:807 ProcessGPO:  Found flags of:  0

The next line in the log is where the Winlogon process determines what Client Side Extensions need to be pulled in order to process the Group Policy. 

USERENV(16c.300) 12:03:23:807 ProcessGPO:  Found extensions:  [{35378EAC-683F-11D2-A89A-00C04FBBCFA2}{0F6B957D-509E-11D1-A7CC-0000F87571E3}]

USERENV(16c.300) 12:03:23:807 ProcessGPO:  ==============================

USERENV(16c.300) 12:03:23:807 ProcessGPO:  ==============================

Same thing happens for the other Group Policies:

USERENV(16c.300) 12:03:23:807 ProcessGPO:  Searching <CN={31B2F340-016D-11D2-945F-00C04FB984F9},CN=Policies,CN=System,DC=contoso,DC=com>

USERENV(16c.300) 12:03:23:807 ProcessGPO:  Machine has access to this GPO.

USERENV(16c.300) 12:03:23:807 ProcessGPO:  GPO passes the filter check.

USERENV(16c.300) 12:03:23:807 ProcessGPO:  Found functionality version of:  2

USERENV(16c.300) 12:03:23:807 ProcessGPO:  Found file system path of:  <\\contoso.com\sysvol\contoso.com\Policies\{31B2F340-016D-11D2-945F-00C04FB984F9}>

USERENV(16c.300) 12:03:23:807 ProcessGPO:  Found common name of:  <{31B2F340-016D-11D2-945F-00C04FB984F9}>

USERENV(16c.300) 12:03:23:807 ProcessGPO:  Found display name of:  <Default Domain Policy>

USERENV(16c.300) 12:03:23:807 ProcessGPO:  Found machine version of:  GPC is 3, GPT is 3

USERENV(16c.300) 12:03:23:807 ProcessGPO:  Found flags of:  0

USERENV(16c.300) 12:03:23:807 ProcessGPO:  Found extensions:  [{35378EAC-683F-11D2-A89A-00C04FBBCFA2}{53D6AB1B-2488-11D1-A28C-00C04FB94F17}][{827D319E-6EAC-11D2-A4EA-00C04F79F83A}{803E14A0-B4FB-11D0-A0D0-00A0C90F574B}][{B1BE8D72-6EAC-11D2-A4EA-00C04F79F83A}{53D6AB1B-2488-11D1-A28C-00C04FB94F17}]

USERENV(16c.300) 12:03:23:807 ProcessGPO:  ==============================

After all Group Policies are identified and all checks are complete, the client then looks for any local GPO defined within a local gpt.ini.  Generally this is not defined and, therefore, the following message is displayed:

USERENV(16c.300) 12:03:23:807 GetGPOInfo:  Local GPO's gpt.ini is not accessible, assuming default state.

USERENV(16c.300) 12:03:23:807 GetGPOInfo:  Leaving with 1

USERENV(16c.300) 12:03:23:807 GetGPOInfo:  ********************************

USERENV(16c.300) 12:03:23:817 ProcessGPOs: Logging Data for Target <XPCLIENT2>.

USERENV(16c.300) 12:03:23:817 GetWbemServices: CoCreateInstance succeeded

USERENV(16c.300) 12:03:23:867 ConnectToNameSpace: ConnectServer returned 0x0

USERENV(16c.300) 12:03:23:867 CSessionLogger::Log: logging new security grps

USERENV(16c.300) 12:03:23:877 ProcessGPOs: Logged Rsop Session successfully.

USERENV(16c.300) 12:03:23:877 ProcessGPOs: -----------------------

USERENV(16c.300) 12:03:23:877 ProcessGPOs: Processing extension Registry

USERENV(16c.300) 12:03:23:877 ReadStatus: Read Extension's Previous status successfully.

USERENV(16c.300) 12:03:23:877 CompareGPOLists:  The lists are the same.

USERENV(16c.300) 12:03:23:877 ProcessGPOList: Entering for extension Registry

USERENV(16c.300) 12:03:23:877 MachinePolicyCallback: Setting status UI to Applying Registry policy...

USERENV(16c.300) 12:03:23:877 MachinePolicyCallback: Extension requested status UI when status UI is not available.

USERENV(16c.300) 12:03:23:908 LogExtSessionStatus: Successfully logged Extension Session data

USERENV(16c.300) 12:03:23:908 EnterCriticalPolicySectionEx: Entering with timeout 60000 and flags 0x2

USERENV(16c.300) 12:03:23:908 EnterCriticalPolicySectionEx: Machine critical section has been claimed.  Handle = 0x824

USERENV(16c.300) 12:03:23:908 EnterCriticalPolicySectionEx: Leaving successfully.

USERENV(16c.300) 12:03:23:908 ResetPolicies: Entering.

One of the settings configured in my “All Computers” GPO was disabling the Windows Firewall.  The next couple of lines who where this settings was configured:

USERENV(16c.300) 12:03:23:908 ParseRegistryFile: Entering with <C:\Documents and Settings\All Users\ntuser.pol>.

USERENV(16c.300) 12:03:23:918 DeleteRegistryValue: Deleted SOFTWARE\Policies\Microsoft\WindowsFirewall\DomainProfile\EnableFirewall

USERENV(16c.300) 12:03:23:938 ParseRegistryFile: Entering with <\\contoso.com\SysVol\contoso.com\Policies\{AF5C4ACE-C8FD-4574-A9E4-07B77EED376E}\Machine\registry.pol>.

USERENV(16c.300) 12:03:23:938 SetRegistryValue: EnableFirewall => 0  [OK]

USERENV(16c.300) 12:03:23:938 ParseRegistryFile: Leaving.

USERENV(16c.300) 12:03:23:948 ParseRegistryFile: Entering with <\\contoso.com\sysvol\contoso.com\Policies\{31B2F340-016D-11D2-945F-00C04FB984F9}\Machine\registry.pol>.

USERENV(16c.300) 12:03:24:008 LogRegistry RsopData: Successfully logged registry Rsop data

USERENV(16c.300) 12:03:24:028 LeaveCriticalPolicySection: Critical section 0x824 has been released.

USERENV(16c.300) 12:03:24:028 ProcessGPOList: Extension Registry was able to log data. RsopStatus = 0x0, dwRet = 0, Clearing the dirty bit

USERENV(16c.300) 12:03:24:038 ProcessGPOs: -----------------------

USERENV(16c.300) 12:03:24:038 ProcessGPOs: -----------------------

When Group Policy processing occurs, it occurs at the Client Side Extension.  If one setting changes for, say, Folder Redirection, any Group Policy that leverages the Client Side Extension fdeploy.dll would have to process regardless of whether or not the actual Group Policy changed.

USERENV(16c.300) 12:03:24:038 ProcessGPOs: Processing extension Wireless

USERENV(16c.300) 12:03:24:038 ReadStatus: Read Extension's Previous status successfully.

USERENV(16c.300) 12:03:24:038 CompareGPOLists:  The lists are the same.

USERENV(16c.300) 12:03:24:038 ProcessGPOs: Extension Wireless skipped because both deleted and changed GPO lists are empty.

The above section shows that no changes were made to any Group Policy that leverages the Client Side extension for Wireless and, therefore, there was nothing for it to do.

More CSE processing:

USERENV(16c.300) 12:03:24:038 ProcessGPOs: -----------------------

USERENV(16c.300) 12:03:24:038 ProcessGPOs: Processing extension Folder Redirection

USERENV(16c.300) 12:03:24:038 CompareGPOLists:  The lists are the same.

USERENV(16c.300) 12:03:24:038 ProcessGPOs: Extension Folder Redirection skipped with flags 0x1000f.

USERENV(16c.300) 12:03:24:038 ProcessGPOs: -----------------------

USERENV(16c.300) 12:03:24:038 ProcessGPOs: Processing extension Microsoft Disk Quota

USERENV(16c.300) 12:03:24:038 CompareGPOLists:  The lists are the same.

USERENV(16c.300) 12:03:24:038 ProcessGPOs: Extension Microsoft Disk Quota skipped with flags 0x1000f.

USERENV(16c.300) 12:03:24:038 ProcessGPOs: -----------------------

USERENV(16c.300) 12:03:24:038 ProcessGPOs: Processing extension QoS Packet Scheduler

USERENV(16c.300) 12:03:24:038 CompareGPOLists:  The lists are the same.

USERENV(16c.300) 12:03:24:038 ProcessGPOs: Extension QoS Packet Scheduler skipped because both deleted and changed GPO lists are empty.

USERENV(16c.300) 12:03:24:038 ProcessGPOs: -----------------------

USERENV(16c.300) 12:03:24:038 ProcessGPOs: Processing extension Scripts

USERENV(16c.300) 12:03:24:038 ReadStatus: Read Extension's Previous status successfully.

USERENV(16c.300) 12:03:24:038 CompareGPOLists:  The lists are the same.

USERENV(16c.300) 12:03:24:038 ProcessGPOs: Extension Scripts skipped because both deleted and changed GPO lists are empty.

USERENV(16c.300) 12:03:24:038 ProcessGPOs: -----------------------

USERENV(16c.300) 12:03:24:038 ProcessGPOs: Processing extension Internet Explorer Zonemapping

USERENV(16c.300) 12:03:24:038 CompareGPOLists:  The lists are the same.

USERENV(16c.300) 12:03:24:038 ProcessGPOs: Extension Internet Explorer Zonemapping skipped because both deleted and changed GPO lists are empty.

USERENV(16c.300) 12:03:24:038 ProcessGPOs: -----------------------

USERENV(16c.300) 12:03:24:038 ProcessGPOs: Processing extension Security

USERENV(16c.300) 12:03:24:038 ReadStatus: Read Extension's Previous status successfully.

USERENV(16c.300) 12:03:24:038 CompareGPOLists:  The lists are the same.

USERENV(16c.300) 12:03:24:038 ProcessGPOList: Entering for extension Security

USERENV(16c.300) 12:03:24:038 MachinePolicyCallback: Setting status UI to Applying Security policy...

USERENV(16c.300) 12:03:24:038 MachinePolicyCallback: Extension requested status UI when status UI is not available.

USERENV(16c.300) 12:03:24:038 LogExtSessionStatus: Successfully logged Extension Session data

USERENV(16c.300) 12:03:24:058 MachinePolicyCallback: Setting status UI to Applying security policy...

USERENV(16c.300) 12:03:24:058 MachinePolicyCallback: Extension requested status UI when status UI is not available.

USERENV(16c.300) 12:03:24:058 MachinePolicyCallback: Setting status UI to Default Domain Policy

USERENV(16c.300) 12:03:24:058 MachinePolicyCallback: Extension requested status UI when status UI is not available.

USERENV(16c.300) 12:03:24:158 MachinePolicyCallback: Setting status UI to Configuring security policy to the system.

USERENV(16c.300) 12:03:24:158 MachinePolicyCallback: Extension requested status UI when status UI is not available.

USERENV(16c.300) 12:03:26:712 MachinePolicyCallback: Setting status UI to Applying computer settings...

USERENV(16c.300) 12:03:26:712 MachinePolicyCallback: Extension requested status UI when status UI is not available.

USERENV(16c.300) 12:03:26:712 ProcessGPOList: Extension Security returned 0x0.

USERENV(16c.300) 12:03:26:712 ProcessGPOList: Extension Security was able to log data. RsopStatus = 0x0, dwRet = 0, Clearing the dirty bit

USERENV(16c.300) 12:03:26:722 ProcessGPOs: -----------------------

USERENV(16c.300) 12:03:26:722 ProcessGPOs: -----------------------

USERENV(16c.300) 12:03:26:722 ProcessGPOs: Processing extension Internet Explorer Branding

USERENV(16c.300) 12:03:26:722 CompareGPOLists:  The lists are the same.

USERENV(16c.300) 12:03:26:722 ProcessGPOs: Extension Internet Explorer Branding skipped with flags 0x1000f.

USERENV(16c.300) 12:03:26:722 ProcessGPOs: -----------------------

USERENV(16c.300) 12:03:26:722 ProcessGPOs: Processing extension EFS recovery

USERENV(16c.300) 12:03:26:722 ReadStatus: Read Extension's Previous status successfully.

USERENV(16c.300) 12:03:26:722 CompareGPOLists:  The lists are the same.

USERENV(16c.300) 12:03:26:722 ProcessGPOList: Entering for extension EFS recovery

USERENV(16c.300) 12:03:26:722 MachinePolicyCallback: Setting status UI to Applying EFS recovery policy...

USERENV(16c.300) 12:03:26:722 MachinePolicyCallback: Extension requested status UI when status UI is not available.

USERENV(16c.300) 12:03:26:722 ReadStatus: Read Extension's Previous status successfully.

USERENV(16c.300) 12:03:26:732 LogExtSessionStatus: Successfully logged Extension Session data

USERENV(16c.300) 12:03:26:732 ProcessGPOList: Extension EFS recovery returned 0x0.

USERENV(16c.300) 12:03:26:732 ProcessGPOList: Extension EFS recovery doesn't support rsop logging

USERENV(16c.300) 12:03:26:742 ProcessGPOs: -----------------------

USERENV(16c.300) 12:03:26:742 ProcessGPOs: -----------------------

USERENV(16c.300) 12:03:26:742 ProcessGPOs: Processing extension 802.3 Group Policy

USERENV(16c.300) 12:03:26:742 CompareGPOLists:  The lists are the same.

USERENV(16c.300) 12:03:26:742 ProcessGPOs: Extension 802.3 Group Policy skipped because both deleted and changed GPO lists are empty.

USERENV(16c.300) 12:03:26:742 ProcessGPOs: -----------------------

USERENV(16c.300) 12:03:26:742 ProcessGPOs: Processing extension Microsoft Offline Files

USERENV(16c.300) 12:03:26:742 CompareGPOLists:  The lists are the same.

USERENV(16c.300) 12:03:26:742 ProcessGPOs: Extension Microsoft Offline Files skipped because both deleted and changed GPO lists are empty.

USERENV(16c.300) 12:03:26:742 ProcessGPOs: -----------------------

USERENV(16c.300) 12:03:26:742 ProcessGPOs: Processing extension Software Installation

USERENV(16c.300) 12:03:26:742 ReadStatus: Read Extension's Previous status successfully.

USERENV(16c.300) 12:03:26:742 CompareGPOLists:  The lists are the same.

USERENV(16c.300) 12:03:26:742 ProcessGPOs: Extension Software Installation skipped because both deleted and changed GPO lists are empty.

USERENV(16c.300) 12:03:26:742 ProcessGPOs: -----------------------

USERENV(16c.300) 12:03:26:742 ProcessGPOs: Processing extension IP Security

USERENV(16c.300) 12:03:26:742 ReadStatus: Read Extension's Previous status successfully.

USERENV(16c.300) 12:03:26:742 CompareGPOLists:  The lists are the same.

USERENV(16c.300) 12:03:26:742 ProcessGPOs: Extension IP Security skipped because both deleted and changed GPO lists are empty.

After all CSEs have processed, and all GPOs have successfully processed, the client then determines whether or not any settings missed due to Asynchronous policy processing versus Synchronous processing.  If any policies failed to process because the computer required a Synchronous foreground policy processing a message would display in the next line stating that the next policy processing would be a Synchronous policy process.

USERENV(16c.300) 12:03:26:742 SetFgRefreshInfo: Previous Machine Fg policy Asynchronous, Reason: NoNeedForSync.

USERENV(16c.300) 12:03:26:742 LeaveCriticalPolicySection: Critical section 0x728 has been released.

USERENV(16c.300) 12:03:26:742 ProcessGPOs: Computer Group Policy has been applied.

USERENV(16c.300) 12:03:26:742 ProcessGPOs: Leaving with 1.

USERENV(16c.300) 12:03:26:742 ApplyGroupPolicy: Leaving successfully.

USERENV(16c.57c) 12:03:26:752 PolicyChangedThread: Calling UpdateUser with 1.

USERENV(16c.57c) 12:03:26:752 PolicyChangedThread: Broadcast message for 1.

USERENV(16c.57c) 12:03:26:752 PolicyChangedThread: Leaving

Group Policy processing (in this case for the computer account) occurs at system boot and during the background policy refresh which occurs anywhere from 90 - 120 minutes after the last policy processing.  This next line shows when the next policy refresh will occur:

USERENV(16c.580) 12:03:26:752 GPOThread:  Next refresh will happen in 102 minutes

At this point, the client processing of Group Policy is complete.

Now that we’ve seen a successful boot sequence of a Windows XP, let’s look at a user logon process.  There are a lot of similarities between a boot sequence and a user logon process.  First thing we see is a check to determine if the system context can impersonate the user account (in this case the user HQUser):

USERENV(160.164) 14:15:18:845 LoadUserProfile: Yes, we can impersonate the user. Running as self

USERENV(160.164) 14:15:18:845 =========================================================

USERENV(160.164) 14:15:18:845 LoadUserProfile: Entering, hToken = <0x844>, lpProfileInfo = 0x6e3e0

USERENV(160.164) 14:15:18:845 LoadUserProfile: lpProfileInfo->dwFlags = <0x0>

USERENV(160.164) 14:15:18:845 LoadUserProfile: lpProfileInfo->lpUserName = <HQUser>

USERENV(160.164) 14:15:18:845 LoadUserProfile: NULL central profile path

USERENV(160.164) 14:15:18:845 LoadUserProfile: lpProfileInfo->lpDefaultPath = <\\ROOTDC\netlogon\Default User>

USERENV(160.164) 14:15:18:845 LoadUserProfile: NULL server name

USERENV(160.164) 14:15:18:845 LoadUserProfile: In console winlogon process

USERENV(160.164) 14:15:18:845 In LoadUserProfileP

USERENV(160.164) 14:15:18:845 =========================================================

----- Snip (A lot of profile loading and expanding of the profile path) -----

Now we start processing Group Policy.  The initial check it to determine if we need a Synchronous or Asynchronous processing of Group Policy.  This was the first time I logged in as this user and, therefore, Fast Logon Optimization was turned on and a Synchronous refresh of Group Policy was required:

USERENV(160.164) 14:15:21:689 IsSyncForegroundPolicyRefresh: Synchronous, Reason: FirstPolicyRefresh

USERENV(160.7b0) 14:15:21:689 IsSyncForegroundPolicyRefresh: Synchronous, Reason: FirstPolicyRefresh

USERENV(160.7b0) 14:15:21:910 ApplyGroupPolicy: Entering. Flags = 6

USERENV(160.7b0) 14:15:21:910 ProcessGPOs:

USERENV(160.7b0) 14:15:21:910 ProcessGPOs:

USERENV(160.7b0) 14:15:21:910 ProcessGPOs: Starting user Group Policy (Background) processing...

USERENV(160.7b0) 14:15:21:910 ProcessGPOs:

USERENV(160.7b0) 14:15:21:910 ProcessGPOs:

USERENV(160.7b0) 14:15:21:910 EnterCriticalPolicySectionEx: Entering with timeout 600000 and flags 0x0

USERENV(160.7b0) 14:15:21:910 EnterCriticalPolicySectionEx: User critical section has been claimed.  Handle = 0x774

USERENV(160.7b0) 14:15:21:910 EnterCriticalPolicySectionEx: Leaving successfully.

Slow Link Detection again and again we determined the connection to be a fast link:

USERENV(160.7b0) 14:15:21:910 PingComputer: PingBufferSize set as 2048

USERENV(160.7b0) 14:15:21:910 PingComputer: Adapter speed 100000000 bps

USERENV(160.7b0) 14:15:21:910 PingComputer:  First time:  0

USERENV(160.7b0) 14:15:21:910 PingComputer:  Fast link.  Exiting.

Enumerating the user account:

USERENV(160.7b0) 14:15:21:910 ProcessGPOs:  User name is:  CN=HQ User,OU=HQ Users,OU=Company Users,DC=contoso,DC=com, Domain name is:  CONTOSO

USERENV(160.7b0) 14:15:21:910 ProcessGPOs: Domain controller is:  \\ROOTDC.contoso.com  Domain DN is contoso.com

RSOP entry point for client side extensions and reading the previous state of each CSE again:

USERENV(160.7b0) 14:15:21:910 ReadGPExtensions: Rsop entry point not found for gptext.dll.

USERENV(160.7b0) 14:15:21:910 ReadGPExtensions: Rsop entry point not found for dskquota.dll.

USERENV(160.7b0) 14:15:21:910 ReadGPExtensions: Rsop entry point not found for gptext.dll.

USERENV(160.7b0) 14:15:21:910 ReadGPExtensions: Rsop entry point not found for iedkcs32.dll.

USERENV(160.7b0) 14:15:21:910 ReadGPExtensions: Rsop entry point not found for scecli.dll.

USERENV(160.7b0) 14:15:21:910 ReadGPExtensions: Rsop entry point not found for C:\WINDOWS\System32\cscui.dll.

USERENV(160.7b0) 14:15:21:910 ReadGPExtensions: Rsop entry point not found for gptext.dll.

USERENV(160.7b0) 14:15:21:910 ReadExtStatus: Reading Previous Status for extension {35378EAC-683F-11D2-A89A-00C04FBBCFA2}

USERENV(160.7b0) 14:15:21:910 ReadExtStatus: Reading Previous Status for extension {0ACDD40C-75AC-47ab-BAA0-BF6DE7E7FE63}

USERENV(160.7b0) 14:15:21:920 ReadExtStatus: Reading Previous Status for extension {25537BA6-77A8-11D2-9B6C-0000F8080861}

USERENV(160.7b0) 14:15:21:920 ReadExtStatus: Reading Previous Status for extension {3610eda5-77ef-11d2-8dc5-00c04fa31a66}

USERENV(160.7b0) 14:15:21:920 ReadExtStatus: Reading Previous Status for extension {426031c0-0b47-4852-b0ca-ac3d37bfcb39}

USERENV(160.7b0) 14:15:21:920 ReadExtStatus: Reading Previous Status for extension {42B5FAAE-6536-11d2-AE5A-0000F87571E3}

USERENV(160.7b0) 14:15:21:920 ReadExtStatus: Reading Previous Status for extension {4CFB60C1-FAA6-47f1-89AA-0B18730C9FD3}

USERENV(160.7b0) 14:15:21:920 ReadExtStatus: Reading Previous Status for extension {827D319E-6EAC-11D2-A4EA-00C04F79F83A}

USERENV(160.7b0) 14:15:21:920 ReadExtStatus: Reading Previous Status for extension {A2E30F80-D7DE-11d2-BBDE-00C04F86AE3B}

USERENV(160.7b0) 14:15:21:920 ReadExtStatus: Reading Previous Status for extension {B1BE8D72-6EAC-11D2-A4EA-00C04F79F83A}

USERENV(160.7b0) 14:15:21:920 ReadExtStatus: Reading Previous Status for extension {B587E2B1-4D59-4e7e-AED9-22B9DF11D053}

USERENV(160.7b0) 14:15:21:920 ReadExtStatus: Reading Previous Status for extension {C631DF4C-088F-4156-B058-4375F0853CD8}

USERENV(160.7b0) 14:15:21:920 ReadExtStatus: Reading Previous Status for extension {c6dc5466-785a-11d2-84d0-00c04fb169f7}

USERENV(160.7b0) 14:15:21:920 ReadExtStatus: Reading Previous Status for extension {e437bc1c-aa7d-11d2-a382-00c04f991e27}

Gathering GPOs for processing:

USERENV(160.7b0) 14:15:21:920 ProcessGPOs: Calling GetGPOInfo for normal policy mode

USERENV(160.7b0) 14:15:21:920 GetGPOInfo:  ********************************

USERENV(160.7b0) 14:15:21:920 GetGPOInfo:  Entering...

USERENV(160.7b0) 14:15:21:920 GetGPOInfo:  Server connection established.

USERENV(160.7b0) 14:15:21:920 GetGPOInfo:  Bound successfully.

USERENV(160.7b0) 14:15:21:930 SearchDSObject:  Searching <OU=HQ Users,OU=Company Users,DC=contoso,DC=com>

USERENV(160.7b0) 14:15:21:930 SearchDSObject:  No GPO(s) for this object.

USERENV(160.7b0) 14:15:21:930 SearchDSObject:  Searching <OU=Company Users,DC=contoso,DC=com>

USERENV(160.7b0) 14:15:21:930 SearchDSObject:  Found GPO(s):  <[LDAP://cn={2C1B39B1-02EC-41B9-B6BA-BD0E7FCC7155},cn=policies,cn=system,DC=contoso,DC=com;0]>

USERENV(160.7b0) 14:15:21:930 ProcessGPO:  ==============================

USERENV(160.7b0) 14:15:21:930 ProcessGPO:  Deferring search for <LDAP://cn={2C1B39B1-02EC-41B9-B6BA-BD0E7FCC7155},cn=policies,cn=system,DC=contoso,DC=com>

USERENV(160.7b0) 14:15:21:930 SearchDSObject:  Searching <DC=contoso,DC=com>

USERENV(160.7b0) 14:15:21:930 SearchDSObject:  Found GPO(s):  <[LDAP://cn={AF5C4ACE-C8FD-4574-A9E4-07B77EED376E},cn=policies,cn=system,DC=contoso,DC=com;0][LDAP://CN={31B2F340-016D-11D2-945F-00C04FB984F9},CN=Policies,CN=System,DC=contoso,DC=com;0]>

USERENV(160.7b0) 14:15:21:930 ProcessGPO:  ==============================

USERENV(160.7b0) 14:15:21:930 ProcessGPO:  Deferring search for <LDAP://cn={AF5C4ACE-C8FD-4574-A9E4-07B77EED376E},cn=policies,cn=system,DC=contoso,DC=com>

USERENV(160.7b0) 14:15:21:930 ProcessGPO:  ==============================

USERENV(160.7b0) 14:15:21:930 ProcessGPO:  Deferring search for <LDAP://CN={31B2F340-016D-11D2-945F-00C04FB984F9},CN=Policies,CN=System,DC=contoso,DC=com>

USERENV(160.7b0) 14:15:21:930 SearchDSObject:  Searching <CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=contoso,DC=com>

USERENV(160.7b0) 14:15:21:930 SearchDSObject:  No GPO(s) for this object.

USERENV(160.7b0) 14:15:21:930 EvaluateDeferredGPOs:  Searching for GPOs in cn=policies,cn=system,DC=contoso,DC=com

Checking to make sure the user account has access to the GPO and that it passes WMI filtering checks:

USERENV(160.7b0) 14:15:21:930 ProcessGPO:  ==============================

USERENV(160.7b0) 14:15:21:930 ProcessGPO:  Searching <cn={AF5C4ACE-C8FD-4574-A9E4-07B77EED376E},cn=policies,cn=system,DC=contoso,DC=com>

USERENV(160.7b0) 14:15:21:930 ProcessGPO:  User has access to this GPO.

USERENV(160.7b0) 14:15:21:930 ProcessGPO:  GPO passes the filter check.

USERENV(160.7b0) 14:15:21:930 ProcessGPO:  Found functionality version of:  2

USERENV(160.7b0) 14:15:21:930 ProcessGPO:  Found file system path of:  <\\contoso.com\SysVol\contoso.com\Policies\{AF5C4ACE-C8FD-4574-A9E4-07B77EED376E}>

USERENV(160.7b0) 14:15:21:970 ProcessGPO:  Found common name of:  <{AF5C4ACE-C8FD-4574-A9E4-07B77EED376E}>

USERENV(160.7b0) 14:15:21:970 ProcessGPO:  Found display name of:  <All Domain Systems>

USERENV(160.7b0) 14:15:21:970 ProcessGPO:  Found user version of:  GPC is 0, GPT is 0

USERENV(160.7b0) 14:15:21:970 ProcessGPO:  Found flags of:  0

USERENV(160.7b0) 14:15:21:970 ProcessGPO:  No client-side extensions for this object.

USERENV(160.7b0) 14:15:21:970 ProcessGPO:  GPO All Domain Systems doesn't contain any data since the version number is 0.  It will be skipped.

USERENV(160.7b0) 14:15:21:970 ProcessGPO:  ==============================

USERENV(160.7b0) 14:15:21:970 ProcessGPO:  ==============================

USERENV(160.7b0) 14:15:21:970 ProcessGPO:  Searching <CN={31B2F340-016D-11D2-945F-00C04FB984F9},CN=Policies,CN=System,DC=contoso,DC=com>

USERENV(160.7b0) 14:15:21:970 ProcessGPO:  User has access to this GPO.

USERENV(160.7b0) 14:15:21:980 ProcessGPO:  GPO passes the filter check.

USERENV(160.7b0) 14:15:21:980 ProcessGPO:  Found functionality version of:  2

USERENV(160.7b0) 14:15:21:980 ProcessGPO:  Found file system path of:  <\\contoso.com\sysvol\contoso.com\Policies\{31B2F340-016D-11D2-945F-00C04FB984F9}>

USERENV(160.7b0) 14:15:21:980 ProcessGPO:  Found common name of:  <{31B2F340-016D-11D2-945F-00C04FB984F9}>

USERENV(160.7b0) 14:15:21:980 ProcessGPO:  Found display name of:  <Default Domain Policy>

USERENV(160.7b0) 14:15:21:980 ProcessGPO:  Found user version of:  GPC is 1, GPT is 1

USERENV(160.7b0) 14:15:21:980 ProcessGPO:  Found flags of:  0

USERENV(160.7b0) 14:15:21:980 ProcessGPO:  Found extensions:  [{3060E8D0-7020-11D2-842D-00C04FA372D4}{3060E8CE-7020-11D2-842D-00C04FA372D4}]

USERENV(160.7b0) 14:15:21:980 ProcessGPO:  ==============================

USERENV(160.7b0) 14:15:21:980 ProcessGPO:  ==============================

USERENV(160.7b0) 14:15:21:980 ProcessGPO:  Searching <cn={2C1B39B1-02EC-41B9-B6BA-BD0E7FCC7155},cn=policies,cn=system,DC=contoso,DC=com>

USERENV(160.7b0) 14:15:21:980 ProcessGPO:  User has access to this GPO.

USERENV(160.7b0) 14:15:21:980 ProcessGPO:  GPO passes the filter check.

USERENV(160.7b0) 14:15:21:980 ProcessGPO:  Found functionality version of:  2

USERENV(160.7b0) 14:15:21:980 ProcessGPO:  Found file system path of:  <\\contoso.com\SysVol\contoso.com\Policies\{2C1B39B1-02EC-41B9-B6BA-BD0E7FCC7155}>

USERENV(160.7b0) 14:15:21:980 ProcessGPO:  Found common name of:  <{2C1B39B1-02EC-41B9-B6BA-BD0E7FCC7155}>

USERENV(160.7b0) 14:15:21:980 ProcessGPO:  Found display name of:  <All Company Users>

USERENV(160.7b0) 14:15:21:980 ProcessGPO:  Found user version of:  GPC is 3, GPT is 3

USERENV(160.7b0) 14:15:21:980 ProcessGPO:  Found flags of:  0

USERENV(160.7b0) 14:15:21:980 ProcessGPO:  Found extensions:  [{35378EAC-683F-11D2-A89A-00C04FBBCFA2}{0F6B957E-509E-11D1-A7CC-0000F87571E3}]

USERENV(160.7b0) 14:15:21:980 ProcessGPO:  ==============================

Checking for any local GPOs at this point:

USERENV(160.7b0) 14:15:21:980 GetGPOInfo:  Local GPO's gpt.ini is not accessible, assuming default state.

USERENV(160.7b0) 14:15:21:980 GetGPOInfo:  Leaving with 1

USERENV(160.7b0) 14:15:21:980 GetGPOInfo:  ********************************

USERENV(160.7b0) 14:15:21:990 ProcessGPOs: Logging Data for Target <HQUser>.

USERENV(160.7b0) 14:15:21:990 GetWbemServices: CoCreateInstance succeeded

USERENV(160.7b0) 14:15:22:020 ConnectToNameSpace: ConnectServer returned 0x8004100e

USERENV(160.7b0) 14:15:22:350 LogExtSessionStatus: Successfully logged Extension Session data

USERENV(160.7b0) 14:15:22:350 CSessionLogger::Log: logging new security grps

USERENV(160.7b0) 14:15:22:370 LogRsopData: Successfully logged Rsop data

USERENV(160.7b0) 14:15:22:370 ProcessGPOs: Logged Rsop Data successfully.

Processing GPO:

USERENV(160.7b0) 14:15:22:390 ProcessGPOs: -----------------------

USERENV(160.7b0) 14:15:22:390 ProcessGPOs: Processing extension Registry

USERENV(160.7b0) 14:15:22:390 CompareGPOLists:  One list is empty

USERENV(160.7b0) 14:15:22:390 ProcessGPOList: Entering for extension Registry

USERENV(160.7b0) 14:15:22:390 UserPolicyCallback: Setting status UI to Applying Registry policy...

USERENV(160.7b0) 14:15:22:390 LogExtSessionStatus: Successfully logged Extension Session data

USERENV(160.7b0) 14:15:22:390 EnterCriticalPolicySectionEx: Entering with timeout 60000 and flags 0x2

USERENV(160.7b0) 14:15:22:390 EnterCriticalPolicySectionEx: User critical section has been claimed.  Handle = 0x894

USERENV(160.7b0) 14:15:22:390 EnterCriticalPolicySectionEx: Leaving successfully.

USERENV(160.7b0) 14:15:22:390 ResetPolicies: Entering.

USERENV(160.7b0) 14:15:22:390 ParseRegistryFile: Entering with <C:\Documents and Settings\HQUser\ntuser.pol>.

USERENV(160.7b0) 14:15:22:390 ParseRegistryFile: Leaving.

USERENV(160.7b0) 14:15:22:390 ResetPolicies: Leaving.

Getting registry.pol for the GPOs:

USERENV(160.7b0) 14:15:22:400 ParseRegistryFile: Entering with <\\contoso.com\SysVol\contoso.com\Policies\{2C1B39B1-02EC-41B9-B6BA-BD0E7FCC7155}\User\registry.pol>.

The settings I configured for this particular GPO was to remove the Welcome Screen, add Logoff to the Start Menu and to disable the automatic update of ADM files during GPO editing.  These settings are seen here:

USERENV(160.7b0) 14:15:22:400 SetRegistryValue: NoWelcomeScreen => 1  [OK]

USERENV(160.7b0) 14:15:22:400 SetRegistryValue: ForceStartMenuLogOff => 1  [OK]

USERENV(160.7b0) 14:15:22:400 SetRegistryValue: DisableAutoADMUpdate => 1  [OK]

USERENV(160.7b0) 14:15:22:400 ParseRegistryFile: Leaving.

USERENV(160.7b0) 14:15:22:430 LeaveCriticalPolicySection: Critical section 0x894 has been released.

USERENV(160.7b0) 14:15:22:430 ProcessGPOList: Extension Registry was able to log data. RsopStatus = 0x0, dwRet = 0, Clearing the dirty bit

USERENV(160.7b0) 14:15:22:430 ProcessGPOs: -----------------------

USERENV(160.7b0) 14:15:22:430 ProcessGPOs: -----------------------

Processing Client Side Extensions:

USERENV(160.7b0) 14:15:22:430 ProcessGPOs: Processing extension Wireless

USERENV(160.7b0) 14:15:22:430 CompareGPOLists:  The lists are the same.

USERENV(160.7b0) 14:15:22:430 ProcessGPOs: Extension Wireless skipped with flags 0x6.

USERENV(160.7b0) 14:15:22:430 ProcessGPOs: -----------------------

USERENV(160.7b0) 14:15:22:430 ProcessGPOs: Processing extension Folder Redirection

USERENV(160.7b0) 14:15:22:430 CompareGPOLists:  The lists are the same.

USERENV(160.7b0) 14:15:22:430 CompareGPOLists:  The lists are the same.

USERENV(160.7b0) 14:15:22:430 ProcessGPOs: Extension Folder Redirection skipped because both deleted and changed GPO lists are empty.

USERENV(160.7b0) 14:15:22:430 ProcessGPOs: -----------------------

USERENV(160.7b0) 14:15:22:430 ProcessGPOs: Processing extension Microsoft Disk Quota

USERENV(160.7b0) 14:15:22:430 CompareGPOLists:  The lists are the same.

USERENV(160.7b0) 14:15:22:430 ProcessGPOs: Extension Microsoft Disk Quota skipped with flags 0x6.

USERENV(160.7b0) 14:15:22:430 ProcessGPOs: -----------------------

USERENV(160.7b0) 14:15:22:430 ProcessGPOs: Processing extension QoS Packet Scheduler

USERENV(160.7b0) 14:15:22:430 CompareGPOLists:  The lists are the same.

USERENV(160.7b0) 14:15:22:430 ProcessGPOs: Extension QoS Packet Scheduler skipped with flags 0x6.

USERENV(160.7b0) 14:15:22:430 ProcessGPOs: -----------------------

USERENV(160.7b0) 14:15:22:430 ProcessGPOs: Processing extension Scripts

USERENV(160.7b0) 14:15:22:430 CompareGPOLists:  The lists are the same.

USERENV(160.7b0) 14:15:22:430 ProcessGPOs: Extension Scripts skipped because both deleted and changed GPO lists are empty.

USERENV(160.7b0) 14:15:22:430 ProcessGPOs: -----------------------

USERENV(160.7b0) 14:15:22:430 ProcessGPOs: Processing extension Internet Explorer Zonemapping

USERENV(160.7b0) 14:15:22:430 CompareGPOLists:  The lists are the same.

USERENV(160.7b0) 14:15:22:430 ProcessGPOs: Extension Internet Explorer Zonemapping skipped because both deleted and changed GPO lists are empty.

USERENV(160.7b0) 14:15:22:430 ProcessGPOs: -----------------------

USERENV(160.7b0) 14:15:22:430 ProcessGPOs: Processing extension Security

USERENV(160.7b0) 14:15:22:430 CompareGPOLists:  The lists are the same.

USERENV(160.7b0) 14:15:22:430 ProcessGPOs: Extension Security skipped with flags 0x6.

USERENV(160.7b0) 14:15:22:430 ProcessGPOs: -----------------------

USERENV(160.7b0) 14:15:22:430 ProcessGPOs: Processing extension Internet Explorer Branding

USERENV(160.7b0) 14:15:22:440 CompareGPOLists:  The lists are the same.

USERENV(160.7b0) 14:15:22:440 ProcessGPOs: Extension Internet Explorer Branding skipped because both deleted and changed GPO lists are empty.

USERENV(160.7b0) 14:15:22:440 ProcessGPOs: -----------------------

USERENV(160.7b0) 14:15:22:440 ProcessGPOs: Processing extension EFS recovery

USERENV(160.7b0) 14:15:22:440 CompareGPOLists:  The lists are the same.

USERENV(160.7b0) 14:15:22:440 ProcessGPOs: Extension EFS recovery skipped with flags 0x6.

USERENV(160.7b0) 14:15:22:440 ProcessGPOs: -----------------------

USERENV(160.7b0) 14:15:22:440 ProcessGPOs: Processing extension 802.3 Group Policy

USERENV(160.7b0) 14:15:22:440 CompareGPOLists:  The lists are the same.

USERENV(160.7b0) 14:15:22:440 ProcessGPOs: Extension 802.3 Group Policy skipped with flags 0x6.

USERENV(160.7b0) 14:15:22:440 ProcessGPOs: -----------------------

USERENV(160.7b0) 14:15:22:440 ProcessGPOs: Processing extension Microsoft Offline Files

USERENV(160.7b0) 14:15:22:440 CompareGPOLists:  The lists are the same.

USERENV(160.7b0) 14:15:22:440 ProcessGPOs: Extension Microsoft Offline Files skipped with flags 0x6.

USERENV(160.7b0) 14:15:22:440 ProcessGPOs: -----------------------

USERENV(160.7b0) 14:15:22:440 ProcessGPOs: Processing extension Software Installation

USERENV(160.7b0) 14:15:22:440 CompareGPOLists:  The lists are the same.

USERENV(160.7b0) 14:15:22:440 CompareGPOLists:  The lists are the same.

USERENV(160.7b0) 14:15:22:440 ProcessGPOs: Extension Software Installation skipped because both deleted and changed GPO lists are empty.

USERENV(160.7b0) 14:15:22:440 ProcessGPOs: -----------------------

USERENV(160.7b0) 14:15:22:440 ProcessGPOs: Processing extension IP Security

USERENV(160.7b0) 14:15:22:440 CompareGPOLists:  The lists are the same.

USERENV(160.7b0) 14:15:22:440 ProcessGPOs: Extension IP Security skipped with flags 0x6.

Determining if any settings were not able to be applied due to an asynchronous refresh of Group Policy.  This was the first login so it was a Synchronous process of Group Policy:

USERENV(160.7b0) 14:15:22:440 SetFgRefreshInfo: Previous User Fg policy Synchronous, Reason: FirstPolicyRefresh.

USERENV(160.7b0) 14:15:22:440 SetFgRefreshInfo: Next User Fg policy Asynchronous, Reason: NoNeedForSync.

USERENV(160.7b0) 14:15:22:440 LeaveCriticalPolicySection: Critical section 0x774 has been released.

Group Policy is reporting as being applied:

USERENV(160.7b0) 14:15:22:440 ProcessGPOs: User Group Policy has been applied.

USERENV(160.7b0) 14:15:22:440 ProcessGPOs: Leaving with 1.

USERENV(160.7b0) 14:15:22:440 ApplyGroupPolicy: Leaving successfully.

USERENV(160.164) 14:15:22:731 IsSyncForegroundPolicyRefresh: Asynchronous, Reason: NoNeedForSync

USERENV(70.bc) 14:15:22:801 LibMain: Process Name:  C:\WINDOWS\system32\userinit.exe

USERENV(8c.94) 14:15:22:861 LibMain: Process Name:  C:\WINDOWS\system32\userinit.exe

The next couple of lines are common in UserEnv logs.  The “Failed to impersonate user with 5” error is common and does not necessarily represent an error with Group Policy processing.  Remember that the process being logged is reported in HEX.  If you look at the next couple of lines, you’ll see that the process changes from HEX 160 to HEX 198.  Another process attempted to impersonate the user and failed.  In this case, it had nothing to do with Group Policy processing:

USERENV(198.1b0) 14:15:22:961 ImpersonateUser: Failed to impersonate user with 5.

USERENV(198.1b0) 14:15:22:961 GetUserNameAndDomain Failed to impersonate user

USERENV(198.1b0) 14:15:22:961 ImpersonateUser: Failed to impersonate user with 5.

USERENV(198.1b0) 14:15:22:961 GetUserDNSDomainName: Failed to impersonate user

Group Policy processing is complete at this point and the random background refresh is displayed here:

USERENV(160.7cc) 14:15:22:971 GPOThread:  Next refresh will happen in 90 minutes

So now we’ve covered both the client boot process and the user logon process.  Now let’s look at our first error.  This first snippet is a time synchronization error which resulted in an initial pass of Group Policy processing failing during a client boot process:

USERENV(160.2c8) 14:02:42:867 ProcessGPOs: Calling GetGPOInfo for normal policy mode

USERENV(160.2c8) 14:02:42:867 GetGPOInfo:  ********************************

USERENV(160.2c8) 14:02:42:867 GetGPOInfo:  Entering...

USERENV(160.2c8) 14:02:42:877 GetMachineToken:  AcceptSecurityContext failed with 0x80090324

USERENV(160.2c8) 14:02:42:877 GetGPOInfo:  Failed to get the machine token with  -2146893020

USERENV(160.2c8) 14:02:42:877 GetGPOInfo:  Leaving with 0

USERENV(160.2c8) 14:02:42:877 GetGPOInfo:  ********************************

USERENV(160.2c8) 14:02:42:877 ProcessGPOs: GetGPOInfo failed.

USERENV(160.2c8) 14:02:42:877 ProcessGPOs: No WMI logging done in this policy cycle.

USERENV(160.2c8) 14:02:42:877 ProcessGPOs: Processing failed with error -2146893020.

USERENV(160.2c8) 14:02:42:877 LeaveCriticalPolicySection: Critical section 0x738 has been released.

After I reconfigured the time Group Policy successfully applied.

Let’s look at a Folder Redirection problem now.  I logged in as RemoteUser who has Folder Redirection configured for the desktop and My Documents folders.  Folder Redirection failed though:

USERENV(16c.744) 13:36:42:388 ProcessGPOs: -----------------------

USERENV(16c.744) 13:36:42:388 ProcessGPOs: -----------------------

USERENV(16c.744) 13:36:42:388 ProcessGPOs: Processing extension Wireless

USERENV(16c.744) 13:36:42:388 CompareGPOLists:  The lists are the same.

USERENV(16c.744) 13:36:42:388 ProcessGPOs: Extension Wireless skipped with flags 0x6.

USERENV(16c.744) 13:36:42:388 ProcessGPOs: -----------------------

USERENV(16c.744) 13:36:42:388 ProcessGPOs: Processing extension Folder Redirection

USERENV(16c.744) 13:36:42:388 CompareGPOLists:  One list is empty

USERENV(16c.744) 13:36:42:388 CompareGPOLists:  One list is empty

USERENV(16c.744) 13:36:42:388 ProcessGPOList: Entering for extension Folder Redirection

USERENV(16c.744) 13:36:42:388 UserPolicyCallback: Setting status UI to Applying Folder Redirection policy...

USERENV(16c.744) 13:36:42:388 LogExtSessionStatus: Successfully logged Extension Session data

USERENV(16c.744) 13:36:42:528 UserPolicyCallback: Setting status UI to Applying personal document settings...

USERENV(16c.744) 13:36:42:588 UserPolicyCallback: Setting status UI to Applying personal document settings...

USERENV(16c.744) 13:36:42:628 UserPolicyCallback: Setting status UI to Applying your personal settings...

USERENV(16c.744) 13:36:42:628 ProcessGPOList: Extension Folder Redirection returned 0x5.

USERENV(16c.744) 13:36:42:628 ProcessGPOList: Extension Folder Redirection was able to log data. RsopStatus = 0x0, dwRet = 5, Clearing the dirty bit

USERENV(16c.744) 13:36:42:628 ProcessGPOs: Extension Folder Redirection ProcessGroupPolicy failed, status 0x5.

USERENV(16c.744) 13:36:42:628 ProcessGPOs: -----------------------

USERENV(16c.744) 13:36:42:628 ProcessGPOs: -----------------------

I then enabled FDeploy Client Side Extension logging https://technet.microsoft.com/en-us/library/cc727967(WS.10).aspx

The fdeploy.log file displayed the following information:

13:47:17:356 Entering folder redirection extension

13:47:17:356      Flags = 0x0

13:47:17:396      Group Policy Object name = {FCFEAACD-739E-4516-BE4D-520417A159BE}

13:47:17:396      File system path = \\contoso.com\SysVol\contoso.com\Policies\{FCFEAACD-739E-4516-BE4D-520417A159BE}\User

13:47:17:396      Directory path = LDAP://CN=User,cn={FCFEAACD-739E-4516-BE4D-520417A159BE},cn=policies,cn=system,DC=contoso,DC=com

13:47:17:396      Display name = Remote Users

13:47:17:396 Found folder redirection settings for policy Remote Users.

13:47:17:416 The user was found to be a member of the group s-1-1-0. The corresponding path was \\RootDC\Share\%USERNAME%\Desktop.

13:47:17:416 Successfully obtained redirection data for Desktop, (Flags: 0x31).

13:47:17:416 The user was found to be a member of the group s-1-1-0. The corresponding path was \\RootDC\Share\%USERNAME%\My Documents.

13:47:17:416 Successfully obtained redirection data for My Documents, (Flags: 0x31).

13:47:17:416 Successfully obtained redirection data for My Pictures, (Flags: 0x2).

13:47:17:416 Successfully gathered folder redirection settings for policy Remote Users.

13:47:17:416 Redirecting folder Desktop to \\RootDC\Share\%USERNAME%\Desktop.

13:47:17:456 Previous folder path C:\Documents and Settings\remoteuser\Desktop expanded to C:\Documents and Settings\remoteuser\Desktop.

13:47:17:456 New folder path \\RootDC\Share\%USERNAME%\Desktop expanded to \\RootDC\Share\remoteuser\Desktop.

13:47:17:456 Failed to perform redirection of folder Desktop.

The new directories for the redirected folder could not be created.

The folder is configured to be redirected to <\\RootDC\Share\%USERNAME%\Desktop>, the final expanded path was <\\RootDC\Share\remoteuser\Desktop>.

The following error occurred:

%%5

 

13:47:17:456 Redirecting folder My Documents to \\RootDC\Share\%USERNAME%\My Documents.

13:47:17:476 Previous folder path C:\Documents and Settings\remoteuser\My Documents expanded to C:\Documents and Settings\remoteuser\My Documents.

13:47:17:476 New folder path \\RootDC\Share\%USERNAME%\My Documents expanded to \\RootDC\Share\remoteuser\My Documents.

13:47:17:476 Failed to perform redirection of folder My Documents.

The new directories for the redirected folder could not be created.

The folder is configured to be redirected to <\\RootDC\Share\%USERNAME%\My Documents>, the final expanded path was <\\RootDC\Share\remoteuser\My Documents>.

The following error occurred:

%%5

This issue was related to an Access Denied error in which the system (and user) didn’t have access to create the redirected folder in the shared space.  I corrected that and we then saw the following UserEnv.log and Fdeploy.log:

USERENV(168.4f0) 15:16:30:041 ProcessGPOs: -----------------------

USERENV(168.4f0) 15:16:30:041 ProcessGPOs: Processing extension Folder Redirection

USERENV(168.4f0) 15:16:30:041 ReadStatus: Read Extension's Previous status successfully.

USERENV(168.4f0) 15:16:30:041 CompareGPOLists:  One list is empty

USERENV(168.4f0) 15:16:30:041 CompareGPOLists:  The lists are the same.

USERENV(168.4f0) 15:16:30:041 ProcessGPOList: Entering for extension Folder Redirection

USERENV(168.4f0) 15:16:30:041 UserPolicyCallback: Setting status UI to Applying Folder Redirection policy...

USERENV(168.4f0) 15:16:30:041 GetWbemServices: CoCreateInstance succeeded

USERENV(168.4f0) 15:16:30:061 ConnectToNameSpace: ConnectServer returned 0x0

USERENV(168.4f0) 15:16:30:071 LogExtSessionStatus: Successfully logged Extension Session data

USERENV(168.4f0) 15:16:30:121 UserPolicyCallback: Setting status UI to Applying personal document settings...

USERENV(168.4f0) 15:16:30:221 UserPolicyCallback: Setting status UI to Applying personal document settings...

USERENV(168.4f0) 15:16:30:471 UserPolicyCallback: Setting status UI to Applying personal document settings...

USERENV(168.4f0) 15:16:30:632 UserPolicyCallback: Setting status UI to Applying your personal settings...

USERENV(168.4f0) 15:16:30:632 ProcessGPOList: Extension Folder Redirection returned 0x0.

USERENV(168.4f0) 15:16:30:632 ProcessGPOList: Extension Folder Redirection was able to log data. RsopStatus = 0x0, dwRet = 0, Clearing the dirty bit

USERENV(168.4f0) 15:16:30:642 ProcessGPOs: -----------------------

USERENV(168.4f0) 15:16:30:642 ProcessGPOs: -----------------------

Fdeploy.log:

15:08:22:617 Entering folder redirection extension

15:08:22:617      Flags = 0x0

15:08:22:657      Group Policy Object name = {FCFEAACD-739E-4516-BE4D-520417A159BE}

15:08:22:657      File system path = \\contoso.com\SysVol\contoso.com\Policies\{FCFEAACD-739E-4516-BE4D-520417A159BE}\User

15:08:22:657      Directory path = LDAP://CN=User,cn={FCFEAACD-739E-4516-BE4D-520417A159BE},cn=policies,cn=system,DC=contoso,DC=com

15:08:22:657      Display name = Remote Users

15:08:22:657 Found folder redirection settings for policy Remote Users.

15:08:22:667 The user was found to be a member of the group s-1-1-0. The corresponding path was \\RootDC\Share\%USERNAME%\Desktop.

15:08:22:667 Successfully obtained redirection data for Desktop, (Flags: 0x31).

15:08:22:667 The user was found to be a member of the group s-1-1-0. The corresponding path was \\RootDC\Share\%USERNAME%\My Documents.

15:08:22:667 Successfully obtained redirection data for My Documents, (Flags: 0x31).

15:08:22:667 Successfully obtained redirection data for My Pictures, (Flags: 0x2).

15:08:22:667 Successfully gathered folder redirection settings for policy Remote Users.

15:08:22:667 Redirecting folder Desktop to \\RootDC\Share\%USERNAME%\Desktop.

15:08:22:667 Folder Desktop already redirected to \\RootDC\Share\remoteuser\Desktop.

15:08:22:687 Redirecting folder My Documents to \\RootDC\Share\%USERNAME%\My Documents.

15:08:22:697 Previous folder path C:\Documents and Settings\remoteuser\My Documents expanded to C:\Documents and Settings\remoteuser\My Documents.

15:08:22:697 New folder path \\RootDC\Share\%USERNAME%\My Documents expanded to \\RootDC\Share\remoteuser\My Documents.

15:08:22:757 Contents of redirected folder My Documents will be copied to the new location.

15:08:22:947 Redirecting folder My Pictures to \\RootDC\Share\%USERNAME%\My Documents\My Pictures.

15:08:22:967 Previous folder path C:\Documents and Settings\remoteuser\My Documents\My Pictures expanded to C:\Documents and Settings\remoteuser\My Documents\My Pictures.

15:08:22:967 New folder path \\RootDC\Share\%USERNAME%\My Documents\My Pictures expanded to \\RootDC\Share\remoteuser\My Documents\My Pictures.

15:08:22:977 Contents of redirected folder My Pictures will be copied to the new location.

15:08:23:047 Previous contents of folder My Pictures at C:\Documents and Settings\remoteuser\My Documents\My Pictures will be deleted.

15:08:23:057 Querying the DS for user remoteuser's home directory.

15:08:23:077 Obtained home directory : .

15:08:23:087 Successfully redirected folder My Pictures.

The folder was redirected from <C:\Documents and Settings\remoteuser\My Documents\My Pictures> to <\\RootDC\Share\remoteuser\My Documents\My Pictures>.

15:08:23:087 Previous contents of folder My Documents at C:\Documents and Settings\remoteuser\My Documents will be deleted.

15:08:23:137 Successfully redirected folder My Documents.

The folder was redirected from <C:\Documents and Settings\remoteuser\My Documents> to <\\RootDC\Share\remoteuser\My Documents>.

15:08:23:137 Disabling permission for user redirection of My Documents.

15:08:23:167 Successfully updated the shortcut to My Pictures in <\\RootDC\Share\remoteuser\My Documents>.

This next snippet is an issue with locating gpt.ini which could be a result of gpt.ini simply not existing or an issue with ACLs set on the policy within SYSVOL:

USERENV(160.c0) 14:26:31:248 ProcessGPO:  ==============================

USERENV(160.c0) 14:26:31:248 ProcessGPO:  ==============================

USERENV(160.c0) 14:26:31:248 ProcessGPO:  Searching <cn={2C1B39B1-02EC-41B9-B6BA-BD0E7FCC7155},cn=policies,cn=system,DC=contoso,DC=com>

USERENV(160.c0) 14:26:31:248 ProcessGPO:  User has access to this GPO.

USERENV(160.c0) 14:26:31:248 ProcessGPO:  GPO passes the filter check.

USERENV(160.c0) 14:26:31:248 ProcessGPO:  Found functionality version of:  2

USERENV(160.c0) 14:26:31:248 ProcessGPO:  Found file system path of:  <\\contoso.com\SysVol\contoso.com\Policies\{2C1B39B1-02EC-41B9-B6BA-BD0E7FCC7155}>

USERENV(160.c0) 14:26:31:248 ProcessGPO:  Couldn't find the group policy template file <\\contoso.com\SysVol\contoso.com\Policies\{2C1B39B1-02EC-41B9-B6BA-BD0E7FCC7155}\gpt.ini>, error = 0x2.

USERENV(160.c0) 14:26:31:248 ProcessGPO:  ==============================

USERENV(160.c0) 14:26:31:248 EvalList:  ProcessGPO failed

USERENV(160.c0) 14:26:31:248 GetGPOInfo:  EvaluateDeferredGPOs failed. Exiting

USERENV(160.c0) 14:26:31:258 GetGPOInfo:  Leaving with 0

USERENV(160.c0) 14:26:31:258 GetGPOInfo:  ********************************

The issue in this case was because I specifically denied access to my user account and they were not able to read the file gpt.ini for the {2C1B…} GPO.  Granting access to that GPT resulted in correcting the issue.

The next error was a result of a version number missing from GPT.ini.  Remember that the Winlogon process compares the version of GPT with the version of GPC.  It does this by checking the version number in the file GPT.ini and comparing with the version of the same GPO within Active Directory.  Here is the snippet:

USERENV(160.254) 14:19:35:340 ProcessGPO:  Searching <cn={2C1B39B1-02EC-41B9-B6BA-BD0E7FCC7155},cn=policies,cn=system,DC=contoso,DC=com>

USERENV(160.254) 14:19:35:340 ProcessGPO:  User has access to this GPO.

USERENV(160.254) 14:19:35:340 ProcessGPO:  GPO passes the filter check.

USERENV(160.254) 14:19:35:340 ProcessGPO:  Found functionality version of:  2

USERENV(160.254) 14:19:35:340 ProcessGPO:  Found file system path of:  <\\contoso.com\SysVol\contoso.com\Policies\{2C1B39B1-02EC-41B9-B6BA-BD0E7FCC7155}>

USERENV(1cc.3fc) 14:19:35:350 GetProfileType:  Profile already loaded.

USERENV(1cc.3fc) 14:19:35:350 GetProfileType: ProfileFlags is 0

USERENV(160.254) 14:19:35:360 ProcessGPO:  Found common name of:  <{2C1B39B1-02EC-41B9-B6BA-BD0E7FCC7155}>

USERENV(160.254) 14:19:35:360 ProcessGPO:  Found display name of:  <All Company Users>

USERENV(160.254) 14:19:35:360 ProcessGPO:  Found user version of:  GPC is 3, GPT is 0

USERENV(160.254) 14:19:35:360 ProcessGPO:  Found flags of:  0

USERENV(160.254) 14:19:35:360 ProcessGPO:  Found extensions:  [{35378EAC-683F-11D2-A89A-00C04FBBCFA2}{0F6B957E-509E-11D1-A7CC-0000F87571E3}]

USERENV(160.254) 14:19:35:360 ProcessGPO:  ==============================

Here is a version mismatch:

USERENV(160.48c) 14:18:04:189 ProcessGPO:  Searching <cn={2C1B39B1-02EC-41B9-B6BA-BD0E7FCC7155},cn=policies,cn=system,DC=contoso,DC=com>

USERENV(160.48c) 14:18:04:189 ProcessGPO:  User has access to this GPO.

USERENV(160.48c) 14:18:04:189 ProcessGPO:  GPO passes the filter check.

USERENV(160.48c) 14:18:04:189 ProcessGPO:  Found functionality version of:  2

USERENV(160.48c) 14:18:04:189 ProcessGPO:  Found file system path of:  <\\contoso.com\SysVol\contoso.com\Policies\{2C1B39B1-02EC-41B9-B6BA-BD0E7FCC7155}>

USERENV(160.48c) 14:18:04:209 ProcessGPO:  Found common name of:  <{2C1B39B1-02EC-41B9-B6BA-BD0E7FCC7155}>

USERENV(160.48c) 14:18:04:209 ProcessGPO:  Found display name of:  <All Company Users>

USERENV(160.48c) 14:18:04:209 ProcessGPO:  Found user version of:  GPC is 3, GPT is 3000

USERENV(160.48c) 14:18:04:209 ProcessGPO:  Found flags of:  0

USERENV(160.48c) 14:18:04:209 ProcessGPO:  Found extensions:  [{35378EAC-683F-11D2-A89A-00C04FBBCFA2}{0F6B957E-509E-11D1-A7CC-0000F87571E3}]

USERENV(160.48c) 14:18:04:209 ProcessGPO:  ==============================

Here is an issue in which the user does not have the ability to apply Group Policy:

USERENV(160.d8) 14:24:06:200 ProcessGPO:  ==============================

USERENV(160.d8) 14:24:06:200 ProcessGPO:  ==============================

USERENV(160.d8) 14:24:06:200 ProcessGPO:  Searching <cn={2C1B39B1-02EC-41B9-B6BA-BD0E7FCC7155},cn=policies,cn=system,DC=contoso,DC=com>

USERENV(160.d8) 14:24:06:200 ProcessGPO:  User does not have access to the GPO and so will not be applied.

USERENV(160.d8) 14:24:06:200 ProcessGPO:  Found functionality version of:  2

USERENV(160.d8) 14:24:06:200 ProcessGPO:  Found file system path of:  <\\contoso.com\SysVol\contoso.com\Policies\{2C1B39B1-02EC-41B9-B6BA-BD0E7FCC7155}>

USERENV(160.d8) 14:24:06:200 ProcessGPO:  Sysvol access skipped because GPO is not getting applied.

USERENV(160.d8) 14:24:06:200 ProcessGPO:  Found common name of:  <{2C1B39B1-02EC-41B9-B6BA-BD0E7FCC7155}>

USERENV(160.d8) 14:24:06:200 ProcessGPO:  Found display name of:  <All Company Users>

USERENV(160.d8) 14:24:06:200 ProcessGPO:  Found user version of:  GPC is 3, GPT is 65535

USERENV(160.d8) 14:24:06:200 ProcessGPO:  Found flags of:  0

USERENV(160.d8) 14:24:06:200 ProcessGPO:  Found extensions:  [{35378EAC-683F-11D2-A89A-00C04FBBCFA2}{0F6B957E-509E-11D1-A7CC-0000F87571E3}]

USERENV(160.d8) 14:24:06:200 ProcessGPO:  ==============================

So now that we’ve discussed how GPO processing is supposed to occur and some of the issue that we see in UserEnv, let’s look at how a UserEnv log looks when a user falls out of scope of applying the GPO:

First pass of GPO:

USERENV(168.9c) 15:19:36:783 ProcessGPOs: Processing extension Folder Redirection

USERENV(168.9c) 15:19:36:783 ReadStatus: Read Extension's Previous status successfully.

USERENV(168.9c) 15:19:36:783 CheckForGPOsToRemove: GPO <Remote Users> needs to be removed

USERENV(168.9c) 15:19:36:783 CheckForGPOsToRemove: GPO <Remote Users> needs to be removed

We know we need to remove the Folder Redirection at this point……

USERENV(168.9c) 15:19:36:783 GetDeletedGPOList: Finished.

USERENV(168.9c) 15:19:36:783 GetDeletedGPOList: Finished.

USERENV(168.9c) 15:19:36:783 ProcessGPOList: Entering for extension Folder Redirection

USERENV(168.9c) 15:19:36:783 UserPolicyCallback: Setting status UI to Applying Folder Redirection policy...

USERENV(168.9c) 15:19:36:783 UserPolicyCallback: Extension requested status UI when status UI is not available.

USERENV(168.9c) 15:19:36:793 LogExtSessionStatus: Successfully logged Extension Session data

USERENV(168.9c) 15:19:36:843 UserPolicyCallback: Setting status UI to Applying your personal settings...

USERENV(168.9c) 15:19:36:843 UserPolicyCallback: Extension requested status UI when status UI is not available.

USERENV(168.9c) 15:19:36:843 ProcessGPOList: Extension Folder Redirection returned 0x4fa.

USERENV(168.9c) 15:19:36:843 ProcessGPOList: Extension Folder Redirection was able to log data. RsopStatus = 0x0, dwRet = 1274, Clearing the dirty bit

Can’t redirect the Folder Redirection back to the original location when we’re already logged in and, therefore, we see this:

USERENV(168.9c) 15:19:36:843 ProcessGPOs: Extension Folder Redirection ProcessGroupPolicy returned sync_foreground.

USERENV(168.9c) 15:19:36:843 ProcessGPOs: -----------------------

USERENV(168.9c) 15:19:36:843 ProcessGPOs: -----------------------

Second Pass of GPO run in Synchronous mode:

USERENV(168.3a4) 15:21:59:772 ProcessGPOs: Processing extension Folder Redirection

USERENV(168.3a4) 15:21:59:772 ReadStatus: Read Extension's Previous status successfully.

USERENV(168.3a4) 15:21:59:772 CheckForGPOsToRemove: GPO <Remote Users> needs to be removed

USERENV(168.3a4) 15:21:59:772 CheckForGPOsToRemove: GPO <Remote Users> needs to be removed

USERENV(168.3a4) 15:21:59:772 GetDeletedGPOList: Finished.

USERENV(168.3a4) 15:21:59:772 GetDeletedGPOList: Finished.

USERENV(168.3a4) 15:21:59:772 ProcessGPOList: Entering for extension Folder Redirection

USERENV(168.3a4) 15:21:59:772 UserPolicyCallback: Setting status UI to Applying Folder Redirection policy...

USERENV(168.3a4) 15:21:59:782 LogExtSessionStatus: Successfully logged Extension Session data

USERENV(168.3a4) 15:21:59:852 UserPolicyCallback: Setting status UI to Applying personal document settings...

USERENV(168.3a4) 15:22:10:907 UserPolicyCallback: Setting status UI to Applying personal document settings...

USERENV(168.3a4) 15:22:11:017 UserPolicyCallback: Setting status UI to Applying personal document settings...

USERENV(168.3a4) 15:22:22:161 UserPolicyCallback: Setting status UI to Applying your personal settings...

USERENV(168.3a4) 15:22:22:161 ProcessGPOList: Extension Folder Redirection returned 0x0.

USERENV(168.3a4) 15:22:22:161 ProcessGPOList: Extension Folder Redirection was able to log data. RsopStatus = 0x0, dwRet = 0, Clearing the dirty bit

USERENV(168.3a4) 15:22:22:171 ProcessGPOs: -----------------------

Hoping this helps with interpreting UserEnv debug logs and with GPO troubleshooting!  Here is a support article that also discusses how to interpret UserEnv logs:

Interpreting Userenv log files
https://technet.microsoft.com/en-us/library/cc786775(WS.10).aspx

 

Updated:  After posting this blog and then looking for the support article from Technet about how to interpret UserEnv log files, I found two other Blogs about interpreting UserEnv.  These are very good blogs.

Understanding How to Read a Userenv Log – Part 1
https://blogs.technet.com/askds/archive/2008/11/11/understanding-how-to-read-a-userenv-log-part-1.aspx

Understanding How to Read a Userenv Log – Part 2
https://blogs.technet.com/askds/archive/2008/11/11/understanding-how-to-read-a-userenv-log-part-2.aspx

]]> How to Consolidate Many Reverse DNS Zones into Fewer Larger Reverse DNS Zones https://docs.microsoft.com/archive/blogs/richpec/how-to-consolidate-many-reverse-dns-zones-into-fewer-larger-reverse-dns-zones Sat, 23 Aug 2008 19:38:00 GMT https://blogs.msdn.microsoft.com/richpec/2008/08/23/how-to-consolidate-many-reverse-dns-zones-into-fewer-larger-reverse-dns-zones/ I just finished a large project consolidating hundreds of 16 bit and 24 bit Reverse DNS zones into a larger global 8 bit Reverse DNS Zone and configuring that zone to be an Active Directory Integrated (ADI) DNS Zone in the ForestDNSZones partition (replicated to all DNS Servers that are also domain controllers in the forest).  This article walks through the process of consolidation and all DNS Server names, IP Addresses, and domains are fictitious to ensure customer confidentiality.

The scenario:

The customer had tens of thousands of DNS nodes and about 250 Reverse DNS Zones.  None of the Reverse DNS Zones were replicated at all and the DNS infrastructure was configured as Standard Primary Zones and then Secondary Zones on other DNS Servers.  This resulted in an administrative nightmare and single points of failure on all Reverse DNS Zones.  Furthermore, since the Reverse DNS Zones were not ADI zones, the customer was unable to configure the zones to allow only secure dynamic updates and, therefore all clients could hijack and register DNS node PTR records even if they were not joined to the domain.  My laptop could even register PTR records in DNS.  It was necessary to mitigate this risk and, therefore, the project called for a mass consolidation and migration to ADI zones.

Roughly 40 DNS Servers exist in the enterprise which consists of 6 separate domains within the same forest.  Half of the DNS Servers were not domain controllers and, therefore, cannot host ADI zones.  Each domain had specific subnets assigned to it and there were some overlapping subnets to take into consideration.  For the sake of simplicity in this article, let's give the domain controllers, DNS Servers, and Reverse DNS Zones fictitious names:

(Note:  Many domain controllers, DNS Servers, and Reverse DNS Zones have been excluded from this article to save time.  The configuration of other domains, other Reverse DNS Zones, domain controller names, and DNS Server names were the same and the process of the consolidation is the same process for all domains and Reverse DNS Zones.)


Domain Controllers with DNS:

Oregon Domain Controllers:

ORDCDNS1, ORDCDNS2, ORDCDNS3

Washington Domain Controllers:

WADCDNS1, WADCDNS2, WADCDNS3

California Domain Controllers:

CADCDNS1, CADCDNS2, CDDCDNS3

Nevada Domain Controllers:

NVDCDNS1, NVDCDNS2, NVDCDNS3

Idaho Domain Controllers:

IDDCDNS1, IDDCDNS2, IDDCDNS3


DNS Servers that are not domain controllers:

Oregon DNS Servers:

ORDNS1, ORDNS2, ORDNS3

Washington DNS Servers:

WADNS1, WADNS2, WADNS3

California DNS Servers:

CADNS1, CADNS2, CADNS3

Nevada DNS Servers:

NVDNS1, NVDNS2, NVDNS3

Idaho DNS Servers:

IDDNS1, IDDNS2, IDDNS3


Some examples of the fictitious Reverse DNS Zones:

Oregon Reverse DNS Zones:

10.in-addr.arpa (10.x.x.x Subnet)
1.10.in-addr.arpa (10.1.x.x Subnet)
2.10.in-addr.arpa (10.2.x.x Subnet)
15.1.10.in-addr.arpa (10.1.15.x Subnet)
16.1.10.in-addr.arpa (10.1.16.x Subnet)
17.1.10.in-addr.arpa (10.1.17.x Subnet)

About 100 other Reverse DNS Zones have been excluded to save time.

ORDNS1 was configured with all Reverse DNS Zones as the Standard Primary and ORDNS2, ORDNS3 as well as some of the domain controllers were all loading these Reverse DNS Zones as secondary zones and transferring the zone data from ORDNS1.  Furthermore, DNS Servers and some domain controllers in all other domains were also loading these zones as Secondary Zones and transferring from ORDNS1.


Washington Reverse DNS Zones:

5.1.10.in-addr.arpa (10.1.5.x Subnet)
6.1.10.in-addr.arpa (10.1.6.x Subnet)
5.2.10.in-addr.arpa (10.2.5.x Subnet)
6.2.10.in-addr.arpa (10.2.6.x Subnet)
18.1.10.in-addr.arpa (10.1.18.x Subnet)
19.1.10.in-addr.arpa (10.1.19.x Subnet)

About 100 other Reverse DNS Zones have been excluded to save time.

WADNS1 was configured with all Reverse DNS Zones as the Standard Primary and WADNS2, WADNS3 as well as some of the domain controllers were all loading these Reverse DNS Zones as secondary zones and transferring the zone data from WADNS1.  Furthermore, DNS Servers and some domain controllers in all other domains were also loading these zones as Secondary Zones and transferring from WADNS1.


California, Idaho, Nevada, and Utah were all configured with Reverse DNS zones mimicing the overlap in subnets.  We'll stop here and get to the process.


Step 1:  Configuring a "Big 10" Reverse DNS zone as an ADI (Active Directory Integrated) DNS Zone and Replicating to all DNS Servers in the Forest

The current 10.in-addr.arpa zone on ORDNS1 was converted to an Active Directory Integrated DNS Zone by selecting the option to Store the zone in Active Directory (available only if DNS Server is a domain controller).  Then, the replication scope was configured to replicate To all DNS Servers in the Active Directory forest contoso.com.  This allowed the 10.in-addr.arpa (10.x.x.x Subnet) to replicate to all DNS Servers that were domain controllers in the forest.  Any DNS Server in the forest that was not a domain controller was not able to load this ADI zone and, therefore, secondary zones were created on all DNS Servers that are not domain controllers.  Clients in all sites within all domains are configured to point their DNS settings in TCP/IP Properties to use the DNS Server in their own site and as we consolidate to one big 10.in-addr.arpa zone we would need this 10.in-addr.arpa zone populated on all DNS Servers.

So now all DNS Servers have the big 10.in-addr.arpa zone loaded as either an Active Directory Integrated DNS Zone or a Secondary Zone transferring from a couple of DNS Servers that are domain controllers.

(Note:  For the transfer to be successful, we had to allow zone transfers by editing the Zone Transfer setting on the 10.in-addr.arpa zone.)


Step 2:  Consolidation

As you saw in the Reverse DNS Zones configuration of these DNS Servers, these DNS Servers load multiple zones that are not only 16 bit but also 24 bit on the same server. 

An example of what I am talking about would be:

10.in-addr.arpa
1.10.in-addr.arpa
2.10.in-addr.arpa
3.10.in-addr.arpa
15.3.10.in-addr.arpa

etc....

Because these zones exist on the same server, DNS creates an automatic delegation in the parent zone that delegates the child zone back to itself.  Looking in the 10.in-addr.arpa Reverse DNS Zone, you see many child domains such as 1, 2, 3, 4, 5, etc.  Because the DNS Server loads these other child zones, the 1, 2, and 3 child domain zones have an icon different from the other non-delegated zones. The delegation is a greyed folder and the non-delegated have the original yellow colored folder as the icon.

The process to consolidate more detailed Reverse Zones into a larger 10.in-addr.arpa zone requires zone exports, manipulating the data and then importing into the big 10.in-addr.arpa zone.  The import will be unsuccessful if a delegation still exists and, therefore the delegated zone must be deleted just before the import.


The Tool:  DNSExporter (obtainable from Microsoft Support under the toolbox search phrase of "DNS Record Export")

DNSExporter allows zone enumeration in tab delimited format and provides information about the record owner, whether or not the record is dynamic or static and whether or not the record is stale.  It is quite useful in environments where aging is turned on for specific zones but scavenging has not been set on any servers.  This tool will export the zones and provide a list of all records that would be scavenged if it were enabled on the server.  However, I used it for zone export and import only.

The Process:

Open DNS Exporter (shown in Figure 1)

Figure 1

 

In the DNS Server Name field, type the name of the DNS Server that contains the Primary zone to be exported.  The File Name field defaults to c:\DNS_ZONE_EXPORT.txt but I found it useful for backup purposes to change the export file to the name of the reverse zone.

The Export Restrictions field is blank by default but must be populated with the name of the zone you want to export.  In my example of exporting the 226.10.in-addr.arpa zone, the Export Restrictions field should read where ContainerName="226.10.in-addr.arpa".

The Record Type drop down should be changed to MicrosoftDNS_PTRType.

Providing the user account being used to export the zone information is an administrator of the DNS Server, no credentials are necessary.

Click on Export and you will see the Records Processed field start to export records.

The exported data text file will contain tab delimited results.  Open the exported text file using Microsoft Excel.  The information will looks something like:

Record Type                                ContainerName            DnsServerName                      DomainName                 OwnerName                  

MicrosoftDNS_PTRType               226.10.in-addr.arpa      ordns1.or.contoso.com            226.10.in-addr.arpa         240.12.226.10.in-addr.arpa

MicrosoftDNS_PTRType               226.10.in-addr.arpa      ordns1.or.contoso.com            226.10.in-addr.arpa         4.12.226.10.in-addr.arpa             

MicrosoftDNS_PTRType               226.10.in-addr.arpa      ordns1.or.contoso.com            226.10.in-addr.arpa         44.12.226.10.in-addr.arpa          

MicrosoftDNS_PTRType               226.10.in-addr.arpa      ordns1.or.contoso.com            226.10.in-addr.arpa         20.20.226.10.in-addr.arpa          

MicrosoftDNS_PTRType               226.10.in-addr.arpa      ordns1.or.contoso.com            226.10.in-addr.arpa         254.20.226.10.in-addr.arpa       

MicrosoftDNS_PTRType               226.10.in-addr.arpa      ordns1.or.contoso.com            226.10.in-addr.arpa         254.20.226.10.in-addr.arpa       

MicrosoftDNS_PTRType               226.10.in-addr.arpa      ordns1.or.contoso.com            226.10.in-addr.arpa         4.20.226.10.in-addr.arpa

There are more columns to the right but they have been snipped to show only the relevant columns that need to be manipulated.  Do not remove the extra columns as they are still needed for the import.

In order to import these records into the "Big 10" Reverse DNS Zone, the ContainerName and the DomainName columns have to be manipulated to import into the correct zone.  The columns for ContainerName and DomainName should be column B and column D respectively.  Change cell B2 and D2 to read 10.in-addr.arpa and then drag replace within Excel all the way down the entire column list of records to overwrite with the new 10.in-addr.arpa values.

Save this tab delimited text file as <something>-import.txt.  You will be prompted with an informational warning that the file may contain features that are not compatible with Text (Tab delimited).  Click Yes to allow this.

Now using DNS Exporter, change the DNS Server Name field to the name of a domain controller containing the 10.in-addr.arpa Reverse DNS Zone.  Also change the File Name to the text file you just saved in the last step.

Before you click on Import, check the 10.in-addr.arpa Reverse DNS Zone to ensure that there is not currently a delegation for the 226 child zone.  If there is, it must be deleted prior to importing.  Then click Import.  The Records Processed data will begin to process the importation of the records.

Now, the Primary Zone 226.10.in-addr.arpa can be deleted on ORDNS1 as well as the Secondary Zones that exist on other DNS Servers. Follow the same steps for all 16 bit and 24 bit Reverse DNS Zones in order to import into the "Big 10" Reverse Zone.

While onsite with my customer, I also built a batch file that would do dnscmd queriy commands against the import server to ensure that these records were in fact imported.  In order to build the script, I had to build a records.txt text file that had the PTR records to look for.  To get this text file I used my DNS Export output file.  There is a column in the output called OwnerName (included above) that contains the PTR information.  I copied that entire column to Notepad and did a Replace all.  I replaced .10.in-addr.arpa with nothing and saved that file as records.txt.  Then the batch file was built and looked like this:

@echo off
for /f "tokens=1" %%i IN (records.txt) DO dnscmd.exe ordc1 /enumrecords 10.in-addr.arpa %%i >> recordresults.txt

After that was run, I searched through recordresults.txt and searched for the word failed.  If a record was not found in the query, the output would be similar to:

DNS Server failed to enumerate records for node 4.225.1.10.in-addr.arpa.

I also built a batch file to use dnscmd to delete the secondary zones on all DNS Servers.

The script used to remove all secondary zones needs a file called servers.txt populated with all DNS Servers.  The script looked like this and had to be edited for every zone that was to be deleted:

@echo off
FOR /F "tokens=1" %%i IN (SERVERS.TXT) DO dnscmd %%i /ZoneDelete 226.10.in-addr.arpa /f

The same process was repeated for all Reverse DNS Zones.  Hope this helps!

 

UPDATED!

Ashley McGlone has written a PowerShell script to perform similar functions. His Blog is located here....

https://blogs.technet.com/b/ashleymcglone/archive/2010/09/02/powershell-script-to-combine-dns-zones.aspx

 

]]> Web Application Needing to Validate Users From Different Domains https://docs.microsoft.com/archive/blogs/richpec/web-application-needing-to-validate-users-from-different-domains Fri, 22 Aug 2008 22:29:00 GMT https://blogs.msdn.microsoft.com/richpec/2008/08/22/web-application-needing-to-validate-users-from-different-domains/ A company I had done some work for has a process that they go through for their custom application.  This application must authenticate the user so it can do pass-through authentication.  Their process grabs the sAMAccountName attribute from the user object.  contoso.com\richpec would, of course, have the sAMAccountName of richpec.  Then they use the REMOTE_USER parameter through Integrated Windows Authentication and pass that to the web application as contoso.com\richpec.  They have a custom policy that then rips off the NetBIOS name of the domain and matches sAMAccountName to the stripped REMOTE_USER and richpec then matches richpec and they are authenticated.
 
They acquired companies and all of the sudden had more than one domain and needed to find a way to make it work.  Thus I was asked to help them find a solution and single sign-on solutions were not in the budget.  So here's what I did.
 
I created a custom attribute within the Schema in Active Directory of my test network.  I named the attribute authenticatingUsername.  Here are the values I gave it:
 
Attribute Name = authenticatingUsername
Description  =  Authenticating-Username
Common Name  =  Authenticating-Username
X.500 OID  =  1.2.840.113556.1.4.555  (more on this in a second)
Syntax  =  Unicode String
Minimum  =  0
Maximum  =  256
Attribute is active  =  Checked
Index this attribute in Active Directory  =  Checked
Ambiguous Name Resolution  =  Checked
Replicate this attribute to GC  =  Checked
 
About the X.500 OID...  In order to create an attribute in the Active Directory Schema a X.500 OID must be defined.  The OID (Object Identifier) is used to ensure that no two objects have the same Identification and, therefore, genuine and original throughout the enterprise.  The OID for sAMAccount name is 1.2.840.113556.1.4.221.  I did a search through my Active Directory Schema for 1.2.840.113556.1.4.anything and found that 1.2.840.113556.1.4.555 didn't exist as an OID.  I then searched that OID on the Internet and found absolutely nothing so I figured I could use it for testing purposes.

(Note:  In a production environment, DO NOT randomly create your own OID.  The OID must be unique and guaranteed that no other schema extension will try to create an object with that ID.  Therefore, you must obtain a custom OID from the Internet Assigned Numbers Authority (IANA www.iana.org) so that you are guaranteed to never have conflicting objects in the Active Directory Schema that other applications needing to extend the Schema are attempting to create with the same OID.  Well, guaranteed as long as other 3rd party application development companies follow RFCs and register object classes with IANA.  Too often have we seen support cases where customers attempting to extend the schema using ADPREP /Forestprep fail because 3rd party applications wrote schema extensions and when we create our attributes for schema extension, and registered them to be unique, they conflict with objects in Active Directory and the Schema update fails.)

The Internet Assigned Numbers Authority (IANA) assigns private enterprise numbers, which are OIDs, in the arc 1.3.6.1.4.1. IANA will assign a number (NEWNUM) so that the new OID arc will be 1.3.6.1.4.1.NEWNUM. These numbers can be obtained from the IANA Web site (www.iana.org).

More information about Object Identifiers can be found here:
https://en.wikipedia.org/wiki/Object_identifier

I then reloaded the Schema and went into the classes container of the Schema and modified the properties of the user class.  I added authenticatingUsername as an attribute of the user class.  This is done to enable the ability for a user object to be populated with an attribute called authenticatingUsername.  I reloaded the Schema again.

Now I needed to populate all user accounts with their respective authenticatingUsername attribute.  I used ADModify.net and did a modification of a custom attribute to all user accounts.  There is a tab for Custom where you can define the name of the custom attribute to change and what value to give it.  I told it to change authenticatingUsername and give it a value of myfirstdomain\'%sAMAccountName%' and then did it to the second domain also as myseconddomain\'%sAMAccountName%' and so on and so forth.
 
Then, the process was to change the query to grab the authenticatingUsername attribute instead of sAMAccountName.

]]>