A Forum reader recently asked:

“I have one server running IDM 3.0 in a production tree with a single AD driver. The server is running Netware 6.5 and I want to upgrade it to Linux.”

And here are some suggestions from Lothar Haegar and Aaron Burgemeister …



It would be *much* easier to first add a new Linux server (with a new name) to the tree, add replicas, install IDM, add the new server to the driverset, remove the old server from the driverset, and finally delete the old server.

You would not lose all your associations, you would have no IDM downtime, and you would not miss any events. Also, see

Here are the steps to follow:

1. Add the new server to the driverset and keep it disabled.

2. Copy the server parameters from old -> new (there’s a new menu item once you have more than two servers to a driverset).

3. Set passwords.

4. Enable and start the new driver.

5. Stop and disable the old driver.

As long as a driver is disabled, it will not receive events. So, all you might see is duplicate event processing for the short period of time when both drivers are enabled (most events don’t do any harm when being processed twice, anyway). If you want to further minimize that time slot, start/stop/enable/disable the drivers using dxcmd, which does not have iManager’s overhead (type “dxcmd” at the linux prompt). With dxcmd you can also view and clear the old drivers event cache after it’s been disabled, so any events cached between stopping and disabling it will not be processed again, should you ever need to restart to that driver.


First, if you MUST use the exact same hardware then you’re close. In doing so, though, you will also need to reimport your configuration over the top of your driver, because some attributes are server-specific. When you remove the server from the tree, those will be lost (they’re still in the export, except passwords).

Reset your driver passwords once the import is complete. This is simply importing an existing
configuration into an existing driver. You will always have just the one driver object in the tree with which your DirXML Associations have a reference. Because your driver is never deleted your associations remain intact.

With this same concept (references between objects) in mind, your DriverSet is not going to have any associated servers once you remove your old server from the tree. This is not a problem, really, but just be aware that the value in the DriverSet will be gone (*poof*) when you clean the tree (which you should definitely do).

Adding the driver’s association to the new server (it is brand new in all respects, regardless of the name) will put the value back in. You will then need to do the import-over-the-top as mentioned above, followed by password-sets.

Now, that should get you where you need to be. All that said, though, if you have a second server that can work in production you could minimize downtime (lost events) to a couple seconds which is probably negligible in the middle of the night.

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.

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

No Comments
Jan 24, 2007
9:57 am
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 IT Security Knowledge Depot LDAP Monitoring Open Enterprise Server Passwords Reporting Secure Access Supported Troubleshooting Workflow