Modifying Active Directory Schema: The Active Directory Schema will probably be modified at some time during the life of your implementation plan. Many applications used as common tools, such as email, will require modification to add necessary objects to the Active Directory database. Being able to safely and correctly modify the schema is a key task for any Active Directory administrator.
Modifying The Active Directory Schema
Numerous commercial applications require the ability to extend the Active Directory schema, or you may wish to create custom schema extensions to support in-house applications that you have developed internally.
For example, Microsoft Exchange 2003 adds over 1,000 classes and attributes to the schema to support its operation. Each class or attribute that you add to the schema should have a valid Object Identifier (OID).
As part of the X.500 structure on which Active Directory is based, OIDs must be globally unique, and they are represented by a hierarchical dotted-decimal notation string. If you are a familiar with the Simple Network Management Protocol (SNMP) namespace, you will recognize the OID structure.
An example of a complete OID might be 1.55678.5.15. OIDs can be obtained directly from the ISO at www.iso.org or from the American National Standards Institute (ANSI) at www.ansi.org.
The Active Directory Schema is replicated to every domain controller within a forest, which means that each Active Directory forest can only have a single schema. Modifications to the schema are managed by the domain controller that is assigned the Schema Master FSMO role.
By default, the Schema Master FSMO is assigned to the first domain controller that’s installed in the forest. Any changes to the schema are then replicated to all domain controllers in the forest during the Active Directory replication process. Planning for these changes involves an understanding of the following points:
- Schema extensions are replicated to all domain controllers in the forest and have a global effect on the modified objects and attributes.
- Default system classes cannot be modified, but additional classes can be added and changed. The best example of this occurs when an application modifies the schema.
- Any class and attribute that you add to the schema cannot be removed; extending the schema is a one-way operation. However, beginning in Windows Server 2003, schema additions can be deactivated, which reduces the overhead created by unwanted schema modifications.
- When the schema is modified, it triggers replication within the forest. Planning modification of the schema may require sensitivity to the time of day and the possible performance impact. If modifications are made during peak usage hours, users may experience some significant performance issues. In particular, an application like Microsoft Exchange 2003 can add over 1000 attributes to the schema at once.
- A certain amount of latency can be expected before all domain controllers contain consistent schema information.
Because of the ramifications of extending the schema improperly, you should only make these modifications if the change is specifically required. Many things in the schema can go awry if changes are made incorrectly.
To protect against possible midnight restores of a corrupted Active Directory, be sure you fully understand the ramifications of a change prior the fact. If the original attribute is called by another script or program, that script or program will not function properly until the issue is resolved. In addition, adding administrators to the schema admin group only for the duration of the task is recommended.
Also, be sure to test any modifications in an isolated environment that closely matches your actual production environment before releasing the changes to the productions network. Planning modifications can sometimes delay the deployment of a desired application or feature, but it is well worth the effort if something does not function as designed in the test environment.
You may want to institute a change management process infrastructure prior to beginning modifications. The CMP will permit you to track exactly which changes were made to the schema and who made those changes.