Updating Profiles when changing LDAP directory
When you change to a new LDAP directory with the same users, you must synchronize the user data in Profiles with the user data in your new LDAP directory. You can use the sync_all_dns command, provided that certain criteria are met.
Before you begin
Note: Changing a user's identifier in Connections Content Manager (CCM)
results in the user record being viewed by the system as a completely new user, and access will be
lost, which can be a particular concern when administrative access is lost.
Procedure
To use the scripts provided with IBM® Connections
to synchronize the IDs and update Profiles, complete the following steps:
-
Open the profiles_tdi.properties file from the IBM® Tivoli® Directory Integrator solution directory on the system that hosts the
Profiles application in a text editor, and edit the following properties to match the values of the
corresponding properties in the LDAP system:
- source_ldap_url
- source_ldap_user_login
- source_ldap_user_password
- source_ldap_search_base
- source_ldap_search_filter
- source_ldap_use_ssl
-
Ensure that the guid property in the
map_dbrepos_from_source.properties file is set to the appropriate value for
your LDAP:
- IBM®
Tivoli® Directory Server:
guid=ibm-entryUuid
- IBM®
Lotus®
Domino®
Directory:
guid={function_map_from_dominoUNID}
- Microsoft™ Active
Directory:
guid={function_map_from_objectGUID}
- Sun Java™ System Directory
Server:
guid=nsuniqueid
- Novell (NetIQ) eDirectory:
guid={function_map_from_GUID}
- IBM®
Tivoli® Directory Server:
- Ensure that all other properties in the map_dbrepos_from_source.properties are set to the correct LDAP attribute name.
-
Identify a database attribute to synchronize with, either uid or
email, with the same value per member in the old LDAP deployment as in the new,
and then set the sync_updates_hash_field property in the
profiles_tdi.properties file to this attribute.
For example:
sync_updates_hash_field=uid
-
Complete only one of the following processes:
- If users are being moved to the new LDAP directory in stages while Connections is running, proceed to step 6 and complete all steps in this procedure.
- If all users are being moved at once when Connections is down, and Connections will remain down until the move is complete, skip to step 8. No further steps are needed.
-
Disable all Search Indexing tasks by using the wsadmin command
SearchService.disableAllTasks().
For more information, see Enabling and disabling scheduled tasks
-
Disable the User Life Cycle event propagation. Add the EnableUserDataPropagation property to
the profiles-config.xml file on the Deployment Manager, as follows:
- In the properties section of the configuration file, set the property name to com.ibm.lconn.profiles.config.EnableUserDataPropagation.
- Set the value of this property to false.
- Synchronize the nodes and restart all servers to clear the WALTZ cache.
-
Synchronize the data so that the values from the new LDAP deployment are updated in the
Profiles database by running the following script:
- IBM AIX® or Linux:
chmod +x sync_all_dns.sh ./sync_all_dns.sh
- Windows:
sync_all_dns.bat
- IBM AIX® or Linux:
-
Update the application member profile tables for the Activities, Blogs, Bookmarks, Communities,
Files, Forums, and News applications by using the wsadmin command
application_nameMemberService.syncBatchMemberExtIdsByEmail.
For more information, see Synchronizing user data by using administrative commands
- For the profiles component only, rebuild the search index. See Reindexing a component in an existing index
-
Re-enable the Search Indexing tasks by using the wsadmin command
SearchService.enableAllTasks().
For more information, see Enabling and disabling scheduled tasks
- Re-enable the User Life Cycle event propagation by undoing the change in step 7 and setting com.ibm.lconn.profiles.config.EnableUserDataPropagation to true.
-
If users are being moved to the new LDAP directory in stages while Connections is running, you
need to carry out steps 6 to 12 for each "batch" of LDAP users that are moved.
For example, if 100 LDAP users are being moved on January 1, you need to perform steps 6 to 12 thereafter. If the next batch of 100 LDAP users are moved on February 1, you need perform steps 6 to 12 again.