Migrating masses of users to IDM

Q. TS wrote: We have over 10k users in this department. When we migrate to IDM, must we migrate EVERY person at the same time, or can we do it in smaller chunks (i.e. region by region)?

A. You can definitely migrate your user information in smaller chunks. And bear in mind that migration may not be needed for all components. As mentioned in the upgrade and migration doc http://www.novell.com/documentation/idm401/idm_upgrade/data/bpgkkrw.html, the IDM engine and other components can be upgraded.

Only the Roles Based Provisioning Module (RBPM) needs to be migrated. In the case of RBPM migration, depending on the partitions in the tree and the number of servers, each server can be migrated one at a time. Check the documentation for more details: at http://www.novell.com/documentation/idm401/idm_upgrade/data/bu7mrjt.html


How To-Best Practice
Comment List
  • Depending on the connected systems, you will need to decide how to proceed. Each user in the system will require an appropriate DirXML-Association, one per driver.

    Some are easy to 'make' by hand, once you understand what the DirXML-Association value ought to be, check out this article to get a feel for what the various values ought to be:

    For example, at a client with 1.5 million objects, we added a new driver for 600,000 of them. Rather than let the engine try to process 600K, we actually scripted retrieving the GUIDs processing them, and then using an LDIF to write the values to the Identity Vault.

    If you 'only' have 10,000, it is not so bad. You should realize if you migrate a user in one system, odds are good you will cause enough of an event to cause all the other drivers to fire. In which case you might want to think about it carefully in terms of overall processing.

    When you Migrate from Identity Vault, you select a list of users, and iManager basically writes a DirXML-Association to the object with a state of 4 (0 is ignore, 1 is associated, 4 is migrate, 3, 5, 6 and the rest of the way to 2^32 are not really used) which causes an event that generates a event for the object.

    If you migrate FROM application in iManager, the engine submits a query (query-ex if the driver supports it, and thus pages to the ECV controlled default) and the doc that is returned is the list of objects to .

    You can use DXCMD and there is a option to Submit a Command, and you provide the file name to the XDS doc with the query you need and it will process it as if you did it in iManager. So you can have a little better control than iManager allows, but it has to be valid XDS query of course.