Extending the AD Schema

Windows 2000 Active Directory (AD) offers a sea of data-management possibilities. "Diving into the AD Schema," September 2001, helps you wade through the AD schema's somewhat complicated collection of terms and relationships: classSchema and attributeSchema objects (and associated attributes) and the relationships among abstract, auxiliary, and structural classes and attributes. Now, you're ready to consider heading into the deep end of the pool to extend the schema.

First, decide whether an extension is truly necessary and think about how it will affect your AD forest. Keep in mind that you can't remove AD extensions under Win2K, so you must understand the schema's restrictions and requirements, and you must carefully plan and test an extension before you implement it in your production environment. Create an extension object successfully in a test environment, then transfer the new object to your production AD.

To Extend or Not to Extend?
The best way to start a schema extension project is to consider whether the data you want to add even belongs in AD. Not all information is suitable for AD storage.

Publish only data that's of global network interest. AD isn't an appropriate storage place for data that only one server or one user accesses.

Avoid publishing data that changes frequently. Win2K distributes and replicates the directory on a regular basis; if the data is likely to be obsolete before AD can replicate data across the enterprise, the information doesn't belong in AD. A good rule of thumb is to publish data that has a useful lifetime longer than twice AD's replication latency (i.e., the time AD takes to replicate information updates or changes across the entire enterprise). Tools such as NetPro's DirectoryAnalyzer can help you monitor your network's replication latency.

Consider the bandwidth that data replication will require; the bandwidth will depend on how often the information changes and the size of the data object. For example, you might not want to store employees' pictures in AD if those pictures are high resolution and have 16 million colors.

If you do need to store a piece of information in AD but the data object is excessively large or changes frequently, you can store a pointer to the information to save replication bandwidth and AD storage space. You can store the data in a Microsoft SQL Server database and publish an ODBC connection string (with the SQL SELECT statement) as a dedicated attribute in AD. Or you can store the data on a Web server and publish a URL that refers users to the information. Of course, AD-enabled applications must be able to interpret the pointer correctly.

If you're confident that your new data belongs in AD, consider whether you can tweak the current schema to meet your needs. Perhaps you can modify an existing class instead of creating a new class. An extensive understanding of the schema in general and of your organization's needs in particular is invaluable and is the key to making the right choice to adapt or extend the base schema. (To perfect your schema knowledge, see "Diving into the AD Schema." You can also study the Microsoft Developer Network—MSDN—AD overview at http://msdn.microsoft.com/certification/schema/default.asp.)

No Turning Back Now
When you've decided to move ahead with a schema extension, keep in mind that only one schema exists for an entire AD forest. Win2K globally replicates the Schema naming context (NC), so any change you make to the Schema NC affects the entire forest.

Moreover, schema extensions aren't reversible. If you add a new classSchema or attributeSchema object, you can't delete it. You can disable some classes and attributes to work around this prohibition, but you can't disable an attribute of an active class, and you can't disable or rename Category 1 classes or attributes. (Objects that are part of the base Directory Information Tree—DIT—are Category 1 objects. See "Diving into the AD Schema" for details about schema object categories.)

You can, however, make certain changes to active schema objects. You can add a new class to a Category 1 or Category 2 classSchema object's possSuperiors attribute. You can add a new attribute to a Category 1 or Category 2 classSchema object's mayContain attribute. You can add a new auxiliary class to a Category 1 or Category 2 classSchema object's auxiliaryClass attribute. You can change a Category 2 classSchema or attributeSchema object's lDAPDisplayName attribute. (Changing the Lightweight Directory Access Protocol—LDAP—name lets you work around a mistake rather than rebuild the whole Win2K infrastructure or live with the mistake forever.)

But you can't add an attribute to or delete an attribute from an object's mustContain attribute, either directly, through an auxiliary class, or through inheritance from a parent class (superclass). Many Win2K components depend on Category 1 objects, so you can't modify these objects' rangeLower, rangeUpper, attributeSecurityGuid, defaultObjectCategory, objectCategory, or lDAPDisplayName attributes.

The complexity of these conditions clearly highlights the importance of carefully planning a schema modification before you start out. I strongly suggest that you choose one person to be in charge of planning, making, and verifying schema changes. This arrangement helps avoid confusion. For simplicity's sake, this article assumes that you'll function as schema manager.

The wise schema manager sets up a dedicated environment to play with before he or she even thinks of touching a production system. Use a separate test system on which you can uninstall and reinstall Win2K without affecting your production forest. I suggest that on the test system you configure one AD domain controller (DC), running one forest. Then, you can demote the system to remove schema changes and promote the system to retrieve the base AD schema.

In preparation, make sure that the user account you're using is a member of the Schema Admins group. You also need to locate the production Win2K DC that owns the schema Flexible Single-Master Operation (FSMO) role.

In your one-DC test environment, this machine will of course be your single DC. However, when you're ready to proceed to your production environment, you must have access to the schema FSMO machine because you must modify the registry on the schema FSMO system to switch the schema NC to read/write mode. To modify the registry, open a registry editor, go to the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters subkey, and set the Schema Update Allowed value (of type REG_DWORD) to 1.

Use a test environment. I can't repeat this recommendation too many times. When you follow careful planning and testing procedures, you dramatically increase your odds of completing a trouble-free schema-extension project.