| Downloads |
|---|
| 41666.zip |
An Active Directory (AD) schema extension adds a class or attribute to the base schema (i.e., the version of the schema that comes with Windows Server 2003 or Windows 2000 Server). Extending the Win2K schema always has required careful planning because Microsoft doesn't support any method of deleting objects from the schema. (The article "Your Mission: Delete from the AD Schema," December 2002, http://www.winnetmag.com, InstantDoc ID 27096, describes a way to delete schema objects, but the method is unsupported and requires caution.) This limitation has often been a showstopper for enterprises that want to use AD to store company-specific information.
You can, however, disable certain classes and attributes in Win2K. Better yet, Windows 2003 lets you deactivate an extension's definition so that the extension seems to disappear from AD; you then can reuse elements (e.g., lDAPDisplayName attribute, Object Identifier—OID) from the deactivated extension. Still, deactivating an AD schema extension demands the same care and planning as creating an extension. You need to consider several factors, including why you want to deactivate the extension, the original design and implementation of the extension, which version of AD you're running (i.e., Windows 2003 or Win2K), and in what mode (aka functional level) you're running AD. (In Windows 2003, the domain and forest functional levels determine which AD features are available. The functional level depends on which OSs your domain controllers—DCs—run. You can configure the Windows Server 2003 forest functional level only when all the DCs in a forest run Windows 2003. This level gives you access to the most new AD features. (For more information about functional levels, see the Microsoft article "HOW TO: Raise Domain and Forest Functional Levels in Windows Server 2003," http://support.microsoft.com/?kbid=322692.) After you've determined the possible ramifications and complications of deactivating the extension, you can use ADSI Edit, the Microsoft Management Console (MMC) Active Directory Schema snap-in (schmmgmt.dll), a Lightweight Directory Access Protocol (LDAP) Data Interchange Format (LDIF) file, or a script to carry out the task.
Before you continue with this article, be sure you understand how the schema works. For more information about schema terminology, mechanisms, and the process of creating extensions, see "Extending the AD Schema," November 2001, http://www.winnetmag.com, InstantDoc ID 22540, and "Diving into the AD Schema," September 2001, InstantDoc ID 21839.
Analyze the Existing Extension
The first factor to consider before deactivating a schema extension is your reason for doing so. Typically, you'll base your decision on one of three possible reasons, as the sidebar "Reasons for Deactivation" explains. The reason will affect the level of difficulty and therefore the amount of planning you can anticipate.
Second, be sure you understand the design and implementation of the extension you want to deactivate. Pay special attention to the various classSchema and attributeSchema object links that the extension involves. Because a schema extension's classSchema and attributeSchema object definitions reference one another (i.e., a set of attributes is always associated with a specific class), you need to unlink these objects before you can deactivate the schema extension's schema object definition.
Third, carefully consider the information used to create the schema extension. If you plan to recreate an updated version of the extension, be aware that, depending on the OS and mode under which AD is operating, some information won't be reusable even after you deactivate the original extension. Web Table 1 lists several classSchema attributes that often are involved in the creation of a new classSchema object (i.e., a new class) and that might not be reusable. Web Table 2 lists attributes that are often involved in the creation of a new attributeSchema object (i.e., a new attribute) and that might not be reusable.
You can use several tools to examine existing schema extensions and gather these types of information. Aside from ADSI Edit, the Active Directory Schema snap-in, and LDP (under Windows 2003's Support Tools), you can use Microsoft's Schema Documentation program, which is available at http://msdn.microsoft.com/library/en-us/dnactdir/html/schemadoc.asp. This little-known program, which supports Windows 2003 or Win2K servers, basically extracts a schema extension to an .xml file; you then can review the extension in any XML editor.
Rules and Restrictions
Depending on the AD version and mode, different restrictions will apply regarding which types of AD objects you can deactivate. Regardless of the OS version and mode, the following characteristics are true.
- Microsoft doesn't support the deletion of any classSchema or attributeSchema objects that have been added to the Schema naming context (NC).
- You can't deactivate a Category 1 classSchema or attributeSchema object. (See "Diving into the AD Schema" for more information about schema object categories.)
- You can't deactivate an attributeSchema object that's part of an active classSchema object.
- You can deactivate a classSchema or attributeSchema object by setting the object's IsDefunct attribute to True.
- When you set a classSchema or attributeSchema object's IsDefunct attribute to True, you can't create a new instance of that object. However, existing instances of the object remain intact. A deactivated attributeSchema object is invisible to existing instances.
Further restrictions in Win2K environments. In Win2K AD environments, certain restrictions apply regardless of whether the organization is running in native or mixed mode. Therefore, you need to consider the following points before disabling an object.
- To reuse the lDAPDisplayName attribute of a class or an attribute that you plan to deactivate, you must change the lDAPDisplayName attribute before you set the IsDefunct attribute to True. Furthermore, you can modify the lDAPDisplayName attribute only on user-defined schema objects, which are Category 2 objects.
- Even if you can reuse the lDAPDisplayName attribute, note that you can't reuse the object's OID. This restriction can be annoying when you need to recreate a standardized schema extension, such as one that an Internet Engineering Task Force (IETF) Request for Comments (RFC) defines. Because the recreated extension's OID number must differ from the originated extension's, the recreated extension clearly won't reflect the standard extension OID as defined by the RFC. However, most applications address classes and attributes by their lDAPDisplayName, so this discrepancy probably won't present a problem unless you must strictly follow the RFC for compliance reasons or unless the Directory Enabled application addresses classes and attributes with the OID. Check with your application vendor or developer before deactivating extensions that might address classes and attributes in this way.
- You can't reuse the cn attribute because you can't rename the schema object. Therefore, to recreate the schema extension, the classSchema and attributeSchema must use a different cn. A good practice when creating schema objects is to add an index number at the end of the name (e.g., cn=DF-HR-Badge-Number-01). Directory Enabled applications use the lDAPDisplayName rather than the cn attribute, so this keeps the door open to recreate the schema object by using a consistent cn naming convention (which is especially useful for a test environment).
New features in Windows 2003 environments. When you operate AD at the Windows Server 2003 forest functional level, AD offers the following new features regarding a schema extension deactivation:
- You can reuse the lDAPDisplayName attribute on the condition that you first deactivate the classSchema or attributeSchema object that uses that lDAPDisplayName (i.e., you set the object's IsDefunct attribute to True). You don't need to change the lDAPDisplayName first, as Win2K requires. Other than this change, the conditions to deactivate a schema object in Win2K still apply in Windows 2003.
- In the same way, you can reuse the OID on the condition that the classSchema or attributeSchema object using the same OID is deactivated first (IsDefunct is set to true). Again, the other conditions to deactivate a schema object in Win2K still apply in Windows 2003.
- You can reuse the cn on the condition that you first rename the classSchema or attributeSchema object that's using the same cn. Also, you can rename the CN schema objects. In this context, you don't need to use an index number at the end of the name if you must recreate the extension many times.
Deactivating an Extension
You can use ADSI Edit or the Active Directory Schema snap-in to manually deactivate a schema extension, but to demonstrate the necessary sequence of operations, I've created a script called DeactivateMyCompanyUserAttributes.vbs (which you can download at http://www.winnetmag.com, InstantDoc ID 41666). This script deactivates a sample extension that adds an auxiliary classSchema object named dF-HR-EmployeeBadge, with an optional attributeSchema object named dF-HR-BadgeNumber, to the structural user class, as Figure 1 shows. (For more information about this sample extension and the process of its creation, see "Extending the AD Schema.") The script assumes that AD is running at Windows Server 2003 forest functional level. You must run the script on the Schema Flexible Single-Master Operation (FSMO) machine. You can modify this script to work in your environment, or you can use ADSI Edit and perform the necessary operations in the same order as in the script.
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.
