Classic Metadirectory Walkthrough: Scenario Design

Updated: June 7, 2006

Applies To: Windows Server 2003 with SP1

Previous Steps in This Walkthrough

Scenario Design

Microsoft Identity Integration Server 2003 is most commonly employed to integrate data between connected data sources. The design of this scenario involves the following three components:

  • Five incongruent data sources that use different data formatting methods.

  • Microsoft Identity Integration Server 2003.

  • Different Microsoft Identity Integration Server 2003 management agent (MA) types that are used to flow data between a data source and Microsoft Identity Integration Server 2003.

The scenario is communicated at the following two levels. First, a high-level discussion of the flow of employee identity and distribution list data from the data sources to their representative objects in the Microsoft Identity Integration Server 2003 metaverse is provided, followed by a detailed examination of how the metaverse should be populated with the objects in the different data sources.

Situation

The fictitious company named Fabrikam will implement a solution for employee data management. Currently, the employee data for Fabrikam is spread across its different data sources. Modifying data for an employee requires updating each independent data source separately according to its data formatting rules.

Fabrikam has employee data that is stored in the following five systems:

  • Human Resources (HR) system

  • Microsoft Exchange Server

  • Active Directory

  • Sun ONE Directory Server 5.1 (formerly iPlanet Directory Server)

  • Telephone system

Modifying employee data across separate data sources is time-consuming. It is also difficult to use employee data in one data source, such as Microsoft Exchange Server, to populate data categories in another data source, such as Active Directory.

Employee Identity Data Management

The problem faced by Fabrikam is the difficulty of managing the flow of its employee data between its different data sources, and an inability to see all of the data related to an employee in a single view. By having its employee data in five disconnected data sources, Fabrikam is unable to accomplish the following objectives:

  • Manage change. Fabrikam wants to discover changes to the employee data stored in the five data sources and update the data sources with these changes in order to coordinate employee data throughout the enterprise.

  • Obtain a summary of employee data. Fabrikam wants to view employee data as it exists in total, instead of five partial views that only provide employee data from the point of view of an individual data source. A summative view will enable Fabrikam to manage employee data across its enterprise.

Solution

By using Microsoft Identity Integration Server 2003, Fabrikam will achieve the following high-level solution:

  • Combine the common characteristics for a specific employee in the metadirectory, thereby creating a single view that contains some or all of the employee identity information from each connected data source.

  • Provide a single location for administration, where applications and users can access or manage the identity information for an employee.

Fabrikam will import the employee data that exists in its independent data sources into Microsoft Identity Integration Server 2003. With employee data assembled in Microsoft Identity Integration Server 2003, Fabrikam can coordinate all connected data sources and reduce the costs associated with managing employee data.

Scenario Goals

By implementing Microsoft Identity Integration Server 2003, Fabrikam hopes to accomplish the following two goals:

  1. Aggregate employee identity data from its five data sources while maintaining data source ownership over specific employee identity characteristics.

  2. Use data from the Exchange Server data source to populate distribution lists in the Active Directory data source.

Identity Aggregation and Ownership

Currently, the employee identity information in the data sources used by Fabrikam share many common characteristics, which are called attributes in Microsoft Identity Integration Server 2003, about the same employees. Each of the specific data sources own specific characteristics. For example, while the HR data source is the established owner of employee identities, authoritative sources of attributes such as e mail addresses or telephone numbers are handled by the other data sources.

When merging the common employee data into the single, logical view of the Microsoft Identity Integration Server 2003 metaverse, Fabrikam maintains precedence for certain characteristics for the data sources that own those employee characteristics.

Data Source Propagation

In addition to maintaining attribute precedence, Fabrikam uses Microsoft Identity Integration Server 2003 to populate distribution lists (DLs) in the Active Directory data source from the group membership data in the Exchange Server e-mail system, which is authoritative for group membership.

Infrastructure and Data Flow Design

The Microsoft Identity Integration Server 2003 infrastructure for Fabrikam is developed in the design and creation of the Microsoft Identity Integration Server 2003 management agents (MAs) that are used to combine the independent Fabrikam employee data sources in the metadirectory. The MAs are designed according to a flow of objects and attributes from the data sources to the metadirectory that upholds the precedence and provisioning requirements of Fabrikam.

To implement its solution, Fabrikam uses Microsoft Identity Integration Server 2003 functionality and the specific objects in the data sources to design the following:

  1. The Microsoft Identity Integration Server 2003 system configuration for this scenario.

  2. Rules that determine the object and attribute flow between the connected data sources and the metadirectory.

  3. The MAs that are needed to flow objects and attributes between the connected data sources and the metadirectory.

Microsoft Identity Integration Server 2003 Deployment

The Microsoft Identity Integration Server 2003 deployment for Fabrikam uses five data sources that are connected to the metadirectory by separate management agents (MAs). These MAs facilitate the import and export of data source objects and attributes to and from the metadirectory.

b393052d-68e3-4a19-a8ff-9264fce3af9e

Figure 1.1: Microsoft Identity Integration Server 2003 Deployment for Fabrikam

Each MA controls the communications between its connected data source and the metadirectory. Each MA is designed to perform as a set of instructions that direct how the metadirectory integrates the data from the connected data source.

The instructions contained in an MA perform the following metadirectory functions:

  • Create objects

  • Delete objects

  • Configure parameters

  • Ensure data integrity

  • Implement transformation rules

  • Maintain attribute ownership

  • Set attribute flow rules

Discovering, Synchronizing, and Updating Data

Fabrikam MAs perform the following:

  • Discover the connected data source.

  • Synchronize the data in the connected data source with the metadirectory.

  • Update the data in connected data source.

The operation of MAs involves all these activities, but each MA serves a different purpose. The table below describes the MAs that you use in this scenario to synchronize employee information and create Active Directory distribution lists for Fabrikam.

 

  MA Name MA Type Purpose

MA 1

Fabrikam HR MA

SQL Server Management Agent

Imports information from the HR system to a database table in the metadirectory. The database table with employee data emulates the HR system to the metadirectory.

MA 2

Fabrikam LDAP Data Interchange Format (LDIF) MA

LDAP Data Interchange Format (LDIF) File Management Agent

Manages both individual mailboxes and distribution groups in Microsoft Identity Integration Server 2003. The MA uses an LDIF file containing the mailboxes and distribution lists in the Exchange 5.5 directory.

MA 3

Fabrikam AD MA

Active Directory Management Agent

Imports user objects from Active Directory into the metadirectory. The MA also populates group memberships in Active Directory from Microsoft Identity Integration Server 2003 metaverse groups.

MA 4

Fabrikam Sun ONE Directory Server 5.1 MA

Sun ONE Directory Server 5.1 Management Agent

Imports inetOrgPerson objects from the Sun ONE Directory Server 5.1 Directory Server.

MA 5

Fabrikam Telephone MA

Fixed Width Text File Management Agent

In Sun ONE Directory Server 5.1, inetOrgPerson is an object class used to describe either person or user objects.

Object and Attribute Flow

The Fabrikam Management Agents (MAs) copy, or import, connected data source objects and attributes into the metadirectory. The objects and attributes imported from the connected data sources are either employee or distribution list identity data.

The object and attribute flow of employee identity data is designed to provide Fabrikam with a single view of all employee data in the enterprise. In this design, employee identity objects and attributes from the five data sources are selected and then imported into the metadirectory, where metaverse objects and attributes are used to represent an integrated view of Fabrikam employees.

The object and attribute flow design for the distribution list identity data provides the Active Directory data source with distribution list membership data that exists in the Exchange data source. Distribution list identity data flows from the Exchange data source into the metadirectory, where the resulting metaverse objects and attributes represent the group membership of the distribution lists. After synchronization, the group membership distribution list data is exported to Active Directory to populate the membership data of its distribution lists.

To design the flow of data from the connected data sources to the metadirectory, the scenario design includes following factors:

  • Employee identity data exists in the five data sources.

  • Distribution list identity data exists in the Exchange data sources.

  • The processes involved in populating the metadirectory.

  • The attribute-value pairs in the five data sources that will be used to populate the metadirectory.

  • The design of the attribute flow from the connected data sources to the metadirectory.

Employee Identity Data

The first goal of Fabrikam is to create an aggregated view of Fabrikam employees from which all of the data sources in Fabrikam can be managed. Fabrikam uses the employee object from the HR system and related data from the other four connected directories to create a person object in the metaverse. This person object is used to manage the related employee information in the connected data sources.

The table below lists and describes how the five connected data sources contribute employee identity data to create the person object in the metaverse.

 

Connected Data Source Employee Identity Data Contribution to Microsoft Identity Integration Server 2003

HR System

Employee object data

Active Directory

User object data

Exchange Server

Mailbox data

Sun ONE Directory Server 5.1 Server

Mailbox data

Telephone System

Telephone data

This figure illustrates the object and attribute flow for the goal of creating the person object in the Microsoft Identity Integration Server 2003 metaverse.

d203ef1e-84f7-41f7-ac71-75f5f1a415e0

Figure 1.2: Fabrikam Data Sources

The data sources are connected to the metadirectory and their imported object data is used to create the metaverse person object.

The Fabrikam data sources have the following employee infrastructure:

  • A total population of 100 employee objects.

  • 50 employee objects have mailboxes in Microsoft Exchange.

  • 50 have mailboxes in Sun ONE Directory Server 5.1.

When the metaverse person object is created from these data sources, there will be a single view of employees that can be used to synchronize employee data for all 100 employees.

Distribution List Identity Data

The second goal of Fabrikam is to create Active Directory distribution lists (DLs) by using the group membership data in the Microsoft Exchange Server data source. The distribution list object from Exchange is copied into the metadirectory to create a metaverse group object, and then the metaverse group object is used to populate the Active Directory DL membership.

57f55141-75d0-4cde-b23d-3020a6895dd1

Figure 1.3: Metaverse Group Object

The difference between the two goals of Fabrikam is that the first goal is the process of synchronizing data sources, and the second goal is the process of exporting data from one connected data source to populate the object of another connected data source. Both processes use the Microsoft Identity Integration Server 2003 to synchronize connected data sources, but the second goal demonstrates the export functionality of Microsoft Identity Integration Server 2003. From the business perspective, the second goal is different because Fabrikam is more interested in leveraging Microsoft Identity Integration Server 2003 to generate data in one of its data sources than in the single view of DLs supplied by the metaverse group object.

Populating the Metaverse

The metaverse is populated by management agents that import data from a connected data source into the connector space, the staging area used to move data in and out of the metaverse and synchronize changes between the metaverse and connected data sources. The metaverse is populated when objects in the connector space are projected to objects in the metaverse and connector space object attribute values are emulated in the metaverse. When objects in the connector space are emulated in the metaverse, Microsoft Identity Integration Server 2003 is said to perform import attribute flow.

Fabrikam MA Join and Projection Rules

Management agents can join or project connector space objects to the metaverse. Before the MAs join or project connector space objects to the metaverse, MAs apply join and projection rules.

Join rules determine if a connector space object can be joined to a metaverse object. An MA runs projection rules if join rules fail. Projection rules determine whether and how an MA creates, or projects, a metaverse object type using a connector space object.

When you run an MA configured with join rules, a join search is applied to each object in the connector space, which attempts to find a corresponding object in the metaverse. The search results are evaluated according to the following resolution rules:

  • Fail: None of the connector space objects satisfies the join criteria, in which case the next search criteria are evaluated.

  • Pass: Exactly one of the connector space objects satisfies the join criteria, in which case it is joined with the connector object.

  • Fail: More than one of the connector space objects satisfies the join criteria, in which case the join operation fails.

Configured projection rules are applied to connector space objects when a join has failed or was not configured. Projection rules define a basic object type mapping from the available connector space and metaverse types (that is, a declarative rule) or use a rules extension to examine the source object and determine whether it is projected to the metaverse.

When the Fabrikam MAs import data source objects into the connector space, the connector space objects are initially disconnector objects, meaning the objects have no link relationship to a metaverse object. When the connector space objects are linked to metaverse objects, the connector space objects are connector objects. The Fabrikam HR MA will import employee objects from the HR system into the connector space as disconnector objects and then project these objects into the metaverse according to its projection rules.

The Fabrikam LDAP Data Interchange Format MA will use both projection and join rules. The distribution lists from the Exchange server will be automatically projected into the metaverse. The attributes associated with mailboxes in the Exchange system will need to be evaluated, or have rules applied, to determine the metaverse object to which they should be joined.

noteNote
In this scenario, multiple join rules are defined to join the employee identities in the connected data sources to the user objects projected by the Fabrikam HR MA. (Distribution lists are also joined between the two Active Directory and Exchange.) For the user objects, the join will only partially succeed, due to the fact that not every connected system has deployed a unique identifier.

This table lists the join and projection methods used by the Fabrikam MAs.

 

Fabrikam MA Name Join/Projection Method

Fabrikam HR MA

Projects user objects from HR data source to the metaverse.

Fabrikam LDAP Data Interchange Format (LDIF) MA

Projects Exchange distribution lists and joins mailboxes to metaverse.

Fabrikam AD MA

Joins Active Directory users and groups to metaverse. Exports group memberships from the metaverse based on Exchange distribution lists members.

Fabrikam Sun ONE Directory Server 5.1 MA

Joins inetOrgPerson objects from Sun ONE Directory Server 5.1 Directory server to metaverse.

Fabrikam Telephone MA

Joins person objects from Telephone data source in the metaverse.

Projection and Joins

This table lists the Fabrikam MAs that use projection, and the object type that is used.

 

Fabrikam MA Name Method Object Type

Fabrikam HR MA

Projection

person

Fabrikam LDAP Data Interchange Format (LDIF) MA

Projection

Group

For each connector space object, MAs use specific criteria to find the metaverse object to which the connector space object is to be joined. The table below lists the connected data source object type, its associated metaverse object type, and the join criteria used to find the metaverse object to which the connector space object is to be joined.

 

Fabrikam MA Name Connected Data Source Object Type Metaverse Object Type Join Criteria

Fabrikam AD MA

User

Person

EmployeeID

Fabrikam AD MA

Group

group

Mail

Fabrikam LDAP Data Interchange Format (LDIF) MA

Mailbox

Person

Firstname & Lastname

Fabrikam Sun ONE Directory Server 5.1 MA

inetOrgPerson

Person

Firstname & Lastname

Fabrikam Telephone MA

Person

person

Name

Selected Attributes and Values in the Connected Data Sources

The design of the Fabrikam Microsoft Identity Integration Server 2003 infrastructure requires a comprehensive knowledge of the attribute data in the five data sources. Once the attributes and values of the data sources are examined you can design the MAs needed to produce the desired synchronization.

The attributes of a connected data source that are selected in the creation of an MA are referred to as selected attributes. Selected attributes of objects in the different Fabrikam connected data sources are used as a starting point for populating the metaverse.

The unique attributes of an object that are not modified in the connected data source are referred to as the anchor attributes for the object and are used by Microsoft Identity Integration Server 2003 to locate an object in the connector space of a specific connected data source. An anchor attribute is a primary key in the Microsoft Identity Integration Server 2003 database table used by the connected data source, thereby maintaining a unique entry for each object record in the database. Each of the objects in the connected data sources has an anchor attribute (for example, an employee number or a user ID).

EmployeeData Attribute in the HR System

This table lists the attributes for an EmployeeData object that the Fabrikam HR system uses. The employeeID attribute is the anchor attribute.

 

Attribute Value

c:

UK

co:

UNITED KINGDOM

company:

Fabrikam plc

branchID:

003

displayName:

Amity Harty

employeeID:

UK0371698

fileAs:

Harty, Amity

givenName:

Amity

sAMAccountName:

aharty

sn:

Harty

telephoneNumber:

+44 20 167 730

title:

Administrative Assoc

hireDate:

1/8/1986

employeeType:

Full

employeeStatus:

active

manager:

UK0057339

These attributes will be used to project the EmployeeData object from the HR system connected data source to person object in the metaverse.

Employee Attributes in the Telephone System

This table lists the attributes for an Employee object that the Fabrikam telephone system connected data source uses. The RECID attribute (record number) is the anchor attribute.

 

Attribute Value

RECID

000016649

Name

Smith

Telephone

+44 22 133 147

Mobile

+44 22 305 717

Pager

+44 22 645 589

Fax

+44 22 533 126

User Attributes in Active Directory

This table lists the attributes for a user object that the Fabrikam Active Directory connected data source uses. Active Directory objects have a natural anchor, ObjectGUID, which is unique and immutable. The management agent for Active Directory recognizes and maintains this anchor.

 

Attribute Value

cn

Harty, Amity

company

Fabrikam plc

c

UK

department

003

displayName

Amity Harty

employeeID

UK0371698

facsimileTelephoneNumber

+44 20 983 120

givenName

Amity

mobile

+44 20 544 672

pager

+44 20 696 726

name

Harty, Amity

sAMAccountName

aharty

sn

Harty

telephoneNumber

+44 20 167 730

Co

UNITED KINGDOM

Title

Administrative Assoc

userPrincipalName

aharty@fabnoa.nttest.microsoft.com

Mailbox Attributes in Exchange

This table lists the attributes for a mailbox that the Fabrikam Exchange system connected data source uses. As the mailbox is never moved and always stays in the Recipient container in this scenario, the anchor is the distinguished name (DN).

 

Attribute Value

dn

cn="Harty, Amity",cn=Recipients,ou=MIIS,o=MS

cn

Harty, Amity

rdn

Amity Harty

distinguishedName

cn="Harty, Amity",cn=Recipients,ou=MIIS,o=MS

rfc822Mailbox

aharty@exchange.fabrikam.com

mail

aharty@exchange.fabrikam.com

textEncodedORaddress

c=US;a= ;p=MS;o=MIIS;s=Harty;g=Amity;

otherMailbox

MS$MS/MIIS/AHARTY

otherMailbox

CCMAIL$Harty, Amity at MIIS

Company

Fabrikam plc

mailPreferenceOption

0

department

3

Extension-Attribute-1

UK0371698

Extension-Attribute-2

512

givenName

Amity

Home-MTA

cn=Microsoft MTA,cn=SEVENOF9,cn=Servers,

cn=Configuration,ou=MIIS,o=MS

Uid

aharty

MAPI-Recipient

TRUE

sn

Harty

facsimileTelephoneNumber

+44 20 983 120

mobile

+44 20 544 672

telephoneNumber

+44 20 167 730

pager

+44 20 696 726

Co

UK

title

Administrative Assoc

Distribution List Attributes in Exchange

This table lists the attributes for a distribution list (DL) that the Fabrikam Exchange system connected data source uses. As the DL is never moved and remains in the Recipient container in this scenario, the anchor attribute is the distinguished name (also known as DN) attribute.

 

Attribute Value

Dn

cn=dep001,cn=Recipients,ou=MIIS,o=MS

cn

dep001

rdn

Department 001

distinguishedName

cn=dep001,cn=Recipients,ou=MIIS,o=MS

rfc822Mailbox

dep001@exchange.fabrikam.com

Mail

dep001@exchange.fabrikam.com

textEncodedORaddress

c=US;a= ;p=MS;o=MIIS;s=dep001;

OtherMailbox

MS$MS/MIIS/DEP001

otherMailbox

CCMAIL$dep001 at MIIS

uid

dep001

Report-To-Originator

TRUE

Report-To-Owner

FALSE

member

cn="Patton, Jonie",cn=Recipients,ou=MIIS,o=MS

inetOrgPerson Object Attributes from Sun ONE Directory Server 5.1

This table lists attributes for the inetOrgPerson that The Fabrikam Sun ONE Directory Server 5.1 system connected data source uses. Sun ONE Directory Server 5.1 objects have the inherent anchor, nsUniqueID, which is unique and immutable. It is not used for any rules in this scenario. The management agent for Sun ONE Directory Server 5.1 recognizes and maintains this anchor automatically.

 

Attribute Value

dn

CN=Dunson\, Darrin,ou=People,dc=fabrikam,dc=com

cn

Dunson, Darrin

description

Fabrikam plc

departmentNumber

001

displayName

Darrin Dunson

employeeNumber

UK0376127

facsimileTelephoneNumber

+44 20 805 658

givenName

Darrin

mobile

+44 20 359 249

pager

+44 20 129 638

uid

ddunson

sn

Dunson

telephoneNumber

+44 20 686 384

title

Lead Investment Banking Associate

mail

ddunson@Sun ONE Directory Server 5.1.fabrikam.com

Attribute Flow

The following tables show which attributes are being imported from the connected data sources into the metaverse, as well as the object types under which they will be imported.

All attribute flows are import attribute flows with the exception of the member attribute flow mapping in the Fabrikam AD MA, which will be exported. Once the group memberships that are managed in the Exchange system are imported into the metaverse, they will be exported to Active Directory by using the member attribute.

 

HR System (EmployeeData) Metaverse (person) Mapping Type Flow Direction

branchID

department

Direct

Import

c

c

Direct

Import

co

co

Direct

Import

company

company

Direct

Import

employeeID

employeeID

Direct

Import

employeeStatus

employeeStatus

Direct

Import

employeeType

employeeType

Direct

Import

fileAs

displayName

Direct

Import

givenName

givenName

Direct

Import

manager

manager

Direct

Import

sn

sn

Direct

Import

telephoneNumber

telephoneNumber

Direct

Import

title

title

Direct

Import

 

Exchange (organizationalPerson object) Metaverse (person object) Mapping Type Flow Direction

rdn

displayName

Direct

Import

mail

mail

Direct

Import

uid

uid

Direct

Import

uid

mailNickname

Direct

Import

 

Exchange (groupOfNames object) Metaverse (group object) Mapping Type Flow Direction

rdn

displayName

Direct

Import

mail

mail

Direct

Import

member

member

Direct

Import

uid

uid

Direct

Import

uid

mailNickname

Direct

Import

 

Sun ONE Directory Server 5.1 (inetOrgPerson object) Metaverse (person object) Mapping Type Flow Direction

description

description

Direct

Import

displayName

displayName

Direct

Import

mail

mail

Direct

Import

uid

uid

Direct

Import

uid

mailNickname

Direct

Import

comment

Advanced (Distinguished name part mapping)

Import

noteNote
The relative distinguished names (separate container labels that establish the distinguished name for an object) represent the hierarchical structure in which the object is located in the directory. Saving the name of the container, or some other part of the hierarchy, in a metaverse attribute can reduce the complexity of programming code required to parse the distinguished name in rules extensions, or in other cases where the hierarchy determines some action to be taken. The mapping of distinguished name parts solves the problem of saving container names without requiring a rules extension.

 

Active Directory (group object Metaverse (group object) Mapping Type Flow Direction

cn

cn

Direct

Import

member

member

Direct

Export (This attribute will be exported)

samAccountName

uid

Direct

Import

 

Active Directory (user object) Metaverse (person object) Mapping Type Flow Direction

cn

cn

Direct

Import

samAccountName

uid

Direct

Import

 

Telephone System (person object) Metaverse (person object) Mapping Type Flow Direction

FAX

facsimileTelephoneNumber

Direct

Import

MOBILE

mobile

Direct

Import

PAGER

pager

Direct

Import

TELEPHONE

telephoneNumber

Direct

Import

Attribute Authority and Precedence

During the synchronization of data from multiple data sources, Microsoft Identity Integration Server 2003 uses rules to define precedence for combining similar data into a final version that is stored in the metaverse.

This scenario has the following attribute authority:

  • The HR system is authoritative for all attributes within the HR system except telephoneNumber and displayName.

  • The telephone system is authoritative for all phone numbers.

  • The Exchange and Sun ONE Directory Server 5.1 systems are authoritative for mail, mailNickname, and displayName. In addition, the Exchange system is authoritative for the member attribute on distribution lists.

  • Active Directory is authoritative for the uid and cn attributes.

The telephoneNumber, displayName, and uid attributes are copied into the Microsoft Identity Integration Server 2003 metaverse by multiple systems.

The table below outlines the attribute precedence for this scenario.

 

Metaverse Attribute Data Source Precedence

displayName

Exchange

1

Sun ONE Directory Server 5.1

2

HR System

3

telephoneNumber

Telephone System

1

HR System

2

uid

Active Directory

1

Exchange

2

Sun ONE Directory Server 5.1

3

Scenario Workflow

The following high-level workflow describes the most important steps for creating the management agents (MAs) for this scenario. The descriptions include the attribute flow mappings and run profiles used to import and export attributes from the metadirectory. Each of the MAs is described according to the three phases of using an MA: creating the MA, running the MA, verifying that the MA accomplished it objective.

Fabrikam HR MA
  1. Specify an anchor attribute by viewing the EmployeeData object in the HR data source, and selecting the employeeID attribute as the anchor attribute for the HR database table in the metadirectory.

  2. Create a projection rule by selecting the person object type and specifying a declared projection type. Then configure the import attribute flow between the HR data source person attribute and the metaverse person object.

  3. Map the remainder of the selected HR data source and metaverse attributes as specified in the management agent attribute flow above.

  4. Create and run a full import run profile.

  5. Verify the results of the MA run by using Operations and Metaverse Search.

Fabrikam LDAP Data Interchange Format MA
  1. Use the distinguished name (DN) of the mailbox object as the anchor attribute because the mailbox is never moved and always stays in the Recipient container in this scenario.

  2. Specify one partition for distribution lists (distributionlists) and one partition for the individual mailboxes (mailboxes).

  3. In the distributionlists partition, select groupOfNames and organizationalPerson.

  4. Create a projection rule that projects the attributes of the Exchange groupOfNames object type to the metaverse group object type.

  5. Create a join rule that joins the attributes of organizationalPerson to the metaverse person object type.

  6. Map the attributes of organizationalPerson to the metaverse person object type.

  7. In the metaverse, to maintain the name of the Exchange container in which the objects are located, map the relative distinguished names (RDNs) of each Exchange object to the comment attribute of their metaverse entries.

  8. Map the attributes of groupOfNames to the metaverse group object type.

  9. Rank the metaverse displayName attribute precedence for the Fabrikam LDAP Data Interchange Format MA at 1.

  10. Create and run the full import run profile.

  11. Verify the results of the MA run using Operations and Metaverse Search.

Fabrikam AD MA
  1. Map user and group object attributes in fabnoa.fabcorp.fabrikam.com to metaverse person and group object attributes.

  2. Rank the metaverse uid attribute flow precedence for the Fabrikam AD MA to 1.

  3. Use Performance Logs and Alerts with the Fabrikam AD MA to monitor metadirectory performance.

  4. Create and run a full import-export run profile.

  5. Create and run an export run profile.

  6. Verify the results of the MA run by using Operations.

Fabrikam Sun ONE Directory Server 5.1 MA
  1. Map the inetOrgPerson Sun ONE Directory Server 5.1 object attributes to the metaverse person object with an import mapping type.

  2. Rank the metaverse displayName attribute precedence for the Fabrikam LDAP Data Interchange Format MA to 1, the Sun ONE Directory Server 5.1 MA to 2, and the HR MA to 3.

  3. Rank the metaverse uid attribute precedence for the Fabrikam AD MA to 1, the LDAP Data Interchange Format MA to 2, and the Sun ONE Directory Server 5.1 MA to 3.

  4. Create and run a full import run profile.

  5. Verify the results of the MA run by using Operations.

Fabrikam Telephone MA
  1. Set the RECID attribute as the anchor attribute.

  2. Create a join rule for the Telephone and metaverse person object types.

  3. Map the Telephone name attribute and the metaverse sn attribute.

  4. Create an import attribute flow for the Telephone and metaverse person object types.

  5. Rank metaverse telephoneNumber attribute precedence for the Fabrikam Telephone MA to 1, and the HR MA at to 2.

  6. Create a full import run profile with a Drop audit file that will create an Extensible Markup Language (XML) file of the data imported into the Telephone data source when the profile is run, and then run the profile.

  7. Verify the results of the MA run by using Operations and Metaverse Search.

Next

Community Additions

ADD
Show: