Hello,

 I working on a FIM setup with the following run profiles:

File Ma -full import and delta sync (imports a bunch of users and email addresses from a CSV)
FIM Ma - Export, Delta Import, Delta Sync (Exports update MV changes to portal, imports to confirm the changes and then performs a sync for some reason)

AD Ma - Export and Delta Import

 My understanding is that whenever a sync is done, it is done against the connector space and the MV, with each MA doing an import or export to the relevant CDS. What I'm not sure about is why I don't need to perform an AD Ma sync before exporting to AD. My sync rules have been configured in the portal - would this be the reason?

If I didn't have my AD sync rules configured in the portal and ran everything from the sync service application would I need to do an AD MA sync?

Just trying to get a better understanding....

Thanks

Hi Peter,

Short answer is yes because the trigger to create the person in AD would be based on the synchronization rule and provisioning configuration being in the Portal. In reality its a bit more complex and really depends on how the provisioning is being done in your environment.

Running a synchronization on the AD MA wouldn't normally result in a person being created in AD, its normally be for finding users in AD that need updating because their data is out of sync or flowing information back into FIM that AD is the authoritative source for (such as user's objectSID) - there are other reasons but listing them all would take a while.  I would recommend adding a synchronization step to your AD MA though to ensure that all the data is in sync.

Based on what you have described I'm assuming the provisioning is using the Set/MPR/Workflow triple in the Portal to create a user in AD - so below is a rundown of what is more than likely what is happening in the background.

1. File MA Import & Delta Sync - Imports the user from the file and synchronizes them into FIM Metaverse. The synchronization step also tells FIM to create them in the FIM Portal on the next export

Breaking up the next one a bit

2a. FIM MA - Export - this creates the user in the FIM Portal. 

When the user is created in the Portal your AD Provisioning logic within the Portal gets applied to the user; and adds information telling FIM to create them in AD.

2b. FIM MA - Import - this imports the user from the FIM Portal including the information telling FIM to create them in AD

2c. FIM MA - Delta Sync - this synchronizes the updated information from the Portal into the Metaverse.  When this synchronization runs FIM finds that the user needs to be created in AD on the next export

3. AD MA Export & Delta Import - The export creates the user in Active Directory and then the import "confirms" that the user has been created.

There are a few other ways that provisioning  can happen but based on your description it sounds like the outline above should be what is happening in your environment.

Hope this helps!  But I'd also recommend checking out some of the Technet articles on outbound/inbound synchronization -> http://technet.microsoft.com/en-us/library/ee621259(v=ws.10).aspx

Andrew.

• Proposed as answer by Vladimir Zanadvorov 3 hours 49 minutes ago

Hi Peter,

Short answer is yes because the trigger to create the person in AD would be based on the synchronization rule and provisioning configuration being in the Portal. In reality its a bit more complex and really depends on how the provisioning is being done in your environment.

Running a synchronization on the AD MA wouldn't normally result in a person being created in AD, its normally be for finding users in AD that need updating because their data is out of sync or flowing information back into FIM that AD is the authoritative source for (such as user's objectSID) - there are other reasons but listing them all would take a while.  I would recommend adding a synchronization step to your AD MA though to ensure that all the data is in sync.

Based on what you have described I'm assuming the provisioning is using the Set/MPR/Workflow triple in the Portal to create a user in AD - so below is a rundown of what is more than likely what is happening in the background.

1. File MA Import & Delta Sync - Imports the user from the file and synchronizes them into FIM Metaverse. The synchronization step also tells FIM to create them in the FIM Portal on the next export

Breaking up the next one a bit

2a. FIM MA - Export - this creates the user in the FIM Portal. 

When the user is created in the Portal your AD Provisioning logic within the Portal gets applied to the user; and adds information telling FIM to create them in AD.

2b. FIM MA - Import - this imports the user from the FIM Portal including the information telling FIM to create them in AD

2c. FIM MA - Delta Sync - this synchronizes the updated information from the Portal into the Metaverse.  When this synchronization runs FIM finds that the user needs to be created in AD on the next export

3. AD MA Export & Delta Import - The export creates the user in Active Directory and then the import "confirms" that the user has been created.

There are a few other ways that provisioning  can happen but based on your description it sounds like the outline above should be what is happening in your environment.

Hope this helps!  But I'd also recommend checking out some of the Technet articles on outbound/inbound synchronization -> http://technet.microsoft.com/en-us/library/ee621259(v=ws.10).aspx

Andrew.

• Proposed as answer by Vladimir Zanadvorov Friday, January 17, 2014 8:01 AM

Hi Peter,

Short answer is yes because the trigger to create the person in AD would be based on the synchronization rule and provisioning configuration being in the Portal. In reality its a bit more complex and really depends on how the provisioning is being done in your environment.

Running a synchronization on the AD MA wouldn't normally result in a person being created in AD, its normally be for finding users in AD that need updating because their data is out of sync or flowing information back into FIM that AD is the authoritative source for (such as user's objectSID) - there are other reasons but listing them all would take a while.  I would recommend adding a synchronization step to your AD MA though to ensure that all the data is in sync.

Based on what you have described I'm assuming the provisioning is using the Set/MPR/Workflow triple in the Portal to create a user in AD - so below is a rundown of what is more than likely what is happening in the background.

1. File MA Import & Delta Sync - Imports the user from the file and synchronizes them into FIM Metaverse. The synchronization step also tells FIM to create them in the FIM Portal on the next export

Breaking up the next one a bit

2a. FIM MA - Export - this creates the user in the FIM Portal. 

When the user is created in the Portal your AD Provisioning logic within the Portal gets applied to the user; and adds information telling FIM to create them in AD.

2b. FIM MA - Import - this imports the user from the FIM Portal including the information telling FIM to create them in AD

2c. FIM MA - Delta Sync - this synchronizes the updated information from the Portal into the Metaverse.  When this synchronization runs FIM finds that the user needs to be created in AD on the next export

3. AD MA Export & Delta Import - The export creates the user in Active Directory and then the import "confirms" that the user has been created.

There are a few other ways that provisioning  can happen but based on your description it sounds like the outline above should be what is happening in your environment.

Hope this helps!  But I'd also recommend checking out some of the Technet articles on outbound/inbound synchronization -> http://technet.microsoft.com/en-us/library/ee621259(v=ws.10).aspx

Andrew.

• Proposed as answer by Vladimir Zanadvorov Friday, January 17, 2014 8:01 AM
• Marked as answer by Peter.Siffredi 16 hours 3 minutes ago

Hi Peter,

Short answer is yes because the trigger to create the person in AD would be based on the synchronization rule and provisioning configuration being in the Portal. In reality its a bit more complex and really depends on how the provisioning is being done in your environment.

Running a synchronization on the AD MA wouldn't normally result in a person being created in AD, its normally be for finding users in AD that need updating because their data is out of sync or flowing information back into FIM that AD is the authoritative source for (such as user's objectSID) - there are other reasons but listing them all would take a while.  I would recommend adding a synchronization step to your AD MA though to ensure that all the data is in sync.

Based on what you have described I'm assuming the provisioning is using the Set/MPR/Workflow triple in the Portal to create a user in AD - so below is a rundown of what is more than likely what is happening in the background.

1. File MA Import & Delta Sync - Imports the user from the file and synchronizes them into FIM Metaverse. The synchronization step also tells FIM to create them in the FIM Portal on the next export

Breaking up the next one a bit

2a. FIM MA - Export - this creates the user in the FIM Portal. 

When the user is created in the Portal your AD Provisioning logic within the Portal gets applied to the user; and adds information telling FIM to create them in AD.

2b. FIM MA - Import - this imports the user from the FIM Portal including the information telling FIM to create them in AD

2c. FIM MA - Delta Sync - this synchronizes the updated information from the Portal into the Metaverse.  When this synchronization runs FIM finds that the user needs to be created in AD on the next export

3. AD MA Export & Delta Import - The export creates the user in Active Directory and then the import "confirms" that the user has been created.

There are a few other ways that provisioning  can happen but based on your description it sounds like the outline above should be what is happening in your environment.

Hope this helps!  But I'd also recommend checking out some of the Technet articles on outbound/inbound synchronization -> http://technet.microsoft.com/en-us/library/ee621259(v=ws.10).aspx

Andrew.

• Proposed as answer by Vladimir Zanadvorov Friday, January 17, 2014 8:01 AM
• Marked as answer by Peter.Siffredi Sunday, January 19, 2014 7:48 PM

Thanks Andrew,

Yup, I'm using the set/mpr/triple in the portal to provision users. So, would you say add step 2d "delta sync"?

No problems Peter - I'd actually add the AD MA Delta Sync in as Step 4, as running it as a step 2d would have no real affect as nothing has happened in AD yet.

I'd probably also add in a Step 5 being an Export and Delta Import on the FIM Portal MA.

This will do two things:

1. If you are using DREs they will get created in the Portal after a user gets created in AD

2. It will also update the user's objectSID in the portal so they can login to the FIM Portal (assuming you want users to be able to access the FIM Portal and its defined in the data flows. With the current schedule that wouldn't happen until the next time the run schedule executes.

Andrew.