The Complete Synchronization Process – Part 2: Existing User Synchronization

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.



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.



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.



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.



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).




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



## ##

Comments (13)

  1. Shesha says:

    Thanks for the wonderful explanation!

  2. Tania says:

    Thank you for the helpful information, however, still looks like the images are not linked correctly. Is there a way I can be sent these in order to be able to see the images?

    1. ktackett says:

      Images should now be visible for this post.

  3. Ran says:


    the images are not showing up.

    1. Thank you for letting us know, ever since the migration of the blog we have noticed alot of issues such as missing post, images etc. We will work to get the images replaced as soon as possible. in the mean time if you have any questions please feel free to ask.

      1. Gary says:

        Good sharing!It will be better if we can see the disappear images.

  4. Williams says:

    P1/2/3/4 are all broken can you have a look at it,

    doesnt load the pictures

    1. currently I am trying to fix the Blog Site from its recent migration, is there anything in particular i can help you with

      1. Williams says:


        No, just wanted to highlight it incase no one notice it

      2. Thank you again and once again I apologize for the inconvenience

Skip to main content