none
Account synchronisation fails to fully provision in FIM 2010 R2 for around 1% of users, I need to perform manual edits in the FIM portal RRS feed

  • Question

  • Hi,

     I'm provisioning users to AD based on an input from a CSV file (it's actually a CSVDE). I've successfully synced around 6000 users and that has worked fine for a number of months. The process I'm using is as follows:

    1. File MA --> Full import and delta sync (loads data from CSV file)
    2. FIM MA --> Export, delta import and delta sync (provisions user to FIM portal)
    (wait 10 minutes)
    3. AD MA --> Export, delta import and delta sync (provisions user and mailbox in AD)
    4. FIM MA --> Export, delta import and delta sync (updates domain attribute in FIM portal)

    I'm using declarative rules, similar to this: https://technet.microsoft.com/en-us/library/ee534908(v=ws.10).aspx

    The HR file is authoritative (i.e. takes precedence

    Today I realised that around 50 users were provisioned to the MV, had a file MA connector and a FIM connector, but not a an AD connector. Looking at the account in the FIM portal I realised that the domain attribute was not populated for contoso and that an AD outbound sync rule was not pending.

    I then decided to run the synchronisation steps at 1 to 4 above, but this time used full imports and full synchronisations. After doing this the number of accounts which did not have an AD MA connector dropped to around 10 (e.g. 40 additional accounts were provisioned to AD).

    To provision the remaining 10 users, I firstly deleted the 10 users from my input CSV file and ran through the sync steps above. This ensured that the 10 users were removed from the MV and FIM portal. I then re-added the 10 users to my CSV and ran through the steps above, but this did not provision the 10 users! To ensure the 10 users and their mailboxes were created in AD/Exchange I did the following:

    1. Logged on the FIM portal and checked to see if an AD outbound sync rule is pending (it's not).
    2. Changed the user account employee type to "contractor" (bringing the user out of scope of a sync rule using the MPR\triple).
    3. On the FIM MA, performed a delta import and delta sync. The MA shows an update, but prompts for a FIM MA export back to "FullTimeEmployee" for the user as the MV value takes precedence.
    3b. I perform an export and delta import on the FIM MA.
    4. The user account now shows as having an AD export sync rule pending.
    5. If the synchronisation step in 3A shows an outbound sychronisation for the AD MA, I simply perform a:

    5a. AD MA --> export, AD delta import & AD delta sync
    5b FIM MA --> export, delta import & delta sync

    If the synchronisation step in 3A does not show an outbound sychronisation for the AD MA, I do the following:

    5c. Change the domain attribute for the user to "contoso" using the drop down in the FIM portal when clicking on the user.
    5d. FIM MA --> delta import and delta sync (MA reports update due to 5c).
    5e. FIM MA --> export, delta import and delta sync. 
    5f. FIM MA --> delta import and delta sync (now the AD MA shows an outbound synchronisation)
    5g. AD MA --> export, delta import and delta sync (user account and mailbox provisioned in AD)
    5h. FIM MA --> export, delta import and delta sync (tidy up)

    I don't know why these additional steps were required for the 10 users, it just feels as if they got stuck in the system! 

    Any ideas on how to avoid this oddness would be appreciated in future...

    On a slightly different note, am I right in thinking that full synchronisations and imports on valid existing objects simply updates the existing object if applicable, rather than delete and create new objects?

    Thanks in advance


    IT Support/Everything

    Wednesday, August 24, 2016 2:19 PM

Answers

  • FIM_TemporalEventsJob (which evaluates groups and sets and by default runs once per day to calculate temporal events).

    or

    FIM_Maintain_SetsJob

    https://technet.microsoft.com/en-us/library/ff830030(v=ws.10).aspx

    https://technet.microsoft.com/en-us/library/jj204562(v=ws.10).aspx


    David Lundell, Get your copy of FIM Best Practices Volume 1 http://blog.ilmbestpractices.com/2010/08/book-is-here-fim-best-practices-volume.html

    • Marked as answer by Aetius2012 Wednesday, September 21, 2016 9:18 PM
    Tuesday, September 20, 2016 4:10 PM

All replies

  • It sounds like you are using the MPR/Set/Workflow approach to apply a sync rule. The only thing that comes to mind is timing. It is a best practice to export to the FIM Service and then wait a minute or two before doing an import so that FIM has had a chance to recalculate all of the sets. You may already be doing this

    The other thing you could do is run one of the SQL Agent jobs that recalcs all of the sets to see if that gets the objects to have an ERE attached.


    David Lundell, Get your copy of FIM Best Practices Volume 1 http://blog.ilmbestpractices.com/2010/08/book-is-here-fim-best-practices-volume.html

    Sunday, September 4, 2016 1:42 AM
  • Hi

    As to your last note, if the object exists in the external system, a full synch  will only update if needed but if the object don´t exist in the external system you will get a delete/create in connector space.

    Monday, September 5, 2016 10:04 AM
  • Thanks David,

     Do you know which SQL agent job I'd need to run - I've briefly looked at the underlying SQL and thought best to leave it alone for fear of screwing up the DB!


    IT Support/Everything

    Tuesday, September 20, 2016 8:06 AM
  • FIM_TemporalEventsJob (which evaluates groups and sets and by default runs once per day to calculate temporal events).

    or

    FIM_Maintain_SetsJob

    https://technet.microsoft.com/en-us/library/ff830030(v=ws.10).aspx

    https://technet.microsoft.com/en-us/library/jj204562(v=ws.10).aspx


    David Lundell, Get your copy of FIM Best Practices Volume 1 http://blog.ilmbestpractices.com/2010/08/book-is-here-fim-best-practices-volume.html

    • Marked as answer by Aetius2012 Wednesday, September 21, 2016 9:18 PM
    Tuesday, September 20, 2016 4:10 PM