Tài liệu Module 4: Designing a Schema Policy docx

Contents
Overview 1
Identifying Business Needs 2
Schema Fundamentals 3
Implications of Modifying the Schema 9
Planning for Schema Modification 11
Lab A: Modifying the Schema 20
Review 27

Module 4: Designing a
Schema Policy


Information in this document is subject to change without notice. The names of companies,
products, people, characters, and/or data mentioned herein are fictitious and are in no way intended
to represent any real individual, company, product, or event, unless otherwise noted. Complying
with all applicable copyright laws is the responsibility of the user. No part of this document may
be reproduced or transmitted in any form or by any means, electronic or mechanical, for any
purpose, without the express written permission of Microsoft Corporation. If, however, your only
means of access is electronic, permission to print one copy is hereby granted.

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.

 2000 Microsoft Corporation. All rights reserved.

Microsoft, Windows, Windows NT, Active Directory, BackOffice, PowerPoint, Visual Basic, and
Visual Studio are either registered trademarks or trademarks of Microsoft Corporation in the
U.S.A. and/or other countries.

The names of companies, products, people, characters, and/or data mentioned herein are fictitious
and are in no way intended to represent any real individual, company, product, or event, unless
otherwise noted.

Other product and company names mentioned herein may be the trademarks of their respective
owners.

Project Lead: Andy Sweet (S&T OnSite)
Instructional Designers: Andy Sweet (S&T OnSite), Ravi Acharya (NIIT), Sid Benavente,
Richard Rose, Kathleen Norton
Instructional Design Consultants: Paul Howard, Susan Greenberg
Program Managers: Lorrin Smith-Bates (Volt), Megan Camp (Independent Contractor)
Technical Contributors: Angie Fultz, Lyle Curry, Brian Komar (3947018 Manitoba, Inc.), Jim
Clark (Infotec Commercial Systems), Bill Wade (Excell Data Corporation), David Stern, Steve
Tate, Greg Bulette (Independent Contractor), Kathleen Cole (S&T OnSite)
Graphic Artist: Kirsten Larson (S&T OnSite)
Editing Manager: Lynette Skinner
Editor: Jeffrey Gilbert (Wasser)
Copy Editor: Patti Neff (S&T Consulting)
Online Program Manager: Debbi Conger
Online Publications Manager: Arlo Emerson (Aditi)
Online Support: Eric Brandt (S&T Consulting)
Multimedia Development: Kelly Renner (Entex)
Testing Leads: Sid Benavente, Keith Cotton
Testing Developer: Greg Stemp (S&T OnSite)

Compact Disc and Lab Testing: Testing Testing 123
Production Support: Ed Casper (S&T Consulting)
Manufacturing Manager: Rick Terek (S&T OnSite)
Manufacturing Support: Laura King (S&T OnSite)
Lead Product Manager, Development Services: Bo Galford
Lead Product Managers: Dean Murray, Ken Rosen
Group Product Manager: Robert Stewart

Module 4: Designing a Schema Policy iii


Instructor Notes
This module discusses modifications to the Microsoft
®
Windows
®
2000 Active
Directory
™
directory service schema. You should emphasize to students that
schema modification, while one of the most powerful features of Active
Directory, has a significant impact on the entire network.
Focus on the need to understand the implications of schema modification and
the need to develop a network-wide policy to manage schema modification.
At the end of this module, the student will be able to:
!
Identify organizational needs that require schema modification.
!
Describe schema components and fundamentals of schema modification.
!

Describe the implications that result from modifying the schema.
!
Design policies for governing schema modifications.

Lab A, Modifying the Schema, is a hands-on lab in which students will use the
Active Directory Schema snap-in to create a new object class with appropriate
attributes. Students will modify an existing object class by adding a new
attribute and modifying the behavior of an existing attribute. The students will
then verify their changes.
Materials and Preparation
This section provides you with the materials and preparation tasks that are
needed to teach this module.
Required Materials
To teach this module, you need the Microsoft PowerPoint
®
file
win1561b_04.ppt.
Preparation Tasks
To prepare for this module, you should:
!
Read all of the materials for this module.
!
Complete the lab.
!
Read the following topic located in the Distributed Systems Guide in the
Microsoft Windows 2000 Server Resource Kit:
• Active Directory Schema

Presentation:
60 Minutes

Lab:
30 Minutes
iv Module 4: Designing a Schema Policy


Instructor Setup for a Lab
This section provides setup instructions required to prepare the instructor
computer or classroom configuration for a lab.
Ensure that the schema is in write mode. No other setup is needed for this lab.
Make sure that the students are aware that when they modify the schema by
creating a new schema class object or a new schema attribute object, they will
not be able to use the class or attribute in the default Active Directory
management tools. In order to use a new class or attribute the interface itself
must be modified. You can utilize new objects and attributes by using scripts.
For more information on modifying the interface and using scripts, see the
Active Directory Programmer’s Guide
(

Module Strategy
Use the following strategy to present this module:
!
Identifying Business Needs
Describe the business situations that require changing the schema, and offer
guidelines for deciding when changes are necessary.
!
Schema Fundamentals
Explain strategies for designing a schema policy, including determining
when, how, and by whom a schema change can be performed. Describe the
basic components of a schema and explain how the schema can be modified.

Explain how object identifiers are obtained and extended in the schema.
Finally, explain how to deactivate classes and attributes in the schema.
!
Implications of Modifying the Schema
Explain how modifying the schema can affect other objects in Active
Directory, replication, and network performance.
!
Planning for Schema Modification
This topic identifies considerations for planning schema modification.
Explain the situations when a schema modification will be required. Also
explain how other factors, such as using directory enabled applications or
using software such as Exchange 2000, can affect your schema modification
plan. Finally explain the considerations for testing the schema and how to
develop a schema modification policy.
Customization Information
This section identifies the lab setup requirements for a module and the
configuration changes that occur on student computers during the labs. This
information is provided to assist you in replicating or customizing Microsoft
Official Curriculum (MOC) courseware.
The lab in this module includes a script to be run at the beginning and end of
the lab, creating and returning the computer to the default configuration for the
course. As a result, there are no lab setup requirements or configuration changes
that affect replication or customization.
Module 4: Designing a Schema Policy 1


Overview
!
Identifying Business Needs
!

Schema Fundamentals
!
Implications of Modifying the Schema
!
Planning for Schema Modification


The Microsoft
®
Windows
®
2000 Active Directory
™
directory service schema
contains the definitions of all objects, such as computers, users, and printers,
that are stored in Active Directory. The definitions contained within the schema
define the classes of objects a directory may contain, and the types of attributes
each object may or must have.
Schema modification includes adding or changing object class or attribute
definitions to fit the needs of your network. This is a powerful feature of Active
Directory that can also have a significant impact on the entire network. You
need a carefully designed policy for modifying the schema that includes
controlling when and how you implement schema modifications.
At the end of this module, you will be able to:
!
Identify business needs that require schema modification.
!
Describe the schema components and the fundamentals of schema
modification.
!

Explain how modifying the schema impacts Active Directory.
!
Create a management policy to control schema modification.

Slide Objective
To provide an overview of
the module topics and
objectives.
Lead-in
In this module, you will learn
how to plan for schema
modification when designing
an Active Directory
infrastructure.
2 Module 4: Designing a Schema Policy


Identifying Business Needs
Primary Reasons for Schema
Modification:
!
Enabling Schema to Address Business
Needs
!
Installing Directory-Enabled Applications
Schema


Because the default Active Directory schema in Windows 2000 contains
hundreds of classes and attributes, the need to change the schema is rare.

However, modification may be necessary when an organization’s business
needs are not addressed by the preexisting definitions in the schema. For
example, an organization may require Active Directory to track a unique user
attribute, such as Cost Center, not included in the schema. In this case the
schema can be modified intentionally to include the new attribute.
Organizations may also plan to use directory-enabled applications. These
applications may modify the schema as they are installed so that the
applications can fully interact with the directory.
Because a schema change impacts the entire forest, try to avoid unnecessary
schema modification. Always identify the importance of the business need, and
also determine if the need can be satisfied in a way that does not require schema
modification.
Slide Objective
To describe the primary
business needs that require
schema modification.
Lead-in
While the Active Directory
Schema contains many
preset classes and
attributes, changes to the
schema may be necessary.
Key Points
Students should carefully
consider the business needs
of the organization and the
capabilities of the schema
before planning any
modifications.
Delivery Tip

Ask the students for
examples of information an
organization may want to
include in Active Directory.
Module 4: Designing a Schema Policy 3


#
##
#

Schema Fundamentals
!
Schema Components
!
Modifying the Schema
!
Obtaining and Extending Object Identifiers
!
Deactivating Schema Components


The Active Directory schema consists of different objects, or components, that
control the classes and attributes maintained by Active Directory. Modifying
these components changes the definitions of the objects in Active Directory and
directly affects how Active Directory operates.
Active Directory schema can be changed in several different ways. You can add
or modify components within the schema, but you cannot delete unused
components. Unused schema components can only be deactivated.
Slide Objective

To introduce the basic
components of the schema,
and how the schema can be
modified.
Lead-in
Modifying the schema
means making changes to
the schema components.
Key Points
Schema components can be
added, modified, or
deactivated, but never
deleted.
4 Module 4: Designing a Schema Policy


Schema Components
Class
Class
-
-
Schema
Schema
Objects
Objects
Examples:
Examples:
Users
Users
Computers

Computers
Some possible User Class
Attributes :
Some possible User Class
Some possible User Class
Attributes :
Attributes :
accountExpires
badPasswordTime
mail
name
accountExpires
badPasswordTime
mail
name
Attribute Definition
includes
Attribute Definition
Attribute Definition
includes
includes
Object Name
Object Identifier
Syntax
Optional Range Limits
Object Name
Object Identifier
Syntax
Optional Range Limits
Class Definition includes

Class Definition includes
Class Definition includes
Object Name
Object Identifier
“May Contain” Attributes
“Must Contain” Attributes
Object Name
Object Identifier
“May Contain” Attributes
“Must Contain” Attributes
List of Attributes
List of Attributes
List of Attributes
accountExpires
badPasswordTime
mail
cAConnect
dhcpType
eFSPolicy
fromServer
governsID
Name
…
accountExpires
badPasswordTime
mail
cAConnect
dhcpType
eFSPolicy
fromServer

governsID
Name
…
Attribute
Attribute
-
-
Schema
Schema
Objects Examples:
Objects Examples:
Servers
Servers


The schema contains two types of components: class-schema objects that define
a class, and attribute-schema objects that define an attribute. These two types of
objects are defined separately from each other.
Schema modification involves changing the schema components. Modifying
the schema components should not be confused with modifying or creating
objects in Active Directory. When you create a new user in Active Directory,
you create an object, or instance, of the class User. Modifying the schema
involves creating or modifying the class or attribute definitions themselves.
Slide Objective
To describe the components
of the Active Directory
schema.
Lead-in
When you modify the
schema, you make changes

to the definitions of schema
components.
Key Point
Creating new objects and
supplying values for their
attributes is a routine
administrative task.
Modifying the schema to
create new classes or class
attributes is not routine.
Delivery Tip
Point out that attributes in
the schema frequently do
not map to the same name
in the user interface. Start
Active Directory Schema
and display the attributes of
the User class.
Module 4: Designing a Schema Policy 5


Class-Schema Objects
Classes are definitions for sets of objects that share a set of characteristics, or
attributes. For example, Users is a class in Active Directory. Every user created
has certain attributes in common with other users, such as a first and last name.
Although the value of each user is different, they each possess a first and last
name.
Each class in Active Directory has a class-schema object corresponding to it in
the schema. The class-schema object is made up of attribute-schema objects.
The class-schema object specifies which attributes can or may be used in

objects created in this class, and defines the following constraints:
!
Must-Contains. A list of mandatory attributes that must be present on any
object that is an instance of this class.
!
May-Contains. A list of optional attributes that can be found on an object
that is an instance of this class.
!
Hierarchy rules. A rule that determines the possible parents in the directory
tree of an object that is an instance of the class. For example, a user cannot
have a server as a parent object.


An object is only allowed to have an attribute that belongs to either the
must-contain or the may-contain list of the class.

Attribute-Schema Objects
Attributes are used to define objects. A sample attribute for an object of the
User class might be the user’s last name. Each user object will have this
attribute, but each will hold a different value that is specific to the user. Every
attribute has a corresponding attribute-schema object. The attribute-schema
object specifies various properties of an attribute, such as the syntax that should
be used in it and whether or not it may have multiple values. An attribute-
schema object must be defined before it can be added to a class. An attribute-
schema object will have the same properties no matter where it is applied,
although the value for each property will differ.
Syntax Rules
Syntax rules state that attributes can hold specific types of information, such as
an integer or a date-formatted value. For example, when you create a user
object, the syntax rule would be that only numeric values are acceptable for the

attribute Telephone-Number. Active Directory defines a set of attribute syntax
for specifying the type of data contained by an attribute. The predefined syntax
does not actually appear in the directory, and you cannot add new syntax.
Note
6 Module 4: Designing a Schema Policy


Modifying the Schema
!
Schema Modification Occurs When You:
$
Use the Active Directory Schema to create,
modify, or deactivate classes or attributes
$
Write scripts to automate schema modification
$
Install software applications that add classes
or attributes
!
To Control Membership of Schema Admins Group:
$
Control Membership of Local Admins, Domain Admins,
and Enterprise Admins Groups
Schema


You can modify the schema by:
!
Using the Active Directory Schema snap-in. Members of the Schema
Admins group can use the Active Directory Schema snap-in in the

Microsoft Management Console (MMC) to manage the schema by creating,
modifying, and deactivating classes and attributes.
!
Scripting. You can write a script with Active Directory Service Interfaces
(ADSI) that will create, modify, or deactivate classes and attributes. Use this
method when you want to automate schema modifications. Scripting also
requires you to review the script before running it, which reduces the chance
of typographical errors that could cause unwanted schema modifications.

For sample scripts, see the Windows 2000 Server Resource Kit
Distributed Systems Guide.

!
Installing software applications. Software applications that add classes or
attributes during the application installation process are referred to as
directory–enabled applications.

Controlling Access to the Schema Admins Group
Membership of the Schema Admins group should be carefully monitored,
because its members are the only users authorized to change the schema.
However, members of the Local Admins, Domain Admins, and Enterprise
Admins groups in the forest root domain have the authority to change the
membership of the Schema Admins group. Because these groups control
membership of the Schema Admins group, they should also be carefully
monitored. Membership of these groups can be restricted by using Group
Policy.
Slide Objective
To explain the methods by
which the schema can be
modified.

Lead-in
Before you can modify the
schema, you must know
how and when schema
modification can occur.
Key Point
Tell the students that
modifying the schema by
using Active Directory
Schema in MMC increases
the risk of making
typographical errors, while
scripting requires the user to
review the proposed
changes before they are
made.
Note
Module 4: Designing a Schema Policy 7


Obtaining and Extending Object Identifiers
!
Object Identifiers
$
Unique identifiers for class and object attributes
$
Obtained from an ISO issuing authority
$
Extend to accommodate your enterprise
!

Object Identifier Format, 1.2.840.x.w.y.z
$
1.2.840, issuing authority
$
x.w.y.z for extension


An object identifier is a unique number that identifies an object class or
attribute in a directory. Each schema object must have an object identifier. You
must obtain an object identifier prior to making any additions to the schema.
This includes new attributes and new classes.
Object identifiers are hierarchical, with the root controlled by the International
Organization for Standardization (ISO). ISO allocates a branch of the tree to
subordinate vendors, or name registration authorities. An object identifier is
expressed as a string of numbers delimited by decimal points; for example,
1.2.840.x.w.y.z. The name registration authority issues the leading digits
1.2.840. The remaining digits, x.w.y.z, are reserved for your organization to
extend as necessary.
In order to obtain an object identifier, you can either contact ANSI or ISO
() or use object identifier Gen.exe in the Windows 2000
resource kit to generate an object identifier. It is recommended that you
generate distinct object identifier trees for attributes and classes.
Slide Objective
To explain how to obtain
and extend object
identifiers.
Lead-in
Object identifiers uniquely
refer to each class and
attribute definition stored in

the Active Directory
schema.
Delivery Tip
Demonstrate how an object
identifier would look by
writing an object identifier
and replacing x with
fictitious numbers on the
whiteboard. You can
mention to students that if
they are familiar with Simple
Network Management
Protocol (SNMP), that
Active Directory objective
identifiers use the same
hierarchy.

Obtaining an OID ensures
that new objects are globally
unique.
8 Module 4: Designing a Schema Policy


Deactivating Schema Components
!
Classes and Attributes Are Not Deleted, but
Deactivated.
!
Classes and Attributes Can Be Reactivated

Classes or attributes are never actually removed from the schema, but are
deactivated. This feature prevents irreversible mistakes, because classes and
attributes can be reactivated. You can deactivate and reactivate a class or
attribute by using the Properties dialog box for that object in the Active
Directory Schema. When planning to deactivate a class or attribute, consider the
following:
!
You cannot deactivate default schema objects. You can only deactivate
objects that have been added to the schema after schema installation.
!
You cannot deactivate attributes that are in use by a Class Schema object, or
any objects of that class with values in that attribute.
!
When a class or attribute is deactivated, it is no longer replicated throughout
the network or to the global catalog server.
!
Deactivating a class does not deactivate existing objects of that class type.
However, you cannot create new objects from a deactivated class.
!
You cannot use deactivated attributes in new or existing classes.
!
Objects from deactivated classes and class attributes appear in searches. If
you no longer need objects of a certain class, you can deactivate the class,
search for objects that are instances of that class, and then delete those
objects from Active Directory.
!
You cannot create new classes or attributes that have the same common name,
object identifier, or Lightweight Directory Access Protocol (LDAP) display name
as a deactivated class or attribute.

Slide Objective
To explain how to deactivate
classes and attributes.
Lead-in
Classes and attributes are
never actually removed from
the schema.
Key Points
The schema objects that are
preloaded with Active
Directory cannot be
deactivated. Only objects
that have been added after
installation can be
deactivated.
Module 4: Designing a Schema Policy 9


Implications of Modifying the Schema
Schema Modification Can Impact:
!
Validity of Existing Objects
!
Replication Latency
!
Network Performance During Replication


Schema modification impacts your entire network. Modifications can affect

existing objects, can create replication latency, and can increase network traffic.
Possible Effects on Existing Objects
A schema update can make an existing object invalid. For example, suppose
Widgets is an instance of object class Products. Products has a May-Contain
attribute called Color. If a schema update deletes Color from the May-Contain
list of Products, Widgets will be invalid, because Widgets has an attribute that
is not in accordance with its class definition.
Active Directory allows deactivated classes and attributes to remain in the
directory to ensure that they do not cause any other schema conflicts. However,
Active Directory does not automatically remove invalid objects. Therefore, you
can search on the invalid attribute and delete it from all existing objects, but
Active Directory will not allow you to add the attribute to any new objects.
Replication Latency
Schema replication is a process separate from normal directory replication. To
avoid potential conflicts, schema modifications are performed on one domain
controller and then replicated across all domain controllers in the forest.
However, schema replication can introduce temporary inconsistencies in the
schema. It is possible that an object, or instance, of a newly created class may
be replicated to a domain controller before the new schema class arrives.
For example, assume you create a new class, Company-Vehicles, at a domain
controller. Then you create an instance of this class, Limo, at the same domain
controller. However, when the changes are replicated to another domain
controller, Limo is replicated before Company-Vehicles. The replication of the
instance will fail because the second domain controller is not yet aware of the
class Company-Vehicles.
Slide Objective
To describe the ways in
which modifying the schema
impacts Active Directory and
the network.

Lead-in
When planning schema
modifications, be aware that
these modifications can
have a significant impact on
your network and the Active
Directory structure.
10 Module 4: Designing a Schema Policy


If replication failure occurs, Active Directory automatically replicates the
schema from the schema operations master, and the schema cache is
immediately updated on the target domain controller. Active Directory then
replicates any object that failed to the target domain controller. As a result, the
Company-Vehicles class is added into the target domain controller’s schema
cache. The next replication cycle will successfully add Limo.
Network Performance During Replication
Some schema modifications can have considerable impact on network
performance. For example, if you deploy Active Directory and then decide to
mark another attribute for inclusion in the global catalog, you can make the
change quite easily in the Schema Manager. However, this change causes all
global catalogs to set their Update Sequence Numbers (USNs) to 0. As a result,
all objects (not just the changed property) in Active Directory must be
replicated to each global catalog again, which causes significant network traffic.

The administrative tools shipped with Windows 2000 Advanced Server
are designed to manage the default schema. New classes and new attributes may
not appear correctly in these tools. The Active Directory administrative tools
can be extended to manage the new schema modifications you make. See The
Active Directory Programmer’s Guide

( />) for directions.

Note
Module 4: Designing a Schema Policy 11


#
##
#

Planning for Schema Modification
!
Deciding when to Modify the Schema
!
Planning for Directory-Enabled Applications
!
Anticipating Microsoft Exchange 2000
!
Testing Schema Modifications
!
Developing a Schema Modification Policy
!
Design Guidelines


When planning for schema modification, you must first decide whether changes
are necessary. You may be able to accommodate some business needs by other
changes. However, there may be changes, such as installing a directory-enabled
application, which would require modifying the schema. Once you determine
that the schema should be modified, you should test the schema modification to

ensure its success. To manage the process of schema modification, it is best to
devise a policy for schema modification that states when and how it will be
changed, and by whom.
Planning for schema modification includes the following:
!
Deciding when to modify the schema.
!
Planning for the eventual use of directory-enabled applications.
!
Anticipating the use of Microsoft Exchange 2000.
!
Testing the schema modification.
!
Developing a schema modification policy.

Slide Objective
To identify considerations
for planning schema
modification.
Lead-in
Developing a schema
modification policy will help
you plan for schema
modification.
12 Module 4: Designing a Schema Policy


Deciding when to Modify the Schema
Situation
Situation

Situation
Suggested Solutions
Suggested Solutions
Suggested Solutions
No existing class meets needs
No existing class meets needs
Existing class needs attributes
but otherwise meets needs
Existing class needs attributes
but otherwise meets needs
Need a new set of unique
attributes, but not a new class
Need a new set of unique
attributes, but not a new class
Existing classes or attributes no
longer needed
Existing classes or attributes no
longer needed
Create a new class
Create a new class
Create new attributes, derive a new
child class, or create an auxiliary class
Create new attributes, derive a new
child class, or create an auxiliary class
Create auxiliary class
Create auxiliary class
Deactivate existing class or attribute
Deactivate existing class or attribute

Because there are more than 140 classes and more than 850 attributes in the
default schema provided with Windows 2000, you should rarely need to add or
modify classes and attributes. However, there may be situations where an
existing class or attribute does not meet your needs. The following table
describes some of these situations, and suggests solutions.
Situation Suggested solutions

No existing class meets your needs. Create a new class.
An existing class needs additional
attributes, but otherwise meets your
needs.
Create new attributes and add them to the
existing class. Alternatively, derive a new
child class from the existing class, and
then add any additional attributes you
need. Create an auxiliary, or placeholder,
class containing additional attributes and
add the auxiliary to the existing class.
You need a set of unique attributes, but
not a new class.
Create an auxiliary class that is connected
to the original class but does not need its
own distinct class. For example,
contractor employees in the Users class
can be placed into an auxiliary class of
Contractors, which holds attributes
specifically needed for that group.
Existing classes or attributes are no longer
relevant to your organization’s business.
Deactivate the existing class or attribute.

Slide Objective
To identify when to modify
the schema.
Lead-in
Be sure to carefully examine
what is already contained in
the schema before deciding
whether to modify it.
Module 4: Designing a Schema Policy 13


Not all schema objects can be modified. The following rules apply:
!
Classes and attributes defined as system cannot be modified or deactivated.
!
Modifications are subject to certain restrictions that are enforced by Active
Directory and are often determined by whether the classes or attributes are
part of the default schema or have been added after the original installation.
!
The set of valid attribute syntax that is recognized by the directory service is
also hard-coded and cannot be changed.
!
The list of mandatory attributes cannot be modified after a class has been
created.


For more information about what can and cannot be modified in the
schema, see the Windows 2000 Resource Kit.

Note
14 Module 4: Designing a Schema Policy


Planning for Directory-Enabled Applications
!
Directory-Enabled Applications Modify the Schema in
Two Phases:
1. Schema Admins Perform the Schema Components
Phase of the Install
2. Any Authorized Individual Can Complete the Install


Directory-enabled applications integrate with Active Directory as they operate,
allowing organizations to combine services in an effort to reduce total cost of
ownership and network overhead. Directory-enabled applications require
special considerations when planning for their use, as these types of
applications will likely modify the schema as they are installed. When
designing an application installation routine that must modify the schema, the
installation routine should be in two distinct phases, as described in the
following:
!
Phase one modifies the schema. Only members of the Schema Admins
group will be allowed to run the part of installation that modifies the
schema. Write-access must be enabled for this phase of the install.
!
Phase two verifies that the schema modifications have successfully taken
place, and then the traditional application installation proceeds. Anyone who
has been assigned appropriate permissions can run this part of the
installation.

You should test any application before installing it on a network, but testing is
especially important for applications that will modify the schema.
Slide Objective
To explain the two phases
of directory-enabled
applications.
Lead-in
Directory-enabled
applications modify the
schema as they are
installed.
Module 4: Designing a Schema Policy 15


Anticipating Exchange 2000
!
Integration of Exchange 2000 and Active Directory
Improves Performance
$
Separate Databases No Longer Necessary
!
Initial Configuration of Exchange 2000 May Take Extra
Time to Complete
$
LDIF Files Replicated
$
Global Catalog Replication


Exchange 2000 is fully integrated with Active Directory. With the advent of

Active Directory in Windows 2000, the directory database that the operating
system provides is now capable of holding all user account details, security
information, and messaging data. This means that a separate directory is not
necessary for Exchange 2000 data.
The integration of Exchange and Active Directory will increase performance,
but the initial configuration may take an extended amount of time. This is
because:
!
Many LDAP Directory Interface Format files, also known as LDIF files, are
imported as part of the installation process for the first Exchange 2000
server in Active Directory.
!
Any additional attributes tagged for global catalog replication will cause all
objects (not just the changed property) in Active Directory to replicate to
each global catalog again. This can cause significant network traffic.
Because the installation of Exchange 2000 tags attributes for replication to
the global catalog, it will also have the same impact on Active Directory.

For organizations planning to deploy Active Directory and install
Exchange 2000 servers at a future date, it is best to import the Exchange-
specific schema changes as soon as possible before Active Directory becomes
too large.
Slide Objective
To describe the implications
of using Exchange 2000
with Active Directory.
Lead-in
Exchange 2000 is fully
integrated with Active
Directory.

16 Module 4: Designing a Schema Policy


Testing Schema Changes
!
When Testing Schema Modifications, Always:
$
Test Changes in a Non-Production Environment
$
Use Thoroughly Tested Scripts
$
Remember that Objects and Attributes Can Only Be
Deactivated


You should always test schema modifications, as well as any other substantial
changes to your network. Before developing and testing a schema modification,
be sure to remove the schema operations master from the network or set up an
isolated test network. If the domain controller is not connected to your primary
network, you can test and troubleshoot any problems you may encounter before
schema updates are replicated to all of the other domain controllers in the
forest.
When testing schema modifications, remember the following:
!
Always test schema modifications in a test environment that is not part of
your forest.
!
Use thoroughly tested scripts whenever possible to avoid typographical
errors when the modifications are applied to a production environment.
!

Attributes and classes added to your schema can only be deactivated, never
deleted.

Slide Objective
To identify primary
considerations for testing
schema modifications.
Lead-in
Testing a schema change is
a critical step in the
modification process. You
must test any changes
before implementing them in
a production environment.
Module 4: Designing a Schema Policy 17


Developing a Schema Modification Policy
!
Creating an Experienced Committee
Responsible for Schema Modification
!
Establishing Modification Guidelines
$
Initiating Schema Modifications
$
Testing Schema Modifications
$
Performing Schema Modifications
Schema

Modification
Committee
Schema
Modification
Committee


Always thoroughly plan and prepare before making schema modifications.
Inconsistencies in the schema can cause significant problems that impair or
disable Active Directory network-wide. These problems might or might not be
evident immediately.
Creating a Schema Modification Committee
It may be desirable to appoint a committee of individuals who have expertise
with directory services to take full responsibility for all schema changes. They
should have a thorough understanding of how the schema works, the effects of
schema modification, and how to avoid potential problems.
Slide Objective
To describe how to develop
a schema modification
policy.
Lead-in
A schema modification
policy will ensure that you
make only appropriate
changes to your schema.
18 Module 4: Designing a Schema Policy


Establishing Modification Guidelines
At minimum, your schema modification policy should include guidelines for

the following:
!
Initiating schema modifications, including:
• Submitting schema change requests to an approving committee.
• Verifying the critical need for the changes.
• Identifying the impact on existing objects, network traffic, and the
process of creating new objects.
• Obtaining a valid object identifier.
• Receiving approval of requested changes from the committee.
!
Testing schema modifications, including:
• Testing the proposed change in a test environment separate from the
production environment, or disconnecting the schema master from the
network if there is no test environment.
• Ensuring that the proposed schema modifications meet the specifications
of the needed change.
• Ensuring that an effective recovery plan is in place.
• Receiving approval to implement the modification.
!
Performing Schema Modifications, including:
• Restricting membership of the Schema Admins group.
• Enabling a write copy on the schema operations master.
• Verifying that all domain controllers receive the change.
• Returning the schema operations master to a read-only copy.

Module 4: Designing a Schema Policy 19


Design Guidelines
!

Plan and Implement with Care
!
Prevent Confusion
!
Prevent Unauthorized Schema Modifications


The following practices will assist you with schema modifications:
!
Plan and implement schema modifications with care.
• Modify the schema only when absolutely necessary.
• Plan, document, and implement a schema modification strategy.
• Take the simplest approach. Use existing attributes when you create
new classes, and avoid large, multi-valued attributes, which are costly to
store and retrieve.
• Choose parent classes carefully. Determine where you want users to
be able to create objects of the new class.
• If you use scripting for large-scale modifications, require intensive
testing of the script before the actual implementation.
!
Prevent confusion.
• Use meaningful names for new classes or attributes. Always use
distinctive prefixes to distinguish them from existing classes and
attributes.
• Do not move the role of the schema operations master unless you need
to take the current master offline.
• Use the common name for the LDAP display name. This will make
searches more efficient.
!
Prevent unauthorized modifications.

• Keep the The Schema may be modified on this server check box
cleared on your schema operations master.
• Closely guard membership of the Schema Admins group.

Slide Objective
To provide best practices for
modifying the schema.
Lead-in
Let’s examine best practices
for modifying the schema.
20 Module 4: Designing a Schema Policy


Lab A: Modifying the Schema


Objectives
After completing this lab, you will be able to:
• Modify the schema.

Prerequisites
Before working on this lab, you must have:
!
Knowledge about the schema in Microsoft Windows 2000 Active Directory
directory service.
!
Knowledge about creating a user account and modifying its properties.

Lab Setup
To complete this lab, you need the following:

!
The Windows 2000 Server Resource Kit must be installed on each student
computer.
!
Your computer must be functioning as a domain controller.
!
Schema modifications must be enabled on the London server according to
the Classroom Setup Guide.
!
Your server name:____________________________________________

Scenario
In this lab, you will create a new object class that is based on the User object
class. The new class will be called MCTyourservername and will contain a new
mandatory attribute called MCPyourservername.
Estimated time to complete this lab: 30 minutes
Slide Objective
To introduce the lab.
Lead-in
In this lab, you will modify
the schema and then verify
the results.
Explain the lab objectives.
Module 4: Designing a Schema Policy 21


Exercise 1
Securing the Schema
Goal
In this exercise, you will verify that the schema for the nwtraders.msft forest can only be modified

by a designated user.

Tasks Detailed Steps
1. Verify membership of the
Schema Admins group.
a. Log on to nwtraders.msft as Administrator with a password of
password.
b. Click Start, point to Programs, point to Administrative Tools, and
then click Active Directory Users and Computers.
c. Double-click the nwtraders.msft domain.
d. Click the Users OU.
e. In the details pane, double-click the Schema Admins group.
f. Click the Members tab.
g. Verify that the default user, Administrator, is not a member.
h. Verify that the schemaadmin user is a member.

2. Register the Schema
Management service with
Windows 2000. (You need
to do this only once.)
a. Log on to nwtraders.msft as Administrator with a password of
password.
i. Click Start, and then click Run.
j. In Open, type regsvr32 schmmgmt.dll and then in the RegSrv32
dialog box, click OK.
3. Load the Active Directory
schema snap-in.
a. Click Start, and then click Run.
b. In Open, type mmc and then click OK.
b. On the Console menu, click Add/Remove Snap-in.

c. In the Add/Remove Snap-in dialog box, click Add.
d. In the Add Standalone Snap-in dialog box, click Active Directory
Schema, and then click Add.
e. Click Close, and then click OK.
f. On the Console menu, click Save.
g. In the Save As dialog box, change to the C:\Documents and
Settings\All Users\Desktop directory.
h. In the File name box, type My Console and then click Save.