Altering a FIM metaverse attribute-type RRS feed

  • Question

  • Hi All,

    I have recently become acquainted with FIM 2010 R2 and I'm still learning all of the inner quirks that this wonderful product has to offer.

    We are currently in the process of configuring the AAD connector ( & for a customer (in lieu of using DirSync). Our original infrastructure and deployment included DirSync as well a consolidated Active Directory. I understand that the AAD connector has recently gone to GA (General Availability). As an attempt to minimize the infrastructure/components required for the deployment, we have removed DirSync and the Consolidated AD out of the picture.

    Our implementation of FIM currently has multiple MAs (management agents) configured and running periodically. While going through the AAD connector guides, we realized that we needed to create several new metaverse attributes and object classes in order to support the AAD connector. In conjunction with the sample code provided and as a general inquiry, we are attempting to modify one of the attributes (accountEnabled) in the metaverse from an attribute-type of String (non-indexable) to Boolean.

    What is the safest way, if any, to change an attribute-type in the metaverse? This attribute seems to be used in various spots throughout FIM (in attribute flows mostly), so we do not want to break any of the existing functionality.

    I understand that the easiest way is to simply alter the sample code and change it to represent a String instead of Boolean. For now, this is not the intended method, unless stated otherwise by the FIM SMEs.

    I appreciate any help that can be provided. Any feedback on your own experience with the AAD connector is also appreciated (pros & cons).



    Tuesday, March 4, 2014 5:49 PM

All replies

  • Sadly you can't just flip the Metaverse attribute to be a boolean. Personally I would add another attribute like blAccountEnabled and let it be populated by the same master source which currently populates accountEnabled.

    Then you can use the old one in your legacy flows and the new one in the ones that require a boolean. If you want to get rid of the old one then you could alter your other rules one by one to the new one untill no rules depend on it.

    On the other hand, if you got a decent test environment, nothing prevents you from carefully testing and determining a proper sequence to delete and recreate the attribute and update were needed...

    Either way, there's no magical solution I think.

    Wednesday, March 5, 2014 2:56 PM