Share via

Schema Cache

All changes made to Active Directory are validated first against the schema. For performance reasons, this validation takes place against a version of the schema that is held in memory on the domain controllers. This "in-memory version," called the schema cache, is updated automatically after the on-disk version has been updated. The schema cache provides mapping between attribute identifiers such as a database column identifier or a MAPI identifier and the in-memory structures that describe those attributes. The schema cache also provides lookups for class identifiers to get in-memory structures describing those classes.

When the computer is started, the schema cache is loaded from the underlying database and updated automatically whenever the on-disk version is updated. When changes are made to the schema, the schema cache is automatically updated within five minutes after the first change was applied. During the interval before the schema updates are copied to the schema cache, objects that reference a new or modified class or attribute cannot be added. This behavior keeps the cache consistent, but it can be confusing because changes are not apparent until the cache is updated, even though they were applied on disk.

There is also a mechanism for updating the schema cache on demand. You can use this when you modify the schema. You can add the schemaUpdateNow attribute to the rootDSE with a value of 1. The value is not used; it acts as a trigger or operational attribute. Writing this attribute starts a cache reload.

The rootDSE is a DSA-specific entry that holds the attributes that pertain to the local domain controller, such as directory partitions, server name, and supported LDAP version numbers. The schemaUpdateNow attribute is defined as an operational attributeI>,used only for administering the directory server itself. It is an artifact attribute that is never defined in the schema and does not require any storage. Generally, when you set an operational attribute, you trigger some action on the server.

Adding the schemaUpdateNow attribute causes a schema cache update to start immediately. The call is blocking, which means that if the call returns with no error, the cache is updated and all schema updates are ready to be used. An error return, however, indicates that the cache update is not successful. It is recommended that applications that want to take advantage of this feature be designed to accommodate the blocking write, particularly in giving the user feedback, if the program or script runs interactively.


It is recommended that you force an immediate schema cache update only once and only after all required schema updates are finished because cache loads are expensive in terms of memory.