Deactivating Schema Extensions

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.

   Previous  1  [2]  3  Next