Novell Identity Manager is a great and powerful product. For those who remember the early days when it was still DirXML 1.0 and first released, there was some talk of selling it only alongside a consulting contract. At the time, that was probably the right decision - DirXML 1.x was WAY too complex to implement without a lot of knowledge of the product.
With the release of 1.1, then Identity Manager (NSure and otherwise) 2.x, 3.0, and now 3.51, things have gotten better and better on many fronts. The driver shims that do the magic against the connected systems keep getting better! New features, more bug fixes, and better policy structuring show up in every release and build.
Identity Manager Solutions
But this presents a serious problem that many people run into and harkens back to the DirXML 1.0 days. It is a big deal to implement an Identity Manager solution. (I happen to believe Novell has one of the easier - if not easiest - models to use, but that is a personal opinion, and your mileage may vary!) It's hard to make changes to the solution once it is up and running, since it involves so many connected systems.
On the flip side, all these new features and fixes are coming out, and Novell, being a publically traded company needs to make money by selling new versions. From a support perspective there are limited number of versions that they can provide reasonable levels of support on. Thus, old versions eventually must be left to go to the big software pasture in the sky, and be phased out of active support.
This has happened reasonably recently in the Novell world with Identity Manager 2.01 being phased out. With the release of Identity Manager 3.5.1, and 3.6 due out sometime this summer, you know the lifespan of version 3.01 is limited. It has to be, no matter how much that complicates our lives.
Many people are facing this issue of an Identity Manager 2.01 install that just plain works. Now they are looking at it again - maybe because a disaster recovery project is asking them for DR plans for the IDM piece, or maybe because someone is reviewing licensing to make sure everything in use is supportable), and realizing they need to upgrade. This is not a minor issue, and to be perfectly honest, it can be quite scary and intimidating if you are not the person who wrote the original implementation.
So what do you do? Can you just slap the 3.51 (or 3.6 whenever they release it) DVD in the drive of each box involved (heck, do you even know all the servers involved in the solution? How many remote loaders?) let it autorun the Installer, and click Next, Next, Next, until you are done? Do you have to re-write everything, test it, deploy it again, as a worst case scenario? Or is it somewhere in between?
My goal in this article is to talk about some of the issues involved in an upgrade, to get you thinking about what needs to be done, and to help you down the road of actually doing it.
As I see it, there are a couple of issues involved in an upgrade. I am sure there are more, please write your own article with the details of what I missed so others can share it, or comment on this one!
Policy Language
Are any verbs, nouns, or tokens in 2.01 broken, deprecated, or removed in 3.51? To the best of my knowledge, no. The syntax for some of them has changed, but in every case I can think of, new functionality is added without impacting the old functionality.
Therefore, a straight upgrade of just the engine to 3.51 and nothing else should basically work every time. (Disclaimer: You cannot blame me if this does not work! It has worked for me to date, and I have not found a reason to doubt it, but please test first, ALWAYS!)
This is not the case from DirXML 1.1a to 3.51, to the best of my knowledge. In DirXML 1.x there was no DirXML Script language (or was it added at the 1.1a level? I forget when DirXML Script exactly began, but definitely in 2.x), so everything was done in an XSLT stylesheet. In principle, these should continue to work, but the complexity of what you can do in XSLT is sufficient to make this non-trivial.
Java Classes in Use
Are any Java classes you use inside the 1.x or 2.x world broken in a 3.51 world? Probably not, but it's impossible to answer from over here. The most likely example would be some of the classes used inside the AD driver that do time conversion. (If you are not aware of them, don't worry - it means they just plain work ...)
The biggest issue is that the underlying JVM you need for 3.5.x is sufficiently newer than the one used by 1.x and 2.x , and many things have changed. JVM compatibility between versions is a whole other can of worms.
Old Engine Quirks
Are you doing something in one of your policies that relies on a quirk of 2.x engine performance, that will be different in 3.x engine world?
I cannot think of a concrete example off the top of my head, but something close to this point is how login disabled and account login settings are handled in AD. In AD, the attribute is a bit mask called User Account Control, but we cannot write to it directly as an attribute via IDM. Instead, there are some psuedo-attributes on the engine side (DirXML-uACXxxx), that the shim maps to the appropriate API calls to set the value you want on the AD side.
The method changed between versions 2 and 3; before, you could only affect the Login Disabled by a mapping, and now you can use many of the User Access control options through the pseudo-attribute. (Thanks to David Gersic for the exact details of that tidbit.) I do not know for certain what the backwards compatibility is, but it is possible you exploited a weird quirk in this ... If you did, then that might break under 3.x. (low probability). My personal experience is that the upgrade just plain worked, but that was in a specific case of a single Active Directory driver to eDirectory, as the only driver, and almost no customization was done.
The Lotus Notes driver has a series of these as well. For example, Attributes such as [OrgUnit] and [AltcommonName] do not exist as real attributes in Notes, but the driver shim translates them into Notes API calls.
There may be other driver examples I cannot think of. (If someone knows, could you comment so we could them added to this article?)
Driver Shims Expecting New Parameters
When driver shims load, they expect and may require certain configuration values. Try loading a driver when you forgot to set the value, or accidentally cleared it, and you will see the failure pretty clearly in the trace.
When you update some driver shims, on the IDM server or on the Remote Loader, they will now be expecting configuration values you have not specified. Watch in the trace and it will be very clearly evident what happened. You can use Designer to drop a default config in any project. Look at the settings XML that gets configured, and you can copy that into your production driver pretty easily.
A concrete example happens when upgrading the JDBC driver shim (thanks to Aaron Burgemeister for this one). On load, it expects a couple of new parameters and will not load without them.
Policy Linkage Model
The way a driverset contains the policies has changed between IDM 3.01 and 3.5. This is basically a total non-issue. The first time you touch it with iManager after the engine is updated, it will ask you to change to the 3.5x model - and then you are done. You do it once, and that's it, never again.
New Features that Require Policies to Implement
Some drivers added new cool features that need new bits of policy to work, but they are not really broken out as standalone bits.
Thinking about it, I know the AD driver changed a lot (for the better!) The example above I gave about those weird attributes is much better than in 2.x. Also, there's the Notes example, the AS400 matching rule issue, and probably many more examples! I was hoping other people would contribute more articles on the theme I started in that article, and maybe the absence of any others means there are not a lot of examples?
Just overlaying the driver configuration XML file on top of your existing configuration is probably a terrible idea. Policy objects are the object level for this kind of an import, and the import will overwrite any changes you had made or additional rules you had added inside the existing policy objects. To truly answer the question, it requires a very intimate knowledge of what, why, and how a driver does what it does.
If your driver set is something you inherited, and you have no idea what this black box does, I would do the following:
Set it up in a test system on a VM model.
Isolate it from the real network and get it working.
Test the upgrade in there and answer it for your self.
This will not be a trivial exercise, but I think it is a very important one. It has the benefit of forcing you to learn what/why/how your drivers do what they do, to get the test lab working. Then you can test more effectively.
Once you have a test plan in place, you can validate that the engine and drivers are doing what you want and expect. Then finally, when you upgrade the test lab, you can just run the tests again and validate whether something broke.
Even more importantly, you will have a sandbox to play in and a test plan that can verify everything is working. You can use this to confirm that changes you have to make down the road are safe to roll out.
Also, as sure as the tides roll in, the next version of Identity Manager will come out, and we will have to repeat this process over and over again sometime in the reasonably near future. Worse than that, with the update of each connected system we need to be sure nothing major has changed, either (Windows 2008, with its new features in Active Directory, Lotus Domino 8, and so on).
So while upgrading will probably work, and there is little cause for concern, you pretty much have to test it in the lab. One possible approach to make this simpler, or at least smaller in scope, would be to consider focusing on one driver at a time, after the engine is upgraded, rather than dealing with the entire project at once. You can break it up into chunks that are easier to handle.
Future Versions
With the coming release of Novell Identity Manager 3.6 sometime this summer (whatever date they talked about at BrainShare), some of these rules may change as well. It looks like some features may require a new version of eDirectory (8.8.3) to work, and that may have implications beyond a simple upgrade. That's yet another reason to get the test environment up and running, so that when IDM 3.6 is released, you will be ready to evaluate the upgrade!
Support
Documentation
Learning Services
Partner Programs