Criteria-Based Bulk Portal Object Deletion

Article
11/18/2014

Today I’d like to discuss a topic that comes up from time to time: how to (intelligently) bulk delete a group of objects from the FIM portal based on a set of criteria. There are several ways of handling this, but most rely on the use of an additional custom activity workflow (generally PowerShell based). If, for whatever reason, these third-party workflows aren’t available to you, or if you simply don’t feel comfortable firing PowerShell against your FIM environment, there is another solution (that is 100% OOB).

Here’s a common scenario: you’re in the process of building a new FIM environment and, due to bad logic, bad precedence, etc., you’re left with “shell” accounts in your portal. These typically manifest themselves as user objects that have few (if any) attributes populated on them. Here is an example of one such object:

As you can see, in this example, there is a single attribute populated on this object. If this singular attribute were something unique (such as an EmployeeID), we could in theory use join logic to populate the remaining attributes. If, however, this is not possible, you may wish to delete them instead. If only 10 of these objects exist, you can check the boxes and use the “Delete” button, but what if you have 10,000 of them?

First, we need to create a set to capture these “bad” users.

The important thing here, and I cannot stress this enough, is to make absolutely sure that we ONLY capture the objects we wish to delete. In this example, I have defined criteria such that the Account Name, Display Name, First Name and Last Name must all be blank, while the PoliticianID must have a value populated. By clicking the “View Members” button, you can see which objects meet this criteria and will be affected. Again, check and double check.

Next, we must create a set to capture a little known built-in workflow that will do our work.

For this set, we have a defined criteria where Display Name is Expiration Workflow.

At this stage, however, this built-in workflow is lacking the necessary permissions to actually delete user objects, so these must be explicitly granted to it. To do so, we will make use of a permission granting management policy rule (MPR).

Here we see the “Requestor” is one of the sets we previously created. Note that we are granting “delete resource” and “grants permission”.

Here we see the target resource is the other set we created (which contains the bad users). Note that we have selected “All Attributes”.

Note, as this is a request based MPR we are not using a workflow.

Finally, we will create the MPR that calls the workflow to actually perform the deletion. Notice that the “Policy is disabled” box is checked. Any time I am creating a workflow activity that could potentially be detrimental, I like to create the MPR in a disabled state. This allows me, after all pieces are in place but before any work is actually performed, to go back and re-check everything to make sure there are no errors.

Here we see the selection of the action workflow.

Here is a step that I urge you to use cautiously. There may be times when we wish to fire a workflow at a transition set that has already been populated with members. As there is no direct way to “re-transition” them, we need some way of simulating that step. One method of doing so (as shown in the below image) is by checking the “Run on Policy Update” box on the workflow itself. In doing so, we can disable/enable the associated MPR, which FIM will see as a “policy update”. I say to use this cautiously as FIM will detect any change to the MPR and, if this box is checked, fire the workflow against the set membership. As such, if you are not purposefully using this, leave this box unchecked as a safety measure.

In this instance, however, our set is already populated with the users we wish to perform work on, so checking this box makes sense.

At this stage, you may wish to go back and review everything that has been done to be sure there are no errors. Verify set criteria catches only those user objects we wish to delete, and make sure all associated MPRs are pointing at the correct sets and
workflows. Once verification has been completed, we are now ready to enable the set transition MPR and fire the workflow. To do so, open the MPR, uncheck the “Policy is disabled” box and submit.

If everything has functioned as intended, deletes should be occurring on these users. To verify, navigate to the “Search Requests” and look for something similar to what is shown below:

By clicking on one, you can see the request in detail:

Again, while this is a 100% out of box option, I would encourage you to use it cautiously. One bad set criteria or one incorrect key stroke could potentially have a majorly negative impact on your environment. If used properly and with caution, however, it could also potentially be a real life saver.

Partager via

Criteria-Based Bulk Portal Object Deletion

Comments

Ressources supplémentaires