The Complete Synchronization Process – Part 2: Existing User Synchronization


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



##

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.