Active Directory Schema
Active Directory Schema |
|
When you modify the schema, you must be aware of the implications and of the potential problems that can arise. There are three main issues involved with modifying the schema: replication, concurrency control, and handling invalid object instances.
Because the schema is replicated across all domain controllers in the forest, a schema update that is performed at one domain controller is guaranteed to be propagated throughout the forest. This guarantees a schema that is consistent forest-wide. However, because of replication latencies, there can be temporary inconsistencies.
For example, consider that a new class A is created at server X, and then an instance of this class (B) is created at the same server (X). However, when the changes are replicated to another server Y, the object B is replicated out before the classSchema object A. When the change arrives at server Y, the replication of B fails because Y's copy of the schema still does not contain the classSchema object A. Hence, Y does not know about the existence of A.
Active Directory solves this problem in such scenarios by explicitly replicating the Schema container from the originating server when such failures occur. Additionally, the replication of the Schema container triggers an immediate schema cache update on the target server. Active Directory then re-replicates the object that failed. In the example, re-replication brings in classdefinition object A and also puts it into the schema cache of Y. Retrying the replication of B now succeeds.
Active Directory must ensure that different program threads do not perform simultaneous, conflicting schema updates (such as when one thread is deleting an attribute and another is adding it to the mayContain list of a class).
To ensure this, any thread that attempts to perform a schema update also automatically writes a special attribute on the Schema container as part of the transaction. (Active Directory automatically causes the thread to write the attribute you do not have to do so in your program code.) Only one thread can write this attribute at any one time. This method guarantees schema consistency, but it does not guarantee which of the updates is successful. You must be aware of this when schema updates are made in a batch (such as in the case of the installation of directory-enabled applications).
For example, consider a scenario in which two Active Directory–aware programs, A and B, are being installed simultaneously, each of which creates several new schema objects. Because Active Directory creates one thread per object update, it is possible that some of the objects in program A and some of the objects in program B get created (if the internal threads do not overlap), and then one of the installations fails (because a thread for a schema object creation for program A overlaps with a thread for a schema object creation for program B).
Assume that program A fails. Now running A from scratch again does not work because some of the objects that program A created are already in the schema; trying to re-create them in the second run (existing objects) returns an error. Therefore, it is recommended that programs that modify the schema not be run concurrently, unless provisions are made in the program to first check if the schema update that is about to be made has already been made and then proceed accordingly.
Schema update can make an existing instance of an object invalid. For example, suppose object X is an instance of class Y. Class Y has an attribute, Z, in its mayContain list. Therefore, because object X is an instance of class Y, object X can have this attribute defined on it. Assume that X does indeed have this attribute currently defined in it. Now a schema update is performed that modifies class Y by deactivating attribute Z from its mayContain list. Note that this change makes the instance of object X invalid because X now has an attribute, Z, that it is not allowed to have according to the class definition of Y (of which object X is an instance). Active Directory allows the now-invalid objects to remain in the directory and ensures that they do not cause any problems in the rest of the schema. Active Directory does not automatically clean up invalid objects, but invalid objects and attributes appear in searches and can be deactivated manually.