Driver vs Driver Set vs Servers in Identity Manager:

Sometimes I get confused within Novell Identity Manager, as there are many moving parts with multiple bits and pieces to contend with.

If you have not read through David Gersic’s excellent series on the basics of how Identity Manager works, then you really should.

David does a great job of taking the typical iManager or Designer view, that you would see when working on an Identity Manager project and walking through it item by item.

The primary difference between the iManager and Designer view, would be that in iManager to ‘fishbone’ diagram is laid on its side, right to left, left to right, and in Designer it is top to bottom. Personally, Designers approach works much better for me, as I am a smidgen right-left dyslexic, but can remember up and down directions much better. (I find gravity more digestible than right and left, go figure!)

On top of all the policies, and their order or execution, and why they execute, that David explains, there is further complexity in the use of DirXML Script to write any of the rules.

There is lots of content on the topic of using DirXML Script, more than is worth linking too, but the nice thing is that the names of the various tokens are pretty good. For example, the send-email Action you see in Policy Builder seems pretty straightforward (which is really a <do-send-email> token) and really is. Some subtly exists, which the help is actually often pretty good at dispelling.

Thus most of the articles you will see talking about tokens specifically, will focus on the subtle stuff, that does not really make it entirely into the documentation. For example:

These first two, discuss the subtle and important differences between the Attribute, Source Attribute, and Destination Attribute tokens as well of the benefits of using each.

Here are some more generally interesting token articles that can be helpful.

On top of the policy flow, DirXML Script, there is a further lower level concern.

The basic unit in Identity Manager is an object. Probably the lowest level is the Policy object (could be a Style sheet object, or a Mapping table, or a ECMA Script object, but you get the idea).

These objects exist in containers. There is a pair, the Subscriber and Publisher containers, meant to corral the appropriate objects into reasonable locations, to make finding them easier.

With the release of Identity Manager 3.5 and the change in policy linkage, it is possible to store them pretty much anywhere inside the driver set (heck you could probably get it to use an appropriate object anywhere in the tree, but I have never really tried that). This is pretty common in the use of Library objects now, so that one set of rules could be used in multiple drivers.

The Subscriber and Publisher containers exist below the Driver object. At the same level is usually the Schema Map, Filter, and Input/Output transforms.

Drivers reside inside Driver Set objects. The Driver Set object is often made into an eDirectory partition boundary. I happen to strongly disagree with the interface in Designer and iManager that defaults to creating the Driver Set object as a partition if you are not careful. That it should be a partition, I understand the reasoning. That it should be a default, I think is a mistake, because before you partition an eDirectory tree, you should check and be sure that the tree is healthy, time is syncing, servers are communicating, and what not. Otherwise, you are opening your self up to a world of hurt.

Driver Sets are assigned to servers, which are the where the actual Identity Manager binaries are executed.

Now there comes a little bit of complexity.

One server can host only one Driver Set at a time. One Driver Set can be hosted by multiple servers. One Driver Set can contain multiple drivers. Each driver should only run on a single server at a time (though in principle they could run on more than one at once, which probably would create bad end results).

Now was that clear?

The key is: A Driver Set can be assigned to multiple servers. However a single server can only host a single Driver Set.

Even that has a quibble, since one physical server could host multiple virtual machines, each with an eDirectory instance, or on Unix/Linux even host multiple eDirectory instances on a single server instance. Perhaps a better criteria is that a single eDirectory instance can only host a single Driver Set at a time.

Thus many drivers can be in a driver set, on several servers, with any combination of drivers running on any of those servers.

The servers can be any platform that eDirectory and Identity Manager is supported on, such as Windows, Netware (pre 3.6 alas, since Java 1.5 which IDM 3.6 relies on, has not been back ported to Netware), Solaris, Linux, and AIX.

0 votes, average: 0.00 out of 50 votes, average: 0.00 out of 50 votes, average: 0.00 out of 50 votes, average: 0.00 out of 50 votes, average: 0.00 out of 5 (0 votes, average: 0.00 out of 5)
You need to be a registered member to rate this post.
Categories: Uncategorized

Disclaimer: As with everything else at NetIQ Cool Solutions, this content is definitely not supported by NetIQ, so Customer Support will not be able to help you if it has any adverse effect on your environment.  It just worked for at least one person, and perhaps it will be useful for you too.  Be sure to test in a non-production environment.

Leave a Reply

Leave a Comment

  • anja98 says:

    I am trying to understand the process of assigning multiple servers to a driverset. By assigning multiple servers, does it means that the driverset will be replicated to the new servers being added?

  • geoffc says:

    Recall that the objects all exist in eDir, so since a requirement for a driverset is a partition containing the driver set, the driver itself is pretty much already replicated there.

    Except for the subtlety that the some of the attributes do not really sync, as they are per-server attributes. Think about config values, like hostname to talk too… You probably want a different one per server, yet only one set of attributes. So they were made server specific. Interesting idea.

    Hmm, maybe an article on the consequences of multiple servers in a driver set?

    But anyway, a driver should only run on one server at a time.

  • morganginga says:

    Can you have multiple servers running different versions of the Metadirectory Server within the same driverset? Example: Currently I have two Metadirectory servers version 3.6.1 running drivers in the same driverset. I would like to do a fresh install of version 4.0.1 Metadirectory Server on a fresh RH 6.2 box and add it to the driverset to copy the drivers over from the old servers to the new ones. Is this possible or would I need a separate driverset for the 4.0.1 Metadirectory Servers and migrate the drivers using export/import?

    • geoffc says:

      Yes, you can mix driver set versions. However, if you have Packaged content, obviously those drivers will not work, (actually should fail to load) if you tried to run them on the 3.6.1 engine servers. So long term, this is a bad plan. Short term as a migration plan it should be fine.

      • morganginga says:

        I don’t plan to change or add anything that is currently running on the 3.6.1 engines. I plan to drop the 4.0.1 servers into the driverset, create one new eDir-to-eDir driver on one of the new 4.0.1 servers (populate a new separate tree) and then over the next few weeks copy the drivers currently running on the 3.6.1 engines over to the 4.0.1 engines. Once all the drivers are copied over and running on the 4.0.1 servers I plan to remove the old 3.6.1 server from the tree. Sounds like I should be able to do this without reeking havoc with the current 3.6.1 servers/drivers.

By: geoffc
Oct 29, 2009
12:04 pm
Active Directory Authentication Automation Cloud Computing Cloud Security Configuration Customizing Data Breach DirXML Drivers End User Management Identity Manager Importing-Exporting / ICE/ LDIF Intelligent Workload Management Knowledge Depot LDAP Monitoring Open Enterprise Server Passwords Reporting Secure Access Sentinel Supported Troubleshooting Workflow