Authority and Precedence
Applies To: Windows Server 2003 with SP1
Previous Sections in This Guide
If a data source is identified as being authoritative for data stored in the metadirectory, when data is imported into the metadirectory from an authoritative source, the imported value overwrites whatever is currently stored in the metadirectory regardless of the value’s source.
MIIS 2003 allows multiple data sources to create, modify, and delete objects that participate in synchronization. Therefore, objects stored in the metadirectory might contain data from multiple data sources. For example, a User object might contain information that was imported from an HR database and information that was imported from Active Directory.
Sometimes the data stored in a single attribute comes from multiple data sources. A user stored in the metadirectory by using a person object has a displayName attribute. This attribute could be populated by using data from Active Directory or the HR database.
When multiple data sources supply data to the same attribute, precedence must be established that identifies the most authoritative data source down to the least authoritative. In the current example, the precedence for authority over the displayName attribute of the Person object in the metadirectory is:
The HR database
Active Directory
Both are allowed to import data to the attribute but the HR database value will always overwrite the Active Directory value.
Active Directory can import a value to the displayName attribute if the currently stored value in the metadirectory is null. However, if Active Directory imports a value to the user’s displayName and then the HR database imports a value, the Active Directory value is overwritten because the HR database is authoritative for that attribute.
Implementing Authority and Precedence
The metadirectory implements authority and precedence by applying rules based on the policies outlined in the dataflow design. The dataflow designer must clearly define the policies that are required by your solution so that the rules designer can construct suitable rules that provide the correct authority and precedence.
Focus on documenting the following:
A logical description of which data sources are authoritative for each metaverse attribute and under what circumstances.
The circumstances that will cause metaverse object creation (projection) and deletion.
The metaverse and rules planners will implement these policies appropriately.
Attribute Authority and Precedence
In simple cases, each metaverse attribute obtains its precedence values from a single flow rule. For example, the employeeID might be provided by the human resources system, e-mail by Exchange, and the telephoneNumber by a phone system. Different rules are authoritative for different attributes, and the connected data sources behind them can also be authoritative.
In more complex cases, you can configure a number of rules to provide a value for the same attribute, and each rule is potentially authoritative for that attribute. A precedence rule is defined in order to decide which rule has priority or goes first. Depending on the precedence rule, different rules (and hence different data sources) can provide the relevant values for different object instances. In other words, the authority is with different data sources for different object instances.
Examine another example: in a global address list (GAL) synchronization scenario, multiple e-mail systems can project objects of the type person to the metaverse. These objects must be provisioned out to all other e-mail systems with an authoritative e-mail address if a global address list is to be built for each different e-mail system. In this case, the e-mail system that projects the object to the metaverse is clearly the authoritative source for that e-mail attribute; but for another object instance, a different source could be authoritative. The way MIIS 2003 decides which to use in each case is determined by a precedence rule.
Object Authority and Precedence
Object precedence is less obvious than attribute precedence; for example, there is no formal UI rule for defining which data source has precedence for object creation or deletion. Objects are created or deleted as a result of import and export operations associated with the management agents. Although a single management agent might be authoritative for a specific object, the creation or deletion of that object might be initiated by a different management agent based on import or export rules processed during synchronization.
MIIS 2003 can perform three types of actions on an object: add, delete, and change. During the dataflow design process, the designer must define what steps to take when one of the three actions takes place. If an object is changed or deleted, the designer must describe how the dataflow should react based on whether the change was made by an authoritative source or not.
For example, if an object is deleted by a non-authoritative data source, the authoritative data source should initiate the recreation of the object. If an object is changed by a data source with a lower precedence, then a data source with a higher precedence should overwrite the change. The designer should define these actions for each data source involved in the deployment. Later in the process, the metaverse and rules planners will use this information to create the actual synchronization rules.
External Authorities
The metadirectory can only control the data that it manages within its own database. The connected data sources still have ultimate control over their own data. Object creation and deletion within the metadirectory is driven by the projection, join, and deletion rules that are applied during import and export operations. Authority over the objects in the metadirectory is determined by the application of those rules. Connected data sources have their own mechanisms in place to enforce their own policies and these must also be considered when determining authority and precedence.
For example, a contractor database may be configured to require a specific value be stored for a particular attribute. The contractor database becomes part of a Microsoft Identity Integration Server implementation and begins receiving data exported from the metadirectory. If authority has not been properly determined, the following sequence of events can take place:
Data is exported to the contractor database.
Another service monitoring the contractor database detects the new data and checks the validity of the data. It determines that some of the data is invalid and overwrites it with valid data.
The metadirectory performs an import to verify that the data it previously exported has arrived at the data source.
The import operation imports the new value that was written to the contractor database by the external service (which overwrote the previous value exported by the metadirectory). The import forces the metadirectory to perform another export because the previous export appears to have failed.
Once again, the service monitoring the contractor database detects the update and checks the validity of the data, which results in the newly imported data being overwritten.
Steps 3-5 continue until the configuration is changed to resolve the conflict in authority.
In this case, there is a service external to the metadirectory that is authoritative for the information stored in the contractor database. When determining authority, be sure to consider external influences on the data sources.
Next
See Also
Concepts
Overview of designing a system dataflow model
Dataflow Design Concepts
Filtering Metadirectory Dataflow
Design Constraints
Process Steps for Designing the System Dataflow