Design Concepts for Advanced Solution Components

About This Guide

The success of an identity integration solution is closely tied to the quality of the planning you do upfront. To properly design and plan an identity integration solution, you must have a complete understanding of how the design decisions you make affect the data flow in and out of the Microsoft® Identity Integration Server (MIIS) 2003 environment. The key to making good design decisions is to understand the entire process (global picture) of designing a solution as well as the nuances of how the different components in an MIIS environment work together. To create the most efficient solution, you must have a good idea about how to design your implementation to take advantage of those nuances. The pertinent information that will assist you in your solution-development effort is covered in the MIIS Design and Planning Guides.

In this set of documents, you will find detailed discussions of specific challenges that are often encountered during the design of MIIS solutions. These documents present some of the most common design issues that are discussed in newsgroups and in e-mail discussion groups. In each document, you will find the following:

• Detailed explanations of particular design challenges.

• Possible solutions with best recommendations.

• Discussions of the pros and cons of potential solutions.

These challenges, and their proposed solutions, have been discovered and documented through numerous discussions with MIIS deployment experts. Once documented, further review cycles have been conducted on each solution by several MIIS deployment experts from both within and outside Microsoft.

While these guides present information about specific design challenges, anyone doing any type of MIIS design work might find them interesting. These solutions can provide insight into design issues not specifically addressed in these documents.

We hope you find these documents useful. If you would like to discuss the content of a document or if you have any questions, feel free to post a message on the MIIS newsgroup on the Microsoft Web site (https://go.microsoft.com/fwlink/?linkid=68184).

Prerequisites

This document is targeted at advanced MIIS users. It is written with the assumption that you have:

• A good understanding of the different components in MIIS 2003 and how they work together.

• An understanding of MIIS concepts such as aggregated view in the metaverse, reference attributes, and identity information import and export.

Advanced Solutions for Identity Integration Challenges

In an Identity Integration Scenario, the primary goal is to collect identity information from various connected data sources into one logical view of an identity and to share the authoritative identity data with the connected data sources. To implement an identity integration solution, MIIS 2003 provides the required components such as management agents and a customizable set of synchronization rules. You can find documentation in the Technical Library for MIIS 2003 available at https://go.microsoft.com/fwlink/?LinkId=70861 that explains how these components work and how you should use them in your solution. Some scenarios, however, require special solutions that are not directly covered out of the box.

In this document, you will find examples of how some MIIS components can be used to provide special solutions for specific tasks. You will learn how:

• Real-world attributes of an identity can be used to store information that supports the identity integration process.

• Metaverse objects can be used to improve the efficiency of the identity integration process and to handle identity data with issues.

• Management agents can be used to implement a reprocessing solution for identity data and how management agents can handle external operations in an identity integration scenario.

Understanding Process-Level Attributes

An identity data object is constituted by its attributes. The goal of an identity integration scenario is to aggregate the authoritative data parts distributed among various connected data sources into one logical view of an identity and to update non-authoritative identity data parts with authoritative data. Some attributes of a digital identity are used to characterize a digital identity within a given context. For example, the samAccountName attribute of a security principal in an Active Directory® directory service is a string-based unique identifier that identifies it within an Active Directory domain. The samAccountName attribute represents the logon name of a user within Active Directory. Other attributes of a digital identity have a global meaning. For example, the first name and last name of a physical identity should ideally have the same attribute value across all connected data sources where a given digital identity is defined.

Another category of attributes associated with a digital identity are process-level attributes. Process-level attributes are used to describe certain characteristics of the associated real world identity related to the identity integration process. In the MIIS 2003 Design Concepts for Correlating Digital Identities document available at https://go.microsoft.com/fwlink/?linkid=58875, you can find an example of a process-level attribute. A correlation ID is used to establish robust link relationships of related identity data parts across various connected data sources. Other examples for process-level attributes are attributes to express the role of an object within the identity integration process and the digital identifier of the authoritative master of an object.

While most attributes are used to store meaningful information about an object or its characteristics related to the identity integration process, there is also one example for a process-level attribute that does not contain information describing an object – the process-level "flip attribute".

The following section explains how a process-level Flip attribute can help improve the process of convergence in an identity integration scenario.

Using a Flip Attribute to Improve the Convergence Efficiency

In an ideal MIIS environment, the goal of the system is to process identity data changes received from different connected data stores. These changes are stored on the objects in a connector space. To process identity data internally, MIIS supports two different synchronization run types – full synchronization and delta synchronization. During a full synchronization, all objects staged in a connector space are processed and all of the synchronization rules are applied to them. In general, a full synchronization should only be initiated in case of synchronization rule changes. MIIS uses a full synchronization run to ensure that all the existing data abide by the changed rules. This is not an efficient operation because all of the objects in the connector space must be processed. Depending on the number of objects staged in a connector space, running a full synchronization can be time-consuming. Conversely, during a delta synchronization run, only objects and attributes with staged changes are processed.

In the documents titled, "MIIS 2003 Design Concepts for Implementing Reverse Joins" and "MIIS 2003 Design Concepts for Managing Reference Attributes" available at https://go.microsoft.com/fwlink/?linkid=58875, you can find examples for identity integration scenarios where certain objects may require to be reprocessed. If you need to reprocess certain objects and you want to avoid processing all objects in a connector space, you can simulate “new identity data” by using a flip process-level attribute. This attribute is implemented in form of a Boolean that is changed in the connected data source if a simulated change is required on a connector space object.

After importing objects with the a changed flip attribute value, you have a staged change on a connector space object that will cause the object to be processed during a next run of a delta synchronization run.

Implementing Process-Level Attributes

The driving factor for implementing a process-level attribute is a solution requirement. You must ask the following questions:

• Is there a need in your environment to synchronize a set of objects that do not have staged changes to real-world objects?

• Do you need to look up the master object for given object in a connected data source?

• Do you need to store provisioning targets with an object?

As soon as you have determined a requirement for a process-level attribute, you need to check your connected data sources for extensibility. Not all connected data sources are extensible and even if they are extensible the owner of a connected data source might be reluctant for a schema extension. If it is not possible to extend the schema of a connected data source, you should evaluate whether storing the attribute in the database of an operational management agent would solve your business problem. You can find more details on operational management agents later in this document.

As a next step, you need to determine an appropriate attribute type to store your value. While a Boolean attribute perfectly covers the needs of the "flip attribute", a Boolean might not be sufficient to store the information about an issuing authority. Besides the role of an object (if it is authoritative or not), you may also want to store the information about the authoritative object with a non-authoritative object. For example, each object in Active Directory is uniquely identified by a GUID. By implementing the authoritative or non-authoritative relationship as GUID value, you can not only determine whether an object is a master, you can also determine who the associated authoritative object is in case of a non-authoritative object. As you can see in this example, while the Boolean gives you the required information, the GUID value would help you to store more information in the operational attribute.

The last of the implementation steps consist of a metaverse extension and the required configuration of attribute flow rules for your operational attribute.

Conditional Metaverse Objects

In MIIS, the metaverse represents the central store for identity data. Identity data attributes received from various connected data sources are aggregated in the metaverse based on a well-defined set of synchronization rules. A metaverse object represents the authoritative view of a given identity. Metaverse objects are created and updated on the basis of identity data that has been staged on connector space objects. The inbound synchronization rules determine whether identity data is processed towards the metaverse. The set of inbound and outbound synchronization rules form a data processing chain into and out of the metaverse. Changes applied to a metaverse object by the inbound synchronization rules trigger events for some of the outbound synchronization rules. For example, a change applied to a metaverse object that is not its deletion, triggers the provisioning function.

There are cases where you do not want a connector space object to be processed towards the metaverse. The most obvious case is when a connector space object has incomplete or even incorrect attribute values. These imperfect objects are typically blocked in the connector space. Such objects are called filtered disconnectors. The term “blocked” in this context refers to preventing connector space objects from being further processed based on connector filter rules in the corresponding management agent. The evaluation result of the attribute value of the filtered disconnector ensures that these connector space objects remain disconnectors in the connector space.

Figure 1: Imperfect objects are blocked in the connector space

An applied disconnector filter is not the only reason to block objects in the connector space. Even if a given connector space object has valid attribute values, you may not want to process the object towards the metaverse. This is the case when a connector space object is not authoritative for the creation of a metaverse object. Metaverse objects are created by the projection synchronization rule. In most identity integration solutions, projection is only configured for authoritative connector space objects. For example, in case of a Global Address List (GAL) synchronization scenario where user objects are synchronized as contacts, the user object is the initiating factor. A contact object, even if it has valid data, cannot contribute any data to the metaverse as long as the authoritative user object is missing. From the implementation perspective, the projection rule is only configured for user objects and contacts have only a configured join synchronization rule.

While these are good reasons for blocking objects in a connector space, this "filtered disconnector" strategy comes with various disadvantages:

• Blocked objects are disconnectors. A disconnector also means a pending import. All pending imports are processed during a delta synchronization run. This is regardless of whether new identity data has been staged on a disconnector between two delta synchronization runs.

• Blocked objects are “hidden” from the identity integration process. The connector space is not searchable. This can cause hidden or visible conflicts as discussed in the MIIS 2003 Design Concepts for Implementing Reverse Joins document available at https://go.microsoft.com/fwlink/?linkid=58875.

• Blocked objects cannot be updated by the identity integration process. Staging outbound identity data updates on a connector space object requires a connection to a metaverse object. In case of a connection to a metaverse object, identity data updates can be pushed out to a connector space object in form of export attribute flow.

It is possible to address these issues by using conditional metaverse objects. A conditional metaverse object represents an object of a specific type that is defined to address the issues associated with blocking objects in a connector space. All other available object types in the metaverse are in this document referred to as regular object types.

In the following sections you will find more details on introducing conditional object types and how these objects can help address the issues associated with the most common blocking scenarios.

Using Conditional Metaverse Objects for Objects with Missing or Incorrect Attribute Values

As outlined in the previous section, from the perspective of an ideal environment, where the metaverse has an aggregated authoritative view of identity data, it makes perfect sense to prevent certain objects from being processed towards the metaverse. This specifically applies to connector space objects with incorrect or incomplete attribute values. However, blocking connector space objects from being processed towards the metaverse comes along with some considerations. In case of a connector space object with incomplete or incorrect attribute values, just blocking the object does not resolve the issue. The attribute-related issue must be fixed eventually. If an object is blocked in the connector space, you will have to apply the fix in the connected data source. From within MIIS, you cannot stage attribute value corrections on objects that are disconnectors. The import and export attribute flow in MIIS happens between a connector space object and a metaverse object that is linked to it. In this scenario, you will have to find a solution that alerts an MIIS administrator about the issue, and you need to define a process to inform the administrator of the related connected data sources about the issue and to get it fixed.

A better approach to this scenario is to bring connector space objects with missing or incorrect attribute values into the metaverse. However, ensure that you do not project these connector space objects a regular object types, but with an object type that is intuitive enough to indicate an object with issues.

The following figure illustrates this scenario:

Figure 2: Imperfect objects projected into the metaverse

For example, in case of a GAL sync scenario, you could define an mvGALError object type and project imperfect connector space objects with incomplete or incorrect attribute values as mvGALError objects into the metaverse. This practice has two significant benefits. If a connector space object is blocked in the connector space as disconnector, the object is marked as a “pending import”. Objects marked as pending imports are always processed during a delta synchronization run. This is independent from whether new identity data has been staged on a connector space object or not between two delta synchronization runs – pending imports are always processed. By keeping a high volume of disconnectors in a connector space, the data processing capabilities of your environment are used inefficiently. You can avoid this inefficiency by processing objects towards the metaverse. If a connector space object has been brought into the metaverse, synchronization rules are not applied to it during a delta synchronization run unless new data has been staged on it. Processing connector space objects towards the metaverse helps you to utilize your processing capabilities more efficiently.

The other benefit of this solution is the fact that you do not need to apply significant changes to your synchronization logic. The outbound case – especially your provisioning function method– might require one line of code that exits the method in case of an outbound trigger that was set by a mvGALError object. The logic for the regular objects is not affected.

Up to this point, we have discussed how processing imperfect objects towards the metaverse can help improve your data processing logic. However, you still need to fix the problem in the connected data source. If you also want to fix the attribute-related issue from within MIIS, you can certainly do this. As soon as an object is in the metaverse, you can apply data updates to it and flow them out. One possible strategy to fix attribute value-related issues is to use an operational management agent. You can find more details on operational management agents later in this document. The objective of such a management agent is to extract of objects requiring special attention into a separate data store. In case of imperfect objects with inaccurate or incomplete data, you could provision them into the connector space of an operational management agent and connect the data source that is tied to this connector space with an application that provides access to these objects. The attribute values can then be fixed either automatically or manually. These identity data fixes can then be applied back into the system. With this technique, you can fix identity data-related issues from within your MIIS environment. A connected data source is considered to be from within an MIIS environment if the data ownership does not cross organizational boundaries. In other words, you do not need to contact other administrative authorities to access and update the data. Such a data source has to be located close to the MIIS environment to reduce the impact of network issues on a given scenario to a minimum.

Since the entire logic of this construct is tied to a conditional metaverse object, it is possible to scope the required synchronization logic to it. In this case, the synchronization logic for the regular objects is not affected.

As outlined in this section, using conditional metaverse objects can help address issues associated with imperfect connector space objects. By using an operational management agent as an extension to your conditional metaverse objects, you can also fix issues related to identity data that prevent an object from being processed within the logic of your regular scenario.

In the next section you will find information about how conditional metaverse objects can help improve the convergence speed of your environment.

Using Conditional Metaverse Objects to Improve the Efficiency of the Identity Integration Process

In the previous section, you have learned how conditional metaverse attributes can be used to address imperfect connector space objects. You can also use this technique to improve the efficiency of your identity integration process, which is the subject of this section

One important concept in an identity integration scenario is data authoritativeness. This means, that specific operations in an identity integration scenario can only be initiated by objects fulfilling specific requirements. For example, a metaverse object represents the aggregated view of an identity and can have several links to various connector space objects. This architecture of linked objects requires one connector space object to be the initiator of the metaverse object creation. Technically, this process is called projection. At least one connector space object has to have a configured projection rule to create a metaverse object. Existing connector space objects can now establish a link relationship to the metaverse object, which has to be initiated by a configured join rule.

In a typical identity integration scenario, you configure a projection rule only for specific objects – objects that fulfill your requirements to create a metaverse object. The basic idea of a Global Address List (GAL) synchronization scenario is to distribute the existence of a user object in one forest as a contact in other forests. In this scenario, the user object is the driving factor. This also means that a projection rule has to be defined for the user object. Ideally, the user object is also the driving factor for the creation of corresponding contact objects. This means, that contacts are created in a target connector space during a provisioning phase that has a user object as the initiating factor.

However, there are scenarios where a user object and related contacts already exist, but are not linked yet to each other. This can happen, for example, if the contact representation of a user was created manually in a target connected data source. To address the cases where a related object already exists, and does not need to be created during provisioning, a join rule enabling an object to be linked to a metaverse object is configured. In our current example, a join rule is configured for contact objects.

MIIS is a convergence engine. This means, that the identity integration process is independent from a specific processing order. Regardless of the order in which run profiles are started, the system eventually generates the desired results. While you can fully rely on the concept of convergence, it is sometimes desirable to have an impact on the timeframe in which related identity data parts are aggregated. In the MIIS 2003 Design Concepts for Implementing Reverse Joins document available at https://go.microsoft.com/fwlink/?linkid=58875, you can find an example of implementing a reverse joins to improve the convergence process.

One initial thought in conjunction with the GAL example could be to configure a join rule for user objects and a projection rule for the contacts. However, if this is to be done on the basis of the regular object type (for example, a person), it would result in more complex synchronization rules and also result in unnecessary triggers of these rules. For example, if a contact projects a person object, this would cause provisioning to be triggered. The provisioning logic will need to determine that the triggering source was the contact object that does not have an authoritative user object linked to the metaverse object.

In this document, we have already provided a motivation for processing connector space objects towards the metaverse. This recommendation is still valid, even in our current analysis of a simple GAL sync scenario. This means, that it is still a good idea to configure a projection rule for the contact object. However, the rule should not result in the projection of the regular object type but a conditional metaverse object, for example an object of type mvUnknown.

There are several benefits in using this concept:

• If a disconnector becomes a connector, the object is not a pending import anymore. The object will not be processed unnecessarily during successive delta synchronization runs.

• It is very simple to reduce the complexity of the provisioning logic. You can simply check the object type of the metaverse object that is associated with the provisioning trigger. In case of an mvUnknown object, you can immediately exit the procedure.

• There is no need to configure other synchronization rules like export attribute flow. A synchronization rule that is not configured will not be called at all.

• In comparison to the connector space, the metaverse is searchable. By maximizing the amount of identity data in the metaverse, you can reduce the possibility of conflicts.

A conditional metaverse object is another example of a concept that helps to improve the convergence process in MIIS.

However, there is one step that is still missing in this discussion on using conditional metaverse objects to improve the process of convergence – that of making the mvUnknown object a regular object.

This requires a join rule to be configured for user objects. In case of at least one matching join partner, the ResolveJoinSearch function is consulted. Besides determining a right match for a join scenario, this function also has the power to change the object type of a metaverse object. In case of a matching mvUnknown object in the metaverse, you can specify the regular object type in this function. That way, the conditional metaverse object is converted into a regular metaverse object.

Using conditional metaverse objects is a very powerful technique to improve the efficiency of identity data convergence in your environment. You should also read the MIIS 2003 Design Concepts for Implementing Reverse Joins document available at https://go.microsoft.com/fwlink/?linkid=58875 to get related information.

Implementing Conditional Metaverse Objects

The implementation of conditional metaverse objects is a relatively simple task. Since it only requires an extension of the metaverse, there is no need to coordinate this step with an owner of a connected data source. However, thorough planning is required in conjunction with the required updates of the synchronization rules. You must pay special attention to the ResolveJoinSearch method in case of required object type changes.

Operational and Auxiliary Management Agents

In MIIS, the role of a management agent is to act as an interface between MIIS and a connected data source storing real world identity data. Management agents import identity data from and export identity data to connected data sources. The identity data maintained in a connected data source is typically required to support the requirements of a directory service or an application. In such an environment, MIIS typically functions as a convergence engine ensuring that all connected data sources contain authoritative identity data.

This section discusses how you can use management agents to support the identity integration process. The two examples covered in this document are Operational and Auxiliary management agents.

Understanding Operational Management Agents

In some identity integration scenarios, it is desirable to have access to identity data aggregated in the metaverse. However, direct access to the metaverse database is not supported because changing the data outside the identity integration process can generate unpredictable results that can even cause the system to crash in some cases. An alternative to this is to change the identity data directly in a connected data source, which is not always possible. For example, the owner of a connected data source might not be willing to provide you access to an administrative console that is required to make changes or you might want to apply changes programmatically.

By using operational management agents, you can implement access to metaverse data in a supported manner.

Note

An operational management agent is not a new management agent type. The term “operational management agent” describes the specific usage of a management agent in an identity integration scenario. Unlike a regular management agent that you use as a data pump between a connected data source and MIIS, you use an operational management agent as a data repository for imperfect objects.

The following figure illustrates this scenario:

Figure 3: Imperfect objects are provisioned into the connector space of an operational management agent

You can use any of the available management agents as an operational management agent according to your personal preferences. The most common operational management agent type is the File MA because it requires the least amount of configuration. Besides the configuration complexity, the number of objects that are supposed to be maintained in an operational management agent is another consideration aspect. In case of a large number of objects, using a SQL management agent is more suitable. However, there is no technical limitation for using a specific management agent type as an operational management agent.

There are two common strategies for operational management agents:

• Operational management agents based on data from MIIS.

• Operational management agents based on data from an external data sources.

In case of an operational management agent that is based on data from MIIS, the content of its database is based on identity data provisioned from MIIS into it. You can then create an application on top of this data source to establish an indirect access to the metaverse data. Such a solution, however, increases the complexity of your overall identity integration solution. After each run of a run profile on a regular management agent, you will also have to run the related run profile on the operational management agent to keep the data in the data source of the operational management agent up-to-date. Other synchronization rules like provisioning and the object deletion rule will need to have the required logic to update the data in the connector space of the operational management agent appropriately.

Operational management agents that are based on data from an external resource are an alternative to the management agents that are based on data from within MIIS. For such a management agent to work correctly, you need a mechanism that generates a list of valid metaverse objects. At a minimum, that list must contain one attribute that enables the system to establish robust joins. You can find more details about robust joins in the MIIS 2003 Design Concepts for Correlating Digital Identities document available at https://go.microsoft.com/fwlink/?linkid=58875. Ideally, this attribute is the metaverse GUID. However, it is also possible to use any other digital identifier that is maintained in the metaverse.

Operational management agents that are based on data from an external resource are a helpful solution in scenarios where you need to apply operations on a smaller set of objects in the metaverse. For example, if you need to clear the value of a metaverse object and if the import attribute flow of the authoritative master for that object has been removed; you can use this type of management agent to accomplish this task. With the correct list of affected objects, you can establish robust joins and flow the desired values into the metaverse.

This solution is simple to implement since you only need to take care of inbound synchronization rules – in the current case, a join synchronization rule and an import attribute flow.

To summarize, an operational management agent is a useful tool to quickly apply identity data changes to the data stored in your environment. The data store associated with such a management agent should not used as a long term management repository for real world identities, but as a store for identities requiring special attention.

Implementing Operational Management Agents

The implementation of an operational management agent starts with determining objects that require “special attention”. The objective of an operational management agent is to isolate these objects in a connected data source. As a next step, you need to determine the type of connected data source that best suits your needs. There are no best practice recommendations for a specific type of a connected data source. The decision is a matter of personal preferences. The most common management agents used to implement operational management agents are the File MA and the SQL MA. However, other management agents would work as well.

The objective of an operational management agent is in most cases to perform some sort of operation that is performed asynchronously from a SQL-transaction of your regular management agent. For example, you may need to create a home directory for a user that is being provisioned by your regular management agent. The best practice recommendation, however, is to not call anything outside of MIIS from within a rules extension. In this scenario, you have to create the home directory by a separate process. Your synchronization logic can, in such a scenario, provision the new user to a target connector space and also to a connector space that collects users requiring a home directory. A process sitting on top of the connected data source associated with the operational management agent will then take care of creating the home directory.

In this example, it is important to ensure that the asynchronous operation of creating a home directory will eventually be synchronized with the process of provisioning a new user. From the technical perspective, this could mean that the user account is initially created as a disabled account, which is enabled as soon as the operational management agent provides a success status for the creation of the associated home directory.

Note

Your synchronization rules design should take this kind of (asynchronous) process dependencies into account. According to these dependencies, you need to plan and implement the synchronization rules in your solution. It is in this context also important to mention that this scenario adds dependencies to the configuration of your run profile schedule. If a management agent is implemented as a spin-off to an identity integration process, you should run an export on the operational MA in parallel or at least close to the export of your regular management agent.

Understanding Auxiliary Management Agents

MIIS 2003 is a great convergence engine. The architecture of the system ensures that all identities will eventually reach a desired state. For example, in case of a GAL-synchronization scenario the desired state is to have associated contact objects in one or more forests for each authoritative user object. To implement this state, MIIS may have to create contacts for the authoritative user objects in the configured forests.

MIIS not only creates the initial contacts for authoritative user objects, it also keeps this relationship intact over time. If a contact that was associated with an authoritative user object gets deleted, MIIS recreates that contact to reestablish the desired state. This is a repetitive process that is active until the authoritative user object gets deleted in a connected data source. This process works independent of the order in which the available run profiles in this scenario are triggered.

However, reaching this state in some scenarios require several runs of run profiles and also depends on the availability of staged identity data, and turning a connector space object into a pending import, which is processed during a next run of a delta synchronization run profile. One reason for the reprocessing requirement is the fact that objects are processed in a random order during a synchronization run. The complete inbound and outbound synchronization cycle is applied to each object that is due to be processed in a processing chain.

However, some synchronization decisions for a given object depend on attribute values of other objects. If these other objects have not been processed at the time a given object is processed, attribute level calculations requiring the attribute values of the object that has not been processed, cannot be completed. In this case, the calculation of the attribute level will have to be postponed to a next run cycle.

A practical real world example for a processing order dependency in MIIS 2003 is the process of calculating reference attributes. For example, if you have two objects (Object A and Object B) in a connector space, and if Object A has a reference to Object B and Object B has not been processed at the time when Object A is processed, the referential relationship cannot be resolved. In case of direct mapped reference attribute flows, MIIS 2003 provides a reprocessing logic to resolve the reference relationship. If a reference relationship cannot be resolved within the initial synchronization run, the object is marked for reprocessing. At the end of the first synchronization cycle, an additional attempt to resolve the reference relationship is performed again for all objects that are marked for reprocessing.

The following flowchart illustrates this process:

Figure 4: Lightweight provisioning process

You can find more details about this topic in the MIIS 2003 Design Concepts for Managing Reference Attributes document available at https://go.microsoft.com/fwlink/?linkid=58875.

To summarize, in an identity integration scenario, you will sometimes find cases in which it would be helpful to reprocess certain objects that have already been processed within one synchronization run. By design, you have two options to ensure that the object is reprocessed:

• The full synchronization run profile

• A staged identity data change

During the run of a full synchronization run profile, all objects in a given connector space are processed. This run profile type was originally implemented to address the case of an applied change to one of the synchronization rules. Since such a change may have an impact on the processing results on all objects, including the objects that have already been processed, it is necessary to determine the impact of a synchronization rule change on the basis of all objects. However, running a full synchronization profile can be a very time-consuming operation, especially, if a large number of objects have been staged in a connector space. For the current scenario in which certain objects are supposed to be reprocessed, this run profile type represents a less than ideal solution, since the ratio of objects that require reprocessing is in most cases relatively low in comparison to the sum of all connector space objects.

On the other hand, during a delta synchronization run, only those connector space objects that are pending imports are processed. This includes disconnectors as well as objects with staged new identity data. Getting objects reprocessed during a delta synchronization run, would require a staged update for the reprocessing attributes. Even, if such a staged update were available, a delta synchronization run also processes all disconnectors that are not part of the reprocessing scenario. This means, that even the delta synchronization run could potentially cause a large amount of objects to be processed.

The ideal solution to address the reprocessing challenge is a solution that only processes objects requiring reprocessing. While a full synchronization run profile is an inefficient solution for a regular connector space, running a full synchronization on a connector space that only consists of objects that should be processed can be an efficient method. The challenge here is to get these objects isolated into a connector space. The solution to this challenge is also known as Auxiliary Management Agent.

By using Auxiliary Management Agents, you can leverage the connector space of this MA to store a record of objects requiring reprocessing.

For details on implementing an Auxiliary MA, see the MIIS 2003 Design Concepts for Managing Reference Attributes document available at https://go.microsoft.com/fwlink/?linkid=58875

Summary

In this document, you have been introduced to a collection of operational solution components. Operational solution components are a collection of tools enabling you to solve various challenges in typical identity integration scenarios. Some of these components address the same challenge. For example, the goal of a flip attribute and an auxiliary management agent is to provide a solution to reprocess certain objects. The major difference between both solutions is that a schema extension and physical changes to real world identity data is required in case of a flip attribute, while this is not necessary in case of an auxiliary management agent. However, implementing auxiliary management agents requires updates to your synchronization logic, which increases the complexity of your identity integration solution. Which is a better solution depends on scenario constraints and personal preferences.