The code that Listing 1 shows declares constants defining which classSchema and attributeSchema objects I want to deactivate. The script then uses some basic Active Directory Service Interfaces (ADSI) operations to perform the deactivation. Listing 2 shows the code that retrieves the schema path. Listing 3 shows the code that removes the classSchema auxiliary class from the structural user class's auxiliaryClass attribute. Listing 4 shows the code that removes the attributeSchema object from the classSchema auxiliary class's mayContain attribute. Note that this step isn't mandatory in the example: I could simply deactivate the classSchema auxiliary class without removing the attributeSchema object from the classSchema object. However, I've split these two schema objects to demonstrate the process you'd need to follow if you wanted to deactivate the attribute but continue to use the auxiliary class (perhaps for another set of attributes). Therefore, you can deactivate a classSchema object that contains active attributeSchema objects, but you can't deactivate an attributeSchema object that's part of an active classSchema object. In such a situation, you'd need to remove the attributeSchema object from the auxiliary class.
Listing 5 shows the code that renames the classSchema auxiliary class to a unique name. This name consists of the current date and time in the strDateTime variable initialized at the beginning of Listing 5. The unique name is useful only if you recreate the schema extension and then deactivate that new extension. Although rare in production environments, this situation is common in development environments, in which you might want to test different versions of the same schema extension.
Listing 6 shows the code that deactivates the classSchema auxiliary class. Listing 7 shows the code that removes the attributeSchema object from the AD indexes and Global Catalogs (GCs).
Listing 8 shows the code that renames the attributeSchema object to a unique name (made with the strDateTime variable). Listing 9 shows the code that deactivates the attributeSchema object. Listing 10 shows the code that updates the schema cache to make the changes effective. Note that the replication from the Schema FSMO DC to all other systems in the forest must still occur.
Ready to Deactivate Windows Server 2003's forest functional level eliminates most of the restrictions that previously have applied to AD schema modifications. However, effectively removing classSchema and attributeSchema objects that you've added to the Schema NC is still tricky and unsupported. As with implementing a schema extension, deactivating a schema extension requires planning to be successful.
Order Your Fundamentals CD Today! Register today for your in-depth copy of one of three Fundamental CDs on the following topics – Exchange, SQL, and SharePoint.
