Your schema changes don't take effect immediately. For performance reasons, AD holds a copy of the schema in memory. A refresh of the in-memory copy occurs automatically 5 minutes after a schema modification, but you can force an immediate update. To do so, the script uses the RootDSE object's functional schemaUpdateNow attribute.
Alternatively, you can update the cache through the Active Directory Schema snap-in. Or you can use a third option: You can use Ldifde to load the LDIF file that Listing 2 shows. (An LDIF file is simply an ASCII version, with binary values encoded in base 64, of exported directory content. For more information about Ldifde and LDIF files, see the Microsoft article "Using LDIFDE to Import/Export Directory Objects to the Active Directory" at http://support.microsoft.com/support/kb/articles/q237/6/77.asp.)
Import to Production
After you've perfected your schema extension in a test environment, you must reproduce the extension in your Win2K production AD forest. You can use the script that you developed in the lab; simply adapt any parameters that differ between your test and production environments. Or you can use Ldifde to create an LDIF file that contains the extension attribute and class objects, export the LDIF file, and import the file into your production forest. For example, to create the dogfoodschema.ldf file, which Figure 3 shows, type
LDIFDE -f DogFoodSchema.ldf -d
"cn=Schema,cn=Configuration,
dc=MyW2KRootDomain,dc=com"
-r "(cn=df-HR*")
This LDIF file contains the extensions as they exist in your test forest. Before you use Ldifde to import the file into your production forest, you should review the file's contents and make any necessary changes to match your production systems' specifications.
Wait for Replication
After you load the schema update to your production system, you should ensure rather than assume that AD has replicated the update across the forest. This procedure is especially important when your update's purpose is to prepare for the installation of an application such as Exchange 2000 because you must wait to start the software installation until the update properly replicates to every DC. To verify that replication is complete, connect to a remote DC through the Active Directory Schema snap-in and determine whether the extension is present in the Schema NC. You should also monitor the Directory Service (DS) event log for replication errors. (Products such as DirectoryAnalyzer can help you monitor AD replication.)
Manage New Objects
After you've successfully created your extension, you still have some work to do. You need a way to manage the new attributes and classes that you added to the schema. You can develop a Web interface or client-side application to do the job, or you can create an MMC extension snap-in. However, the standard MMC Active Directory Users and Computers snap-in doesn't show extension attributes by default. You must first use display specifiers to extend the console. Display specifiers are attributes that reside in the AD Configuration NC's cn=DisplaySpecifiers container and that contain data that relates to a specific class, as well as define how to display that data. A complete explanation of display specifiers and how to use them is outside the scope of this article, but you can read the Microsoft white paper "Active Directory Display Specifiers" (http://www.microsoft.com/windows2000/techinfo/howitworks/activedirectory/addisplay.asp) for details.
Secure Your Extensions
Each classSchema object has a default security descriptor that protects objects you instantiate from that class. If you need more specific control over access to your new extensions, AD provides a way to define new rights and dedicate those rights to a new object. (For our DogFood company example, you might want to create a right that lets users read, but not change, the badge-number attribute.) These rights, called extended rights, reside in the Configuration NC's cn=Extended-Rights container and contain information about the attributes to be protected and how to protect them. Like display specifiers, extended rights are outside the scope of this article; for information about creating and implementing these rights, refer to the Platform SDK on the MSDN Web site (http://msdn.microsoft.com/library/default.asp?url=/library/psdk/adsi/glsecur2_3cvn.htm).
Look, then Leap
To successfully modify the AD schema, you must understand the steps you need to take and commit to following them exactly. The most vital requirement is a well-defined plan that includes adequate testing. This point is extremely important because schema modifications are irreversible under Win2K. As schema manager, you must be sure to validate all the tests and configurations before you decide to implement the schema extension in your production forest. When you respect these basic rules, you can enjoy AD's flexibility and ability to meet your data needs—and you won't feel as though you're in over your head.