The Microsoft Identity Integration Server 2003 metadirectory consists of two parts: the metaverse and the connector space.
The metaverse is a set of tables in the SQL Server 2000 database that contains the combined identity information for a person or resource. Management agents update and modify the metaverse from multiple connected data sources, and in turn, management agents use the data in the metaverse to update and modify the connected data sources. The metaverse contains its own schema, which defines which object types and attributes the metaverse can contain. For more information about configuring the metaverse schema, see Using Metaverse Designer.
All objects in the metaverse must be one of the types defined in the Microsoft Identity Integration Server 2003 metaverse schema. When you install Microsoft Identity Integration Server 2003, Microsoft Identity Integration Server 2003 creates a default schema with the following object types:
Each object type contains a defined set of attributes. With Metaverse Designer, you can modify these object types and their attributes, and you can create additional object types and attributes. For more information, see Using Metaverse Designer.
When you create a management agent, you configure how the metaverse object types map to the object types in the data source. For example, a User object type in a data source might map to the Person object type in the metaverse, or a Distribution list object type in a data source might map to the Group object type in the metaverse. For more information about mapping object types, see Attribute flow rules.
The connector space is a storage area where object additions, deletions, and modifications are written before they are synchronized with the metaverse or the connected data source. A portion of the connector space is dedicated to each management agent. It is important to note that the connector space does not contain the connected data source object itself, but a shadow copy of the object that contains a subset of the object's attributes, as defined in the management agent.
The connector space can contain three kinds of objects: connector objects, disconnector objects, and placeholder objects.
There are two types of connector objects: connectors and explicit connectors.
| Type | Description |
|---|---|
| Connector | An object in the connector space that represents an object in a connected data source and is currently linked to an object in the metaverse. All management agent rules will still be applied to this type of connector. |
| Explicit connector | An object in the connector space that is linked to an object in the metaverse and cannot be disconnected by a connector filter. An explicit connector can only be created manually with Joiner, and it can only be disconnected by provisioning or by using Joiner. For more information about joining objects, see Using Joiner. |
There are three types of disconnector objects:
| Type | Description |
|---|---|
| Disconnector | An object in the connector space that represents an object in a connected data source and is not currently linked to an object in the metaverse For more information, see Using Joiner. |
| Explicit disconnector | An object in the connector space that is not linked to an object in the metaverse and can only be joined by using Joiner. For more information, see Using Joiner. |
| Filtered disconnector | An object in the connector space that is prevented from being joined or projected to an object in the metaverse based on connector filter rules in the associated management agent. For more information, see Using Joiner. |
Placeholder objects are objects in the connector space that represent a single level of the hierarchy of the connected data source. For example, if you want to synchronize objects with an Active Directory forest, you need to import the containers that make up the path for the Active Directory objects. In this example, CN=MikeDan, OU=Users,DC=Microsoft,DC=Com, placeholder objects would be created for DC=Com and DC=Microsoft,DC=Com. For more information about this scenario, see Using the management agent for Active Directory. Also, a placeholder object can represent an object in the connected data source to which an imported reference attribute value refers (for example, the object to which the manager attribute refers in a User object). Placeholder objects do not contain attribute values and cannot be linked to the metaverse.
An anchor attribute acts as a unique identifier for an object in the management agent's connector space. It can consist of a single attribute or a combination of multiple attributes from the connected data source. All attributes used for an anchor must be single-value attributes, or multi-value attributes with only one value. Typical candidates for an anchor attribute are unique attributes such as the employee ID or possibly distinguished name (also known as DN) for directories where the distinguished name is not subject to change. The anchor attribute is configured in Management Agent Designer.
Caution
For more information about anchor attributes, see Configure attributes.
When an object is imported to the connector space that has the same distinguished name attribute as an existing connector space object but a different anchor attribute, the existing connector space object is marked as transient. If more objects are imported with the same distinguished name and a different anchor attribute, each one will become transient. Only the last object imported with that distinguished name will be non-transient. Objects marked as transient remain in the connector space until they are updated with a new distinguished name, or are deleted from the connector space during a full import. In this last case, Microsoft Identity Integration Server 2003 assumes that because the object does not exist in the connected data source, it was deleted, therefore it will be deleted in the connector space.
A Reference (DN) attribute is an attribute type whose value refers to another object. Microsoft Identity Integration Server 2003 uses the Reference (DN) attribute type to express relationships between objects.
A common application for the Reference (DN) attribute type is for the manager attribute of a person object type. In this example, when you configure the management agent for the connected data source, you set the anchor attribute for the connected data source to employeeID. Next, define the manager attribute as a Reference (DN) attribute type, and then configure the attribute flow so that the connected data source attribute manager maps to the metaverse attribute manager, which is defined by default in the metaverse schema as a Reference (DN) type.
After the data source objects are synchronized with the metaverse, the metaverse manager attribute of the object now references the employeeID attribute of the employee's manager. When you view the properties of a metaverse object that is configured in this way, the value of manager is displayed as a link to the manager object. The following table illustrates this example.
| User | Metaverse attribute | Value | Metaverse attribute | Value |
|---|---|---|---|---|
| Employee | employeeID | 123 | manager | reference to employeeID of manager (456) |
| Manager | employeeID | 456 | --- | --- |
| Object | Metaverse attribute | Value | Metaverse attribute | Value |
|---|---|---|---|---|
| Group | GUID | 111 | member | reference to GUID of person object (222) |
| Person | GUID | 222 | --- | --- |
Important
The connector space of each management agent can be divided into multiple partitions. A management agent partition is a logical memory space where processing of an object and attributes in the connector space take place. Each management agent has one partition by default. Partitions are configured in the Management Agent Designer, and each object type must be assigned to a partition. An object type can only be assigned to one partition, although each partition can be linked to multiple object types. Configuring additional partitions is not required, but is recommended for more efficient processing where a large number of logical object groupings exist. A partition must be specified when creating a run profile. Only the objects in that partition will be processed when the run profile is run.
The following illustration shows a management agent that is configured with two partitions, Partition 1 and Partition 2. The object type Person is assigned to Partition 1, and the object type Group is assigned to Partition 2. The run profile PersonOnly is configured to process only object types that are assigned to Partition 1, and the run profile GroupOnly is configured to process only object types that are assigned to Partition 2.
When you run a management agent, changes that you make to objects in the connected data source are written to the connector space, management agent rules are applied, and the resulting data is then written to the metaverse. Then, the metaverse sends those changes to the connector space of other connected data sources that the object might be synchronized with, and their respective management agents propagate the changes to those connected data sources. For more information about management agent rules, see Understanding management agent rules.
The following illustration shows the flow of data from one data source to two other data sources.
