Novell Identity Manager is a big product with lots of moving parts. It can be quite daunting to get started working with it. Just as bad, the deeper you dig, the more complexity you discover. Now this is not necessarily a bad thing, it is just something you have to deal with. There is a learning curve.
Thus my attempt here to try and lower that curve. First off I have an article with stuff you should start off reading to get over the first hump in the learning curve. If you have not already read this stuff, take a few minutes and do so, it will pay off ten fold as you work through IDM: FAQ: Getting started with IDM, what should you read?
On top of the learning curve, there are some reasonably well known common problems that beginners in the product will run into. I figured that trying to write them down can only help. If nothing else, Google ought to find it, if you search for it.
Thus I started this series, with the first article that you can read here: Common Mistakes Newcomers to IDM Make - Part 1
In that article I covered the concepts:
In the second article, Common Mistakes Newcomers to IDM Make - Part 2 I covered examples of:
In the third article Common Mistakes Newcomers to IDM Make - Part 3 I covered examples of:
In the fourth article Common Mistakes Newcomers to IDM Make - Part 4 I covered examples of:
In the fifth article Common Mistakes Newcomers to IDM Make - Part 5 I covered examples of:
In the sixth article Common Mistakes Newcomers to IDM Make - Part 6 I covered the issue of:
In the seventh article Common Mistakes Newcomers to IDM Make - Part 7 I covered the issue of:
For this article, I wanted to talk about multiple servers in a driver set and some of the issues that come from that decision.
I discussed some of these issues when discussing the Per Replica attributes in the fourth article. Basically all the issues of interest are due to the unique nature of Per Replica attributes. A quick summary, in case you did not read the other articles seems appropriate.
Per Replica syntax type in eDirectory is quite a contradictory thing. It is allows you to flag an attribute as non-replicating, such that if there are replicas on three different servers, there can be three different values in the attribute, one per server. This turns out to be really useful when it comes to Identity Manager, since you can have the same driver configured on multiple different servers.
A single driver, can only exist in one driver set at a time, but that driver set can have multiple servers assigned to it. So a driver in a driver set that has 6 servers can be have settings for 6 different servers available, one per server. (This is one of the reasons why iManager and I think Designer still) default to making a partition of the IDM Driver set object, to make it easier to replicate around, as each server in the driver set requires a replica of the Driver set's partition.
You can read more about the distinctions between Drivers, Driver Sets and Servers in this article: Drivers vs DriverSets vs Servers in Identity Manager
So far so good. A bunch of configuration like attributes in the IDM driver sets are Per Replica flagged attributes. So there can be as many sets of settings.
But one really confusing things about the use of these attributes is how they are shown and managed in the various tools.
This is very different in iManager and in Designer.
Lets start with Designer, since it is a bit easier. First off, if you go restart a driver in Designer, it is different than in iManager and will actually try to restart both of them. Now as it turns out this is usually not an issue as to have a workable multi server driver set you pretty much have to have one driver set to Disabled, and one to either Manual or Auto Start. After all, if you left them both enabled (i.e. Manual or Auto Start, which is really just not disabled) then both would be collecting events, and when it came time to start the second one, it would replay all the events in its cache file (the TAO file) that have piled up, which would probably be pretty lousy.
Otherwise, when you are looking at a configuration page, (like Properties of the driver) for a tab that has per replica attributes, at the top of the window will be a server selector, and it will show you which servers perspective you are seeing.
Now one of the most ANNOYING features I find is when you are working on a server that is considered second or third in the driver set. This means that every single time you visit one of these configuration pages, it will always default to the 'first' server in the driver set. I do not thing it is really defaulting so much as not remembering where you last were.
This can cause a bit of heartache as you open up say the Global Configuration Variable (GCV) tab, and see nothing there! Wait, where did all my GCV's go?
Ironically this is actually BETTER than if you have them set on all the different servers and then need to add one, but you forget to change to the correct server, and you add it to the 'first' server instead of the 'second' server where you need it!
I am pretty sure the ordering of first, second, third, and so on for the servers in the list is defined by how they are added to the driver set, (Driver Set Properties page, Servers tab) which is pretty much alphabetical. I tried, you cannot reorder them in Designer.
The other annoyance, is if you are working in Policy, on a token that allows variable replacement, or even using the Global Configuration Variable token, when you choose the GCV selector, in the upper right hand corner there is a selector to add a new GCV. Although there is also a server selector in the upper left hand corner, I have found mixed results in getting the GCV added to the server I want it added too.
What would be a nice enhancement would be a button in the GCV page to sync the GCV's between all the drivers. The easiest way is to go the XML view, copy all the XML, switch to the next server view, XML view, and paste in all the XML text. If you are adding a new server, you can 'Migrate' the driver in Designer which syncs ALL the per replica settings, however that is a one time thing and there is no great way that I know of to keep them in sync, except manually.
What can make this worse is that you have a second server as a DR style backup and you have not been keeping them in sync, and do not have a Designer project handy, then the GCV's are stuck on the primary server and if the DR situation is such that the primary server is not available you can be out of luck.
The good news is that Designer will keep track of this stuff if you use it.
When you go to do a Compare or Deploy and there is more than one server the various per replica attributes get a slightly different notation when showing the differences between Designer and eDirectory. You will see that say, the GCV's will have a (server1) after it. (That is, open round bracket, server name, close round bracket). This is meant to indicate that its a per replica attribute and that this item where it differs is specific to this server. Thus you might have added a new GCV value to all three servers in the driver set, so you will see a line item in the Compare summary for each server, indicated by this notation.
This is quite useful in terms of keeping track of what is going on. On a side note, if you have connectivity issues (say you are on a VPN connection that can only see one but not all of the servers in the driver set) to any servers, they will show as empty, and if there is a value in Designer, it will come up on every Compare attempt.
As you can see, it is not too horrible in Designer, so long as you remember to always switch to the correct server.
iManager is slightly more interesting in how it does it.
First off, in the Driver Overview perspective, which is where I spend most of my time in Designer there is a selector near the top for the server name. This is potentially more useful than the Designer approach, since it will show you the running state of all the drivers in one view, from the perspective of the particular server. You can switch to see the other servers view if you need too.
Now when you open up the driver properties (Right click or left click, depending on your browser on the little Green light in each icons upper right hand corner that shows running state, and select Edit Properties) you see the view for a single server. It seems like it might depend on your iManager plugins for Identity Manager version, but usually it seems to me that you see the first server in the driver sets view by default.
Each section that is per replica based, has another server selector. This is most annoying on the Driver Configuration page, where in Designer you have 4 or 5 tabs (actually depends on IDM 3.6 or IDM 4, since with IDM 4 an extra one for Global Configuration objects has appeared in Designer) in iManager it is really a bunch of sections of the page, and each section has it's own independent server selector.
Alas, this makes it very easy to select the right server at the Driver Overview page, open the driver properties window, change to the server you want for the first section of settings, go to the second one, forget to change the server, and end up changing the settings on the wrong server! In hindsight this is probably a lousy user interface design choice. The only real solution is remember to keep an eye on it, and not forget. Lovely. I prefer when the user interface makes it harder for me to screw up, rather than easier. This is one of those features that slowly morphed and without a complete user interface redesign (which is basically what Designer got, moving to tabs on the side and then sub tabs along the top) it would be hard to fix.
This pattern is all over the Driver Properties in iManager so keep an eye open for it.
This per replica stuff also applies at the driver set level as you could have GCVs set on the driver set that the drivers all inherit, but still they can differ from server to server. Interestingly enough, the new Global Configuration objects that became available in IDM 4 which needs them for supporting Packages, also have the same per replica issue. That is, there is a new object you can make in IDM 4 called a DirXML-GlobalConfigDef object class, that has an attribute, DirXML-ConfigValues, and the data in this attribute is per replica. In this case rather make a new attribute syntax and extend schema, they just added the object class for the new DirXML-GlobalConfigDef and reused the existing DirXML-ConfigValues which was already flagged as per replica in schema.
To use a GCV object in a driver, you have to link it in, just like you would an ECMA Script object. Alas it turns out you cannot do this in iManager, as although the iManager snapins for IDM 4 were updated to understand Packages, they were not updated to allow using Packages and Global Configuration objects were considered part of Packages. Thus in Designer, on the Driver Properties page, if you select the Global Configuration Variables side tab you will see a new tab along the top, one per Global Configuration object (Plus a default one for the driver object itself) you need to go to the Driver Configuration side tab, and then next to the ECMA Script tab along the top, select the Global Configurations tab to add or remove Global Configuration objects from the linkage to the driver.
As it turns out, this is actually stored in the DirXML-Policies attribute, and you can read more about that in these articles if you are interested:
Anyway, back on the Global Configuration side tab, for each top tab, there will be a server selector to make sure you are looking at the copy from the correct server.
One thing to note is that if the GCV is linked in as part of a Package, it will probably not let you unlink it. They would prefer that you remove the Package from the driver, maybe copy it into a new Package of your own, and not include the GCV object in your new Package. This keeps the Package state 'clean' instead of 'dirtied'.
There is tons more to say about Packages, which you can read about in these articles, if you are interested.
That about exhausts my list of ideas for articles in this series, so unless someone suggests some more or I think of more, I think we can wrap this up. Please let me know via a comment, a message in Cool Solutions, an email, or whatever if there is an area that befuddled you when you started with IDM and maybe I can help clear it up for you.
Support
Documentation
Learning Services
Partner Programs