Before you begin
If your LDAP directory has a data size limitation, consider using the source_ldap_iterate_with_filter
property set to true when synchronizing changes from the LDAP directory back to the Profiles database. This property replaces the sync_all_dns_forLarge
scripts used in earlier releases.
About this task
Profiles is the repository for information about the people in your organization within IBM Connections. Typically, this data is retrieved from an LDAP or other corporate source which is the master copy. When data changes in the source, you will want these updates reflected in Profiles and throughout Connections. For example, if an employee moves department or leaves the company, or if your organization has taken over another division and you want to import new hires into the Profiles database, you update the LDAP directory and then synchronize the changes to the Profiles database.
For data sources, such as LDAP, the sync_all_dns
command can be used to take changes from the source and apply them to the Profiles database. If you want to keep the Profiles database in a close synchronized state with your LDAP directory, run this task nightly or at another frequency that suits you. During synchronization, the entries in the Profiles database are compared to the mapped values from the source. Updates are then applied to existing records, new records are added, and no longer found records are removed based on configuration settings. Because this task performs a complete comparison of the search scope with the Profiles database, be sure to allow sufficient time for it to run. As with the initial data population, the mapping values configured in map_dbrepos_from_source.properties
are compared to determine if an update is needed. If you configure extension attributes, that information is also compared and synchronized.
task creates temporary files that are used during the synchronization process so you need to allocate sufficient disk space. Specify the location of these files and whether to delete or retain them after synchronization using the sync_updates_working_directory=sync_updates
If you are troubleshooting a problem, you should change the sync_updates_clean_temp_files=false
setting to false
to retain the temporary files for diagnosis.
In addition to the temporary files, the following files in the TDI solution directory record the changes made during synchronization. When set to true
, the sync_updates_show_summary_only
property shows only the records that need to be changed, but does not make the changes. See Understanding how the sync_all_dns task works
for more information.
Like the other IBM
® Directory Integrator tasks, the sync_all_dns
command has its own log file that shares the same name as the task. You can check the log to see whether the task finishes successfully, and look for error information if necessary. You can also check the ibmdi.log
file. This file is a system log that records detailed information about the task when it is run. All the Tivoli
Directory Integrator log files are located in the TDI\logs
To synchronize LDAP directory changes with Profiles, perform the following steps.
- In addition to the general Tivoli Directory Integrator configuration properties, you can set the following properties in the profiles_tdi.properties file to control the synchronization process.
For more information about Tivoli
Directory Integrator configuration properties, see Tivoli Directory Integrator solution properties for Profiles
With the exception of sync_delete_or_inactivate
, these properties can only be used with the sync_all_dns task; they cannot be used with the process_tds_changes
|perform_deletion_for_sync||Controls whether the specified delete action is performed as part of the sync_all_dns task. Set this property to true when you want to delete or mark as inactive those users who are no longer in the Profiles database.|
The command checks the value of the property and acts using the following logic:
- If perform_deletion_for_sync=false then perform neither the delete nor the inactivate action.
- If perform_deletion_for_sync=true then look at the sync_delete_or_inactivate property.
- Based on the value of the sync_delete_or_inactivate property (either delete or inactivate), perform the specified action.
|source_ldap_iterate_with_filter||This configuration should be used if the size of the data to be retrieved from LDAP exceeds the search limit from the LDAP. For example, if your search parameters would return 250K records but your LDAP only allows 100K to be returned at a time, this parameter must be used. |
If the data is too large, an LDAP size limit exceeded error message is generated. To configure this mechanism, see the Populating a large user set topic.
When set to true, this specifies that the default iterations assembly line use the collect_ldap_dns_generator.js file to iterate over a set of LDAP search bases and filters. The cconfig setting replaces the sync_all_dns_forLarge and collect_dns_iterate scripts used in earlier releases.
The default value is false.
This parameter is not configurable when using the population wizard.
|sync_check_if_remove||Specifies the name of an optional custom delete hook assembly line. By default, the assembly line's name is set to sync_all_dns_check_if_remove. For more information about this property, see Customizing the logic used for the delete operation.|
The sync_updates_double_check property must also be set to use this functionality.
|sync_delete_or_inactivate||Controls what happens to a user record when the delete action is performed. The value must be either delete or inactivate and is case sensitive. By default, the property is set to inactivate so that users are not deleted. The inactive state is propagated to all the other IBM Connections applications.|
This property cannot be used with the sync_all_dns, process_tds_changes, and process_ad_changes commands.
For more information about this property, see Customizing the logic used for the delete operation.
For information about automating the delete user or inactivate user process, see Using supplied scripts to delete inactive users based on inactivity length.
|sync_updates_clean_temp_files||When set to true, this property deletes temporary files after the synchronization process is completed.|
|sync_updates_double_check||Uses the custom deletion-checking assembly line that is defined in the sync_check_if_remove property to perform a double check. The logic of the default double-check assembly line is to match on the distinguishedName mapping (usually $dn). If that match fails, the user is assumed to no longer be in the LDAP directory and is deleted.|
|sync_updates_hash_field||This property is used to match a record in the Profiles database with the corresponding record in the source. Choose a value that will not change, so that the match will remain intact between the source and the Profiles database. |
If the value in this field in the source changes, the match will be broken and unintended actions may take place, for example the existing database information for this person could be deleted if the corresponding match in the source is no longer accessible.
The supported values for this field are guid, uid, and email.
If the value of the hash field in the source has changed, you must set this property to a different value that has not changed. For example, if you have not changed the value of email, you can set it to email.
The default value is uid.
|sync_updates_hash_partitions||Number of partitions to divide the temporary files into. The default of 10 is sufficient in most cases. If the file size gets too large, this value can be increased.|
|sync_updates_show_summary_only||When set to true, this property shows only the records that need to be changed, but does not make the changes. |
|sync_updates_working_directory||The directory where the working files are stored. The path can be relative to the Tivoli Directory Integrator solution directory or an absolute path.|
- Optional: If you are storing data from multiple LDAP branches in the same database, and you want to keep these areas synchronized with the LDAP directory, then you also need to synchronize them separately or distinctly. To accomplish this task, you can set the following properties in the profiles_tdi.properties file:
These properties can only be used with the sync_all_dns task; they cannot be used with the process_tds_changes
|sync_source_url_enforce=true||Synchronizes only those records that have a matching URL. When set to true, it limits the scope of the set of data in the database and skips the records that do not match the source URL. When set to false, it deletes the records that do not match the source URL. The default value is false.|
|sync_source_url_override=true||Updates the source_url field if it doesn't match when the employee is being updated.|
|sync_store_source_url=true||Stores the source LDAP URL in the prof_source_url field in the database. The source LDAP URL is needed to determine the source of the data to correctly synchronize it. |
When storing the sync_store_source_url property in the Profiles database, the data format of prof_source_url in the Profiles database is as follows:
- Optional: When the sync_all_dns task is performed, it generates a lock file in the Tivoli Directory Integrator solution directory to prevent other customers from starting another sync_all_dns process in the same Tivoli Directory Integrator solution. The name of the lock file is sync_all_dns.lck. When the sync_all_dns process has finished successfully, the lock file is automatically deleted. However, if the process did not complete, the lock file won't be deleted. In this case, you can delete it yourself, or run the clearLock.sh or clearLock.bat command, located in the Tivoli Directory Integrator solution directory.
- Process changes using one of the following options:
This sample employee table illustrates results from a scenario in which you have pulled users A, B, and C from ldap_branch1 and users X, Y, and Z from ldap_branch2.
Table 1. Example employee table correlating initial employee UID and DN values
|uid ||distinguishedName (DN)|
To synchronize the ldap_branch2 users, set the following properties:
By setting these properties, you get updates for the ldap_branch2 users X, Y, and Z, but not for users A, B, and C. Updates are not provided for users A, B, and C because their PROF_SOURCE_URL does not match the Tivoli
Directory Integrator property source_ldap_url. When you set sync_source_url_enforce to true, the script skips users A, B, and C. When you set sync_source_url_enforce to false, users A, B, and C are deleted from the database.
To move the ldap_branch1 users to another branch of the LDAP directory , ldap_branch3, set the following properties:
This configuration retrieves the users from ldap_branch3, and finds users A, B, and C but not users X, Y, and Z. It matches users A, B, and C because the hash field is the same. The synchronization updates in the Profiles database are shown in the following table:
Table 2. Example employee table correlating changed employee UID and DN values
Parent topic: Managing user data using Tivoli Directory Integrator scripts
Understanding how the sync_all_dns process works
Synchronizing the application member tables and corporate directory
Switching to unique administrator IDs for system level communication
Synchronizing IBM Tivoli Directory Server and Microsoft Active Directory LDAP changes
Synchronizing source changes such as LDAP with Profiles
Customizing the logic used for the delete operation
Managing user data using Profiles administrative commands
Updating Profiles when changing LDAP directory
Tivoli Directory Integrator solution properties for Profiles
Batch files for processing Profiles data
Using supplied scripts to delete inactive users based on inactivity length