Compartilhar via

Deactivating a class or attribute

  • Artigo

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2

Deactivating a class or attribute

Domain controllers running Windows Server 2003 do not permit the deletion of classes or attributes, but they can be deactivated if they are no longer needed or if there was an error in the original definition. A deactivated class or attribute is considered defunct. A defunct class or attribute is unavailable for use; however, it is easily reactivated.

If your forest has been raised to the Windows Server 2003 functional level, you can reuse the object identifier (governsId and attributeId values), the ldapDisplayName, and the schemaIdGUID that were associated with the defunct class or attribute. This allows you to change the object identifier associated with a particular class or attribute. The only exception to this is that an attribute used as a rdnAttId of a class continues to own its attributeId, ldapDisplayName, and schemaIdGuid values even after being deactivated (for example, those values cannot be reused).

If your forest has been raised to the Windows Server 2003 functional level, you can deactivate a class or attribute and then redefine it. For example, the Unicode String syntax of an attribute called SalesManager could be changed to Distinguished Name. Since Active Directory does not permit you to change the syntax of an attribute after it has been defined in the schema, you can deactivate the SalesManager attribute and create a new SalesManager attribute that reuses the same object identifier and LDAP display name as the old attribute, but with the desired attribute syntax. You must rename the deactivated attribute before it can be redefined.

For more information about forest functionality, see Domain and forest functionality.

Notes

  • Classes and attributes added to the base schema can be deactivated without raising the forest functional level. However, they can be redefined only in forests raised to the Windows Server 2003 functional level or higher.

  • Default schema attributes or classes in the base schema cannot be deactivated if bit 4 of the systemFlags attribute is set to 1. Only attributes or classes where bit 4 of the systemFlags attribute is equal to zero can be deactivated.

Object identifiers must be unique. Mistyping a number when entering an object identifier can cause a conflict between the invalid object identifier and a legitimate object identifier that is registered by an application. When installing an application that adds an attribute or class, the application may need to use the mistyped object identifier for one of its legitimate schema extensions. You can correct object identifier conflicts in forests that are set to the Windows Server 2003 functional level. To correct the conflict, deactivate the attribute or class with the incorrect object identifier. The application installation program will then be able to create the new attribute or class using the correct object identifier.

Before deactivating a class, consider the following:

  • You can deactivate a class only if that class is not specified as a subClassOf, auxiliaryClass, systemAuxiliaryClass, possSuperiors, or systemPossSuperiors of any existing active class.

  • You cannot use a defunct class in definitions of new classes, and you cannot add it to existing class definitions.

  • You cannot create objects that are instances of the defunct class or modify existing instances of the class. However, the instances of the defunct class become available again for modification when the defunct class is reactivated.

Before deactivating an attribute, consider the following:

  • You can deactivate an attribute only if the attribute is not specified as a systemMustContain, mustContain, systemMayContain, mayContain, or rdnAttId of any existing active class.

  • You cannot use a defunct attribute in definitions of new classes, and you cannot add it to existing class definitions.

  • You cannot read, modify, or delete instances of the defunct attribute present in existing objects. However, the instances of the defunct attribute become available when the defunct attribute is reactivated.

  • To purge the directory of instances of an attribute you must delete the instances before deactivating the attribute.

Classes and attributes can be deactivated programmatically (recommended) or by using the Active Directory Schema snap-in. To deactivate a class or attribute using the Active Directory Schema snap-in, see Deactivate a class or attribute. For information about programmatically deactivating classes and attributes, see the Active Directory Programmer's Guide at the Microsoft Web site.

Reactivating a class

A defunct class can be reactivated. However, a defunct class cannot be reactivated unless the attributes referenced in its mustContain, systemMustContain, mayContain, and systemMayContain properties are active and the classes referenced in its subClassOf, auxiliaryClass, systemAuxiliaryClass, possSuperiors, and systemPossibleSuperiors properties are also active.

Further, a defunct class cannot be reactivated if the values of the following attributes collide with an already active attribute or class: ldapDisplayName, attributeId, governsId, or schemaIdGuid.

To reactive a defunct class, see Reactivate a class or attribute.

Reactivating an attribute

An defunct attribute can be reactivated. However, a defunct attribute cannot be reactivated if the values of the following attributes collide with an already active attribute or class: ldapDisplayName, attributeId, governsId, schemaIdGuid, or mapiId.

To reactive a defunct attribute, see Reactivate a class or attribute.