Novell Identity Manager initially came with a Console One plugin to manage policies and stylesheets, back when it was still called DirXML. Then as the product matured and DirXML Script became available we got iManager with plugins to manage it.

When Designer for Identity Manager was released, it really was a game changing paradigm shift for Novell's product. Being able to take a project offline, work on it, come back, push out (and double check) your changes made how we work on IDM projects totally different. Documentation generation did not hurt either!

Each release of Designer has added new features and functionality. I recently worked through a series on what is new in Identity Manager 4 Advanced Edition (and compared it to what was introduced with IDM 3.5 and 3.6 releases), which you can read here:

• What has changed between Identity Manager versions - Part 1

• What has changed between Identity Manager versions - Part 2

• What has changed between Identity Manager versions - Part 3
  

• More on what's new in IDM 4

Of course most of those features discussed included support for managing them in Designer. In fact, the series on what has changed is more focused on what has changed in Designer. But that was a high level overview and so much more has changed down low in weeds it is going to take a fair bit of work to get through them all.

With Identity Manager 4 Advanced Edition there are some major engine and Designer changes that are yet another example of a paradigm shift, and it can be summed up in one word, Packages. I started talking about Packages in these articles:

• A first look at some of Designer 4.0 New Features
  

• Let's talk some more about Packages in Designer 4 - Part 1

I wanted to continue on to more interesting features of packaging. In the first article Let's talk some more about Packages in Designer 4 - Part 1 I talked about versioning, base packages, building prompts, interesting linkages, GCV and filter extensions.

In the second article Let's talk some more about Packages in Designer 4 - Part 2 I talked about more details in the nitty gritty about packages like localization, dependencies and ordering, and finally about the package catalog and what is stored there.

In the last article I demonstrated a point with the Active Directory driver and all its many policies. You can see the list that shows up under the Package Catalog, in the Directory category in the Active Directory group:

Active Directory Account Tracking

Active Directory Audit Entitlement

Active Directory Base

Active Directory Default Configuration

Active Directory Entitlements and Exchange Mailbox Support

Active Directory Managed System Information

Active Directory Password Synchronization

When you try and install all those you will be informed there are additional dependencies you need, which will be resolved and shown as:

Audit Entitlements Common

Account Tracking Common

Data Collection Common

Advanced Java Class

Common Settings

They have broken-out almost all the policies from the base package and put them into a package called "Active Directory Default Configuration". This reduces the base package to basically shim parameters and maybe some basic input and output transformation policies. The reason for this is that they absolutely want people to use Novell's base packages so that we can push updates to shim parameters out easily.

For example, to add Incremental DirSync support with Active Directory first the shim itself needed to be updated to support it, and of course the Active Directory domain needed to be at a 2003 forest functional level. But to get the driver shim to actually use it, you needed to edit the XML of the driver configurations to add a new value. While this is not technically hard, it is sort of an annoying thing to try and get people to have to do to upgrade. Of course in later driver configurations, this is even more annoying since the XML needed is actually included, but the configuration parameter is flagged as hidden! So you would have to go into the XML view and change it to not be hidden, and then you can see it to change in the user interface. But again, explaining this to someone is a little trickier than it needs to be.

Another example would be adding support for Exchange 2007 and 2010. If you have read the TID's in the Novell Support Knowledge Base on how to do this, it is more than a little unclear. I consider myself somewhat good at this stuff, and the first time I tried following those directions, I got it wrong. So clearly it is not a trivial task to do. In the case of the Exchange 2007 and 2010 support there is again an update to the shim, a service, and some configuration values change. The binaries are easy to explain, but how about the XML changes?

With this new approach in Packages it is much easier for Novell to add new driver shim features, and controlling values via the base package, and not affect much of anything else. Of course you can imagine that they will probably need policies elsewhere to fully utilize the functionality, so that will just come in another package, that will require the specific build of the base package to work.

From the perspective of the IDM developer team who have to build and maintain these configurations and drivers you can see how this is a huge win for them!

To make people use Novell's provided base packages instead of creating their own, they had to minimize their content so that it would not be "in the way". After all who really likes the default placement, matching, and creation policies or the schema mapping and filters that the current default configuration ships with. Most people only use them as a starting point and make changes. What I often do is copy the default policies, create my own with [acme] in the name of the object so I know I have touched the policy, and then unlink the shipping configuration and link mine in, in its place. Well now I can build a package of my own to do that for clients!

Thus to prevent that all base packages would be either customized always or abandoned and not used, they removed all content that is likely to be subject to customization and put it into one package called "Driver Name Default Configuration" for every driver. That allows partners and customers to create their own "Driver Name My Configuration" packages and use those instead of Novell's but still use the same base packages.

You can see that a fair bit of thought and planning went into the redesign of the packages from the current configurations. Which is good, as the default configurations were getting a bit long in the tooth (no offense intended to beavers, rabbits or walruses with that comment). There was a fair bit of accumulated stuff in them that it was not always clear was needed, including a series of bugs that hung around for a while.

One of those dependant packages is interesting. The Advanced Java Class was a Java toolkit class that Novell Consulting wrote as they found they needed functionality not provided by the engine at the time. Much of this is NSure Identity 2.0 timeframe stuff, as you can tell by looking at the function set.

At a later date they got Shon Vella (his name is in the comments) to port the Java class into an ECMA Script library, which has all sorts of great ECMA functions you can learn from. To see a list I am maintaining of other interesting ECMA functions, you can read and contribute to this article.
Open Call for useful ECMA functions to use in Identity Manager

Many of these functions do things that tokens now do. For example there are a number of time conversion related functions. Prior to Identity Manager 3.5 and the Convert Time token it was a bit of a pain to convert time. The syntax to the Java time function while not explicitly arcane, was sufficiently complex to take some memory work. Whereas the Convert Time token is quite easy to use with no need to fire up any brain cells.

When you go to import a driver, lets keep going with the example of the Active Directory one. the process is a bit different than in the past. Previously you would select a monolithic configuration file and import. With later Designer builds, you might have a couple of different configurations to choose from, but then it was on to the prompts.



With packages, we now get asked and shown at first only base packages. As discussed above, there is not a whole heck of a lot in a base package. (And for some reason my Designer shows it in reverse alphabetical order sorting). It is worth noting at the bottom of that page there is an Import Configuration button which will allow you to fall back to the older configuration files, if for example you are using Designer 4 against an IDM 3.6 driver set.

Next we see the list of optional features. As discussed above this includes:

Account Tracking

Default Configuration

Entitlements and Exchange Mailbox Support

Data Collection

Password Synchronization

What you actually see is a topic name (without the Active Directory part), which if you expand the plus sign ( ) next to it, shows you the versions of the Active Directory version of that topic. I.e. You see Default Configuration, and then if you expand it you see Active Directory Default Configuration and the version is shown as 1.0.0.

Some of the topics need two or more packages to deliver the functionality, like Entitlements and Exchange Mailbox Support which includes:

Active Directory Entitlements and Exchange Mailbox Support

Audit Entitlements Common

Active Directory Audit Entitlements

Already, even with the IDM 4.0 release, some of the packages have been revised and are at 1.0.1 levels. This is probably a good sign that they were testing heavily internally to validate these configurations.

Then you get notified that there are some dependencies that need to be resolved. Each dependency will pop up its own resolution window, choose each as makes sense for you, though it probably will not work if you cancel out of any dependencies.



Now you start working through the new prompting part of the driver wizard that was mentioned in Part 2 of this series. Basically for each package and dependant package, there can be any number of prompts. You can see from the screen shot



that under the installation tasks, a whole long list of things have shown up. These are indicators of the prompts from each of the packages you chose to install.

This is actually quite nice, as it breaks out the various configuration and Global Configuration Variables that each driver needs, and actually lets you know which part of the system it is coming from. Of course, you can change them after the fact, but this nicely walks you through the options.

This is somewhat of a reversal from the IDM 3.6.1 approach where there was more of a design goal to minimize prompting, and just accept reasonable defaults that needed to be changed later. Here we now get a bit more hand holding, but also a lot more questions to answer. It is an interesting discussion to have in terms of which approach makes more sense, but this approach by breaking it into smaller chunks at a time, and since we know which module it came from, makes it a bit easier to manage. Additionally, not every package has prompts, and if there aren't any prompts in a package it is skipped over in the wizard, so it is usually not quite as bad as it looks. Perhaps an enhancement request would be to look ahead see if there are any prompts and flag the packages with prompts to make it clear it is not as bad as it seems. However, since this is usually a once in a while task, it may not be worth much effort.

In this screen shot



you can see that the Default Configuration as discussed above, is the standard mirrored vs flat placement. You of course can choose to write these all on your own, and use your own package here instead.

New for IDM 4 is the Reporting module. This keeps track of events and whatnot, different than how Sentinel would track events, since the context of interest is different. Sentinel is more interested in auditable things, where as Reporting is more interested in reportable things. The report that interests me the most if the State report. That is, what did an object look like at a moment in time. I like to imagine it like a backup/restore application that lets you see how a directory structure looked at a moment in time, overlaying the various full, incremental, and/or differential backups to show a synthetic view of the directory structure.

Well how does it get that data? Turns out since this is IDM, there is a driver for Reporting to collect that data. Actually there are two. The first is the Managed System driver, for which we get prompted to provide some identifying information that will be shown in Reporting.







Then there is the Data Collection driver, which I do not fully yet understand its purpose. I intend to delve into Reporting when I have time, as next on my list of interesting things. I am curious how the driver delivers the data to the Reporting database.

Now you are at the point of a regular driver import and good to go. Lets see what else is of interest in the next part of this series.