none
Attribute created as non-indexed string now needs to be a Filter criteria attribute. Best way to change type non-indexed to indexed without destroying the system? RRS feed

  • Question

  • We have a FIM solution that is in use.

    A custom attribute "CustomExt9" was created to hold a piece of information. At the time there was no need to maintain an index for it.

    We now realise that the attribute needs to be part of a Set criteria for Notification purposes.

    This custom attribute has been added happily to the Filter Permissions allowed attributes (no check made there for indexed or not), it exists in the RCDC forms and Synchronization Engine flows, sync rules etc.. Basically its everywhere.

    What dangers are there if I simply delete the non-indexed string attribute in FIM in Administration/All Attributes then recreate it WITH SAME NAME but as an indexed string?

    I realise after this I must reload  schema  on the FIMMA on the Synch Engine.

    Can I get away with just the delete / readd of the custom attribute without it affecting all other existing MPRs and stuff???????

    Thursday, March 28, 2013 9:21 AM

All replies

  • Hi,

    I think you will have issues because the schema and policies will reference the attribute via its Resource ID guid.

    You might be able to export the schema and policy, search and replace for the guid and then reload. (Definitely take back ups and try on dev first.)

    Also, in order to delete the attribute in the portal, you would have to clear all of the values it currently holds. Your new attribute would need to be re-populates with those values. (PowerShell might help with this if you export a list of objects that have the attribute value and then have a script to re-populate.)

    Others may have better suggestions, but those are the pitfalls I see.

    HTH,

    Sami

    Thursday, March 28, 2013 5:03 PM
  • Ok. I guessed it would be not so straightforward. Seems that on Portal side we should make all strings indexed "just in case" and not care about the efficiency/load.

    I figured out that we can get away with "just" creating a second INDEXED String attribute and adding this also to the list of selected attributes controlled by the admin accounts and use this Indexed string in the Set criteria.

    Fortunately the attribute just holds a calculated PIN number so we can flow this value from MV attribute holding the PIN to both the indexed and unindexed Portal attributes. Display the unindexed string on the RCDC form as now and use the Indexed string in the Set criteria. 

    Complete duplication but it seems sound.

    Hopefully others will not fall into this trap.

    Thursday, March 28, 2013 6:08 PM