The Complete Synchronization Process – Part 2: Existing User Synchronization

This post has been republished via RSS; it originally appeared at: Core Infrastructure and Security Blog articles.

First published on MSDN on Sep 25, 2015

In “ The Complete Synchronization Process – Part 1: New User Synchronization ”, we covered the complete synchronization process as it relates to new objects. To add to that, I’d now like to discuss the complete synchronization process as it relates to pre-existing objects.

As you can see below, we have the same basic environment (SQL data source and Active Directory). Since this is a pre-existing user, you can see they exist (in the same state) in: SQL, the SQLMA connector space, the Metaverse, the ADMA connector space and Active Directory. Essentially, they look the same everywhere they exist.

0

However, in the real world, users infrequently stay the same. People get married, change roles, switch departments, and get new managers – all things that are reflected in their attributes. Along those lines, below we can see an attribute has changed (as noted in yellow) in our authoritative system of record (SQL). An import brings this change into the SQLMA connector space.

1

If we think back to the six steps that make up the synchronization process (filter/delete, join, project, import attribute flow, provision, export attribute flow), we can make a series of realizations. First, we know that a filter/delete should not occur; if this object met the filter criteria, it wouldn’t exist in the first place. Next, we know that this is a pre-existing user who has been previously synchronized. Based on that, we know a relationship criteria exists (which we will discuss later), so a join isn’t necessary. Finally, since the object is pre-existing in the Metaverse, a project isn’t called for. That brings us to the import attribute flow step. Since there is a changed attribute (as noted in yellow), this step occurs and the new value is populated in the Metaverse.

2

Moving down the list, we again know that the user is pre-existing in the target connector space. Based on this, we know a provision will not happen (since the object is already there). This leaves the export attribute flow step. As before, this will flow the changed attribute value from the Metaverse to the target connector space. This completes the synchronization cycle.

3

As with a new object, the final step in the complete process is to perform an export on the target management agent (in this case, the Active Directory MA). As before, this will take the staged change from the target connector space and populate it in the connected data source (AD).

4

Questions? Comments? Love FIM so much you can’t even stand it?

EMAIL US !

>WE WANT TO HEAR FROM YOU<

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

REMEMBER: these articles are REPUBLISHED. Your best bet to get a reply is to follow the link at the top of the post to the ORIGINAL post! BUT you're more than welcome to start discussions here:

This site uses Akismet to reduce spam. Learn how your comment data is processed.