Removing an Attribute from the Portal

A few weeks ago, I created a new attribute in the portal called adOU. This attribute contained the Active Directory OU of a user and was defined in code from the HR database input – that’s where the OU definitions are defined…..

I planned to use the attribute to define Sets containing the users whose accounts resided in those OU’s. So, after creating and populating that attribute, I started looking at the Set’s Workflows, MPR’s and Email templates that I’d require to make use of that new attribute – these items were to be used to send email notifications.

When I got to the point of creating the Sets, I noted that I could not choose the adOU attribute as a criteria. I checked the relevant MPR’s, Admin filter etc., all looked OK. Then I realised that when I created the new attribute, I had configured it as an un-indexed string. Thus, this was the reason that I could not use it in my Set definition.

So, off I go trying to delete the binding and attribute, always fails – after doing the few normal bits that I remember that I need to do beforehand – I have been here a few times before!

So, its about time that I documented all of the steps, to save me and maybe others the pain in the future.

  1. Delete the attribute mapping in the FIMMA:


2. Un-tick the attribute in the attribute chooser in the FIMMA


3. Remove any references to the attribute in any workflows, MPR’s, Sets, mail templates etc..Run an Export policy script like the following, then look for references (e.g. “[//Target/adOU]”) to the attribute in the resulting xml file:

4. Clear the attribute from all users. Previously, I have used an MPR and workflow to to this, but in this case, I found it unreliable. So turned to the LithnetRMA PowerShell module (

5. Finally, delete the binding and then the attribute – they should go now – if not something has been missed.

6. Refresh the FIMMA schema

Now in my case, I then re-created the attribute – as an Indexed String, and then the Binding. Then refreshed the FIMMA Schema again, added the attribute to the FIMMA picker, recreated the FIMMA flow, reset the MPR’s (to allow the attribute to be managed) and Admin filter permissions. Then run the export to get the data back into the portal. The Set criteria now contains the option to use adOU.