iManager Driver images:

If you have been using Novell (now NetIQ I guess) Identity Manager for any period of time you will know there are two main administrative interfaces for managing the drivers. There is iManager for a web based approach, that is really quite a clever bit of coding. It is quite amazing how much stuff you can do in the IDM snapins for iManager.

Over the various releases the snapins have continued to get better and really it is quite useful. With the release of Identity Manager 4 and the advent of Packages, they chose not to write full support for Packages into the iManager plugins, and so support for Packages is somewhat limited.

Thus the second interface which started out as a secondary method after iManager and evolved into a really powerful tool, is Designer for Identity Manager. This is an Eclipse based application that runs in Java on Windows and Linux as client side applications. Alas it requires JClient (The Java based version of DClient, which is the underlying library used to talk to eDirectory) and NICI support neither of which have not been ported to the Mac, or else it looks like it would mostly run. In fact, when someone reports that Designer loads, but will not do compares or any live action against the tree, it is almost always throwing a JClient error, which you can trace back to a problem with NICI. (Fairly common on Linux).

Designer is a great tool, but every so often I run into something confusing that is not included in the documentation.

One great example of this is how Designer and iManager handle the icons for drivers that show up when you look.

When you look in iManager, Identity Manager side item, then select the Identity Manager Overview, you get the you see the Driver set view, which after enough clicks, will show you all the drivers in the driver set as hubs on a spoke. There is an image for each driver.

If you look at a Driver configuration export file, in XML, there will be a node in the XML called <driver-image/> which will contain a text value that is the base 64 encoded version of the driver image. This is usually in GIF format as it turns out.

But the icon that shows up in Designer itself is actually a different size and shape. For one thing, it does not have the circular cutout for the red light, green light (1, 2, 3, for those who have kids of the appropriate age) semaphore that indicates Running, Stopped, Starting, Stopping, etc.

This became an issue for me recently as I was working with some drivers for a client, and in fact, ended up doing 5 Active Directory drivers, that were basically all identical but to 5 different domains. They differed in some basic ways, but it seemed like it would make a lot of sense to share the policy objects across all 5 drivers. My reasoning for this was that any customization I needed to make to one, invariably applied to all 5 and I have to tell you, that even with the memory leak fixes in Designer 4.01 that boost performance, making the same change 5 times gets really tedious.

Instead, I used a trick my boss showed me. I deployed my first driver to an eDirectory server running the IDM engine. Then I went in Console1, and moved every Policy object from under the driver I just deployed into a Library object at the root of the driver set.

This works because the linkage of the Policies within the driver configuration is actually stored in an attribute called DirXML-Policies, which is a Typed Name syntax attribute. This syntax allows for two 32 bit integers, and a DN reference. (Which is of course also a 32 bit integer, but displays differently). One of the integers refers to the numeric placement of the policy set of interest. The possible values are in the table below:

0 Schema Map
1 Input Transform
2 Output Transform
3 ECMA Script Object
4 Sub Event Transform
5 Pub Event Transform
6 Sub Match
7 Pub Match
8 Sub Create
9 Pub Create
10 Sub Command Transform
11 Pub Command Transform
12 Sub Placement
13 Pub Placement
14 GCV Objects

This is a nice model, as you can see that number 14 may look a bit odd, being for GCV objects, but that is a new construct that came with IDM 4 Packages, the notion of a standalone object to hold Global Configuration Variables. The current approach in Packages to handle the Filter is in my mind problematic, and needs to be updated, and I imagine the solution will basically be identical to how GCV's got handled, and I am betting that Filter objects gets to be number 15. The filter and GCV before Packages were single valued attributes on the driver object that held large blobs of XML. Either in the config values DTD or the Filter definition DTD. With Packages, GCV's are still supported on the driver object, but you can link in addition DirXML-GlobalConfig objects whose DirXML-ConfigValues attribute holds the XML, and the sum of all the values what the driver uses. Filters also being a single attribute were handled different, and there is a DirXML-Resource object with a DirXML-ContentType indicating it is a filter extension that is used. The extensions seem to get tacked onto the Filter values in the original attribute. This works fine for adding, but leaves some areas of concerns if you remove or downgrade packages that include Filter extensions.

Then the second integer starts at 0 and lists off the ordering within the policy set. Thus you can have 10 policies linked into a single policy set (Say the Subscriber Event transform) and maintain ordering for them. This is much better than the pre IDM-3.5 approach where the Subscriber and Publisher objects had an attribute named something like DirXML-EventTransformation (one for each possible thing, Event, Match, Create, Placement, and Command) linking to the first policy in the chain. Then each policy object would have a DirXML-NextTransformation attribute This model had to change to allow for Libraries, and extending the model, so we moved to the current DirXML-Policies attribute in IDM 3.5. This is why you have to convert or upgrade the linkage model when you move from IDM 3 to IDM 3.5.

Anyway the final piece of Typed Name syntax is a DN reference pointing at the object being discussed. Well this is a DN syntax attribute, which means if you rename it or move it in eDirectory, the attribute continues to work. This is because eDirectory really stores a 32 bit integer that defines the object in the database, and only displays the pretty name whenever you look at it. So if you rename it, the underlying database value did not change, nor if you moved it. Just the pretty name that is displayed when ever we choose to look has changed. Sort of like a Schroedingers Cat, right? The DN value doesn't change till someone looks? Hmm, quantum eDirectory computing.

Now Designer will not let you move policies around, but eDirectory will.

So once you have moved everything into a Library in eDirectory, you can just rename the driver in your Designer project, then re import the driver from the vault. Then you get the correct linkage. In principal you could edit the DirXML-Policies attributes by hand, one by one, if you wanted too, but this is a LOT of work, when you consider there are usually twenty to forty such objects in a typical driver configuration (Thinking of IDM 4 Packaged version of the Active Directory driver).

Anyway, so now I had one driver, that has all its policies (Including Schema Map, which can be a problem, so keep that in mind) in a Library. I exported that as an iManager configuration file once, so I could move it to QA and Prod systems.

But then I edited the XML from the iManager export, basically pulling out all the XML that defines policy objects. The XML is pretty easy to understand and read. Most of the node names are really understandable in English. (Sorry for non English speakers, not much I can do about that one). Leaving behind the Filter, the GCV's, and some of the config settings.

Then I import this driver config a second, third, and so on time, and I get a new driver object, that is basically empty of Policy content, but linked to the policies in the Library.

You can see how this model can really help when you have to do connectors to say 5 domains in an Active Directory forest that are basically identical, with the exception of some naming configuration values. Make one driver, and reuse everything 5 (or more) times. If you realize there is a silly bug in one of your policies, change it once, and it applies to the other drivers on their next restart. We did for a parent agency that had hundreds of sites each with either its own local eDirectory or Active Directory. They had on the order of 150 drivers between those two types. Amazing how well it can work in the right circumstances!

Anyway, along the way, I somehow corrupted the driver image. I am still not clear on what I did, since I did not touch the base 64 GIF item. When I look in iManager it shows as empty. When I do a compare in Designer it shows that is identical. But iManager will not show the image.

My first thought was to reuse the Designer image, since that was still fine.
I went hunting in my Designer install directory and I found the image in Designer's palette and went in iManager to try and set the driver image to the PNG file from Designer. That is when I realized it is the wrong size and shape.

Well that didn't work. Next up, be clever, and try to LDIF out a working DirXML-DriverImage attribute from a driver I had yet to break and then LDIF import it onto a driver with a broken image. Still did not show the image. Not sure why that one did not work.

Just to double check I took the LDIF's base64 encoded text and decoded it into a binary, calling it a .GIF file and it shows nothing when I view the file in an image viewing tool. So maybe something more than base 64 is happening here?

It seems like I should be able to get a proper image to upload to iManager to fix my broken image? This seems like it ought to be easier.

I initially found the Designer PNG image, by expanding the driver in the Outline view and finding the icon item at the very end of the list. But that is the Designer image, a PNG.

The good news is that Properties of the driver object in Designer has an iManager icon side tab, and then using the image selector to find the correct path in my Designer install

The paths in my install are:
Designer icons:
C:\Program Files (x86)\Novell\Designer4\plugins\com.novell.idm_4.0.0.201104051747\defs\model_items\Applications

iManager icons:
C:\Program Files (x86)\Novell\Designer4\plugins\com.novell.core_4.0.0.201104051747\icons\iManager

Obviously you will have potentially installed elsewhere but you get the idea. Also, with different releases, Novell/NetIQ may up the version count for some of the modules, so the 4.0.0.201104051747 might change, but the rest of the path will basically be the same.

Once I had that GIF file, I could use iManager to reset it. I still had strange issues comparing in Designer, so I just gave up on it and ignored it, since I only care that it look right in iManager.

Anyway this was an interesting little tidbit, so I thought I would share it.