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

Disconnector objects

Placeholder objects

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

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.

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.

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.

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.

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

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.

---

---

Data sources

Partitions