information in this document is subject to change without notice. the names of companies, products, people, characters,

Contents
Overview 1
Overview of the Metadirectory Design and
Development Process 2
Defining a Data Model 5
Developing a Join Strategy 9
Determining the Naming Structure 11
Determining the Physical Topology 13
Designing a Management and Security
Strategy 15
Lab A: Designing and Developing a
Metadirectory 17
Review 18

Module 14: Designing
and Developing a
Metadirectory

BETA MATERIALS FOR MICROSOFT CERTIFIED TRAINER PREPARATION PURPOSES ONLY

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, BackOffice, MS-DOS, Windows, Windows NT, <plus other appropriate product
names or titles. The publications specialist replaces this example list with the list of trademarks
provided by the copy editor. Microsoft is listed first, followed by all other Microsoft trademarks
in alphabetical order. > are either registered trademarks or trademarks of Microsoft Corporation
in the U.S.A. and/or other countries.

<The publications specialist inserts mention of specific, contractually obligated to, third-party
trademarks, provided by the copy editor>

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


Module 14: Designing and Developing a Metadirectory iii

BETA MATERIALS FOR MICROSOFT CERTIFIED TRAINER PREPARATION PURPOSES ONLY

Instructor Notes
Instructor_notes.doc

Module 14: Designing and Developing a Metadirectory 1

BETA MATERIALS FOR MICROSOFT CERTIFIED TRAINER PREPARATION PURPOSES ONLY

Overview
!
Overview of the Metadirectory Design and Development
Process
!
Defining a Data Model
!
Developing a Join Strategy
!
Determining the Naming Structure
!
Determining the Physical Topology
!
Designing a Management and Security Strategy


During the MMS planning phase, you created a list of functional requirements
for the proposed metadirectory. The next phase in the MMS planning and
design process is to apply the results from the planning into the design and
development of a metadirectory implementation that meets the functional
requirements for the proposed metadirectory. During design and development,
you create a blueprint, called a data model, which specifies how information
will flow in and out of the metadirectory. You will then configure and test
management agents to verify that the information flows as defined in the data
model. Additionally, during this phase you will define the metadirectory
namespace, the physical topology, and the metadirectory’s management and

security requirements.
After completing this module, you will be able to:
!
Describe the process of designing and developing a metadirectory that
meets the functional requirements of an organization.
!
Design a data model of the metadirectory, metaverse-connector space
relationship, and attribute flows.
!
Design and develop a strategy to join connected directories to the
metadirectory.
!
Determine an appropriate naming structure for the metadirectory.
!
Determine a MMS server topology that is based on the number of MMS
servers, MMS server locations, and connected directories in your enterprise.
!
Design a metadirectory management and security strategy.

Topic Objective
To provide an overview of
the module topics and
objectives.
Lead-in
In this module, you will learn
about designing and
developing a metadirectory
based on a set of functional
requirements.
2 Module 14: Designing and Developing a Metadirectory

BETA MATERIALS FOR MICROSOFT CERTIFIED TRAINER PREPARATION PURPOSES ONLY

#
##
#

Overview of the Metadirectory Design and
Development Process
Designing and Developing a Metadirectory Solution is an Iterative Process
Designing and Developing a Metadirectory Solution is an Iterative Process
Define a Data
Model
Define a Data
Model
Determine a
Naming Structure
Determine a
Naming Structure
Develop a
Join Strategy
Develop a
Join Strategy
Determine the
Physical
Topology
Determine the
Physical
Topology
Develop and Test

MAs
Develop and Test
MAs
Design
Management and
Security Strategy
Design
Management and
Security Strategy


The metadirectory planning phase produced a set of function requirements that
specify the content, behavior, management, and security requirements of a
metadirectory that meets the needs of an organization. By working with the
deliverables from the planning phase the next step is to design and develop the
metadirectory. During this process, you will perform the following:
!
Define a data model.
This consists of a detailed data model for the proposed metadirectory. The
data model includes specifying the metadirectory to connected directory
relationships and designing the flow of attributes between the metadirectory
and connected directories.
!
Develop a strategy for joining connected directories to the metadirectory.
This includes planning and testing the joining of connected directories to the
metadirectory. A good join strategy reduces the number of entries that must
be manually joined to the metadirectory.
!
Create a naming structure for the metadirectory.
Defining the correct naming structure for your organization is critical

because it affects the manageability, security, performance, and usability of
the metadirectory.
!
Define a physical metadirectory topology.
The physical topology of the metadirectory determines where to
interconnect management agents to connected directories, and where to
physically locate MMS servers to support access and management needs.
Topic Objective
To introduce the process of
designing and developing a
metadirectory.
Lead-in

Module 14: Designing and Developing a Metadirectory 3

BETA MATERIALS FOR MICROSOFT CERTIFIED TRAINER PREPARATION PURPOSES ONLY

!
Develop and test management agents.
To meet the functional requirements of the proposed metadirectory, you
may need to customize the management agents included with MMS or
develop new management agents MAs. You will also have to test
managements to verify whether they produce the expected metadirectory
behavior and whether information flows properly among connected
directories.
!
Develop a management and security strategy.
You will need to determine the appropriate access controls that will enforce
your administrative model.

The design and development of a metadirectory implementation consists a set
of related processes; it is not a linear set of tasks. Therefore, approach the
design phase as an iterative prototyping, learning, and development process.
You should experiment with metadirectory concepts, the connected directory
environments, and the tools and functionality MMS provides to validate and
then implement a solution that best addresses the functional requirements for
your metadirectory.
4 Module 14: Designing and Developing a Metadirectory

BETA MATERIALS FOR MICROSOFT CERTIFIED TRAINER PREPARATION PURPOSES ONLY

Mapping the Functional Requirements to Design and Development
Design Phase
Design Phase
Design Phase
Functional Requirement
Functional Requirement
Functional Requirement
Define a Data Model
Define a Data Model
$ The attributes stored in each metadirectory entry
$ The directory from where each attribute initially originates
$ The directory that will be authoritative for each attribute
$ The attributes stored in each metadirectory entry
$ The directory from where each attribute initially originates
$ The directory that will be authoritative for each attribute
Develop a
Join Strategy
Develop a
Join Strategy

$ A list of directories to be integrated in the metadirectory
$ The metadirectory entry types
$ The naming convention for metadirectory entries
$ A list of directories to be integrated in the metadirectory
$ The metadirectory entry types
$ The naming convention for metadirectory entries
Determine a
Naming Structure
Determine a
Naming Structure
Determine the
Physical Topology
Determine the
Physical Topology
Design Management
and Security
Strategy
Design Management
and Security
Strategy
$ The metadirectory management method
$ The metadirectory security policy
$ The metadirectory entry types
$ The metadirectory management method
$ The metadirectory security policy
$ The metadirectory entry types
$ The metadirectory management method
$ The metadirectory security policy
$ The metadirectory management method
$ The metadirectory security policy

$ The metadirectory management method
$ The metadirectory security policy
$ The metadirectory management method
$ The metadirectory security policy


Each of the functional requirements that you identified during the metadirectory
planning phase will be used during the design and development of the
metadirectory. The following table identifies the phase in the design and
development process in which each the functional requirement is used:
Design Phase Functional Requirement from Planning Phase

Define a Data Model • The attributes stored in each metadirectory entry
• The directory from where each attribute initially
originates
• The directory that will be authoritative for each
attribute

Develop a Join Strategy • A list of directories to be integrated in the
metadirectory
• The metadirectory entry types
• The naming convention for metadirectory entries

Determine a Naming
Structure
• The metadirectory management method
• The metadirectory security policy
• The metadirectory entry types

Determine the Physical

Topology
• The metadirectory management method
• The metadirectory security policy
Design Management and
Security Strategy
• The metadirectory management method
• The metadirectory security policy


Topic Objective
To identify which design
phase addresses the
functional requirements
developed during the
planning process.
Lead-in

Module 14: Designing and Developing a Metadirectory 5

BETA MATERIALS FOR MICROSOFT CERTIFIED TRAINER PREPARATION PURPOSES ONLY

#
##
#

Defining a Data Model
!
The Data Model Is a Blueprint for the Metadirectory
%
Defines how MAs should be configured and operated

%
Defines how MAs function together to flow data into and
out of the metadirectory
!
The Data Model Specifies:
%
The strategy for initially populating the metadirectory
%
The mode in which each management agent is run
%
The attribute flow rules


The metadirectory data model defines how management agents need to be
configured and operated to meet the content and behavior requirements that you
determined during the metadirectory planning phase. When defining the data
model, you will determine how the management agents function together to
flow information into and out of the metadirectory. The data model provides a
blueprint that guides you through the development and testing of management
agents.
The metadirectory data model specifies the following:
!
A strategy for how to initially populate the metadirectory with data from
each connected directory.
!
The mode in which each management agent is run to initially populate the
metadirectory and to maintain the relationships between entries in the
metadirectory and entries in each connected directory.
!
The attribute flow rules that define how information flows between

connected directories and the metadirectory. You must also design attribute
flow in a way that defines and enforces which connected directory is
authoritative for each attribute.
Topic Objective
To introduce the
metadirectory data model.
Lead-in

6 Module 14: Designing and Developing a Metadirectory

BETA MATERIALS FOR MICROSOFT CERTIFIED TRAINER PREPARATION PURPOSES ONLY

Assigning Modes to MAs
!
Use Reflector Mode To:
%
Initially populate the metaverse namespace
%
Create foreign entries in connected directories
!
Use Creator Mode To:
%
Populate a connected directory with entries from the metadirectory
%
Create foreign entries in connected directories
!
Use Association Mode To:
%
Import attributes, but not entire entries, into the metaverse
namespace

%
Add selective, unique attributes to entries in the metaverse
namespace


Because a metadirectory system consists of two or more connected directories
and their corresponding management agent, you must define how to configure
and when to operate each management agent so that collectively, all
management agents work together to meet the content and behavior
requirements of the proposed metadirectory.
Use the following guidelines to determine the appropriate mode to assign to
each management agent:
!
Use the Reflector mode to initially populate the metadirectory with the
entries and attributes that were defined during the planning phase. For
example, to build the metadirectory from an existing human resources (HR)
database, operate the HR management agent in Reflector mode to populate
the metadirectory with the HR data.
You can also use the Reflector mode if your metadirectory requirements
specify directory synchronization with email systems. In this scenario, you
would use Reflector mode to create entries in the metadirectory from one
email system, and then run the management agent for different email
systems in Creator mode to create a foreign entry that originates in the first
email system.
!
Use the Creator mode to create native entries in a connected directory that
correspond to entries in the metadirectory. Some directories, such as a
simple phone list, can be populated by exporting entries from the
metadirectory into a flat file. However, creating native entries in an email
system or directory service database usually requires invoking management

utilities outside the connected directory to create applications resources,
such as a mailbox or user account.
Topic Objective
To describe how to
collectively configure the
mode for each management
agent in the metadirectory
system.
Lead-in

Module 14: Designing and Developing a Metadirectory 7

BETA MATERIALS FOR MICROSOFT CERTIFIED TRAINER PREPARATION PURPOSES ONLY

!
Use the Association mode if you want to import attributes from a connected
directory, but do not want to create entries in that connected directory or
import entire entries from it into the metaverse namespace. Association
mode is also useful for importing a unique attribute that you want to include
in metadirectory entries.
For example, you may want to merge account information, such as a logon
name, from a Windows NT directory into the metaverse namespace, but not
create an entry in the metaverse namespace for every user account.

8 Module 14: Designing and Developing a Metadirectory

BETA MATERIALS FOR MICROSOFT CERTIFIED TRAINER PREPARATION PURPOSES ONLY

Designing Attribute Flow
!

The Attribute Flow Design Starts During the Planning
Phase Where You:
%
Determined which attributes will be stored in each
metadirectory entry
%
Identified the connected directory in which each attribute
originates
%
Identified the connected directory that will be
authoritative for each attribute
!
Configure and Operate Each Management Agent To
Ensure that MAs Work Together to Meet the
Metadirectory Requirements


After you assign modes to management agents, you will join entries from the
connected directories into the metaverse namespace. After that, you will set up
attribute flows to move information between the metadirectory and the
connected directories.
During the planning phase, you established the design of the attribute flow by:
!
Determining which attributes will be stored in each metadirectory entry.
!
Identifying the connected directory in which each attribute originates.
!
Identifying the connected directory that will be authoritative for each
attribute.
In the design phase, you need to configure and operate each management agent

in a way that satisfies the metadirectory content and behavior requirements.
Meeting these information flow requirements may simply a matter of copying
the contents of one attribute from one directory to another, perhaps under a
different name. To achieve this type of attribute flow, you can set up the flow
by using MMS Compass to configure attribute flow.
However, if the flow involves calculating attribute values, such as unique IDs
for new employees, then you will have to configure management agent
templates.
Topic Objective
To describe how to design
attribute flow that meets the
information flow
requirements for the
metadirectory.
Lead-in

Module 14: Designing and Developing a Metadirectory 9

BETA MATERIALS FOR MICROSOFT CERTIFIED TRAINER PREPARATION PURPOSES ONLY

Developing a Join Strategy
To Develop a Join Strategy
To Develop a Join Strategy
To Develop a Join Strategy
Determine Which Directory Will Be the
Prime Connector
Join One or More of the Remaining
Directories to the Prime Connector
Customize One or More of the Mas to Use
More Information

Manually Join the Remaining Ambiguous
Entries


During the planning phase, you identified the connected directories to integrate
with the metadirectory, and what entry types to include. You will use these
elements when you create a strategy to join connected directories. When
creating a join strategy, the key is to select the best prime connector as the first
directory to be reflected into the metaverse namespace, and then look for ways
to match attributes from the other connected directories against attributes in the
prime connector.
To avoid including ambiguous, or unmatched, entries in the metadirectory,
carefully plan and test your strategy for joining connected directories to the
metadirectory. This is especially beneficial if your directory data is not clean.
Clean directory data exists where the logical entries are unique across multiple
systems. Additionally, perform trial runs of your join strategy to further refine
the process. By developing a strategy for joining connected directories, you will
minimize the number of manual joins that you will have to perform.
To develop a join strategy:
!
Identify the prime connector.
The prime connector is the first directory you reflect into the metadirectory.
To select the prime connector, identify the directory that best represents
your information structure. Candidates for the prime connector should also
contain the most stable and authoritative attribute information.
!
Join additional directories to the prime connector.
After you run the management agent for your prime connector in Reflector
mode, you will join one or more of the remaining directories. This step will
help to gauge the cleanliness of the data. Do not expect every entry to join

on the first run of the management agent. If a majority of the entries do not
join, reconsider your choice of the prime connector; the data may not meet
the criteria set forth previously. If only 60 to 80 percent of the entries join
on the first attempt, you can configure the management agents to improve
this percentage.
Topic Objective
To describe the principles
for developing a strategy to
join connected directories to
the metadirectory.
Lead-in

10 Module 14: Designing and Developing a Metadirectory

BETA MATERIALS FOR MICROSOFT CERTIFIED TRAINER PREPARATION PURPOSES ONLY

!
Customize the management agents.
To increase the number of joins when connecting directories to the prime
connector, you can configure on or more of the management agents to use
more attribute information during the join process. By default, MMS joins
using only the Common Name attribute or the equivalent attribute in the
connected directory. To optimize the number of joined entries, try finding
other attribute values that are held in common across directories. Keep
enhancing the join criteria until you have taken full advantage of the
available data in the directory.
!
Manually join the remaining ambiguous entries.
After configuring the management agents to achieve the greatest percentage
of joined entries, you will have to manually join the remaining ambiguous,

or unmatched, entries. The cleaner the data and the better you have
optimized your management agents, the less manual joins you will need to
perform.

Module 14: Designing and Developing a Metadirectory 11

BETA MATERIALS FOR MICROSOFT CERTIFIED TRAINER PREPARATION PURPOSES ONLY

Determining the Naming Structure
!
Consider the Following When Determining Your Namespace:
%
Manageability
%
Security
%
Performance
%
Usability
!
Base the Organizing Structure on One of the Following:
%
Organizing entries other than people
%
Organizing people
%
Organizing by function
%
Organizing by geography
%

Minimal or no organization


Determining the naming structure for the proposed metadirectory includes
defining the naming context, which is the top level name for the metadirectory
namespace, and defining the organizing structure of the metadirectory and the
type of containers that you will use in this structure.
Namespace Considerations
When determining the naming structure for the metadirectory, start at the top
and consider how your enterprise naming structure fits into the global naming
structure. Continue down into your organizational level to design the internal
naming structure.
Defining the correct name structure for your enterprise is critical because it
affects the manageability, security, performance, and usability of the
metadirectory. For each of these considerations, use the following guidelines:
!
Manageability. The namespace should provide a set of containers to
separate the metadirectory into manageable parts. To create a name structure
entirely based on manageability, create containers (administrative areas) that
map to your support structure. For example, if your support structure were
site-based, create site containers; if support is based on departments, create
organizational unit containers.
!
Security. Through a proper namespace design, access controls can be
logically positioned in containers. Access control can apply hierarchically to
many entries, yet be overridden for administrative areas that may require a
different security policy than the rest of the organization. To address
security concerns, consider creating containers that map to security
requirements that vary between departments.
!

Performance. To improve performance, create enough container levels to
ensure that no single container has more than n entries, where n from about
20 entries to 500 entries depending upon how much information the entries
contain, For example, “bulky” entries may contain many certificates or
photographs.
Topic Objective
To describe how to
determine the metadirectory
naming structure.
Lead-in

12 Module 14: Designing and Developing a Metadirectory

BETA MATERIALS FOR MICROSOFT CERTIFIED TRAINER PREPARATION PURPOSES ONLY

!
Usability. If the naming structure is too obscure, too deep, too cryptic, or too
unstable administrators or users may have difficulty finding information by
navigating the directory.

It is important to consider the naming context carefully, because
changing the naming context for a server will require reinstalling MMS.

Defining the Organizing Structure
You can define the types and names of containers to hold metadirectory entries.
Depending on your implementation, you can base this organizing and naming
structure on one of the following strategies:
!
Organizing entries other then people. If you plan to store entries containing
information about objects on the network, applications, or other resources,

consider compartmentalizing them separately from the people in your
organization. For example, you can separate entries belonging to different
object classes (such as people, buildings, applications) into different
branches of the tree.
!
Organizing people. Whether or not you have a “People” branch as shown in
some of the examples above, People will comprise perhaps the most
important part of your directory, and you need to structure this branch
carefully. The following paragraphs contain examples of directory
information organized in functional, geographical, or flat namespaces.
!
Functionally organized. Use organizational units group entries according to
the function within the organization. This approach would mimic the
organization structure of the organization.
!
Geographically organized. Use regions or sites containers to hold entries
contained in that site or region. The type of structure will be fairly stable;
however, consider using sub-containers to achieve greater granularity of
management or security.
!
Minimal organization. This approach will be very stable. Use this approach
if you are storing minimal data in the metadirectory or if there are no useful
geographical or functional structures on which to base your structure.

Im
p
ortant
Module 14: Designing and Developing a Metadirectory 13

BETA MATERIALS FOR MICROSOFT CERTIFIED TRAINER PREPARATION PURPOSES ONLY

Determining the Physical Topology
!
To Define the Physical MMS Topology:
%
Determine the required number of MMS servers
%
Identify the physical locations for the MMS servers
%
Determine when to use referrals and when to use
replication to tie together the different parts of the
metadirectory
!
Physical Topology Considerations Include:
%
Performance
%
Administration


An implementation of MMS can have a single MMS server that supports
multiple management agents or have multiple MMS servers that divide the load
and replicate information as needed. Part of the metadirectory design process is
to determine the physical server topology of the MMS servers.
To define the topology, you will need to do the following:
!
Determine how many MMS servers will be required. If possible, test the
MMS server on your hardware and your network before putting it into
production to determine how many MMS servers may be required.
Additionally, plan to monitor the computers running servers closely during

deployment to ensure that performance meets your requirements.
!
Identify the physical locations of the MMS server locations and how the
computers running MMS will be connected to the connected directory.
!
Determine when to use referrals and when to use replication to connect
together the different parts of the metadirectory.

The factors that you must consider when determining the physical
metadirectory topology include performance, administration, and connectivity.
Performance Factors
If you are using MMS only to manage directory information, you will not need
more than one computer running MMS. However, if you are using MMS as a
query server that provides end users with access to the metadirectory, you may
need more than one server. In this case, you should replicate a copy of the
metadirectory to at least one query server.
Topic Objective
To describe guidelines for
how to determine the
physical topology for a
metadirectory.
Lead-in

14 Module 14: Designing and Developing a Metadirectory

BETA MATERIALS FOR MICROSOFT CERTIFIED TRAINER PREPARATION PURPOSES ONLY

Consider using additional MMS servers for the following situations:
!
The metadirectory contains mission critical information and downtime

cannot be tolerated
!
The MMS capacity is sufficient, but bandwidth between sites is low. In this
case, some sites may need a dedicated MMS server, particularly if the
metadirectory contains large amounts of data, such as digital photographs.
!
A MMS server needs to be placed on a security boundary, and policy does
not allow it to contain all the metadirectory information that would be
accessible from the safe side of the boundary.
Administrative Factors
If your enterprise is widely distributed or has multiple support organizations,
consider using multiple MMS servers that are managed by the different support
groups. The MMS servers could then be allocated along the lines of your
support organization, by region or by department, and housed at the support
facilities used by the appropriate groups.
If you distribute the metadirectory to multiple support groups, there should first
be an agreement on the overall naming structure. Using your naming structure,
the enterprise will be divided into a number of containers. Some of those
containers represent the starting naming contexts for the MMS servers. These
naming contexts also act as administrative areas, each with security subentries
designating the administrators from the local support group that has authority
over their MMS server and all it contains.
Module 14: Designing and Developing a Metadirectory 15

BETA MATERIALS FOR MICROSOFT CERTIFIED TRAINER PREPARATION PURPOSES ONLY

Designing a Management and Security Strategy
!
The Management Strategy Depends on the Physical Topology of
the Metadirectory

%
A single site design will use centralized management
%
A multiple site design will use distributed management
!
To Design the Security Policy for the Metadirectory:
%
Create a super user account for each MMS server
%
Create additional data administrators to handle routine
administration
%
Assign access controls on the namespace and the administrative
areas to protect the privacy of user data
%
Avoid setting permissions on individual entries or attributes


In the planning phase you determined the best management method and
security policy. You will now use that information to design the metadirectory
management and security strategy.
Designing Metadirectory Management
Much of the management design is accomplished by determining the physical
topology of the metadirectory. This determines whether you will locate your
MMS servers in a single site, or distribute them throughout the enterprise. If
you are using a single site, then you will manage the metadirectory in a
centralized method using one support organization. If you are distributing the
MMS servers throughout the enterprise, you might want to have different
support organizations manage the part of the directory stored on the server in
their location.

Next, you must decide who will manage the data on those servers. Initially,
consider allowing the administrators of the connected directories to continue to
manage that data in the metadirectory. You can include aliases to those
administrative user accounts in the appropriate role lists: directory
administrators, operators, and security officers. Then assign the necessary
permissions to the administrative areas that contain the data managed by those
administrators.
Designing the Metadirectory Security Policy
The planning phase for metadirectory security has resulted in defining the
privacy boundaries, authentication requirements, and access control
requirements. This information enables you to determine who will be able to
log on to the metadirectory, what information they will be able to access, and
what information is accessible by other users.
Topic Objective
To describe how to design
and metadirectory
management and security
strategy.
Lead-in

16 Module 14: Designing and Developing a Metadirectory

BETA MATERIALS FOR MICROSOFT CERTIFIED TRAINER PREPARATION PURPOSES ONLY

Apply the following guidelines to design the security policy for the
management role:
!
Only allow the administrator to have write access to the namespace area, or
management agent, that he or she controls.
!

Each MMS server must have a superuser, who is the administrator who has
the right to modify access controls and define new administrators.
!
Create data administrators to handle routine adds, deletes, and changes to
the namespace.

Next, define specific access controls to allocate administrator privilege to the
different parts of the directory, and to protect private information. You can
apply these permissions at the namespace, container, entry, or attribute level.
For ease of management, avoid applying security at the entry or attribute level
where possible.
Module 14: Designing and Developing a Metadirectory 17

BETA MATERIALS FOR MICROSOFT CERTIFIED TRAINER PREPARATION PURPOSES ONLY

Lab A: Designing and Developing a Metadirectory


Lab.doc
Topic Objective
To introduce the lab.
Lead-in
In this lab, you will design
and develop a metadirectory
based on the functional
requirements that you
developed in the previous
planning lab.
Explain the lab objectives.
18 Module 14: Designing and Developing a Metadirectory

BETA MATERIALS FOR MICROSOFT CERTIFIED TRAINER PREPARATION PURPOSES ONLY

Review
!
Overview of the Metadirectory Design and Development
Process
!
Defining a Data Model
!
Developing a Join Strategy
!
Determining the Naming Structure
!
Determining the Physical Topology
!
Designing a Management and Security Strategy


1. What three pieces of information from the planning metadirectory planning
phase are required before you can develop a join strategy?
A list of directories to be integrated in the metadirectory, the
metadirectory entry types, and the naming convention for
metadirectory entries.

2. What is included in a metadirectory data model?
The metadirectory data model specifies the following:
• A strategy for how to initially populate the metadirectory with
entries from each connected directory
• The mode in which each management agent is run. The modes are

different depending on whether the management agent is initially
populating the metadirectory and or if it is maintaining the
relationships between entries in the metadirectory and entries in
each connected directory.
• The attribute flow rules that define how information flows between
connected directories and the metadirectory.


3. What is clean directory data? Why is a clean directory an important part of
the join strategy?
Clean directory data ensure that entries in a directory are unique, so
that multiple entries for the same real-world object are minimal. Clean
data is the primary criterion for choosing the first directory that you
connect to the metadirectory. The clean data in the prime connector
will reduce the number of , and the better you have optimized your
management agents, the less manual joins you will need to perform.
Topic Objective
To reinforce module
objectives by reviewing key
points.
Lead-in
The review questions cover
some of the key concepts
taught in the module.
Module 14: Designing and Developing a Metadirectory 19

BETA MATERIALS FOR MICROSOFT CERTIFIED TRAINER PREPARATION PURPOSES ONLY

4. When a new employee is hired at NWTraders Corporation, the HR manager
sends an e-mail message to the HR SQL database administrator, the e-mail

administrator, and the network administrator, to request that a user object
for the new employee be added to each of those directories.
Which of these directories is good candidate for a prime connector?
What business process change would you suggest to this company to ensure
cleaner data in their directories?
None of them. More than likely, the data in each of these directories
would not be very clean. Without adequate and enforced corporate
guidelines and naming conventions, these different administrators
could create accounts for the user object that do not have identical
names, therefore you will probably have ambiguous and unmatched
entries in the metadirectory after joining these directories.
To improve this situation, suggest that the account gets created initially
in one directory only (for example, the HR database) and then from the
SQL database, network user account and the e-mail account are
created. Better yet, suggest a hire/fire scenario based on MMS.


5. What three things do you need to determine in order to define the physical
topology for metadirectory?
1. How many MMS servers will be required.
2. The physical locations of the MMS server locations.
3. When to use referrals and when to use replication to connect together
the different parts of the metadirectory.






THIS PAGE INTENTIONALLY LEFT BLANK