Export (0) Print
Expand All

Administering the ADAM schema

Updated: August 22, 2005

Applies To: Windows Server 2003 R2

Administering the ADAM schema

You can administer the Active Directory Application Mode (ADAM) schema in a number of ways, including extending the schema with new classes and attributes, deactivating classes and attributes, and reactivating classes and attributes. You can use the ADAM Schema snap-in to administer the ADAM schema.

For information about tasks related to administering the schema, see Manage Schemas and Directory Partitions.

Extending the schema

Before you can use ADAM to support a particular directory-enabled application, you may need to modify the ADAM schema with classes and attributes that are required by that application. You can easily modify the ADAM schema by using a number of methods, including:

  • Automatically, through a directory-enabled application.

  • Semiautomatically, using Ldifde.exe and the importation of .ldf files.

  • Programmatically, through Active Directory Service Interfaces (ADSI).

  • Manually, through Ldp and the ADAM Schema snap-in.

noteNote
Before you can use the ADAM Schema snap-in, you must first install it. For more information, see Install the ADAM Schema snap-in.

For environments that require the ability to create users in the ADAM directory, ADAM includes an importable .ldf file that contains four user object classes. For information about importing the ADAM user .ldf file, see Import the user classes supplied with ADAM.

Deactivating classes and attributes

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 a defunct class to existing class definitions.

  • You cannot create objects that are instances of a defunct class or modify existing instances of a defunct 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 a defunct attribute to existing class definitions.

  • You cannot read, modify, or delete instances of a defunct attribute that are 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.

Was this page helpful?
(1500 characters remaining)
Thank you for your feedback

Community Additions

ADD
Show:
© 2014 Microsoft