How does one force IDM to execute drivers in a particular order?

For example, there are numerous drivers configured, there are two that has to be executed in a particular order. The AD driver will create the account, then sometime after the Scripting Driver will then execute to physically create the home directory and the proper rights. I have both drivers configured already, I’m asking for a method on how I can force IDM to start the script driver after AD is done?

As of right now, I’m thinking entitlements as the approach, is there another method/approach?



0 votes, average: 0.00 out of 50 votes, average: 0.00 out of 50 votes, average: 0.00 out of 50 votes, average: 0.00 out of 50 votes, average: 0.00 out of 5 (0 votes, average: 0.00 out of 5)
You need to be a registered member to rate this post.

Disclaimer: As with everything else at NetIQ Cool Solutions, this content is definitely not supported by NetIQ, so Customer Support will not be able to help you if it has any adverse effect on your environment.  It just worked for at least one person, and perhaps it will be useful for you too.  Be sure to test in a non-production environment.

Leave a Reply

Leave a Comment

  • geoffc says:

    To be fair, drivers do not execute in order, they basically all execute together, in a first in first out stack model.

    What you would do, in your example of the AD driver for account creation and then the Scripting driver for Home Directory creation on a Windows server, is pick something that happens when the AD driver is done, and use that event to trigger the Scripting driver.

    For example, in the Pub Channel, you will see an add-association event when the user is completed being created in AD. (Also see some status events with Success).

    You could watch DirXML-Associations, check if there is an Association to that driver (Use XPATH, see this article: Using XPATH to Examine Association Values to look for the AD drivers DN in an assoication value (Probably also check that the nameSpace component is 1 to show that it succeeded) and then trigger the Scripting driver off that.

    Or else add a trigger attribute of your own, i.e. say acmeADUserCreated gets added to the user, say with a timestamp value so it is useful by itself, in your AD driver input Transform, you could look for an event of status = success (probably need to add an operation property on the Sub channel for Add’s that indicate it was an add event to avoid doing this on Modify or modify-password or the like events) and then add this attribute to the user.

    Then the Scripting driver could watch for that attribute changing and then kick off to create the home directory.

    Lots of different ways of differing complexity. But the same basic model across the board… When the AD driver is done, figure out what shows you that, then look for that event in the Scripting driver.

    • clessard says:

      We’ve begun our development for Home Directory provisioning in AD. We already know how to set the profile attributes (homeDirectory, homeDrive, and scriptPath), and we already have a Powershell Script that will create home directory folders and then set rights. The script expects me to pass parameters for Username, FileServer, and Home Directory path.

      Is there a way to call this script directly from the AD driver. We do not have the script driver?

  • nate_spears says:

    In addition to Geoff’s excellent suggestions, if you needed to chain more than two drivers together in a particular order, it might make sense to use a particular attribute as a token, rather than a flag. For instance, instead of using acmeADUserCreated, the custom attribute is acmeUserCreationToken, and you store something in it like DriverWhoseTurn#timestamp, which you are using in the creation policy of each driver to veto out-of-turn events.

    In that case you would probably want to create a WorkOrder in the first driver’s creation policies to check to make sure it reaches the end of the cycle in an appropriate timeframe.

    You might also use a loopback driver to monitor the associations, or for ease of debugging until you get your policies right.

  • geoffc says:

    Nate, excellent idea. Nice way to genericize the process.

    Of course, you imply it, but do not say it outright, so I will, for the acmeUserCreationToken define it as Backlink syntax (which is a DN, then a 32 bit INT, which is perfect for Driver DN then the Timestamp of the event!)

    Remember to NOT make it Single valued (and thus is implicitly multi-valued).

    Also, it leaves you a tracking attribute as to when each object was created in each connected system, which is useful by itself!

    For more on Syntaxes available, look at these two articles that just got published:
    Interesting Schema Part 2

By: jlr1271
Dec 30, 2008
1:31 pm
Active Directory Authentication Automation Cloud Computing Cloud Security Configuration Customizing Data Breach DirXML Drivers End User Management Identity Manager Importing-Exporting / ICE/ LDIF Intelligent Workload Management IT Security Knowledge Depot LDAP Monitoring Open Enterprise Server Passwords Reporting Secure Access Supported Troubleshooting Workflow