Thursday, November 1, 2007

Defragging Active Directory .DIT Database



What are the reasons, why we would ever need to defrag .DIT database. In my case the DC (domain Controller) going out of space on C drive, and there is a little space letf on the other available drive.The other important reason in this case, the DC having big replication issues , and .DIT database seems to be reached 6GIG in size, Although , other DC's have .DIT database size in 2GIG.If you remember I have mentioned many times in my previous articles about , .DIT database, Which is partitioned database. How does Exchange related to .DIT database. Exchange Utilizes all partitions in the .DIT database. The partitions in the .DIT database follows as below.

  • Domain
  • Configuration
  • Schema
  • Application ( .DIT 2003 Only)

In my example the DC , which is having heavy replication problems need defragmetation on the .DIT database. You may ask yourself why .DIT database reached 6GIG ( the actual size o fthe .DIT database is less than 1GIG) on this Domain Controller.

Lets take a look a little closer the reasons. DLT objects (Distributed Link Tracking) in active directory.

  • Distributed Link Tracking is a service that was introduced in Windows 2000 and is now also available in Windows XP and .NET servers (including the most recent post beta-3 release). The service was intended to resolve problems with outdated shortcuts. These problems applied to both shell shortcuts (such as ones located in Desktop, Favorites, Start Menu, and Recent folders) as well as OLE application links (such as an Excel spreadsheet stored within a Word document)
  • Dltpurge.vbs (Q315229)
  • You can use the Distributed Link Tracking Server service and the Distributed Link Tracking Client service to track links to files on NTFS-formatted partitions. Distributed Link Tracking tracks links in scenarios where the link is made to a file on an NTFS volume, such as shell shortcuts and OLE links. If that file is renamed, moved to another volume on the same computer, moved to another computer, or moved in other similar scenarios, Windows uses Distributed Link Tracking to find the file. When you access a link that has moved, Distributed Link Tracking locates the link; you are unaware that the file has moved, or that Distributed Link Tracking is used to find the moved file.
  • Distributed Link Tracking consists of a client service and a server service. The Distributed Link Tracking Server service runs exclusively on Windows Server-based domain controllers. It stores information in Active Directory, and it provides services to help the Distributed Link Tracking Client service. The Distributed Link Tracking Client service runs on all Windows 2000-based and Microsoft Windows XP-based computers, including those in workgroup environments or those that are not in a workgroup. It provides the sole interaction with Distributed Link Tracking servers.

    Distributed Link Tracking clients occasionally provide the Distributed Link Tracking Server service with information about file links, which the Distributed Link Tracking Server service stores in Active Directory. Distributed Link Tracking clients also may query the Distributed Link Tracking Server service for that information when a shell shortcut or an OLE link cannot be resolved. Distributed Link Tracking clients prompt the Distributed Link Tracking server to update links every 30 days. The Distributed Link Tracking Server service scavenges objects that have not been updated in 90 days

    When a file that is referenced by a link is moved to another volume (on the same computer or on a different computer), the Distributed Link Tracking client notifies the Distributed Link Tracking server, which creates a linkTrackOMTEntry object in Active Directory. A linkTrackVolEntry object is created in Active Directory for every NTFS volume in the domain.

What Microsoft recommends for the DLT in windows 2000 based servers

  • Turn off the Distributed Link Tracking Server service on all domain controllers (this is the default configuration on all Windows Server 2003-based servers).


Notes:

  • The Directory Information Tree (DIT) size on domain controllers is not reduced until the following actions are completed
  • Deleted objects are stored in the Deleted Objects container until the tombstone lifetime expires. The default value for a tombstone lifetime is 60 days, the minimum value is 2 days, and the minimum value that is recommended by Microsoft for production domains is 30 to 45 days
  • Garbage collection has run to completion
  • You use Ntdsutil.exe to defragment the Ntds.dit file in Dsrepair mode

How to defrag The Directory Information Tree (DIT) database.

Before , I get to this you must read following articles

A sample customer experience , it is so unbelivable the place I work currenlty is 4 times worst than , what Microsoft talks about in the article. Seriousily thre DL object in one domain exides 379.000 DLT object in my case.

Anatomy of DLT object deletion

DLT objects themselves contain very few attributes and use very little space in Active Directory. When an object is marked for deletion (tombstoned), all the unnecessary attributes are stripped away, except for those necessary to track the object until it is purged from Active Directory.

In the case of the link-tracking objects, marking the object for deletion only amounts to two attributes being removed: dscorepropagationdata and objectcategory. The deletion of the two attributes results in an initial savings of 34 bytes. However, the process of marking the link-tracking object for deletion also updates the object by adding an IS_DELETED attribute (4 bytes), and by mangling the RDN and the "common name" attributes, causing each of those attributes to grow by about 80 bytes. In addition, the "replication metadata" attribute also grows by about 50 bytes to reflect the updates performed on this object. So, by marking a link-tracking object for deletion, the object will end up growing by approximately 200 bytes. The NTDS.DIT will not exhibit a reduction in size until the deleted objects have tombstoned, been garbage collected and an offline defragmentation performed.

Steps

  1. Rebot the server , Press F8 and select Directory Services Restore Mode option.
  2. Use Administrator account to get in to Directory services restore mode.
  3. This is special mode, the .DIT database if isolated from multi master replication model theory
  4. Go to Command line, any type
  5. NTDSUTIL ( enter)
  6. Files
  7. File maintanace: compact to c:\temp (Enter)
  8. Watch the bar similar Exchange Defragmentation process
  9. copy c:\temp\ntds.dit %systemroot%\ntds\ntds.dit ( you woulod think window would do it autimaticly , just like in exchange, but you have to perform this manually
  10. restart the Domain Controller

Regards,

Oz ozugurlu

3 comments:

Rasheedickinson said...

In addressing heavy replication issues in the Domain Controller due to the overloaded .DIT database (6GB vs. 1GB), it's crucial to understand the role of Distributed Link Tracking. This service, essential since Windows 2000, helps maintain access to files through shortcuts and links. Just like dodging notes in friday night funkin , effective defragmentation and diligent tracking prevent errors.

Percy Rempel said...

Defragging the .DIT database can help with space issues and replication problems, especially when the database grows unexpectedly large due to services like Distributed Link Tracking. It’s crucial to understand its impact on Active Directory performance. Retro bowl

Barbara M. Luna said...

Check out the latest updates on M365 and AZURE Blog! Discover insights, tips, and news on cloud computing and productivity tools. Plus, take a break with slope unblocked for some thrilling downhill action!