With the release of Identity Manager 4.5, a new version of Designer came with it. I like to report on new features in each release, in ways that affect the IDM admin.

You can read some past articles of this type:

• 
  Series: What has changed between Identity Manager versions
  

• More on what’s new in IDM 4

• New features in IDM 4 and 4.01 – Part 1

• New features in IDM 4 and 4.01 – Part 2

• Designer 4.02 Refresh has Been Released

• What’s new in Designer 4.02 Auto Update 3

• What’s New in Auto Update 4 for Designer 4.02

I went through the Readme to try and explain the consequences of each called out new feature. There are many additional bugs fixed, and I will call out the ones I can find. Staring with the named new features in the Readme.

• 64-Bit Designer

• Designer 4.5 is built on Eclipse Standard 4.3.

These two items together amount to a huge upgrade, since at the same time we get a 64 bit version. The combination of 64 bit, Eclipse update, and background code fixes have made a big performance increase in Designer. It is worth noting this is Eclipse 4.3.1 not 4.4 the latest bleeding edge build, but I will take what I can get here.

With the move to 64 bit, the question is, did they manage to change from using JClient over NCP to a more LDAP based approach for live events? This is one of the main issues with porting Designer to the Mac platform. There is no NICI or JClient for Mac. JClient is the Java library used to talk to eDirectory, and while you can actually get Designer to run on Macintosh right now, it can only do offline tasks, it cannot talk to eDirectory to import, compare or deploy items.

Additionally, there are VPN and NAT issues with NCP as NCP contains within its data packet the original IP address, which can make NAT/VPN not work well. The expectation is that a move to a LDAP replacement for JClient would eliminate these problems.

However I have gotten it confirmed that the move to LDAP did not happen in the 4.5 timeframe. It is being worked on, but was not ready in time for the 4.5 release.

"Perform Out of Band Sync (Subscriber) Option is Added to the Filter Editor Attribute Settings

This option is available only for Filter attributes on the subscriber channel. It allows you to assign a higher priority to the selected attribute and have it processed before the other attributes that are in the queue.

For more information about the Perform Out of Band Sync (Subscriber) Option, refer to Changing the Filter Settings in the NetIQ Identity Manager Policies in Designer Guide."

This is a very interesting new feature. A second queue for events (TAO file) is created for any driver with one or more Out of Band flagged attributes. Any event for an Out of Band sync flagged attribute will get written to both queues (the normal queue we are used to and the new queue). When the event is processed in the Out of Band queue, it will remain, marked as processed, until the event in the regular queue is processed. Then the main queues event will be skipped and the out of band sync queues event will be cleared. This avoids playing the event twice. You can imagine how important this is, else a password change flagged as out of band, potentially would change quickly, and then at some indeterminate time later change it again which could be bad.

The Dashboard view in iManager will show only the standard queue views at this time, the Out of Band sync queue stats should get moved into there later.

The cache browser that is available for the main cache file, is also available (from a slightly differently named menu item) for the Out of Band sync queue which is good. Dxcmd has some extensions to manage this new queue.

Amusingly, the original name was Priority Sync but of course that name is actually used for a feature of eDirectory and confusing. Thus the rename to Out of Band sync, however the underlying XML in the filter is priority-sync="true".

This is technically an engine enhancement, but the way you enable it, is in the Filter editor in Designer, which makes it get into our list.


Startup and Shutdown Policy Sets in Policy Flow View

In IDM 4.02 Patch 3, two new policy sets were added, Startup and Shutdown, to facilitate the needs of the Permissions Collection and Reconciliation Services (PCRS) project. But the way they were displayed was pretty obscure. You can read more about some of the funny consequences you can get into in this article:
https://www.netiq.com/communities/cool-solutions/idm-array-index-out-of-bounds-error/

They were shown if you clicked a driver line in the Modeler view, then in the lower left window, selected Policies, you would see the two new Policy Sets. Now they have their own little icon for each, at the top of the fishbone view. You can see that in this image:

Improved Job Deployments:

This is a nice enhancement that moves more functionality into Designer that previously required iManager. When you deploy a Job you can now set the permissions the Job needs to run. Kind of like how you set Driver Security equivalence when you deploy a driver.

Package Manager Enhancements:

This is a set of a couple of things improved in Packaging.

Package Deprecation:

This is a new feature. With Packaging, we got the idea of publish a package to a repository. This was just a file system path, where the site.xml file gets updated with the appropriate new packages, and the files are stored in the proper format. (If you just build a package, you get one JAR file. If you publish, it is split into two files for some reason). Well that is fine if you need to distribute the addition of a package. How would you push out the fact that say version 1.0.7 has a horrible bug, you wish to recall it, and no one should ever use it? Thus we get the deprecation feature.

For everyone who first installed Designer 4.5 they would see this error since the deprecation list was not available on the public update sites:

Unable to download the deprecations file from Novell Public

java.io.FileNotFoundException: http://cdn.novell.com/cached/designer/packages/idm/updatesite1_0_0//deprecations/deprecated.properties
	at sun.net.www.protocol.http.HttpURLConnection.getInputStream(Unknown Source)
	at java.net.URL.openStream(Unknown Source)
	at com.novell.idm.ui.contentupdates.PkgUpdateAction$1.fetchDeprecationList(Unknown Source)
	at com.novell.idm.ui.contentupdates.PkgUpdateAction$1.run(Unknown Source)
	at org.eclipse.core.internal.jobs.Worker.run(Worker.java:53)

Which brings up the question of how does one add a deprecation file? The good news is the error gives us a very useful hint. The URL is a great hint:
http://cdn.novell.com/cached/designer/packages/idm/updatesite1_0_0//deprecations/deprecated.properties

So the base URL for the update site is:
http://cdn.novell.com/cached/designer/packages/idm/updatesite1_0_0/ (For Designer packages in the old version format)
http://cdn.novell.com/cached/designer/packages/idm/updatesite2_0_0/ (For Designer 4.02 packages that have the date in the version string).

The rest of the URL is:
deprecations/deprecated.properties

So we need a file, in the deprecations directory named deprecated.properties. We can look at NetIQ's public sites to guess at the format. I found buried in the file system an actual sample file that explains how it works and I will write an article about later. If you do not need to deprecate anything in your Package Repository you can basically ignore this.

You can now view package readme during package upgrades.

This is something that annoyed me, and I am glad they fixed. I like reading readmes (witness this article). I like writing Readmes (witness my entire collection of 380 articles). So when I build a package I usually write a long Readme or Description. Though since this feature was missing for so long, I just wrote everything into the package Description. You know that would be a nice enhancement, just like you can append the changelog to the Readme of a package, be nice to copy the Description to the readme. When you Imported a packaged into your catalog, you could read the readme at that time. Now you can do it while upgrading a package. Here is an example of what the screen would look like:

The example image shows that there were changes for the 4.5 packages. Oh dear that means I need to start writing a series of articles figuring out what changed in each of the 4.5 packages. Oh well material for the next year, until 4.5.1 and then I have to start again.

Designer now prompts for migrating linkages at startup for older projects.

This is a nice idea, to ask you to Migrate Linkages, which you used to have to do from the Package Catalog, right click, Migrate Linkage, but alas, this introduces a particularly nasty bug, where if you open a Project that needs linkage migrated, and you say Yes when prompted, it will re-arrange all your drivers. Now if your project has a single driver, who cares. But in a project with 100 drivers in 4 vaults, and they are arranged by category or whatever, this is very painful.

The good news is there is a simple workaround. Just say No when prompted, once the project is open, go to the Package Catalog and right click, select Migrate Linkage and save the project. Now it will no longer prompt you, and all is good.

Support for Integer 64

This is a nice addition. Peter Kuo of eDirectory book fame once told me that 64 bit integer support in eDirectory has been there for years now. The main use case I know if is for a timestamp value that is better than CTIME. The Time syntax in eDirectory is a 32 bit integer that when signed, starts 0 at Jan 1, 1970, but runs out at about 2 billion seconds in the year 2037. On a side note, was the roll of CTIME from 1.3 billion seconds to 1.4 billion seconds sometime in October 2014 a big deal for anyone but me? Sort of like the odometer on the car rolling over to 1,000,000 kilometers (I only ever saw a 1 million K roll over, that is about 600,000 miles, a full million miles would be a lot harder). Unsigned, CTIME runs out in 2108, which helps. But then you cannot define dates before 1970. The 64 bit timestamp model used by Active Directory is strange, but is the count of 100 nanosecond intervals since the year 1601, and handles dates for many centuries to come. (64 bit allows for VERY large numbers! 128 bits I once read could hold the count of atoms in the known universe. Scary how big powers of 2 can get you).

I had noticed a while back while doing a series of article son eDirectory syntaxes that Designer did not support Integer 64, so nice to see it added. However, there is no usage of a 64 bit timestamp in eDirectory that I am aware of yet. We will probably have to switch fairly soon. The year 2037 is approaching faster than I would like to admit, and a better time syntax would be helpful.

Updating Schema During Deploy

This one I am of mixed feelings on. The notes says "Designer now automatically updates the eDirectory schema during deploy operations when required." I need to investigate the specifics of this implementation. I do NOT want Designer deploying schema unless I tell it too, since Schema changes are not that big a deal (Looking at you Active Directory. Get over it, it is just schema!) but nonetheless want to control it.

Specifically I know WHY they implemented it. With the fix in Designer 4.02 Auto Update 4 or 5 they added a new attribute in eDirectory, DirXML-pkgLinkages that is really quite useful. It allows you to deploy the Linkage information from your package to the vault, so that a reimport you can retrieve Linkage information. This was a real pain point before. However they needed to get that schema change out and the 4.5 installer will now include it in its schema update, but 4.02 trees might still be missing it. (This is part of the Migrate Linkages process, to start using this attribute).

The key is, what other attributes might it do this for? If just DirXML-pkgLinkages I could live, but I want to be sure.

That is the high level stuff. I will have more to say about bugs I can find, or interesting known issues in the next part of this series.