An introduction to ILM coding

While writing this series of newbie posts I have, on a few occasions now, had to stop half-way through a post because I’ve realised that something else needs to be explained first. I’m at the point now where I can’t go any further without introducing the topic of writing code.

I have spoken to several people who evaluated, and rejected, MIIS/ILM because of the coding requirement. “We don’t have any developers” they would say. Instead they went for an alleged “out of the box” solution, only to find they had to pay plenty in consultancy fees to get it configured anyway. Believe me, there are no easy IdM solutions today, and any gains you may get in out-of-the-box functionality you will lose on lack of configurability. No two environments will be exactly the same, so why shackle yourself to a solution with innate limitations? Go for something extensible. <dismount soapbox>

Anyway it really isn’t too bad, once you get over the initial learning phase, so let us begin.

Visual Studio

Now I should point out that I am no developer, so I apologise now for anything I get wrong, or sound a bit vague about. The point here is to get ILM working, not to deliver an erudite treatise on programming with Visual Studio.

The first thing you need to do is to install Visual Studio on you development server.

You do have a development server don’t you? Good.

(Me, I make a point of not installing VS on my production server so I won’t be tempted to try any quick fixes. If I need to troubleshoot code on the production server I can always do that remotely from the development machine.)

Now I’m not entirely clear on which version of VS you’ll need – can’t seem to find it on What I can tell you is that I’m running VS 2005 Professional with ILM 2007, and that’s working fine.

ILM Solution

The first thing you should do is create a new solution for your ILM code. You will probably end up with a number of projects and it’s convenient to keep them all together.

The MVExtension

You need to be familiar with the different types of extension code.

The Metaverse Extension, or MVExtension, is where you write your provisioning code – ie the code that creates and deletes objects.

Officially you only have a single MVExtension in your solution – there is only one metaverse so there is only one metaverse extension.

This idea can take a little getting used to. Our connected directories are distinct environments, so we tend to think of provisioning to them as seperate activities. But in the metaverse all objects are considered equal. ILM will run all MVExtension code in response to any change to a metaverse object.

It is important to remember this point when writing MVExtension code, and to test appropriately if you wish to exclude certain objects. ILM won’t know you only intended a piece of code to run on group objects unless you explicitly test for the mventry.ObjectType.

Note that there is a way to split your MVExtension code into multiple dlls, although ILM will still run them all against each object change. Please see this article in the Developer’s Reference for details.

To create an MVExtension project from Identity Manager, open the Tools menu and select Options then click Create Rules Extension Project.


Once the project has been created, add it to your ILM solution in Visual Studio.

For more info see Creating a Metaverse Rules Extension in the Developer’s Reference.

MA Extensions

MA Extensions are where you put code that only relates to objects in the connector space for a particular MA – such as advanced flow rules and advanced join rules. You can (only if you need to) have one MA Extension per MA.

To create an MA Extension in Identity Manager, click the MA and select Create Extension Projects from the Actions menu.

Once the project has been created, add it to your ILM solution in Visual Studio.

I’m going to have to leave talking about how to actually write code into your MAExtension for another post, but I will just point out one thing at this point.

All the MAExtensions are created with the same default Class name. You need to change this so you don’t get conflicts within your solution. Just add “_MAName“ to the end of the default class name, as shown:

To read about MA Extensions in the Developer’s Reference see Creating a Management Agent Rules Extension.

Other Extension Types

You can also have Connected Data Source Extensions and Password Extensions, but all I’m going to include on them, in this post anyway, is a quick definition:

  • CDS Extensions are used with Extensible MAs where you also need to write your own Import and Export routines, and
  • Password Extensions work with the Password Change Notification Service (PCNS), allowing a changed password to be captured and sent to MAs which don’t natively support password sync.