Novell IDM Migrating to Another Environment


We are using Novell's term to describe the promotion of Novell's IDM from one environment to another.

We do feel this an organizational situation that is dependent on the environment that is in place.

We personally would recommend and use Designer.

There are two primary situations that need to be addressed. The initial migration and then ongoing maintenance.

First, we maintain separate Projects within Designer, for each environment. (one for development, one for Production etc)

Certainly if there is more than one active developer you should ALL entities should be checked in to Subversion ("Version Control") and We recommend being religious about making sure that all changes are checked in with good check in log notes as to what changed and why.

For single developers or those without subversion, driver exports will work but you loose the check-in logs as to why changes were made.

Regardless of the Method#

The big issue is to identify all of the entries in the IDV that are required in the next environment. The drivers, of course, are easy, but then there are all the
  • driverSet GCVs
  • driver GCVs
  • Administrative entries used by the drivers - Equivalent to whom?
  • Notification entries used by the driver - Send an email to the IDM group?
  • Groups - Groups used for running the IDM environment. These may be used to determine who is authorized to do what in User App.
  • any other reference entries that you use in the drivers.
We find it easiest to maintain a list of these entries so we do not forget.

For the initial migration#

The Development project gets stepped forward in Subversion or is saved as we are working on a new driver. Once the driver is built and tested in development (and checked in), we export to XML configuration file, open the Production project, and import it. After any other needed changes are made to the driver config, the Production project is then checked in to Subversion, and the new driver deployed.

You can Migrate an entire DriverSet to a server within a different Tree for the initial move form Development to production. Section 17.2.2 Migrating a Driver Set To a Server in a Different Tree describes the process.

Read the instructions carefully and then double check every thing.

Ongoing maintenance#

As time goes on, then, there are always changes in driver configurations. You'll find those in my Development project, again saved or checked in and logged via Subversion. As those changes are completed and tested, they are copied over to the Production project, saved or checked in, and deployed.

IMHO, the Subversion logs are critical to figuring out what has changed if there are a bunch of changes made over a period of time. This is especially true if a single task requires making changes to a bunch of drivers.

To get changes for data between projects, I usually just open the policy, switch to XML source, and copy and paste the results in to an open text editor (ultraedit). Then switch projects, open the policy, switch to XML source, copy and paste in to it. Save the change, check it in, and deploy it. This is kinda cumbersome, but it works.

Other Items to Consider#

There are some other items that may need to be performed and maintained.

There are the driverSet GCV parameters. These values should be maintained on each server that is a member of each driverSet. You should save the source on each change to a dated XML file. You could put XML comments in the file for notes and version control. Check out Copy > Global Configuration Values

There are the driver GCV parameters. These values should be maintained on each server that is a member of each driverSet. Check out Copy > Settings

There are server specific information parameters. These values should be maintained on each server that is a member of each driverSet. Check out Copy > Server-Specific Settings

Staging in Designer#

We also like the new option in Designer having "staging" support which make this all easier.

CoolSoution on Staging#

There is a CoolSoution on Staging

Staging Best Practices Guide 3.6.1#

Staging Best Practices Guide 3.6.1