Extensible Storage Engine (ESE) - protege987/Active-Directory-Domain-Services GitHub Wiki

Introduction:

Extensible Storage Engine (ESE) something I came across while reading about naming convention in AD and came across this section:

Special issues for OUs When the OU at the domain root level has the same name as a future child domain, you might experience database problems. Consider a scenario in which you delete an OU named marketing to create a child domain that has the same name. For example, marketing.contoso.com (leftmost label of the child domain FQDN name has the same name).

You delete the OU. During the tombstone lifetime of the deleted OU, you create a child domain that has the same name. Then, you delete the child domain, and then create it a second time. In this scenario, a duplicate record name in the ESE database causes a phantom-phantom name collision when the child domain is re-created. This problem prevents the Active Directory Configuration container from replicating.

What is Extensible Storage Engine (ESE)?

Extensible Storage Engine (ESE) has a mechanism called the version store. For most people this stock store version configuration will be fine but there is always the small % out there with exceptionally large and/or busy Active Directory deployments, (or for those who make “interesting” administrative choices,) the monitoring and tuning of the version store can become a very important topic. Such as the special issues section.

The Extensible Storage Engine (ESE) is a low-level database engine that is used internally by Windows for systems such as Microsoft Exchange message store, Active Directory database, Microsoft Updates, Local Security Policy and most likely more.

Version Store: What is it?

The store is a temporary storage area in memory when object are being modified copies of it are stored here for the sake of providing atomic transactions. If change can't be completed the database would will roll back to it's previous state. It allows other threads to read from a copy of the data while it’s in the process of being modified.

Store feature

The store is able to hold long-running transactions such as

Deleting a group with 100,000 members
Deleting any object, not just a group, with 100,000 or more forward/back links to clean
Modifying ACLs in Active Directory on a parent container that propagate down to many thousands of inheriting child objects

Using resource we are able to monitor the version and see if there are any issues with it In resource monitor right click properties > Data > Add >

Select your DC from the list or browse then scroll down to Database ==>

Select (lsass/NTDSA)\Version buckets allocated

This was done on Server 2019

Below is taken from Microsoft blog post by Ryan Ries (see sources for link) This is showing when a spike occurs (deleted 200k group OU)

You can see normally the store does not have much activity and after a spike it normalizes which you should be fine if this is the case. If it stays high or even maxed out for extended periods of time, then no more database transactions for you. This includes no more replication.

After you delete an object in AD, each domain controller has to process the linked-value attributes of that object to maintain the referential integrity of the database. It does this in “batches,” usually 1000 or 10,000 depending on Windows version and configuration. Since each “batch” of 1000 or 10,000 is considered a single transaction, a smaller batch size will tend to complete faster and thus require less version store usage. (But the overall job will take longer.)

If AD Recycle Bin enabled will defer this action by an msDs-DeletedObjectLifetime number of days after an object is deleted, since that’s the appeal behind the AD Recycle Bin – it allows you to easily restore deleted objects with all their links intact. Will create a new page about AD recycle bin

When you run out of storage, no other database transactions can be committed until the transaction or transactions that are causing the version store exhaustion are completed or rolled back. At this time people start rebooting the DC and this could resolve this issue. I do remember in the past having to restart certain servers and things started to work again

Event ID: 1519 Internal Error: Active Directory Domain Services could not perform an operation because the database has run out of version storage.

Event ID: 623 NTDS (480) NTDSA: The version store for this instance (0) has reached its maximum size of 408Mb. It is likely that a long-running transaction is preventing cleanup of the version store and causing it to build up in size. Updates will be rejected until the long-running transaction has been completely committed or rolled back.

Sources: