With the release of NetIQ Identity Manager 4.5 a bunch of new options were made available, notably in Designer itself. In the context of Package Management, the biggest one is probably the Migrate Linkages option. As a side note, if you open an older project in Designer 4.5 you will get asked if you want to Migrate the Linkages to the new model. In general this would be a good thing. But there is a silly GUI bug, where if you say yes, it will set the Arrange of your project to Auto, and all the placement of driver objects and vaults you may have spent hours getting just right will get lost.

On a single tree, single driver project this is not a big deal. On a project with dozens of drivers, multiple trees this really sucks. The good news is there is a simple workaround. Open the project, say no to Migrate the Linkages, and instead once inside, right click on the Package Catalog node and select Migrate Linkages and save. This has the same affect, without the painful side effect. (Alas there seems to be now way back except to switch to a backup copy of the workspace if you make the mistake of saying yes.) I have reported this and hope it will be fixed in the first major Auto Update for Designer so my hope is by the time you read this, the point will be moot.

Even with this pain, the linkage migration thing is still a net benefit. What happens is a new attribute DirXML-pkgLinkages is added to schema in later versions of IDM 4.02 and Designer 4.02 that store the Package linkage info in eDirectory. This was missing before, only the Package in the Designer catalog knew the weight values of content, but now that gets written to eDirectory. Also until you Migrate linkages you do not get to see the weights shown in the lower left Policy window. (I have asked if we could get those weight items to be editable there, so instead of right clicking Package Properties, third item, Linkage, and changing the value, just type in that space, we shall see if they deliver.) There is some bug I do not understand well enough to report, where even though you have done the Migrate Linkages, the weight values do not show up, but once again, right click on the Package Catalog, Migrate Linkages and then they start to show up.

One of the other more interesting additions is the notion of deprecating a Package.

I think Packaging was one of the best new features added to IDM in a while. The idea is, before we had these big monolithic XML files with the entire driver config, including a Base 64 encoded version of the iManager and Designer icons. That worked, but if you had ever tried to migrate a project from Development to QA to Production, you probably ran into the pain of trying to figure out what stays the same, what changes.

There are all sorts of approaches to mitigate this pain, all of which remain true in Packaging. For example, don't hard code DN's into your policies. Use a Global Configuration Value, and then you change them to match the QA tree naming model and then Prod. If you are smart, you try to avoid that altogether and use the dirxml.auto.driverdn GCV which is automatically populated in every driver. You can ParseDN that to get the DriverSet, and whatnot, if that is helpful. The tree name is available as dirxml.auto.treename as well.

Even more helpful is the move to separate GCV objects (DirXML-GlobalConfig object class) that allows each Package to contribute its own set of GCV's, and for a driverset and driver to have many such objects linked to it. Thus your Package can easily add and remove its GCV options.

Now you can make an add on package to deliver your extra policies, Entitlements, Jobs, Mapping tables, ECMA Script objects, whatever you need.

On top of the functionality of the Package model, there is also the ability to build the package into a JAR file that you can share with others. You can also lock the Package by releasing it so the version stays constant and makes it easier to track who has what. Once you release a package, you have to make a new version to modify it further. Finally you can Publish a Package to a repository. This allows you to give a customer (or a friend you are helping) a URL to add to Designer that it will check when it does that Checking For Package Updates thing (often at startup of Designer).

In fact I have a public Repository you are welcome to add to your Designer, and play with some fun Packages I have developed.

To use my Repository, go to Designer, Windows menu, select Preferences, expand NetIQ, then expand Package Manager, select Online Updates, and add a new Repository. Call it what you like, I would suggest CIS Package Repo and set the URL to: http://idmfolder.ciscony.com/cis-idm-repo

It happens that my day job, (when not writing these articles) is with a consulting firm Computer Integrated Services LLC out of New York. If you have an IDM project you need help with, contact us. (Company web site is http://www.cisus.com and all my Packages have that info in them as the Vendor information).

Do a Check for Package Updates from the Help menu, restart and they will be available.

At the moment there are a bunch of interesting packages I make available there.

• An add of for the Work Order driver that will do a better job on every polling cycle if you have lots of pending work orders. (Tested at a client with 24,000 pending WO's and it went from 10 minutes to 40 seconds a polling cycle. Faster if you turned off trace).

• An Alternate Logging approach, based on Holger Dopp's truly excellent work on the SAP drivers. Turn off trace, use this instead and you get the performance boost, but also get to see much of what happened, or hopefully enough to get a hint of what went wrong. (Then turn trace on and reproduce to be sure).

• An add on to allow you to do Exchange Mailbox load balancing with Resources. Modifies the Exchange query that User app does for the Resource to Entitlement assignment to return a Load Balancing Option for the value of 'defer'.

• A License clean up tool. Try to find all inactive users, disable them (or not, GCV controlled), remove any DirXML-Associatons, and critically clear the object class nrfIdentity (which is how the auditors screw you if you don't). It is not perfect, complete, but if you have a use case let me know and I will add support if I agree.

• A Package I built for an article about Nodeset vs Strings.

• A Multivalued Attribute cleaner, for when eDir has an attribute multivalued, and the target (mainly Active Directory) has it single valued. Save you those pesky errors.

Try them see if you like them. I think I will be using this to distribute future packages, so one day you may get a nice surprise of some new package I added.

With Packaging, the initial implementations were focused on adding things to a driver. Look at my list above, an Add on to Work Order processing. An Add on to Exchange Entitlement handling. An Add On to the AD driver for multivalued attributes protection. What is missing is an easy way to remove things.

Deprecations is a step in the right direction since it sets up a way to remove a Package from the catalog.

Lets say I realize after I release it, that version 1.0.1 of my License Clean Up tool has a horrible bug I missed and in some cases, goes on a deleting rampage. (That would be bad. I will do my best to avoid that, but just coming up with ideas here). I suppose I could go through the Web Server logs and try and find every IP that read that file and try to find the user and warn them, but that would be impossible to do. Especially since I would only have the IP of the host at best. But with 4.5 a new directory is added when you do your first Publish of a Package. Inside the 'deprecations' directory will be a file 'deprecated.properties'.

In fact, Designer, when it does a Check for Package Updates will look for this folder, and on older repositories, that did not have it, throw an error in the Error Log that it cannot find the deprecated.properties file.

Amusingly, early releases of 4.5 had some typos in the code that I was able to report and get fixed that meant it never actually found it.

On a side note, one of the new features in Designer 4.5 (which really comes from the Eclipse upgrade to 4.3) is the Quick Access box on the toolbar, in the upper right. If you just click in there and type Error, you open the Error Log view. Before you had to go to the Window menu, select Show View, mouse down to Show Other, then expand the General section, to finally select Error Log. Now it is much faster. Yay!

The format of the deprecations file is shown below, in an example I grabbed from the NetIQ package repository.

#This file contains all the packages which are deprecated in designer.
#Usage 
#------- 
#$lt;Package short name>=$lt;Package version 1>/$lt;Text to be shown in the tooltip>,$lt;Package version 2>/$lt;Text to be shown in the tooltip>,......
#where Package version can be a single package version, or a range of package versions. Each entry in the above template are comma 
#separated.
#
#Package version range can be defined in one of the following ways
#
# 1) *-version# : This denotes that all packages that have versions less than or equal to 'version#' will be deprecated.
# 2) version#-* : This denotes that all packages that have versions greater than or equal to 'version#' will be deprecated.
# 3) *          : An asterix denotes that the whole package is deprecated. Here, all the available versions for the corresponding package will be marked as deprecated.
#
# Example:
#
# NOVLPKG1=0.0.2,0.0.2.20140507110740/Package tooltip.
# NOVLPKG2=*-1.0.2.20140507110740
# NOVLPKG3=*
#
#---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
TRVRRSABASE=*/Deprecated RSA Base driver from the designer build as this driver is no longer supported from IDM 4.5.
TRVRRSADCFG=*/Deprecated RSA Default Configuration driver from the designer build as this driver is no longer supported from IDM 4.5.
NOVLSENTSMQ=*/Deprecated Sentinel Sonic MQ Configuration driver from the designer build as this driver is no longer supported from IDM 4.5.
NOVLSENTB=*/Deprecated Sentinel Base driver from the designer build as this driver is no longer supported from IDM 4.5.
NOVLSENTAMQ=*/Deprecated Sentinel Active MQ Configuration driver from the designer build as this driver is no longer supported from IDM 4.5.
NOVLAVYAB=*/Deprecated Avaya Base driver from the designer build as this driver is no longer supported from IDM 4.5.

Thus with IDM 4.5, they removed the RSA driver (base and default configuration packages), Sentinel driver (Sonic MQ and Active MQ configurations), and the Avaya phone system driver.

You see this in the package catalog, when you go to add a driver, that these specific packages are shown in strike through. The ability to control the specific version, versions less than, greater than or all versions is a nice versatile option. Thus in my example I could easily deprecate a specific version. I have not tried, but I think I would still need to add a new package to get your Designer to pick up the details. I do not quite know if every Check Package Updates will read the deprecations and apply them regardless. But as I think about it, maybe it will, since it reports an error on every check if there is no such file in the repository.

This is a nice feature to be added on, since the ability to remove things is otherwise lacking in Packages.

Probably the biggest problem is how to remove items from the Filter. Right now, each Package provides a Filter Extension, with the Filter XML. These are added together to 'sum up' to the effective filter.

A side note, while the new Global Resource object (DirXML-GlobalConfig), ECMA Script, Mapping Table and others get their own mention in the "New" menu, when you right click on a Driver object in the Outline view, there is no entry there for Filter Extension. This is a huge area of confusion for folk new to Package building. It turns out that many of those objects I listed, are actually DirXML-Resource objects with specific DirXML-ContentType attribute.

The options are:

application/vnd.novell.dirxml.mapping-table xml ;charset=UTF-8
text/ecmascript;charset=UTF-8
text/vnd.novell.idm.entitlementConfiguration xml
text/xml
text/ text
application/vnd.novell.dirxml.ds-object xml
application/vnd.novell.dirxml.pkg-prompt xml
application/vnd.novell.dirxml.filter-ext xml

The very last one is the Filter Extension. Thus you would chose to make a new Resource object, name it and then select the proper Content Type. Then Designer knows which editor to load when you open it. Thus that is the difference between an XML (text/xml) Resource and a Mapping table, in case you ever wondered. Just the DirXML-ContentType value.

The problem is, a filter extensions contents are added on, and even if you added an additional extension without an attribute, it does not remove the attribute that another extension may have added.

Thus it is hard to properly package something as an add on that removes an attribute from the filter.

Removing a policy with a Package involves a two step dance. First you have the version of the package with the policy. Then you make a new version without it. Upgrade from one to two and Designer will delete the policy and on a deploy delete it in eDirectory. Alas, if you do not own the package and want to do this in an add on, this is still a problem.

I am always glad to see new functionality being added to Designer, and this is a nice example of making Packaging better. I hope we see more improvements in coming updates.