Synchronize the application member tables and corporate directory 

Before using the product, be sure to synchronize the member database tables for each IBM Connections application with the data in the user directory.

About this task

With the version 3 release, enhancements were introduced to 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. But, after migrating to 3, the application databases may not be fully in sync with each other or 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 IBM Connections applications and your corporate directory.

Procedure

1. Synchronize all of the application member table databases, except News and Profiles, with the corporate directory by running the syncAllMembersByExtId() administrative command for each application.

   1. Open a command prompt and then do the following:
      
      Change to the following directory of the system on which you installed the deployment manager:

      <WAS_HOME>\profiles\<DMGR>\bin

      Attention: You must run the following command to start the wsadmin client from this specific directory because the Python files for the product are stored here. If you try to start the client from a different directory, then the execfile() command that you subsequently call to initialize the administration environment for an IBM Connections component will not work properly.
      

   2. Enter the following command to start the wsadmin client:
      

      • AIX / Linux™:

        ./wsadmin.sh -lang jython -user <admin_user_id> -password 
         <admin_password> -port <SOAP_CONNECTOR_ADDRESS Port>

        
        

      • Microsoft™ Windows™:

        wsadmin -lang jython -user <admin_user_id> -password 
         <admin_password> -port <SOAP_CONNECTOR_ADDRESS Port>

        
        

      where:
      

      • <admin_user_id> is the user name of the WAS administrator.

      • <admin_password> is the password of the WAS administrator.

      • <SOAP_CONNECTOR_ADDRESS Port> is the SOAP port for the WAS. The default value of the SOAP port is 8879. If you are using the default port value, you do not need to specify this parameter. If you are not using the default and you do not know the port number, you can look up its value in the WAS Integrated Solution Console. To look up the SOAP port number, do one of the following:

        1. Open the WAS Integrated Solution Console for the deployment manager, and then select System Administration -> dmgr.

        2. In the Additional properties section expand Ports, and then look for the SOAP_CONNECTOR_ADDRESS port entry to find the port number.
           

      For example:
      

      • AIX / Linux:

        ./wsadmin.sh -lang jython -username jsmith -password myp@assword -port 8879

        
        

      • Microsoft Windows:

        wsadmin -lang jython -username jsmith -password myp@assword -port 8879

        
        

   3. Use following command to access the application configuration files:
      

      execfile("<application_py_file>")

      where <application_py_file> is one of the following:

      • Activities: activitiesAdmin.py

      • Blogs: blogsAdmin.py

      • Bookmarks: dogearAdmin.py

      • Communities: communitiesAdmin.py

      • Files: filesAdmin.py

      • Forums: forumsAdmin.py

      • Home Page: homepageAdmin.py

      • Wikis: wikisAdmin.py
        

      The News repository, Profiles, and Search do not need to be synchronized at this time.
      

   4. Enter the following command to synchronize user data:
      

      <application_name>MemberService.syncAllMembersByExtId({"updateOnEmailLoginMatch": "false"})

      where <application_name> is the name of the application. Specify one of the following:

      • Activities

      • Blogs

      • Dogear (Bookmarks)

      • Communities

      • Files

      • Forums

      • News
        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.
        

      • Wikis
        

      For example:

      DogearMemberService.syncAllMembersByExtId({"updateOnEmailLoginMatch":"false"})

      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 we specified this input parameter: "updateOnEmailLoginMatch": "false", the command does not update the application database automatically. Instead, it writes a log entry to the <application>UIcSyncCmd.log file so that an administrator can later perform a 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
      command.

      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]

      
      

2. Look through the log file for CLFWY0242W messages. Investigate the users who were reported to have external IDs that do not match the directory.

3. Do one of the following things:

   • If you determine that the user identified in the log file and the person in the corporate directory are the same person, then use the following command to update the user's information in the corporate directory:

     <application_name>MemberService.syncMemberByExtId(externalId)

     where externalId is the external ID specified for that user in the log. For example:

     CommunitiesMemberService.syncMemberByExtId("25374cc6-82a511df-80b6c81b-5330ca0eZZZ")

     
     

   • If you determine that the application user identified in the log file the and the person in the corporate directory are not the same person, then use one of the following commands to change the status associated with the user to inactive in the application's membership table:

     <application_name>MemberService.inactivateMemberbyEmail(email)

     where email is the email address of the user specified in the log. For example:

     ForumsMemberService.inactivateMemberByEmail("jsmith@example.com")

     <application_name>MemberService.inactivateMemberbyExtId(externalId)

     where externalId is the unique ID representing the user as specified in the log. For example:

     ForumsMemberService.inactivateMemberByExtId("25374cc6-82a511df-80b6c81b-5330ca0eZZZ")

     
     

4. Repeat the previous steps for each application to synchronize each application's member table against the corporate directory.

5. Make sure the Profiles member database table is synchronized with the corporate directory by looking at the USER_STATE_LAIDX table in the PEOPLEDB database. Make sure it is populated and that each member has a user status of 0, indicating that they are active. If this is not the case, run the following command to update the Profiles member database tables:
   

   ProfilesService.rebuildLookAsideIndexes()

   See Rebuilding the look-aside indexes for more details.
   

What to do next

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, periodically run the syncAllMembersByExtId({"updateOnEmailLoginMatch":"true"}) 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 syncAllMembersByExtId({"updateOnEmailLoginMatch":"true"}) command needs to be run in an interval shorter than the dormancy time for email and login reuse. See Manage users for more information.

Parent topic

Post-migration tasks

Related concepts
Manage users

Related tasks

Synchronize LDAP directory changes with Profiles
Rebuilding the look-aside indexes

   

 

});

+

Search Tips   |   Advanced Search