Windows 2003 simplifies the process
| 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.
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.
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:
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.
