Windows Server


Some Important ADSIEDIT Active Directory Partition Paths to know about    



Some Important ADSIEDIT Active Directory Partition Paths to know about


Some Important ADSIEDIT Active Directory Partition Paths to know about


Lost & Found Container


Objects, whose parent OU's are missing (deleted) are moved into Lost & Found Container inside Active Directory.





Lost and found objects


On a domain controller, the Lost and Found container contains Active Directory objects that have been orphaned. An object is orphaned when the object is created on one domain controller and the container in which the object is placed is deleted from the directory on another domain controller before the object has a chance to replicate. An orphaned object is automatically placed in the Lost and Found container where it can be found by an administrator, who must determine whether to move or delete the object.


The lostAndFound container is where objects that are orphaned during Active Directory database replication are placed. It is also where you find objects that have been moved to a new location that is missing after the server has replicated.


The LostAndFound container:

When you enable Advanced Features from Active Directory Users and Computers from the View menu the LostAndFound leaf appears among other menu items that are not displayed by default such as the NTDS Quotas, Program Data, and the System container.


The lostAndFound container is the place to locate orphaned objects such as orphaned user accounts.


You can delete all objects under lost&found from the configuration container.


The steps are as follows:


Open the ADSI Edit MMC snap-in.


1.      On the Action menu, click Connect to.

2.      In the Connection Settings dialog box, in the Name field, enter a name for the ADSI connection. Under Connection Point, select Select a well known Naming Context, and then select Configuration in the drop-down menu. Click OK.

3.      In the left pane, double-click the Configuration object, and then double-click LostAndFoundConfig.

4.      In the right pane, delete all objects and containers. Right-click the object or container, click Delete, and then click Yes.

5.      Exit ADSI Edit.


Please note that this operation if performed wrong can render your environment unusable.


LostAndFoundConfig container provides storage for global configuration objects (in forest configuration partition) that are being created in containers that are simultaneously being deleted elsewhere on the network.


LostAndFound container (in directory partition of each domain) serves the same purpose for domain-specific objects.


For those objects that is no longer necessary you can safely delete them in both two containers.


For more information about the occurrence of replication conflict in Active Directory, you may refer to:


A Guide to Active Directory Replication





To prevent Duplicated Objects with the same name, Active Directory Renames one of these Objects as a CNF Object. The System Administrators can then manually determine which one to keep and which one to remove.


The duplicate object is renamed as Object-Name.CNF


For example if there are two Domain Controllers in the Domain, DC A and DC B, and then you create a user object called “Rohit” on each DC at the same time. Then the Active Directory finds this as a conflict and fiunally inside Active Directory you will have two objects :






    A                                B

   DC                              DC




name = Rohit             name = Rohit


-                                    -

-                                    -

-                                    -



Replicate → [ 2 objects: Rohit, Rohit.CNF ]



Conflict Resolution:


1) Versions> [Higher ver. signify changed passwords]

2) Time. (Last writer wins)

3) Server GUID (Higher) Imp.

For Conflict resolution, the Active Directory (more accurately, the PDC) uses the above three attribute values as criteria to determine the conflict winner.



The version associated with the object inside Active Directory.



The Time stamp value for when the Object was created inside Active Directory.


Server GUID

The GUID of the Server on which that object was created (origination write) is also taken into account when deciding the conflict winner. The Higher the Server GUID represents the winner.




• If two (user) objects with same username are created at two DC's at the same time, then

• in Conflict Resolution the Dc with higher GUID will win & the other would be renamed to <obj>.CNF {<objectname>.CNF}


When a conflict occurs, instead of using timestamps as the primary mechanism to determine what updates are preserved, Active Directory uses volatility (number of changes) as the first element of the per-attribute stamps that are compared during conflict resolution. The second element is a timestamp. Therefore, if an attribute is updated once on domain controller A and once on domain controller B, the last writer’s update is preserved. But if the attribute is updated on domain controller A, then on domain controller B, and then again on domain controller A, the update of domain controller A is preserved even if the clock of domain controller B is set forward from that of domain controller A. With Active Directory, clock skew can never prevent a value from being overwritten.


For further help on Conflict Resolution, refer the following article: How the Active Directory Replication Model Works, an excerpt from which is taken below:


Multimaster Conflict Resolution Policy


Active Directory must ensure that all domain controllers agree on the value of the updated attribute after replication occurs. The general approach to resolving conflicts is to order all update operations (Add, Modify, Move, and Delete) by assigning a globally unique (per-object and per-attribute) stamp to the originating update. Thus each replicated attribute value (or multivalue) is stamped during the originating update and this stamp is replicated with the value.


Conflict Resolution Stamp


The stamp that is applied during an originating write has the following three components:

  • The version is a number that is incremented for each originating write. The version of the first originating write is 1. The version of each successive originating write is increased by 1. 
  • The originating time is the time of the originating write, to a one-second resolution, according to the system clock of the domain controller that performed the write.
  • The originating DC is the invocationID of the domain controller that performed the originating write.

When stamps are compared, the version is the most significant, followed by the originating time and then the originating DC. If two stamps have the same version, the originating time almost always breaks the tie. In the extremely rare event that the same attribute is updated on two different domain controllers during the same second, the originating DC breaks the tie in an arbitrary fashion.

Two different originating writes of a specific attribute of a particular object cannot assign the same stamp because each originating write advances the version at a specified originating domain controller. The originating time does not contribute to uniqueness. Replicated writes cannot decrease the version because values with smaller versions lose during conflict resolution. You can see all three components of the stamp in the output of the repadmin /showobjmeta command.


In the case of a conflict, the ordering of stamps allows a consistent resolution, as described in the following table.


Replication Conflict Resolution


Replication Conflict



Attribute value conflict

A Modify operation sets the value of an attribute. Concurrently, at another domain controller, a Modify operation sets the value of the same attribute to a different value.

The attribute value at all domain controllers is the value with the larger version number in its stamp.

Add or Move under deleted parent, Delete non-leaf object

An Add or Move operation makes an object a child of parent object. Concurrently, at another domain controller, a Delete operation deletes the parent object.

At all domain controllers, the parent object is deleted and the child object is a child of the special LostAndFound container in the directory partition. Stamps are not involved in the resolution.

Relative distinguished name conflict

An Add or Move operation names a child object below a parent object. Concurrently, at another domain controller, an Add or Move operation names a different child of the same parent with the same child name, resulting in two child objects with identical relative distinguished name values below the same parent object.

The child object whose naming attribute has the larger version number in its stamp keeps its given name. The child object whose relative distinguished name attribute (for example, CN for most objects, OU for organizational units, DC for domain components) has the smaller version number in its stamp is named by the following convention: At all domain controllers, a system-assigned value that is unique to the conflicting name and cannot conflict with any client-assigned value is assigned to the child object. For example, if the relative distinguished name of a child object was “CN=ABC” before conflict resolution, its relative distinguished name after resolution is “CN=ABC*CNF:< GUID >,” where “*” represents a reserved character, “CNF” is a constant that indicates a conflict resolution, and “< GUID >” represents a printable representation of the objectGUID attribute value.


-- End of excerpt –


Deleted Objects Container

Whenever an Object is deleted from Active Directory, it is moved to the Deleted Object Container.

The Deleted Objects Container is a special container inside Active Directory to hold objects that have been deleted from the database.

When any object is deleted, its “isDeleted” attribute is set to TRUE.


<object> → Delete            →                 moved to Deleted objects container

: Attrib: isDeleted = T/F


For example, if we have the following Object in Active Directory,



After deleting this object,

OU = TEST will change to CN=Deleted Objects





Tombstone Lifetime: →

When an Object is deleted from Active Directory, it is moved to the Deleted Objects Container. The deleted objects are retained in the active Directory for a time period that is called “Tombstone Lifetime” period. This period is defined and stored in an Attribute called as the “Tombstone Lifetime”. More on this object can be found here:


A tombstone is invisible to normal LDAP searches. However, a tombstone is visible to searches that use the special LDAP control 1.2.840.113556.1.4.417.


The tombstone lifetime in an Active Directory forest determines how long a deleted object (called a “tombstone”) is retained in Active Directory Domain Services (AD DS). The tombstone lifetime is determined by the value of the tombstoneLifetime attribute on the Directory Service object in the configuration directory partition.


You can use this procedure to determine the tombstone lifetime for the forest.


Membership in Domain Users, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at Local and Domain Default Groups (http://go.microsoft.com/fwlink/?LinkId=83477).


To determine the tombstone lifetime for the forest using ADSIEdit

1.      Click Start, point to Administrative Tools, and then click ADSI Edit.

2.      In ADSI Edit, right-click ADSI Edit, and then click Connect to.

3.      For Connection Point, click Select a well known Naming Context, and then click Configuration.

4.      If you want to connect to a different domain controller, for Computer, click Select or type a domain or server: (Server | Domain [:port]). Provide the server name or the domain name and Lightweight Directory Access Protocol (LDAP) port (389), and then click OK.

5.      Double-click Configuration, CN=Configuration,DC=ForestRootDomainName, CN=Services, and CN=Windows NT.

6.      Right-click CN=Directory Service, and then click Properties.

7.      In the Attribute column, click tombstoneLifetime.

8.      Note the value in the Value column. If the value is <not set>, the value is 60 days.


To determine the tombstone lifetime for the forest using Dsquery

1.      Open a Command Prompt window. To open a command prompt, click Start, click Run, type cmd, and then press ENTER.

2.      At the command prompt, type the following command, and then press ENTER:

3.      dsquery * "cn=directory service,cn=windows nt,cn=services,cn=configuration,dc=<forestDN>" –scope base –attr tombstonelifetime

Be sure to replace <forestDN> with the actual distinguished name of the forest. For example, if your forest name is corp.proseware.com, type the following, and then press ENTER:

dsquery * "cn=directory service,cn=windows nt,cn=services,cn=configuration,dc=corp,dc=proseware,dc=com" –scope base –attr tombstonelifetime


Referenced Article:

·        Determine the tombstone lifetime for the forest



Garbage Collection (cycle) of Deleted Objects occurs every 12 Hrs.


The Garbage Collection cycle of Active Directory occurs every 12 Hrs. It collects and removes only those Objects who have finished their Tombstone Lifetime.


Forest Functionality level    (Configuration & Schema)

Domain Functionality Level (Domain Partition)


    2k            2k3.SP1                R2

    60                180                    60


The Tombstone Lifetime period for Windows 2000 Server is 60 Days.

The Tombstone Lifetime period for Windows Server 2003 SP1 is 180 Days.

The Tombstone Lifetime period for Windows Server 2003 R2 is 60 Days.


Attrib =

The tombstone lifetime is determined by the value of the tombstoneLifetime attribute on the Directory Service object in the configuration directory partition.


Path for tombstone lifetime is as given in above mentioned steps.




Config > Services > Windows NT > Directory Services


No TrackBacks

TrackBack URL: http://www.skar.us/site/mt-tb.cgi/3164

Leave a comment


Author Bio          ★★★★★

Author Name:         administrator
Author Location:    India
Author Rank:          Writer
Author Status:        
The Green leave stands!!



  • eBooks
  • Games
  • Softwares
  • Tools
  • Tweaks
  • Wallpapers
  • Warez
  • Games
  • Tools
  • Wallpapers
    System Administration
  • dll Center
  • Scripts
  • Tools
  • .extensions database
  • Write-up
  • Download Database
  • Jobs
  • Lists
  • Polls
  • Glossary

01000011 01110010 01100001 01100011 01101011 01111010 01101000 01100001 01100011 01101011