You can enable user data changes to be pushed automatically from the Profiles database to the databases of the other applications. As a result, if you install Profiles, keeping user data in sync will be easier. However, after migrating to the new release of IBM Connections, the application databases may not be fully in sync with each other or with the corporate user directory. To level set the data stores, run a set of wsadmin commands that synchronize the user data between the member tables for the
is the name of the application. Specify one of the following:
- Dogear (Bookmarks)
Note: The Home page, News repository, and Search applications share the same database, so running the synchronization command against News applies to all three areas.
For each user in the application's member table, this command first checks to see if the external ID of each member is present in the corporate directory. If it is, then the command gets the display name, email address, and login names from the corporate directory and updates the application database tables with the values from the directory, if they are different. This is considered to be an update operation and these updates are not logged to the output file.
If a match for the user's external ID in the application membership table is not found in the directory, then the code uses the email address and login names contained in the application database tables to continue to search for the user in the corporate directory. When a login name or email address match for this user is found in the corporate directory, because of the input parameter "updateOnEmailLoginMatch": "false"
, the command does not update the application database automatically. Instead, it writes a log entry to the application_nameULcSyncCmd.log
file so that an administrator can later perform synchronization after confirming that the update should be made. Here is an example of the log entry that would be created in this situation:
[2010-08-12 09:45:44] CLFWY0242W: The synchronize command found that active member Dan Retired [current
external id: 25374cc6-82a511df-80b6c81b-5330ca0eZZZ, application id 7980ff0f-7f41-4544-b1a7-9c4779aff287]
could not be matched via external id, but could be matched via login or email to external id
25374cc6-82a511df-80b6c81b-5330ca0e. The member was not updated since this action was disabled by the
If a match for the user's external ID is not found in the corporate directory, nor is a match found for the user's email address and login names, then the status of the user is changed to inactive in the application database. The code writes a log entry for this action as well. Here is an example of that log entry type:
[2010-08-12 09:45:42] CLFWY0261I: The synchronize command inactivated member Ann Retired [current
external id: 25374cc2-82a511df-80b6c81b-5330ca0e, application id 4fd0bb17-1495-4944-9e2a-b86971cab5c2]
The location of the generated log file is dependent on your server configuration; either single server or cluster. In a single server environment, the log is generated in the server1
folder. In a server cluster, the log is generated in the application_cluster
path, example .profiles/AppSrv01/logs/Cluster1_server1/
After performing this task, all of the component membership tables are consistent with the directory. If you have profiles installed, profiles will actively push user data changes including inactivations, or updates to the a person's email, login or external ID to the other components' membership tables. If you do not have Profiles installed, you must periodically run the
commands for each installed application. The frequency with which you need to run these commands depends on the size of your deployment and how your company's directory is managed. The key determination is the time interval during which old emails and logins for inactive users are reserved before being assigned to new users. The
command needs to be run in an interval shorter than the dormancy time for email and login reuse. See