Planning the Metaverse for MIIS 2003

Applies To: Windows Server 2003 with SP1

Download Instructions

This document is available for download on the Web as a Microsoft Word document at https://go.microsoft.com/fwlink/?LinkId=30436.

Overview of Metaverse Planning

After the dataflow designer designs your data flow model, the metaverse planner plans the Microsoft® Identity Integration Server (MIIS) 2003 metaverse. During this process, the metaverse planner transforms the information contained in the dataflow design document from a logical view of the metadirectory to a physical design, producing a metaverse design specification that will be used by the rules planner to complete the rules document.

This topic is part of the Design and Planning collection of the Microsoft Identity Integration Server 2003 Technical Library.

The dataflow model — that is, the logical metadirectory design — is a set of policies that you need to implement in order to achieve your solution proposal. The design of a system dataflow model that was presented in the previous topic is a complete design of the object types and attributes that are required to meet your business objectives. However, you can implement that logical design in different ways, resulting in solutions that do the same job but have different characteristics for storage, performance, and coding.

One important task of metaverse planning is to turn related policies into a plan that describes the required metaverse objects and attributes, and their related flow rules, in order to address your identified requirements. The primary task of the metaverse planner is to analyze the gathered policies and determine the most appropriate implementation of the metaverse plan, turning the logical design into an efficient physical design — preferably, the optimal design.

Dataflow design policies are simple statements of the business requirements that are defined in your solution proposal and that drive the functional requirements of the solution. The dataflow design policies are at a logical level, rather than a physical level. You refine each statement so that it evolves into a precise policy of your business requirements. After you implement these policies, more specifically, after you plan and implement the metaverse and synchronization rules, the policies become physical level.

For example, the following sequence shows how a single business requirement evolves into a precise business policy:

• The policy begins as a simple statement of the business requirement: “Contracted labor should not be incorporated into the human resources database.”

• As you design the dataflow model (or metadirectory design), the policy evolves into a statement of your functional requirements: “Contracted labor will not be included in the metadirectory” or “Contracted labor will be provisioned to the telephone system but not human resources.”

• During the current design stage — the metaverse design stage — you refine the statement to become a physical-level policy. Assuming you took the first choice at the logical level, the business policy might become: “Contracted labor will be excluded by the WHERE clause of the delta import View in Lotus Notes” or “Contracted labor will be trapped by a Connector Filter on the Lotus Notes management agent.”

The collection of such policies guides the design of the metaverse and the synchronization rules. Unlike the dataflow designer, the metaverse planner must be aware of technical issues, such as the maximum row length in the HR SQL Server database table; the planner modifies the worksheets that were started earlier in the design process to reflect any changes made due to technical considerations. The major factors to consider are:

• Storage considerations — The physical characteristics or limitations of Microsoft® SQL Server™ 2000.

• Performance considerations — In the absence of any storage considerations, reducing processing overhead to a minimum.

• Complexity considerations — A modest reduction in optimal performance, or even reconsideration of a business requirement, might be acceptable if it reduces development efforts sufficiently.

For example, the logical metaverse design may have specified outbound attribute transformation rules that might be implemented more efficiently by using an inbound attribute transformation rule (and storing the transformed data rather than the raw data). Your design for the metaverse will affect the final requirements for the rule planners that follow.

Before you begin planning the metaverse, coordinate with the project team to ensure that you understand the deployment scenario. You need the completed solution proposal and the dataflow design document, which along with their attached worksheets, describe the solution. Take copies of these documents so that the logical design is kept as a record. You can then modify the documents according to the guidelines in this topic and add the new worksheets that are introduced in this topic. When your metaverse plan is complete, the project team needs to review the proposal, approve it, and then pass it on to the rules planner.

Figure 1: Steps in the metaverse planning process

For more information about creating the dataflow model, see “Designing a System Dataflow Model for MIIS 2003,” which is another topic in the Design and Planning collection of this technical library. For more information about creating the solution proposal, see “Initiate Your Identity Integration Project” in that same collection.

Metaverse Concepts

This section provides background information to use in planning your metaverse. It provides introductory information about the metaverse schema and about attribute flow rules, which you need to understand before you plan your metaverse.

For more information about the architecture of MIIS 2003, see Essential Concepts of Microsoft Identity Integration Server 2003 in the Technical Reference collection of the MIIS 2003 Technical Library at https://go.microsoft.com/fwlink/?LinkId=26499.

The metaverse is the data store used by MIIS 2003 to contain the aggregated identity information from multiple connected data sources. The objects in the metaverse provide a single global, integrated view of the identity data staged in the connector spaces. Metaverse objects are directly populated from objects that are staged in the connector space. They are unique to the metaverse and may contain operational data that is required by the synchronization process. Metaverse objects and their attributes are defined in the metaverse schema.

Metaverse Schema

Metaverse objects and their attributes are defined in the metaverse schema. The MIIS 2003 metaverse schema is extensible and based on a flat-data model (a non-hierarchical model). During installation, MIIS 2003 builds a default metaverse schema, which you can modify by using the Metaverse Designer feature in MIIS 2003. When you use the Metaverse Designer to make changes to the metaverse structure, the schema that is stored in Microsoft® SQL Server is automatically modified.

The schema can also be exported to an XML file along with other configuration information, and imported from such a file. This technique can be used to deploy a development metaverse schema to a production system.

The MIIS 2003 metaverse relies on two basic elements:

• Metaverse object types

• Metaverse attributes

Metaverse Object Types

The logical dataflow design might require that you create new object types and attributes for all but the simplest MIIS 2003 implementations. In planning the physical implementation of the logical design, you should document all changes and additions that you make to the metaverse object types. When you make additions, start them as copies of other object types, and modify them, as needed — especially the precedence policies.

For most MIIS 2003 implementations, you typically create a completely new schema. Optionally, you can modify the default schema rather than starting over. Regardless, be sure to remove unused attributes.

Table 1 defines the default object types that are supported by the metaverse and some of their commonly used attributes.

Object Type	Examples of Attributes
Person	assistant, comment, company, department, description, displayName, employeeID, givenName, personalTitle, postalAddress, surname
Computer	cn, description, displayName, I, location, manager, o, ou, seeAlso
Domain	company, dc, description, displayName, postalAddress
Group	cn, description, displayName, mail, mailNickname, manager, member, o, ou, seeAlso, uid
Locality	description, displayName, I, seeAlso, st, street
Organization	company, description, displayName, facsimileTelephoneNumber, I, o, physicalDeliveryOfficeName, telephoneNumber
organizationalUnit	company, description, displayName, I, ou, postOfficeBox, street
Role	company, description, displayName, member, ou, seeAlso
Printer	Cn, description, displayName, location, manager, o, ou, seeAlso

Although MIIS 2003 does not permit you to directly rename an object type, you can use the copy technique to achieve the same effect. For example, if you decide that the e-mail distribution groups are better represented by on object type called distributionGroup, you can copy the default group object type to a new type called distributionGroup and then delete the original group object.

Warning

Copying an object type copies only its structure and does not copy any data that it represents.

Metaverse Attributes

The metaverse schema has a predefined list of possible attribute types, some of which are indexable and multivalued. Part of the metaverse planner’s role is to define, for each object type, the required attributes and their characteristics.

Each metaverse object type has a set of default attributes that you can add custom attributes to. An attribute of a specified name that is used by any number of object types always occupies the same column in the metaverse table, which is contained in the MicrosoftIdentityIntegrationServer database in SQL Server 2000. Likewise, an attribute of the same name that is used by multiple object types has the same attribute type, such as whether it is indexed or multivalued.

Available Attributes

Only one set of attributes is available to all object types, but not all attributes are required for each object type. You can add a new attribute to an object type in the metaverse — that is, you can associate it with that particular object type — providing a name, data type, and other information. This new attribute is then available for use with any other object type.

For example, Table 2 shows some of the attributes that are defined within the default metaverse schema and some of the default metaverse object types that use them.

Table 2: Example of Available Metaverse Objects and Attributes

Metaverse Attribute	Person	Group Object
sn	Available	Not available
givenName	Available	Not available
displayName	Available	Available
member	Not available	Available
description	Available	Available
company	Available	Not available

By deleting an attribute that is used by a particular object type, you make the attribute unavailable for the object type; for example, that attribute is no longer available for metaverse import or export attribute flow or for joins. Any values that the attribute contained are also deleted. The attribute can still be applied to other object types; however, when the attribute is removed from all object types, the attribute is truly deleted and will be removed from the underlying SQL Server 2000 table that represents the metaverse.

Note

MIIS 2003 uses the displayName attribute as the general identifier in the user interface (UI), and a metaverse globally unique identifier (GUID), as the unique identifier for the object in the metaverse. Although MIIS 2003 provides and manages the GUID, you should populate the value of the displayName attribute to provide a user-friendly display name for each object. There is no system requirement that the displayName be unique; however, because it is typically used as an informal identifier, it is an MIIS 2003 best practice to make it unique.

Attribute Properties

A metaverse attribute has the following properties:

•Name

•Data type

•Value (whether multivalued)

•Indexed

Name

The name property identifies the attribute. Therefore, choose an attribute name that reflects the real-world value it will contain. Do not use a name that would confuse the rest of the team. For example, do not use or create an attribute called facsimileNumber to hold a mobile telephone number.

Data type

Use the Metaverse Designer to set a data type. Table 3 defines the possible data types. The data type you set determines how the metaverse stores data for the attribute.

Table 3: Data Types Defined for the Metaverse

Data Type	Description
String (indexable)	Characters or character bytes stored in either single or multiple values. Indexable string attributes provide fast access to data in the metaverse, if they are indexed.
String (non-indexable)	Characters or character bytes stored in either single or multiple values. You cannot index this attribute type, and you cannot change the type to indexable.
Binary (indexable)	Values expressed as combinations of the integers 0 and 1. You can store indexable binary attributes in either single or multiple values. If indexed, this data type provides fast access to data in the metaverse.
Binary (non-indexable)	Values expressed as combinations of the integers 0 and 1. You can store non-indexable binary attributes in either single or multiple values. However, you cannot index them or change them to an indexable type.
Number	64-bit integers with values ranging from -9,223,372,036,854,775,808 through +9,223,372,036,854,775,807.
Boolean	One of the following values: TRUE or FALSE. Boolean attributes can have only single values. You cannot index them.
Reference (DN)	Values that refer to another object. MIIS 2003 uses this attribute type to express relationships between objects. You can store reference (DN) attributes in either single or multiple values. You cannot index them. You can only flow references to references directly; you cannot use a rules extension-implemented rule with a reference attribute.

Note

Throughout the UI, you see distinguished name (also known as DN) associated with an anchor attribute and with reference (DN). DN associated with an anchor attribute. Reflects that all the connector space objects managed by a specific management agent must have either a unique DN for LDAP data sources or anchors. (An anchor attribute is a unique logical link, such as an employee number or user ID, between a connector space object and a connected data source object.) However, many Lightweight Directory Access Protocol (LDAP) data sources also have an anchor attribute. For example, an Active Directory® directory service globally unique identifier (GUID) has an anchor. Reference (DN). Reflects that any reference attribute for the connector space object stores anchors that are often distinguished names. However, a metaverse reference attribute stores metaverse GUIDs, not DNs (or anchors), and if you are a developer you should be very clear on this matter.

Typically, your choice of data type should follow that of the source data. Therefore, a name or a telephone number that is stored as a string in a connected data source flows through to a string type attribute in the metaverse. You can, however, use import or export flow rules to transform attribute values.

Before choosing transformations to other, nonstandard data types, review the following as a guide:

• A string data source that holds only “Yes” or “No” is more efficiently stored in a Boolean metaverse attribute.

• If your identity data is in two or more languages, such as English, French, and German, yes/no might also need to be oui/non or ja/nein. Also, consider a Boolean metaverse attribute to act as a central, non-language attribute. For example, consider that doctor, docteur, and doktor, (and other translations of doctor, as required by your database) might all be stored as title number 1 in a numeric data type.

• Many data items that are referred to as numbers (account numbers and serial numbers, for example) are actually strings, which are stored two bytes per character. You can save storage space by storing such data in number format; however, take care to ensure that you do not lose important formatting information, such as leading zeroes.

• Only binary and string types can be indexed. Therefore if you want to join an account number or employee number, store it as a string — preferably indexed, for better performance.

Only attributes that have the following data types can be used in a join condition:

• Binary (indexable)

• String (indexable)

• Number

• Boolean

If you intend to use a binary or string data type in a join, you must use the indexable types and index them whenever possible. You cannot change a non-indexable attribute to an indexable attribute (or vice-versa); so if you have any doubt whether you might need an index, make the type indexable if you can.

Indexable attributes are limited to 900 bytes (450 Unicode characters). Of the available data types, only string and binary can be indexed; so you should favor one of these two data types for any attributes that are used in a join operation. For example, even though a number data type might be appropriate for an account code, if you intend to use it as part of the join criteria, consider using an indexed string data type instead.

If multivalued

MIIS 2003 can support metaverse attributes with single or multiple values:

• Single-valued attribute. Can only contain one value that cannot exceed 900 bytes, if it is indexed, or 2 GB, if it is not indexed.

• Multivalued attribute. Can contain one or more values of the defined type; each element of a multivalued attribute can contain up to 900 bytes and must be unique.

A single-valued attribute cannot be directly mapped to a multivalued attribute. If this scenario is a requirement in your design, you will require a rules extension to implement your flow rule.

If indexed

Because indexable types can be indexed, you should use indexable types where they improve the performance of queries against the attribute. You should usually index any attributes that are used as part of a join or for other searching.

Both single-valued and multivalued attributes can be indexed. You can leave single-valued attributes unindexed but of the indexable type — in case you need to index them later — remembering that you cannot change the data type. For multivalued attributes, if the type is indexable, MIIS 2003 adds an index automatically.

Extending the Schema

MIIS 2003 provides a default schema. It is common practice to extend the schema if the default schema does not meet your requirements.

Operational Attributes

At times it is necessary to use an existing attribute or to create one for performing an operation. Attributes — non-operational attributes, that is — typically synchronize an object by flowing between connected data sources. An operational attribute, however, flows to the metaverse where it is used by the metaverse to make decisions.

The operational attribute is created by extending the schema and can be named for easy recognition. Like other attributes, you can define operational attributes; however, their distinction is in their function.

Attribute Flow Rules

Metaverse design is closely tied to import and export flow rules, which you use to define attribute mapping and flow direction. Therefore, the metaverse planner must have a good understanding of flow rules and ensure that the correct information is handed on to the rules planners.

Table 4 defines the attribute mapping types for MIIS 2003.

Table 4: Attribute Mapping Types

Mapping Type	Description
Direct	Defines a direct relationship between a single source attribute and a single destination attribute. The destination attribute is assigned the value of the source attribute, which cannot be modified by a rules extension. An example is flowing employeeID to userID.
Advanced	Defines a relationship between zero, one, or many source attributes and a destination attribute. Depending on the subtype, this mapping type can be a rules extension, constant, or distinguished name component.
Rules Extension	Defines a flow from one or more source attributes to a single destination attribute by using a rules extension. The value to which the destination attribute is set can be a manipulation of the source attributes plus any constant data. For more information about rules extensions, see “Building Rules Extensions for MIIS 2003” in this collection of the MIIS 2003 Technical Library.
Constant	Defines a constant value that is flowed to a single destination attribute. A destination attribute is not tied to any data source attribute.
DN component	Defines a numbered component of the distinguished name property of a connector space object that is flowed to a string attribute of a metaverse object. For example, “Redmond” is component 2 of cn=Stefan,ou=Redmond,dc=Microsoft,dc=com.

If any attribute mapping fails, the entire object synchronization transaction is rolled back, an error is reported, and the management agent runs with the next object.

Determining Precedence Order

Attribute flow can occur in both directions: inbound and outbound. A connector space object can flow attribute values to a metaverse object, and metaverse attribute values can flow from a metaverse object to a connector space object.

Multiple management agent rules can contribute values to the same destination metaverse object attribute. MIIS 2003 allows you to specify the precedence of one defined attribute mapping over others. Precedence can be a simple specification of an order by using the Metaverse Designer or a specific treatment in a rules extension. By default, the order in which management agents (MAs) appear in the UI determines precedence order.

In a typical identity integration scenario, objects from different connected data sources have different priorities for flowing attribute values to the metaverse and receiving updates from the metaverse. In a scenario where at least two different connector space objects are flowing attribute values from and to the same metaverse object, you probably need to determine the priority in which these values are applied.

MIIS 2003 stores with an attribute value, the priority of the object that contributed the value. The system rejects attempts to update an attribute value if they are made by an object with a lower priority. The same mechanism applies to export attribute flow. A metaverse attribute with a lower priority cannot flow to an object with a higher priority.

Using the Metaverse Object Design Worksheet to Decide Priority

The Metaverse Object Design worksheet that you began in the dataflow design document contains the precedence policies that the system dataflow designer identified. Although the metaverse planner makes the decisions during the current planning stage, two precedence issues require the attention of the rules planner:

• By defining additional object types in the metaverse design, you can avoid the need for complex precedence rules because you can define attribute flow rules in the user interface for each different object type.

• If you change the metaverse attributes and flow policies while you convert the logical design to a physical one, you may have to make modifications to the precedence policies.

Impact of Flow Rule Changes on Precedence

When you change the design from logical to physical, your changes can affect your flow rules: adding, changing, or removing flow rules; hence, you might need to make similar changes to precedence rules.

Whenever you change flow rules, always review precedence again. Tables 5 and 6 provide examples of two different logical designs, each having its own advantages.

Table 5: Outbound Transformations

Source	Precedence	Metaverse	Destination
MA1.sn	1	sn
MA1.nickName	2	givenName
MA1.givenName	1	givenName
		Sn + “,” + givenName	MA2.name
		Sn + “,” + givenName	MA3.name

In Table 5, nickName is used if givenName is null. At first glance, you might think that having two identical outbound transformations (for example, Sn + “,” + givenName) is wasteful and that the physical design in Table 6 is more efficient.

Table 6: Single Attribute Calculation

Source	Precedence	Metaverse	Destination
MA1.sn	1	sn
MA1.nickName	2	givenName
MA1.givenName	1	givenName
MA1.sn + “,” + MA1.givenName/nickName	1	name
		name	MA2.name
		name	MA3.name

The benefit you are hoping to gain by making the change shown in Table 6 is that the calculation of the name is only done once. (Note that the actual benefit depends on how many objects are associated with each management agent. For purposes of this discussion, assume that all other elements are equal.) However, the physical design in Table 6 uses a more complex precedence logic that requiresan additional precedence rule to go with the inbound attribute flow rule. This additional precedence rule must be done manually as a rules extension, rather than through simple precedence as before. Therefore, what initially appears to be a beneficial change that uses identical transformations is actually less efficient.

Next

• Process Steps for Planning the Metaverse