Your Mission: Delete from the AD Schema

Many books and articles about the Active Directory (AD) schema—even from Microsoft—state that deleting classes or attributes from the AD schema is impossible. The supposed inability to delete from the schema presents problems for AD administrators because testing new schema extensions is difficult and removing unwanted extensions is unachievable. Suppose you want to test the schema-extension process in a test forest. If you encounter an error while testing the extensions, you'll want to retest them. However, because you can't delete them, you find that you must rebuild the forest. Or suppose you add extensions in a production forest that turn out to be faulty. You'd like to simply delete them, but you can't.

Now is the time to dispel the myth that deleting from the schema is impossible. Let's take a look at how to enable schema deletions and what precautions you must take before doing so.

A Little Background
The AD schema defines how AD represents and structures data. A basic understanding of the schema is essential for any AD administrator. A couple of excellent starting points for learning more about the schema are "Diving into the AD Schema," September 2001, http://www.winnetmag.com, InstantDoc ID 21839, and "Extending the AD Schema," November 2001, http://www.winnetmag.com, InstantDoc ID 22540.

Over the past couple of years, more and more applications have become directory-aware and are requiring that data reside in AD. In most cases, these applications require that you extend the AD schema to include custom classes and attributes. When you store data in AD, applications can use AD's distributed, multimaster architecture so that a separate replication mechanism isn't necessary for transferring data between application servers. Storing information in AD also makes the application data more accessible to end users and other applications.

Many IT departments extend the schema for their own use. For example, organizations that have a "white pages" application that internally publishes employee or customer information might need to extend the schema to support specific attributes that don't exist in the default AD schema. Suppose you need to add building name to each employee's user object. Because the default AD schema doesn't contain a building attribute, you must either create a new attribute or use an existing unused attribute for that purpose. The AD schema contains many useful attributes and classes, but most vendors and large organizations will need to add others to fully meet their applications' requirements. To make the most of AD's capabilities, you need to extend the schema.

Because extending the schema is such an essential task in AD, the ability to delete schema extensions can be extremely beneficial. Many people were disappointed that Microsoft neglected to support a means to delete schema extensions in Windows 2000. In Microsoft's defense, deleting attributes or classes from the schema is a highly sensitive operation that, if performed inappropriately, can have disastrous consequences in your AD environment.

If you delete a class and objects of that class still exist, AD might end up in an inconsistent state or objects might exist without a class definition. Although AD's multimaster replication architecture is beneficial, that architecture complicates the implementation of a robust schema-deletion process. You have no way to guarantee that an object isn't using a class or attribute before you delete that object. After you delete a class or attribute on a domain controller (DC), an application could create an object that uses that class or attribute on a DC that has yet to receive the deletion update.

Although Microsoft doesn't support the deletion of classes or attributes, you can deactivate them, much as you can disable a user account. The object will still exist in AD, but you can't use it to instantiate other objects and you can't use it in other class definitions. In Microsoft .NET, Microsoft has taken the deactivation functionality a step further by letting you redefine (i.e., recreate, as opposed to reactivate) deactivated classes or attributes, if necessary.

Benefits of Deleting from the Schema
You might wonder why deleting from the schema is important, particularly considering that Microsoft provides the deactivate function. The two most significant reasons why you might need to delete from the schema are to test new schema extensions and to remove unused classes and attributes.

Anyone who has developed schema extensions for AD understands that testing new extensions can be a painful process. Without the ability to remove schema extensions, the only way to repeatedly test modifications to extensions or the extension process itself is to use a different forest each time or rebuild the already-extended forest. For application developers, this process can be tedious.

A third benefit of deleting from the schema is to remove extensions that decommissioned applications have created. In most enterprises, applications come and go for a variety of reasons. More than likely, an application for which you've extended the schema will eventually be decommissioned or no longer used. Deleting from the schema lets you remove all traces of the application's existence in AD. Cleaning up the schema will become even more important over time, as the number of stale classes and attributes grows.

   Previous  [1]  2  3  Next