Classic Metadirectory Walkthrough: Scenario Design
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:
Aggregate employee identity data from its five data sources while maintaining data source ownership over specific employee identity characteristics.
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:
The Microsoft Identity Integration Server 2003 system configuration for this scenario.
Rules that determine the object and attribute flow between the connected data sources and the metadirectory.
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.
.gif "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.
.gif "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.
.gif "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.
Note
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 |
|
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 |
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 |
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 |
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 |
Direct |
Import |
||
uid |
uid |
Direct |
Import |
uid |
mailNickname |
Direct |
Import |
| Exchange (groupOfNames object) | Metaverse (group object) | Mapping Type | Flow Direction |
|---|---|---|---|
rdn |
displayName |
Direct |
Import |
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 |
Direct |
Import |
||
uid |
uid |
Direct |
Import |
uid |
mailNickname |
Direct |
Import |
comment |
Advanced (Distinguished name part mapping) |
Import |
Note
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
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.
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.
Map the remainder of the selected HR data source and metaverse attributes as specified in the management agent attribute flow above.
Create and run a full import run profile.
Verify the results of the MA run by using Operations and Metaverse Search.
Fabrikam LDAP Data Interchange Format MA
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.
Specify one partition for distribution lists (distributionlists) and one partition for the individual mailboxes (mailboxes).
In the distributionlists partition, select groupOfNames and organizationalPerson.
Create a projection rule that projects the attributes of the Exchange groupOfNames object type to the metaverse group object type.
Create a join rule that joins the attributes of organizationalPerson to the metaverse person object type.
Map the attributes of organizationalPerson to the metaverse person object type.
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.
Map the attributes of groupOfNames to the metaverse group object type.
Rank the metaverse displayName attribute precedence for the Fabrikam LDAP Data Interchange Format MA at 1.
Create and run the full import run profile.
Verify the results of the MA run using Operations and Metaverse Search.
Fabrikam AD MA
Map user and group object attributes in fabnoa.fabcorp.fabrikam.com to metaverse person and group object attributes.
Rank the metaverse uid attribute flow precedence for the Fabrikam AD MA to 1.
Use Performance Logs and Alerts with the Fabrikam AD MA to monitor metadirectory performance.
Create and run a full import-export run profile.
Create and run an export run profile.
Verify the results of the MA run by using Operations.
Fabrikam Sun ONE Directory Server 5.1 MA
Map the inetOrgPerson Sun ONE Directory Server 5.1 object attributes to the metaverse person object with an import mapping type.
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.
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.
Create and run a full import run profile.
Verify the results of the MA run by using Operations.
Fabrikam Telephone MA
Set the RECID attribute as the anchor attribute.
Create a join rule for the Telephone and metaverse person object types.
Map the Telephone name attribute and the metaverse sn attribute.
Create an import attribute flow for the Telephone and metaverse person object types.
Rank metaverse telephoneNumber attribute precedence for the Fabrikam Telephone MA to 1, and the HR MA at to 2.
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.
Verify the results of the MA run by using Operations and Metaverse Search.