First published on MSDN on Oct 29, 2014
Here’s the first of a two-part piece on working with time and dates within the FIM portal. With this post, I’d like to speak to a common request I get from customers. In a lot of organizations, it’s perfectly acceptable to delete a user object when that user is no longer employed. A simple example of this would be: user disappears from HR data feed, therefore, we delete that user from the FIM portal, purge them from the FIM and HR connector spaces, delete their metaverse object and, on the next export run cycle, delete them from the AD connector space and, ultimately from Active Directory itself.
However, more and more organizations are require some form of data retention. In these cases, we cannot simply delete the user everywhere they exist once they disappear from HR. Or rather, we cannot delete them right now . So, how, then, do we handle these scenarios? In cases where Active Directory is our authoritative system of record, we have to key off attributes such as accountExpires, which requires the creation and use of a rules extension (.DLL). In most cases, however, AD is not our authoritative system of record (HR is). In these instances, I find there is a far easier method that relies on a set, two MPRs and two simple workflow activities. With this method, we stamp the current date/time on an object when they have been determined to be “inactive” or disabled”, and then use a set with a pre-defined duration (180 days, for example) to catch them when that threshold is met. At that point, the other workflow fires and deletes them.
It is worth noting that some of the following activities rely on custom (not out-of-box) workflow activities. Fortunately, all of these are contained within the Workflow Activity Library (WAL). WAL download and documentation can be found here .
First, we need a simple workflow activity to set the current date stamp when the user is disabled. The prerequisite here is a user disabling workflow. In my environment, for example, I have a set to catch users who (in HR) have been marked disabled, change their userAccountControl, move them to an exiled users OU, etc. In this example, let’s assume you have a similar workflow already in place that we can piggyback these activities on.
For the first piece, we will use a value expression of
DateTimeNow()
With a target of
[//Target/EmployeeEndDate]
This will set a value of MM:DD:YY:HH:MM:SS in the EmployeeEndDate attribute. However, we don’t really care about the time, only the date. Therefore, I like to follow this activity up with another to trim off the hours, as shown here:
This will reduce the value in the EmployeeEndDate attribute to a MM:DD:YY format.
So, we are now stamping each user object with the date on which it was disabled. What now? Next we need a set to capture those users who have timed-out on their threshold. In this example, we’re using 180 days.
This is known as a temporal set . The criteria for membership in this set is any user object within the FIM portal who has a value in their EmployeeEndDate attribute set to a date 180+ days ago (from the current days date). Once we have a set to grab users who have been disabled for 180+ days, we are now ready for a delete activity. For this activity, we will use the workflow target (as defined by the management policy rule) for our object deletion.
With that in mind, we must now configure an MPR. This one will be a set transition.
Transition In with a “Transition Set” target of the set we created to catch the 180+ day disabled users:
Firing the delete action workflow:
Questions? Comments? Love FIM so much you can't even stand it?
EMAIL US>WE WANT TO HEAR FROM YOU!<