Schema classes and attributes

架构类别和属性

架构类别和属性

您创建的每个目录对象都是架构中包含的对象类的实例。每个对象类别都包含一个相关属性的列表，这些属性决定了该对象能够包含的信息。类别和属性是独立定义的，因此单个属性可与多个类别相关联。所有的架构类别和属性都是分别由 classSchema 和 attributeSchema 对象定义的。

类别

ClassSchema 对象用于定义架构中的类别。classSchema 提供了建立该类别的目录对象的模板。classSchema 的示例包括“用户”和“服务器”。classSchema 对象在其他内容中包含下列信息：

• 类别的类型（结构、抽象或辅助）
  
  
• 公用名和轻型目录访问协议 (LDAP) 显示名称
  
  
• 对象实例的“必须包含”和“可能包含”属性列表
  
  
• 相对可分辨名称属性
  
  
• 可能的父类别的列表
  
  

类别的类型

架构中存在三种不同类型的类别：

 

类别的类型	用途
结构	用于实例化目录中的对象（用户、服务器等）。
抽象	提供派生结构式类别的模板。
辅助	包含可包括到结构式和抽象类别中的属性的预定义列表。

注意

• 在 Windows Server 2003 家族中，inetOrgPerson 类别现在已经是基础架构的一部分。像用户类别一样，此类别可以同样的方式用作安全主体。
  
  

属性

AttributeSchema 对象用于定义架构中的属性。attributeSchema 对象确定了目录中该属性的实例所允许的内容和语法。attributeSchema 的示例包括“用户主体名称”和“电报号码”。attributeSchema 在其他内容中包含下列信息：

• 公用名和 LDAP 显示名称
  
  
• 语法规则
  
  
• 数据限制（单值与多值、最小和最大值）
  
  
• 属性是否以及如何索引
  
  

单值和多值属性

属性可以是单值的，也可以是多值的。单值属性的实例只能包含单个值。多值属性的实例可包含采用统一语法的多个值。多值属性不存储有关它所包含的属性的排序信息。多值属性的每个值必须唯一。

索引的属性

多值和单值属性都可进行索引以帮助提高对该属性的查询性能。（索引不能应用于类别。）根据属性的架构定义标记属性以便进行索引。索引属性时还允许用户在指定搜索字符串时使用通配符 (*) 作为前缀和后缀。将属性标记为可索引时，属性的所有实例都添加到索引中，而不仅仅是只有特定类成员的实例才被添加。对属性的索引，特别是对多值属性的索引，会负面影响复制和对象创建时间，以及目录数据库大小。因此，建议只索引常用的属性。详细信息，请参阅在 Active Directory 中编制属性的索引。

有关该架构的详细信息，请参阅 Microsoft Windows 资源工具包网站 和 Microsoft MSDN 网站 中的“Active Directory Schema”（Active Directory 架构）。

 

扩展架构

扩展架构

当基本的 Active Directory 架构中的类和属性集不能满足需要时，可以通过修改或添加类和属性来扩展架构。只有在绝对必要时才应扩展架构。扩展架构最简便的方法是使用 Microsoft 管理控制台 (MMC) 中的“架构”管理单元。只有在测试实验室中开发和测试架构扩展以后，才能将其扩展移至生产网络中。

扩展架构之前

在扩展架构之前，请查看如下要点：

 

首先检查基础架构	验证基础架构中现有的类和属性是否满足您的应用程序或数据的需要。有关基础架构中的类和属性的完整集，请参阅 Microsoft 网站。
查看架构文档	有关扩展架构的详细信息，请参阅 Microsoft 网站上的“Active Directory Programmer's Guide”（Active Directory 程序员指南）和 Microsoft Windows 资源工具包网站上的“Active Directory Schema”（Active Directory 架构）。
架构修改是全局的	扩展架构时，更改将应用于整个林中的每个域控制器。
不能修改系统相关的架构类	不能修改架构中的默认系统类（Windows 运行所需的类）。但是，用于修改架构的启用目录的应用程序可以添加可修改的新类。
架构扩展不可逆	属性或类在创建之后就不能删除。最多它们只能被修改或停用。详细信息，请参阅停用类别或属性。
获得有效的对象标识符	架构中的每个类和属性必须有一个唯一且有效的对象标识符（也称为 OID）。不要创建任意的对象标识符或重复使用旧的对象标识符。有关获得有效对象标识符的信息，请参阅架构对象名称。
记录所做更改	如果决定扩展架构，一定要记录所做更改。

如何扩展架构

可以使用图形用户界面 (GUI) 工具、命令行工具和脚本来修改架构。修改架构的最简便方法是使用 Microsoft 管理控制台 (MMC) 中的“Active Directory 架构”管理单元，它是进行架构管理的 GUI 工具。有关安装“Active Directory 架构”管理单元的信息，请参阅安装 Active Directory 架构管理单元。通过脚本修改架构需要有编程知识并熟悉 Active Directory 服务接口 (ADSI)。详细信息，请参阅 Active Directory 编程人员指南 和 Microsoft MSDN 网站 上的“Extending the Schema”（扩展架构）。

有关架构管理工具的详细信息，请参阅 Active Directory 架构的管理工具。

有关扩展架构的详细信息，请参阅修改现有架构类别或属性定义和添加新的架构类别或属性定义。有关停用和重新激活的信息，请参阅停用类别或属性、停用类别或属性和重新激活类别或属性。

使用测试林

避免在生产林中出现损失或发生代价昂贵的架构错误的最简单方法，是首先在测试林中测试您的架构扩展。通过使用测试环境，可以事先确定您的规划中的任何潜在问题，以免以后影响您的用户和生产环境。

在测试林中执行架构更改之后，可通过在架构更改复制到的测试林中降级每个域控制器，重新安装默认的架构。然后，使用“Active Directory 安装向导”在服务器上重新安装 Active Directory。此过程仅适用于测试环境。

 

停用类别或属性

停用类或属性

运行 Windows Server 2003 的域控制器不允许删除类或属性，但是如果不再需要这些类或属性，或者其原始定义中存在错误，则可以将其停用。停用的类或属性被认为“已经失效”。失效的类或属性不再可用；但可以方便地重新激活。

如果您的林已被提升到 Windows Server 2003 功能级别，则可重新使用与失效的类或属性相关的对象标识符（governsId 和 attributeId 值）、ldapDisplayName 和 schemaIdGUID。这样可允许您更改与特定类或属性相关的对象标识符。唯一的例外情况是，用作类的 rdnAttId 的属性即使在被停用之后也会继续拥有其 attributeId、ldapDisplayName 和 schemaIdGuid 值（例如，那些不能重新使用的值）。

如果您的林已被提升到 Windows Server 2003 功能级别，则可以停用某个类或属性，然后对其重新定义。例如，可以将 SalesManager 属性的“Unicode 字符串”语法更改为“可分辨名称”。由于 Active Directory 不允许在架构中定义某个属性之后再更改该属性的语法，因此您可以停用 SalesManager 属性并创建一个新的 SalesManager 属性，重新使用与旧的属性相同的对象标识符和 LDAP 显示名称，但却使用所需的属性语法。必须重命名停用的属性之后才能重新定义它。

有关林功能的详细信息，请参阅域和林功能。

注意

• 在不提升林的功能级别的情况下，可以停用添加到基础架构上的类和属性。但是，只有在提升到 Window Server 2003 或更高功能级别的林中才能重新定义它们。
  
  
• 如果 systemFlags 属性的第 4 位被设置为 1，则不能停用基础架构中的默认架构属性或类。只能停用 systemFlags 属性的第 4 位等于 0 的属性或类。
  
  

对象标识符必须是唯一的。在输入对象标识符时如果键入错误的数字，可能导致无效的对象标识符与某个应用程序已注册的合法的对象标识符之间发生冲突。当安装要添加属性或类的应用程序时，该应用程序可能需要使用已错误键入的对象标识符作为其合法的架构扩展之一。可以在设置为 Windows Server 2003 功能级别的林中纠正对象标识符。要纠正此冲突，请停用具有不正确的对象标识符的属性或类。然后，该应用程序安装程序就能使用正确的对象标识符创建新的属性和类。

停用类之前，请注意以下事项：

• 只能在未将类指定为任何现有有效类的 subClassOf、auxiliaryClass、systemAuxiliaryClass、possSuperiors 或 systemPossSuperiors 时，才可停用这个类。
  
  
• 不能在新类的定义中使用失效的类，也不能将失效的类添加到现有的类定义中。
  
  
• 不能创建作为失效类的实例的对象或修改此失效类的现有实例。但是，重新激活失效的类之后，失效的类的实例就再次变得可用，可对其修改。
  
  

停用属性之前，请注意以下事项：

• 只能在未将属性指定为任何现有有效类的 systemMustContain、mustContain、systemMayContain、mayContain 或 rdnAttId 时，才可停用这个属性。
  
  
• 不能在新类的定义中使用失效的属性，也不能将失效的属性添加到现有的类定义中。
  
  
• 不能读取、修改或删除失效属性在现有对象中的实例。但是，当重新激活失效的属性时，失效属性的实例就变得可用。
  
  
• 要清除属性实例的目录，必须在停用该属性之前删除其实例。
  
  

可以通过编程方式（推荐使用）或使用“Active Directory 架构”管理单元停用类和属性。若要使用“Active Directory 架构”管理单元停用某个类或属性，请参阅停用类别或属性。有关如何通过编程停用类或属性的信息，请参阅 Microsoft 网站 上的“Active Directory Programmer's Guide”（Active Directory 程序员指南）。

重新激活类

可以重新激活失效的类。但是，除非其 mustContain、systemMustContain、mayContain 和 systemMayContain 属性中引用的属性是有效的，并且其 subClassOf、auxiliaryClass、systemAuxiliaryClass、possSuperiors 和 systemPossibleSuperiors 属性中引用的类也是有效的，否则不能重新激活已失效的类。

而且，如果下列属性的值与已经有效的属性或类相冲突，也不能重新激活已失效的类，这些属性是：ldapDisplayName、attributeId、governsId 或 schemaIdGuid。

要重新激活已失效的类，请参阅重新激活类别或属性。

重新激活属性

可以重新激活失效的属性。然而，如果下列属性的值与已经有效的属性或类相冲突，也不能重新激活已失效的属性，这些属性是：ldapDisplayName、attributeId、governsId、schemaIdGuid 或 mapiId。

要重新激活已失效的属性，请参阅重新激活类别或属性。

 

架构对象名称

架构对象名称

在扩展架构时，需要知道如何引用架构对象。类和属性架构对象都可通过下列几种方式进行引用：

• 轻型目录访问协议 (LDAP) 显示名称
  
  
• 公用名
  
  
• 对象标识符
  
  

LDAP 显示名称

“Active Directory 架构”管理单元和其他管理工具显示对象的 LDAP 显示名称。程序员和系统管理员使用 LDAP 显示名称以编程方式引用对象。LDAP 显示名称通常由两个或多个单词组合而成。该名称包含多个单词时，名称中后面的单词用大写形式标识出来。例如，mailAddress 和 machinePasswordChangeInterval 都是 LDAP 显示名称。保证每个对象的 LDAP 显示名称都是唯一的。

公用名

公用名是 LDAP 显示名称的更加易读的版本。上例中使用的两个属性的公用名为 SMTP-Mail-Address 和 Machine-Password-Change-Interval。保证公用名在容器内是唯一的。

对象标识符

对象标识符（也称为 OID）是由一些颁发机构发放的，如国际标准化组织 (ISO) 或美国国家标准学会 (ANSI)。例如，SMTP-Mail-Address 属性的对象标识符是 1.2.840.113556.1.4.786。每个对象标识符必须是唯一的。有关 ISO 的详细信息，请参阅国际标准化组织的网站。

在扩展架构时，可以通过 Microsoft 注册新的对象标识符。详细信息，请参阅 Microsoft 网站。

架构对象命名规则

为使架构命名约定标准化，Microsoft 强烈建议架构扩展应遵守“LDAP 显示名称”和“公用名”的命名规则。为满足“已经过 Windows 认证”的条件，扩展架构的应用程序必须遵守这些命名规则。详细信息，请参阅 Microsoft 网站上的认证程序文档的 Active Directory 章节。另请参阅 Microsoft 网站上的 Active Directory 程序员指南。

消息队列别名

消息队列别名是 Active Directory 中的一个对象，可用来引用可能未在 Active Directory 中列出的队列。例如，可以使用队列别名来引用通讯组上下文中的专用队列。另外，可以使用“Active Directory 用户和计算机”来创建队列别名。使用队列别名可提供下列好处：

• 删除队列别名对象时，该别名将自动从所有引用它的通讯组列表中删除。
  
  
• 更改队列别名所引用的队列时，不必更改别名。
  
  
• 队列别名可用于引用目录服务中没有列出的队列，包括专用队列或来自其他组织的队列。
  
  
• 通过引用那些使用直接格式名的目标队列，队列别名可用来发送 http 消息。
  
  

队列别名对象只有一个属性，即引用队列的格式名。队列别名可包含公用、专用和直接格式名。队列的格式名不能超过 255 个字符。详细信息，请参阅使用消息队列。

 

Schema classes and attributes

Updated: January 21, 2005

Schema classes and attributes

Every directory object you create is an instance of an object class contained in the schema. Each object class contains a list of associated attributes that determine the information the object can contain. Classes and attributes are defined independently, so that a single attribute can be associated with multiple classes. All schema classes and attributes are defined by the classSchema and attributeSchema objects, respectively.

Classes

ClassSchema objects are used to define classes in the schema. A classSchema object provides the template for building directory objects of that class. Examples of classSchema include User and Server. A classSchema object contains, among other things, the following information:

• Class type (structural, abstract, or auxiliary)
  
• Common name and Lightweight Directory Access Protocol (LDAP) display name
  
• Lists of the "must contain" and "may contain" attributes for instances of the object
  
• Relative distinguished name attribute
  
• A list of possible parent classes
  

Class types

Three different types of classes exist in the schema:

 

Class type	Purpose
Structural	Used to instantiate objects (users, servers and so on) in the directory.
Abstract	Provides templates for deriving structural classes
Auxiliary	Contains predefined lists of attributes that can be included in structural and abstract classes.

Note

• With the Windows Server 2003 family, the inetOrgPerson class is now a part of base schema. This class can be used as a security principal in the same manner as the user class.
  

Attributes

AttributeSchema objects are used to define attributes in the schema. An attributeSchema object determines the allowable contents and syntax for instances of that attribute in the directory. Examples of attributeSchema include User-Principal-Name and Telex-Number. An attributeSchema object contains, among other things, the following information:

• Common name and LDAP display name
  
• Syntax rules
  
• Data constraints (single versus multivalued, minimum, and maximum values)
  
• Whether and how the attribute is indexed
  

Single and multivalued attributes

Attributes can be single-valued or multivalued. An instance of a single-valued attribute can can only contain a single value. An instance of a multivalued attribute can contain multiple values of uniform syntax. A multivalued attribute stores no information about ordering of the attributes it contains. Each value of a multivalue attribute must be unique.

Indexed attributes

Both multivalued and single valued attributes can be indexed to help improve the performance of queries on that attribute. (Indexing does not apply to classes.) Attributes are marked for indexing based on their schema definition. Indexing an attribute also allows users to use wildcards (*) as prefixes and suffixes when specifying a search string. When you mark an attribute as indexed, all instances of the attribute are added to the index, not just the instances that are members of a particular class. Indexing attributes, particularly multivalued attributes, can negatively affect replication and object creation time, as well as directory database size. So, it is recommended that you only index commonly used attributes. For more information, see Index an attribute in Active Directory.

 

 

Schema object names

Updated: January 21, 2005

Schema object names

When extending the schema, you need to know how to reference schema objects. Both class and attribute schema objects can be referenced in several ways:

• Lightweight Directory Access Protocol (LDAP) display name
  
• common name
  
• object identifier
  

LDAP display name

The Active Directory Schema snap-in and other administrative tools display the LDAP display name of objects. Programmers and system administrators use LDAP display names to reference objects programmatically. The LDAP display name typically consists of two or more words combined. When the name consists of multiple words, subsequent words in the name are identified using capitalization. Example LDAP display names are mailAddress and machinePasswordChangeInterval. The LDAP display name is guaranteed to be unique for each object.

Common name

The common name is a more readable version of the LDAP display name. The common names of the two attributes used in the previous example are SMTP-Mail-Address and Machine-Password-Change-Interval. Common names are guaranteed to be unique within a container.

Object identifier

An object identifier (also known as OID) is issued by an issuing authority such as the International Organization for Standardization (ISO) or the American National Standards Institute (ANSI). For example, the object identifier for the SMTP-Mail-Address attribute is 1.2.840.113556.1.4.786. Every object identifier must be unique. For more information about ISO, see the International Organization for Standardization Web site.

When extending your schema, you can register new object identifiers through Microsoft. For more information, see the Microsoft Web site.

Schema object naming rules

To help standardize schema naming conventions, Microsoft strongly suggests that schema extensions adhere to naming rules for both the LDAP Display Name and the Common Name. To qualify as "Certified for Windows," an application that extends the schema must adhere to these naming rules. For more information, see the Active Directory chapter of the certification program documentation at the Microsoft Web site. See also the Active Directory Programmer's Guide at the Microsoft Web site.

Message queuing aliases

A message queuing alias is an object in Active Directory that can be used to reference queues which might not be listed in Active Directory. For example, a queuing alias can be used to reference a private queue within the context of a distribution list. You can create a queuing alias by using Active Directory Users and Computers. Using queuing aliases provides the following benefits:

• When a queuing alias object is deleted, the alias is automatically removed from all distribution lists that reference the alias.
  
• A queue referenced by a queuing alias can be changed without changing the alias.
  
• Queuing aliases can be used to reference a queue not listed in the directory service, including private queues or queues from another organization.
  
• Queuing aliases can be used to send http messages by referencing the destination queue using a direct format name.
  

A queuing alias object has a single attribute, a format name that references a queue. Queuing aliases can contain public, private, and direct format names. The format name for the queue cannot exceed 255 characters. For more information, see Using Message Queuing.

 

Deactivating a class or attribute

Updated: January 21, 2005

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.

 

 

Extending the schema

Updated: January 21, 2005

Extending the schema

When the set of classes and attributes in the base Active Directory schema do not meet your needs, you can extend the schema by modifying or adding classes and attributes. You should only extend the schema when absolutely necessary. The easiest way to extend the schema is through the Schema Microsoft Management Console (MMC) snap-in. You should always develop and test your schema extensions in a test lab before moving them to your production network.

Before extending the schema

Before extending the schema, review these key points:

 

Check the base schema first	Verify that no existing class or attribute in the base schema meets your application or data needs. For the complete set of classes and attributes in the base schema, see the Microsoft Web site.
Review schema documentation	For detailed information about extending the schema, see the Active Directory Programmer's Guide at the Microsoft Web site and "Active Directory Schema" at the Microsoft Windows Resource Kits Web site.
Schema modifications are global	When you extend the schema, the changes apply to every domain controller in the entire forest.
Schema classes related to the system cannot be modified	You cannot modify default system classes (those classes required for Windows to run) within the schema. However, directory-enabled applications that modify the schema may add new classes that you can modify.
Schema extensions are not reversible	Attributes or classes cannot be removed after creation. At best, they can be modified or deactivated. For more information, see Deactivating a class or attribute.
Obtain valid object identifiers	Every class and attribute in the schema must have a unique and valid object identifier (also known as OID). Do not create arbitrary object identifiers or recycle old object identifiers. For information about obtaining valid object identifiers, see Schema object names.
Document your changes	If you do decide to extend the schema, be sure to document your changes.

How to extend the schema

You can modify the schema through graphical user interface (GUI) tools, command-line tools, and through scripting. The easiest way to modify the schema is by using the Active Directory Schema snap-in in Microsoft Management Console (MMC), which is a GUI tool for schema management. For information about installing the Active Directory Schema snap-in, see Install the Active Directory Schema snap-in. Modifying the schema through scripting requires programming knowledge and familiarity with the Active Directory Service Interfaces (ADSI). For more information, see the Active Directory Programmer's Guide and Extending the Schema at the Microsoft MSDN Web site.

For more information about schema administration tools, see Administration tools for the Active Directory schema.

For more information about extending the schema, see Modify an existing schema class or attribute definition and Add a new schema class or attribute definition. For information about deactivation and reactivation, see Deactivating a class or attribute, Deactivate a class or attribute and Reactivate a class or attribute.

Using a test forest

A very simple way to avoid damaging or costly schema mistakes in your production forest is to first test your schema extensions on a test forest. By using a test environment, you can identify any potential problems in your plan before they affect your users and your production environment.

After making schema changes in a test forest, you can reinstall the default schema by demoting each domain controller in the test forest to which the schema changes have replicated. Then, use the Active Directory Installation Wizard to reinstall Active Directory on the servers. This procedure is practical only in a test environment.