With the release of Identity Manager 4.5 SP1 a bunch of things got updated. I wanted to discuss some of the fixes and new features in the Designer 4.5 patch 1 update in this article.
I have discussed some of the bug fixes and features new in IDM 4.5 itself in these articles if you are interested in more information.
This update to Designer at least came as an update, instead of a full installer, which is nice. Much easier to upgrade. One thing to keep in mind about Designer updates is that they occur within the process permissions of Designer itself, so how you launched it and from where matters. Earlier Windows versions of Designers nicely installed into c:\Program Files(x86) which is fine and appropriate but when you go to upgrade that path is protected by Windows UAC and if you did not run Designer as Administrator then the update downloads, looks like it installed, you reboot and nothing happened. The simplest fix they implemented in 4.5 was to change the default install path to c:\netiq\Designer, which is not a protected directory. The same issue was true for Package updates.
If you are not seeing the update, go to the Window menu, Preferences, expand NetIQ, and select the Identity Manager side tab. Then there is a top tab, Updates. NetIQ is transitioning from the cdn.novell.com content distribution network to the nu.novell.com setup (which OES uses for licensing SUSE I think so check that the URL is set to something like this:
https://nu.novell.com/designer/updatesite4_5_0/
While you are there, check your Package Manager update location as well since that is changing as well:
The update has a What's New that it shows, and is available from the Help menu in Designer as well. I figured it would be useful to explain what some of these fixes and features are all about.
Designer provides a single view user interface for viewing and upgrading the installed packages in your Identity Manager project. To access the single view use interface, right-click Package Catalog in the Outline view, then select Package Upgrade.
This is a great new feature. A bunch of people have requested it and you will appreciate it once you get seriously into using Packages. You can imagine that you might have dozens of packages deployed and you may have updated some of them or not. In many cases, you may be using the same package on many drivers. (The extreme case is a friend who advocated hard for this feature, since he has about a dozen instances of the same driver, that would all need package updates at the same time.
Right now you would have to go to each Driver, select properties, Packages, then upgrade them one at a time. This new features helps by giving you a single consolidated view that shows all the drivers, with all their packages. Each package has a version show, and if there is an upgrade you can chose it here.
This is also helpful as it shows you in a single view what packages are installed on which drivers. Before, there was no easy way to tell if this package was installed on more than one driver. As the title says, you get to this by right clicking on the Package Catalog icon in the Outline view, and select Package Upgrade.
This pops up a new window that looks like the image here.
You can see the tree, driver set, and driver level packages that are applied, with the current version and the latest upgrade available. As is usual in these types of Package interfaces, if there is more than one version available you can select the specific version you want to use.
Imagine NetIQ releases an update the Password management Common package, and you wanted to update it on all 10 drivers it is deployed on. You can imagine how much clicking that would take. In this interface, simply select that package on each driver to upgrade. Now you still have to deploy the changes to the vault, but at least this step was made much easier with this new feature.
Personally I had been advocating for a slightly different approach. I wanted it part of the Dataflow sub tab when in the Modeler view. If you are not aware of the Dataflow tab, you should take a look, it is very powerful. When you open a Designer project and see the graphical layout of your project, that is the modeler view. At the bottom of that screen are 4 tabs. Try the Dataflow one. This shows all the drivers, all the filters, for all attributes in one place. This way, if you decided to start syncing one new attribute on 22 drivers, you would just find the class down the left side, expand it, find your attribute and across the line start changing the setting to what you wanted. Then from this view you can deploy all the filters. In the upper left, there is a drop down, that has a similar option for Password Synchronization settings. This does the same project wide consolidation of all the settings in one place so you can easily change it across many drivers. i wanted another option for Packages in this view. Seemed like the right place to put it.
If you do not have a lot of packages and drivers, this is less useful, but still it shows you nicely in one view what is installed on each driver. If you have dozens of drivers and many packages, this is really helpful.
Designer now extends the Compare Customization feature to the driver set and Identity Vault packages in addition to drivers. This feature compares the package items with the driver set or Identity Vault items similar to the driver items.
This is an important fix. If you want to start making your own custom packages, one of the most common things to do is to clone the NetIQ delivered Default Configuration for your driver, give it a name relevant for your company/university/house of ill repute (but I repeat myself) or whatever and then start making all your changes in this. But this means you no longer benefit from updates NetIQ makes to their package that you might be interested in. For driver objects, you can compare versions of the package, and even individual items from the package. Like two Policy objects. Or two prompt objects. (Now comparing disparate things makes little to no sense, so keep it like with like).
This means, when NetIQ released a new package version you could compare the versions, see what changed and port those changes into your package. I had a kludgey way of doing that before this feature. But this is much easier. However it did not work well for non-Driver packages. Until you needed it, this did not matter, but once you get used to it at the Package level, and then need it at the Driver Set level, it really hurts.
In fact, there are a number of things in Packaging that seem like they only work at the Package level, and were somehow forgotten when it came to the Driver Set level. Good to see them closing some of the holes.
Designer now supports comparing resource objects. For example, you can now compare objects such as resources, mapping tables, ECMA script, prompts, and so on, similar to the existing Compare Policies feature
You would think, that if you can compare package objects, like Policies and Stylesheets that you could compare Resources like Filter Extension, DS Object, Mapping tables, but you could not. There are a bunch of objects in IDM (mostly stuff that started in IDM 3.6 where a whole bunch of new features were added) that use the object class DirXML-Resource. Then there is a DirXML-ContentType attribute that supports a bunch of different values like:
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
You can see some well known types in there, Mapping tables, ECMA objects, EntitlementConfiguration, Package Prompt, Filter Extensions and so on. Now you can compare them one to another. In reality, they are all either Text or XML containing objects, the only value a specific DirXML-ContentType adds is that Designer knows the proper editor to open.
It happens, that if you wanted to see the underlying text or XML of such an object, where the Designer editor does not have a show XML tab, you can right click it from the catalog and try the other editors on it. Usually the text one works and will show you the underlying data the editor is working with. This can sometimes show subtle issues, that you might be able to fix by being a bit clever. I know I did this once but the specific example eludes my fading memory.
The most useful thing though is the Package Prompts being able to be compared. Again, you could compare a Mapping Table to a Filter Extension, but that would make no sense, since nothing would be the same so why bother? But you could. However Package Prompts are useful, since you can check and see if you got the needed customization done from the new NetIQ fixed package into your cloned package. This, like the Driver Set compare functionality was noticeably absent and I am glad to see it getting added in finally.
Designer now supports copying server-specific settings for GCV resources.
Identity Manager takes advantage of a really neat eDirectory feature called Per-Replica attributes. It is a flag in schema that tells eDirectory, that even though it is a replicated distributed database, the data for this attribute will not replicate to other replicas, instead it will remain as is on this replica. The copy on that other replica will not overwrite the copy here, they will remain independent. This is a bit strange if you are used to attributes replicating normally.
However IDM uses this in a clever way. Imagine you have 2 drivers in your driver set, one in the main data center and one in the backup data center. You can configure the main server to point at the AD, eDir, Notes, LDAP, or whatever instance in the main data center. Then you can have a totally different set of configuration data on the second IDM server in the backup data center which point at the AD, eDir, Notes, LDAP, or whatever instances in the main data center.
This is a very clever way of letting the underlying directory provide functionality with no real code changes needed, but it comes with some costs. If you add a new driver to your driver set, all the stuff stored in per-replica attributes needs to be copied over to the new servers appropriate places. That does not sound too terrible, but there are a fair number of places this stuff is handled.
GCV
Named Passwords (this one is hard since you do not know the value often)
Engine Control Values
Authentication Context
Authentication ID
Application Password
Remote Loader Password (But not driver password, that is shared on all replicas)
Designer (and actually, I just learned iManager) have a Copy Server Specific info option which is very handy. The UI is a bit less clear and clunky than I would prefer. In fact the first time I used it, I totally got it wrong and screwed up my project. This gives you a tick box of options you can chose to copy. From this bug it seems clear that while it offered to copy GCV data it probably was only just copying the DirXML-ConfigInfo attribute from the driver object and not the DirXML-ConfigInfo attributes from all linked in DirXML-GlobalConfig objects. With Packages, GCV's are now legal on the Driver Set, Driver object, and linked in via GCV objects at both levels.
This means that before, if this was a packaged driver, almost all of the GCV values were in DirXML-GlobalConfig objects and would not be properly copied. That is pretty bad, and I am glad to see it fixed. Especially since a packaged driver may have 6 or more GCV objects. If you have to copy the settings of 6 GCV objects to 3 new drivers that is 18 edits and could take a while and a whole heck of a lot of clicks.
That is about it for now, I have lots more items to discuss from the readme, so stay tuned!
True, I was thinking of the individual content objects, where if you look at a Policy, Mapping Table, or GCV, you cannot tell from the object itself which package it is from. On the Package itself in the catalog, there is the target, which is helpful to tell where the package is installed. Agreed.
This add on, though is very helpful if you need to upgrade many instances in one operations.
"Before, there was no easy way to tell if this package was installed on more than one driver." - not entirely true, just go to package properties and check the "Targets" tab. But you had to do it package per package, the new "Package Update" feature is much nicer to use, agreed.
Support
Documentation
Learning Services
Partner Programs