The Metaverse and the Connector Space

The Microsoft® Forefront Identity Manager (FIM) 2010 R2 metadirectory consists of two parts: the metaverse and the connector space.

The metaverse

The metaverse is a set of tables in the SQL Server 2008 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 FIM metaverse schema. When you install FIM, it creates a default schema with the following object types:

• computer

• domain

• group

• locality

• organization

• organizationalUnit

• person

• printer

• role

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

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.

Connector 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.

Disconnector objects

There are three types of disconnector objects: disconnectors, explicit disconnectors, and filtered disconnectors.

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

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.

Anchor attribute

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.

Warning

Because anchor attributes are used to uniquely identify an object in the connector space, it is very important that when you configure the management agent, you select an anchor attribute that will be immutable, or permanent. FIM treats all changes to anchor attributes as new objects, which can result in object deletions in the connector space, and through provisioning, can result in object deletions in other connector spaces.

For more information about anchor attributes, see Configure Attributes.

Transient

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, FIM 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.

Reference (DN) attributes

A Reference (DN) attribute is an attribute type whose value refers to another object. FIM 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	---	---

Reference (DN) attributes are also commonly used for group memberships. Similar to the example above, the member attribute of a group object can be configured to refer to the globally unique identifier (GUID) of a person object.

Object	Metaverse attribute	Value	Metaverse attribute	Value
Group	GUID	111	member	reference to GUID of person object (222)
Person	GUID	222	---	---

Important

For more detailed documentation on implementing Reference (DN) attributes, see "Simple Account Provisioning") at the Microsoft Web Site. (https://www.microsoft.com/) For more information about Allow Nulls, see Attribute Flow Rules.

Partitions

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.

Working together

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.