Selective provisioning to the FIM MA – well, sort of

Recently a thread I’d started a long time ago about selective provisioning to the FIM MA bubbled back up to the top of the FIM Forum. At the time it provoked a lot of discussion, with the Microsoft line remaining firmly “ALL metaverse objects must be in the Portal” and many FIM users saying they didn’t see why this should be the case.

There are lots of very good reasons I can think of why you’d want some objects in the Metaverse but not in the Portal and seeing the post pop up again reminded me that I’d actually “solved” this problem long ago by the simple expedient of deleting objects that I don’t want.

I didn’t want objects without an accountName cluttering up the Portal so in my Metaverse Extension code I have:

    If Not mventry("accountName").IsPresent Then
        mventry.ConnectedMAs("FIM").Connectors.DeprovisionAll()
    End If

As the Metaverse extension code seems to run after the hard-coded provisioning to the FIM MA this has the simple result of removing the unwanted objects as soon as they’re created. It didn’t particulary seem to slow things down either.

3 Replies to “Selective provisioning to the FIM MA – well, sort of”

  1. I was really hoping to use this method as we have something like 5,000 employees that we want to manage groups for via the portal, and 130,000 student objects (growing at 30k/year) that I’d really rather not have in the portal.

    It seems that if there is an update imported from AD for the object, but no flow updates, the hard-coded FIM provisioning code runs but the metaverse extension provisioning code does not.

    The result is that some of the student objects would end up in the portal anyway, at least until a full sync or flow activity actually triggered the deprovisioning to occur.

  2. That’s a pity. I think your only option is to have a seperate object type in the metaverse for students, which can be a real nuisance when you have people changing between staff and student, or being both at the same time.

  3. Actually, as it turns out the deprovisioning is triggered when the FIM MA object is imported and sync’ed the first time…not sure how Microsoft licensing would view a ” very-short-lived” object!

    Another problem I found is when a delta sync is run where attributes have changed indicating an object should now go to the portal (i.e. a student is hired and becomes an employee). The metaverse extension code removing the FIM MA connector that I wrote correctly does not deprovision the connector and thus it is created. But the only attributes that flow out on that sync are the ones that changed! Basic identity data (name, AccountName, etc.) does not flow until the next full sync runs that touches the object because it isn’t changed during that sync cycle. That’s just one more way the FIM MA is unlike any other, it assumes that if the metaverse object is already there, the FIM MA connector must already be there too.

    This new factor may be the reason that we do not keep the students out of the portal. I can only run full syncs nightly, but for account provisioning our SLA is an hour and it wouldn’t be possible to add the employee to the right groups without all the relevant data on the first export.

    You’re right about the nuisance of separate object types. For us, user role (employee/student) is more of a checkbox than a radio button. 🙂

Comments are closed.