After the release of IDM 4.5 the first patch came out. One of the components updated is Designer, with an online update (or downloadable ZIP file). When you chose to install the update it shows a list of fixes and enhancements. As I have been wont to do, I decided to go through each item in that list and explain what I think it means. This way I hope to draw attention to new features, bug fixes, that get only a one liner in the docs.

I have done a series of articles on new features in various releases before. See the first article in this series for links to those various articles. Generally I enjoy writing these, since I find I learn about new features that I might otherwise have not noticed. Here we go with part 2 of this series.

Designer provides the ability to copy the Engine Control Values by using "Copy > Server-Specific Settings..." option from the Driver's context menu.

Similar to the ability to copy Global Configuration values discussed in the previous article, Engine Control Values are per replica attributes and if you add a new server need to be copied to the new server. Now ECVs are a special case as the engine will add them if missing in the default set of values. So you could just start the driver, let the engine populate them, compare and import to Designer. If you needed any changes made you could then do so, and push back to eDirectory.

Regardless this is still a welcome addition.

• 
  The Project Checker has been enhanced to notify if upgrades are available for the packages installed on a driver, driver set, and Identity Vault.
  

• 
  The Project checker has been enhanced to notify if the driver or driver set policies in a user created package have After/Before linkages or have the same weight in a policy set.
  

I have mixed feelings about the Project Checker. I think it is a great idea in principle, but I never actually use it. Well at least not until some error occurs during deploy, then I go look at the thousands of things it is complaining about. It is so nit picky about stuff that I mostly ignore it.

Thus on the one hand, I am glad it adds in some useful things, like notifying of available package updates, but that just seems like adding a bunch of noise to the process, which is already so noisy as to be unintelligible.

On the other hand I am glad to see it reports duplicate linkage weight issues and After/Before linkages. I am a big fan of NOT using the default weight of 500 that Designer selects. I was campaigning for a system where Designer is clever, and if you add a package into a specific location, then Add to Package, look at the policies on either side, and put this one dead in the middle between the two. (Maybe round to the nearest 10 to keep it clean).

When I reviewed the bug list fixed in IDM 4.5 and more for 4.5.1 I see a bunch of bugs for packages where there are duplicate weights. Which makes me think they decided to clean this up, and it was easier to add in a check to Project Checker to find them all, than it was to do it by hand. Then as a spin off they get a new feature! I have learned it can be wise to cast features you want, as bugs that if fixed, would make fixing the real bug much easier. My favorite story about that was a memory leak in Designer 4.0 where every time you opened up packaged content you got that annoying pop up about not modifying packaged content. But to reproduce my bug you needed to open 10-20 items. I pointed out to the developer that it would be faster to make that a 'Remember this decision' type thing first, then he could reproduce my bug. He said he needed a bug for it, so I entered one and he got a two-fer. Fixed two bugs in the time he was going to spend anyway on one. The team in India is pretty good on developing, you just have to learn how to ask properly.

The reason using weight of 500 is a problem is that you end up with lots of content colliding at the same weight. If every one uses 500, no one really uses 500. But there needs to be some kind of default. There was a bug in the ordering of multiple objects at the same weight that was fixed in Designer 4.5 I recall so this is less painful, but still it is better to not have the collisions in the first place.

Designer provides you an option to update the GCVs without the need for deploying the entire driver or the driver set that contains the GCV. You can now deploy the GCV from the Deploy Attributes section in the Driver or Driver Set configuration.

Until I started writing this, I did not actually think about what this bug means. The Package overview, of all packages on all drivers is probably the biggest enhancement but this one is a solid second place. This is great news.

The advent of packages raised a new issue, one of those unintended consequences. When you start using Driver Set Packages you find that you are adding GCV's or other attributes to the object. Previously if you compared, it would show what looks like an attribute listing the linked objects, but you cannot Update eDirectory or Update Designer. It is maddeningly close but so far away. This is because that with the IDM 3.6 release the model of linkage changed. (This is NOT the Migrate Linkages thing you see nowadays.) Used to be, the Driver object has attributes like DirXML-InputTransformation that had a DN reference to the first policy or style sheet object in the list. That object had a DirXML-NextTransformation attribute pointing at the next one in the list. All the policy sets were handled this way, with an attribute named with the policy set name on the Driver object or the Subscriber or Publisher container as appropriate. In IDM 3.6, a switch was made to allow much greater flexibility.

Now we use a multi valued Typed Name attribute. Typed Name has a DN and two integers. The DN is the object being linked in, and the two integers represent the Policy Set number, and then the ordering within that Policy Set. On top of the well known ones, GCV, ECMA Script have numbers as well. You can read more about it in this article:
Talking about the DirXML-Policies attributes

The numbering in case you care happens to be:

0 Schema Map
1 Input Transform
2 Output Transform
3 ECMA Script Object
4 Sub Event Transform
5 Pub Event Transform
6 Sub Match
7 Pub Match
8 Sub Create
9 Pub Create
10 Sub Command Transform
11 Pub Command Transform
12 Sub Placement
13 Pub Placement
14 GCV Objects
15 Startup
16 Shutdown

What is fun, is when they added Startup and Shutdown policy sets in IDM 4.02 patch 2 or 4, they had to add on 15 and 16, which led to a case where I deployed values for those policy sets to a engine that was not patched and it threw a pretty funny error. You can read about that story here if you are interested:
Bidirectional eDirectory driver – Dealing with a strange error

All that is to say since Designer shows it as a simple attribute, but under the covers knows it is a more complex part of a trickier attribute, simple compares do not work. In order to update in either direction it needs to be a Deploy or Import. Well Deploy is an all or nothing sort of thing. You deploy everything or your don't deploy. In the case of a Driver Set with 50 drivers, that can take a fairly long time, especially if all you want is to link in a single GCV object. To be honest, I stopped using Deploy for simple things like this and went into iManager and would do the linkage manually after Comparing out the object itself. This was not allowed on Driver Set objects by the iManager snapins making it even more painful.

This fix adds the option to Deploy Attributes, similar to the Compare Attributes option on a driver object, so as to not require Deploying all the children of the Driver Set (I.e. All the drivers). I would like to test this and see how much can be deployed this way, but this looks like a really big enhancement.

The downside to a deploy is that the passwords need to be deployed, but cannot be imported. That is, if you build a project on one machine in Designer, push it to the Vault. All is good. IDM Dude #2 is hired, he imports the project from the Vault, all is good. Alas, he did not pick up all the Application, Driver, Remote Loader, and Named Password values in that import. He has a project that knows they exist, but think they are blank. Thus on a deploy he will overwrite all those passwords. I wish they would fix this one. But this is why you want to be careful with deploy whenever possible.

Also Deploy inherits to all objects below, and all linked objects (Possibly in a Library, or some other object) and may update more than you expected. Thus with great Deploy power, comes great responsibility. When you are working on a team, be very cautious in your use of Deploy. I am hoping this option makes a big difference in that respect.

As a side note, there already exists an option to do at least an attribute level compare for the Driver, where in the Live menu, there is an additional submenu called Driver Attributes. I cannot remember now (and am not going to start up a D4.02 instance just to check) but there seems to be a Deploy attributes option as well. Wonder if that does the password thing too. This is why I write these things, in researching the answers I learn all sorts of fun things.


The Package Manager now provides a new document during prompt transformations for packages. This document will help the package developers to move the prompts from the driver configuration parameters to GCVs.

I spent a fair bit of time trying to figure out what they are talking about here, and I still cannot quite figure out what they are talking about. The problem is, to see a difference of an embedded style sheet, you would need to compare the old one to the new one, which is hard to do, since I would need to load an older version, then the newer version. There is actually a facility in Designer that can be enabled by changed a config file value that enables some interesting options in terms of bulk Package operations, but that has been there since Designer 4.0. (If you are part of my IDM User Group you would have seen a session that demonstrates this feature.)

That is about it for this one. Next up, is one last enhancement, a neat one that adds better documentation support by fixing a missing component. Once that is done there is one more section in the readme about Fixes Included. Stay tuned for part 3 where I will go through those. I have yet to decide if I will try and find all the bugs in Bugzilla that were updated and call out the interesting ones. That one is a lot more work so I am not sure if I will go that way or not.