none
Set Membership not computed until SQL-Job FIM_MaintainSetsJob runs RRS feed

  • Question

  • I'm using a Transition In - MPR to add users to the outbound synchronization flow to active directory.

    Now if for example 10 users are added to the set, often times a few of them aren't added to the synchronization flow, until the FIM_MaintainSetsJob runs and the MPRs are kicked off, when they should be added immediately after they join the set. The number of users which are processed and the ones which aren't isn't consistent in any way, sometimes all are added, but sometimes if it's just one additional user he doesn't get added.

    Did any of you run into this issue before and found a resolution to get the transition-based MPRs to fire more consistently?

    Monday, July 22, 2019 12:49 PM

Answers

All replies

  • Raffael-

    Is your MIM instance fully patched with the latest rollup? Does the set criteria reference any date/time fields?


    Thanks,
    Brian

    Consulting | Blog | AD Book

    Monday, July 22, 2019 4:43 PM
    Moderator
  • Hi Brian

    Thank you for your response! I just checked back with our customer, the SQL-instance is running on 2016 SP1, not SP2.

    There are no temporal criteria for the set.

    I'll get the customer to update to the newest Service Pack.

    Tuesday, July 23, 2019 9:39 AM
  • SQL-Instance is now updated, the issue is persisting.
    Tuesday, July 23, 2019 12:16 PM
  • What about MIM? That's more what I am concerned about in this case. 

    Thanks,
    Brian

    Consulting | Blog | AD Book

    Tuesday, July 23, 2019 2:03 PM
    Moderator
  • Oh, I figured you were talking about SQL because you asked for the instance, my bad.

    It's a fresh install. Service and Portal and Sync Service are on 4.5.412.0

    Tuesday, July 23, 2019 2:20 PM
  • That's the latest build. What's the criteria on the set look like? 

    Thanks,
    Brian

    Consulting | Blog | AD Book

    Tuesday, July 23, 2019 2:29 PM
    Moderator
  • /Person[(not(EmployeeID = 'N/A')) and
    (starts-with(EmployeeID, '%')) and
    (starts-with(DisplayName, '%')) and
    (starts-with(UserPrincipalName, '%')) and
    (starts-with(AccountName, '%')) and
    (not(vslNoProvisioning = True))]
    Wednesday, July 24, 2019 5:50 AM
  • You'd have to get a support case logged to figure out why this isn't working. Looking at the filter I'm not necessarily surprised that there's something wrong. Is this something you could try and simplify and take the tests for whether the fields are present out? Possibly use a Boolean flow in the sync engine or a workflow to calculate a true/false flag? 

    Thanks,
    Brian

    Consulting | Blog | AD Book

    Thursday, July 25, 2019 3:22 PM
    Moderator
  • I haven't had issues with the "is present" condition in previous environments. Are you saying I should opt to use as little "is present" conditions as possible?

    I'm sure I can build a way around it, it was just the simplest way to do it for the different ways they want to be able to create users.

    Friday, July 26, 2019 6:58 AM
  • It *should* work but I've seen filters like this not work correctly before so that's why I suggested looking at refactoring this. 

    Thanks,
    Brian

    Consulting | Blog | AD Book

    Friday, July 26, 2019 2:46 PM
    Moderator