Creating a Consistent, Standardized Change Workflow

Technical White Paper

Published: July 2008

On This Page

Executive Summary

Introduction

Overview of the Active Directory Domain Services Environment at Microsoft

Planning

Deployment

Mitigating Risks

Microsoft IT IdM Standards

Conclusion

For More Information

Executive Summary

Active Directory® Domain Services (AD DS) provides a global identity and access management infrastructure. In addition, AD DS provides general directory functionality and extensibility that application developers can use when directory functionality is required in an application under development. Using AD DS functionality centralizes and simplifies directory administration. AD DS also reduces development costs and enhances data compatibility. For example, using AD DS authentication and authorization service interoperability within an application accomplishes two goals. It removes the requirement to create an additional security database and it simplifies enterprise security management.

To use AD DS functionality to support business processes or new tools, application developers extend the AD DS schema. Typically, a schema administrator makes schema changes independently, or the software installation process automates the changes. Institutionalizing a change management system provides optimal schema change results.

This paper shares the Microsoft Information Technology (Microsoft IT) department's approach to managing the AD DS schema change process though a structured workflow. The structured workflow helps ensure proper design, implementation, usage, ownership, and security of each change deployed in each forest. The experience of Microsoft IT shows that a robust, carefully planned change management system based on the Microsoft® Operations Framework (MOF) contributes to a highly manageable schema infrastructure. By using the MOF, Microsoft IT created a five-phase process that includes justification, assessment, testing, staging, and implementation milestones. By carefully planning and phasing schema changes, along with managing client communications and expectations, Microsoft IT handles the AD DS schema change process smoothly, minimizing risk to AD DS. Providing a consistent and predictable process enables parties to concentrate on achieving business goals.

Enterprises interested in ensuring an optimal outcome for each schema change through a structured workflow will benefit from this paper. This paper is for IT professionals, IT architects, and directory service professionals who are already familiar with the functionality of the Windows® operating system, AD DS, and identity and access management considerations. It provides an in-depth examination of the Microsoft IT schema management solution. It includes best practices, recommendations, and deployment considerations. Adopters can apply the change management design recommendations, principles, and techniques to most enterprise-scale IT environments by using Microsoft products. However, because each enterprise environment is unique, adopters should not use this paper as a procedural guide. Each organization should adapt the following information to its specific needs.

Introduction

Experienced developers of Windows-based applications use or extend the existing AD DS functionality when creating applications that require directory functionality. This includes identity and access management and central configuration, or general directory functionality. Extending or using AD DS functionality allows the application to use the existing security subsystem as well as the shared data within the global directory. Because this maximizes resource efficiency, using or extending the existing AD DS functionality is more beneficial than creating a new identity database outside AD DS.

Because of the potential AD DS impact, it is important to ensure that the schema change does not cause unanticipated results. Enterprises can execute schema changes smoothly through change planning, testing, and management of client expectations.

Schema Basics

The schema is an AD DS component that defines all the objects and attributes that the directory service uses to store data. The directory service uses objects as storage units. Each time the directory service handles data, it queries the schema for an appropriate object definition. Based on the object definition in the schema, the directory service creates the object and stores the data. For example, when a new user object is created, AD DS uses the schema definitions to create and configure the default user object. The physical structure of the schema consists of the object definitions stored in their own schema partition within the directory. The schema is replicated among all the domain controllers in the forest, and any change that is made to the schema is replicated to every domain controller in the forest.

Objects

Objects, attributes, and classes are the basic components that are used to build object definitions in the schema. Objects are structures that store both data that the objects represent and data that controls the content and structure of the objects. For example, a user account object contains a user's logon name in addition to data that specifies the proper syntax for storing the user's logon name in the user object. AD DS uses objects to store data while the data is maintained in the directory. When the directory stores an object, some associated data is stored along with the object. The extra data is stored in the attributes of the object.

Attributes

Attributes contain data that defines the information that is stored in an object or in another attribute. For example, a user account object has attributes that store user information, such as the user's first name, last name, password, office number, and telephone number.

Attributes differ depending on the type of object. Some attributes contain information that relates to other attributes, such as syntax information or flags that label the attribute as optional or required. AD DS uses syntax attributes to ensure that information is stored in a legitimate format and that the information is a valid data type.

Attributes can be required or optional. Continuing with the example of a user account object, the user name attribute is required for the user to log on. However, the office number attribute is optional because it is used to store additional information.

Single-value and Multivalue Attributes

Attributes can be single value or multivalue. A single-value attribute, such as the password attribute on a user object, can contain one value. A multivalue attribute, such as the memberOf attribute, contains multiple values.

Linked Attributes

Linked attributes enable the association of one object with another object. A linked attribute represents an interobject, distinguished-name reference. Linked attributes occur in pairs: forward link and backward link (back link). Linked attribute pairs exist on source objects and target objects. The forward link is a linked attribute on a source object (for example, the member attribute on the group object). It can be a single-value attribute or a multivalue attribute. As an option, a back link can be defined on a target object (for example, the memberOf attribute on the user object). A back-link attribute should be created as a multivalue attribute, and it cannot exist without a corresponding forward link. The back-link attribute cannot be updated directly. Instead, it is automatically calculated when it is queried, based on the corresponding forward link. A back-link value on any instance of an object consists of the distinguished names of all source objects that have the target object's distinguished name in their corresponding forward link.

System-Owned Attributes

A number of default attributes are owned by the system and cannot be modified by end users. System-owned attributes have the systemOnly flag set to TRUE. No user-defined attribute must ever have the systemOnly flag set.

Indexed Attributes

Both multivalue and single-value attributes can be indexed to help improve the performance of queries on those attributes. Indexing does not apply to classes. Attributes are marked for indexing based on their schema definition. Indexing an attribute also enables users to use wildcards (*) as prefixes and suffixes when specifying a search string. When an administrator marks 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.

Partial Attribute Set

Each global catalog server in an AD DS forest hosts a copy of every existing object in that forest. For the objects of its own domain, a global catalog server has information related to all attributes that are associated with those objects. For the objects in domains other than its own, a global catalog server has only information that is related to the set of attributes that are marked in the AD DS schema to be included in the partial attribute set (PAS).

Confidential Attributes

On domain controllers running Windows Server® 2003 with Service Pack (SP) 1 or later, attributes whose attributeSchema objects are marked with a specific search flag are interpreted as confidential. Only users who have been granted the following access can read confidential attributes:

• READ_PROPERTY
• CONTROL_ACCESS

The syntax for an attribute defines the storage representation, byte ordering, and matching rules for comparisons of property types. The syntax defines whether the attribute value must be a string, a number, or a unit of time. Each attribute of every object is associated with exactly one syntax. The syntaxes are not represented as objects in the schema, but they are programmed for AD DS to understand them. The allowable syntaxes in AD DS are predefined. New syntaxes cannot be added.

Deactivation of Attributes

An administrator cannot remove object definitions from the schema. However, an administrator can render object definitions unusable through the process of deactivation. When an object definition is deactivated, it can no longer be used to create new objects in the directory. Objects whose definitions have been deactivated in the schema are referred to as defunct. Deactivation of schema attributes is subject to the following restrictions:

• An attribute that appears in the base AD DS schema cannot be deactivated. Only schema extensions of the base schema can be deactivated.
• An attribute that is referenced in the mustContain, systemMustContain, mayContain, systemMayContain, or rdnAttId properties of an active class cannot be deactivated.

To deactivate an attribute, an administrator sets the isDefunct attribute of the itsattributeSchema object to TRUE. When an attribute is deactivated, it can no longer be added to new class definitions. To reactivate an attribute, the administrator sets the isDefunct attribute to FALSE.

Classes

Object definitions are categorized into groups that are called classes. Classes act as blueprints that can be used each time a new object is created. When a new object is created in the directory, the object's class determines the attributes that are associated with the new object, including which attributes are required and which attributes are optional. AD DS includes predefined classes that define the object types that the directory needs to function properly. For example, the default classUser class defines the required and optional attributes for user accounts.

A schema object, called a classSchema object, defines each class in the schema. Another schema object, called an attributeSchema object, defines each attribute in the schema. Therefore, every class is actually an instance of the classSchema class, and every attribute is an instance of the attributeSchema class. As shown in Figure 1, schema objects are used to define classes and attributes in the schema. Classes in the schema are used to define objects in the directory.

Figure 1. Schema class objects

Categories of Object Classes

The X.500 1993 specification requires that object classes are assigned to one of four categories:

• Structural classes. Structural classes are the only classes that can have instances in the directory. That is, directory objects whose class is one of the structural classes can be created. A structural class can be used in defining the structure of the directory and is derived from either an abstract class or another structural class. A structural class can include any number of auxiliary classes in its definition. This type of class is specified by a value of 1 in the objectClassCategory attribute.
• Abstract classes. Abstract classes are templates that are used only to derive new structural classes. Abstract classes cannot be instantiated in the directory. This means that no object can belong only to an abstract class; each object of an abstract class also belongs to some nonabstract subclass of that class. A new abstract class can be derived from an existing abstract class. This type of class is specified by a value of 2 in the objectClassCategory attribute. Classes of the abstract category have the sole function of providing attributes for subordinate classes, called subclasses. A subclass contains all mandatory and optional attributes of the class from which it is derived, called its superclass, in addition to those specific to the class itself. Likewise, the subclass of that class contains all attributes of both superclasses, and so forth.
• Auxiliary classes. Auxiliary classes are like "include" files; they contain a list of attributes. Adding the auxiliary class to the definition of a structural or abstract class adds the auxiliary class's attributes to the definition. An auxiliary class cannot be instantiated in the directory, but new auxiliary classes can be derived from existing auxiliary classes. This type of class is specified by a value of 3 in the objectClassCategory attribute. For example, the securityPrincipal class is an auxiliary class, and it derives its attributes from the parent abstract class called top. Although a security principal object cannot be created in the directory (because auxiliary classes cannot have instances), objects of the structural class user, which has the securityPrincipal class as an auxiliary class, can be created. The attributes of the securityPrincipal class contribute to making the user object recognizable to the system as a security account. Similarly, the group class has securityPrincipal as an auxiliary class.
• 88 classes. Classes defined before 1993 are not required to fall into one of the preceding categories; the X.500 1988 specification did not require assigning classes to categories. Classes that were defined prior to the X.500 1993 standards use the 88 class by default. This type of class is specified by a value of 0 in the objectClassCategory attribute. An administrator must not define new 88 classes.

Deactivation of Classes

Similar to attributes, class definitions can be deactivated. Deactivation of class attributes is subject to the following restrictions:

• A class that appears in the base AD DS schema cannot be deactivated. Only schema extensions of the base schema can be deactivated.
• A class that is referenced in the subClassOf, auxiliaryClass, or possibleSuperior properties of an active class cannot be deactivated.

To deactivate a class, an administrator sets the isDefunct attribute of its classSchema object to TRUE. When a class is deactivated, new object instances of the class can no longer be created. To reactivate a class, the administrator sets the isDefunct attribute to FALSE.

Object Identifiers

Object identifiers (OIDs) are unique numeric values that are granted by various issuing authorities to identify data elements, syntaxes, and other parts of distributed applications. OIDs are found in Open Systems Interconnection (OSI) applications, X.500 directories, Simple Network Management Protocol (SNMP), and other applications where uniqueness is important. OIDs are based on a tree structure in which a superior issuing authority, such as the International Organization for Standardization (ISO), allocates a branch of the tree to a subauthority, who in turn can allocate subbranches. The Lightweight Directory Access Protocol (LDAP) protocol (RFC 2251) requires a directory service to identify object classes, attributes, and syntaxes with OIDs. This is part of the LDAP X.500 legacy.

Because they are globally unique, OIDs ensure that the objects that these issuing authorities define do not conflict with one another when different directories, such as AD DS and Novell Directory Services, are used concurrently within a global directory namespace. OIDs in the AD DS base schema include some OIDs that the ISO issues for X.500 classes and attributes and some OIDs that Microsoft issues. Object identifiers ensure that every object is interpreted appropriately.

OID notation is a dotted string of numbers; for example, 1.2.840.113556.1.5.9. Table 1 explains the meaning of the OID notation.

Table 1. OID Notations

Schema Master Operations Master Role

AD DS performs schema updates in a single-master fashion to prevent conflicts such as those resulting from simultaneous schema updates on two different computers. The one domain controller in the forest that is allowed to perform schema updates at any specific time is called the schema master. The schema master is the domain controller that holds the schema operations master role. After the schema master completes an update, it replicates the changes to all other domain controllers by normal replication channels. In this way, changes to the schema are distributed throughout the forest.

Schema Admins Group

By default, schema changes are limited to members of the Schema Admins AD DS group. By default, the only member in the Schema Admins group is the Administrator account in the root domain of the enterprise. Other accounts must be explicitly added. Because members of this group can modify the schema, which has a forest-wide impact, an organization must apply proper security measures for this group. The organization should keep the Schema Admins group unpopulated during normal operations. It should add only trusted individuals to this group, and only when schema changes are required.

Schema Changes

Normally, users do not interact directly with the schema on a daily basis. AD DS uses the schema to help create objects that are stored in the directory. Users interact with those objects, not the schema. Administrators interact directly with the schema only when making schema changes by adding definitions or by modifying existing ones.

Schema Extensions

The default schema is a basic set of classes and attributes supplied in an AD DS forest. When the existing class and attribute definitions in the schema do not meet the needs of an organization, the organization can add or modify schema objects to extend the schema. Experienced developers and administrators can extend the schema by defining new classes and new attributes for existing classes to store a new type of information in the directory.

Schema changes are commonly required for packaged applications or internal applications that require AD DS functionality. Packaged applications, such as Microsoft Exchange Server 2007, add new classes and attributes and modify existing classes and attributes and include an installation program that can be used to extend the schema. Internal applications that require new AD DS attributes are another common driver of schema extensions. Schema extensions for internal applications are typically performed manually through import files, such as LDAP Data Interchange Format (LDIF) files.

The "Methods to Extend the Schema" section later in this document provides more information about extending the AD DS schema.

Schema Change Scope

Extending the schema is an advanced operation that requires careful planning and testing. The schema is fundamental to both the use and operation of AD DS within a forest. Therefore, to avoid issues, enterprises must carefully consider any extensions or changes made to the system-supplied base schema. Schema changes can affect important settings such as directory database indexing, global catalog data availability, and AD DS database size and integrity. Most importantly, schema changes can affect business continuity.

In general, reversing schema changes is not possible. A developer or an administrator who is considering changes should remember three key points:

• Schema extensions are global. The schema master replicates any change to the schema to every domain controller in the forest.
• Schema classes related to the system are not modifiable. System administrators cannot modify default system classes within an AD DS schema. However, administrators can change the optional system classes that they added.
• Schema classes and attributes are not removable. After adding a new class or attribute to the schema, administrators can deactivate the class or attribute by marking it as defunct. Although administrators cannot completely remove the class or attribute, they can modify some attributes or class properties after creation. For example, if an existing object needs to change an unchangeable attribute, administrators can do this by marking the initial object as defunct and then changing the Relative Distinguished Name (RDN) of the object. This allows the creation of a new object instance with the corrected attribute value. For details, refer to "Disabling Existing Classes and Attributes" at http://msdn.microsoft.com/en-us/library/ms675903(VS.85).aspx.

Overview of the Active Directory Domain Services Environment at Microsoft

To understand the schema change process at Microsoft, it is important to understand the identity and access management infrastructure that it supports, as well as the teams that support AD DS.

Infrastructure Overview

The Microsoft identity and access management infrastructure is similar to the environments of other enterprise organizations. The infrastructure provides a collection of services that are essential to the Microsoft computing environment. AD DS is the foundation of the identity and access management infrastructure within each forest. It provides centralized identity and access management to maintain the availability and security of resources. The infrastructure also serves as a proving ground for pre-release identity and access management software that Microsoft develops.

The Microsoft identity infrastructure consists of a multiple-forest deployment. Multiple forests are required at Microsoft for several reasons. Software applications under development, such as the pre-release versions of Exchange Server, require their own forest to prevent interference with the main corporate forest during early pre-release deployments and testing. Forests also exist for security reasons when Microsoft works with outside partners through an extranet. In addition, because of the legal requirements associated with the MSNBC joint venture, MSNBC maintains a separate forest. Finally, Microsoft IT specifically creates some forests for business divisions within the company, such as the division that supports the MSN® network of Internet services.

The use of multiple forests enables Microsoft to stage schema changes through pre-production environments prior to a production implementation. In addition, the use of multiple forests requires Microsoft to have a consistent and repeatable process for the installation of schema extensions.

Schema Management Environment

Microsoft IT uses a structured approach to schema management, including roles and responsibilities.

Microsoft IT Organization

Microsoft IT is responsible for driving global operations and delivering IT services to the entire Microsoft organization. Microsoft IT directs all activities related to running and maintaining information systems worldwide. It maintains the technology infrastructure in addition to the corporate and marketing information systems. This includes production, distribution, and other key internal systems. Microsoft IT works to provide world-class utility and business operation excellence. It does this through leadership in the design and integration of the company's strategies, processes, and architecture.

Microsoft IT provides a full range of services, including server and end-user support, telecommunications management, network operations, and information security. This role includes managing connectivity for more than 300,000 personal computers worldwide. Microsoft IT ensures that more than 63,000 personnel and 35,000 contractors and vendors in 90 countries, and in more than 400 Microsoft locations, can access corporate network services and resources 24 hours a day, seven days a week.

Because the primary business of Microsoft is software design, Microsoft IT has a second mission that is unique among global providers. Microsoft IT is an early adopter of the company's technologies and is responsible for testing and deploying Microsoft products such as Microsoft Office SharePoint® Server 2007, Windows Server 2008, Microsoft Identity Integration Server (MIIS) 2003, and Exchange Server 2007, before releasing to customers. Within Microsoft, this pre-release deployment process is called "eating our own dog food" or simply "dogfooding."

By using pre-release products in the Microsoft enterprise environment, Microsoft IT thoroughly field tests the products and assesses their business value. This helps to shape final product configurations and identifies best practices to guide customer product deployments. The rigorous enterprise testing environment of dogfooding provides Microsoft with the confidence of releasing high-quality products. From the lessons learned during the process, the product groups can improve the product designs and add value to the final versions.

Identity Management Team

The Identity Management (IdM) team within Microsoft IT manages the Microsoft identity and access management infrastructure. The team manages all related applications or tools, accounts and groups, and the workflow for making additions or changes.

The IdM team is responsible for the following data management and service management areas:

• All user accounts, including normal users, elevated access users, service accounts, and built-in accounts
• Group accounts, including the administrative groups, and related internal applications
• Organizational units
• Group Policy objects
• Trusts
• Inter-forest synchronization by using MIIS 2003 with SP1 to synchronize various object types, including users and groups, sites and subnets, and printer queues
• AD DS schema management

Because the IdM team owns the content of the directory, it manages data in directories as a single logical instance. To maintain cross-forest consistency, when the IdM team changes the schema in one forest, it generally changes it in all the other forests. Although the IdM team leads the schema change process, it does not manage all aspects of the process. For example, it does not physically manage domain controllers, replication topology, or applications. The Infrastructure Engineering (IEng) team and the specific application owners handle these aspects.

Infrastructure Engineering Team

The IEng team within Microsoft IT is responsible for Microsoft IT's core infrastructure servers, which include the domain controllers where AD DS resides. The responsibilities of the IEng team include:

• Server performance, administration, and configuration
• The placement of domain controllers on the network based on application dependencies and network connectivity
• Data replication topology

The IEng team's involvement in the schema change process stems from the responsibilities in the data replication topology. The IEng team collaborates with the IdM team to help ensure the successful replication of schema changes throughout each forest that it manages.

Microsoft Schema Management

Software development is the primary contributor to the volume of schema changes at Microsoft. Each time a business unit installs or updates software that uses AD DS functionality and modifies schema, the unit must go through the schema management process. Microsoft IT supports each product group's development efforts by installing multiple interim builds during the development process. Dogfooding further complicates schema management and can increase the number of schema changes.

The IdM team devised an internal Web site that guides anyone requesting a schema change through the process. The site provides an overview of the process, links to related information, and an online schema change form. The requester fills out the form that the IdM team reviews. The IdM team assesses the business justifications after it has determined that the requester properly filled out the form and all issues are resolved. If the form is acceptable from a business perspective, the IdM team puts the request into the change queue. After approving the request form, it creates a schema package document. The schema package is a living document that follows the change from start to finish. The IdM team enters all additional data and approvals with each step of the process. When the IdM team makes changes to the schema, the IEng team follows the replication through the forests and ensures accuracy. Finally, the IdM team puts the form, scripts, and all related information in a folder and stores it in a secure location for backup.

The IdM schema management system handles:

• Extensions. At Microsoft, the most common schema change is an extension. Of the three schema management options, an extension is easier and poses less potential impact. Adding new definitions rather than changing existing definitions negates the possibility of affecting existing applications.
• Modifications. Schema modifications are much less common than extensions. If an existing object is changed, this can adversely affect the applications depend on that object. Therefore, the IdM team carefully examines any changes to existing schema objects and proceeds only if it thoroughly understands the consequences. Furthermore, Microsoft does not consider any attributes provided by Windows Server to be unused because they all have a purpose. Therefore, modifying unused definitions applies only to custom attributes.
• Deactivations. Microsoft IT rarely disables unused definitions. Instead, when it no longer needs attribute or object data, Microsoft IT deletes the attribute values or object instances. This is because unused schema objects do not consume significant resources. In fact, Microsoft specifically designed AD DS to contain sparse data. Furthermore, schema administrators cannot deactivate default Windows schema objects. They can deactivate only custom schema objects.

Planning

Proper planning is fundamental for schema management. Planning for schema management includes determining when to extend the schema, selecting the method to use to extend the schema, and planning the addition and change of attributes and classes.

When to Extend the Schema

With careful schema change planning in addition to client communications and expectation management, administrators can handle the AD DS schema change process smoothly with minimal risk to AD DS. Because schema changes are global changes that cannot be reversed, designing a schema change process is imperative when an organization is designing the schema. A properly designed schema change process will aid in mitigating the impact of a problematic schema change. Every request for a schema change must be examined carefully.

If the schema change is required for an enterprise-wide application, such as Exchange Server, the schema change is usually warranted. However, if the schema change is required for an application that a small population of the organization will use, an organization should determine whether deploying a global change to satisfy the needs of this small population of the organization is warranted. As previously mentioned, schema changes are global, so schema changes that are required for a non-enterprise-wide product will still require a global change that is not reversible. Additionally, schema changes that are required for a subset of users in the organization are typically required on a short-term basis. The organization should analyze whether the schema change is a long-term or short-term requirement. Modifying the schema for a short-term requirement is not ideal because the schema change cannot be reversed when the requirement no longer exists. Although schema attributes can be deactivated later, attributes still consume space in the schema partition, which is replicated to all domain controllers in the forest. Whenever possible, the organization should aim to limit schema changes to requirements that are enterprise wide and long term.

Active Directory Lightweight Directory Services (AD LDS) can be used as an alternative to extending the AD DS schema, especially for application-specific or short-term requirements. The AD LDS server role in Windows Server 2008, previously called Active Directory Application Mode (ADAM), is an LDAP directory service. It provides data storage and retrieval for directory-enabled applications, without the dependencies that are required for AD DS. AD LDS provides much of the same functionality as AD DS (and, in fact, is built on the same code base), but it does not require the deployment of domains or domain controllers. AD LDS directories are separate from the domain infrastructure of AD DS. As a result, they can support applications that depend on schema extensions that are not desirable in the AD DS directory—such as schema extensions that are useful to a single application or required on a short-term basis.

Methods to Extend the Schema

Administrators can perform schema extensions manually by using import files, such as LDIF files, or programmatically by using an installation program. Regardless of the method used, an administrator must use a consistent method when releasing the change into one or more pre-production environments before implementing the change into production. The recommended practice is to strictly control the schema updates. When installing schema extensions, the administrator must use a consistent installation method. The same method should be used in testing environments and in production.

Packaged applications typically include an executable file that can be used to extend the AD DS schema. The software vendor typically defines all aspects of the classes and attributes, such as LDAP display name, OID, globally unique identifier (GUID), syntax, range, whether the attribute is single value or multivalue, whether the attribute is indexed, and whether the attribute is part of the partial attribute set in the installation package.

Schema extensions for internal applications are usually performed through a combination of an LDIF import file and the LDAP Data Interchange Format Data Exchange (LDIFDE) tool. LDIF is a standard for a file format that is used in LDAP implementations. The LDIFDE tool can be used to import and export Active Directory objects via LDIF-formatted files. LDIFDE is especially useful for performing schema extensions. LDIFDE can be used to ensure that custom schema changes are released in a consistent manner through an organization's pre-production and production environments. Additionally, the use of LDIFDE can reduce or eliminate human error when an administrator is modifying the AD DS schema.

Planning the Addition and Change of Attributes and Classes

Because of the complexity of the AD DS schema, an organization should consider several factors when adding and changing attributes and classes.

Single-Value and Multivalue Attributes

Single-value and multivalue attributes are defined by the singleValued attribute being set to TRUE or FALSE. All values that are defined for a multivalue attribute must have a uniform syntax. Multivalue attributes that are not linked can store a maximum of 1,300 entries. This limit is based on the size and type of the values that are stored. Multivalue attributes hold a set of values with no particular order. There is no guarantee that multivalue properties are ever going to be returned in the order in which they were stored (or any other order).

Indexed Attributes

Attributes may be indexed. Indexing an attribute can improve the performance of queries for that attribute. An attributes is indexed when the searchFlags attribute in the attribute's schema definition has the least significant bit set to 1. Setting the least significant bit of the searchFlags attribute schema definition to 1 will dynamically build an index. Setting the least significant bit of the searchFlags attribute schema definition to 0 will cause the index for the attribute to be removed. A background thread on the domain controller will automatically build the index.

Ideally, indexed attributes should be single value with highly unique values evenly distributed across the set of instances. The less unique the values of an attribute are, the less effective the index will be. Multivalue attributes can also be indexed, but the cost to build the index for a multivalue attribute is larger in terms of storage, update, and search time. The uniqueness requirement for a multivalue property is the same as that for a single-value property—the more unique the values are, the more effective the index will be. The more indexed attributes a class has, the more time is required to create new instances of the class.

Indexes apply to attributes, not to classes. That is, when an attribute is marked as indexed, all instances of the attribute are added to the index, not just the instances that are members of a particular class.

Partial Attribute Set

Microsoft defines the PAS as the attributes that are most likely to be used for searches. These attributes are replicated to every global catalog server in an AD DS forest. The isMemberOfPartialAttributeSet attribute controls whether or not an attribute is replicated to the global catalog. If the isMemberOfPartialAttributeSet value is checked (set to TRUE), the attribute is replicated to the global catalog. If the value is not checked (set to FALSE), the attribute is not replicated to the global catalog. When an attribute is added to the global catalog, it is added to the partial copy subset (partial attribute set). This causes the global catalog to perform a full synchronization of all the read-only copies again to repopulate itself with only the partial attributes that it needs to hold. This full synchronization occurs even if the attribute property isMemberOfPartialAttributeSet is set to TRUE. Thus, the global catalog does a full synchronization only on the read-only partial copy domains and not on its own writable domain, the configuration directory partition, or the schema directory partition.

Attributes with the following characteristics are usually appropriate for storage in the global catalog:

• The attribute is globally interesting, either because the attribute is required for locating objects that can occur anywhere in the forest, or because read access to the attribute is valuable even when the full object cannot be accessed.
• The volatility of the attribute is very low. This is important, because if an attribute class is included in the global catalog, changes to every value of that attribute class throughout the enterprise forest are replicated to all global catalog servers in the enterprise.
• The size of the attribute value is small.

When deciding whether or not to place an attribute in the global catalog, an administrator should remember that increased replication and increased disk storage on global catalog servers is being traded for, potentially, faster query performance. Typically, the global catalog would be used to search for an object of interest so that selected attributes of the object can be read. If the attributes of interest are replicated to the global catalog, they can be read directly from the global catalog. Alternately, to read attributes that are not replicated to the global catalog, the administrator must take additional steps to retrieve them.

Linked Attributes

A back-link value on any object instance consists of the distinguished names (DNs) of all the objects that have a DN set in the corresponding forward link. For example, Manager and Reports are a pair of linked attributes, where Manager is the forward link and Reports is the back link. A forward link/back link pair is identified by the linkID values of two attributeSchema definitions. The linkID value of the forward link is an even, positive, nonzero value, and the linkID value of the associated back link is the forward linkID plus one. For example, the linkID for Manager is 42 and the linkID for Reports is 43.

The guidelines for defining a new pair of linked attributes are as follows:

• The linkID values must be unique among all attributeSchema objects.
• A back link must have a corresponding forward link; that is, the forward link must exist before a corresponding back-link attribute can be created.
• A back link is always a multivalue attribute. A forward link can be single value or multivalue. An administrator should use a multivalue forward link when a many-to-many relationship exists.
• The attributeSchema value of a forward link must be 2.5.5.1, 2.5.5.7, or 2.5.5.14. These values correspond to syntaxes that contain a distinguished name, such as the Object(DS-DN) syntax.
• The attributeSchema value of a back link must be 2.5.5.1, which is the Object(DS-DN) syntax.
• By convention, back-link attributes are added to the mayContain value of the top abstract class. This enables the back-link attribute to be read from objects of any class because they are not actually stored with the object, but are calculated based on the forward link values.

Beginning with Windows Server 2003, it is no longer necessary to request a linkID value from Microsoft; a process exists for automatically generating a linkID value. The system will automatically generate a link ID for a new linked attribute when the attribute's linkID attribute is set to 1.2.840.113556.1.2.50. An administrator creates a back link for this forward link by setting the linkID value to the attributeId or ldapDisplayName value of the forward link. The schema cache must be reloaded after the administrator creates the forward link and before the administrator creates the back link. Otherwise, the forward link's attributeId or ldapDisplayName value will not be found when the back link is created. The schema cache is reloaded on demand, a few minutes after a schema change is made, or when the domain controller is restarted. The administrator should create all forward links, reload the schema cache, and then create all back links.

Mandatory Attributes

The term mandatory attributes refers to object attributes for which values must be specified. If a value for a mandatory attribute is not specified, one of the following happens:

• The attribute takes on a default value.
• The object is not created until a value for the attribute is specified.

Which of the object's attributes are mandatory is determined by the class to which the object belongs. Some mandatory attributes are inherited. Because every schemaClass object belongs to a subclass called top in the class hierarchy, each schemaClass object inherits the mandatory attributes that belong to top. Table 2 lists the mandatory attributes that every object inherits from top.

Table 2. Mandatory Attributes That All Schema Class Objects Inherit

Object Identifiers

The preferred way to obtain a root OID is to request one from an ISO Name Registration Authority. This is a one-time action; when a root OID has been obtained, the OID space that it defines is the organization's, and the organization can administer it. There is usually a fee associated with registering an organization name and receiving a root OID.

OIDs can be obtained from Microsoft. To extend the AD DS schema successfully, an administrator can obtain a root OID from a script available at http://go.microsoft.com/fwlink/?LinkId=100725. The OIDs generated from the script are unique; they are mapped from a unique GUID.

After a base OID has been obtained, the administrator should be careful when deciding how the OIDs should be divided into categories, because these OIDs are contained in the prefix table and are part of the replication data for the domain controller. The recommendation is to create no more than two OID categories. The administrator can create subsequent OIDs for new schema classes and attributes by appending digits to the OID in the form of OID.x, where x can be any number that an organization chooses. A common schema extension generally uses the following structure. If an organization's assigned base OID was 1.2.840.113556.1.8000.999999, the organization might create categories as shown in Table 3.

Table 3. Example OID Categories

Rollback

As previously mentioned, thorough planning and testing are imperative when an organization is implementing schema changes. If a problematic schema extension that has replicated to all domain controllers in the forest needs to be rolled back, an AD DS forest recovery must be performed.

Before proceeding with a forest recovery, an organization should work with Microsoft Customer Service and Support to ensure that a forest recovery is required, to evaluate possible remedies, and to conclude that restoring the whole forest to its state before the schema extension occurred is the best way to recover. In many cases, total AD DS forest recovery should be the last option.

For more information about AD DS forest recovery, refer to Planning for Active Directory Forest Recovery at http://technet2.microsoft.com/windowsserver/en/library/c5db2957-b932-4f55-b7fd-9f1e2442fde61033.mspx?mfr=true.

Deployment

Figure 2 illustrates the process flow for the schema change deployment process.

Figure 2. Schema change deployment process

The following sections of this document describe the phase activities in detail.

Initiating Schema Changes

The schema change requester usually represents a product group that is developing a new product, a business unit, or an IT infrastructure group that wants a schema extension to support a new application. By far, the largest number of schema changes at Microsoft comes from the Exchange Server and Windows product groups. The IdM team provides valuable feedback to the product groups about their schema changes and proposed implementation options.

Schema changes for third-party applications are more difficult to implement because many applications have hidden schema change requirements. Third-party applications can extend the schema by using an .exe file, which makes extracting the changes difficult. Furthermore, the .exe file might import an LDIF file only during the installation process. This makes the LDIF file difficult to obtain for testing.

All change requests are evaluated for impact and benefit to the organization. Microsoft uses a system that uses request for change (RFC) forms so that changes are initiated in a consistent manner and the information provided for each RFC meets Microsoft change management requirements. RFC forms are kept as simple as possible while capturing sufficient information to manage risk. The RFC is continually updated throughout the process.

All schema changes start at the IdM Web site. The site is available internally to all Microsoft personnel. The instructions link to an online request form and additional information. The instructions set expectations for minimum lead-time for discovery and review. If approved by the IdM team, the minimum lead-time for testing and implementation is an additional four weeks. The team may make an exception to the seven-week timeline for schema changes that meet emergency criteria.

The request form helps the IdM team effectively set user expectations regarding the level of knowledge required to implement a schema change. For example, the requester is required to supply appropriate and unique OIDs, prior testing results, and functional testing plans. In addition, the requester must supply schema change requests in the form of an LDIF text file. The LDIF format clearly shows each change and includes its authoritative source.

If an emergency schema change is required, the business unit director must submit the request and prove that it meets certain criteria. Criteria include work stoppage, business stoppage, or security issues. The IdM team provides a recommendation to the IdM director. The IdM director must approve all emergency schemas before deployment. The process for an emergency schema change is the same as that for a standard schema change. However, an approved emergency schema change entails an expedited timeline.

After the change has been initiated through a new RFC request, technical reviews of the RFC are performed to check the technical configuration. This includes ensuring that the RFC has identified all configuration items that will be affected or that will require a change.

To eliminate needless schema changes or requests for the wrong changes, the IdM team requires the requester to provide both a business justification and a technical justification.

The business justification describes the value of the changes to the business unit. It provides the IdM team with the knowledge of why the requester wants the changes and the deadlines for when the changes must occur. For example, a product group might have a requirement to deploy an application that uses AD DS functionality into the Microsoft production environment to receive feedback before releasing it to manufacturing.

The technical justification defines specifically what the proposed schema changes are supposed to accomplish. The IdM team reviews the requested changes against the technical goal to determine whether it is obtainable and whether the solution is optimal.

Whereas a product group focuses on adding features and providing security for a product, it depends on Microsoft IT to test how the application affects a working environment. The IdM team sometimes finds significant application design issues. For example, the IdM team might find that the product group is using AD DS to capture frequently changing data. The data may change frequently enough that it is likely to change again before it has replicated throughout the forest. Because of this, invalid data could constantly exist on some domain controllers within the forest, negating the value of the schema change.

Classifying Schema Changes

The IdM team classifies the schema change after the RFC has been initiated.

To begin, the priority of the change must be identified. Priority levels are designed with specific time frames and support the business requirements. A typical priority ranking includes:

• Low. The change can wait until the next scheduled release.
• Medium. Because of its impact level, the change cannot wait until the next scheduled release.
• High. The change needs to be released as soon as it is complete and has been tested.
• Emergency. The change needs to be released as soon as possible; many of the approval and the development steps are abbreviated.

A change manager manages the activities of the change management process for the Microsoft IT organization. The change manager ensures that changes are made with the least amount of risk and impact to the organization. The change manager and RFC initiator might need to negotiate the priority if they do not agree about it. If too many emergency and high-priority changes exist, the reasons for the volume are reviewed. This may indicate that staff members are avoiding the process or that the process is not effective.

Next, the category of the change is identified. Categories take into account the resource requirements for the change, the impact to the business of doing or not doing the change, organizational experience with the change, and new technology or processes. Typical categories include:

• Standard change. This category is low risk because it has a set release path that has been proven to be successful, it has minimal business impact, and it has a known set of release procedures.
• Minor change. This category affects a small percentage of users and resources. Also, the risk of an outage is less because of the organization's experience in implementing this type of change.
• Significant change. This category has a moderate effect on users, resources, and the business. It might involve downtime of services and might involve a situation in which the organization has less experience with the product, the infrastructure, or the customer involved in the change.
• Major change. With a high risk and high cost, this category involves the greatest potential impact on users and resources. It might also affect a business-critical system and might involve downtime of the service.
• Emergency change. This category is high risk because of the urgency of release and the minimal time in which to test it. Whether the change will succeed is relatively uncertain, and the business will experience a big impact if the change fails. This type of change is often a result of an urgent incident. These changes are escalated to an emergency committee for fast-track approval.
• Unauthorized change. This level involves changes that occur outside the agreed-to change management policies or that are specifically forbidden.

Schema changes typically fall into the significant change or major change category.

Approving and Scheduling Schema Changes

After the change has been classified, the change request must be approved and scheduled. Approval of a change is driven by its category. Approval for a significant or major change usually begins when the change is presented to the appropriate approving body—a team of reviewers typically known as the change advisory board (CAB). The CAB is a cross-functional team set up to evaluate all Microsoft IT change requests for business needs, priority, cost versus benefit, and potential impact to other systems or processes. In general, the CAB will make recommendations for implementation, further analysis, deferment, or cancellation. The CAB represents many perspectives and is accountable for the results of the change. It is a Microsoft IT function that was set up in accordance with the MOF, and it is separate from the IdM team.

Emergency changes are normally reviewed by an emergency committee of the CAB for fast-track approval. The CAB determines whether the change should:

• Be approved and scheduled.
• Be refused and ended.
• Be returned to earlier processes.

An organization's IT governance process usually determines the correct approving body. Approving bodies should have some members that participate in change approvals on an ongoing basis. These standing members should be well versed in weighing the broader implications of making changes. In addition to standing members, the approving body should include personnel and experts who are from parts of the organization affected by the change or who can add value to the discussion of the change. These additional members are chosen on a case-by-case basis.

Understanding the potential impact of change is fundamental when an organization is making approval decisions. The input for the approval process includes:

• Previously determined risk tolerance
• The category of the change—standard, minor, significant, major, or emergency—which summarizes the complexity and resources required, including people, money, and time.
• The potential impact of the change on the organization's configuration and users, including service downtime.

This information helps in the identification and selection of appropriate reviewers with sufficient knowledge and authority to make a decision.

After the change has been routed to the correct approving body, the impact of the change must be analyzed and the reviewers must be identified. It is important for an organization to identify the proper reviewers.

In the case of schema changes, the IdM team is selected as reviewers. After the IdM team understands and agrees with the business and technical justifications, it thoroughly reviews the LDIF file. The team looks for errors, analyzes the design, and then provides feedback to the author of the change. If issues exist, this feedback loop helps the author to optimize the solution and redesign the request to be accepted.

When reviewing a schema file, the reviewer will:

• Note the new attributes and object classes that the schema change requires to assist in testing.
• Review default security descriptor changes for excessive permissions and delegation.
• Look for objects that add to the system workload, such as the indexed attribute, a PAS rebuild, or a security descriptor propagator (SDProp).
• Assess the range of potential changes and ensure that they all comply with AD DS schema best practices in addition to IdM standards.
• Check each OID (at http://asn1.elibel.tm.fr/oid/index.htm) to ensure that it is unique and registered.
• Check the schema elements to ensure that proper definitions, consistent values, and meaningful descriptions exist.
• Check for consistent naming conventions that comply with Microsoft standards. For more information, refer to "Naming Attributes and Classes" at http://msdn.microsoft.com/library/default.asp?url=/library/en-us/ad/ad/naming_attributes_and_classes.asp.

After the IdM team reviews the change request and tests the implementation, it either approves or denies deployment. If the team approves the change request, it notifies the CAB and moves the change request to functional testing. If the team denies the change request, it returns the request to the requester with a detailed explanation of the denial.

Next, the change is ready to be approved, rejected, or set to require additional information. During this stage, an organization should:

• Implement all approved requests on a timely basis.
• Keep the business case and impact analysis close in time to the approval of a change to help ensure that the change is still relevant and the right thing to do.
• Retain minutes of the change approval meetings as part of the documentation of the process and participants.
• Keep identified contingencies as simple and direct as possible to minimize additional judgments or interpretations of the RFC.

The IT environment is extremely complex and contains many interdependencies, often on a global scale. The CAB determines the effects of the changes on interdependent systems and departments, and it coordinates the changes between departments. It coordinates the changes by using the Microsoft IT change management system concurrently with the schema management system. The CAB reviews the change request to determine:

• Authorization. The parties must have the authority to make the changes.
• Interdependencies. The changes might affect many different groups and their service level agreements (SLAs).
• Conflicts. Because it understands Microsoft IT in the context of the larger Microsoft organization, the CAB can determine whether it needs to modify any changes and the timing of those changes to prevent conflicts.

After reviewing the change request, the CAB either approves the change request or returns it with change recommendations. If the change request is approved, the CAB adds it to the general change management system for a ticket number and notifies all interdependent groups by e-mail. The notification enables these groups to take the necessary steps to avoid conflicts and coordinate the changes.

Developing and Testing Schema Changes

After a change has been approved, development and then testing of the proposed change can start.

Design the Change

The design for schema changes must demonstrate an understanding of the business requirements, the development of adequate usage scenarios, and the ability of the design to address operational or system requirements. It is also important to maintain traceability between requirements and solution features. This serves as one way to check the correctness of design and to ensure that the design meets the goals and requirements of the solution.

Identify Configuration Dependencies

After the change has been designed, the configuration dependencies must be identified. In this part of the process, the configuration items that have dependencies on or that could be affected by the proposed change need to be identified. Additionally, whether the proposed change has dependencies on other changes must be determined. In other words, does completing the proposed change require other changes to be made first?

Build and Test the Change

After the change has been designed, and the configuration dependencies have been identified, it is time to build and test the change. During this phase, the built-out change must meet the customer's specifications. Additionally, it must be determined whether the development team has prepared a development lab and issue-tracking process. Development teams should have worked with the test teams to prepare a test specification. The change must be tested in pre-production environments through a consistent process. User acceptance testing must be performed in the pre-production environments as part of the testing.

If the LDIF file loads well in the laboratory environment, the next step is to start the first pilot. The pilot enables the requester to perform functional testing as described in the functional test plan. The IdM team typically uses the Windows development forest to launch the first pilot. This limited production forest includes users who use this environment to facilitate dogfooding. The requester is usually given a week to test the functionality and determine whether the schema changes have worked as expected. If the requesters have an additional forest to test in, the IdM team will provide the opportunity for a second pilot. At the end of each pilot phase, the requester confirms the successful completion of the functional testing. The requester might attempt to make small change refinements during functional testing to fix minor issues. However, if the requester finds any major issues, the process will stop and the requester will be required to rework the schema changes.

An organization should adhere to the following best practices during the build and test phase:

• Resolve all known issues, whether the resolutions are fixes or deferrals.
• Define and communicate standards for issue priority and severity to all team members, including development, test, and user experience.
• Deliver the issue database to training and support staff so that they can have a deeper insight into the history of the solution and the problems found in development.
• Schedule regular meetings with those responsible for development and testing to review issues and plan strategies for resolving them.

Review Change Readiness

After the change has been built and tested, it is time to review the readiness of the change for release. Some key considerations during this phase of the process include:

• Is there business alignment, and are priorities understood?
• Is there clear ownership of all activities and actions?
• Has the appropriate management signed off on all plans?
• Have required communications with all affected groups occurred?
• Do the users and owners of dependent services know that this change is scheduled and what the impact will be to them?
• Are the functional users ready and committed to the new processes?
• Is the testing complete?
• Are operations and support teams ready for the release?

A release manager is responsible for managing and coordinating the activities of the release management process for the Microsoft IT organization. The release manager receives the appropriate status reports. Additionally, the release manager provides feedback and acknowledgements to those who have supported the release.

Releasing Schema Changes

Before the change is released, the release plan, solution deliverables, and solution documentation are examined. This assists in determining whether the change is stable enough to release into production. The release strategy that was developed early in the project must be followed to ensure the release into production is consistent with the pre-production releases. At this point, the change is released into production.

The IdM team then proceeds with its schema change deployment schedule. The date and time that the changes are deployed depends on timeline requirements, the scale of the changes, replication impact, and the existing workload for both the IdM and IEng teams. With proper testing, the IdM team will load small changes consecutively on the same day, but it will load significant schema changes in isolation if possible. The IdM team reserves Friday evenings (Pacific Time) for schema changes to ensure that replication will finish and the AD DS load will return to normal prior to Monday morning in Asia. The IEng team monitors the replication process.

By scripting the process, the IdM team can apply the same changes to each forest without manual manipulation. It applies the changes to each forest consecutively for all schema extensions. To confirm the successful completion of the change process, the IdM team compares the number of successful changes provided at the bottom of the log file to subsequent changes in other forests. If they do not match, the IdM team reviews the log records. If significant errors occur that affect AD DS stability, the IdM team might need to work with the IEng team to initiate a recovery plan.

After successfully completing the deployment, the IdM team compresses the script, LDIF file, and log file for each forest, in addition to the error file if it exists. Then, the team adds the records to the change history file for all schema changes.

Validating and Reviewing Schema Changes

After the IdM team has successfully released the change into the production environment, the next important process is to validate the release and then review it. The goal of validation is to verify that the change has actually been released as expected. The goal of reviewing the change—typically called a post-implementation review (PIR)—is to determine whether the change has had the desired effect and has met the requirements from the original RFC. Determining whether the released change has been effective and has achieved the desired results requires monitoring the change in the production environment.

After the IdM team deploys the changes to the targeted forests, the IEng team monitors the replication process to ensure that there are no issues replicating the schema throughout each forest. The IEng team is also responsible for recovery if there was a serious issue. When the schema changes have replicated throughout each forest and the IEng team is satisfied with the results, it sends a final e-mail message to everyone involved that confirms the successful replication of the schema change.

After the release of the change has been validated, the PIR can be performed. The results of the PIR should include:

• A success/failure decision on the change implementation.
• A review of how the change was released and whether it was implemented on time and on budget.
• Documentation of the lessons learned from the change process.

Validating the technical success or failure of a change includes the following:

• Did the change meet the technical requirements?
• Are all site deployments complete and stabilized?
• Have all the project team members transferred out of the project?
• Was the quiet period uneventful or were numerous incidents documented?

Validating the technical success or failure of a change includes the following:

• Did the change meet the business requirements and objectives?
• Are customers and users satisfied with the solution and its release?
• Are customers and users happy with the results?
• Have there been any unexpected side effects?

After the technical and business success has been validated, the RFC should be updated to include the results of the PIR, and then the RFC can be closed.

Mitigating Risks

To mitigate the schema change risks, an enterprise must understand the risks, determine the causes, and take steps to eliminate or minimize risk. In addition, it must prepare a contingency plan for issues that might occur.

Measuring Risk

Microsoft IT determines the risk of an adverse event by using both the impact and likelihood of an occurrence. The events that can generate the most damaging impact, such as a system failure, are usually the first events that Microsoft IT defends against with safety measures and redundancies. This creates an inverse relationship between high-risk and high-impact events in which the most damaging events are often the most unlikely to occur. Although it is important to prepare for high-impact events, managing any events with a moderate occurrence risk is more productive. An organization should consider each of the risks discussed in the following sections.

Replication Impact: Low Impact, Moderate Risk

AD DS replication uses a priority system that replicates the schema changes before any data changes. This can increase the time required for the data to converge between the various domain controllers. Subsequently, large schema changes can bottleneck the data changes required by AD DS–dependant applications and affect the people who will use the data. For example, replicating a group membership change throughout the forest may take longer than the normal five-hour replication latency during a schema change. This is because the group membership replicates after the schema extension is completed.

The implementation of a significant application that uses AD DS functionality, such as Exchange Server 2007, produces a large number of schema changes that can require more than one replication cycle per hop to replicate the schema changes, depending on the forest site topology. Other attributes that can cause additional replication workload include indexed attributes, a PAS rebuild, or inherited security descriptors (SDProp). Sometimes, these changes are required to achieve certain system functionality and administrators cannot avoid them, but a well-designed implementation can minimize any negative effects.

Application Failure: Moderate Impact, Moderate Risk

AD DS provides certain application functionality within the forest, including security and access to the global catalog. In addition, applications that extend the AD DS schema have custom functionality that is dependent on their access to AD DS and its extensions. The schema extensions provide the definitions that the applications use to create the objects that they need in order to function. Losing access to AD DS can cause the application to lose specific functionality or to fail completely.

A poorly designed schema change can invalidate existing elements that are required by the dependent application that is causing the issues. In addition, a poorly implemented schema extension might provide only a partial change and cause application errors, or prohibit a new application to function fully.

System Failure: High Impact, Low Risk

AD DS manages network resource access as well as functionality to applications that use AD DS functionality. Therefore, if AD DS becomes unavailable, users within the forest will lose access to these resources and to certain application functionality. However, for AD DS to become unavailable, all domain controllers in the domain must fail. Failure of a single domain controller does not affect AD DS for the entire forest. This is a low-risk event because domain controller failures are uncommon.

Either hardware or software failures can cause domain controller failures. The resolution for a domain controller failure is to resolve the hardware failure or reinstall the software. Domain controller failures do not imply AD DS failures when administrators deploy multiple domain controllers to provide redundancy. However, if the schema master fails during a schema change, administrators should be careful when bringing the server back online to ensure a consistent state.

Replicated AD DS corruption caused by data failures is also very uncommon. The resolution for replicated AD DS corruption is to implement a disaster recovery plan.

Managing Risk

The two main causes of significant schema change issues are poor design and poor implementation. Design issues can increase replication latency or domain controller system load and cause application incompatibility or outages. Implementation issues can include partial implementations that impede functionality or poor timing that pushes replication latency beyond typical thresholds. Replication latency can affect latency-sensitive applications. Therefore, to minimize or eliminate risk, it is important to manage schema change design and implementation. To accomplish this, the IdM team has exclusive authority to make all schema changes within Microsoft IT– managed forests.

Managing Design Risk

The IdM schema management system requires schema change requesters to follow the specific guidelines for change approval. The change management system manages design risk by performing the following functions:

• Documentation management. Poor documentation can lead to implementation challenges. To eliminate this issue, requesters must submit standardized documentation before a review begins.
• Design analysis. The IdM team analyzes schema designs based on IdM standards and returns poorly designed change requests to the author with comments and suggestions. The IdM team postpones questionably designed schema changes until it can review the reworked technical details.
• Standard establishment. The IdM team enforces a set of high standards and best practices that define an acceptable schema change. These standards minimize the conflict risk with existing schema objects. They spotlight the use of attributes that cause replication workload spikes.
• Third-party vendor accountability. Vendors do not always provide LDIF files or the schema security descriptors for design or security evaluation. Due to compliance issues, administrators should thoroughly review third-party schema security descriptors, and acquire and validate documented schema changes.

Managing Implementation Risk

After the schema change has been accepted and designed, implementation and functional testing begins. The procedures include:

• Process scripting. The IdM team uses a standard script to implement the LDIF file to all forests, ensuring that they use correct and consistent parameters across the enterprise. This eliminates common human errors during the implementation process that can cause partial schema changes.
• Implementation testing. By testing the LDIF file implementation in a laboratory environment, administrators can discover and correct errors and conflicts before deploying the file to a production environment.
• Functional testing. By piloting the schema changes in a limited environment, the requester can determine the application functionality. The result of the pilot determines whether the IdM team will implement the schema changes. This eliminates the risk of implementing a poorly functioning schema design.
• Implementation standards. The IdM team has developed implementation standards and best practices that minimize risk. They include:
  • Direct schema master implementation. The IdM team uses Terminal Services to implement schema changes locally on the schema master so that the implementation is not susceptible to workstation issues or network connectivity issues. This eliminates the risk of implementing partial schema changes that these issues generate.
  • Replication impact consideration. The IdM team generally implements schema changes during a window to minimize any impact on other replication traffic.
  • Successful replication verification. The IEng team verifies the successful replication of the schema change throughout the forest. This reduces the chance of unexpected application behavior occurring in a production environment when the schema change has not fully replicated.

Planning Disaster Recovery

There are times that schema changes result in issues that are not easy to fix. The preferred recovery method is to modify the schema. However, modifying the schema is not always a practical choice. In these cases, an administrator must restore the domain or forest. The IEng team is responsible for disaster recovery.

An enterprise must perform regular backups of critical volumes, validate that the backups are successful, and periodically exercise the restore process. The IEng team exercises the restore process regularly by performing a monthly non-authoritative restore to test the process and an authoritative restore every three to four months to assist users who have lost data. In the case of a schema change, a forest restore is required. This is an extended version of the backup and restore scenario. The IEng team performs an annual forest restore in the lab to test the process.

There are several changes to backup and restore in Windows Server 2008. For more information, refer to Step-by-Step Guide for Windows Server 2008 AD DS Backup and Recovery at http://technet2.microsoft.com/windowsserver2008/en/library/778ff4c7-623d-4475-ba70-4453f964d4911033.mspx?mfr=true.

Microsoft IT IdM Standards

The IdM team requires adherence to the following standards for all schema changes. These standards ensure that the schema change process is consistent and provides optimal results.

Schema Design

The following are Microsoft IT schema design standards:

• All schema elements require a valid OID.
• Recommended naming conventions must be observed.
• Administrators should index only elements that are unique and widely populated.
• Additions to the partial attribute set are made only when required.
• The owner of a custom property set must approve any changes to that set.
• A single object within AD DS should not be greater than 1 megabyte (MB).

Schema Ownership

The following are Microsoft IT schema ownership standards:

• Owners of schema elements must be full-time employees.
• For internally developed applications, each schema element's ownership must be defined prior to implementation of the extension.
• Owners must notify the IdM team about unused schema elements and must make them defunct.

Schema Implementation and Usage

The following are Microsoft IT implementation and usage standards:

• Schema elements with identical purposes must not exist.
• All schema changes must be made through an LDIF script. Where third-party products use executable files or an installation wrapper, an LDIF file must be made available for examination, manual installation, or both.
• All LDIF files must be archived for future reference.
• Only the IdM team will implement changes to the schema for any Microsoft IT– managed forest.
• The level of testing that a proposed schema extension has undergone must be documented.
• An implementation procedure must be provided to implement any schema change that uses an LDIF script, program executable file, installation wrapper, and so on.

Schema Security

The IdM team pays very close attention when changing the default security descriptor for schema elements, because it affects network security.

Multiple-Forest Staging

Efforts to be consistent must be practical as well. IdM stages schema changes in different forests to verify implementation methods, identify any compatibility conflicts, and ensure consistency among the forests.

Conclusion

An organization should institutionalize a consistent AD DS schema change process that includes justification, assessment, testing, staging, and implementation milestones. It should also integrate the schema change process with the existing change management system to mitigate conflicts and risks.

Microsoft IT gave a specific group the authority to handle all schema changes and to enforce standards. The standards are explicitly defined and enforceable.

Schema changes require active management and might require cooperation between several stakeholder teams. The Microsoft schema change process assigns responsibilities, and it provides checks and balances between the parties. Following a standard step-by-step process eliminates confusion and fulfills all requirements.

By establishing the schema change process, Microsoft IT normalized schema changes by using a structured workflow that enforces organizational standards and establishes solid expectations. Now, the workflow eliminates schema change issues early in the process, and it provides clear responsibilities for each party involved. This enhances collaboration between all parties involved and enables timely, optimized results.

For More Information

For more information about Microsoft products or services, call the Microsoft Sales Information Center at (800) 426-9400. In Canada, call the Microsoft Canada Information Centre at (800) 563-9048. Outside the 50 United States and Canada, please contact your local Microsoft subsidiary. To access information through the World Wide Web, go to:

http://www.microsoft.com

http://www.microsoft.com/technet/itshowcase

For more information about the MOF, go to:

http://www.microsoft.com/mof

For more information about the MOF change management process, go to:

http://www.microsoft.com/technet/itsolutions/cits/mo/smf/smfchgmg.mspx#EGAA

The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft and Microsoft cannot guarantee the accuracy of any information presented after the date of publication.

This White Paper is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED, OR STATUTORY, AS TO THE INFORMATION IN THIS DOCUMENT.

Complying with all applicable copyright laws is the responsibility of the user. Microsoft grants you the right to reproduce this White Paper, in whole or in part, specifically and solely for the purpose of personal education.

Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property.

Unless otherwise noted, the example companies, organizations, products, domain names, e-mail addresses, logos, people, places, and events depicted herein are fictitious, and no association with any real company, organization, product, domain name, e-mail address, logo, person, place, or event is intended or should be inferred.

© 2008 Microsoft Corporation. All rights reserved.

This document is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS SUMMARY. Microsoft, Active Directory, MSN, SharePoint, Windows, and Windows Server are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries. The names of actual companies and products mentioned herein may be the trademarks of their respective owners.