Working around an Compare/Deploy issue in Designer 3.5:

Novell Identity Manager has a pair of tools available for managing an Identity Manager system.

There are benefits and downsides to each approach, and because we have two almost equally relevant tools to manage it, we get something of the best of both worlds as we can choose to maximize the benefits.

Designer for Identity Manager (henceforth Designer. Have to distinguish, since Novell Composer, a product acquired as part of the SilverStream acquisition a few years back is a really cool product, and there used to be an Identity Manager driver version of it, and the management tool for it was called Designer as well. Alas the Composer driver, and Designer tool seem to have dropped off the product list) and iManager are the two obvious tools under discussion.

Designer has some major benefits, since it can be used offline, and if you are a consultant who has to take information with him, then you cannot live with out it. Of course some clients mandate that you NOT take it offsite, in which case, you work with what you have.

iManager has a benefit of all changes being performed live. Which conversely is also an advantage of Designer, that the changes can be modeled in their entirety before being sent into the live system. But with iManager, you need a live network connection to do much of anything, whereas with Designer you can work almost entirely offline, until it is time to roll out the changes.

Recently Designer 3.5 was released and I eagerly updated, because there are a number of new features included that increase performance on large projects or add new features that I really wanted, so I was an early adopter. Had to convince the rest of the team to upgrade at the same time, since there is support for new object types, and we share our projects via source control (A Subversion server, called SVN) and once you update a project to Designer 3.5 format and check it into the source control repository, everybody using it needs to be using the same versions.

However we ran into a really annoying bug that is really quite painful and initially bewildering, but thankfully, once you understand the cause it is really easy to work around. I tested, and it is NOT fixed in the November update to 3.5, alas, but the bug is marked as fixed in Bugzilla so we should be able to expect a fix released in the next update to Designer 3.5.

If you are looking to download Designer or updates to Designer, the best place to look for it to date is at:
http://www.novell.com/coolsolutions/dirxml/designer

The bug that was entered for this issue is available at:
https://bugzilla.novell.com/show_bug.cgi?id=557140

If you are not familiar with Bugzilla, it is a bug tracking application the Mozilla folk wrote as part of their project to re write Netscape into Mozilla and ultimately into what became Firefox and Thunderbird. It is open source, and Novell uses it to track bugs in their projects.

You as an end user can submit bugs, as well as viewing many bugs. Some are marked private, or Novell staff only, or other levels of permissions. For the most part, most bugs are made public. Obviously security bugs are hidden, as are some that involved confidential information.

If you find a bug that interests you, you can add yourself to the Cc: list to follow the bug as it is updated or changed.

This bug was actually entered, because I posted a question in the forums to see if anyone else was experiencing the same issue in Designer 3.5. This is a great way to confirm you are not going mad, by checking with the community of other people similarly using the same software.

If you do not have a team to cross check with, you can join a virtual team, and consider posting about it in the Novell Support Forums, which are hosted at http://forums.novell.com (if you can live with a web based vBulletin interface. I happen to be a big fan of NNTP protocol, so I use a news reader like Thunderbird, to connect to nntp://forums.novell.com which I find works better.) and look for the forum: novell.support.identity-manager.designer. For Identity Manager more general issues there is a engines-drivers forum with lots of contributors

If you are having an interesting problem, consider posting a sample from DSTrace, and discussing your issue.

While the forums are not actually formally supported by Novell, there is a dedicated team (some more so than others) who read and post as much as they can get away with, trying to help out. I.e. Volunteer support sysops, now called NKP's (Novell Knowledge Partners). Thus while you are not guaranteed a response, you can at least take a pretty good chance on getting help. Often just enough troubleshooting tips from the forums will give you the hint you need to figure it out on your own. If that happens to work for you, do what I do, and write it up as a Cool Solutions article! It is the process of troubleshooting that is complex and hard to both learn and teach. A walk through of some ones process can be enlightening and offer ideas to others in similar situations.

In this particular case, I had been working on a driver in a stand alone Designer project that I was going to import multiple times into the production tree. The theory was develop a generic Active Directory driver, so that by changing a few GCVs (Global Configuration Variables) in the configuration, and change the connection info to match the target, the same driver import could be used in many domains. We were initially looking at 20 or so. I worked in a standalone project, where I had two drivers. The original I was working from as a template, and a second instance (actually in a second tree entirely) a copy to reference when I needed to see something.

The reason I created a standalone project for this has to do with a limitation in Designers project model. Each object that exists in a project, needs to be reloaded, every time the Outline view needs to be refreshed, which is pretty much any time you switch tabs. What that means is, the larger the project gets, the slower Designer gets.

Now there are some tricks to help out. For one thing, delete any email template objects not being used, specifically the localized versions. Each one counts as an object and adds to that load. If you are like most installs, you may be using at most three email templates. In which case, get rid of all the Provisioning ones in all languages, or at least in all languages but your own. This cuts the number of objects down by quite a bit. You do not have to delete them from the tree, but you should remove them from your project. After all, if you ever need to use them, they are sitting in the tree, a compare away from being in your project.

You can really see this have an affect, if you open a bunch of tabs on a largish project (say 10-20 drivers) and try switching between them. Then close the Outline view and try again. Yep, it is really that much faster! Alas, you cannot actually work without the Outline view, unless you are just doing Provisioning and Workflow work.

For my generic driver, to make it more scalable, we used a Library object (a new container construct introduced in Identity Manager 3.5 and higher) in which we moved all the rules we were using, and linked them into the appropriate place in the driver configuration. Thus in the Subscriber channel, the Event Transform rule named sub-etp is stored as sub-etp.Library.Acme, instead of in sub-etp.Subscriber.DriverName.DriverSetname.OUName.acme but when you look in the Driver policy flow, you will see the sub-etp rule.

This is great, as one driver configuration file, can be reused, and share the basic driver rules. It also means that the driver export is pretty empty, as it has just the basic driver stuff, but very few (if any) of the rules. On a side note, be aware that Designer exports any linked Library references and driver set GCV's on every export. So you have to go in and edit the export file anyway, to clean that stuff up. Also it will export the Driver Set GCV's as well. So you REALLY need to go in and clean up the export if you intend to use it more than once. The good news is that the XML of the export is really quite readable, plus since you will recognize many of the GCV names and values as belonging to either the driver or the driver set, you should find it an easy task. Just remember to take out entire nodes, and keep the XML valid. I suppose an XML parser would make that easier to do. Heck, use the XML Editor in Designer and see if you can open an arbitrary text file to edit. After all, Eclipse does include such editors and Designer is based on Eclipse.

Basically on the first import, you want to import the Library rules, but not on the second, third or twentieth.

All was going well, until it came time to deploy and start testing the driver. I exported from my standalone project, edited out the stuff I did not want, imported my standalone export and again all was going well.

Went to deploy, started the process, then nothing. Look at the Error Log, and just meaningless errors about array out of bounds.

Something about how the error unfolded made me think of DN (Distinguished Name) referenced objects. I am not sure what it was exactly that made me think of it.

Any time there is a DN referenced object (Mapping table, Email template, Password policy (in Generate password)) Designer exports it as follows:

<do-send-email-from-template notification-dn="cn=security\cn=Default Notification Collection" template-dn="cn=security\cn=Default Notification Collection\cn=Password Sync Fail" template-dn-dot-dn="Password Sync Fail.Default Notification Collection.security">

There are several issues:

1. template-dn="cn=security" and so on. That format is incorrect, nonetheless ALL the default drivers have it, and it seems to work sufficiently well. I initially thought this was the issue. However

• When you import, the DN will change from
  
  cn=security\cn=Default Notification Collection\cn=Password Sync Fail

• to ..\..\cn=security\cn=Default Notification Collection\cn=Password Sync Fail which will fail.

The relative path calculation, even if the export includes the correct FULL path, will be wrong, and this is what is causing the deploy error.

The root cause of why that calculation is wrong is this part:
template-dn-dot-dn="Password Sync Fail.Default Notification Collection.security"

It is not needed, and if you delete it from the export file by editing the XML before you import, Designer will not 'fix' the path for you, to an incorrect relative DN, and thus Deploy/Compare will actually work.

If you have a problem comparing/deploying, you need to find all DN style references (Which appear to be primarily the Email from Template tokens (do-send-email-from-template tokens)) and edit them in XML view to be more correct. Heck, even clear it in XML, then use the picker widget in Policy Builder to reset it.

Typically, every driver has two rules, one in the Input Transform and one in the Output Transform named either

pub-itp-EmailOnFailedPasswordSub 
sub-otp-EmailOnFailedPasswordSub

if the driver has rules named by the 3.6 resource kit naming model or if the driver uses the older naming model, then look for:

Password(Sub)-Pub Email Notifications
Password(Pub)-Sub Email Notifications

To fix this, export your Driver set to a iMan config file, search for do-send-email-from-template and then look at the rules using it, go and fix.

This is a really annoying problem, with a really simple solution. Be nice when it is all fixed and just goes away.,