Structured Active Directory Schema Management at Microsoft
Creating a Consistent, Standardized Change Workflow
Technical White Paper
Published: July 2008
|
Situation
|
Solution
|
Benefits
|
Products & Technologies
|
|
Active Directory schema changes are frequent at Microsoft. Implementing a schema
change without advanced planning and testing can have unexpected consequences. Therefore,
changes require a structured workflow to ensure a consistent, smooth, and successful
process.
|
Microsoft institutionalized a schema change management process that provides a consistent,
structured workflow. The process establishes clear standards, expectations, and
timelines. The process mitigates risks and provides optimal schema change results.
|
- Reduces risk by standardizing schema changes
- Creates a structured workflow
- Enforces organizational standards
- Establishes solid expectations
- Standardizes required communications
|
- Windows Server 2003
- Windows Server 2008
- Active Directory
- Microsoft Identity Integration Server 2003 with SP1
- Microsoft Exchange Server 2007
|
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.
Note: In this paper, the concept of extending the schema refers to the process
of modifying or updating the schema.
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.
.jpg)
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
|
Value
|
Meaning
|
Description
|
|
1
|
ISO
|
Identifies the root authority
|
|
2
|
American National Standards Institute (ANSI)
|
Group designation assigned by ISO
|
|
840
|
United States
|
Country/region designation assigned by the group
|
|
113556
|
Microsoft
|
Organization designation assigned by the country/region
|
|
1
|
Active Directory
|
Assigned by the organization
|
|
5
|
Classes
|
Assigned by the organization
|
|
9
|
user class
|
Assigned by the organization
|
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
|
Inherited mandatory attribute
|
Default status
|
|
nTSecurityDescriptor
|
Defaults if not specified. The default value depends on the default security descriptor
for the classSchema class.
|
|
objectCategory
|
Defaults to the value of the default object category of the class (which is usually
the class itself). Can be changed after the class is created.
|
|
objectClass
|
No default. Administrator must specify the class.
|
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
|
OID base value
|
Description
|
|
1.2.840.113556.1.6.1.8000.999999.1
|
Application classes
The first class would have the OID 1.2.840.113556.1.8000.999999.1.1, the second
class would have the OID 1.2.840.113556.1.8000.999999.1.2, etc.
|
|
1.2.840.113556.1.6.1.8000.999999.2
|
Application attributes
The first attribute's OID would be 1.2.840.113556.1.8000.999999.2.1, the second
attribute's OID would be 1.2.840.113556.1.8000.999999.2.2, etc.
|
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.
.jpg)
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.