The Complete Synchronization Process – Part 3: Joins


First published on MSDN on Sep 28, 2015

In ”


The Complete Synchronization Process – Part 1: New User Synchronization


“, we covered the complete synchronization process as it relates to new objects.In ”


The Complete Synchronization Process – Part 2: Existing User Synchronization


“, we stepped through the sync process for modifying a preexisting user object. In both of those, we mentioned

joins

and the sync step of the same name. With this post, I'd like to explain that in further detail. It is also worth noting that this post is in reference to the automatic process which occurs based on a met criteria, not the manual process of effecting a join as described

here

.

For this scenario to occur, we must first be in a state where a join is needed. Realistically, there are two principle situations in which joins are likely: 1. A disaster scenario where the Metaverse and connector spaces have been deleted, and, 2. Bringing an additional data source into FIM (i.e., another AD or a ) that contains users we already have. It is also worth noting that a

join

requires a unique value be present

in each data source where the object exists

so that we can use it as an anchor. Typical examples of this are values such as

EmployeeID

or

sAMAccountName.

In the below example, we are using

EmployeeID

. Note that this user object exists in both SQL

and

, but it

does not

exist in either connector space or the Metaverse.

1

As before, our process begins with an

import

. In this example (SQL and AD), it doesn't matter which is imported first. In fact, it is perfectly acceptable to perform two or more imports simultaneously (if the performance allows). In the below illustration, we see both imports running, simultaneously building their respective connector spaces.

2

Next, it is necessary for a synchronization to occur. In this example, it does not matter which runs first (so long as only one synchronization job runs at a time). That being said, there

are

scenarios where order

absolutely

matters. These situations we will discuss later. In this example, we'll first sync the SQL MA. This will, as we know,

project

the shell object into the Metaverse.

3

As well as perform an

import attribute flow

. From here, we have a fully formed Metaverse object.

4

Next, we will perform a synchronization on the management agent. Now, however, the second step (join) occurs.

5

Here's how it works: The user object is currently sitting in the Metaverse. Of the populated attributes, one of them is the

EmployeeID

. In this case,

EmployeeID=12345

. When a synchronization is run on the AD management agent, the filter/delete step is passed over and it attempts a join. During this attempt, the AD management agent contacts the Metaverse and basically says, “Do you have a user object with

EmployeeID=12345

?” The Metaverse, naturally, responds in the affirmative and the two become joined together.

Now, I previously mentioned that sometimes the order in which synchronizations occur matters. Allow me to explain: in the above scenario (SQL and AD), it doesn't matter who syncs first as we can (and likely have) configured

join logic

on both management agents. However, there are management agent types on which you

cannot

configure join logic. The most common of these, in fact, is the FIM Service Management Agent (FIMMA). Because of this, if the two data sources in use were AD and the FIM Portal, the FIM would


absolutely


need to sync first. The reason behind this is, since we cannot configure join logic on that management agent, it needs to be the one to project into the Metaverse (and have the other management agent join to it). Failure to do so can result in duplicate and/or orphaned Metaverse objects.

I also previously mentioned that once a join has occurred (or FIM has provisioned an object, in the case of new objects), a

relationship criteria

then exists. Once an object has been created in a connector space, it receives a unique ID, known as the

csObjectID

. Likewise, once an object has been created in the Metaverse, it receives an

mvObjectID

. Once an object has passed all the way through FIM (from source connected data source, through the Metaverse and into the target connected data source), these values are created and an association is made. A visible representation of this would be:

relationship

These values are actually stored in the FIMSynchronization database in the form of a

link table

. That, however, is outside the scope of this discussion.

Questions? Comments? Love FIM/MIM so much you can't

even

stand it?



EMAIL US!



##

https://blogs.msdn.microsoft.com/connector_space

#

#

 

This article was originally published by Microsoft's Core Infrastructure and Security Blog. You can find the original article here.