IBM Connections 4 Part 2: Administering Common Areas, Activities, Blogs, Bookmarks, Communities, Files

IBM Connections 4 Documentation Part 2: Administering Common Areas, Activities, Blogs, Bookmarks, Communities, Files

Administering common areas

Administer the common areas of IBM® Connections.

Administrator checklist

Consider tasks you might want to complete after installing IBM Connections and before users start using it.

Database and file system backup and maintenance

Recommended tasks to schedule

  1. No tasks can run while the search index is being built. You do not need to take action to create the initial search index; it is scheduled automatically as part of the installation program; just wait for one of the default indexing tasks to run. If you want to recreate the search index, you must stop all scheduled tasks first, and then you can recreate the index using one of these procedures:
    Recreating the Search index
    Users cannot use search while you recreate the index using this method.
    Creating a background index
    Users can continue to use search while you recreate the index using this method.
  2. Schedule the following tasks:
    • Schedule PowerCube refreshes for the Metrics application.
    • For user directory maintenance:
      • To keep the Profiles data in sync with the source from which you populated it, schedule the sync_all_dns script to run nightly. See Synchronizing source changes such as LDAP with Profiles for more details.
        Note: If you made any customizations to the population process, schedule your custom synchronization script to run nightly instead.
      • If, when populating the database, you chose to identify managers, run the mark_managers program after synchronizing the information to keep manager/managed relationship information up-to-date. This information is reflected in the report-to chain that is displayed in the user interface. See Configuring the Manager designation in user profiles for more details.

Managing content

Consider enabling the following features:
  • Moderation. You can configure the product so that content added to Blogs, Forums, or Files in Communities must be reviewed by a moderator before it can be made public. Or you can allow people to add content freely, but enable others to flag content as inappropriate. See Moderation overview for more details.
  • Create a global administrator if you want to enable one or more administrators to perform advanced tasks in all of the applications in the product.
  • Designate who can view and interact with server-level metrics (by default, community owners can view metrics only for their communities and general users cannot view metrics at all).

Integrating with other products

.Consider integrating the following features:

Security considerations

Consider configuring the following features:
  • IBM Connections uses single sign-on (SSO) to secure the transfer of user ID and password information that is used to authenticate with the system. With SSO, users can switch to different applications without needing to authenticate again Configuring single sign-on.
  • By default, the IBM® Connections AJAX proxy is configured to allow cookies, headers or mime types, and all HTTP actions to be exchanged among the IBM Connections applications. If you want to change the traffic that is allowed from non-IBM Connections services, you must explicitly configure it Configuring the AJAX proxy.

Customizing the product

Consider adding the following customizations:
  • Start IBM Connections and review the product user interface to determine which areas of the product you want to Customizing the user interface.
  • You can also use an OAuth 2.0 consumer proxy to allow the Homepage component to surface gadgets in an OpenSocial container that can interact with an OAuth 2.0 protected service Configuring OAuth for custom gadgets.

Testing the environment for production readiness

  • If during product installation you specified directory paths to application data and resources that were different from the default paths, you must change your environment variables to reflect those changes. The application configuration files that define the behavior of the applications reference the directory paths using these environment variables.
  • Make sure references to administrator IDs and passwords are correct.
  • If your IBM HTTP Server is hosting multiple web servers, you might want to change the session cookie name of one of them to prevent the cookie from being lost when the user is redirected from one product to another.

Administration tools

Use the wsadmin utility to edit configuration properties or run administrative commands.

The wsadmin utility is a tool provided with WebSphere Application Server that you can use to manage applications hosted by the WebSphere Application Server, including IBM Connections.

The wsadmin tool runs IBM Connections script-based commands that you enter into a wsadmin command session. Behind the scenes, these scripts are based on the Jython scripting language, and they invoke WebSphere Application Server and IBM Connections commands that do the actual work. These scripts can both change XML-based file values that control an application's configuration and run IBM Connections-supplied MBean commands, which are grouped into services that perform related tasks, such as managing application membership.

You can change the behavior of IBM Connections by using the wsadmin client to perform one of the following actions:
Edit configuration properties
These properties control configurable aspects of the applications and are stored in XML-formatted configuration files. When you change these types of properties, you must use scripts that check out the configuration file, make the change, and then check the configuration file back in. After checking in your changes, you must restart the servers for the changes to take effect. In a network deployment, you must also synchronize the nodes to propagate the changes across a cluster.
Run administrative commands
Run administrative commands to invoke MBean commands associated with the product applications. MBeans control the applications that run on the server. When you run an administrative command, you must start the Jython script interpreter, but you do not have to check out any configuration files nor restart the server. Your changes take effect immediately.

For more detailed information about the wsadmin tool, go to the IBM WebSphere Application Server information center at the following web site: http://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/topic/com.ibm.websphere.base.doc/info/aes/ae/txml_scriptingep.html

Starting the wsadmin client

Use the wsadmin client to make configuration changes to common IBM Connections settings and individual application settings.

Before you begin
The wsadmin client is a scripting environment that gets installed with IBM WebSphere Application Server. You can use Jython language scripts, that are installed with IBM Connections, to access and change properties that govern the IBM Connections configuration. You can configure common properties that apply across all applications, and you can configure properties that apply only to an individual application.
Procedure
Start the wsadmin client by completing the following steps:
  1. Open a command prompt, and then change to the following directory of the system on which you installed the deployment manager:
    app_server_root\profiles\dm_profile_root\bin
    where app_server_root is the WebSphere Application Server installation directory and dm_profile_root is the Deployment Manager profile directory, typically dmgr01. For example, on Windows:
    C:\Program Files\IBM\WebSphere\AppServer\profiles\Dmgr01\bin
    Attention: You must run the following command to start the wsadmin client from this specific directory because the Jython 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 does not work correctly.
  2. Enter the following command to start the wsadmin client:
    • AIX® or 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 a person in the Administrator role on the IBM WebSphere Application Server.
    • admin_password is the password of the WebSphere Application Server administrator.
    • SOAP_CONNECTOR_ADDRESS Port is the SOAP port for the WebSphere Application Server deployment manager server. 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 WebSphere Application Server Integrated Solution Console. To look up the SOAP port number, perform the following steps:
      1. Open the WebSphere Application Server Integrated Solution Console for the deployment manager, and then select System Administration > Deployment Manager.
      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 or Linux:
      ./wsadmin.sh -lang jython -username primaryAdmin -password p@assword -port 8879
    • Microsoft Windows:
      wsadmin -lang jython -username primaryAdmin -password p@assword -port 8879
What to do next
See the common IBM Connections section and individual application sections for information about the properties that you can change.

Editing configuration files

You can edit configuration files in two ways: by editing configuration settings in the wsadmin client, or by editing the configuration XML files directly. In both cases, you must first check out the configuration files and later check them back in using the wsadmin client.

Procedure
  1. Start the wsadmin client by completing the following steps:
    1. Open a command prompt, and then change to the following directory of the system on which you installed the deployment manager:
      app_server_root\profiles\dm_profile_root\bin
      where app_server_root is the WebSphere Application Server installation directory and dm_profile_root is the Deployment Manager profile directory, typically dmgr01. For example, on Windows:
      C:\Program Files\IBM\WebSphere\AppServer\profiles\Dmgr01\bin
      Attention: You must run the following command to start the wsadmin client from this specific directory because the Jython 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 does not work correctly.
    2. Enter the following command to start the wsadmin client:
      • AIX or 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 a person in the Administrator role on the IBM WebSphere Application Server.
      • admin_password is the password of the WebSphere Application Server administrator.
      • SOAP_CONNECTOR_ADDRESS Port is the SOAP port for the WebSphere Application Server deployment manager server. 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 WebSphere Application Server Integrated Solution Console. To look up the SOAP port number, perform the following steps:
        1. Open the WebSphere Application Server Integrated Solution Console for the deployment manager, and then select System Administration > Deployment Manager.
        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 or Linux:
        ./wsadmin.sh -lang jython -username primaryAdmin -password p@assword -port 8879
      • Microsoft Windows:
        wsadmin -lang jython -username primaryAdmin -password p@assword -port 8879
  2. Use the following command to access the application configuration files:
    execfile("application_py_file")
    where application_py_file is one of the following:
    • IBM Connections-wide: connectionsConfig.py
    • Activities: activitiesAdmin.py
    • Blogs: blogsAdmin.py
    • Bookmarks: dogearAdmin.py
    • Communities: communitiesAdmin.py
    • Files: filesAdmin.py
    • Forums: forumsAdmin.py
    • Home Page: homepageAdmin.py
    • News: newsAdmin.py
    • Profiles: profilesAdmin.py
    • Search: searchAdmin.py
    • Wikis: wikisAdmin.py
    • Metrics: metricsAdmin.py

    If prompted to specify a service to connect to, type 1 to pick the first node in the list. Most commands can run on any node. If the command writes or reads information to or from a file using a local file path, you must pick the node where the file is stored. This information is not used by the wsadmin client when you are making configuration changes.

  3. Check out the configuration file for the application using the following command:
    service_name.checkOutConfig("working_directory",
     "cell_name")
    where:
    • service_name is one of the following:
      • IBM Connections-wide: LCConfigService
      • Activities: ActivitiesConfigService
      • Blogs: The configuration settings for the Blogs application are not made in a configuration file, so no files need to be checked out, updated, and checked back in for Blogs. Unlike the other applications, when you edit Blogs configuration properties, the changes are written directly to the Blogs database tables.
      • Bookmarks: DogearCellConfig
      • Communities: CommunitiesConfigService
      • Files: FilesConfigService
      • Forums: ForumsConfigService
      • Home Page: HomepageCellConfig
      • News: NewsCellConfig
      • Profiles: ProfilesConfigService
      • Search: SearchCellConfig
      • Wikis: WikisConfigService
      • Metrics: MetricsConfigService
    • working_directory is the temporary working directory to which the configuration XML and XSD files are copied by the checkOutConfig command. The XML file contains the configuration settings and the corresponding XSD files is used to validate the XML file. The files are kept in this working directory while you make changes to them using the updateConfig command. When you run the checkInConfig command, the updated configuration file is copied from the temporary directory to where these files are located and overwrites the existing XML file. When you specify a path to the working directory on a system running Microsoft Windows, use a forward slash for the directory. For example: "C:/temp".
      Note: AIX and Linux only: The directory must grant write permissions or the command will not run successfully.
    • cell_name is the name of the WebSphere Application Server cell hosting the IBM Connections application. This argument is case-sensitive, so type it with care. If you do not know the cell name, type the following command while in the wsadmin command processor:
      print AdminControl.getCell()
      Note: This input parameter is case-dependent.
    For example:
    • Common IBM Connections properties:
      LCConfigService.checkOutConfig("C:/temp","foo01Cell01")
    • The events-config.xml file:
      LCConfigService.checkOutEventsConfig("/temp","foo01Cell01")
      This command is part of the LCConfig service and only checks out the events-config.xml file. See the topic Editing events-config.xml.
    • Activities:
      ActivitiesConfigService.checkOutConfig("/temp","foo01Cell01")
    • Bookmarks:
      DogearCellConfig.checkOutConfig("C:/temp","foo01Cell01")
    • Communities:
      CommunitiesConfigService.checkOutConfig("/temp","foo01Cell01")
    • Files:
      FilesConfigService.checkOutConfig("C:/temp","foo01Cell01")
    • Forums:
      ForumsConfigService.checkOutConfig("C:/temp","foo01Cell01")
    • Home Page:
      HomepageCellConfig.checkOutConfig("/temp","foo01Cell01")
    • News repository:
      NewsCellConfig.checkOutConfig("/temp","foo01Cell01")
    • Profiles:
      ProfilesConfigService.checkOutConfig("C:/temp","foo01Cell01")
    • Search:
      SearchCellConfig.checkOutConfig("/temp","foo01Cell01")
    • Wikis:
      WikisConfigService.checkOutConfig("C:/temp","foo01Cell01")
    • Metrics
      MetricsConfigService.checkOutConfig("/temp","foo01Cell01") 
  4. Optional: If you want to see what the current values of the configuration properties are, use the following command to retrieve a list of them:
    service_name.showConfig()
    where service_name is one of the service names defined in step 4.
  5. Edit the values of the configuration properties that you want to change. Some properties must be edited using the wsadmin client; others can only be edited by editing the configuration XML file directly.
    For example:
    service_name.updateConfig("property_name","new_value")
    See the documentation for the individual application sections to see a list of the configuration properties you can edit for that application.
  6. Update the value of the version stamp configuration property to force users' browsers to pick up this change. See Required post-customization step for more details.
  7. After making edits, check the configuration files back in using the following command:
    service_name.checkInConfig()
    where service_name is one of the service names defined in step 4. You do not need to perform this step for the Blogs application. To check in the events-config.xml file the command is LCConfigService.checkInEventsConfig().
    Note: You must run the checkin during the same wsadmin session in which you ran the checkout command.
  8. After making updates, type the following command to deploy the changes:
    synchAllNodes()
  9. To exit the wsadmin client, type exit at the prompt.
  10. Stop and restart the servers hosting the edited IBM Connections applications.
    Note: If you changed any Blogs configuration settings, the changes were written directly into the Blogs database tables. Therefore, you do not need to stop and restart the server hosting the Blogs application for the changes to take effect.
IBM Connections configuration property values

Find out what configuration properties you can edit for each application.

About this task
To figure out which properties are editable, do one of the following:
  • Refer to the topic which lists all of the configuration properties for an application.
  • Find the topic that describes the task that you want to complete. Many of the tasks you can perform involve editing a configuration property; the rest are completed using administrative commands.
Follow the related reference links to find a list of the configuration properties for each application.
IBM Connections configuration files

Configuration files are XML-formatted files that store configuration information for IBM Connections.

The following table lists the configuration files that are provided with IBM Connections and describes what they do.
Table 1. IBM Connections configuration files
Configuration file Description
calendar-config.xml Stores properties that control the behavior of the Events widgets.
communities-config.xml Stores properties that control the behavior of the Communities application.
communities-policy.xml Defines the permission levels of different roles in the Communities application. For example, it might specify that owners in a public community can modify the community description or members in a private community can add bookmarks.
contentreview-config.xml Defines settings for content moderation in the Blogs, Files, and Forums applications.
directory.services.xml Stores properties that control the behavior of common directory services.
dogear-config-cell.xml Stores properties that affect Bookmarks at the cell level, such as differentiating between intranet and internet sites.
events-config.xml Stores properties that control how events are collected and managed.
files-config.xml Stores properties that control the behavior of the Files application.
forum-config.xml Stores properties that control the behavior of the Forums application.
forum-policy.xml Defines the permission levels of different roles in the Forums application.
gettingstarted-config.xml Stores properties that define the content of the Getting Started tab in the home page.
library-config.xml Stores properties that control the behavior of library widgets in the Communities application.
LotusConnections-config.xml Stores properties that control common IBM Connections applications, such as the navigation bar links.
media-gallery-config.xml Stores properties that control the behavior of the Media Gallery widget in the Communities application.
metrics-config.xml Stores properties that control the behavior of the Metrics application.
mime-files-config.xml Stores Multipurpose Internet Mail Extensions (MIME) type assignments for file extensions and icons in the Files application.
mime-wikis-config.xml Stores Multipurpose Internet Mail Extensions (MIME) type assignments for file extensions and icons in the Wikis application.
mobile-config.xml Stores properties that control the behavior of the IBM Connections Mobile service.
news-config.xml Stores properties that control how information is cleaned up and synchronized in the news repository.
notification-config.xml Stores properties that control email notifications across all of the applications.
oa-config.xml Stores properties that affect Activities, such as managing uploaded files, defining which statistics to collect, and purging the trash.
opensocial-config.xml Defines properties that affect the behavior of the OpenSocial service, and is used for the integration of OpenSocial gadgets.
profiles-config.xml Stores properties that control the behavior of the Profiles application.
profiles-policy.xml Stores properties that can enable or disable profiles on the basis of profile type and properties that control the behavior of status updates in Profiles.
proxy-config.tpl Defines proxy server redirects for specific URL patterns. Using redirects, you can allow access to web sites that you deem to be safe or block access to web sites that you deem to be dangerous. This configuration file also defines rewrite rules that specify aliases for web addresses.
search-config.xml Stores properties that control the behavior of the Search application.
uiextensions-config.xml Stores properties that manage customization in the business card, Communities, the home page, and Profiles.
widgets-config.xml Stores properties that control the behavior of the widgets that can be added to the Communities and Profiles applications.
wikis-config.xml Stores properties that control the behavior of the Wikis application.
XRDS.xml Standard definition document in XML format for the discovery of metadata about a resource.

Editing events-config.xml

You can edit the events-config.xml file by checking it out with a command, and then editing it directly.

About this task

The events configuration file stores properties that control how events are collected and managed. You can edit configuration properties for deploying event handlers and setting some media gallery configuration values. See the topics Deploying an event handler and Media gallery events-config.xml properties for more information.

Procedure
  1. Start the wsadmin client.
  2. Use the following command to access the IBM Connections configuration files:
    execfile("connectionsConfig.py")
  3. Check out the events-config.xml configuration file using the following command:
    LCConfigService.checkOutEventsConfig("<temp_directory>", "<cell_name>")
    where:
    • working_directory is the temporary working directory to which the configuration XML and XSD files are copied by the checkOutEventsConfig command. The XML file contains the configuration settings and the corresponding XSD files is used to validate the XML file. When you specify a path to the working directory on a system running Microsoft Windows, use a forward slash for the directory. For example: "C:/temp".
      Note: AIX and Linux only: The directory must grant write permissions or the command will not run successfully.
    • cell_name is the name of the WebSphere Application Server cell hosting the IBM Connections application. This argument is case-sensitive, so type it with care. If you do not know the cell name, type the following command while in the wsadmin command processor:
      print AdminControl.getCell()
      Note: This input parameter is case-dependent.
    For example:
    LCConfigService.checkOutEventsConfig("C:/temp","foo01Cell01")
  4. Navigate to the working directory you specified in Step 3, open the events-config.xml file, and edit the values of the configuration properties that you want to change.
  5. After making edits, check the configuration files back in using the following command:
    LCConfigService.checkInEventsConfig("<temp_directory>", "<cell_name>")
    Note: You must run the checkin during the same wsadmin session in which you ran the checkout command.
  6. After making updates, type the following command to deploy the changes:
    synchAllNodes()
  7. To exit the wsadmin client, type exit at the prompt.
  8. Stop and restart the servers hosting the edited IBM Connections applications.

Changing common configuration property values

Configuration settings control how and when various common operations take place. You can edit the settings to change how IBM Connections behaves.

About this task
Use the connectionsConfig script in the WebSphere Application Server wsadmin client to interact with the IBM Connections configuration file, which is named LotusConnections-config.xml. Changes to common configuration settings require node synchronization and a restart of all the application servers.

Some properties in the LotusConnections-config.xml file cannot be edited using this procedure. They cannot be edited using updateConfig command nor displayed using the showConfig command. Instead, you must check out the configuration file using the checkOutConfig command, and then edit the property values by opening the checked out property file from the temporary directory using a text editor. After editing the property file, be sure to save the file, and then open it in a web browser to make sure you did not introduce any errors. XML files that are well formed display in a web browser; if there are errors, the web browser reports that an error was encountered. After fixing any errors, you must check the file back in using the checkInConfig command.

How do you determine which properties you can edit using the wsadmin commands and which you cannot? Use the showConfig command. This command returns a listing of all the properties that can be edited using the updateConfig command and their current values.

To change common configuration settings using wsadmin commands, complete the following steps:

Procedure
  1. Start the wsadmin client by completing the following steps:
    1. Open a command prompt, and then change to the following directory of the system on which you installed the deployment manager:
      app_server_root\profiles\dm_profile_root\bin
      where app_server_root is the WebSphere Application Server installation directory and dm_profile_root is the Deployment Manager profile directory, typically dmgr01. For example, on Windows:
      C:\Program Files\IBM\WebSphere\AppServer\profiles\Dmgr01\bin
      Attention: You must run the following command to start the wsadmin client from this specific directory because the Jython 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 does not work correctly.
    2. Enter the following command to start the wsadmin client:
      • AIX or 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 a person in the Administrator role on the IBM WebSphere Application Server.
      • admin_password is the password of the WebSphere Application Server administrator.
      • SOAP_CONNECTOR_ADDRESS Port is the SOAP port for the WebSphere Application Server deployment manager server. 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 WebSphere Application Server Integrated Solution Console. To look up the SOAP port number, perform the following steps:
        1. Open the WebSphere Application Server Integrated Solution Console for the deployment manager, and then select System Administration > Deployment Manager.
        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 or Linux:
        ./wsadmin.sh -lang jython -username primaryAdmin -password p@assword -port 8879
      • Microsoft Windows:
        wsadmin -lang jython -username primaryAdmin -password p@assword -port 8879
  2. Use the wsadmin client to access and check out the IBM Connections configuration files:
    1. Enter the following command to access the IBM Connections configuration file: execfile("connectionsConfig.py")

      If prompted to specify a service to connect to, type 1 to pick the first node in the list. Most commands can run on any node. If the command writes or reads information to or from a file using a local file path, you must pick the node where the file is stored. This information is not used by the wsadmin client when you are making configuration changes.

    2. Enter the following command to check out the IBM Connections configuration files:

      LCConfigService.checkOutConfig("working_directory","cell_name")

      where:
      • working_directory is the temporary working directory to which the configuration XML and XSD files are copied and are stored while you make changes to them. Use forward slashes to separate directories in the file path, even if you are using the Microsoft Windows operating system.

        AIX and Linux only: The directory must grant write permissions or the command does not run successfully.

      • cell_name is the name of the WebSphere Application Server cell hosting the IBM Connections application. This argument is case-sensitive, so type it with care. If you do not know the cell name, type the following command while in the wsadmin command processor:print AdminControl.getCell()
      For example:
      • AIX or Linux:LCConfigService.checkOutConfig("/opt/temp","foo01Cell01")
      • Microsoft Windows:LCConfigService.checkOutConfig("c:/temp","foo01Cell01")
  3. Optional: If you want to find out the current value of a property, you can list the current configuration settings and values using the following command: LCConfigService.showConfig()
  4. Enter the following command to change a common configuration setting: LCConfigService.updateConfig("property","value") where property is one of the editable IBM Connections configuration properties and value is the new value with which you want to set that property. See Common configuration properties for a complete list of editable properties. For example:
    LCConfigService.updateConfig("versionStamp","")
  5. Optional: Repeat the previous step once for each property setting that you want to change.
What to do next

Check the configuration files back in during the same wsadmin session in which you checked them out. For more information, see the Applying common configuration property changes topic.

Common configuration properties

The common configuration properties for IBM Connections are stored in the LotusConnections-config.xml file. The properties are represented as XML elements.

You can change the values of the properties in the following ways:
  • Using the updateConfig command from the wsadmin client. This is the preferred method for editing values of properties in the configuration file. When you use the wsadmin client to edit a property value, validation is performed on your change before the change is applied, which helps to prevent errors.
    Note: Not all properties can be edited this way.
  • Editing the XML elements in the file directly using a text editor. This method is potentially more error prone. If you choose to edit the XML elements directly, you still must use the checkOutConfig wsadmin command to check out the configuration files and the checkInConfig wsadmin command to check the LotusConnections-config.xml file back in after you have made your updates. When you check the file in, validation runs on the edited file and you are informed if you introduced any errors. Fix any errors, save the file, and try to check it in again.
While it is better to use the updateConfig command from the wsadmin client to edit the properties in the configuration file, some of the properties cannot be edited this way. The values of those properties must be changed by editing the XML file directly.

How do you determine which properties you can edit using the wsadmin commands and which you cannot? You can use the showConfig wsadmin command. This command returns a listing of all the properties that can be edited using the wsadmin client.

This topic outlines those properties that you can edit using the updateConfig command from the wsadmin client and those that you cannot.

Properties that you can edit using the wsadmin client
The following list defines the configuration properties that can be edited using the updateConfig command from the wsadmin client.
activities.ejb.cluster

Name of the cluster on which the application is running in a network deployment. This property is used for JNDI lookups in cluster environments to ensure failover and load balancing on lookups.

activities.ejb.port

WebSphere Application Server port number of the application server instance running on the first node of the cluster that hosts this application. This information is used during JNDI lookups. This value is usually 2809, but may be different if port 2809 is already in use.

activities.ejb.server

Fully qualified domain name of the application server instance running on the first node of the cluster that hosts this application. This information is used during JNDI lookups.

activities.enabled
Specifies whether the ability to access the Activities application over HTTP is enabled. The property accepts the following values: true or false.
activities.href
Web address from which to access the Activities application over HTTP. Specify the protocol (HTTP), server name, and optionally the port number.
Note: Provide a fully-qualified domain name. This parameter is case-sensitive.
activities.href.prefix
Context root from which to access the application. For example: /activities.
activities.interService.href
Web address from which other IBM Connections applications access this application. Specify the protocol and server name.
Note: Provide a fully-qualified domain name. This parameter is case-sensitive.
activities.pcs.name.js.eval
Defines the label of the link that you click to access the Activities application from the business card.
activities.pcs.url.pattern
Web pattern of the link to the Activities application from the business card.
activities.ssl.enabled
Specifies whether the ability to access the Activities application over secure HTTP is enabled. The property accepts the following values: true or false. It is set to true by default, and should only be changed to false if you are disabling ssl in your environment. Disabling ssl is a complex, multi-step process that you should consult with IBM Support before attempting.
activities.ssl.href
Web address from which to access the Activities application over secure HTTP (HTTPS). Specify the protocol (HTTPS), server name, and optionally the port number.
Note: Provide a fully-qualified domain name. This parameter is case-sensitive.
allowedContent.contentType.enabled
Specifies whether the active content filter removes flash animation files from entries in the Blogs and Wikis applications. Accepts the values: true or false. However, editing this value has no effect. See Configuring the active content filter for Blogs and Wikis for information about how to prevent flash from being added to entries in those applications.
blogs.ejb.cluster

Name of the cluster on which the application is running in a network deployment. This property is used for JNDI lookups in cluster environments to ensure failover and load balancing on lookups.

blogs.ejb.port

WebSphere Application Server port number of the application server instance running on the first node of the cluster that hosts this application. This information is used during JNDI lookups. This value is usually 2809, but may be different if port 2809 is already in use.

blogs.ejb.server

Fully qualified domain name of the application server instance running on the first node of the cluster that hosts this application. This information is used during JNDI lookups.

blogs.enabled
Specifies whether the ability to access the Blogs application over HTTP is enabled. The property accepts the following values: true or false.
blogs.href
Web address from which to access the Blogs application over HTTP. Specify the protocol (HTTP), server name, and optionally the port number.
Note: Provide a fully-qualified domain name. This parameter is case-sensitive.
blogs.href.prefix
Context root from which to access the application. For example: /blogs.
blogs.interService.href
Web address from which other IBM Connections applications access this application. Specify the protocol and server name.
Note: Provide a fully-qualified domain name. This parameter is case-sensitive.
blogs.pcs.name.js.eval
Defines the label of the link that you click to access the Blogs application from the business card.
blogs.pcs.url.pattern
Web pattern of the link to the Blogs application from the business card.
blogs.ssl.enabled
Specifies whether the ability to access the Blogs application over secure HTTP is enabled. The property accepts the following values: true or false. It is set to true by default, and should only be changed to false if you are disabling ssl in your environment. Disabling ssl is a complex, multi-step process that you should consult with IBM Support before attempting.
blogs.ssl.href
Web address from which to access the Blogs application over secure HTTP (HTTPS). Specify the protocol (HTTPS), server name, and optionally the port number.
Note: Provide a fully-qualified domain name. This parameter is case-sensitive.
cognos.ejb.cluster
Name of the cluster on which the application is running in a network deployment. This property is used for JNDI lookups in cluster environments to ensure failover and load balancing on lookups.
cognos.ejb.port
WebSphere Application Server port number of the application server instance running on the first node of the cluster that hosts this application. This information is used during JNDI lookups. This value is usually 2809, but may be different if port 2809 is already in use.
cognos.ejb.server
Fully qualified domain name of the application server instance running on the first node of the cluster that hosts this application. This information is used during JNDI lookups.
cognos.enabled
Specifies whether the ability to access the Cognos application over HTTP is enabled. The property accepts the following values: true or false.
cognos.href
Web address from which to access the Cognos application over HTTP. Specify the protocol (HTTP), server name, and optionally the port number.
Note: Provide a fully-qualified domain name. This parameter is case-sensitive.
cognos.href.prefix
Context root from which to access the application. For example: /cognos.
cognos.interService.href
Web address from which other IBM Connections applications access this application. Specify the protocol and server name.
Note: Provide a fully-qualified domain name. This parameter is case-sensitive.
cognos.ssl.enabled
Specifies whether the ability to access the Cognos application over secure HTTP is enabled. The property accepts the following values: true or false. It is set to true by default, and should only be changed to false if you are disabling SSL in your environment. Disabling SSL is a complex, multi-step process and you should consult with IBM Support before attempting to do so.
cognos.ssl.href
Web address from which to access the Cognos application over secure HTTP (HTTPS). Specify the protocol (HTTPS), server name, and optionally the port number.
Note: Provide a fully-qualified domain name. This parameter is case-sensitive.
communities.ejb.cluster

Name of the cluster on which the application is running in a network deployment. This property is used for JNDI lookups in cluster environments to ensure failover and load balancing on lookups.

communities.ejb.port

WebSphere Application Server port number of the application server instance running on the first node of the cluster that hosts this application. This information is used during JNDI lookups. This value is usually 2809, but may be different if port 2809 is already in use.

communities.ejb.server

Fully qualified domain name of the application server instance running on the first node of the cluster that hosts this application. This information is used during JNDI lookups.

communities.enabled
Specifies whether the ability to access the Communities application over HTTP is enabled. The property accepts the following values: true or false.
communities.href
Web address from which to access the Communities application over HTTP. Specify the protocol (HTTP), server name, and optionally the port number.
Note: Provide a fully-qualified domain name. This parameter is case-sensitive.
communities.href.prefix
Context root from which to access the application. For example: /communities.
communities.interService.href
Web address from which other IBM Connections applications access this application. Specify the protocol and server name.
Note: Provide a fully-qualified domain name. This parameter is case-sensitive.
communities.pcs.name.js.eval
Defines the label of the link that you click to access the Communities application from the business card.
communities.pcs.url.pattern
Web pattern of the link to the Communities application from the business card.
communities.ssl.enabled
Specifies whether the ability to access the Communities application over secure HTTP is enabled. The property accepts the following values: true or false. It is set to true by default, and should only be changed to false if you are disabling ssl in your environment. Disabling ssl is a complex, multi-step process that you should consult with IBM Support before attempting.
communities.ssl.href
Web address from which to access the Communities application over secure HTTP (HTTPS). Specify the protocol (HTTPS), server name, and optionally the port number.
Note: Provide a fully-qualified domain name. This parameter is case-sensitive.
connections.blogs.feed.return401_fornopermission_toviewblog
If the setting is present and set to True, then return a 401 error if a user does not have permission to view a blog entry, otherwise return a 403 error.
connections.blogs.lastModifierDisabled
Controls whether or not to display the last modifier information in blogs entries.
connections.blogs.onlymembercanvote
Specify "True" if you want to limit voting in an Ideation blog to the community members. Other users will still be able to recommend ideas.
customAuthenticator.name
Specifies the short name for the code to use to secure server to server communication. The options are:
  • DefaultAuthenticator: Uses the IBM LTPA token to secure the connection. This option is the default option.
  • SiteMinderAuthenticator: Uses a SiteMinder token to secure the connection.
  • TAMAuthenticator: Uses a Tivoli® Access Manager token to secure the connection.
Note: The customAuthenticator.ConnectionTimeout, customAuthenticator.CookieTimeout, customAuthenticator.DefaultMaxConnectionsPerHost, customAuthenticator.MaxTotalConnections, and customAuthenticator.SoTimeout properties were deprecated in version 3.
deployment.id
Unique identifier of the current deployment. This deployment ID is used by plug-ins and other API clients after the address of a deployment changes to determine whether the new address is the same deployment or not. The deployment ID is a unique value that is generated by the installer. Alternatively, you can assign an ID to a deployment. If you decide to assign the ID instead of using the ID generated by the installer, do the following things:
  1. Use the naming convention: the reversed domain name of the IBM Connections installation. For example: com.example.social-intranet.
  2. If the deployment moves from one installation or hostname to another, set the value of the new deployment ID to the same value as the original deployment.
The deployment.id value is exposed within the atom:id of the /serviceconfigs API feed available from all IBM Connections services.
dogear.ejb.cluster

Name of the cluster on which the application is running in a network deployment. This property is used for JNDI lookups in cluster environments to ensure failover and load balancing on lookups.

dogear.ejb.port

WebSphere Application Server port number of the application server instance running on the first node of the cluster that hosts this application. This information is used during JNDI lookups. This value is usually 2809, but may be different if port 2809 is already in use.

dogear.ejb.server

Fully qualified domain name of the application server instance running on the first node of the cluster that hosts this application. This information is used during JNDI lookups.

dogear.enabled
Specifies whether the ability to access the Bookmarks application over HTTP is enabled. The property accepts the following values: true or false.
dogear.href
Web address from which to access the Bookmarks application over HTTP. Specify the protocol (HTTP), server name, and optionally the port number.
Note: Provide a fully-qualified domain name. This parameter is case-sensitive.
dogear.href.prefix
Context root from which to access the application. For example: /dogear.
dogear.interService.href
Web address from which other IBM Connections applications access this application. Specify the protocol and server name.
Note: Provide a fully-qualified domain name. This parameter is case-sensitive.
dogear.pcs.name.js.eval
Defines the label of the link that you click to access the Bookmarks application from the business card.
dogear.pcs.url.pattern
Web pattern of the link to the Bookmarks application from the business card.
dogear.ssl.href
Web address from which to access the Bookmarks application over secure HTTP (HTTPS). Specify the protocol (HTTPS), server name, and optionally the port number.
Note: Provide a fully-qualified domain name. This parameter is case-sensitive.
dogear.ssl.enabled
Specifies whether the ability to access the Bookmarks application over secure HTTP is enabled. The property accepts the following values: true or false. It is set to true by default, and should only be changed to false if you are disabling ssl in your environment. Disabling ssl is a complex, multi-step process that you should consult with IBM Support before attempting.
dynamicHosts.enabled
Specifies whether a reverse proxy is configured for IBM Connections. The property accepts the following values: true or false.
dynamicHosts.href
Web address from which to access IBM Connections through a reverse proxy over HTTP.
Note: Provide a fully-qualified domain name. This parameter is case-sensitive.
dynamicHosts.ssl_href
Web address from which to access IBM Connections through a reverse proxy over secure HTTP (HTTPS).
Note: Provide a fully-qualified domain name. This parameter is case-sensitive.
email.expose.enabled
Specifies whether or not to display user email addresses in the product user interface, and product-generated notifications or URLs. The property accepts the following values: true or false.
files.ejb.cluster

Name of the cluster on which the application is running in a network deployment. This property is used for JNDI lookups in cluster environments to ensure failover and load balancing on lookups.

files.ejb.port

WebSphere Application Server port number of the application server instance running on the first node of the cluster that hosts this application. This information is used during JNDI lookups. This value is usually 2809, but may be different if port 2809 is already in use.

files.ejb.server

Fully qualified domain name of the application server instance running on the first node of the cluster that hosts this application. This information is used during JNDI lookups.

files.enabled
Specifies whether the ability to access the Files application over HTTP is enabled. The property accepts the following values: true or false.
files.href
Web address from which to access the Files application over HTTP. Specify the protocol (HTTP), server name, and optionally the port number.
Note: Provide a fully-qualified domain name. This parameter is case-sensitive.
files.href.prefix
Context root from which to access the application. For example: /files.
files.interService.href
Web address from which other IBM Connections applications access this application. Specify the protocol and server name.
Note: Provide a fully-qualified domain name. This parameter is case-sensitive.
files.pcs.name.js.eval
Defines the label of the link that you click to access the Files application from the business card.
files.pcs.url.pattern
Web pattern of the link to the Files application from the business card.
files.ssl.enabled
Specifies whether the ability to access the Files application over secure HTTP is enabled. The property accepts the following values: true or false. It is set to true by default, and should only be changed to false if you are disabling ssl in your environment. Disabling ssl is a complex, multi-step process that you should consult with IBM Support before attempting.
files.ssl.href
Web address from which to access the Files application over secure HTTP (HTTPS). Specify the protocol (HTTPS), server name, and optionally the port number.
Note: Provide a fully-qualified domain name. This parameter is case-sensitive.
force.conf.comm.enabled
Specifies whether access to the IBM Connections applications can only be reached over a secure HTTP channel (HTTPS).The property accepts the following values: true or false. If you set the value of this property to true, the value of the profiles.directory.service.extension.href or communities.directory.service.extension.href properties, if Profiles or Communities directory service integration is enabled, must be specified as a secure HTTP (HTTPS) web address.
forums.ejb.cluster

Name of the cluster on which the application is running in a network deployment. This property is used for JNDI lookups in cluster environments to ensure failover and load balancing on lookups.

forums.ejb.port

WebSphere Application Server port number of the application server instance running on the first node of the cluster that hosts this application. This information is used during JNDI lookups. This value is usually 2809, but may be different if port 2809 is already in use.

forums.ejb.server

Fully qualified domain name of the application server instance running on the first node of the cluster that hosts this application. This information is used during JNDI lookups.

forums.enabled
Specifies whether the ability to access the Forums application over HTTP is enabled. The property accepts the following values: true or false.
forums.href
Web address from which to access the Forums application over HTTP. Specify the protocol (HTTP), server name, and optionally the port number.
Note: Provide a fully-qualified domain name. This parameter is case-sensitive.
forums.href.prefix
Context root from which to access the application. For example: /forums.
forums.interService.href
Web address from which other IBM Connections applications access this application. Specify the protocol and server name.
Note: Provide a fully-qualified domain name. This parameter is case-sensitive.
forums.pcs.name.js.eval
Defines the label of the link that you click to access the Forums application from the business card.
forums.pcs.url.pattern
Web pattern of the link to the Forums application from the business card.
forums.ssl.enabled
Specifies whether the ability to access the Forums application over secure HTTP is enabled. The property accepts the following values: true or false. It is set to true by default, and should only be changed to false if you are disabling ssl in your environment. Disabling ssl is a complex, multi-step process that you should consult with IBM Support before attempting.
forums.ssl.href
Web address from which to access the Forums application over secure HTTP (HTTPS). Specify the protocol (HTTPS), server name, and optionally the port number.
Note: Provide a fully-qualified domain name. This parameter is case-sensitive.
help.enabled
Specifies whether the ability to access the help system over HTTP is enabled. The property accepts the following values: true or false.
help.href
Web address from which to access the help system over HTTP. Specify the protocol (HTTP), server name, and optionally the port number.
Note: Provide a fully-qualified domain name. This parameter is case-sensitive.
help.href.prefix
Context root from which to access the help system. For example: /activities.
help.interService.href
Web address from which other IBM Connections applications access the help system. Specify the protocol and server name.
Note: Provide a fully-qualified domain name. This parameter is case-sensitive.
help.ssl.enabled
Specifies whether the ability to access the help system over secure HTTP is enabled. The property accepts the following values: true or false. It is set to true by default, and should only be changed to false if you are disabling ssl in your environment. Disabling ssl is a complex, multi-step process that you should consult with IBM Support before attempting.
help.ssl.href
Web address from which to access the help system over secure HTTP (HTTPS). Specify the protocol (HTTPS), server name, and optionally the port number.
Note: Provide a fully-qualified domain name. This parameter is case-sensitive.
homepage.ejb.cluster

Name of the cluster on which the application is running in a network deployment. This property is used for JNDI lookups in cluster environments to ensure failover and load balancing on lookups.

homepage.ejb.port

WebSphere Application Server port number of the application server instance running on the first node of the cluster that hosts this application. This information is used during JNDI lookups. This value is usually 2809, but may be different if port 2809 is already in use.

homepage.ejb.server

Fully qualified domain name of the application server instance running on the first node of the cluster that hosts this application. This information is used during JNDI lookups.

homepage.enabled
Specifies whether the ability to access the Home page application over HTTP is enabled. The property accepts the following values: true or false.
homepage.href
Web address from which to access the Home page application over HTTP. Specify the protocol (HTTP), server name, and optionally the port number.
Note: Provide a fully-qualified domain name. This parameter is case-sensitive.
homepage.href.prefix
Context root from which to access the application. For example: /homepage.
homepage.interService.href
Web address from which other IBM Connections applications access this application. Specify the protocol and server name.
Note: Provide a fully-qualified domain name. This parameter is case-sensitive.
homepage.ssl.enabled
Specifies whether the ability to access the Home page application over secure HTTP is enabled. The property accepts the following values: true or false. It is set to true by default, and should only be changed to false if you are disabling ssl in your environment. Disabling ssl is a complex, multi-step process that you should consult with IBM Support before attempting.
homepage.ssl.href
Web address from which to access the Home page application over secure HTTP (HTTPS). Specify the protocol (HTTPS), server name, and optionally the port number.
Note: Provide a fully-qualified domain name. This parameter is case-sensitive.
metrics.ejb.cluster
Name of the cluster on which the application is running in a network deployment. This property is used for JNDI lookups in cluster environments to ensure failover and load balancing on lookups.
metrics.ejb.port
WebSphere Application Server port number of the application server instance running on the first node of the cluster that hosts this application. This information is used during JNDI lookups. This value is usually 2809, but may be different if port 2809 is already in use.
metrics.ejb.server
Fully qualified domain name of the application server instance running on the first node of the cluster that hosts this application. This information is used during JNDI lookups.
metrics.enabled
Specifies whether the ability to access the Metrics application over HTTP is enabled. The property accepts the following values: true or false.
metrics.href
Web address from which to access the Metrics application over HTTP. Specify the protocol (HTTP), server name, and optionally the port number.
Note: Provide a fully-qualified domain name. This parameter is case-sensitive.
metrics.href.prefix
Context root from which to access the application. For example: /metrics.
metrics.interService.href
Web address from which other IBM Connections applications access this application. Specify the protocol and server name.
Note: Provide a fully-qualified domain name. This parameter is case-sensitive.
metrics.ssl.enabled
Specifies whether the ability to access the Metrics application over secure HTTP is enabled. The property accepts the following values: true or false. It is set to true by default, and should only be changed to false if you are disabling SSL in your environment. Disabling SSL is a complex, multi-step process and you should consult with IBM Support before attempting to perform this step.
metrics.ssl.href
Web address from which to access the Metrics application over secure HTTP (HTTPS). Specify the protocol (HTTPS), server name, and optionally the port number.
Note: Provide a fully-qualified domain name. This parameter is case-sensitive.
mobile.ejb.cluster

Name of the cluster on which the application is running in a network deployment. This property is used for JNDI lookups in cluster environments to ensure failover and load balancing on lookups.

mobile.ejb.port

WebSphere Application Server port number of the application server instance running on the first node of the cluster that hosts this application. This information is used during JNDI lookups. This value is usually 2809, but may be different if port 2809 is already in use.

mobile.ejb.server

Fully qualified domain name of the application server instance running on the first node of the cluster that hosts this application. This information is used during JNDI lookups.

mobile.enabled
Specifies whether the ability to access IBM Connections from a mobile device over HTTP is enabled. The property accepts the following values: true or false.
mobile.href
Web address from which to access IBM Connections from a mobile device over HTTP. Specify the protocol (HTTP), server name, and optionally the port number.
Note: Provide a fully-qualified domain name. This parameter is case-sensitive.
mobile.href.prefix
Context root from which to access IBM Connections from a mobile device. For example: /mobile.
mobile.interService.href
Web address from which IBM Connections applications access one another from a mobile device. Specify the protocol and server name.
Note: Provide a fully-qualified domain name. This parameter is case-sensitive.
mobile.ssl.enabled
Specifies whether the ability to access IBM Connections from a mobile device over secure HTTP is enabled. The property accepts the following values: true or false. It is set to true by default, and should only be changed to false if you are disabling ssl in your environment. Disabling ssl is a complex, multi-step process that you should consult with IBM Support before attempting.
mobile.ssl.href
Web address from which to access IBM Connections from a mobile device over secure HTTP (HTTPS). Specify the protocol (HTTPS), server name, and optionally the port number.
Note: Provide a fully-qualified domain name. This parameter is case-sensitive.
news.ejb.cluster

Name of the cluster on which the application is running in a network deployment. This property is used for JNDI lookups in cluster environments to ensure failover and load balancing on lookups.

news.ejb.port

WebSphere Application Server port number of the application server instance running on the first node of the cluster that hosts this application. This information is used during JNDI lookups. This value is usually 2809, but may be different if port 2809 is already in use.

news.ejb.server

Fully qualified domain name of the application server instance running on the first node of the cluster that hosts this application. This information is used during JNDI lookups.

news.enabled
Specifies whether the ability to access Home page Updates over HTTP is enabled. The property accepts the following values: true or false.
news.href
Web address from which to access Home page Updates over HTTP. Specify the protocol (HTTP), server name, and optionally the port number.
Note: Provide a fully-qualified domain name. This parameter is case-sensitive.
news.href.prefix
Context root from which to access the application. For example: /news.
news.interService.href
Web address from which other IBM Connections applications access Home page Updates. Specify the protocol and server name.
Note: Provide a fully-qualified domain name. This parameter is case-sensitive.
news.ssl.enabled
Specifies whether the ability to access Home page Updates over secure HTTP is enabled. The property accepts the following values: true or false. It is set to true by default, and should only be changed to false if you are disabling ssl in your environment. Disabling ssl is a complex, multi-step process that you should consult with IBM Support before attempting.
news.ssl.href
Web address from which to access Home page Updates over secure HTTP (HTTPS). Specify the protocol (HTTPS), server name, and optionally the port number.
Note: Provide a fully-qualified domain name. This parameter is case-sensitive.
personTag.href
Web address from which to access the business card service over HTTP. Specify the protocol (HTTP), server name, and optionally the port number.
Note: Provide a fully-qualified domain name. This parameter is case-sensitive.
personTag.href.prefix
Context root from which to access the business card.
personTag.interService.href
Web address from which other IBM Connections applications access the business card. Specify the protocol and server name.
Note: Provide a fully-qualified domain name. This parameter is case-sensitive.
personTag.enabled
Specifies whether the ability to access the business card over HTTP is enabled. The property accepts the following values: true or false.
personTag.ssl.enabled
Specifies whether the ability to access the business card over secure HTTP is enabled. The property accepts the following values: true or false. It is set to true by default, and should only be changed to false if you are disabling ssl in your environment. Disabling ssl is a complex, multi-step process that you should consult with IBM Support before attempting.
personTag.ssl.href
Web address from which to access the business card service over secure HTTP (HTTPS). Specify the protocol (HTTPS), server name, and optionally the port number.
Note: Provide a fully-qualified domain name. This parameter is case-sensitive.
profiles.directory.service.extension.enabled
Identifies whether Profiles directory service integration is enabled. When Profiles directory service integration is enabled, IBM Connections retrieves user information from the Profiles database instead of the LDAP server. The property accepts a value of true or false. It is set to false by default. If you install the Profiles application and specify that you want to use the Profiles database as the user directory during the installation, this value is automatically set to true.
Note: Group information can be retrieved from the LDAP directory only.
Note: The profiles.directory.service.extension.auth, profiles.directory.service.extension.auth.alias, communities.directory.service.extension.auth, communities.directory.service.extension.auth.alias, and communities.directory.service.extension.enabled properties can not be edited using wsadmin commands starting in version 3.
profiles.ejb.cluster

Name of the cluster on which the application is running in a network deployment. This property is used for JNDI lookups in cluster environments to ensure failover and load balancing on lookups.

profiles.ejb.port

WebSphere Application Server port number of the application server instance running on the first node of the cluster that hosts this application. This information is used during JNDI lookups. This value is usually 2809, but may be different if port 2809 is already in use.

profiles.ejb.server

Fully qualified domain name of the application server instance running on the first node of the cluster that hosts this application. This information is used during JNDI lookups.

profiles.enabled
Specifies whether the ability to access the Profiles application over HTTP is enabled. The property accepts the following values: true or false.
profiles.href
Web address from which to access the Profiles application over HTTP. Specify the protocol (HTTP), server name, and optionally the port number.
Note: Provide a fully-qualified domain name. This parameter is case-sensitive.
profiles.href.prefix
Context root from which to access the application. For example: /profiles.
profiles.interService.href
Web address from which other IBM Connections applications access this application. Specify the protocol and server name.
Note: Provide a fully-qualified domain name. This parameter is case-sensitive.
profiles.pcs.name.js.eval
Defines the label of the link that you click to access the Profiles application from the business card.
profiles.pcs.url.pattern
Web pattern of the link to the Profiles application from the business card.
profiles.ssl.enabled
Specifies whether the ability to access the Profiles application over secure HTTP is enabled. The property accepts the following values: true or false. It is set to true by default, and should only be changed to false if you are disabling ssl in your environment. Disabling ssl is a complex, multi-step process that you should consult with IBM Support before attempting.
profiles.ssl.href
Web address from which to access the Profiles application over secure HTTP (HTTPS). Specify the protocol (HTTPS), server name, and optionally the port number.
Note: Provide a fully-qualified domain name. This parameter is case-sensitive.
quickr.enabled
Specifies whether the ability to access a link to a Lotus Quickr™ place from the business card over HTTP is enabled. The property accepts a Boolean value; the options are true and false. See Using business cards in the Administering Profiles section of the product documentation for more information about these Lotus Quickr properties.
quickr.href
Web address from which to access a Lotus Quickr place over HTTP. Specify the protocol (HTTP), server name, and optionally the port number.
Note: Provide a fully-qualified domain name. This parameter is case-sensitive.
quickr.href.prefix
Context root from which to access Sametime awareness services. For example: /quickr.
quickr.interService.href
Web address from which other IBM Connections applications access this application. Specify the protocol and server name.
Note: Provide a fully-qualified domain name. This parameter is case-sensitive.
quickr.pcs.name.js.eval
Defines the label of the link that you click to access the Lotus Quickr place from the business card.
quickr.pcs.url.pattern
Web pattern of the link to the Lotus Quickr place from the business card.
quickr.ssl.enabled
Specifies whether the ability to access a link to a Lotus Quickr place from the business card over secure HTTP (HTTPS) is enabled. The property accepts the following values: true and false. It is set to true by default, and should only be changed to false if you are disabling ssl in your environment. Disabling ssl is a complex, multi-step process that you should consult with IBM Support before attempting.
quickr.ssl.href
Web address from which to access a Lotus Quickr place over secure HTTP (HTTPS). Specify the protocol (HTTPS), server name, and optionally the port number.
Note: Provide a fully-qualified domain name. This parameter is case-sensitive.
sametimeLinks.anonymousLogin.enabled
Boolean. Specifies whether the ability to access the Sametime Links resources anonymously is enabled. Options are true and false.
Note: Do not edit this value. For information about how to add Sametime awareness to IBM Connections, see Adding Sametime awareness to IBM Connections.
sametimeLinks.enabled
Boolean. Specifies whether the ability to connect to the Sametime Links resources over HTTP is enabled. Options are true and false.
Note: Do not edit this value. For information about how to add Sametime awareness to IBM Connections, see Adding Sametime awareness to IBM Connections.
sametimeLinks.href
Web address from which the Sametime Links resources, which support the display of presence awareness information in IBM Connections, can be accessed over the HTTP protocol. Specify the protocol (HTTP), server name, and optionally the port number.
Note: Do not edit this value. For information about how to add Sametime awareness to IBM Connections, see Adding Sametime awareness to IBM Connections.
sametimeLinks.href.prefix
Context root from which to access the application. For example: /sametime.
sametimeLinks.interService.href
Web address from which the Sametime Links resources, which support the display of presence awareness information in IBM Connections, can be accessed from other IBM Connections applications.
Note: Provide a fully-qualified domain name. This parameter is case-sensitive.
sametimeLinks.ssl.enabled
Boolean. Specifies whether the ability to connect to the Sametime Links resources over HTTPS is enabled. The property accepts the following values: true or false.
Note: Do not edit this value. For information about how to add Sametime awareness to IBM Connections, see Adding Sametime awareness to IBM Connections.
sametimeLinks.ssl.href
Web address from which the Sametime Links resources, which support the display of presence awareness information in IBM Connections, can be accessed over the HTTPS protocol. Specify the protocol (HTTPS), server name, and optionally the port number.
Note: Do not edit this value. For information about how to add Sametime awareness to IBM Connections, see Adding Sametime awareness to IBM Connections.
sametimeProxy.enabled
Boolean. Specifies whether the ability to connect to the Sametime proxy resources over HTTP is enabled. Options are true and false.
sametimeProxy.href
Web address from which the Sametime proxy resources, which support the display of presence awareness information in IBM Connections using the Sametime proxy, can be accessed over the HTTP protocol. Specify the protocol (HTTP), server name, and optionally the port number.
sametimeProxy.interService.href
Web address from which the Sametime proxy resources, which support the display of presence awareness information in IBM Connections using the Sametime proxy, can be accessed from other IBM Connections applications.
Note: Provide a fully-qualified domain name. This parameter is case-sensitive.
sametimeProxy.ssl.enabled
Boolean. Specifies whether the ability to connect to the Sametime proxy resources over HTTPS is enabled. The property accepts the following values: true or false. It is set to true by default, and should only be changed to false if you are disabling ssl in your environment. Disabling ssl is a complex, multi-step process that you should consult with IBM Support before attempting.
sametimeProxy.ssl.href
Web address from which the Sametime proxy resources, which support the display of presence awareness information in IBM Connections using the Sametime proxy, can be accessed over the HTTPS protocol. Specify the protocol (HTTPS), server name, and optionally the port number.
sand.enabled
Boolean. Specifies whether the ability to connect to the Social Networking and Discovery resources over HTTP is enabled. Options are true and false.
sand.href
Web address from which the Social Networking and Discovery resources can be accessed over the HTTP protocol. Specify the protocol (HTTP), server name, and optionally the port number.
sand.href.prefix
Context root from which to access the application. For example: /sand.
sand.ssl.enabled
Boolean. Specifies whether the ability to connect to the Social Networking and Discovery resources over HTTPS is enabled. The property accepts the following values: true or false. It is set to true by default, and should only be changed to false if you are disabling ssl in your environment. Disabling ssl is a complex, multi-step process that you should consult with IBM Support before attempting.
sand.ssl.href
Web address from which the Social Networking and Discovery resources can be accessed over the HTTPS protocol. Specify the protocol (HTTPS), server name, and optionally the port number.
search.ejb.cluster

Name of the cluster on which the application is running in a network deployment. This property is used for JNDI lookups in cluster environments to ensure failover and load balancing on lookups.

Note: This property has no default value and typically should not be modified from installed defaults in a cluster configuration.
search.ejb.port

WebSphere Application Server port number of the application server instance running on the first node of the cluster that hosts this application. This information is used during JNDI lookups. This property has no default value.

search.ejb.server

Fully qualified domain name of the application server instance running on the first node of the cluster that hosts this application. This information is used during JNDI lookups.

Note: This property has no default value.
search.enabled
Specifies whether the ability to access Advanced Search over HTTP is enabled. The property accepts the following values: true or false.
search.href
Web address from which to access Advanced Search over HTTP. Specify the protocol (HTTP), server name, and optionally the port number.
Note: Provide a fully-qualified domain name. This parameter is case-sensitive.
search.href.prefix
Context root from which to access the application. For example: /search.
search.ignore.punctuation.enabled
Specifies whether or not to ignore punctuation in search terms. This property accepts the following values: true or false. When set to true, punctuation in search terms is ignored. For example, for an occurrence of the term I.B.M, the terms I.B.M. and IBM are stored in the index. This configuration results in a larger index. If you choose to change this option, complete the steps in the topic, Deleting the index.
search.interService.href
Web address from which other IBM Connections applications access Advanced Search. Specify the protocol and server name.
Note: Provide a fully-qualified domain name. This parameter is case-sensitive.
search.language.sensitivity.enabled
Specifies whether or not to turn on language sensitivity in search. The property accepts the following values: true or false. When set to true, the product supports accent insensitive searches. For example, for an occurrence of ált, the product stores ált and alt. This configuration results in a larger index. If you choose to change this option, complete the steps in the topic, Deleting the index.
search.one.to.two.mapping.enabled
Specifies whether or not to perform one-to-two mapping on search terms. The property accepts the following values: true or false. When set to true, the product performs a one-to-two mapping on search terms. For example, for an occurrence of the term Müller, the terms Müller and Mueller are stored in the index. This configuration results in a larger index. If you choose to change this option, complete the steps in the topic, Deleting the index.
search.Queue_Max
Number of connections refused before a subsequent transaction is allowed. This property is used only when Search is installed on a different server from the server hosting the application in which a search is being performed. If the Search server is not responding, a queue of requests is created. The length of the queue is defined by the value of this property. Only the last search request in the queue is sent to the Search server. When the search server starts responding, the queue is no longer used. The default value is 10.
search.ssl.enabled
Specifies whether the ability to access Advanced Search over secure HTTP is enabled. The property accepts the following values: true or false. It is set to true by default, and should only be changed to false if you are disabling ssl in your environment. Disabling ssl is a complex, multi-step process that you should consult with IBM Support before attempting.
search.ssl.href
Web address from which to access Advanced Search over secure HTTP (HTTPS). Specify the protocol (HTTPS), server name, and optionally the port number.
Note: Provide a fully-qualified domain name. This parameter is case-sensitive.
search.Transaction_Max
Maximum number of transactions allowed. This property is used only when Search is installed on a different server from the server hosting the application in which a search is being performed. This setting prevents the server that is preforming the search from running out of memory due to the Search server not responding. The default value is 20.
seedlistSettings.maximumPageSize
Maximum number of items on the search return page. The value must be greater than or equal to 100.
seedlistSettings.maximumIncrementalQuerySpanInDays
Number of days that deletion records are saved before they are eligible to be deleted by the SearchClearDeletionHistory task. The value must be greater than or equal to 1. Connections keeps records of deleted files. These records are eligible to be deleted by the SearchClearDeletionHistory task after the number of days specified in this property. The incremental search crawler needs these deletion records to update the search index. If the records are deleted before the incremental crawler reads them, updates will be incomplete. This is not allowed, so Connections performs a full crawl instead of an incremental crawl. Full crawls delete the existing search index and create a new one, which is more time consuming than incremental crawls. To avoid frequent full crawls, make sure that this value is higher than the span of days between incremental crawls. For example, if incremental crawls happen every four days, make sure this value is higher than 4. This ensures that incremental crawls capture all deletion records.
use.richTextEditor.inBookmarklet.enabled
Specifies whether the description field on the Edit Bookmark form that is displayed when you create a bookmark using the Add Bookmark button is a rich text or plain text field. The form loads more quickly with a plain text description field. The field is plain text by default. The property accepts the following values: true or false.
versionStamp
Defines a version number that is stored as an internal URL reference for static content on the product's web pages. After customizing the product or installing an interim fix, the administrator increments the value of this property to prevent end users from having to clear their web browser cache to see the latest changes. When updating the value of this property, pass a null value to make the server assign a time stamp value to it. If you choose to specify your own time stamp, use the following syntax: yyyyMMdd.HHmmss For example: 20090720.034448.
wikis.ejb.cluster

Name of the cluster on which the application is running in a network deployment. This property is used for JNDI lookups in cluster environments to ensure failover and load balancing on lookups.

wikis.ejb.port

WebSphere Application Server port number of the application server instance running on the first node of the cluster that hosts this application. This information is used during JNDI lookups. This value is usually 2809, but may be different if port 2809 is already in use.

wikis.ejb.server

Fully qualified domain name of the application server instance running on the first node of the cluster that hosts this application. This information is used during JNDI lookups.

wikis.enabled
Specifies whether the ability to access the Wikis application over HTTP is enabled. The property accepts the following values: true or false.
wikis.href
Web address from which to access the Wikis application over HTTP. Specify the protocol (HTTP), server name, and optionally the port number.
Note: Provide a fully-qualified domain name. This parameter is case-sensitive.
wikis.href.prefix
Context root from which to access the application. For example: /wikis.
wikis.interService.href
Web address from which other IBM Connections applications access this application. Specify the protocol and server name.
Note: Provide a fully-qualified domain name. This parameter is case-sensitive.
wikis.pcs.name.js.eval
Defines the label of the link that you click to access the Wikis application from the business card.
wikis.pcs.url.pattern
Web pattern of the link to the Wikis application from the business card.
wikis.ssl.href
Web address from which to access the Wikis application over secure HTTP (HTTPS). Specify the protocol (HTTPS), server name, and optionally the port number.
Note: Provide a fully-qualified domain name. This parameter is case-sensitive.
wikis.ssl.enabled
Specifies whether the ability to access the Wikis application over secure HTTP is enabled. The property accepts the following values: true or false. It is set to true by default, and should only be changed to false if you are disabling ssl in your environment. Disabling ssl is a complex, multi-step process that you should consult with IBM Support before attempting.
Properties that can only change by editing the XML file directly
The following properties are also stored in the LotusConnections-config.xml file, but cannot be edited using the updateConfig command from the wsadmin client. Instead, you must check out the configuration file using the wsadmin client LCConfigService.checkOutConfig command. Then, navigate to the temp directory and open the checked-out file, and then edit the property in a text editor. When you have finished editing the file, check in the updated file using the LCConfigService.checkInConfig command. Validation runs on the file. If an error is found, you are notified and can make any necessary changes, save the file, and try to check it in again.
  • Virus scanning properties:
    <!-- 
      To enable virus scanning, first delete the empty avFilter element.
      Then, uncomment the avFilter in the comment and replace hostname as 
      appropriate
      Replace myScannerService with the appropriate name for your scanner 
      (eg AVSCAN for Symantec, RESPMOD for McAfee)
    -->
        <avFilter>
        </avFilter>
        <!-- <avFilter class="AVScannerICAP">
            <property>av.scanner.servers=myscanner.host.com</property>
            <property>exception.on.virus=yes</property>
            <property>av.scanner.service=myScannerService</property>
            <property>av.chunk.size=50000</property>
            <property>first.read.timeout=120000</property>
        </avFilter>
    	   -->
    The XML elements and attributes function as follows:
    av.chunk.size
    Transfer rate. Specify an integer in bytes. This property is not displayed in the configuration file by default. If you want to specify a value for it, you must add it.
    av.scanner.servers
    Defines the virus scanning server to use to scan uploaded files for viruses. Replace my.virus.scanning.server.com with a list of one or more of the virus scanning servers used by your organization. Separated multiple servers with a comma. For example:

    <property>av.scanner.servers=ssoc.acme.com</property> or <property>av.scanner.servers=ssoc1.acme.com,ssoc2.acme.com</property>

    av.scanner.service
    Defines the service name used by the anti virus scanner. Set this to AVSCAN for Symantec, and RESPMOD for McAfee.
    exception.on.virus
    Defines what to do when a virus is found. This property should always be set to yes.
    first.read.timeout
    Length of time for the timeout. Specify an integer in milliseconds. This property is not displayed in the configuration file by default. If you want to specify a value for it, you must add it.
  • Display language customization support:
    <languageSelector 
     enabled="true" 
     defaultLanguage="" 
     cookieName="conxnsCookie"
     cookieDomain=".acme.com" 
     usePermanentCookie="true">
      <language lang="en">English</language>
      <language lang="zh">\u4e2d\u6587\uff08\u7b80\u4f53\uff09</language>
      <language lang="zh_tw">\u4e2d\u6587 (\u7e41\u9ad4)</language>
      <language lang="ja">\u65e5\u672c\u8a9e</language>
      <language lang="ko">\ud55c\uad6d\uc5b4</language>
      <language lang="fr">Fran\u00e7ais</language>
      <language lang="de">Deutsch</language>
      <language lang="it">Italiano</language>
      <language lang="es">Espa\u00f1ol</language>
      <language lang="pt_br">Portugu\u00eas (Brasil)</language>
      <language lang="cs">\u010ce\u0161tina</language>
      <language lang="da">Dansk</language>
      <language lang="nl">Nederlands</language>
      <language lang="fi">suomi</language>
      <language lang="el">\u0395\u03bb\u03bb\u03b7\u03bd\u03b9\u03ba\u03ac</language>
      <language lang="hu">Magyar</language>
      <language lang="no">Norsk (Bokm\u00e5l)</language>
      <language lang="pl">polski</language>
      <language lang="pt">Portugu\u00eas (Portugal)</language>
      <language lang="ru">\u0420\u0443\u0441\u0441\u043a\u0438\u0439</language>
      <language lang="sl">slovenščina</language>
      <language lang="sv">Svenska</language>
      <language lang="tr">T\u00fcrk\u00e7e</language>
      <language lang="iw">\u05e2\u05d1\u05e8\u05d9\u05ea</language>
      <language lang="ar">\u200f\u0627\u0644\u0639\u0631\u0628\u064a\u0629\u200f</language>
      <language lang="ca">Catal\u00e0</language>
      <language lang="kk">\u049a\u0430\u0437\u0430\u049b\u0448\u0430</language>
      <language lang="th">\u0e44\u0e17\u0e22</language>
    </languageSelector>
    The following table identifies the languages based on the lang property value:
    Table 2. Language code values
    Lang property value Language
    ar Arabic
    ca Catalan
    cs Czech
    da Danish
    de German
    en English
    el Greek
    es Spanish
    fi Finnish
    fr French
    hu Hungarian
    it Italian
    iw Hebrew
    ja Japanese
    kk Kazakh
    ko Korean
    nl Dutch
    no Norwegian
    pl Polish
    pt Portuguese
    pt_br Brazilian Portuguese
    ru Russian
    sl Slovenian
    sv Swedish
    th Thai
    tr Turkish
    zh Simplified Chinese
    zh_tw Traditional Chinese
    The XML entries and attributes function as follows:
    cookieDomain
    Optional. Defines a cookie domain which enables the language setting to work across multiple servers. Specify a valid, fully qualified domain name of the server where the cookie resides. For example: .acme.com. Note that the domain name begins with a period (.). If you specify this cookie domain, the language setting would work for Profiles on profiles.acme.com and for Activities on activities.acme.com. By default, no cookie domain is used.
    cookieName
    Optional. The default cookie name is lcLang. If you want to use a different name for the cookie, specify a new name in this attribute.
    defaultLanguage
    By default, the product user interface is displayed in the language specified as the preferred language by the web browser. You can use the defaultLanguage attribute to define a fallback language in which to display the user interface if the preferred language specified by the browser is not included in the language elements list. It there are no language elements specified, the language specified in this attribute is the only language in which IBM Connections is displayed. Specify the language using the exact strings listed in the example.
    enabled
    Specifies whether to allow users to change the display language of the product. This attribute accepts a Boolean value; the options are true and false.
    language
    Each <language> element represents a language that you want users to be able to select from the language selector drop-down list in the product navigation bar. Add and remove language elements to create a full list of the languages you want to make available. Include a lang attribute that specifies the ISO country code associated with the language. Provide the language name as it should be displayed in the list as the value of the language element. Specify non-Latin characters in Javascript-escaped unicode format. You can only specify languages that the product supports. For a list of languages, see Supported languages.

    Also, remove any of the language elements that are included in the languageSelector element by default if you do not want them to be displayed from the drop-down list of language options in the product menu bar. They are English, French, Chinese, and Arabic.

    usePermanentCookie
    Optional. Specifies whether you want the cookie to persist for longer than the duration of the web browser session. This attribute accepts a Boolean value; the options are true and false. If you set the attribute to true, it creates a persistent cookie that has an expiry date of ten years from the date it was created.
  • Active content filter:

    For some applications, you can customize the configuration file that is used by the active content filter. To do so, you must manually edit the acf_config_file attribute of the <sloc:serviceReference> element representing the application. See Configuring the active content filter for Blogs, Wikis, and Forums or Configuring the active content filter for Activities, Communities, and Bookmarks for more details.

Applying common configuration property changes

After you have edited the configuration properties that are common to all IBM Connections applications, check the changed configuration files in, and restart the servers to apply the changes.

Before you begin

You must perform the check in during the same wsadmin session in which you checked out the files for the changes that you made to take effect.

Procedure
  1. Open a command window and start the wsadmin command line tool as described in the topic, Starting the wsadmin client.
  2. Optional: If you want to confirm the changes that you made before checking the configuration files in, you can list the configuration settings and values using the following command:
    LCConfigService.showConfig()
  3. Update the value of the version stamp configuration property to force users' browsers to pick up this change. Enter the following command to increment the value of the versionStamp property: LCConfigService.updateConfig("versionStamp","gmt_timestamp") where gmt_timestamp is the GMT time. You can specify an empty string for the time stamp or provide a GMT value string. When you specify an empty string, the client calculates the current GMT time and updates the version stamp with that value. If you choose to provide the time, specify it using the following format: yyyyMMdd.HHmmss and specify the time in GMT. It is best to provide an empty string and let the client format the time stamp. For example: LCConfigService.updateConfig("versionStamp",""). See Required post-customization step for more details.
  4. To check in the changed configuration property files, use the following command:
    LCConfigService.checkInConfig()
  5. After making updates, type the following command to deploy the changes:
    synchAllNodes()
  6. To exit the wsadmin client, type exit at the prompt.
  7. Stop and restart all of the IBM Connections application servers.

Running administrative commands

Use administrative commands to run tasks on the server.

About this task

Administrative commands interact with the IBM Connections applications and their resources through scripts. These scripts use the AdminControl object available in WebSphere Application Server wsadmin tool to interact with the application servers. Each script uses managed Java™ beans (MBeans) to get and set server administration properties.

Unlike with configuration properties, when you use these commands to change server administration properties, you do not have to check out any files nor restart the server for the changes to take effect. You do, however, need to understand a bit about how to manipulate Java objects. When you perform server operations using the commands, the item, member information, and access level information are represented as hash tables. Many of the commands, in fact, return a vector of hash tables that represent application resources. Commands you can use to perform tasks, such as deleting, archiving, and restoring, all take parameters formatted as vectors of hash tables. You can then pass information in the hash tables to commands that perform server tasks.

When an administrative command is invoked, a SOAP request is made to the IBM Connections application, for example Activities. The number of seconds that the wsadmin client waits for a response to a SOAP request is specified in the com.ibm.SOAP.requestTimeout property specified in the soap.client.props file in the following directory: {WAS_HOME}\profiles\{PROFILE_NAME}\properties. If a command takes longer to complete than the value of the com.ibm.SOAP.requestTimeout property, an error is displayed on the wsadmin console, and any value returned from the invoked method is lost. The command continues to be processed by the application, but the connection that the application had to the client that invoked it is gone. This detail is important to note because some commands take a long time to run. For example, in a system with a large number of Activities, the ActivityService.fetchActivities() command can take a long time to complete. You can monitor the status of these operations by scanning the SystemOut.log file for success and failure messages.

To increase the time interval that passes before a request fails, edit the com.ibm.SOAP.requestTimeout property in the soap.client.props file. This property is a configuration property, so after editing the property, you must restart the server for the change to take effect.

Procedure
  1. Start the wsadmin client by completing the following steps:
    1. Open a command prompt, and then change to the following directory of the system on which you installed the deployment manager:
      app_server_root\profiles\dm_profile_root\bin
      where app_server_root is the WebSphere Application Server installation directory and dm_profile_root is the Deployment Manager profile directory, typically dmgr01. For example, on Windows:
      C:\Program Files\IBM\WebSphere\AppServer\profiles\Dmgr01\bin
      Attention: You must run the following command to start the wsadmin client from this specific directory because the Jython 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 does not work correctly.
    2. Enter the following command to start the wsadmin client:
      • AIX or 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 a person in the Administrator role on the IBM WebSphere Application Server.
      • admin_password is the password of the WebSphere Application Server administrator.
      • SOAP_CONNECTOR_ADDRESS Port is the SOAP port for the WebSphere Application Server deployment manager server. 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 WebSphere Application Server Integrated Solution Console. To look up the SOAP port number, perform the following steps:
        1. Open the WebSphere Application Server Integrated Solution Console for the deployment manager, and then select System Administration > Deployment Manager.
        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 or Linux:
        ./wsadmin.sh -lang jython -username primaryAdmin -password p@assword -port 8879
      • Microsoft Windows:
        wsadmin -lang jython -username primaryAdmin -password p@assword -port 8879
  2. Use following command to access the application configuration files:
    execfile("application_py_file")
    where application_py_file is one of the following:
    • IBM Connections-wide: connectionsConfig.py
    • OAuth: oauthAdmin.py
    • Activities: activitiesAdmin.py
    • Blogs: blogsAdmin.py
    • Bookmarks: dogearAdmin.py
    • Communities: communitiesAdmin.py
    • Files: filesAdmin.py
    • Forums: forumsAdmin.py
    • Home Page: homepageAdmin.py
    • Metrics: metricsAdmin.py
    • News: newsAdmin.py
    • Profiles: profilesAdmin.py
    • Search: searchAdmin.py
    • Wikis: wikisAdmin.py

    If prompted to specify a service to connect to, type 1 to pick the first node in the list. Most commands can run on any node. If the command writes or reads information to or from a file using a local file path, you must pick the node where the file is stored. This information is not used by the wsadmin client when you are making configuration changes.

  3. Edit administrative properties and perform administrative tasks using the administrative commands documented in the individual application sections of the product documentation.

Starting or stopping Connections applications

IBM Connections applications, such as Files, are WebSphere Enterprise Applications. Start or stop them in the WebSphere Administrative Console as you would any other WebSphere application.

About this task

For complete documentation on starting and stopping WebSphere applications, see the topic Starting or stopping enterprise applications in the IBM WebSphere Application Server information center.

Procedure
  1. Log in to the WebSphere® Administrative Console on the IBM® Connections server.
  2. Click Applications > Application Types > WebSphere enterprise applications in the console navigation tree.
  3. Select the check box for the application you want started or stopped.
  4. Click a button:
    Option Description
    Start Runs the application and changes the state of the application to Started. The status is changed to partially started if not all servers on which the application is deployed are running.
    Stop Stops the processing of the application and changes the state of the application to Stopped.
    To restart a running application, select the application you want to restart, click Stop and then click Start.

System maintenance

Make sure IBM Connections works properly in your particular environment.

Changing WebSphere Application Server environment variables

The directory paths to IBM Connections application data and other resources are given associated WebSphere Application Server environment variables. If you change default paths in your environment, you must update the variables.

Before you begin
The environment variables are given default values unless you change them during the product installation. See WebSphere Application Server environment variables for a list of the default values.

If, for example, you decide to move the directory associated with an application, such as the index directory for Bookmarks, to a different system driver, you can do so, but you must also update the environment variable defined for the Bookmarks index directory in WebSphere Application Server. It is important to update the environment variables because the application configuration files that define the behavior of the applications reference the directory paths using these environment variables.

Procedure
  1. Using an administrator ID, log into the WebSphere Application Server Integrated Console associated with the profile to which you installed IBM Connections. If you installed the applications to multiple WebSphere Application Server profiles, log into the console associated with the appropriate profile.
  2. Expand Environment, and then click WebSphere Variables.
  3. Find the environment variable that you want to change and edit it from the list.
  4. Save and apply your changes, and then restart the server.
WebSphere Application Server environment variables

Unless you change the directory paths during the installation, a set of default IBM WebSphere Application Server environment variables are defined for the IBM Connections application directories. These variables are referenced from the configuration files associated with the applications.

The following tables list the default environment variables defined for application directories on WebSphere Application Server, and for the customization base directory.
Note: It is common practice for production deployments to use more than one shared content store to avoid issues when all the applications attempt to read or write to the same attached device. In this scenario, you might need to change the environment variables to match your deployment. When doing so, you need to update the properties in the IBM Connections configuration engine at the same time; otherwise, the utility for export/import will not function properly. For more information about IBM Connections configuration engine properties, see ConfigEngine properties.
Table 3. Activities default WebSphere Application Server environment variables
Variable name Description / Local or shared* Default value
ACTIVITIES_CONTENT_DIR File upload directory / shared

AIX and Linux: /opt/IBM/Connections/data/shared/activities/content

Microsoft Windows: C:\Program Files\IBM\Connections\data\shared\activities\content

ACTIVITIES_HOME Directory in which Activities was installed. This variable is only necessary on the first node. / local

AIX and Linux: /opt/IBM/Connections/activities/activities/activities

Microsoft Windows: C\Program Files\IBM\Connections\activities\activities\activities

ACTIVITIES_JDBC_DRIVER_HOME JDBC Driver JAR files directory / local JDBC driver library path that you specified when you installed the product. For example: opt/ibm/db2/java
ACTIVITIES_STATS_DIR Statistics directory / shared

AIX and Linux: /opt/IBM/Connections/data/shared/activities/statistics

Microsoft Windows: C:\Program Files\IBM\Connections\data\shared\activities\statistics

Table 4. Blogs default WebSphere Application Server environment variables
Variable name Description / Local or shared* Default value
BLOGS_CONTENT_DIR File upload directory / shared

AIX and Linux: /opt/IBM/Connections/data/shared/blogs/upload

Microsoft Windows: C:\Program Files\IBM\Connections\data\shared\blogs\upload

BLOGS_JDBC_DRIVER_HOME JDBC Driver JAR files directory / local JDBC driver library path that you specified when you installed the product.
BLOGS_HOME Directory in which Blogs was installed. This variable is only necessary on the first node. / local

AIX and Linux: /opt/IBM/Connections/blogs/blogs/blogs

Microsoft Windows: C:\Program Files\IBM\Connections\blogs\blogs\blogs

Table 5. Bookmarks default WebSphere Application Server environment variables
Variable name Description / Local or shared* Default value
DOGEAR_FAVICON_DIR Icons upload directory / shared

AIX and Linux: /opt/IBM/Connections/data/shared/dogear/favorite

Microsoft Windows: C:\Program Files\IBM\Connections\data\shared\dogear\favorite

DOGEAR_JDBC_DRIVER_HOME JDBC Driver JAR files directory / local JDBC driver library path that you specified when you installed the product.
DOGEAR_HOME Directory in which the Bookmarks application was installed. This variable is only necessary on the first node. / local

AIX and Linux: /opt/IBM/Connections/dogear/dogear/dogear

Microsoft Windows: C:\Program Files\IBM\Connections\dogear\dogear\dogear

Table 6. Communities default WebSphere Application Server environment variables
Variable name Description / Local or shared* Default value
CATALOG_INDEX_DIR Directory in which the index is stored / local

AIX and Linux: /opt/IBM/Connections/data/local/catalog/index

Microsoft Windows: C\Program Files\IBM\Connections\data\local\catalog\index

CATALOG_REPLICATION_DIR Directory in which the delta index files are stored / shared

AIX and Linux: /opt/IBM/Connections/data/shared/catalog/indexReplication

Microsoft Windows: C\Program Files\IBM\Connections\data\shared\catalog\indexReplication

COMMUNITIES_JDBC_DRIVER_HOME JDBC Driver JAR files directory / local JDBC driver library path that you specified when you installed the product.
COMMUNITIES_HOME Directory in which Communities was installed. This variable is only necessary on the first node. / local

AIX and Linux: /opt/IBM/Connections/communities/communities/communities

Microsoft Windows: C:\Program Files\IBM\Connections\communities\communities\communities

Table 7. Customization default WebSphere Application Server environment variable
Variable name Description / Local or shared* Default value
CONNECTIONS_CUSTOMIZATION_PATH Customization directory / shared

AIX and Linux: /opt/IBM/Connections/data/shared/customization

Microsoft Windows: C:\Program files\IBM\Connections\data\shared\customization

Table 8. Files default WebSphere Application Server environment variables
Variable name Description / Local or shared* Default value
FILES_CONTENT_DIR File upload directory / shared

AIX and Linux: /opt/IBM/Connections/data/shared/files/upload

Microsoft Windows: C:\Program Files\IBM\Connections\data\shared\files\upload

Files_HOME Directory in which the Files application was installed. This variable is only necessary on the first node. / local

AIX and Linux: /opt/IBM/Connections/files/files/files

Microsoft Windows: C:\Program Files\IBM\Connections\files\files\files

Files_JDBC_DRIVER_HOME JDBC Driver JAR files directory / local JDBC driver library path that you specified when you installed the product.
Table 9. Forums default WebSphere Application Server environment variables
Variable name Description / Local or shared* Default value
FORUM_CONTENT_DIR Forum content directory / shared

AIX and Linux: /opt/IBM/Connections/data/shared/forums/content

Microsoft Windows: C:\Program Files\IBM\Connections\data\shared\forums\content

FORUM_JDBC_DRIVER_HOME JDBC Driver JAR files directory / local JDBC driver library path that you specified when you installed the product.
FORUM_HOME Directory in which the Forum application was installed. This variable is only necessary on the first node. / local

AIX and Linux: /opt/IBM/Connections/forum/forum/forum

Microsoft Windows: C:\Program Files\IBM\Connections\forum\forum\forum

Table 10. Home page default WebSphere Application Server environment variables
Variable name Description / Local or shared* Default value
Homepage_JDBC_DRIVER_HOME JDBC Driver JAR files directory / local JDBC driver library path that you specified when you installed the product.
Homepage_HOME Directory in which the Home page application was installed. This variable is only necessary on the first node. / local

AIX and Linux: /opt/IBM/Connections/homepage/homepage/homepage

Microsoft Windows: C:\Program Files\IBM\Connections\homepage\homepage\homepage

Table 11. Metrics default WebSphere Application Server environment variables
Variable name Description / Local or shared* Default value
METRICS_HOME Directory in which the Metrics application was installed. This variable is only necessary on the first node. / local

AIX and Linux: /opt/IBM/Connections/metrics/metrics/metrics

Microsoft Windows: C:\Program Files\IBM\Connections\metrics\metrics\metrics

METRICS_JDBC_DRIVER_HOME JDBC driver JAR files directory / local. JDBC driver library path that you specified when you installed the product.
Table 12. News default WebSphere Application Server environment variables
Variable name Description / Local or shared* Default value
ACTIVITY_STREAM_SEARCH_INDEX_DIR Directory in which the index for Activity Stream search is stored / local

AIX and Linux: /opt/IBM/Connections/DataLocal/news/search/index

Microsoft Windows: C:\Program Files\IBM\Connections\DataLocal\news\search\index

ACTIVITY_STREAM_SEARCH_REPLICATION_DIR Replication directory for Activity Stream Search / shared

AIX and Linux: /opt/IBM/Connections/data/news/search/indexReplication/ActivityStream

Microsoft Windows: C:\Program Files\IBM\Connections\data\news\search\indexReplication\ActivityStream

AUDIT_FILE_ROOT_DIR Stores temporary attachments for audit purposes. / shared

AIX and Linux: /opt/IBM/Connections/data/shared/audit

Microsoft Windows: C:\Program Files\IBM\Connections\data\shared\audit

NEWS_JDBC_DRIVER_HOME JDBC Driver JAR files directory / local JDBC driver library path that you specified when you installed the product.
NEWS_HOME Directory in which the News application was installed. This variable is only necessary on the first node. / local

AIX and Linux: /opt/IBM/Connections/news/news/news

Microsoft Windows: C:\Program Files\IBM\Connections\news\news\news

Table 13. Profiles default WebSphere Application Server environment variables
Variable name Description / Local or shared* Default value
PROFILES_CACHE_DIR Cache directory / local

AIX and Linux: /opt/IBM/Connections/data/local/profiles/cache

Microsoft Windows: C:\Program Files\IBM\Connections\data\local\profiles\cache

PROFILES_HOME Directory in which the Profiles application was installed. This variable is only necessary on the first node. / local

AIX and Linux: /opt/IBM/Connections/profiles/profiles/profiles

Microsoft Windows: C:\Program Files\IBM\Connections\profiles\profiles\profiles

PROFILES_JDBC_DRIVER_HOME JDBC Driver JAR files directory / local JDBC driver library path that you specified when you installed the product.
PROFILES_STATS_DIR Statistics directory / shared

AIX and Linux: /opt/IBM/Connections/data/shared/profiles/statistics

Microsoft Windows: C:\Program Files\IBM\Connections\data\shared\profiles\statistics

Table 14. Search default WebSphere Application Server environment variables
Variable name Description / Local or shared* Default value
CRAWLER_PAGE_PERSISTENCE_DIR Directory used to store the seedlist pages persisted during crawing. / local

AIX and Linux: /opt/IBM/Connections/data/local/search/persistence

Microsoft Windows: C:\Program Files\IBM\Connections\data\local\search\persistence

EXTRACTED_FILE_STORE Directory used to store the extracted file content. / shared

AIX and Linux: /opt/IBM/Connections/data/shared/search/extracted

Microsoft Windows: C:\Program Files\IBM\Connections\data\shared\search\extracted

FILE_CONTENT_CONVERSION Platform-specific path to the executable that will be called for text extraction from files at indexing time. / local

AIX and Linux: /opt/IBM/WebSphere/Connections/data/local/search/stellent/dcs/oiexport/exporter

Microsoft Windows: Program Files\IBM\Connections\data\local\search\stellent\dcs\oiexport\exporter

SEARCH_DICTIONARY_DIR Dictionary directory / shared

AIX and Linux: /opt/IBM/Connections/data/shared/search/dictionary

Microsoft Windows: C:\Program Files\IBM\Connections\data\shared\search\dictionary

SEARCH_HOME Directory in which Search was installed. This variable is only necessary on the first node. / local

AIX and Linux: /opt/IBM/Connections/search/search/search

Microsoft Windows: C:\Program Files\IBM\Connections\search\search\search

SEARCH_INDEX_DIR Index directory / local

AIX and Linux: /opt/IBM/Connections/data/local/search/index

Microsoft Windows: C:\Program Files\IBM\Connections\data\local\search\index

SEARCH_INDEX_BACKUP_DIR Backup index directory / local

AIX and Linux: /opt/IBM/Connections/data/local/search/backup

Microsoft Windows: C:\Program Files\IBM\Connections\data\local\search\backup

SEARCH_INDEX_SHARED_COPY_LOCATION Directory used for the automatic distribution of the baseline index to other nodes. / shared

AIX and Linux: /opt/IBM/Connections/data/shared/search/staging/

Microsoft Windows: C:\Program Files\IBM\Connections\data\shared\search\staging\

SEARCH_JDBC_DRIVER_HOME JDBC Driver JAR files directory / local JDBC driver library path that you specified when you installed the product.
Table 15. WebSphere Application Server Service Integration Bus file store environment variables
Variable name Description / Local or shared* Default value
MESSAGE_STORE_PATH Directory used to store the files used and managed by the messaging engines of the WebSphere Application Server Service Integration Bus (SIB) for the IBM Connections bus (permanent, temporary and log file) / shared
Note: The same requirements as for other shared content apply to this directory. In addition, if NFS is used, it is highly recommended by WebSphere Application Server SIB to use the version 4 of the protocol.

AIX and Linux: /opt/IBM/Connections/data/shared/messageStores

Microsoft Windows: C:\Program Files\IBM\Connections\data\shared\messageStores

Table 16. Wikis default WebSphere Application Server environment variables
Variable name Description / Local or shared* Default value
WIKIS_CONTENT_DIR File upload directory / shared

AIX and Linux: /opt/IBM/Connections/data/shared/wikis/upload

Microsoft Windows: C:\Program Files\IBM\Connections\data\shared\wikis\upload

WIKIS_HOME Directory in which the Wikis application was installed. This variable is only necessary on the first node. / local

AIX and Linux: /opt/IBM/Connections/wikis/wikis/wikis

Microsoft Windows: C:\Program Files\IBM\Connections\wikis\wikis\wikis

WIKIS_JDBC_DRIVER_HOME JDBC Driver JAR files directory / local JDBC driver library path that you specified when you installed the product.
*Shared content must be accessible (read/write) by all nodes in a cluster. The shared content store must reside in a shared repository that grants read-write access to the Deployment Manager and all the nodes. Use one of the following methods to create a shared data directory:
  • Network-based file shares (for example: NFS, SMB/Samba, and so on)
  • Storage area network drives (SAN)
  • If you are using a shared-file system on Microsoft Windows, specify the file location using the Universal Naming Convention (UNC) format. For example: \\server_name\share_name
Note: With version 3, all variables changed from being server-level variables to being cell-level variables. Variables having a server level scope are more granular than those with a node or cell level scope.

Both shared and local content stores must be accessible using the same path from all nodes and the deployment manager.

ConfigEngine properties

The ConfigEngine properties in the wkplc_comp.properties file are used during the export/import operation.

Production deployments often use more than one shared content store to avoid issues when all the applications are trying to read or write to the same attached device. In the event that you need to change the values of IBM WebSphere Application Server environment variables to match your deployment, you must update the properties in the IBM Connections configuration engine at the same time to ensure that the utility for exporting and importing functions correctly.

IBM Connections uses WebSphere Application Server environment variables at runtime, but during the export/import operation, the utility uses the wkplc_comp.properties file. The file is located in the following directory:
LC_install_dir/ConfigEngine/properties/wkplc_comp.properties

Table 17. ConfigEngine properties
WebSphere environment variables ConfigEngine Properties
ACTIVITIES_CONTENT_DIR activities.objectstore.file.directory
ACTIVITIES_STATS_DIR activities.statistic.directory
AUDIT_FILE_ROOT_DIR news.auditFileDir
BLOGS_CONTENT_DIR blogs.UploadDirectory
COMMUNITIES_STATS_DIR communities.StatisticDirectory
CONNECTIONS_CUSTOMIZATION_PATH connections.CustomizationDirectory
DOGEAR_FAVICON_DIR dogear.UploadDirectory
FILES_CONTENT_DIR files.UploadDirectory
FILE_CONTENT_CONVERSION search.StellentDirectory
FORUM_CONTENT_DIR forum.UploadDirectory
PROFILES_STATS_DIR profiles.statistic.directory
SEARCH_DICTIONARY_DIR search.DictionaryDirectory
WIKIS_CONTENT_DIR wikis.UploadDirectory

Changing the name of the session cookie ID

The session cookie ID for IBM Connections is named JSESSIONID by default. Other products hosted by the WebSphere Application Server often use the same name for their session cookie. If IBM HTTP Server is hosting multiple web servers, you might want to change the cookie name of one of them to prevent the cookie from being lost when the user is redirected from one product to another.

Procedure
  1. If multiple products are hosted on the IBM WebSphere Application Server cell, by default the other application and WebSphere Application Server servers will have conflicting use of the JSESSIONID session ID cookie. For each WebSphere Application Server that uses the same virtual host (hostname) as the one that hosts Lotus Connections applications, do the following:
    1. In the WebSphere Application Server Integrated Solutions Console, expand Servers in the navigation pane, and then select Server Types > WebSphere application servers.
    2. Click the first clustered server.
    3. Expand Web Container Settings under Container Settings, and then select Web container.
    4. Under Additional Properties, click Session management.
    5. Select Enable cookies.
    6. Enter a different cookie name in the Cookie name field, for example, LCSESSIONID.
    7. Click OK, click Save, and then click Save again.
    8. Repeat with each clustered server.
  2. Restart the WebSphere Application Server or servers.
  3. Regenerate the plugin-cfg.xml file for the IBM HTTP Server in the WebSphere Application Server Integrated Solutions Console. To do so, complete the following steps:
    1. Open the WebSphere Application Server Integrated Solutions Console.
    2. Expand Servers, and then select Server Types > Web servers.
    3. Select the check box next to the IBM HTTP Server name. For example: webserver1.
    4. Click Generate Plug-in to regenerate the plugin-cfg.xml file.
    5. If necessary, click Propagate Plug-in to copy the plugin-cfg.xml file from the local directory where the Application Server is installed to the remote machine.
  4. Restart the IBM HTTP Server.

Scheduling tasks

The Activities, Communities, Files, Forums, News, Search, and Wikis applications use the IBM WebSphere Application Server scheduling service for performing regular tasks. You can use wsadmin commands to change the schedule by which a task runs or to disable a scheduled task altogether.

The scheduling service allows you to reliably process workloads using parallel processing, and to schedule resource-intensive tasks during off-peak hours when there is low traffic. For more information about the WebSphere Application Server scheduling service, see the WebSphere Application Server Information Center at: http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/topic/com.ibm.websphere.nd.multiplatform.doc/info/ae/ae/welc6tech_sch.html

The WebSphere Application Server scheduling service is based on the Cron calendar, which uses predefined date algorithms to determine when a task should run. IBM Connections tasks are configured by default to run on a certain schedule. You can change the time at which the scheduled tasks run using wsadmin commands to edit the configuration files for the associated application. Cron schedule values use the following syntax:
second minute hourOfDay dayOfMonth month dayOfWeek
Some tips when specifying the cron schedule values:
  • Specify an asterisk (*) to indicate that you want to select all options. For example, if you specify * as the value of the dayOfWeek parameter, the task runs every day of the week.
  • Always set seconds to 0, except for in the Profiles task, which runs every 20 seconds and is specified using the syntax */20.

    The */n syntax means take the first value in the range, and then every nth value. So, if you specified */3 in the month position, the task would run quarterly in January, April, July, and October.

  • dayOfMonth and dayOfWeek are mutually exclusive; always set one to ?.

    The ? indicates that no value is being provided.

  • You can indicate in a single cron expression that you want a task to run multiple times by using multiple values separated by commas or you can specify a range by separating the values with a dash.
    • You can specify the value in dayOfWeek using SUN, MON or using numbers 1,2 where 1 represents Sunday.
    • You can specify JAN, FEB for the value of month or by using numbers 1,2 where 1 represents January.
    • To specify one or more seconds, use the values 0, 1, ... 59.
    • To specify one or more hours, use the values 0, 1, ... 23.
    For example, specifying 1,4,7,10 in the month position specifies that you want the task to run quarterly. Specifying 2-6 in the dayOfWeek position indicates that you want the task to run Monday through Friday.
  • If it is easier for you to read and define the schedule by separating out the values into multiple cron expressions, you can do so and use a | to concatenate the values into a composite schedule. For example, you could indicate that you want to schedule to run quarterly at 3:45 PM on the second day of the month using the following string: 0 45 15 2 1 ? | 0 45 15 2 4 ? | 0 45 15 2 7 ? | 0 45 15 2 10 ?

To see examples of cron expressions and what they mean, see Examples of scheduler values. For more information on the Cron calendar, see the WebSphere Application Server Information Center at: http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/index.jsp?topic=/com.ibm.websphere.javadoc.doc/web/apidocs/com/ibm/websphere/scheduler/UserCalendar.html

To disable a scheduled task, use wsadmin commands.

Examples of scheduler values

Use the examples provided here to construct your own Cron calendar scheduler values or copy and paste these values into your wsadmin commands to reuse them.

*/30 * * * * ?
Every 30 seconds
0 */5 * * * ?
Every 5 minutes starting at midnight. Be very sure to specify ‘0' for seconds
0 0 * * * ?
Every hour
0 0 * ? * *
Every hour on the hour
0 50 * * * ?
Every hour at 50 minutes past the hour
0 15 0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23 1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31 1,2,3,4,5,6,7,8,9,10,11,12 ?
Every hour at 15 minutes past the hour
0 0 0-22/2 * *
Every other hour starting at midnight.
0 0 4/5 * * ?
Every 5 hours starting at 4 AM. This would run at 4:00, 9:00, 14:00, and 20:00.
0 0 0,8,16 * * ?
Midnight, 8 AM, and 4 PM every day
0 0 11 * * ?
Every day at 11 AM
0 0 0 * * ?
Every day at midnight
0 0 2 ? * *
Every day at 2 AM
0 0 12 ? * MON,TUE,WED,THU,FRI
Weekdays at noon. MON and so on represent the days of the week.
0 0 23 ? * 2-6
Monday through Friday at 11 PM
0 0 21 ? * 2-6/2
Monday, Wednesday, and Friday at 9 PM
0 30 18 ? * SAT,SUN
Weekend days at 6:30 PM
0 0 2 ? * SUN
Weekly on Sundays at 2:00 AM
0 0 23 ? * SAT
Weekly on Sat at 11 PM
0 0 * 1 * ?
Every hour on the first day of every month
0 1 0 L * ?
Last day of every month at 00:01 AM
0 59 23 L * ?
Every month on last day at 11:59 PM
0 0 22 1 * ?
First day of every month at 10 PM
0 45 15 2 1,4,7,10 ?
Quarterly on the 2nd day of the month (January, April, July, October) at 3:45 PM
0 45 15 2 */3 ?
Quarterly on the 2nd day of the month (January, April, July, October) at 3:45 PM
0 45 15 2 1 ? | 0 45 15 2 4 ? | 0 45 15 2 7 ? | 0 45 15 2 10 ?
Quarterly on the 2nd day of the month (January, April, July, October) at 3:45 PM
0 30 3 1 1,7 ?
January 1 and July 1 at 3:30 AM
0 30 3 2 1 ? | 0 30 3 1 7 ?
January 2 and July 1 at 3:30 AM
0 0 0 4 7 ?
Once a year at midnight on the 4th of July
0 30 9 4 7 ?
Once a year at 9:30 AM on the 4th of July
0 45 15 2 1 ?
Once a year on January 2 at 3:45 PM
Clearing all scheduled tasks

Use administrative commands to clear the scheduler of all tasks.

Before you begin
Only perform this procedure if you need to recreate all scheduler tasks. If you see an exception relating to LTPA tokens in the system log before each task runs, then you should perform this procedure to clear the scheduled tasks. This might be required, for example, after a new LTPA token is imported into IBM Connections or imported from a server in another cell as the result of enabling single sign-on, when reverting the databases from a production environment to a staging environment, or after generating new LTPA keys due to a corporate security policy or LTPA timeout.
About this task

Do not run the command documented here unless the clusters hosting the applications and the applications themselves are running. The administrative command used in this procedure interacts with the scheduler MBeans for each application to enumerate the scheduled tasks, and clear the tasks. The WebSphere Application Server scheduler is not application-aware, so as long as the clusters hosting an application are running, the scheduler will attempt to run the scheduled tasks for that application, even if the application itself is stopped. Each attempt to run a scheduled task for a stopped application results in an error message to the log.

If you disable or stop an application, be sure to also cancel any scheduled tasks associated with it.

Procedure
  1. Start the wsadmin client by completing the following steps:
    1. Open a command prompt, and then change to the following directory of the system on which you installed the deployment manager:
      app_server_root\profiles\dm_profile_root\bin
      where app_server_root is the WebSphere Application Server installation directory and dm_profile_root is the Deployment Manager profile directory, typically dmgr01. For example, on Windows:
      C:\Program Files\IBM\WebSphere\AppServer\profiles\Dmgr01\bin
      Attention: You must run the following command to start the wsadmin client from this specific directory because the Jython 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 does not work correctly.
    2. Enter the following command to start the wsadmin client:
      • AIX or 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 a person in the Administrator role on the IBM WebSphere Application Server.
      • admin_password is the password of the WebSphere Application Server administrator.
      • SOAP_CONNECTOR_ADDRESS Port is the SOAP port for the WebSphere Application Server deployment manager server. 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 WebSphere Application Server Integrated Solution Console. To look up the SOAP port number, perform the following steps:
        1. Open the WebSphere Application Server Integrated Solution Console for the deployment manager, and then select System Administration > Deployment Manager.
        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 or Linux:
        ./wsadmin.sh -lang jython -username primaryAdmin -password p@assword -port 8879
      • Microsoft Windows:
        wsadmin -lang jython -username primaryAdmin -password p@assword -port 8879
  2. Use the wsadmin client to access the IBM Connections configuration files.
    1. Enter the following command to access the IBM Connections configuration file: execfile("connectionsConfig.py")

      If prompted to specify a service to connect to, type 1 to pick the first node in the list. Most commands can run on any node. If the command writes or reads information to or from a file using a local file path, you must pick the node where the file is stored. This information is not used by the wsadmin client when you are making configuration changes.

  3. Make sure that all clusters and applications are started and that no scheduled tasks are currently running by retrieving a list of tasks. Use the following command:
    Scheduler.listAllTasks()
    From the returned list, determine what to do next using these guidelines:
    Wsadmin client message
    Recommended action
    Status = running
    Wait until the task is completed.
    Skipping app_name application
    This means that the cluster hosting the application is not started. Restart the cluster.
    Here is a sample of the type of response you may receive when listing scheduled tasks:
    wsadmin>Scheduler.listAllTasks()
    
    Task Name  |  Status  |  Next Fire Time |  Interval
    Communities tasks
    LifecycleRetryQueuedEvents  SCHEDULED  Mon Feb 07 09:01:00 EST 2011  0 1 0-23/3 ? * *
    EventLogCleanup               SCHEDULED  Mon Feb 07 09:30:00 EST 2011   0 30 0-23/3 ? * *
    
    Activities tasks
    TrashAutoPurgeJob             SCHEDULED  Sun Feb 13 02:00:00 EST 2011   0 0 2 ? * SUN
    ActivityAutoCompleteJob       SCHEDULED  Sat Feb 12 23:00:00 EST 2011   0 0 23 ? * SAT
    DatabaseRuntimeStats          SCHEDULED  Mon Feb 07 09:00:00 EST 2011   0 0 * * * ?
    30MinStats                    SCHEDULED  Mon Feb 07 09:00:00 EST 2011   0 0/30 * * * ?
    DailyStats                    SCHEDULED  Mon Feb 07 11:00:00 EST 2011   0 0 11 * * ?
    
    Forums tasks
    TrashAutoPurgeJob             SCHEDULED  Sun Feb 13 02:00:00 EST 2011   0 0 2 ? * SUN
    
    Profiles tasks
    Profiles Worker Process       SCHEDULED  Mon Feb 07 08:36:46 EST 2011   20seconds
    
    Files tasks
    SearchClearDeletionHistory    SCHEDULED  Mon Feb 07 16:00:00 EST 2011   0 0 0,8,16 * * ?
    MetricsDailyCollection        SCHEDULED  Tue Feb 08 00:00:00 EST 2011   0 0 0 * * ?
    TagUpdateFrequency            SCHEDULED  Mon Feb 07 10:00:00 EST 2011   0 0 0-22/2 * * ?
    DirectoryGroupSynch           SCHEDULED  Mon Feb 07 09:00:00 EST 2011   0 0 * * * ?
    FileActuallyDelete            SCHEDULED  Mon Feb 07 09:00:00 EST 2011   0 0 0-23/3 * * ?|0 30 1-23/3 * * ?
    
    Wikis tasks
    SearchClearDeletionHistory    SCHEDULED  Mon Feb 07 16:00:00 EST 2011   0 0 0,8,16 * * ?
    MetricsDailyCollection        SCHEDULED  Tue Feb 08 00:00:00 EST 2011   0 0 0 * * ?
    TagUpdateFrequency            SCHEDULED  Mon Feb 07 10:00:00 EST 2011   0 0 0-22/2 * * ?
    DirectoryGroupSynch           SCHEDULED  Mon Feb 07 09:00:00 EST 2011   0 0 * * * ?
    FileActuallyDelete            SCHEDULED  Mon Feb 07 09:00:00 EST 2011   0 0 0-23/3 * * ?|0 30 1-23/3 * * ?
    
    News tasks
    NewsDataCleanup               SCHEDULED  Mon Feb 07 23:00:00 EST 2011   0 0 23 ? * *
    NewsCheckUpdatedPersons       SCHEDULED  Mon Feb 07 08:50:00 EST 2011   0 50 * * * ?
    EmailDigestDelivery           SCHEDULED  Mon Feb 07 09:00:00 EST 2011   0 0 * ? * *
    MetricsCollector              SCHEDULED  Tue Feb 08 02:00:00 EST 2011   0 0 2 ? * *
    PersonSpreadTranche           SCHEDULED  Tue Mar 01 22:00:00 EST 2011   0 0 22 1 * ?
    
    Search tasks
    20min-file-retrieval-task     SCHEDULED  Mon Feb 07 08:41:00 EST 2011   0 1/20 0,2-23 * * ?
    15min-search-indexing-task    SCHEDULED  Mon Feb 07 08:46:00 EST 2011   0 1/15 0,2-23 * * ?
    nightly-optimize-task         SCHEDULED  Tue Feb 08 01:30:00 EST 2011   0 30 1 * * ?
    nightly-sand-task             SCHEDULED  Tue Feb 08 01:00:00 EST 2011   0 0 1 * * ?
    
    wsadmin>
  4. After performing any suggested actions, run the following command to clear the scheduled tasks:
    Scheduler.clearAllTasks()
  5. Restart the cluster servers to force the scheduled tasks to be recreated.
    1. From the WebSphere Application Server Integrated Solutions Console, expand Servers, click Server Types, and then click WebSphere application servers.
    2. Select the check box for one server per cluster, and then click Restart.

Maintaining application databases

Each IBM Connections application stores data in a database, and some also store data on a file system. You must back up these databases and file systems on a regular schedule using the methods documented by the vendor from whom you purchased the database and file system that you are using.

About this task

If you use IBM DB2 databases, IBM Connections provides a few SQL scripts to help you perform maintenance tasks on them, such as collecting statistics and compacting. You can collect statistics while IBM Connections is running; there is no need to stop the applications nor bring the databases offline. However, you must stop all applications that access the databases before compacting and defragment them.

Note: When you restore data for an application that is also available from the Communities application, you must also restore the data in the Communities application to keep the two in sync. See Recovering from a database failure for more details.
Gathering DB2 database statistics daily

Use the provided script to gather statistics about DB2 database table usage. Run the scripts nightly using the DB2 Task Center, for example, to update internal statistics used by DB2. Up-to-date statistics are necessary for proper performance. This procedure is relevant for DB2 databases only. Oracle and SQL Server gather statistics automatically.

About this task
You can collect statistics while IBM Connections is running and in use. However, it is best to schedule statistic collection to run on a regular basis during off-peak hours using a tool such as DB2 Task Scheduler.

To gather DB2 database statistics, complete the following steps:

Procedure
  1. Copy the statistics script named runstats.sql to the root directory of the application database for which you want to gather statistics. The script is stored in the following subdirectory of the IBM Connections installation files:
    • AIX or Linux:
      /Lotus_Connections_Install/connections.sql/
       application_subdirectory/db2
    • Microsoft Windows:
      \Lotus_Connections_Install\connections.sql\
       application_subdirectory\db2
    where application_subdirectory is the script file storage directory of the application for which you are compacting the database. Choose one of the following subdirectories:
    • activities
    • blogs
    • communities
    • dogear
    • files
    • forum
    • homepage
    • metrics
    • profiles
    • wikis
  2. Log into the database server using an ID that has administrative privileges.
  3. Open a command prompt, and then change to the directory to which you copied the script.
  4. Use the following command to run the application scripts:
    • For Activities, Blogs, Communities, and Forums:
      db2 -td@ -vf runstats.sql
    • For Bookmarks and Profiles:
      db2 -tvf runstats.sql
    • For Home page:
      db2 -tvf updateStats.sql
    • For Files, Metrics, and Wikis:
      db2 -td@ -vf updateStats.sql
Improving access performance and defragmenting DB2 database data

Use the scripts provided with IBM Connections to improve access performance and reclaim fragmented space in the DB2 database data of an application database. This procedure is relevant for DB2 databases only. Oracle and SQL Server compact data automatically.

Before you begin
The script that you run to improve access performance and reclaim the fragmented space of the database takes the database offline. To prepare the database to be taken offline, you must stop the WebSphere Application Server instances for each application that you plan to run the script on.
About this task
You do not need to run this script on the database frequently. It is recommended that you schedule this tasks during another maintenance task that requires you to take the application offline.
Procedure
  1. Copy the database compacting script named reorg.sql to the root directory of the application database for which you want to improve access performance. The scripts are stored in the following subdirectory of the IBM Connections installation files:
    • AIX or Linux:
      /Lotus_Connections_Install/connections.sql/
       application_subdirectory/db2
    • Microsoft Windows:
      \Lotus_Connections_Install\connections.sql\
       application_subdirectory\db2
    where application_subdirectory is the script file storage directory of the application for which you are improving database access performance. Choose one of the following subdirectories:
    • activities
    • blogs
    • communities
    • dogear
    • files
    • forum
    • homepage
    • metrics
    • profiles
    • wikis
    Note: To improve access performance of the Communities discussion forum database, copy the reorg_forum.sql file from the communities subdirectory.
  2. From the WebSphere Application Server Integrated Solutions Console, stop the servers hosting the applications hosting the databases. To do so, complete the following steps:
    1. Log in to the WebSphere Application Server Integrated Solutions Console as an administrator.
    2. Expand Servers > Server Types, and then select WebSphere application servers.
    3. Select the check boxes next to the servers hosting the applications with the databases in which you want to improve access performance, and then click Stop.
  3. Log into the database server using an ID that has administrative privileges.
  4. Open a command prompt, and change to the directory to which you copied the script.
  5. Use the following command to run the application scripts:
    • For Activities, Blogs, Communities, Forums, Files, Metrics, and Wikis:
      db2 -td@ -vf reorg.sql
    • For Bookmarks, Home page, and Profiles:
      db2 -tvf reorg.sql
  6. Restart the application servers by repeating Step 2, but selecting Start instead of Stop.

Configuring notifications

If you did not create a mail session on the WebSphere Application Server during the initial installation, you can configure it afterwards to enable support for email notifications in the IBM Connections applications.

Before you begin
When you enable notifications, users are kept informed about new information and events that take place in the IBM Connections applications. For example, the following types of notifications are available for the applications:
Activities
Notification events are enabled by default. Email event types are only enabled if you enabled email notifications during the product installation process.
Table 18. Activities notification types
Notification name Description Notification type
add-member When an activity owner adds members to an activity, a notification is automatically sent to them to inform them about the activity. Directed
autocomplete Activity owners receive an email to warn them that one of their inactive activities will be marked complete if it is not updated. Directed
create When a standard activity is created, each member is sent a notification informing them about the activity. When a community activity is created, notifications are sent out only if individual members are added; no notifications are sent when an entire community membership list is added. Directed
notify Activity members can send other members notifications about entries. Directed
Blogs
Table 19. Blogs notification types
Notification name Description Notification type
approved When an entry, idea, or comment is approved, an automatic notification is sent to the author as well as last editor to inform them about it. Moderation
confirmflagged When a flag on a post, idea or comment is confirmed, an automatic notification is sent to the flag creator to inform him about it. Moderation
notify Notifications that one user sends to others to inform them about useful blog posts. Directed
notifyassigned-author When a blog owner assigns author permission for a blog, an automatic notification is sent to the member to inform them of the blog and their access level. Directed
notifyassigned-draft When a blog owner assigns draft permission for a blog, an automatic notification is sent to the member to inform them of the blog and their access level. Directed
notifyassigned-owner When a blog owner assigns owner permission for a blog, an automatic notification is sent to the member to inform them of the blog and their access level. Directed
notify-idea Notifications that one user sends to others to inform them about useful ideas. Directed
notifyflagged When a post, idea, or comment is flagged as inappropriate, an automatic notification is sent to content reviewers, which includes anyone in the global-moderator role, to inform them about it. Moderation
notifyreposted When an entry or idea is modified and re-posted, an automatic notification is sent to content reviewers, which includes anyone in the global-moderator role, to inform them about it. Moderation
notifyreview When a new entry, idea, comment or trackback comment is posted and put in pending status, an automatic notification is sent to content reviewers, which includes anyone in the global-moderator role, to let them know they need to review it. Moderation
ownermsg When a new comment is posted, an automatic notification is sent to the entry or idea creator about the new comment. Response
quarantined When an entry, idea, or comment is quarantined, an automatic notification is sent to the authors, which includes the post creator and its last editor, and blog owners to inform them about it. Moderation
rejected When an entry, idea, or comment is rejected, an automatic notification is sent to the author and last editor to inform them about it. Moderation
restored When an entry, idea, or comment is restored, an automatic notification is sent to the author and last editor and blog owners to inform them about it. Moderation
returned When an entry or idea is returned, an automatic notification is sent to the post authors, which includes the post creator and its last editor, and blog owners to inform them about it. Moderation
Bookmarks
Table 20. Bookmarks notification types
Notification name Description Notification type
brokenurl Broken URL notifications display in the activity stream on the Home page. Directed
notify Users can send notifications to other users to inform them about useful bookmarks. Directed
notifyReplaceURL Administrator can send a notification to the bookmark owner to report the update of a link. This notification is triggered by an MBean
Communities
Table 21. Communities notification types
Notification name Description Notification type
broadcastMail Members can send notifications to other members to inform them about important events. Broadcast
invite Members can send a notification to a non-member to invite them to join the community. Directed
memberAdded Notifications are automatically generated and sent to members when they are added to a community. Directed
memberRemoved Notifications are automatically generated and sent to members when they are removed from a community. Directed
notifyEvent Community members can send other members notifications about specific events by opening the event and selecting More Actions > Notify Other People. The event owner can also send this notification when creating the event. Directed
requestToJoin Users can request to join a community by sending a notification to the community's owner. Directed
Files
Table 22. Files notification types
Notification name Description Notification type
collectionMediaAdd Notification sent to users when a file is added to a folder or community they are following. Directed
collectionMemberUpdate Notification sent to users when a folder is shared with them, or when their folder access level changes. This applies to individual users, not groups. Directed
commentAdd Notification sent to users when a comment is created on a file they are following. Users can follow files by opening the file page and clicking Follow. Follow
communityVisibilityUpdate Notification sent to owners of a community when the community was changed from non-public to public and private files shared with the community were removed from it. Directed
mediaEdit Notification sent to users when a file they are following is edited. Users can follow files by opening the file page and clicking Follow. Follow
mediaShare Notification sent to users when files are shared with them. Directed
Moderation
Table 23. Moderation notification types
Notification name Description Notification type
notifyApproved When an entry is approved, an automatic notification is sent to the entry authors, which includes the entry's creator and its last editor, and the entry owners to inform them about it. Moderation
notifyAutoQuarantined When an entry is flagged as inappropriate a specified number of times, automatic notification is sent to the Global Moderator and Reviewers. The number of inappropriate flaggings is specified in the contentreview-config.xml file, in the autoQuarantine property. For example, if you specify autoQuarantine at "5", notification is sent after the entry is flagged a fifth time. Moderation
notifyFlagged When an entry is flagged as having inappropriate content, and put in pending status, an automatic notification is sent to content reviewers, which includes anyone in the global-moderator role, to let them know they need to review it. Moderation
notifyPending When an entry is added and needs approval, an automatic notification is sent to the entry author to let them know that the entry is in the review process. Reviewers and moderators are notified separately by a notifyReview email. Moderation
notifyQuarantined When an entry is quarantined, an automatic notification is sent to the entry authors, which includes the entry's creator and its last editor, and the entry owners to inform them about it. Moderation
notifyRejected When an entry is rejected, an automatic notification is sent to the entry authors, which includes the entry's creator and its last editor, and the entry owners to inform them about it. Moderation
notifyRestored When an entry is restored, an automatic notification is sent to the entry authors, which includes the entry's creator and its last editor, and the entry owners to inform them about it. Moderation
notifyReview When an entry is added, and put in pending status, an automatic notification is sent to content reviewers, which includes anyone in the global-moderator role, to let them know they need to review it. Moderation
News
Table 24. News notification types
Notification name Description Notification type
dailyDigest If email notifications are enabled on your system, you will have options that are set to Daily Newsletter option by default in the Settings page. Each of the options correspond to a subview within the Home page Updates News Feed view. All options can be customized to a desired frequency. Areas that have this option set will have content included in the Daily Newsletter received, once there has been an update by a person other than yourself within that subview since the last Daily Newsletter. Follow
followIndividual If email notifications are enabled on your system, you will have options that are set to Individual E-mails option by default in the Settings page. Each of the options correspond to a subview within the Home page Updates News Feed view. All options can be customized to a desired frequency. Any updates within the corresponding News Feed subview by a person other than yourself are sent to you in individual emails. Follow
replyToError When a user replies to a ReplyTo enabled notification and an error occurs at the server, an automatic notification is generated and sent to the user to inform them of the error. Directed
weeklyDigest If email notifications are enabled on your system, you will have options that are set to Weekly Newsletter option by default in the Settings page. Each of the options correspond to a subview within the Home page Updates News Feed view. All options can be customized to a desired frequency. Areas that have this option set will have content included in the Weekly Newsletter received, once there has been an update by a person other than yourself within that subview since the last Weekly Newsletter. Follow
Profiles
Table 25. Profiles notification types
Notification name Description Notification type
notify If a person designates someone else as a colleague, the colleague is sent a notification inviting them to join that person's network. Directed
notifyBoardOwnerForComment Board owners are notified when someone comments on their message board. Response
notifyBoardOwnerForEntry Board owners are notified when someone posts a message in their message board. Response
notifyEntryOwnerForComment Board owners are notified when someone comments on a message board entry. Response
Wikis
Table 26. Wikis notification types
Notification name Description Notification type
commentAdd

Notification sent to users when a comment is created on a wiki page they are following, or on any page in a wiki they are following.

Users can follow wiki pages or wikis by opening a page and clicking Follow, and then Follow this Page or Follow this Wiki.

Follow
mediaEdit

Notification sent to users when an event occurs in a wiki page or wiki they are following. Events include title or description edits, new tags, and new or deleted pages, edits or comments.

Users can follow wiki pages or wikis by opening a page and clicking Follow, and then Follow this Page or Follow this Wiki.

Follow
roleAdd

Notification sent to users when they are made a member of a wiki, or when their wiki access level is changed. This applies to individual users, not groups.

Directed
The following notification types are supported:
Broadcast
Sent solely to the recipients by email. Broadcast notifications are not shown on the Home Page.
Directed
Sent from one user, or the system, to another user or set of users. Users can opt to not receive these notifications via email through their email preferences settings. Directed notifications are always visible to the recipients and the sender from the Home Page.
Follow
Generated for users who follow a particular resource and who choose to have individual notifications sent for that type of resource on their email preferences settings.
Moderation
Used solely in the content moderation process.
Response
Used to inform a user when a comment or reply has been left on their content. Response notifications only go to the owner of the content, not followers. These notifications are sent if the user has elected to receive responses through individual emails in their email preferences settings.
Note: Only complete this task if you did not configure notifications during the installation.
About this task
You can configure notifications to be sent in one the following ways:
Send mail from a server found by doing a lookup
This configuration performs a lookup of domain namespace (DNS) MX records to retrieve a list of available SMTP servers. If the DNS lookup does not find any available SMTP servers, then notification fails. If one or more SMTP servers are returned by the lookup, then IBM Connections attempts to send the notification email through one, and then the next until the email is sent successfully. This option avoids the risk of a single point of failure. If you choose this option, make sure your DNS is configured with valid MX records to ensure that available SMTP servers can be found.
Send mail from a specific SMTP server
This configuration uses a single SMTP server. You must define the SMTP server and its associated settings as a mail session that is managed by WebSphere Application Server. This single SMTP server is used to send email notifications. If the server is unavailable, then notification fails.
Sending mail from any available mail server

Configure IBM Connections to perform a lookup of domain namespace (DNS) MX records to retrieve a list of available SMTP servers. If the DNS lookup does not find any available SMTP servers, then email notifications fail to be delivered. If one or more SMTP servers are returned by the lookup, then IBM Connections attempts to send the email through one, and then the next until the email is sent successfully.

Before you begin
Mail is configured as part of the installation process. Only perform this procedure if you did not enable mail during the installation or you want to change the mail configuration.

You can choose to have IBM Connections perform a DNS lookup of multiple SMTP server to find one that is available to send the message or you can configure notifications to be sent from a single, dedicated SMTP server. If you are interested in the latter configuration, see Sending mail from a dedicated mail server. If you choose to enable mail from any available server, make sure your DNS is configured with valid MX records to ensure that available SMTP servers can be found.

Procedure
  1. Start the wsadmin client from the following directory of the system on which you installed the deployment manager:
    app_server_root\profiles\dm_profile_root\bin
    Note: You must start the client from this directory or subsequent commands that you try to run will not execute properly. See Starting the wsadmin client for more details.
  2. Use the following command to access the IBM Connections configuration files:
    execfile("connectionsConfig.py")

    If prompted to specify a service to connect to, type 1 to pick the first node in the list. Most commands can run on any node. If the command writes or reads information to or from a file using a local file path, you must pick the node where the file is stored. This information is not used by the wsadmin client when you are making configuration changes.

  3. Check out the notification-config.xml file using the following command:
    LCConfigService.checkOutNotificationConfig("temp_dir","cell_name")
    where temp_dir is a temporary directory and cell_name is the WebSphere Application Server cell to which you installed the application for which you are enabling mail. When you specify a path to the temporary directory on a system running Microsoft Windows, use a forward slash for the directory. For example: "C:/temp".
    Note: AIX and Linux only: The temporary directory must grant write permissions or the command will not run successfully.
  4. From the temporary directory to which you checked out the notification-config.xml file, open it in a text editor.
  5. Search for the <emailChannelConfig> element, and then change the value of the <useJavaMailProvider> element from true to false:
    <useJavaMailProvider>false</useJavaMailProvider>
  6. Remove the punctuation commenting out the <smtpJNDILookup> element by removing the !-- from the opening element and -- from the closing element. For example, change the following XML markup:
    <!--smtpJNDILookup>
    ...
    </smtpJNDILookup-->
    to the following markup:
    <smtpJNDILookup>
    ...
    </smtpJNDILookup>
  7. Set the value of the <smtpJNDILookupURL> element within the <smtpJNDILookup> XML block to a valid DNS lookup web address for your environment.

    For example, the following web address performs a lookup of MX records for the acme.com domain using the default DNS server on the system on which IBM Connections is running:

    dns:///acme.com
    This value performs the same lookup on a specific DNS server that has an IP address of 192.168.0.2.
    dns://192.168.0.2/acme.com
  8. Configure or comment out any of the remaining properties in the <smtpJNDILookup> element block as needed for your environment. Some of the elements for which you can specify values are defined as follows:
    <authEntry>
    Specifies a WebSphere managed Java 2 Connector alias that specifies the username and password to use when connecting to an SMTP server requiring authentication.
    <javamail>
    Specifies valid JavaMail properties. For example:
    <javamail>
      <property name="mail.debug">false</property>
      <property name="mail.smtp.connectiontimeout">120000</property>
      <property name="mail.smtp.timeout">120000</property>
      <property name="mail.smtp.port">465</property>
      <property name="mail.smtp.socketFactory.port">465</property>
      <property 
       name="mail.smtp.socketFactory.class">javax.net.ssl.SSLSocketFactory
      </property>
      <property name="mail.smtp.socketFactory.fallback">false</property>
    </javamail>

    The smtp properties configure a secure connection to the SMTP server using SSL. The time out properties define the amount of time for the notification to wait for the server to complete the request. If the time limit is reached, an exception is written to the server log, and an error is displayed to the Activities user that requested the notification. These properties prevent resources from being consumed in the event that the SMTP server is unavailable. The time interval is specified in milliseconds. A value of 120,000 is two minutes.

    See the JavaMail documentation for more information about these properties.
  9. The <maxRecipients> element defines the maximum number of people to whom you can send a notification at one time. The default value for this element is 50, but you can change it.
    <maxRecipients>50</maxRecipients>
  10. Save and close the notification-config.xml file.
    Note: You must check out and edit the same file in the procedure described in Enabling email notifications. If you plan to complete that procedure next, keep the notification-config.xml file open and checked out.
  11. Check in the configuration files using the following command:
    LCConfigService.checkInNotificationConfig("<temp_dir>","<cell-name>")
  12. Stop and restart IBM Connections.
What to do next
You must complete the steps described in Enabling email notifications before users can send and receive email notifications.
Sending mail from a dedicated mail server

Configure IBM Connections notifications to be sent from a specific SMTP server that is managed by WebSphere Application Server. If the designated mail server is unavailable, then notification emails fail to be delivered.

Before you begin
Mail is configured as part of the installation process. Only perform this procedure if you did not enable mail during the installation or you want to change the mail configuration.

You can choose to configure notifications to be sent from a single SMTP or have IBM Connections perform a lookup of multiple SMTP server to find one that is available to send the message. If you are interested in the latter configuration, see Sending mail from any available mail server.

Procedure
  1. Log into the IBM WebSphere Application Server Integrated Solutions Console.
  2. Expand Resources and select Mail > Mail sessions.
  3. Select Cell scope, and then create a new session.
  4. Specify values for the following fields:
    Name
    Specify IBM Connections Notification or another descriptive string.
    JNDI name
    Specify mail/notification as the value of the JNDI name.
  5. Specify the following custom properties to define time outs that will prevent resources from being consumed in the event that the SMTP server is unavailable:
    mail.smtp.timeout=120000
    mail.smtp.connectiontimeout=120000
    The time interval is specified in milliseconds. A value of 120,000 is two minutes.
  6. In the Outgoing Mail Properties section, specify the fully qualified host name or IP address of the SMTP server that you want to use in the Server field.
  7. Optional: If the SMTP server requires authentication, then provide values for the following fields:
    User
    User ID used to connect to the SMTP server.
    Password
    Password associated with the user ID used to connect to the SMTP server.
    Verify Password
    Repeat the password specified in the previous field.
  8. If the SMTP server requires traffic to be sent over SSL, then add the following customer properties, and then specify values for them by clicking the Custom properties link, and then clicking New:
    mail.smtp.port
    Specifies the SMTP port number, which is often 465.
    mail.smtp.socketfactory.port
    Specifies the SMTP port number, which is often 465.
    mail.smtp.socketfactory.class
    Specifies the SSL socket factory class.
    mail.smtp.socketFactory.fallback
    Specifies whether an unsecure connection can be made if SSL is not available. This property accepts the following values: true or false.
    For example:
    mail.smtp.port=465
    mail.smtp.socketfactory.port=465
    mail.smtp.socketfactory.class=javax.net.ssl.SSLSocketFactory
    mail.smtp.socketFactory.fallback=false
  9. Click OK, and then save your changes.
  10. Start the wsadmin client from the following directory of the system on which you installed the deployment manager:
    app_server_root\profiles\dm_profile_root\bin
    Note: You must start the client from this directory or subsequent commands that you try to run will not execute properly. See Starting the wsadmin client for more details.
  11. Update the notification configuration file to indicate that you want to use a mail session managed by WebSphere Application Server.
    1. Use the following command to access the IBM Connections configuration files:
      execfile("connectionsConfig.py")

      If prompted to specify a service to connect to, type 1 to pick the first node in the list. Most commands can run on any node. If the command writes or reads information to or from a file using a local file path, you must pick the node where the file is stored. This information is not used by the wsadmin client when you are making configuration changes.

    2. Check out the notification-config.xml file using the following command:
      LCConfigService.checkOutNotificationConfig("temp_dir","cell_name")
      where temp_dir is a temporary directory and cell_name is the WebSphere Application Server cell to which you installed the application for which you are enabling mail. When you specify a path to the temporary directory on a system running Microsoft Windows, use a forward slash for the directory. For example: "C:/temp".
      Note: AIX and Linux only: The temporary directory must grant write permissions or the command will not run successfully.
    3. From the temporary directory to which you checked out the notification-config.xml file, open it in a text editor.
    4. Search for the <emailChannelConfig> element, and then uncomment the following line of XML markup if it is commented out:
      <useJavaMailProvider>true</useJavaMailProvider>
    5. Comment out the <smtpJNDILookup> element if it is not already.
      <!--smtpJNDILookup>
      ...
      </smtpJNDILookup-->
    6. Save and close the notification-config.xml file.
      Note: You must check out and edit the same file in the procedure described in Enabling email notifications. If you plan to complete that procedure next, keep the notification-config.xml file open and checked out.
    7. Check in the configuration files using the following command:
      LCConfigService.checkInNotificationConfig("<temp_dir>","<cell-name>")
    8. Stop and restart IBM Connections.
What to do next
You must complete the steps described in Enabling email notifications before users can send and receive email notifications.
Enabling email notifications

Edit configuration settings to enable email notifications in the IBM Connections applications if you did not do so during the installation.

Before you begin
Only complete this procedure if you did not enable email notifications during the product installation. You must complete the steps described in the Configuring notifications topic before you can start this procedure.
About this task
You might choose not to enable email notifications if you have configured IBM Connections to hide email addresses, for example. Even when you do not enable email notifications, if you installed the Home page application, the product still supports a subset of notifications that can be displayed in the Home page application. The subset includes the notifications of type "Directed," which are listed in the topic named Configuring notifications.

When you set the enabled property to false globally or for a specific source, this disables all notification events for the Home page. Notification emails will not be sent and notifications will not display in the My Notifications view in the Home page. For this reason, when you are disabling email only, it is important to ensure that you only set the email channel to false for a specific notification type.

Procedure

To configure email notifications, complete the following steps:

  1. Start the wsadmin client from the following directory of the system on which you installed the deployment manager:
    app_server_root\profiles\dm_profile_root\bin
    Note: You must start the client from this directory or subsequent commands that you try to run will not execute properly. See Starting the wsadmin client for more details.
  2. Use the following command to access the IBM Connections configuration files:
    execfile("connectionsConfig.py")

    If prompted to specify a service to connect to, type 1 to pick the first node in the list. Most commands can run on any node. If the command writes or reads information to or from a file using a local file path, you must pick the node where the file is stored. This information is not used by the wsadmin client when you are making configuration changes.

  3. Check out the notification-config.xml file using the following command:
    LCConfigService.checkOutNotificationConfig("temp_dir","cell_name")
    where
    • temp_dir is the temporary directory to which the configuration XML and XSD files are copied and are stored while you make changes to them. Use forward slashes to separate directories in the file path, even if you are using the Microsoft Windows operating system.
      Note: AIX and Linux only: The temporary directory must grant write permissions or the command will not run successfully.
    • cell_name is the WebSphere Application Server cell to which you installed the application for which you are enabling mail. This argument is case-sensitive, so type it with care.
    Note: If you want to enable mail for all of the applications and if you installed IBM Connections into multiple WebSphere Application Server profiles, for example: Activities is installed on AppSrv01, Blogs is installed on AppSrv02, and so on), then there is a notification-config.xml file for each component. If you used this type of deployment, you must perform these steps to edit the notification-config.xml file associated with each WebSphere Application Server profile.
    For example:
    • AIX/Linux:
      LCConfigService.checkOutNotificationConfig("/opt/temp","foo01Cell01")
    • Microsoft Windows:
      LCConfigService.checkOutNotificationConfig("c:/temp","foo01Cell01")
  4. From the temporary directory to which you checked out the notification-config.xml file, open it in a text editor.
  5. Find the <config> element with the ID attribute equal to notification-config.
  6. Search for the <source name="<applicationName>" string to find the section of XML markup that defines the notification settings for the application for which you want to enable email notifications.
  7. Change the value of the enabled attribute associated with the email channel element to true. For example:
    <source 
     name="Activities" 
     enabled="true" 
     defaultFollowFrequency="DAILY">
       <type name="notify" notificationType="DIRECTED">
    <type name="notify" notificationType="DIRECTED">
     <channel name="email" enabled="true">
      <property name="sender">blogs-admin@example.com</property>
      <property name="ftl">notify.ftl</property>
     </channel>
     <channel name="event" enabled="true">
      <property name="eventName">blogs.notification.notify</property>
      <property name="transformerClass">com.ibm.lotus.connections.core.notify.channels.event.BlogsNotificationEventTransformer</property>
     </channel>
    </type>
    ...
    </source>
    Note: When you disable notifications during the installation process, all the email channels are set to false. Source events are left at true because notification events are still valid to be sent and displayed in the Home page activity stream. Setting the entire source to false disables all events, which means that notification emails will not be sent and will not display in the My Notifications view in the Home page.
  8. Save and close the notification-config.xml file.
  9. Check in the configuration files using the following command:
    LCConfigService.checkInNotificationConfig("<temp_dir>","<cell-name>")
    Note: If you plan to specify administrator email addresses now, keep the notification-config.xml file checked out; you must edit values in it to complete the next procedure.
What to do next

See Defining valid administrator email addresses for some additional steps that you must take to configure automatic notifications in Activities.

Configuring Forums for email notification replies

Configure Forums so that users can reply to forum topics by email.

When a reply is added to a forum topic, an email is sent to followers of that forum and that topic. After you enable and configure notification replies, users receiving that email can respond by email. The content of that response is added as a new reply in the forum, after the original.

When users reply to notifications, a mail server uses a rule or trigger to direct the reply emails to a mailbox dedicated for this purpose. The IBM Connections server uses a WebSphere Application Server mail session to process this mailbox periodically, adding content to the forums.

For this to work, an administrator must configure the mail server and mail session, and then enable the feature. Users must specify their email settings in IBM Connections. For a user to receive notifications that they can reply to, the Notifications feature must be enabled on the server. The email notification reply feature must also be enabled on the server in the news-config.xml file. Each user who wants to receive email reply notifications must then have the feature enabled on their Settings screen.

Configuring the mail session requires performing some simple steps in the WebSphere Application Server administrative console. Configuring the mail server requires creating the dedicated mailbox, and creating a rule or trigger to direct replies to it. Steps for creating the rule or trigger will vary depending on the mail server. For example, in Microsoft Exchange you create a transport rule; in Domino® you create a trigger.

IBM Connections supports the Simple Mail Transfer Protocol (SMTP) for sending notifications, and the Internet message access protocol (IMAP) and secure Internet message access protocol (IMAPS) for notification replies. Any mail server using these protocols can direct notifications and notification replies. This documentation only provides information on configuring the following mail servers to handle notification replies: IBM Lotus Domino 8.5.2, Microsoft Exchange 2007, and Microsoft Exchange 2010. See Configuring notifications for information on configuring notifications in an installed deployment.

Note: In deployments with multiple IBM Connections servers, the different servers cannot use the same mailbox. However, they can use different mailboxes on the same mail server, in which case each would require its own direction rules.
Configuring WebSphere Application Server for email notification replies

Configure an IBM WebSphere Application Server mail session to connect to a mailbox dedicated to storing email notification replies.

Before you begin
After you have set up your IBM Lotus Domino or Microsoft Exchange server to receive replies, you need to configure the IBM® WebSphere® Application Server mail session parameter to connect to the mailbox dedicated to storing email notification replies. If your environment requires authentication to connect to the mailbox containing the replies, you must use IBM WebSphere Application Server with FixPack 17 or later.
About this task

The steps in this topic are required to configure Forums so that users can reply to forum topics by email. When a reply is added to a forum topic, an email is sent to followers of that forum and that topic. Users receiving that email can respond by email. The content of that response is added as a new reply in the forum, after the original.

A mail server uses a rule or trigger to direct reply emails to a mailbox dedicated for this purpose. The IBM Connections server uses a WebSphere Application Server mail session to process this mailbox periodically, adding content to the forums. This topic documents how to create the mail session.

Note: The ReplyTo mailbox should be different from a Connections user's regular mailbox. It is better to have a mailbox set aside just to handle ReplyTo replies to avoid the risk of having notifications sent to that user being read back in as ReplyTo replies.
Procedure
  1. Open the IBM WebSphere Administrative Console.
  2. Navigate to Resources > Mail > Mail Sessions.
  3. Select a scope, and then create a new mail session with the following properties:
    1. In the Name field type: lcreplyto
    2. In the JNDI name field type: mail/replyto
  4. In the Incoming Mail Properties section set the following properties:
    1. In the Server field, type the name of the mail server where the MailIn mailbox is located.
    2. In the Protocol field, type the name of the protocol the server will use. You must use either IMAP or IMAPS.
    3. In the User field, type the name of a user with access to the mailbox.
    4. In the Password field, type the password the user from Step c.
Configuring Domino for email notification replies

Configure IBM Lotus Domino 8.5.2 to direct email notification replies to a dedicated mailbox.

Before you begin
Install and configure a IBM Lotus Domino 8.5.2 Messaging Server. See the IBM Lotus Domino Messaging Server documentation.
About this task

The steps in this topic are required to configure Forums so that users can reply to forum topics by email. When a reply is added to a forum topic, an email is sent to followers of that forum and that topic. Users receiving that email can respond by email. The content of that response is added as a new reply in the forum, after the original.

A mail server uses a rule or trigger to direct reply emails to a mailbox dedicated for this purpose. The IBM Connections server uses a WebSphere Application Server mail session to process this mailbox periodically, adding content to the forums. This topic documents how to configure a Domino server to direct reply emails to a dedicated mailbox.

Procedure
  1. Open the Domino server and click the Domain tab.
  2. Expand Messaging in the navigator, and then click Configuration.
  3. Select the messaging server and click Edit Configuration.
  4. Click the Router/SMTP tab, then the Restrictions and Controls tab, and then the Rules tab.
  5. Click New Rule and create a rule that moves emails containing lcreplyto_ in the To field to the mailbox, for example:
    When To contains lcreplyto_ move to Database mail\mailin.nsf
    Where mail\mailin.nsf is the location and name of your dedicated email reply mailbox.
  6. Domino moves the emails to the Sent view instead of the Inbox of the mail database. Create a Notes® agent to move the emails from the Sent view to the Inbox.
    1. Open the mail server in Notes.
    2. In the People & Groups tab, expand PeoplebyOrganization.
    3. Edit the account of the user used to direct reply mail.
    4. Click Open Mail File.
    5. Select the View > Agents menu item.
    6. Click New Agent.
    7. Add the following Lotusscript to the agent:
      Note: The following script is only an example to be used for reference, and you will need to change or adjust the script based on your actual environment.
      Sub Initialize
          
          Dim session As New NotesSession
          Dim db As NotesDatabase
          Dim view As NotesView
          Dim doc As NotesDocument
          
          Set db = session.CurrentDatabase
          Set view = db.getView("$Sent")
          
          Set doc = view.GetFirstDocument()
          While Not(doc Is Nothing)
              Call doc.PutInFolder("$inbox")
              Set doc = view.GetNextDocument(doc)
          Wend
          
          
      End Sub
    8. Open the agent properties:
      • In the Options section select Shared.
      • In the Runtime section select On schedule, and then select More than once a day.
      • In the Target field select All new & modified documents.
      • Set a schedule, for example have it run every 5 minutes, all day.
    9. Before running the script ensure you have adequate permissions to run it.
Configuring Exchange for notification replies

Configure Microsoft Exchange 2007 or 2010 to direct email notification replies to a dedicated mailbox.

In environments with Microsoft Exchange, you must create a Transport Rule, on either the Edge Transport server or Hub Transport server, that identifies notification reply emails based on a pattern, and then directs that mail to the dedicated mailbox. For example, you can create a rule that identifies emails in which the To header contains the unique domain name you've appended as a suffix to notification reply email addresses.

Example:
  • Rule type: Transport Rule, on Hub Transport
  • Condition: "when the message header contains text patterns"
  • Sub-condition: message header = "To"
  • Sub-condition: pattern = "lconn.acme.com$" (address ends with lconn.acme.com). Substitute lconn.acme.com with the domain you are using for notification reply emails. See Enabling notification replies for more information.
  • Action: "redirect the message to addresses"
  • Target address: "lconn@acme.com". Substitue lconn@acme.com with the address of the mailbox dedicated to storing notification reply emails.
Note: The domain configured in the news-config.xml file for ReplyTo needs to be an Accepted Domain, which can be configured in the Hub Transport tab of the Exchange console.

For details on creating rules for identifying and directing email, see the Microsoft Exchange documentation.

Enabling notification replies

An administrator must edit settings in the news-config.xml file to allow users to reply to email notifications. Users must specify two preferences.

Before you begin

To edit configuration files, you must use the IBM WebSphere Application Server wsadmin client. See Starting the wsadmin client for details.

About this task

In the news-config.xml file you must enable support for the reply feature, and also provide a special ReplyTo address. If your deployment has a dedicated IBM Connections mail domain, you must provide that as well. If your deployment uses an existing domain, provide either a prefix or suffix to add to the IBM Connections domain.

For users to be able to reply to emails, certain of their IBM Connections settings must be selected. They must click Settings, and then the Email Preferences tab. They must make sure Receive notifications from other people by email and Allow me to reply to notifications by email (this option is only available if mail-in is enabled in the news-config.xml file) are selected. In the Content that I am following section, they must make sure Forums is set to Individual Emails.
Note: Users will not see Allow me to reply to notifications by email until you perform the steps in this topic to enable notification replies.
Procedure

To configure the data synchronization task, complete the following steps.

  1. Start the wsadmin client from the following directory of the system on which you installed the Deployment Manager:
    app_server_root\profiles\dm_profile_root\bin
    where app_server_root is the WebSphere Application Server installation directory and dm_profile_root is the Deployment Manager profile directory, typically dmgr01.

    You must start the client from this directory or subsequent commands that you enter do not execute correctly.

  2. Start the News Jython script interpreter.
    1. Use the following command to access the News configuration file:
      execfile("newsAdmin.py")
      If prompted to specify a service to connect to, type 1 to pick the first node in the list. Most commands can run on any node. If the command writes or reads information to or from a file using a local file path, you must pick the node where the file is stored.
    2. Check out the News cell-level configuration file using the following command:

      NewsCellConfig.checkOutConfig("working_dir", "cellName")

      where:
      • working_dir is the temporary directory to which you want to check out the cell-level configuration file. This directory must exist on the server where you are running wsadmin.
        Note: AIX and Linux only: The directory must grant write permissions or the command will not run successfully.
      • cellName is the name of the cell that the home page node belongs to. This argument is required. It is also case-sensitive, so type it with care. If you do not know the cell name, type the following command in the wsadmin command processor to determine it:

        print AdminControl.getCell()

      For example:
      NewsCellConfig.checkOutConfig("d:/temp", "NewsServerNode01Cell")
      The command displays this message:
      News Cell Level configuration file successfully checked out.
  3. Open news-config.xml in a text editor.
  4. Locate the section containing the mailin element:
    	<!-- These settings control the Mail-In feature, which provides support
    for replying to certain notifications to add responses / comments. -->
    
    	<mailin enabled="true">
    	    <replyto enabled="true">
    	    
    	    	<!-- A special ReplyTo address is added to notifications where
    				 the user can reply to the notification to respond/comment.
    				 The domain may be a dedicated domain for connections bound
    				 mails. Or it could be existing domain, in which case a prefix
    				 of suffix should be provided also. -->
    
    	        <replytoAddressFormat>
    	            <domain>enterprise.com</domain>
    
    	            <!-- A prefix OR suffix (not both) may also be provided. 
    						This is necessary if an existing domain (with other 
    						email addresses) is being used.
    						There is a 28 character limit for the affix. -->
    
    	            <!--  
    	            	<affix type="suffix">_lcreplyto</affix>
    					-->
    
    	        <affix type="prefix">lcreplyto_</affix>
    	            
    	        </replytoAddressFormat>
    	    </replyto>
    	</mailin>
    • Specify the mailin.enabled and replyto.enabled attributes as "true."
    • Specify your email server domain in the replytoAddressFormat.domain element. The example shown is enterprise.com.
    • If you use an existing, non-dedicated domain that contains other email addresses, specify either a suffix or prefix to be added to the domain in the address. The examples shown are _lcreplyto and lcreplyto_.
  5. After making changes, you must check the configuration files back in, and you must do so during the same wsadmin session in which you checked them out for the changes to take effect. See Applying property changes in the News repository for information about how to save and apply your changes.
Results
ReplyTo can be turned on or off by Connections users if the default setting <replyToEnabled>true</replyToEnabled> is specified in notification-config.xml. Refer to Enabling email notifications for instructions on modifying notification-config.xml.
Defining valid administrator email addresses

Edit configuration property settings to change the default email addresses from which system notifications, such as a request to join a community, are sent. Notifications are sent from generic administrator email addresses if you do not take action. Default email addresses are initially set during installation, so use this procedure only if you want to change them.

Before you begin
By default, automatic notifications are sent from a generic email address, such as blogs-admin@example.com. Edit the property to change this to a legitimate administrator email address that has access rights to send mail. Some of the notification messages sent automatically, such as the notifications used to handle blog postings that are flagged for containing inappropriate content, inform recipients that they can respond to the default administrative user email address from which the notification was sent. If you do not edit the default email address, recipients get a delivery failure notification when they try to respond to the automatic email.
Note:
  • If you plan to prevent user email addresses from being displayed in the product, define a valid email address for the global administrator. When you hide emails, this global administrator address is specified as the sender even in emails generated by user actions that would normally specify that user as the sender. The global sender email address is only used if you configure IBM Connections to prevent emails from being displayed.
  • If you provide additional administrator email addresses for the different types of notifications, those settings take precedence over the global address. If you want the global administrator address to be used for a specific notification, comment out the sender property currently specified for that notification type. For example:
    <!--<property name="sender">files_admin@example.com</property>-->
About this task
You can edit the following administrator email addresses:
  • Global sender. Change the default email address of the global sender into one with the correct domain for your enterprise and a name that your users will recognize and trust.
  • Specific notification types. Edit the administrator addresses used when different types of notifications are sent.
If you want to change default email addresses from what you assigned in install, complete the following steps:
Procedure
  1. Start the wsadmin client from the following directory of the system on which you installed the deployment manager:
    app_server_root\profiles\dm_profile_root\bin
    Note: You must start the client from this directory or subsequent commands that you try to run will not execute properly. See Starting the wsadmin client for more details.
  2. Use the following command to access the IBM Connections configuration files:
    execfile("connectionsConfig.py")

    If prompted to specify a service to connect to, type 1 to pick the first node in the list. Most commands can run on any node. If the command writes or reads information to or from a file using a local file path, you must pick the node where the file is stored. This information is not used by the wsadmin client when you are making configuration changes.

  3. Check out the notification-config.xml file using the following command:
    LCConfigService.checkOutNotificationConfig("temp_dir","cell_name")
    where temp_dir is a temporary directory and cell_name is the WebSphere Application Server cell to which you installed Activities. When you specify a path to the working directory on a system running Microsoft Windows, use a forward slash for the directory. For example: "C:/temp".
    Note: AIX and Linux only: The directory you specify as the temporary directory must grant write permissions.
  4. From the temporary directory to which you checked out the notification-config.xml file, open it in a text editor.
  5. Specify a valid internet-style email address containing no spaces for the global sender by editing the globalSenderEmailAddress property in the following section of the notification-config.xml file:
    <properties>
      <property name="globalSenderName">IBM Connections Administrator</property>
      <property name="globalSenderEmailAddress">global-admin@example.com</property> 
    </properties>
  6. Optional: If you want to force the email address that you specify in the globalSenderEmailAddress to be used as the sender of all notifications, add the following property to the <properties> element previously listed, and set it equal to true.
    <property name="alwaysUseGlobalSender">true</property>
  7. Optional: By default, the email address of the original sender is set as the reply-to address. If you do not want the original sender to appear as the reply-to address, then add the following property to the <properties> element previously listed, and set it equal to false.
    <property name="includeOriginalSenderAsReplyTo">false</property>

    If the alwaysUseGlobalSender property is set to false, then the includeOriginalSenderAsReplyTo property is ignored. If the alwaysUseGlobalSender property is set to true, then the includeOriginalSenderAsReplyTo is optional. The default value for this property is true if the property is added, but no value is defined for it.

  8. Optional: To specify different administrator email addresses for different notifications types per application, search for the notification types you want to change, and then change the value of the sender properties. If there is no sender property, add one.
    Note: If a type element is present, the email address specified for it is used instead of the global administrator address. If you want the global sender address to be used instead of the address specified here, comment out the associated type element. For example, if you want to change the address from which notifications that inform people that they have been added to an activity are sent, edit the value of the sender property in the following notification type:
    add-member
    For example:
    <type name="add-member">
      <channel name="email" enabled="true">
        <property name="sender">
          activities-admin@example.com
        </property>
        <property name="ftl">
    			addMemberMail.ftl
        </property>
      </channel>
     </type>
    Note: No notifications are sent from the Home page application.
  9. Save and close the notification-config.xml file.
  10. Check in the configuration files using the following command:
    LCConfigService.checkInNotificationConfig("<temp_dir>","<cell-name>")
Enabling users to specify email notification preferences

Edit configuration settings to enable users to specify the email address to which they would like notifications sent, the frequency with which they receive notifications, and what language the notification is written in.

Before you begin
Email notifications must be enabled in IBM Connections for this procedure to have any effect. If you have configured IBM Connections to hide email addresses, you might not want to enable email notifications.
About this task

When you enable users to specify email preferences, a Settings link is available from the product header that users can click to define their email preferences. Otherwise, no user interface settings are made visible to users.

The following preferences are set by default:
Table 27. Default email preference settings
Preference Default setting
Responses and notifications Individual emails
Activities Daily newsletter
Blogs Weekly newsletter
Bookmarks Weekly newsletter
Communities Daily newsletter
Files Individual emails
Forums Daily newsletter
People Weekly newsletter
Tags Weekly newsletter
Wikis Daily newsletter
Procedure
  1. Start the wsadmin client from the following directory of the system on which you installed the deployment manager:
    app_server_root\profiles\dm_profile_root\bin
    Note: You must start the client from this directory or subsequent commands that you try to run will not execute properly. See Starting the wsadmin client for more details.
  2. Enter the following command to access the IBM Connections configuration files:
    execfile("connectionsConfig.py")

    If prompted to specify a service to connect to, type 1 to pick the first node in the list. Most commands can run on any node. If the command writes or reads information to or from a file using a local file path, you must pick the node where the file is stored. This information is not used by the wsadmin client when you are making configuration changes.

  3. Enter the following command to check out the notification-config.xml file:
    LCConfigService.checkOutNotificationConfig("temp_dir","cell_name")
    where
    • temp_dir is the temporary directory to which the configuration XML and XSD files are copied and are stored while you make changes to them. Use forward slashes to separate directories in the file path, even if you are using the Microsoft Windows operating system.
    • cell_name is the WebSphere Application Server cell to which you installed the application for which you are enabling mail. This argument is case-sensitive, so type it with care.
    Note: If you installed IBM Connections into multiple WebSphere Application Server profiles, for example: Activities is installed on AppSrv01, Blogs is installed on AppSrv02, and so on), then there is a notification-config.xml file for each application. If you used this type of deployment, you must perform these steps to edit the notification-config.xml file associated with each WebSphere Application Server profile.
    For example:
    • AIX or Linux:
      LCConfigService.checkOutNotificationConfig("/opt/temp","foo01Cell01")
    • Microsoft Windows:
      LCConfigService.checkOutNotificationConfig("c:/temp","foo01Cell01")
  4. From the temporary directory to which you checked out the notification-config.xml file, open it in a text editor.
  5. Make any of the following changes that you want to the <defaultEmailPreferences> element:
    • To allow users to specify a preferred email address for notifications, change the value of the <allowEmailAddressOverride> element to true. For example:
      <defaultEmailPreferences>
       <allowEmailAddressOverride>true</allowEmailAddressOverride>
        ... 
      </defaultEmailPreferences>
    • Specify whether automatic email notifications that result from one user notifying another or that are sent from the system should be sent to the person in email. If users do not receive the notification in email, they can still view the notifications from the Home page application. To prevent notifications from being sent by email, set <sendEmailsForDirectNotifications> to false.
    • Define the language in which notifications should be written:
      • If you want emails to be displayed in the language that corresponds to the locale that was set in the browser the last time the user accessed the application from the web, then set <useLanguageFromCallingComponent> to true.
      • If you want to define a default language to use for all notification messages all of the time, set <useLanguageFromCallingComponent> to false and specify the language code of the language in the <defaultLanguage> element.
      Users can change these settings from the product user interface; you are just defining the default values here.
      Note: The list of languages present in the Settings page represents the languages that are enabled for the product, which is defined in the <languageSelector> element in the LotusConnections-config.xml file. For more details, see Enabling users to set a language preference.
    • Edit the following elements:
      <defaultResponsesFrequency>
      Specifies the frequency with which users receive notifications about responses to their postings.
      Valid values include:
      • DAILY: Send a notification email with a list of notifications once a day.
      • INDIVIDUAL: Send an email each time a notification is produced.
      • NONE: Do not send any notifications by email.
      • WEEKLY: Send a notification email with a list of notifications once a week.
      Users can change this setting from the product user interface; you are just defining the default values here.
      <defaultTagFollowFrequency>
      Specifies the frequency with which users receive notifications about tags that they are following.
      Valid values include:
      • DAILY: Send a notification email with a list of notifications once a day.
      • INDIVIDUAL: Send an email each time a notification is produced.
      • NONE: Do not send any notifications by email.
      • WEEKLY: Send a notification email with a list of notifications once a week.
      Users can change this setting from the product user interface; you are just defining the default values here.
      <digestItemsPerCategory>10</digestItemsPerCategory>
      Defines the number of items that display within a category of the daily or weekly digest. The allowable range is 5-25. The default value is 10. This setting is applied globally and cannot be configured per user.
      <replyToEnabled>true</replyToEnabled>
      When set to true, users receive emails with replyTo support. This option is displayed on the Email Settings page for each user. The default value is true.
    For example:
    <defaultEmailPreferences>
      <allowEmailAddressOverride>true</allowEmailAddressOverride>
      <useLanguageFromCallingComponent>false</useLanguageFromCallingComponent>
      <defaultLanguage>es</defaultLanguage>
      <sendEmailsForDirectNotifications>true</sendEmailsForDirectNotifications>
      <defaultResponsesFrequency>INDIVIDUAL</defaultResponsesFrequency>
      <defaultTagFollowFrequency>WEEKLY</defaultTagFollowFrequency>
      <digestItemsPerCategory>10</digestItemsPerCategory>
      <replyToEnabled>true</replyToEnabled>
    </defaultEmailPreferences>
  6. For each application, you can also specify the frequency with which users should receive notifications about content that they are following by editing the defaultFollowFrequency attribute for that application. For example, to define the frequency with which users should receive notifications about content they are following in the Activities application, edit the source element for Activities as follows:
    <source 
     defaultFollowFrequency="DAILY" 
     enabled="true" 
     name="Activities">
  7. Save and close the notification-config.xml file.
  8. Check in the configuration files using the following command:
    LCConfigService.checkInNotificationConfig("<temp_dir>","<cell-name>")
  9. Update the version stamp property to force a refresh of users' web browsers, so that they see the email preference changes the next time they access the product. See Required post-customization step.
Disabling embedded applications in notifications

Standard notifications sent from IBM Connections can include an OpenSocial embedded application that is displayed in supported email clients. You can remove embedded applications from all supporting notifications by disabling a configuration property in the notification-config.xml file.

Before you begin

To run administrative commands, you must use the wsadmin client. See Starting the wsadmin client for details.

About this task
The notification types listed in the following table include the application/embed+json MIME part that is required for embedded application support. All other notifications support HTML and plain text versions only.
Table 28. Notification types that support embedded applications
Application/Embedded application Operation
Files (specific to a file)
  • Create a file
  • Update a file
  • Comment on a file
  • Like a file
  • Share a file
Blog entries
  • Create a blog entry
  • Update a blog entry
  • Comment on a blog entry
  • Like a blog entry
Ideation Blog entries
  • Create an ideation blog idea
  • Update an ideation blog idea
  • Comment on an ideation blog idea
Forum topics
  • Create a forum topic
  • Update a forum topic
  • Reply to a forum topic
Status updates
  • Post a status update
  • Comment on a status update
  • Like a status update
  • Repost a status update
Network invites
  • Send a network invitation
Note: Embedded applications are only included in standard notifications; users must select the individual email option available from the Email Preferences page to receive them.
Procedure
  1. Start the wsadmin client from the following directory of the system on which you installed the deployment manager:
    app_server_root\profiles\dm_profile_root\bin
    Note: You must start the client from this directory or subsequent commands that you try to run will not execute properly. See Starting the wsadmin client for more details.
  2. Enter the following command to access the IBM Connections configuration files:
    execfile("connectionsConfig.py")

    If prompted to specify a service to connect to, type 1 to pick the first node in the list. Most commands can run on any node. If the command writes or reads information to or from a file using a local file path, you must pick the node where the file is stored. This information is not used by the wsadmin client when you are making configuration changes.

  3. Enter the following command to check out the notification-config.xml file:
    LCConfigService.checkOutNotificationConfig("temp_dir","cell_name")
    where
    • temp_dir is the temporary directory to which the configuration XML and XSD files are copied and are stored while you make changes to them. Use forward slashes to separate directories in the file path, even if you are using the Microsoft Windows operating system.
    • cell_name is the WebSphere Application Server cell to which you installed the application for which you are enabling mail. This argument is case-sensitive, so type it with care.
    Note: If you installed IBM Connections into multiple WebSphere Application Server profiles, for example: Activities is installed on AppSrv01, Blogs is installed on AppSrv02, and so on), then there is a notification-config.xml file for each application. If you used this type of deployment, you must perform these steps to edit the notification-config.xml file associated with each WebSphere Application Server profile.
    For example:
    • AIX or Linux:
      LCConfigService.checkOutNotificationConfig("/opt/temp","foo01Cell01")
    • Microsoft Windows:
      LCConfigService.checkOutNotificationConfig("c:/temp","foo01Cell01")
  4. From the temporary directory to which you checked out the notification-config.xml file, open it in a text editor.
  5. Locate the following section of the file:
    <properties>
      <property name="globalSenderName">IBM Connections Administrator</property>
      <property name="globalSenderEmailAddress">global-admin@example.com</property>
      <includeMobileLinksInNotifications>false</includeMobileLinksInNotifications>
      <disableEmbeddedAppsInNotifications>false</disableEmbeddedAppsInNotifications>
    </properties>
  6. Change the value of the <disableEmbeddedAppsInNotifications> element to true as follows:
    <disableEmbeddedAppsInNotifications>true</disableEmbeddedAppsInNotifications>
    The default value is false.
  7. Save and close the notification-config.xml file.
  8. Check in the configuration files using the following command:
    LCConfigService.checkInNotificationConfig("<temp_dir>","<cell-name>")

Removing nodes from a cluster

You can remove IBM WebSphere Administration Server nodes from a cluster using the Integrated Solutions Console or using a command.

Removing nodes from a cluster using the Integrated Solutions Console

You can remove nodes from a cluster using the IBM WebSphere Application Server Integrated Solutions Console.

Procedure

To remove a node from a cluster, complete the following steps:

  1. From the Integrated Solutions Console, select System Administration > Nodes.
  2. Select the check box next to the node that you want to delete and click Remove Node.
    Note: If you cannot remove the node by clicking Remove Node, remove the node from the configuration by clicking Force Delete.
  3. Restart WebSphere Application Server.
Removing nodes from a cluster from the command line

Use the removeNode command to remove an IBM WebSphere Application Server node from a Network Deployment distributed administration cell.

Before you begin
For additional information about the removeNode command, refer to the following web page:
http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/index.jsp?topic=%2Fcom.ibm.websphere.nd.multiplatform.doc%2Finfo%2Fae%2Fae%2Frxml_removenode.html
Procedure

To remove a node from a cluster, complete the following steps:

  1. Log in to the node that you want to remove from the cluster.
  2. Open a command prompt and change to the profile_root/bin directory.
  3. Run one of the following scripts to remove the node:
    • AIX or Linux:

      ./removenode.sh

      [-username uid] [-password pwd]

    • Windows:

      removenode.bat

      [-username uid] [-password pwd]

    where:
    • uid is the Deployment Manager administrator user name
    • pwd is the Deployment Manager administrator password

Backing up and restoring data

You must back up both the application databases and content stores on a regular schedule using the methods documented by the vendor from whom you purchased the database and file system you are using.

Note: When you restore data for an application that is also available from the Communities application, you must also restore the data in the Communities application to keep the two in sync. See Recovering from a database failure for more details.

Managing content

Use superusers, moderation, and other methods to manage IBM Connections content.

Administering application content

To view and control content in your deployment, you can create a dedicated global administrator or administrators with administrative capabilities over content in the applications.

A global administrator can edit and remove objectionable content. The Moderation feature can assist in this process, but not all components have the Moderation implemented. Also, although some wsadmin commands can be helpful with removing objectionable content, they do not cover all situations. For example, in the event that someone who is the only Owner of some content (such as the only owner of an activity or community) and that person leaves the organization or is out of office for an extended time period, the Global Administrator could add additional owners and even remove the original owner if needed.

Table 29. Summary of administrative capabilities for Connections applications.

IBM strongly recommends creating a new user account solely for these administrative purposes. This is especially true for administrators in Activities. Adding administrative abilities to your own account in other applications can result in confusion and can lead to accidental modification of data. Also recommended is that the same person (or multiple people) be given an admin role across all components, rather than assigning the admin role to someone different for each component, particularly for Communities, which might have widgets added from multiple components.

Application Administrative capabilities Steps

Activities

  • Access any activity returned by search
  • Open any activity using a URL address
  • Modify any activity
  • Delete any activity in Trash
  • See private entries. They cannot change privacy settings.
To view and control Activities content:
  1. Find or create a user who will be dedicated to this purpose.
  2. Add the user to the Activities J2EE admin role. See Roles.

Blogs and Ideation Blogs

  • Configure administration settings
  • Edit any blog or blog entry
  • Delete any blog, entry, or comment
To view and control Blogs and Ideation Blogs content:
  1. Find or create a user who will be dedicated to this purpose.
  2. Add the user to the Blogs J2EE admin role. See Roles.

When the user logs into Blogs or Ideation Blogs they will see an Administration tab where they can configure administration settings.

Bookmarks

  • Remove unwanted links

There is no way to create a comparable administrator for Bookmarks. However, adding a user to the J2EE search-admin role allows that user to see any bookmark in Bookmark search results. Any administrator can use the Bookmarks wsadmin commands to remove unwanted links from the Bookmarks application.

Communities

  • Access to any community, public or restricted
  • Rights to view and update community settings, members, invitations, bookmarks and feeds
  • With some extra configuration, rights to access and edit content in remote application widgets
  • Users with this role will see an additional Administration link that will allow them to administer the Community Catalog.

To view and control Communities content, follow steps in Administering Communities content.

Files

  • Editor access on all files
To view and control Files content:
  1. Find or create a user who will be dedicated to this purpose.
  2. Add the user to the Files J2EE admin role. See Roles.

Forums

  • Edit, update, or delete any forum, forum topic, or reply
To view and control Forums content:
  1. Find or create a user who will be dedicated to this purpose.
  2. Add the user to the Forums J2EE admin role. See Roles.

Home page

  • Administer site-wide settings for the Home page from the Home page administration user interface or using the wsadmin client
  • Add custom widgets for use on the Home page
  • Enable and disable widgets
  • Enable and disable the My Page view

Users with the Home page administrator role have access to an additional Administration view on their Home page. When you are assigned this role, you can see an Administration option in the navigation sidebar, under the My Page option. Select this option to access a simple, form-based user interface that allows you to perform key tasks.

News

Events are generated by the various IBM Connections applications whenever an activity occurs in the system. Information about these events is stored in the News repository, and the Home page application pulls data from the repository to display only the events that are relevant to a particular user on that user's Home page. You can configure News configuration settings to control how the information that the Home page receives from the News repository is stored and administered.

The administrators are the users mapped in the admin J2EE role in the News application.

  • Register a new application or source type so that it displays in the IBM Connections user interface.
  • Update, enable, or disable an application registration.
  • Check out/check in News repository configuration files.
  • Remove single or multiple reply-to IDs.
  • Remove all microblog and associated data for a community from the News repository.
  • Synchronize news data with other applications.
  • Return an XML synchronization report of the community resources held in the News repository.
  • Return information about a scheduled task.
  • Delete any status update and comment on status updates in the system, including community status updates.
  • Create a status update in any community.
  • Change the status update settings in any community.
  • View the Activity Stream feed from any community

View and control News content using scripts accessed using the wsadmin client as detailed in the Administering the News repository section.

Profiles

  • Delete photos
  • Edit user About Me and Background information
  • Activate or deactivate any profile
  • Edit core user attributes
To view and control Profiles content:
  1. Find or create a user who will be dedicated to this purpose.
  2. Add the user to the Profiles J2EE admin role. See Roles.

You must use wsadmin commands to delete photos, edit About Me and Background information, and activate or inactivate any profile. See Profiles administrative commands.

Use the Profiles REST ATOM API to edit core user attributes. See Profiles Administration API. Attributes you cannot edit are link roles, friends, tags, and the following and follower lists. To edit those attributes you must use direct SQL.

Search

Search in any application returns all content. For example, a search in Communities will return private communities even if you are not a member.

To have search return all content:
  1. Find or create a user who will be dedicated to this purpose.
  2. Add the user to the Search J2EE search-admin role. See Roles.

Wikis

  • Search returns all content
  • Create, edit, read, and delete any content
  • Remove a wiki creator from wiki membership
To view and control Wikis content:
  1. Find or create a user who will be dedicated to this purpose.
  2. Add the user to the Wikis J2EE admin role. See Roles.
Note: Once a user creates a wiki, they are the owner of that wiki. An administrator can add new owners to the wiki, but the creator of the wiki cannot be removed from the membership. Direct SQL manipulation on the database is required to reassign the creator and remove them from the membership.
Administering community content

You can create a dedicated administrator with access to all communities, public or restricted. This administrator has granular control over communities content, including the ability to edit or remove inappropriate content. This administrator is also required for IBM Lotus Sametime integration with IBM Connections.

About this task

Global communities administrators can access all communities with rights to view and update community settings, members, invitations, bookmarks and feeds; however, within restricted communities the global administrator cannot view and manage remote widget applications, such as Activities, Blogs, Ideation Blogs, Files, Forums, and Wikis. To manage content in remote widget applications, you add the communities global administrator to the J2EE admin role for all of these applications. See Assigning people to J2EE roles for detailed information. After communities global administrator is in the admin role for those applications, she can manage content in any of them, whether the applications are standalone or remote widgets in a community.

You can use search to find private communities, but you must add the global administrator to the search-admin role of the Search application. Use the Public Communities view to find public and moderated communities.

Note: Global administrators cannot add or remove widgets from communities by default. They must log into the community as the global administrator, and then add themselves as a community member with Owner access.
Note: The global administrator role is not supported on mobile devices. Global administrators must use a supported browser.
Procedure
  1. Find or create a user who will be dedicated to administering content, and add them to the J2EE admin role of Communities, Activities, Blogs, Files, Forums, and Wikis. Also add them to the search-admin role of Search. See Roles. In the following steps, we will ensure that the communities-config.xml file contains the "admin" block of grant statements and is not commented out.
  2. Start the wsadmin client by completing the following steps:
    1. Open a command prompt, and then change to the following directory of the system on which you installed the deployment manager:
      app_server_root\profiles\dm_profile_root\bin
      where app_server_root is the WebSphere Application Server installation directory and dm_profile_root is the Deployment Manager profile directory, typically dmgr01. For example, on Windows:
      C:\Program Files\IBM\WebSphere\AppServer\profiles\Dmgr01\bin
      Attention: You must run the following command to start the wsadmin client from this specific directory because the Jython 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 does not work correctly.
    2. Enter the following command to start the wsadmin client:
      • AIX or 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 a person in the Administrator role on the IBM WebSphere Application Server.
      • admin_password is the password of the WebSphere Application Server administrator.
      • SOAP_CONNECTOR_ADDRESS Port is the SOAP port for the WebSphere Application Server deployment manager server. 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 WebSphere Application Server Integrated Solution Console. To look up the SOAP port number, perform the following steps:
        1. Open the WebSphere Application Server Integrated Solution Console for the deployment manager, and then select System Administration > Deployment Manager.
        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 or Linux:
        ./wsadmin.sh -lang jython -username primaryAdmin -password p@assword -port 8879
      • Microsoft Windows:
        wsadmin -lang jython -username primaryAdmin -password p@assword -port 8879
  3. Access and check out the Communities configuration files:
    1. Use the following command to access the Communities configuration files:
      execfile("communitiesAdmin.py")
      If prompted to specify a service to connect to, type 1 to pick the first node in the list. Most commands can run on any node. If the command writes or reads information to or from a file using a local file path, you must pick the node where the file is stored.
    2. Check out the Communities configuration files using the following command:
      CommunitiesConfigService.checkOutPolicyConfig("working_directory", "cell_name")
      where:
      • working_directory is the temporary working directory to which the configuration XML and XSD files are copied. The files are kept in this working directory while you make changes to them.
        Note: AIX and Linux only: The directory must grant write permissions or the command will not run successfully.
      • cell_name is the name of the WebSphere Application Server cell hosting the IBM Connections application. This argument is required. If you do not know the cell name, you can determine it by typing the following command in the wsadmin command processor:
        print AdminControl.getCell()
      For example:
      CommunitiesConfigService.checkOutPolicyConfig("/opt/my_temp_dir", "CommServerNode01Cell")
  4. From the temporary directory to which you just checked out the IBM Connections configuration files, open the communities-policy.xml file in a text editor.
  5. Make sure the file contains the following grant statement, and that it is not "commented out" (disabled).
    <comm:grant>
    	<comm:principal class="com.ibm.tango.auth.principal.Role" name="admin" />
    	<comm:permission class="com.ibm.tango.auth.permission.CommunityManagementPermission" communityType="*" action="*" />
    	<comm:permission class="com.ibm.tango.auth.permission.CommunityMembershipPermission" communityType="*" action="*" />
    	<comm:permission class="com.ibm.tango.auth.permission.CommunityAccessPermission" communityType="*" action="*" />
    	<comm:permission class="com.ibm.tango.auth.permission.CommunityReferencePermission" communityType="*" action="*" />
    	<comm:permission class="com.ibm.tango.auth.permission.CommunityBroadcastPermission" communityType="*" action="*" />
    	<comm:permission class="com.ibm.tango.auth.permission.CommunityInvitePermission" communityType="*" action="*" />
    </comm:grant>
  6. Save your changes to the communities-policy.xml file.
  7. Check in the updated file using the following wsadmin client command:
    CommunitiesConfigService.checkInPolicyConfig("<working_directory>", "<cell_name>")
  8. To exit the wsadmin client, type exit at the prompt.
  9. Stop and restart the server hosting the Communities application.
Results
When the global administrator specified in the various J2EE roles logs in to Communities, she should be able to view and edit all communities and community resources.

Moderation overview

Find out what level of content moderation is available for the applications in version 3 and version 3.0.1.

If the moderation application is installed and enabled, you can define a person or set of people who will review and approve the content that users add to certain applications before it is published or review and act on content that has been flagged as problematic.

Moderation can be configured to make moderation available for global moderators, community owners or blog owners, as follows:
Global moderators
User assigned the global-moderator J2EE role for the Moderation component can review and manage content for blogs, forums, and community files from the global moderation interface, which is accessed using the Moderation link in the application menu bar. The link is only visible to users who have been assigned the J2EE global-moderator role. For more information about assigning roles, see Roles.
Community moderators
When owner moderation is enabled for communities, community owners can access moderation options for their community by opening the community and selecting Community Actions > Moderate Community. Community moderators can only manage the content of communities that they own, and they can only do so from the community moderation interface; they cannot access the global moderation interface.

You can specify whether owner moderation is enabled by changing the value of the ownerModerate setting in the contentreview-config.xml file. For more information, see Managing content moderation and flagged content.

Blogs moderators
If the Moderation service is enabled, you can moderate Blogs from the central moderation interface. If the Moderation service is not enabled, you can moderate Blogs from a moderation interface available from the Blogs application. When owner moderation is enabled for Blogs, blog owners can access moderation options for a blog they own by opening the blog and choosing the Moderation tab. If moderation is enabled for a blog, the blog owner can review content before it is posted to a blog. In addition, users of the Blogs application have the options to flag content as inappropriate. When content is flagged, the moderator is informed and can take action from the moderation interface.

In addition to the user interfaces available for moderation, there is a public moderation API that can be leveraged by third-party developers to extend the capabilities of content moderation.

Moderation roles

Monitor and control the content of blogs, community files, and forums using the moderation tools.

As the IBM Connections administrator, you can do the following to enable and configure moderation:
  • Enable or disable moderation for content before it is published and after it is published.
  • Assign the Global-Moderator role to users so they can moderate all content from a central UI.
  • Set up categories and route which moderators see what flagged content.
  • Enable owner moderation for blogs, forums, or community files so that owners can publish their content directly to a blog, forum, or community file and moderate content for the blogs, forums, or community files they own.
When moderation is enabled, users can:
  • Flag published blog or forum posts or community files that are inappropriate
  • Submit content for review.
  • Blog and forum users can edit their own published content.
  • In addition, Blog owners can view their own submitted, rejected, or published content.
Users you have assigned the Global-Moderator role can:
  • Approve, reject or delete submitted content.
  • Dismiss, quarantine or delete flagged content and restore quarantined content.
  • Provide an explanation to the author when rejecting submitted content, dismissing or quarantining flagged content, or when restoring quarantined content.
  • View and directly edit submitted content or comments

When owner moderation is enabled, blog, forum, or community owners can manage the content in the blog, forum, or community files they own.

Moderated content states

When content is moderated, it can be in a variety of states before and after being published.

The state that content is in dictates where it is in the pre-moderation or post-moderation workflow and controls whether the content is available to users or unavailable because it has not been approved or is in quarantine.

Content states before publication

Content that requires review and approval before it is published can be in one of the following states:

  • Pending: The moderator can approve or reject the content.
  • Active: Content is published
  • Rejected: Content will not be published.
Content states after publication

Content that has already been published but requires review, for example, if it was flagged as inappropriate, can be in one of the following states:

  • Active with flags: The content is published but it may be flagged for review. The moderator can dismiss flags or quarantine the content.
  • Active: The content is published.
  • Quarantined : the content is quarantined and notification is sent to the author
Managing content moderation and flagged content

Edit configuration property settings in the contentreview-config.xml file to enable moderation and to specify what moderators should receive email notification when content requires moderation. Restart your applications to see the changes.

Before you begin

To edit configuration files, you must use the wsadmin client. See Starting the wsadmin client for details.

Configure IBM Connections using scripts accessed with the wsadmin client. These scripts use the connectionsConfig object available in WebSphere Application Server wsadmin client to interact with the IBM Connections configuration file, which is named contentreview-config.xml.

The properties in the contentreview-config.xml file cannot be edited using the updateConfig command nor displayed using the showConfig command. Instead, you must check out the configuration file using the checkOutContentConfig command, and then edit the property values by opening the checked out property file from the temporary directory using a text editor. After editing the property file, save the file in Unicode format and check the file back in using the checkInContentConfig command and restart the application servers to see the changes.

About this task
If moderation is enabled, moderators can review and approve blog comments and entries, forum posts, and community files from a central location. You can configure who can review and approve content with a setting in the contentreview-config.xml file as follows:
  • If ownerModerate=true in contentreview-config.xml, a blog, forum, or community owner can moderate content for a blog, forum, or community they own. In addition, content an owner creates is published directly, without requiring moderation.
  • If ownerModerate=false in contentreview-config.xml, only users assigned the J2EE moderator role in the WAS console can manage content on the site. For information on assigning users to the moderator role, see the topic Roles.

You can also configure the flag inappropriate content application for Blogs and Forums to specify categories for what type of content to flag, and to specify designated reviewers who will receive email notifications when content is flagged. There are two default categories for inappropriate content: Legal issue and Human resources issue. You can edit those categories, add new ones, or remove all categories. The file is also configured with placeholders for the email addresses of designated reviewers. Change those to actual email addresses for users assigned the moderator role who can review flagged content.

Note: When you enable moderation, users cannot upload thumbnail images in Media Gallery widgets.

To change moderation configuration settings, complete the following steps:

Procedure
  1. Start the wsadmin client from the following directory of the system on which you installed the deployment manager:
    app_server_root\profiles\dm_profile_root\bin
    where app_server_root is the WebSphere Application Server installation directory and dm_profile_root is the Deployment Manager profile directory, typically dmgr01. For example, on Windows:
    C:\Program Files\IBM\WebSphere\AppServer\profiles\Dmgr01\bin
    Attention: You must run the following command to start the wsadmin client from this specific directory because the Jython 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 does not work correctly. See the topic Starting the wsadmin client.
  2. Use the wsadmin client to access and check out the IBM Connections configuration file:
    1. Access the IBM Connections configuration file using the following command:
      execfile("connectionsConfig.py")

      If prompted to specify a service to connect to, type 1 to pick the first node in the list. Most commands can run on any node. If the command writes or reads information to or from a file using a local file path, you must pick the node where the file is stored. This information is not used by the wsadmin client when you are making configuration changes.

    2. Check out the IBM Connections content configuration file using the following command:
      LCConfigService.checkOutContentReviewConfig("working_directory","cell_name")
      where:
      • working_directory is the temporary working directory to which the configuration XML and XSD files are copied and are stored while you make changes to them. Use forward slashes to separate directories in the file path, even if you are using the Microsoft Windows operating system.
      • cell_name is the name of the WebSphere Application Server cell hosting the IBM Connections application. This argument is case-sensitive, so type it with care. If you do not know the cell name, type the following command while in the wsadmin command processor:
        print AdminControl.getCell()
      For example:
      • AIX/Linux:
        LCConfigService.checkOutContentReviewConfig("/opt/temp","foo01Cell01")
      • Microsoft Windows:
        LCConfigService.checkOutContentReviewConfig("c:/temp","foo01Cell01")
  3. From the temporary directory to which you just checked out the IBM Connections configuration files, open the contentreview-config.xml file in a Unicode text editor.
    Note: Editing the file using a standard text editor that does not support Unicode could corrupt the file.
  4. To configure settings for managing content in the pre-moderated state, that is, before it is published or when it is updated, set the following options for each application:
    contentApproval
    Set to "true" to require moderation for the specified application. By default this is set to "false". When the setting is set to false, moderation is not automatically enforced for an application, but moderation API command and filters still work. Moderators can still perform moderation tasks.
    ownerModerate
    Set to "true" to specify that blog owners and community owners can moderate content in blogs or communities they own. By default this is set to "false" so that only users assigned the J2EE moderator role in the WAS console can moderate content. For information on assigning users to the moderator role, see the topic Roles.
    In the following example, moderation is enforced for blogs so that all content must be approved by a moderator before it is published or updated in a blog. Each blog owner can moderate content for the blogs they own.
    <serviceConfiguration>
    <service id="blogs">
    <contentApproval enabled="true">
      <ownerModerate enabled="true" /> 
      </contentApproval>
  5. To configure settings for managing content in the post-moderated state, that is, content that is flagged by a user after it is published. set the following options for each application:
    contentFlagging
    Set to "true" to require moderation for flagged content. By default this is set to "false". When the setting is set to false, this means the end user can't flag content from the user interface or using an API command. Blogs Moderation API and filters will still work. Moderators can still perform moderation tasks. Files and Forums API commands will return errors.
    ownerModerate
    Set to "true" to specify that forum users can moderate their own flagged content. By default this is set to "false" so that only users assigned the J2EE moderator role in the WAS console can moderate. For information on assigning users to the moderator role, see the topic Roles.
    IssueCategorization
    Set to "true" to display a list of categories so that users can choose one when flagging content. By default this is set to "false."
    Note: This feature is not available for Files.
    automaticQuarantine
    Forums only. Set to "true" and specify an integer as a value for threshold. When a forum post is flagged the number of times specified for the threshold value, the post is automatically quarantined and removed from the forum. By default this is set to "false."
    flagCategory
    To make a <flagCategory> element available for an application, first define it with a unique id and descriptions in the desired languages to the <flaggedCategories> section of the configuration file, then add it to the <IssueCategorization> section for the application.
    reviewer email
    To add designated reviewers who will receive notification email when content is flagged, replace the placeholder email names for each category with the email addresses of designated reviewers who are assigned the moderator role.
    Note: You can also configure a group email here, but each member of the group must be assigned the moderator role.
    In the following example, flagging is enabled for forums and each forum owner can moderate flagged content for the forums they own. Issue categorization is enabled so that users can select a category when flagging content. If ten users flag a forum post, it is automatically quarantined and removed from the forum.
    <service id="forums">
    <contentApproval enabled="true">
      <ownerModerate enabled="true" /> 
      </contentApproval>
     <contentFlagging enabled="true">
      <ownerModerate enabled="true" /> 
      <automaticQuarantine enabled="true" threshold="10" /> 
     <issueCategorization enabled="true">
     <flagCategory id="001">
      <reviewer email="reviewer1@acme.com" /> 
      <reviewer email="reviewer2@acme.com" /> 
      </flagCategory>
    <flagCategory id="002">
      <reviewer email="reviewer2@acme.com" /> 
      <reviewer email="reviewer3@acme.com" /> 
      </flagCategory>
      </issueCategorization>
      </contentFlagging>
  6. To add a category for flagged content, add a new <flagCategory> element with a unique id and descriptions in the desired languages to the <flaggedCategories> section of the configuration file.
    Tip: The fastest way to add a content category is to copy an existing <flagCategory> element, paste it into the file and edit the ID and descriptions in the required languages.
    For example, to add a content category for "Offensive Language" add the following:
    <flagCategory>
        <id>003</id>
        <description xml:lang="en">Offensive Language</description>
        <description xml:lang="fr">French equivalent</description>
        <description xml:lang="it">Italian equivalent</description>
       </flagCategory>
    Note that the new ID is “003”. This must be unique. As this example shows, you can also add language statements and provide translated strings for category names.
  7. To specify who should receive email notification of content awaiting moderation or flagged content that needs review, replace the placeholder email names in the following section with the email addresses of users assigned the moderator role for that service.
    <moderator email="moderator3@acme.com" /> 
      <moderator email="moderator4@acme.com" /> 
  8. Save your changes to the contentreview-config.xml file.
  9. Check the file back in, using the command:
    LCConfigService.checkInContentReviewConfig(<temp-dir>,"<cell-name>")
    During the check-in process validation is done to ensure no xml syntax errors are in the file.
  10. Restart the affected applications to see the changes.
Moderating content before it is published

Review before it is published to make sure it meets your standards.

Before you begin
When content is submitted by a user, it is marked for review and it displays on the Content Approval section of the Moderation tab. An authorized moderator can view the state of submitted content and take action on it. Content can be:
  • Blog entries or comments
  • Community files content or comments
  • Forum posts or comments

The workflow described in this topic requires that valid email addresses are configured for the reviewers and that email notifications are enabled for your Connections deployment.

About this task

When a user submits content, it sets in motion a workflow for reviewing the content. The workflow goes as follows:

  1. Notification is sent to the moderator that content has been submitted. The notification includes information about the person submitting the content and a link to the content. The content is posted to the Content Approval section in the Moderation interface for viewing and managing content before it is published.
  2. The moderator reviews the content and acts on it.
  3. If the content is acceptable, the reviewer approves it and it is published. The author receives notification email that the content is approved.
  4. If the content is considered inappropriate, the reviewer rejects the content. In this case, the author is notified by email. The posting appears on the Rejected panel.
  5. If the content is considered inappropriate, the reviewer can delete it from either the Require Approval or the Rejected tabs.
Follow these steps to review content and take action.
Procedure
  1. Click the Moderation tab.
  2. Click Content Approval in the navigation pane and then select the type of content that you want to work with - Blogs, Files, or Forums. Content awaiting decisions are displayed along with information on who submitted the content.
  3. Review an item and choose one of these actions:
    Option Description
    Approve Publish the content.
    Reject The content is moved to the Rejected tab where you can later approve it or delete it. Blog content that is rejected can be revised by the author and resubmitted for approval.
    Delete Permanently remove the content.
Moderating published content that is flagged

Review published content that has been flagged as inappropriate and take action on flagged entries and comments.

Before you begin
When content is flagged by a user, it is marked for review and it displays on the Flagged Content section of the Moderation tab. An authorized moderator can view the history and state of flagged content and take action on it. Flagged content can be:
  • Blog entries or comments
  • Community files content or comments
  • Forum posts

The workflow described in this topic requires that valid email addresses are configured for the reviewers and that email notifications are enabled for your Connections deployment.

About this task

When a user flags content as inappropriate, it sets in motion a workflow for reviewing and resolving the issue. The workflow goes as follows:

  1. Notification is sent to the moderator that content has been flagged. The notification includes information about the person flagging the content, and a link to the content in the Moderation interface. The entry or comment is posted to the Flagged Content section in the Moderation interface for viewing and managing flagged content.
    Note: There is a setting in the contentreview-config.xml file which determines whether notification is sent to a moderator or content reviewer as follows:
    • If issueCategorization is disabled, then notification is sent to all the moderators.
    • If issueCategorization is enabled, then the notification will only be sent to the reviewers defined under each issue category, but if reviewer information is not provided, the notification will still be sent to all the moderators.
  2. The moderator reviews the content and acts on it.
  3. If the reviewer does not think the content is inappropriate, the flag is dismissed and the content remains in the blog or community.
  4. If the content is considered inappropriate, the reviewer quarantines the posting, which means it is removed and placed in a quarantined state. In this case, the author is notified. The posting appears on the Quarantined panel.
  5. If the content is considered inappropriate, the reviewer can delete it from either the Flagged for Review or the Quarantined tabs.
Follow these steps to review flagged content and take action.
Procedure
  1. Click the Moderation tab.
  2. Click Flagged Content in the navigation pane and then select the type of content that you want to work with - Blogs, Files, or Forums. Content awaiting decisions are displayed along with information on who flagged the content and why.
  3. Review a flagged entry and choose one of these actions:
    Option Description
    Dismiss Dismiss the flag. The content remains available.
    Quarantine This option turns the post in question to a draft and removes it to a quarantine area so it is not available to readers. This option prompts you to send notification to the posting author explaining your reason for removing the post and providing a link so the author can revise the content. Quarantined content can be restored or deleted.
    Delete Permanently remove the content.
  4. View content that you have quarantined, select one or more items, and take one of the following actions:
    • Click Restore to dismiss the flag and restore the content to a published state.
    • Click Delete to permanently remove the content.
Managing moderation when email is disabled

If email is disabled or if users do not have email addresses, some parts of the moderation workflow must be completed manually.

If IBM Connections is configured so that email notification is disabled, the automatic notifications used for this workflow are disabled. The following activities would require manual intervention:
  • When an entry is flagged as inappropriate, the reviewers will not receive email indicating there is a potentially offensive posting. Reviewers will have to periodically visit the Flagged Content section of the Moderation interface to see what content needs action and then manually send confirmation notification messages to the user who flagged the content.
  • If the reviewer quarantines an item, the owner will not receive email notifications. The reviewer will have to manually send a notification message to the content owner.
Note: If your organization includes people with no email, the automatic notifications used for this workflow are disabled. The following activities would require manual intervention:
  • If a reviewer has no email, when an entry or comment is flagged as inappropriate, the reviewer will not receive email indicating there is a potentially offensive posting. Reviewers will have to periodically visit the Flagged Entries or Flagged Comments pages of the Moderation interface to see what entries need action.
  • If the content owner has no email, and the reviewer quarantines an item, the content owner will not receive email notifications.
  • If the person who flagged the message as inappropriate has no email, the person will not receive a confirmation email that the post they found offensive is being reviewed.
Configuring moderation for communities

Configure moderation for communities so that owners can review and manage the blog, file, and forum content directly in the community. Owners can control what content is added by members (pre-moderation) and remove anything that might be considered inappropriate in your organization (post-moderation).

Before you begin

To edit configuration files, you must use the wsadmin client. See Starting the wsadmin client for details.

Configure IBM Connections using scripts accessed with the wsadmin client. These scripts use the connectionsConfig object available in WebSphere Application Server wsadmin client to interact with the IBM Connections configuration file, which is named contentreview-config.xml.

The properties in the contentreview-config.xml file cannot be edited using the updateConfig command nor displayed using the showConfig command. Instead, you must check out the configuration file using the checkOutContentReviewConfig command, and then edit the property values by opening the checked out property file from the temporary directory using a text editor. After editing the property file, save the file in Unicode format and check the file back in using the checkInContentReviewConfig command and restart the application servers to see the changes.

About this task
When owner moderation is enabled for communities, community owners can access moderation options for their community by opening the community and selecting Community Actions > Moderate Community. Community moderators only can manage the content of communities that they own.

Administrators configure the following section of the contentreview-config.xml file to set community moderation:

<commModerationConfiguration>
	<preModeration>
		<forceForAllCommunities enabled=boolean value of true or false />
		<enabledByCreation enabled="true" />
	</preModeration>
	<postModeration>
		<forceForAllCommunities enabled=boolean value of true or false />
		<enabledByCreation enabled="true" />
	</postModeration>
</commModerationConfiguration>

<service id="blogs">
		<contentApproval enabled=boolean value of true or false>
		    <ownerModerate enabled=boolean value of true or false/>
	</contentApproval>
		<contentFlagging enabled=boolean value of true or false>
		    <ownerModerate enabled=boolean value of true or false/>

<service id="files">
		<contentApproval enabled=boolean value of true or false>
		    <ownerModerate enabled=boolean value of true or false/>
        </contentApproval>
		<contentFlagging enabled=boolean value of true or false>
		    <ownerModerate enabled=boolean value of true or false/>


<service id="forums">
		<contentApproval enabled=boolean value of true or false>
           		 <ownerModerate enabled=boolean value of true or false/>
       </contentApproval>
		<contentFlagging enabled=boolean value of true or false>
			<ownerModerate enabled=boolean value of true or false/>
Where:
preModeration
Community owners must approve all content before it can be posted.
postModeration
Viewers can flag content.
forceForAllCommunities
Set to "true" to require moderation for communities. By default this attribute is set to "false". When the setting is set to false, moderation is not automatically required for a community, but moderation API command and filters still work. Moderators can still perform moderation tasks.
enabledByCreation
Setting determines if the moderation check boxes in the Start Community form should be checked when a user clicks Start a Community.
contentApproval
Set to "true" to require moderation for the specified application. By default this attribute is set to "false". When the setting is set to false, moderation is not automatically enforced for an application, but moderation API command and filters still work. Moderators can still perform moderation tasks.
contentFlagging
Set to "true" to require moderation for flagged content. By default this attribute is set to "false". When the setting is set to false, the user cannot flag content from the user interface or using an API command. Blogs Moderation API and filters still work. Moderators can still perform moderation tasks. Files and Forums API commands returns errors.
Note: If you upgraded IBM Connections from release 2.5 to release 3.0 or higher, the default for Blogs is "true" for compatibility reasons.
ownerModerate
Must be set to "true" to specify that community owners can moderate the content in communities that they own, otherwise it is set to "false". If contentFlagging or contentApproval for a service is set to true, then ownerModerate must be set to true. If contentFlagging or contentApproval for a service is set to false, then ownerModerate must be set to false.
Procedure

To change community moderation configuration settings, complete the following steps:

  1. Start the wsadmin client from the following directory of the system on which you installed the deployment manager:
    app_server_root\profiles\dm_profile_root\bin
    where app_server_root is the WebSphere Application Server installation directory and dm_profile_root is the Deployment Manager profile directory, typically dmgr01. For example, on Windows:
    C:\Program Files\IBM\WebSphere\AppServer\profiles\Dmgr01\bin
    Attention: You must run the following command to start the wsadmin client from this specific directory because the Jython 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 does not work correctly. See the topic Starting the wsadmin client.
  2. Use the wsadmin client to access and check out the IBM Connections configuration file:
    1. Access the IBM Connections configuration file using the following command:
      execfile("connectionsConfig.py")

      If prompted to specify a service to connect to, type 1 to pick the first node in the list. Most commands can run on any node. If the command writes or reads information to or from a file using a local file path, you must pick the node where the file is stored. This information is not used by the wsadmin client when you are making configuration changes.

    2. Check out the IBM Connections content configuration file using the following command:
      LCConfigService.checkOutContentReviewConfig("working_directory","cell_name")
      where:
      • working_directory is the temporary working directory to which the configuration XML and XSD files are copied and are stored while you make changes to them. Use forward slashes to separate directories in the file path, even if you are using the Microsoft Windows operating system.
      • cell_name is the name of the WebSphere Application Server cell hosting the IBM Connections application. This argument is case-sensitive, so type it with care. If you do not know the cell name, type the following command while in the wsadmin command processor:
        print AdminControl.getCell()
      For example:
      • AIX/Linux:
        LCConfigService.checkOutContentReviewConfig("/opt/temp","foo01Cell01")
      • Microsoft Windows:
        LCConfigService.checkOutContentReviewConfig("c:/temp","foo01Cell01")
  3. From the temporary directory to which you just checked out the IBM Connections configuration files, open the contentreview-config.xml file in a Unicode text editor.
    Note: Editing the file using a standard text editor that does not support Unicode could corrupt the file.
  4. Determine if you want to give owners the ability to turn pre-approval on and off, or if you want to force owners to approve content.
    Table 30. Owners must approve all content
    Force pre-approval Sample code What the owner sees in the user interface
    Let owners turn off pre-approval
    <preModeration>
    <forceForAllCommunities enabled="false">
    .....
    </premoderation>

    Owners can clear the check box.

    Checked Owners must approve all content (...)

    Force owners to pre-approve content
    <preModeration>
    <forceForAllCommunities enabled="true">
    .....
    </premoderation>

    Owners cannot clear the check box.

    Cannot check Owners must approve all content (...)

  5. After you decide whether or not you want to force owners to pre-approve content, you should select the specific content that requires pre-approval.
    Table 31. Determine the content that requires approval
    Content that requires owner’s approval Sample code What owner sees in the user interface
    Blog content requires the owner’s approval
    <service id="blogs">
    <contentApproval enabled="true">
    <ownerModerate enabled= "true">
    </contentApproval>

    If forceForAllCommunities is set to false, the check box can be cleared by owners.

    Checked Owners must approve all content (Blogs)

    If forceForAllCommunities is set to true, the check box cannot be cleared by owners. The check box is gray.

    Cannot check Owners must approve all content (Blogs)

    Files content requires the owner’s approval
    <service id="files">
    <contentApproval enabled="true">
    <ownerModerate enabled= "true">
    </contentApproval>

    If forceForAllCommunities is set to false, the check box can be cleared by owners.

    Checked Owners must approve all content (Files)

    If forceForAllCommunities is set to true, the check box cannot be cleared by owners. The check box is gray.

    Cannot check Owners must approve all content (Files)

    Forums content requires the owner’s approval
    <service id="Forums">
    <contentApproval enabled="true">
    <ownerModerate enabled= "true">
    </contentApproval>

    If forceForAllCommunities is set to false, the check box can be cleared by owners.

    Checked Owners must approve all content (Forums)

    If forceForAllCommunities is set to true, the check box cannot be cleared by owners. The check box is gray.

    Cannot check Owners must approve all content (Forums)

    Blogs and Files require the owner’s approval. Forums does not.
    <service id="blogs">
    <contentApproval enabled="true">
    <ownerModerate enabled= "true">
    </contentApproval>
    <service id="files">
    <contentApproval enabled="true">
    <ownerModerate enabled= "true">
    </contentApproval>
    <service id="Forums">
    <contentApproval enabled="false">
    <ownerModerate enabled= "true">
    </contentApproval>

    If forceForAllCommunities is set to false, the check box can be cleared by owners.

    Checked Owners must approve all content (Blogs, Files)

    If forceForAllCommunities is set to true, the check box cannot be cleared by owners. The check box is gray.

    Cannot check Owners must approve all content (Blogs, Files)

    Files requires the owner’s approval.

    Blogs content is moderated in the community, but only the global moderator can approve it. The community owner cannot manage content or change the moderation options of Blogs in his community.

    <service id="blogs">
    <contentApproval enabled= "true">
    <ownerModerate enabled= "false">
    <service id="files">
    <contentApproval enabled= "true">
    <ownerModerate enabled= "true">

    If forceForAllCommunities is set to false, the check box can be cleared by owners.

    Checked Owners must approve all content (Files)

    If forceForAllCommunities is set to true, the check box cannot be cleared by owners. The check box is gray.

    Cannot check Owners must approve all content (Files)

    Files requires the owner’s approval.

    Blogs content does not require any approval. All content is published directly without approval.

    <service id="blogs">
    <contentApproval enabled= "false">
    <ownerModerate enabled= "false">
    <service id="files">
    <contentApproval enabled= "true">
    <ownerModerate enabled= "true">

    If forceForAllCommunities is set to false, the check box can be cleared by owners.

    Checked Owners must approve all content (Files)

    If forceForAllCommunities is set to true, the check box cannot be cleared by owners. The check box is gray.

    Cannot check Owners must approve all content (Files)

  6. Determine if you want to give owners the ability to let people flag inappropriate content. You can let owners decide if they want to include this ability in their community, or you can force them to offer this ability in their community.
    Table 32. Viewers can flag inappropriate content
    Force pre-approval Sample code What the owner sees in the user interface
    Let owners turn off flagging
    <postModeration>
    <forceForAllCommunities enabled="false">
    .....
    </postmoderation>

    Owners can clear the check box.

    Checked Viewers can flag inappropriate content (...)

    Force owners to viewers to flag content.
    <postModeration>
    <forceForAllCommunities enabled="true">
    .....
    </postmoderation>

    Owners cannot clear the check box.

    Cannot check Viewers can flag inappropriate content (...)

  7. After you decide if you want to force owners to let viewers flag content, select the specific widget where they can flag content.
    Table 33. Determine the content that can be flagged
    Content that can be flagged Sample code What owner sees in the user interface
    Blog content can be flagged as inappropriate by viewers
    <service id="blogs">
    <contentFlagging enabled="true">
    <ownerModerate enabled="true"/>

    If forceForAllCommunities is set to false, the check box can be cleared by owners.

    Checked Viewers can flag inappropriate content (Blogs)

    If forceForAllCommunities is set to true, the check box cannot be cleared by owners. The check box and text are gray.

    Cannot check Viewers can flag inappropriate content (Blogs)

    Files content can be flagged as inappropriate by viewers
    <service id="files">
    <contentFlagging enabled="true">
    <ownerModerate enabled="true"/>

    If forceForAllCommunities is set to false, the check box can be cleared by owners.

    Checked Viewers can flag inappropriate content (Files)

    If forceForAllCommunities is set to true, the check box cannot be cleared by owners. The check box and text are gray.

    Cannot check Viewers can flag inappropriate content (Files)

    Forums content can be flagged as inappropriate by viewers
    <service id="Forums">
    <contentFlagging enabled="true">
    <ownerModerate enabled="true"/>

    If forceForAllCommunities is set to false, the check box can be cleared by owners.

    Checked Viewers can flag inappropriate content (Forums)

    If forceForAllCommunities is set to true, the check box cannot be cleared by owners. The check box and text are gray.

    Cannot check Viewers can flag inappropriate content (Forums)

    Files and Forums content can be flagged as inappropriate by viewers. Blogs cannot.
    <service id="blogs">
    <contentFlagging enabled="false">
    <ownerModerate enabled="false"/>
    <service id="files">
    <contentFlagging enabled="true">
    <ownerModerate enabled="true"/>
    <service id="Forums">
    <contentFlagging enabled="true">
    <ownerModerate enabled="true"/>

    If forceForAllCommunities is set to false, the check box can be cleared by owners.

    Checked Viewers can flag inappropriate content (Files, Forums)

    If forceForAllCommunities is set to true, the check box cannot be cleared by owners. The check box and text are gray.

    Cannot check Viewers can flag inappropriate content (Files, Forums)

    Files content can be flagged as inappropriate by viewers.

    Blogs content can be flagged as inappropriate by viewers, but only the global moderator can take action. The community owner cannot manage content or change the moderation options of Blogs in his community.

    <service id="blogs">
    <contentFlagging enabled="true">
    <ownerModerate enabled= "false">
    <service id="files">
    <contentFlagging enabled="true">
    <ownerModerate enabled= "true">

    If forceForAllCommunities is set to false, the check box can be cleared by owners.

    Checked Viewers can flag inappropriate content (Files)

    If forceForAllCommunities is set to true, the check box cannot be cleared by owners. The check box and text are gray.

    Cannot check Viewers can flag inappropriate content (Files)

    Files content can be flagged as inappropriate by viewers.

    Blogs content cannot be flagged as inappropriate. The community owner cannot manage flagged content or change the flag moderation options of Blogs in his community.

    <service id="blogs">
    <contentFlagging enabled="false">
    <ownerModerate enabled= "false">
    <service id="files">
    <contentFlagging enabled="true">
    <ownerModerate enabled= "true">

    If forceForAllCommunities is set to false, the check box can be cleared by owners.

    Checked Viewers can flag inappropriate content (Files)

    If forceForAllCommunities is set to true, the check box cannot be cleared by owners. The check box and text are gray.

    Cannot check Viewers can flag inappropriate content (Files)

Administering the Widget container

The Widget Container is the IBM Connections-specific integration of the Common Rendering Engine, also known as the CRE.

The CRE is the successor to Mashup Enabler and adds the ability to render OpenSocial gadgets as well as iWidgets. Throughout the IBM Connections documentation, the Connections instance of CRE will be referred to as the Widget Container. This section of the documentation is specific to the administration of the Widget Container. More details on the CRE in general can be found in the IBM Social Business Development wiki.

Note: If you wish to add gadgets deployed externally, such as iGoogle gadgets, you must configure locked domains. Locking domains isolates semi-trusted gadgets and prevents them from accessing SSO tokens or via DOM access to the parent page of the gadget iFrame that can be used to forward sensitive data to external sites. For more information on locked domains, refer to Enabling locked domains.

Administering gadgets for IBM Connections and widgets for Home page

You can extend the functionality of the Home page application by adding custom widgets and extend IBM Connections by adding OpenSocial gadgets. To make the widgets and gadgets available for use, you can add them from the Administration view and then enable them for use.

The widgets that you add to the Home page can be based on the iWidget specification, which uses technology based on JavaScript, XML, HTML, and CSS, or the OpenSocial gadget specification. The widget files are stored on an HTTP server.

The gadgets that you add to IBM Connections need to be based on the OpenSocial gadget specification, which enables you to surface gadgets in an OpenSocial container that can interact with an OAuth 2.0 protected service

The widget files can be bundled as EAR applications and deployed on IBM WebSphere Application Server. They can also be hosted in LAMP, .NET, and other environments.

You can add two types of third-party widget to the Home page:
Opened by default
This type of widget displays by default, but can be removed or hidden. It can also be moved to a different location. For example, the To Do List widget that displays in the Updates view is opened by default.
Optional
This type of widget is available for users to add to their Home page if they select it from the widget catalog. Optional widgets can be added, removed, hidden, or moved by Home page users.
Any widget can be used as a default or optional widget.

Third-party widgets can be added to the side column in the Updates view and to any column in the My Page view.

Configuring widgets

You can add widgets to the widget catalog to meet the needs of your users. Ensure that the widgets that you add to the catalog are from trusted sources. The widget catalog allows you to administer OpenSocial gadgets for the entire IBM Connections system including Embedded Experiences and Share Dialog gadgets as well as gadgets and iWidgets that are specific to the Home page.

Before you begin
To add widgets via the Home page, you must be logged in as an administrator. If you do not see an Administration option display under the My Page option in the navigation sidebar on the Home page, this means that you are not configured as an administrator of the Home page application. See Configuring the Home page administrator for more details.
Note: If you wish to add gadgets deployed externally, such as iGoogle gadgets, you must configure locked domains. Locking domains isolates semi-trusted gadgets and prevents them from accessing SSO tokens or via DOM access to the parent page of the gadget iFrame that can be used to forward sensitive data to external sites. For more information on locked domains, refer to Enabling locked domains.
Procedure

To add a widget to the widget catalog, complete the following steps:

  1. Open the Administration view.
  2. Click Add another widget to display the Add new widget form.
  3. Specify whether you are adding a widget that is based on the iWidget specification or the OpenSocial gadget specification. To allow users to be able to integrate applications such as Facebook, Twitter, and LinkedIn into their IBM Connections client experience, select OpenSocial gadget. Selecting OpenSocial gadget opens the Gadget settings with Activity stream or Share dialog subform, on which you need to specify the following additional options:
    1. For Security, select either a Trusted or a Restricted security type. Make your selection based on the following considerations:
      • Trusted gadgets can access a wider selection of container APIs and they can interact with IBM Connections data. Even though a gadget is marked as "trusted", its data access is still isolated from SSO data when used in combination with locked domains.
      • Select Use SSO token for trusted enterprise gadgets. Selecting this feature disables all of the security provided by locked domains for this particular gadget.
      • In general, gadgets should be written to utilize OAuth unless they are speaking to a "legacy" system that has not been OAuth enabled. For 4.0, all of the Connections APIs are now OAuth enabled. Currently SSO is not a standard OpenSocial feature, but specific to the Common Rendering Engine (CRE). Some IBM Containers, such as Notes Social Edition, do not support the SSO feature at all at the time of this writing.
      • Restricted gadgets are limited in terms of the OpenSocial features. For example, they are not able to popup model dialogs. In general, you should always scope gadget feature access as narrowly as possible. Use this setting if the gadget does not require the additional page API features provided to trusted gadgets.
      Note: You should not put any external (restricted) gadgets into IBM Connections if you have not configured locked domains.
    2. For UI integration points select where the gadget should be inserted in the user interface:Show in Share dialog or Show for Activity stream events or both.
      Note: Your gadget will display after the IBM Connections gadgets in the Share dialog.
    3. Select the Server access via proxy preference as follows:
      • Only outside the intranet prevents the gadget from accessing your intranet servers. Unless specifically configured, the system will deem a server as part of the intranet if it is part of the WebSphere SSO domain. If this scoping is too narrow, it can be expanded via additional configuration settings.
      • All servers allows the gadget to access URLs in your intranet as well as outside it.
      • Custom rule defined for this gadget in the proxy-policy.dynamic file enforces settings defined in the policy file. For more information refer to Configuring per-host proxy access rules for OpenSocial gadgets.
    4. In the Service Mappings section, create a new mapping between an OAuth client, such as Facebook or Twitter, and its associated service, or edit or remove an existing mapping.
      Note: OAuth clients must be pre-configured via wsadmin commands. This setting just manages the association of the clients with individual gadgets.
      1. Click Add Mapping to create a new mapping between an OAuth service and an OAuth client. In the fields that display, select an OAuth Client name and enter the associated Service Name.
      2. Select an existing mapping in the map list and then click Edit Mapping to update the mapping.
      3. Select an existing mapping in the map list and then click Delete Mapping to remove that mapping from the list.
      For more information about OAuth tokens, refer to Configuring OAuth for custom gadgets.
  4. Enter a name for the widget in the Widget Title field.
  5. Enter a short description of the widget in the Description field.
  6. Enter the web address for the XML widget descriptor in the URL Address field. This address must be an absolute web address.
  7. Enter the widget location in the Secure URL Address field. This address must be an absolute web address.
  8. Enter the web address for an icon to associate with the widget in the Icon URL field. This image is used to represent the widget when it is docked in the widget palette.
  9. Enter the location of an icon to display for the widget in the Icon Secure URL field. This icon displays when the widget is docked in the content palette.
  10. Select Use IBM Connections specific tags to indicate if the widget deployment descriptor uses specific IBM Connections tags to represent the URLs of the IBM Connections applications.
  11. To display the widget in the My Page view, select Display in the My Page view. You must display the widget in the My Page view or the Updates view, or both.
  12. To display the widget in the Updates view, select Display in the Updates view. You must display the widget in the My Page view or the Updates view, or both.
  13. To display the widget when users open the Home page for the first time, select Opened by default. The widget will not display for existing users, but it will be available from the widget palette so that they can add it whenever they want.
  14. To enable multiple instances of the widget to be used, select Multiple widgets. Each widget instance has its own properties, which can be useful. For example, if you are using a widget that displays bookmarks for a specific tag, you might want to enable multiple instances of the widget so that you can follow different tags in each widget.
    Note: This setting is only applicable for iWidgets. Only one instance of an OpenSocial gadget may be loaded at a time.
  15. If there are specific IBM Connections applications that must be included in your deployment for the widget to function correctly, select the required applications in the Prerequisites area.
    Note: When an IBM Connections application is selected as a prerequisite but that application is not installed, the widget does not display on the Home page. For gadgets that declare dependencies this way, they will act as though they are "disabled" for the purposes of whitelisting if all of their dependencies are not met.
  16. Click Save.
What to do next
If you are adding widgets that are hosted on third-party servers, then you might need to update your proxy configuration. For more information on configuring the Ajax proxy, see Configuring the AJAX proxy for a specific application.
Enabling widgets

You need to enable widgets before they can display on the Home page or elsewhere in IBM Connections.

About this task
The Home page administration user interface lists the current status of widgets in the widgets catalog, and allows you to enable and disable widgets as needed. All changes made in the user interface, including enabling and disabling widgets, take immediate effect without the need for application restart.
Procedure

To change a widget's status to enabled, complete the following steps.

  1. Open the Administration view.
  2. In the Disabled widgets area, select the widget that you want to enable and click Enable.
Disabling widgets

You can disable widgets from displaying on the Home page or elsewhere in IBM Connections when you no longer want them to be available to your users.

About this task
Setting a widget's status to disabled means that it no longer displays on the Home page. The Home page administration user interface lists the current status of widgets in the widget catalog, and allows the administrator to enable and disable widgets as needed. All changes made in the user interface, including enabling and disabling widgets, take immediate effect without the need for application restart.
Procedure

To change a widget's status to disabled, complete the following steps.

  1. Open the Administration view.
  2. In the Enabled widgets area, select the widget that you want to disable and click Disable.
Editing widgets

Edit a widget to change its name, description, or deployment descriptor.

About this task
You can edit a widget to update the icon associated with the widget when it is docked, specify whether the widget deployment descriptor uses particular IBM Connections tags to represent the URLs of IBM Connections applications, and select IBM Connections applications as prerequisites for the widget.
Note: For system widgets that are installed as part of IBM Connections, you can only change the name of the widget.
Procedure

To edit a widget, complete the following steps.

  1. Open the Administration view.
  2. Select the widget that you want to edit and click Edit.
  3. Make the necessary changes in the Edit widget form and then click Save.
Removing widgets

If a third-party widget is no longer used or needed, you can remove it from the widget catalog. You cannot remove IBM Connections widgets from the catalog, you can only disable them.

Procedure

To remove a third-party widget from the widget catalog, complete the following steps.

  1. Open the Administration page.
  2. Select the widget that you want to remove, and then click Remove.

Gadget registration commands

Administrators can use NewsWidgetCatalogService commands to register gadgets, particularly if the IBM Connections Home page application, with its administrative interface, has not been installed.

Flag constants used for widget policy settings
GadgetFlags
TRUSTED use to indicate that a gadget is 'trusted' and should be granted access to the non-base gadget features.
SSO indicates that a particular gadget is granted access to the SSO feature.
WidgetContexts
UPDATE indicates that this widget is applicable to the updates page of the Homepage.
WIDGET indicates that this widget is applicable to the widgets page of the Homepage.
SHAREDIALOG indicates that this gadget is applicable to the share dialog.
EMBEDXP indicates that this gadget is provides an embedded experience.
Settings available for widgets

Before using any NewsWidgetCatalogService commands, be sure to run newsAdmin.py as described in the first two steps of the topic Accessing the News configuration file. The following table describes the settings available for widgets:

Table 34. Description of the settings available for widgets
Settings Description
widgetId READONLY The id of the widget.
title REQUIRED The title for the widget in the catalog.
text REQUIRED Descriptive text for the widget in the catalog.
url REQUIRED URL for the widget.
secureUrl Alternate 'secure' (HTTPS) URL for the widget XML.
iconUrl The URL for the widget icon. This icon is placed next to the widget in the widget catalog.
secureIconUrl Alternate 'secure' (HTTPS) URL for the widget icon. This icon is placed next to the widget in the widget catalog.
previewImage Setting for a URL to an optional preview image.
categoryName Sets the category for the widget to be displayed in if it is available in the 'customize' panel. Valid values for this are the name of a Connections application (for example: 'profile', 'wikis', 'files') in lowercase.
isSystem READONLY: Indicates if this is a 'system' defined widget. These should not be altered as a rule.
isHomepageSpecific Indicates if the widget is homepage specific. This setting is used by Homepage iWidgets.
isDefaultOpened This indicates if the particular widget should be placed on the widgets page (if applicable) for new users.
multipleInstanceAllowed This indicates if the user may place multiple instances of a widget onto the widgets or updates page. This setting is only valid for iWidgets.
isGadget Indicates whether this is a OpenSocial gadget (true) or iWidget (false).
policyFlags Also see GadgetFlags. List of policy flags set for this widget. For the 4.0 release, this setting is only relevant for gadgets.
enabled Indicates if this widget is enabled or disabled.
prereqs This is a comma-separated list of applications that are required for this widget to be enabled. The widget is implicitly disabled if the list of prerequisites is not met.
appContexts Also see WidgetContexts. Indicates the contexts where this widget is intended to be used.
proxyPolicy Specifies the proxy policy access for custom gadgets. Also see proxyPolicy constant.
Constants for enablement
Enablement
ALL returns both enabled and disabled widgets
ENABLED returns only enabled widgets
DISABLED returns only disabled widgets
Constants for True and False
Constant for True
TRUE=1
Constant for False
FALSE=0
Unbounded page size constant
PAGE_SIZE_UNBOUNDED = -1
Constants for proxyPolicy
proxyPolicy
INTRANET_ACCESS All server access.
EXTERNAL_ONLY Only servers outside of the SSO domain.
CUSTOM No access. Access will be defined by the proxy-policy.dynamic file.
For more information about the proxy-policy.dynamic file, refer to Configuring per-host proxy access rules for OpenSocial gadgets.
NewsWidgetCatalogService
NewsWidgetCatalogService.browseWidgets(enablement = Enablement.ALL, pageSize = PAGE_SIZE_UNBOUNDED, pageNumber = 1)
Browse the widgets in the widget catalog.
Uses the parameter for enablement (Refer to Enablement).
Uses the parameter for pageSize.
Uses the parameter for pageNumber.
Returns a list of Widget objects.
wsadmin>NewsWidgetCatalogService.browseWidgets(Enablement.ALL, 1, 1)
NewsWidgetCatalogService.clearWidgetCaches()
Clears cached widget.xml files from your server without needing to restart your system. If a gadget or iWidget.xml has been updated and you want to force it to be reread by the system, simply call this command.
NewsWidgetCatalogService.countWidgets(enablement = Enablement.ALL)
Count the widgets in the widget catalog.
* Uses the parameter for enablement (Refer to Enablement).
* Returns a count of the number of widgets in the catalog.
NewsWidgetCatalogService.findWidgetById(WidgetId)
Find a widget by id.
Uses the parameter for widgetId.
Returns the matching widget or null if no matching widget is found.
For example:
wsadmin>NewsWidgetCatalogService.findWidgetById("405a4f26-fa08-4cef-a995-7d90fbe2634f")
NewsWidgetCatalogService.findWidgetByUrl(widgetUrl)
Find a widget by Url.
Uses the parameter for url.
Returns the matching widget or null if no matching widget is found.
NewsWidgetCatalogService.listShareGadgets(enablement = Enablement.ALL)
List out the share gadgets. By design, paging is not supported.
Uses the parameter for enablement (Refer to Enablement).
Returns the share gadgets.
For example:
wsadmin>NewsWidgetCatalogService.listShareGadgets(Enablement.ALL)
NewsWidgetCatalogService.updateWidgetShareOrder(widgetId, orderAfterWidgetId)
Place the widget marked in a widgetId after a second widget in widget ordering.
widgetId The id of the widget you wish to move.
orderAfterWidgetId The id of the widget you want to place the gadget after. If this is null, the widget will be placed first in the ordering.
NewsWidgetCatalogService.addWidget(**widget)
Add a widget to the widget catalog.
** widget indicates that this is a free form set of key=value properties. The keys/values map to the Settings available for widgets table previously described.
Returns the ID of the newly created widget.
The following example creates a sample EE gadget that has 'trusted' access policies. This gadget depends on the Profiles component.
NewsWidgetCatalogService.addWidget(title="Sample gadget title", text="Sample gadget description.", url="http://www.to.my.gadget.com/gadget.xml",
categoryName=[WidgetCategories.NONE], isGadget=TRUE,appContexts=[WidgetContexts.EMBEDXP], "policyFlags=[GadgetPolicyFlags.TRUSTED]}, prereqs=["profiles"])
NewsWidgetCatalogService.updateWidget(widgetId, **widget)
Update an existing widget in the widget catalog.
Uses the parameter for widgetId.
** widget indicates that this is a free form set of key=value properties. The keys/values map to the Settings available for widgets table previously described.
wsadmin>NewsWidgetCatalogService.updateWidget("1bf9ad75-a634-4301-88c6-ce493eb03cc9", title="test", text="test")
NewsWidgetCatalogService.removeWidget(widgetId)
Remove a widget matching the widgetId entered.
For example:
wsadmin>NewsWidgetCatalogService.removeWidget("405a4f26-fa08-4cef-a995-7d90fbe2634f") 
NewsWidgetCatalogService.enableWidget(widgetId)
Returns the following output:
CLFRQXXXXI: Widget {0} is now enabled.
NewsWidgetCatalogService.disableWidget(widgetId)
Returns the following output:
CLFRQXXXXI: Widget {0} is now disabled.
NewsWidgetCatalogService.ProxyPolicy
Specify the server proxy policy.
INTRANET_ACCESS May access intranet sites.
EXTERNAL_ONLY May access external (non-intranet) sites only.
CUSTOM Uses rules in the rule manager configuration.

Configuring OAuth for custom gadgets

The IBM Connections 4.0 release supports an OAuth 2.0 consumer proxy that allows the Homepage component to surface gadgets in an OpenSocial container that can interact with an OAuth 2.0 protected service. In order for this proxy to function, there are a series of new administration commands that are exposed in the News service to define OAuth 2.0 providers, clients, and the associated gadget that will interact with the protected service.

Counting providers
NewsOAuth2ConsumerService.countProvider()
Returns the total number of OAuth 2.0 providers registered with the consumer proxy. There are no parameters.
Example:
wsadmin>NewsOAuth2ConsumerService.countProvider()

20
Returning a list of providers
NewsOAuth2ConsumerService.browseProvider(int pageSize, int pageNumber)
Returns a list of Map objects that represent each OAuth 2.0 provider registered with the consumer proxy, in ascending ordered by provider name. The following information is returned for each map object in the returned list:
  • authHeader: "true" or "false"
  • authUrl: the authentication url endpoint for the provider
  • clientAuth: the client authentication method in use
  • name: the name of the provider
  • tokenUrl: the token url endpoint for the provider
  • urlParam: "true" or "false"
pageSize
The maximum number of providers to list per page. The default value is 20. This parameter is optional.
pageNumber
The number of the page to display. For example, if you specify in the pageSize parameter that each page will have 50 items, page 1 will contain items 1-50. The default value is 1. This parameter is optional.
Example:
wsadmin>NewsOAuth2ConsumerService.browseProvider(50, 1)
Returning a single provider
NewsOAuth2ConsumerService.findProvider(string providerName)
Returns a Map with information about the registered OAuth 2.0 provider with the specified name.
providerName
The unique provider name.
Example:
wsadmin>NewsOAuth2ConsumerService.findProvider("provider123")
Registering or updating a provider
NewsOAuth2ConsumerService.registerProvider(string providerName, string clientAuth, string authHeader, string urlParam, string authUrl, string tokenUrl)
Registers or updates an existing OAuth 2.0 provider by name with the associated parameters.
providerName
The unique provider name.
clientAuth
The client authentication method for accessing this provider. Supported values out of the box are "standard" and "basic" per the specification.
authHeader
Value of "true" if credentials must be encoded in the authorization header, otherwise "false".
urlParam
Value of "true" if credentials must be specified as query parameters on the URI, otherwise "false".
authUrl
The authentication endpoint for the provider.
tokenUrl
The token endpoint for the provider.
Example:
wsadmin>NewsOAuth2ConsumerService.registerProvider("provider123", "standard", "true", "false", "???", "???")
Deleting a provider
NewsOAuth2ConsumerService.deleteProvider(string providerName)
Deletes a provider by name if it exists, and has no existing associated clients or gadget bindings.
providerName
The unique provider name.
Example:
wsadmin>NewsOAuth2ConsumerService.deleteProvider("provider123")
Counting clients
NewsOAuth2ConsumerService.countClient(string providerName)
Returns the total number of OAuth 2.0 clients registered with the consumer proxy.
providerName
An optional filter to only count clients associated with the specified provider.
Example:
wsadmin>NewsOAuth2ConsumerService.countClient("provider123")
Returning a single client
NewsOAuth2ConsumerService.findClient(string clientName)
Returns a Map with information about the registered OAuth 2.0 client with the specified name.
providerName
The client name.
Example:
wsadmin>NewsOAuth2ConsumerService.findClient("client123")
Returning a list of clients
NewsOAuth2ConsumerService.browseClient(string providerName, int pageSize, int pageNumber)
Returns a list of Map objects that represent each OAuth 2.0 clients registered with the consumer proxy, in ascending ordered by provider name. The following information is returned for each map object in the returned list:
  • clientId: the identifier issued by the authorization server when registering your client
  • clientSecret: the secret issued by the authorization server when registering your client
  • ctype: the client type, "confidential" or "public" are the supported values per the specification
  • grantType: "code" per specification, or "client_credentials" per specification
  • name: the name of the client
  • providerName: the name of the associated provider that was previously registered
  • redirectUri: the client redirection uri
providerName
An optional filter to only browse clients associated with the specified provider.
pageSize
The maximum number of clients to list per page. The default value is 20. This parameter is optional.
pageNumber
The number of the page to display. For example, if you specify in the pageSize parameter that each page will have 50 items, page 1 will contain items 1-50. The default value is 1. This parameter is optional.
Example:
wsadmin>NewsOAuth2ConsumerService.browseClient("provider123", 50, 1)
Registering or updating a client
NewsOAuth2ConsumerService.registerClient(string clientName, string providerName, string ctype, string grantType, string clientId, string clientSecret, string redirectUri)
Registers or updates an existing OAuth 2.0 client by name with the associated parameters.
clientName
The name to associate with the client that must be unique in a deployment.
providerName
The name of the registered provider to associate with this client.
ctype
The client type. Supported values are "confidential" or "public" per LINKspecification/LINK.
grantType
The authorization grant type. Supported values are "code" or "client_credentials" per specification??
clientID
The identifier issued by the authorization server when registering your client.
clientSecret
The secret issued by the authorization server when registering your client.
redirectUri
The client redirection URI.
Example:
wsadmin>NewsOAuth2ConsumerService.registerClient("client123", "provider123", "confidential", "code", "my-client", "my-secret", "https://{opensocial}/gadgets/oauth2callback")
Deleting a client
NewsOAuth2ConsumerService.deleteClient(string clientName)
Deletes a client by name if it exists, and has no existing associated gadget bindings that leverage this client.
clientName
The name of the client to remove.
Example:
wsadmin>NewsOAuth2ConsumerService.deleteClient("client123")
Binding a gadget
NewsOAuth2ConsumerService.bindGadget(string widgetId, string serviceName, string clientName, string allowModuleOverride)
Binds a gadget to a client with the specified service name and client name.
widgetId
The id of the widget.
serviceName
The name to associate with the gadget. The widgetId and service name must create a unique composite key for the deployment.
clientName
The name of the client to associate with this gadget.
allowModuleOverride
Value is "true" if the gadget overrides the provider default endpoint urls, else "false".
Example:
wsadmin>NewsOAuth2ConsumerService.bindGadget("aad20aa1-c0fa-48ef-bd05-8abe630c0012", "connections_service", "client123", "false")
Deleting a binding
NewsOAuth2ConsumerService.unbindGadget(string widgetId, string serviceName)
Deletes a gadget binding by widgetId and serviceName.
widgetId
The id of the widget.
serviceName
The name to associate with the gadget. The widgetId and service name must create a unique composite key for the deployment.
Example:
wsadmin>NewsOAuth2ConsumerService.unbindGadget("aad20aa1-c0fa-48ef-bd05-8abe630c0012", "connections_service")
Returning bindings
NewsOAuth2ConsumerService.browseGadgetBinding(string widgetId, string clientName, int pageSize, int pageNumber)
Returns a list of Map objects that represent each OAuth 2.0 gadget bindings registered with the consumer proxy ordered by service name ascending. The following information is returned for each map entry in the returned list:
  • clientName: the name of the associated client
  • allowModuleOverride: "true" or "false"
  • serviceName: the name of the associated service
  • uri: the gadget uri
widgetId
An optional filter to browse bindings only associated with a specific widget.
clientName
An optional filter to browse gadgets only associated with the specified client.
pageSize
The maximum number of bindings to list per page. The default value is 20. This parameter is optional.
pageNumber
The number of the page to display. For example, if you specify in the pageSize parameter that each page will have 50 items, page 1 will contain items 1-50. The default value is 1. This parameter is optional.
Example:
wsadmin>NewsOAuth2ConsumerService.browseGadgetBinding("aad20aa1-c0fa-48ef-bd05-8abe630c0012", "client123", 50, 2)
Counting bindings
NewsOAuth2ConsumerService.countGadgetBinding(string widgetId, string clientName)
Returns the total number of OAuth 2.0 bindings registered with the consumer proxy.
string widgetId, string clientName
widgetId is an optional filter to count only bindings associated with a specific widget.
Example:
wsadmin>NewsOAuth2ConsumerService.countGadgetBinding("aad20aa1-c0fa-48ef-bd05-8abe630c0012", "connections_servicex")
Returning a single binding by gadgetUri
NewsOAuth2ConsumerService.findGadgetBindingByUri(string gadgetUri, string serviceName)
Returns a Map with information about the registered OAuth 2.0 gadget bindings with the specified gadgetUri and service name.
gadgetUri
The uri for the gadget.
serviceName
The name associated with the gadget. A gadgetUri and service name create a unique composite key for a gadget in the deployment.
Example:
wsadmin>NewsOAuth2ConsumerService.findGadgetBinding("http://www.acme.com/mygadget", "connections_service")
Returning a single binding by widgetId
NewsOAuth2ConsumerService.findGadgetBindingByWidgetId(string widgetId, string serviceName)
Returns a Map with information about the registered OAuth 2.0 gadget bindings with the specified widget id and service name.
widgetId
The id of the widget.
serviceName
The name associated with the gadget. A widgetId and service name create a unique composite key for a gadget in the deployment.
Example:
wsadmin>NewsOAuth2ConsumerService.findGadgetBinding("aad20aa1-c0fa-48ef-bd05-8abe630c0012", "connections_service")
Purging all tokens
NewsOAuth2ConsumerService.purgeAllTokens()
Purges all tokens persisted in the repository. This operation should be executed if the underlying encryption method has been modified.
Example:
wsadmin>NewsOAuth2ConsumerService.purgeAllTokens()

Configuring per-host proxy access rules for OpenSocial gadgets

Proxy access is configured on a per-gadget level. This configuration is distinct from the proxy configuration file in that it specifies which end points may be contacted rather than what tokens or headers may be sent. In general the proxy access is configured during gadget registration by setting the Server access setting to external (outside the SSO domain) or all server access. Beyond these two settings, an administrator may expand or restrict access further by specifying custom proxy or (in cases where they wish for extra security) may enumerate per-gadget-per-server (and even per user) custom proxy rules. Custom proxy rules are defined in a separate configuration file.

The rule manager operates as a stack. If one rule allows the request and a second deny's the request, then the last rule to execute wins. In Connections the execution ordering is as follows:
  1. denyAll(): block all requests
  2. MasterRule(): consult the widget DB and allow or deny the request based on the gadget administrative data. Registering a gadget with "custom" causes a deny() to be pushed onto the stack
  3. Any custom rules defined in proxy-policy.dynamic: Finally the proxy-policy.dynamic file is executed. This file contains additional allow/deny rules.
Thus, custom rules you define in the policy file might override any other access decision. In the case of gadgets with "custom" server access, the gadget has no implicit server access.

The "proxy-policy.dynamic" file is located in the under LotusConnections-config/opensocial-proxy-rules. Add rules as needed as described in this topic. Unlike other configuration files, an application or server restart is NOT needed to reload the file. File changes will be detected and acted upon with-in 10-15 seconds.

A rule consists of an Action, User, Target URL, and Component.
  • The Action represents the action to be taken by the proxy when processing this rule such as "Allow" and "Deny".
  • The User represents a current user, and can be an anonymous user or system user, for example, the viewer or owner of a gadget.
  • Target URL represents the target URL to access through the proxy.
  • The Component represents the gadget that sends out the request.
The rules are specified as JavaScript program source code. Each rule is specified as a JavaScript function invocation. Four functions are provided out-of-box:
  • allow - Used to specify an ALLOW rule. This function takes three parameters:
    • Current® user's UID
    • Widget's URL - URL of the widget/gadget component that sends the request
    • Target URL - the URL that the widget/gadget wants to access.
    For example, allow('user1', 'http://www\.example.com/widget1\.xml', 'http://www\.google\.com') specifies that if the current user is 'user1', then the widget 'http://www.example.com/widget1.xml' is allowed to access URL 'http://www.google.com'.
  • deny - Used to specify a DENY rule. This function shares the same parameters as allow function.
  • allowAll - A shortcut function to allow all requests.
  • denyAll - A shortcut function to deny all requests.
When using allow and deny functions, the username, widget URL and target URL are actually regular expressions so wild cards can be used. For example, if all user names that start with 'user' is allowed, then 'user.*' can be entered as the first parameter. A guide of JavaScript regular expression pattern can be found at here. Since the rules are specified as JavaScript program source code, JavaScript code logic also can be used. You can use an if/else clause in a rule. For example, The following predefined variables also are provided:
  • user: login-id of current user
  • component : URL of the widget that sends the request
  • targetUrl : the URL to access
These predefined variables can be used in the JavaScript code. For example:
allow('user1', '.*', '.*ibm\.com'); // user1 is allowed to access all URLs that end with ibm.com
In another example of a gadget that draws from Connections data, you want to set a rule that only certain gadgets can communicate with the internet. To accomplish this you could set a global rule to prevent gadgets from connecting to secure.ibm.com and then make gadget- or user-specific rules to permit particular gadgets to do so. Or you can expose certain mail servers, but you might want extra protection so that only certain gadgets can make a request to those servers.
Here is an example of rule configuration that uses a mix of allow and deny functions:
/*

* Pre-defined variables that can be used in the script.

* _user -> Current user's UID

* _component -> Gadget URL

* _targetUrl -> Target URL to access

*/


allowAll(); // this means allow('*', '*', '*')

allow('alex', 'http://myserver/gadget1.xml', 'www.ibm.com');

deny('alex', 'http://myserver/gadget1.xml', 'www.ibm.com/private');


deny('bob', 'http://myserver/gadget2.xml', '*');

deny('*', 'http://myserver/gadget3.xml', '*');


//denyAll(); // this means deny('*', '*', '*');


if (/\S+@\S+\.ibm\.com/i.test(_user)) {  // Use regular expression

    allow(_user, '*', '*.ibm.com');  //IBM users are allowed to access IBM sites

}

Managing access

Manage roles, credentials, users, and directories, and allow third-party access to IBM Connections data.

Manage access by setting roles, creating superusers, allowing third-party applications to access data, making sure the administrator credentials are accurate, keeping users synchronized with the directory, managing inappropriate content, and enabling moderation.

Roles

Describes the roles defined for IBM Connections users on WebSphere Application Server.

The four roles that are consistent across the applications (person, everyone, reader, and admin) should be consistently set across all of the IBM Connections services.
Table 35. Activities roles
J2EE Role Description
admin Used by an administrator to manage Activities content. See Administering application content.
everyone Can access public pages without signing in to the application. There are not many pages that allow everyone to access them. The login page is an example. Do not change the default mappings for this role as it is used internally by the IBM Connections application. Changing the role will break the basic login function of the application.
person Can read and write to Activities.
reader Used exclusively by the Ajax proxy.
search-admin Used by Search to read public and private data in order to create search indexes.
widget-admin Used by widget containers to send events alerting widget applications of container changes. The widget-admin role is mapped to the user specified in the remoteHandlerAuthenticationAlias attribute defined in the widgets-config.xml file for the Activities widget. The installer sets the attribute to the connectionsAdmin alias, and maps the widget-admin role to the user specified in that alias. The user mapped to the widget-admin role must also be mapped to the person role.
Table 36. Blogs roles
J2EE Role Description
admin Used by an administrator to manage Blogs configuration and content. See Administering application content.
everyone Can access public pages without signing in to the application. Do not change the default mappings for this role as it is used internally by the IBM Connections application. Changing the role will break the basic login function of the application.
global-moderator Users in this role can moderate content. That is, they can read, edit, delete, reject, approve, quarantine, and dismiss entries and comments, and flag inappropriate content.
person Can read and write to Blogs.
reader Users in this role have read access to Blogs. If this role is mapped to the WebSphere Application Server group "All Authenticated in Application's Realm," then it forces all users to log in before they can use Blogs.
search-admin Used by Search to read public and private data in order to create search indexes.
widget-admin Used by widget containers to send events alerting widget applications of container changes. The widget-admin role is mapped to the user specified in the remoteHandlerAuthenticationAlias attribute defined in the widgets-config.xml file for the Blogs widget. The installer sets the attribute to the connectionsAdmin alias, and maps the widget-admin role to the user specified in that alias.
Table 37. Bookmarks roles
J2EE Role Description
everyone Can access public pages without signing in to the application. Some examples are the Public Bookmarks and Popular Bookmarks views, as well as the login page. Do not change the default mappings for this role as it is used internally by the IBM Connections application. Changing the role will break the basic login function of the application.
person Can read and write to Bookmarks.
reader Users in this role have read access to Bookmarks. If this role is mapped to the WebSphere Application Server group "All Authenticated in Application's Realm," then it forces all users to log in before they can use Bookmarks.
search-admin Used by Search to read public and private data in order to create search indexes.
Table 38. Communities roles
J2EE Role Description
admin Used by an administrator to manage Communities content. See Administering application content.
community-creator Users in this role can create communities. By default, this role is mapped to the WebSphere Application Server group "Everyone", but this can be changed to a more restricted user set if needed.
dsx-admin Used by the Communities directory service extension to read both public and private data. Do not add real users to this role.
everyone Not used.
global-moderator

Users in this role can see the moderation link on the navigation bar in communities. To access the moderation user interface they must also be in the Moderation global-moderator role. To actually moderate content, they must also be in the Blogs, Forums, and Files global-moderator roles. For example, for a user to moderate Blogs in a community they must be in the global-moderator roles in Communities, Moderation, and Blogs.

person Users in this role can create communities, join a public community, or request to join a moderated community. Communities Atom API creates and updates can only be performed by a user in this role.
reader Users in this role have read access to Communities. If this role is mapped to the WebSphere Application Server group "All Authenticated in Application's Realm," then it forces all users to log in before they can use Communities. This role is also used to restrict access to the Ajax proxy; it is recommended that you set reader to the WebSphere Application Server group "All Authenticated in Application's Realm" in a production environment.
search-admin Used by Search to read public and private data in order to create search indexes.
Table 39. Files roles
J2EE Role Description
admin Used by an administrator to manage Files content. See Administering application content.
everyone This role is mapped to the WebSphere Application Server group "Everyone" by default and should not be modified. Do not change the default mappings for this role as it is used internally by the IBM Connections application. Changing the role will break the basic login function of the application.
everyone-authenticated This role is mapped to the WebSphere Application Server group "All Authenticated in Application's Realm" by default and should not be modified.
files-owner Users with this role have all of the privileges of someone in the person role, but also will have a personal file stream created when they log in to files. If a user is removed from this role after they have already logged into files, they will continue to have a personal file library, but it will be hidden from the main personal files user interface for them. When changing this role, or changing members of groups in this role, consider using the Files administrative commands to browse and delete applicable personal libraries. This role does not affect who can upload files to community file libraries. It is mapped to the WebSphere Application Server group "All Authenticated in Application's Realm" by default. You can apply this role to a subset of people in the person group to limit who can upload files.
global-moderator Users in this role can moderate content. That is, they can read, edit, and delete community files and comments that have already been approved, and can reject or approve community files and comments that are awaiting approval. They can also quarantine content, restore or delete quarantined content, and dismiss flags on content.
person Users with this role have read and write access to the application. Mapped to the WebSphere Application Server group "All Authenticated in Application's Realm" by default. When this role is mapped to "All Authenticated in Application's Realm," the reader role should be mapped to "Everyone."
reader Users with this role have read-only access to the application. Mapped to the WebSphere Application Server group "Everyone" by default. When this role is mapped to "Everyone," the person role should be mapped to "All Authenticated in Application's Realm." If this role is mapped to something other than "Everyone,' the person and reader roles must have the same mappings.
search-admin Used by Search to read public and private data in order to create search indexes.
widget-admin Used by widget containers to send events alerting widget applications of container changes. The widget-admin role is mapped to the user specified in the remoteHandlerAuthenticationAlias attribute defined in the widgets-config.xml file for the Files widget. The installer sets the attribute to the connectionsAdmin alias, and maps the widget-admin role to the user specified in that alias.
Table 40. Forums roles
J2EE Role Description
admin Used by an administrator to manage Forums content. See Administering application content.
everyone Can access public pages without signing in to the application. The login page is an example. Do not change the default mappings for this role as it is used internally by the IBM Connections application. Changing the role will break the basic login function of the application.
global-moderator Users in this role can moderate content in a forum. That is, they can read, edit, delete, reject, approve, quarantine, and dismiss entries and comments, or content that has been flagged as inappropriate.
person Can read and write to Forums.
reader Users in this role have read access to Forums. If this role is mapped to the WebSphere Application Server group "All Authenticated in Application's Realm," then it forces all users to log in before they can use Forums.
search-admin Used by Search to read public and private data in order to create search indexes.
widget-admin Used by widget containers to send events alerting widget applications of container changes. The widget-admin role is mapped to the user specified in the remoteHandlerAuthenticationAlias attribute defined in the widgets-config.xml file for the Forums widget. The installer sets the attribute to the connectionsAdmin alias, and maps the widget-admin role to the user specified in that alias.
Table 41. Home page roles
J2EE Role Description
admin This role is not mapped to any users by default. This role is used to protect the Home page administrative user interface, which allows administrators to register new widgets, and to enable and disable widgets. Users in this role can see a Server metrics link in the Home page footer. Specific administrator user IDs should be mapped to this role, but you should not map this role to the WebSphere Application Server "Everyone" or "All Authenticated in Application's Realm" groups.
everyone Applies to the Home page login page and the service configuration APIs only. This role allows users to access these resources without any authentication. By default, the role is mapped to the WebSphere Application Server group "Everyone" and should not be modified. It is used internally by the IBM Connections application, and changing the role will break the basic login function of the application.
person Used to secure the Home page web user interface. Users must authenticate to access the Home page. Note that the Home page is not designed to work in an unauthenticated fashion, and therefore this role should not be mapped to the WebSphere Application Server group "Everyone." By default, this role is mapped to the "All Authenticated in Application's Realm" group, which means that all authenticated users can access the Home page. If you need to restrict access to a smaller set of people, modify the mapping of this role as needed.
reader Used to access the Search APIs. This role is mapped to the WebSphere Application Server group "Everyone" by default. Modifying this role has no effect on the Home page.
Table 42. Metrics roles
J2EE Role Description
metrics-report-run Grants users the authority to view and interact with global metrics. Other than administrators, only the users assigned to the metrics-report-run role can access global metrics. Whenever a user with this authorization level views the global metrics, the report information is updated automatically. For best results, limit access to a small set of users whose jobs require them to view the most recent metrics. Granting this level of access to a large number of users may slow performance, as update requests are processed in sequence
community-metrics-run Grants users the authority to view community metrics using static reports. Other than administrators and community owners, only the users assigned to the community-metrics-run role can access community metrics. Users with this level of access see static reports, which can be refreshed by clicking the Update button in the Metrics user interface. You can map this role to everyone, or to subset of the user population. For example, you can gradually provide the community metrics feature to the user population by mapping this role to small group first, and then adding more users to the role over time.
metrics-reader Grants users the authority to view metrics from the previous release of IBM Connections (for information, see the Connections 3.0.1 topic Collecting metrics). If you upgraded to version 4, this role remains in place with its existing assignments.
 
Table 43. Mobile roles
J2EE Role Description
everyone Applies to the Mobile page login page API. This role allows users to access these resources without any authentication. By default, the role is mapped to the WebSphere Application Server group "Everyone" and should not be modified. It is used internally by the IBM Connections application, and changing the role will break the basic login function of the application.
person Used to secure all Mobile pages other than the login page. By default, this role is mapped to the WebSphere Application Server group "All Authenticated in Application's Realm," which means that all authenticated users can access the Mobile pages. If you want to restrict access to a smaller set of people, modify the mapping of this role. Do not map this role to the WebSphere Application Server group "Everyone" because the Mobile pages page are not meant to be available to unauthenticated users.
Table 44. Moderation roles
J2EE Role Description
reader Applies to public Atom APIs. This role allows users to access these resources without authenticating. By default, the role is mapped to the WebSphere Application Server group "Everyone." Modifying this role limits access to the public APIs. For instance, mapping this role to "All Authenticated in Application's Realm" requires users to log in when accessing public Atom APIs.
everyone-authenticated This role is mapped to the WebSphere Application Server group "All Authenticated in Application's Realm" by default and should not be modified.
person Used to secure the Atom APIs for "top stories" or "saved stories" as well as to secure the Email preferences page in the product. Users must authenticate to access the New APIs and preferences page. By default, this role is mapped to the WebSphere Application Server group "All Authenticated in Application's Realm," which means that all authenticated users can access the "top stories" and "saved stories" APIs and the email preferences page. If you want to restrict access to a smaller set of people, modify the mapping of this role. Do not map this role to the WebSphere Application Server group "Everyone" because the email preferences page is not meant to be available to unauthenticated users.
global-moderator Users in this role can see the moderation interface. To actually moderate Blogs, Forums, and community Files content, they must also be in the global-moderator role of the application. For example, to moderate Blogs they must be in the global-moderator role in Moderation and in Blogs. To moderate Blogs, Forums, and Files in communities, they must also be in the Communities global-moderator role. For example, to moderate Files in a community, they must be in the global-moderator role in Communities, Moderation, and Files. After a user is in the appropriate roles, they can read, edit, delete, reject, approve, quarantine, and restore entries and comments, dismiss flags, and flag inappropriate content.
Table 45. News roles
J2EE Role Description
admin Defined in the news repository, but not used. Changing its mapping has no effect on the news repository. This role is not mapped to any users by default.
everyone This role should not be modified. It is used to define pages which should always be available, such as the login page. Do not change the default mappings for this role as it is used internally by the IBM Connections application. Changing the role will break the basic login function of the application.
person Used to secure the Atom APIs for Status Updates, News Feed stories, or Saved stories, as well as to secure the E-mail Preferences page in the product. Users must authenticate to access the News APIs and preferences page. By default, this role is mapped to the WebSphere Application Server group "All Authenticated in Application's Realm," which means that all authenticated users can access the Status Updates, News Feed stories, and Saved stories APIs, and the E-mail Preferences page. If you want to restrict access to a smaller set of people, modify the mapping of this role. Do not map this role to the WebSphere Application Server group "Everyone" because the email preferences page is not meant to be available to unauthenticated users.
reader Applies to public Atom APIs. This role allows users to access these resources without authenticating. By default, the role is mapped to the WebSphere Application Server group "Everyone." Modifying this role limits access to the public APIs. For instance, mapping this role to "All Authenticated in Application's Realm" requires users to log in when accessing public Atom APIs.
Table 46. Profiles roles
J2EE Role Description
admin Used by an administrator to manage Profiles content. See Administering application content.
allAuthenticated Mapped to the WebSphere Application Server group "All Authenticated in Application's Realm" by default. Do not change the default mappings for this role as it is used internally by the IBM Connections application. Changing the role will break the basic login function of the application. Specifically, this role is used to secure the login-redirect page and is needed to correctly redirect the user back to the page they were attempting to access before the login procedure began. Never change the default value of this role.
dsx-admin Used by the Profiles directory service extension to read both public and private data. This role secures the directory service communication when email addresses are hidden.
everyone Users with this role can access public pages without signing in to the application. The login page is an example. Do not change the default mappings for this role as it is used internally by the IBM Connections application. Changing the role will break the basic login function of the application.
person Users with this role have read and write access to the application. Mapped to the WebSphere Application Server group "All Authenticated in Application's Realm" by default.
reader Users with this role have read-only access to the application. Mapped to the WebSphere Application Server group "Everyone" by default.
search-admin Used by Search to read public and private data in order to create search indexes.
Table 47. Search roles
J2EE Role Description
admin Administrative role. No default mappings are defined for this role. The installation wizard maps the person defined as the system administrator to this role.
everyone Not used. There are no default mappings defined for this role. By default, this role is mapped to the WebSphere Application Server group "Everyone." Changing the mapping has no effect.
person Restricts access to the user interface for the Search application and personal Atom API searches (/atom/mysearch). By default, this role is mapped to the WebSphere Application Server group "Everyone," but this can be changed to a more restricted user set if needed.
reader Used to protect the Atom APIs with the exception of /atom/mysearch. This role allows users to access the resources without authenticating. By default, the role is mapped to the WebSphere Application Server group "Everyone." Modifying this role limits access to the public APIs. For instance, if you map this role to the WebSphere Application Server group "AllAuthenticated in Application's Realm," then users must log in before they can access the public Atom APIs.
Table 48. Wikis roles
J2EE Role Description
admin Used by an administrator to manage Wikis content. See Administering application content.
everyone Users with this role can access public pages without signing in to the application. The login page is an example. This role should not be modified. Do not change the default mappings for this role as it is used internally by the IBM Connections application. Changing the role will break the basic login function of the application.
everyone-authenticated This role is mapped to the WebSphere Application Server group "All Authenticated in Application's Realm" by default and should not be modified.
person Users with this role have read and write access to the application. Mapped to the WebSphere Application Server group "All Authenticated in Application's Realm" by default. The reader role should be mapped to "Everyone" when this role is mapped to "All Authenticated in Application's Realm."
reader Users with this role have read-only access to the application. Mapped to the WebSphere Application Server group "Everyone" by default. The person role should be mapped to the WebSphere Application Server group "All Authenticated in Application's Realm" when this role is mapped to "Everyone." If this role is mapped to something other than "Everyone,' the person and reader roles must have the same mappings.
search-admin Used by Search to read public and private data in order to create search indexes.
widget-admin Used by widget containers to send events alerting widget applications of container changes. The widget-admin role is mapped to the user specified in the remoteHandlerAuthenticationAlias attribute defined in the widgets-config.xml file for the Wikis widget. The installer sets the attribute to the connectionsAdmin alias, and maps the widget-admin role to the user specified in that alias.
wiki-creator Users with this role can create wikis outside of communities. Only they can see the Start a Wiki button in Wikis. This role does not affect who can create a wiki inside a community or who can create wiki pages in any wiki. It is mapped to the WebSphere Application Server group "All Authenticated in Application's Realm" by default. This does not control whether users can create wikis in communities.
Assigning people to roles
To assign a person or group to a role, complete the following steps:
  1. From the WebSphere Application Server Integrated Solutions Console, expand Applications > Application Types, and then select WebSphere enterprise applications. Find and click the link to the application that you want to configure.
  2. Click Security role to user/group mapping. Find the role that want to add users to.
  3. Select the check box next to the role that you want to assign, and then click Map users or Map groups.
  4. In the Search String box, type the name of the person or group that you would like to assign to this role, and then click Search. If the user or group exists in the directory, it is found and displayed in the Available list.
  5. Select the user or group name from the Available box, and then move it into the Selected column by clicking the right arrow button.
  6. Repeat Steps 4 and 5 to add more users to the role.
  7. Click OK.
  8. To map a user or group to a different role for another application, repeat steps 1–7.
  9. After making your changes, click OK, and then click Save to save them.
  10. Synchronize all of your WebSphere Application Server instances.
Assigning people to J2EE roles

Assign roles for IBM Connections users on WebSphere Application Server.

About this task

See Roles for definitions of the different available roles.

Procedure

To assign a person or group to a role, complete the following steps:

  1. From the WebSphere Application Server Integrated Solutions Console, expand Applications > Application Types, and then select WebSphere enterprise applications. Find and click the link to the application that you want to configure.
  2. Click Security role to user/group mapping. Find the role that want to add users to.
  3. Select the check box next to the role that you want to assign, and then click Map users or Map groups.
  4. In the Search String box, type the name of the person or group that you would like to assign to this role, and then click Search. If the user or group exists in the directory, it is found and displayed in the Available list.
  5. Select the user or group name from the Available box, and then move it into the Selected column by clicking the right arrow button.
  6. Repeat Steps 4 and 5 to add more users to the role.
  7. Click OK.
  8. To map a user or group to a different role for another application, repeat steps 1–7.
  9. After making your changes, click OK, and then click Save to save them.
  10. Synchronize and restart all your WebSphere Application Server instances.

Managing stored credentials

IBM Connections does not create nor store user names and passwords. Instead, it uses the user credentials that already exist in your LDAP directory for authentication. IBM Connections does not store administrative user IDs and passwords either. It does, however, create and store references to existing administrative user credentials. You can make changes to those references.

User credentials

To change a user's password, you must change the password in the LDAP directory that you are using to store user data. IBM Connections does not provide a method that administrators can use to change user credentials. Use the methods in place in your organization for changing user credentials. Alternatively, you can refer to the documentation provided with the LDAP directory that you are using.

Administrative credentials

When you install IBM Connections, it creates a set of references to the administrative user credentials it needs to access other tools and services to configure IBM Connections. Refer to the following topics for information on how to update these references.

Changing the WebSphere Application Server administrative user ID password

Update the password for the administrative user ID used to configure IBM Connections on WebSphere Application Server.

Before you begin
This is an optional procedure.
Procedure
  1. Refer to the WebSphere Application Server information center: http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/topic/com.ibm.websphere.base.doc/info/aes/ae/uwim_adminuserpwdsettings.html
  2. WebSphere Application Server Deployment Manager user ID only: Synchronize the nodes of the cluster to propagate the change.
  3. If the administrative user ID is used in any of the J2C authentication aliases, you must update the password associated with the alias. In the WebSphere Application Server administration console, select Security > Global security.
  4. In the Authentication area, expand Java Authentication and Authorization Service, and click J2C authentication data.
  5. Click the alias name to edit it, and then change the value in the Password field.
  6. Apply and save the changes.
  7. Restart the servers hosting IBM Connections.
Changing references to database administrative credentials

Update the aliases that reference the administrative user IDs and passwords used to manage IBM Connections databases.

Before you begin
This is an optional procedure.
Procedure
  1. Change the administrative user credentials using the tools provided with the database product that you are using.
    • DB2 Configuration Assistant
    • Oracle Enterprise Manager Console
    • SQL Server Management Studio
  2. To update the reference to the administrative user credentials that you just changed, change the credential information for the corresponding J2C authentication alias. In the WebSphere Application Server administration console, select Security > Global security.
  3. In the Authentication area, expand Java Authentication and Authorization Service, and click J2C authentication data.
  4. Click the alias name to edit it. Refer to the following tables for alias information.
    Table 49. DB2 database user IDs and aliases
    Database user ID Description Alias
    LCUSER User ID of the user with a limited set of administrative privileges to access all of the application tables in the DB2 database.

    activitiesJAASAuth

    blogsJAASAuth

    communitiesJAASAuth

    dogearJAASAuth

    filesJAASAuth

    forumJAASAuth

    homepageJAASAuth

    metricsJAASAuth

    newsJAASAuth

    profilesJAASAuth

    searchJAASAuth

    wikisJAASAuth

    Table 50. Oracle database user IDs and aliases
    Database user ID Description Alias
    BLOGSUSER User ID of the user with a limited set of administrative privileges to access the Blogs table in the Oracle database. blogsJAASAuth
    DFUSER User ID of the user with a limited set of administrative privileges to access the Forums table in the Oracle database. forumJAASAuth
    DOGEARUSER User ID of the user with a limited set of administrative privileges to access the Bookmarks table in the SQL Server and Oracle databases. dogearJAASAuth
    FILESUSER User ID of the user with a limited set of administrative privileges to access the Files table in the SQL Server and Oracle databases. filesJAASAuth
    HOMEPAGEUSER User ID of the user with a limited set of administrative privileges to access the Home page table in the Oracle database. The same user ID administers the Home page, Search, and Updates services.

    homepageJAASAuth

    newsJAASAuth

    searchJAASAuth

    METRICSUSER User ID of the user with a limited set of administrative privileges to access the Metrics table in the SQL Server and Oracle databases. metricsJAASAuth
    OAUSER User ID of the user with a limited set of administrative privileges to access the Activities table in the SQL Server and Oracle databases. activitiesJAASAuth
    PROFUSER User ID of the user with a limited set of administrative privileges to access the Profiles table in the SQL Server and Oracle databases. profilesJAASAuth
    SNCOMMUSER User ID of the user with a limited set of administrative privileges to access the Communities table in the SQL Server and Oracle databases. communitiesJAASAuth
    WIKISUSER User ID of the user with a limited set of administrative privileges to access the Wikis table in the SQL Server and Oracle databases. wikisJAASAuth
    Table 51. SQL Server database user IDs and aliases
    Database user ID Description Alias
    BLOGSUSER User ID of the user with a limited set of administrative privileges to access the Blogs table in the SQL Server database. blogsJAASAuth
    DFUSER User ID of the user with a limited set of administrative privileges to access the Forums table in the SQL Server database. forumJAASAuth
    DOGEARUSER User ID of the user with a limited set of administrative privileges to access the Bookmarks table in the SQL Server and Oracle databases. dogearJAASAuth
    FILESUSER User ID of the user with a limited set of administrative privileges to access the Files table in the SQL Server and Oracle databases. filesJAASAuth
    HOMEPAGEUSER User ID of the user with a limited set of administrative privileges to access the Home page table in the SQL Server database. The same user ID administers the Home page, Search, and Updates services.

    homepageJAASAuth

    newsJAASAuth

    searchJAASAuth

    METRICSUSER User ID of the user with a limited set of administrative privileges to access the Metrics table in the SQL Server and Oracle databases. metricsJAASAuth
    OAUSER User ID of the user with a limited set of administrative privileges to access the Activities table in the SQL Server and Oracle databases. activitiesJAASAuth
    PROFUSER User ID of the user with a limited set of administrative privileges to access the Profiles table in the SQL Server and Oracle databases. profilesJAASAuth
    SNCOMMUSER User ID of the user with a limited set of administrative privileges to access the Communities table in the SQL Server and Oracle databases. communitiesJAASAuth
    WIKISUSER User ID of the user with a limited set of administrative privileges to access the Wikis table in the SQL Server and Oracle databases. wikisJAASAuth
  5. Change the value in the Password field to reflect the change you made in Step 1.
  6. Apply and save the changes.
  7. Restart the servers hosting IBM Connections.
Changing references to administrative credentials

Update the aliases that reference the administrative user IDs and passwords used to handle server-to-server communication.

Before you begin
This is an optional procedure.
Procedure
  1. To update the aliases that manage server-to-server communication, you must edit the associated J2C authentication data for the alias. In the WebSphere Application Server administration console, select Security > Global security.
  2. In the Authentication area, expand Java Authentication and Authorization Service, and click J2C authentication data.
  3. Click the connectionsAdmin alias to edit it. You defined the current user ID and password to use for the connectionsAdmin alias during the installation. The user id and password must be one of the following values:
    • A valid user in the organization's LDAP service. Organizational security requirements may require you to change this password periodically, in which case the stored credentials will need to be updated to reflect the new password.
    • A user defined in the WebSphere Identity Manager.
  4. Update the values that have changed.
  5. Apply and save the changes.
  6. Restart the servers hosting IBM Connections.
  7. If you changed the name of the administrative user, you must update the mapping for the following J2EE roles:
    Table 52. Application J2EE roles and aliases
    Application J2EE role Alias Description
    dsx-admin connectionsAdmin Accesses user information from the Profiles or Communities databases using the corresponding directory service extensions.
    search-admin connectionsAdmin Indexes the applications to support advanced searches across the product.
    widget-admin connectionsAdmin Accesses other applications from the Communities application to support the widgets that are available within Communities.
    See Switching to unique administrator IDs for system level communication for more details.
  8. Perform some additional steps to update the messaging bus configuration, which also relies on the connectionsAdmin alias. See Updating the messaging bus configuration when the connectionsAdmin user ID changes for more details.
Switching to unique administrator IDs for system level communication

When you install IBM Connections, you provide a user name and password for a system user account that is created by the installer to handle application-to-application communication. The installer also creates a J2C authentication alias, named connectionsAdmin. The alias is filled with the specified user and maps that user to a set of application roles. If you want to map these roles to different system user accounts, create additional J2C authentication aliases and remap the roles.

Before you begin

This is an optional configuration. Only complete one of these tasks if you want to map a different user ID to the system-level roles for one or more of the IBM Connections applications.

About this task
The connectionsAdmin is mapped to roles that perform the following tasks:
Table 53. Roles associated with connectionsAdmin
Role Description
dsx-admin Used by the Profiles and Communities applications to query their corresponding databases to retrieve user or community data. When other applications need user or community data, they use the connectionsAdmin user to authenticate with Profiles and Communities, and then request the data from Profiles and Communities.
search-admin Used by all applications to control which user IDs can query for seedlist information. The seedlist data is used to create the global index. The Search application uses the connectionsAdmin user ID to authenticate with the other applications, and then makes queries to them on a scheduled basis to keep the index up-to-date.
widget-admin Used by applications that make widgets available within the Communities application, such as Activities, Blogs, Files, and Wikis. People assigned to this role can run administrative commands that make changes to those managed applications, such as to create, delete, or modify membership information. The Communities application uses the connectionsAdmin user ID to authenticate with the other applications, and then passes the requests on to them.
In addition, the connectionsAdmin user is used by the Home page application to secure the messaging bus connection.

The connectionsAdmin does not represent the administrative user of an application; it represents a system-level user for application to application communication.

To map a different user ID to one of the default roles, complete the following steps:
Procedure
  1. Perform one of the following tasks:
    • To specify a different system-level user ID for the dsx-admin, search-admin, or widget-admin roles: Create a J2C authentication alias on WebSphere Application Server by completing the following steps:
      1. From the IBM WebSphere Application Server Integrated Solutions Console, expand Security, and then select Global security.
      2. In the Authentication area, expand Java Authentication and Authorization Service, and click J2C authentication data.
      3. Click New, and then enter an alias name, user ID, and password.
        • dsx-admin: If you are creating an alias for this role and plan to enable or have enabled single sign-on with a third-party authentication manager, specify a user ID that is present in the corporate directory, and not only in the WebSphere Identity Manager.
        • search-admin: If you are creating an alias for this role, specify an alias name with the syntax: searchapplication_nameAlias where application_name is the name of the application for which you want to create the alias. For example, searchBlogsAlias.
        • widget-admin: If you are creating an alias for this role, specify an alias name with the syntax: widgetapplication_nameAlias where application_name is the name of the application for which you want to create the alias. For example, widgetActivitiesAlias.
      4. Click OK, and then click Save
      5. Repeat steps c to d for each new role that you want to create.
      6. Save your changes.
    • To specify a different system-level user ID for the connectionsBus role: Map the user ID to a security setting in the service integration buses defined for IBM Connections by completing the following steps:
      1. From the WebSphere Application Server Integrated Solutions Console, select Service integration > Buses.
      2. Click the bus to which you want to map a different user ID.
        Note: All IBM Connections buses have names that begin with Connections.
      3. Click Security > Users and groups in the bus connector role.
      4. Delete the existing user ID by selecting the check box next to the user ID and clicking Delete.
      5. To add the new user ID, click New, select User name, and then type the name of the new user ID.
      6. Click OK.
      7. Repeat steps b to f for each bus.
      8. Save the changes.
  2. If you are specifying a different system-level user ID for the widget-admin role: Edit the widget-config.xml configuration file for the application or applications affected by this change. To do so, complete the following steps:
    1. From the profile_root\config\cells\<cellName>\LotusConnections-config directory, open the widget-config.xml file in a text editor.
    2. Change the remoteHandlerAuthenticationAlias attribute in the lifecycle element for the widgetDef (widget definition) corresponding to the application that is to be changed. Replace the current value with the name of the alias that you created; include the full name of the alias, which is likely to include a node name prefix.
    3. Repeat the previous step for each application for which you defined a new alias.
    4. Save the widget-config.xml file.
  3. If you are specifying a different system-level user ID for the dsx-admin, search-admin, or widget-admin roles: Map the user in the alias to the role you want by completing the following steps:
    Attention: For Activities, you must map the person that you are mapping to the widget-admin role to the person role as well.
    1. From the WebSphere Application Server Integrated Solutions Console, expand Applications > Application Types, and then select WebSphere enterprise applications. Find and click the link to the application that you want to configure.
    2. Click Security role to user/group mapping. Find the role that you created in the Role column, and then click Map users or Map groups.
    3. In the Search String box, type the name of the person or group you would like to assign to this role, and then click Search. If the user or group exists in the directory, it is found and displayed in the Available list.
    4. Select the user or group name from the Available box, and then move it into the Selected column by clicking the arrow button.
    5. Repeat steps i and j to add additional people or groups.
    6. Repeat steps f through k to define access levels and assign people to any other aliases that you created.
    7. Click OK.
    8. Click OK, and then click Save to save the changes.
  4. If you are specifying a different system-level user ID for the dsx-admin role: Update the value of the corresponding attributes in the LotusConnection-config.xml file. To do so, start the wsadmin client , and then complete the following steps:
    1. Enter the following command to access the IBM Connections configuration file: execfile("connectionsConfig.py")

      If prompted to specify a service to connect to, type 1 to pick the first node in the list. Most commands can run on any node. If the command writes or reads information to or from a file using a local file path, you must pick the node where the file is stored. This information is not used by the wsadmin client when you are making configuration changes.

    2. Enter the following command to check out the IBM Connections configuration files:

      LCConfigService.checkOutConfig("working_directory","cell_name")

      where:
      • working_directory is the temporary working directory to which the configuration XML and XSD files are copied and are stored while you make changes to them. Use forward slashes to separate directories in the file path, even if you are using the Microsoft Windows operating system.

        AIX and Linux only: The directory must grant write permissions or the command does not run successfully.

      • cell_name is the name of the WebSphere Application Server cell hosting the IBM Connections application. This argument is case-sensitive, so type it with care. If you do not know the cell name, type the following command while in the wsadmin command processor:print AdminControl.getCell()
      For example:
      • AIX or Linux:LCConfigService.checkOutConfig("/opt/temp","foo01Cell01")
      • Microsoft Windows:LCConfigService.checkOutConfig("c:/temp","foo01Cell01")
    3. Use the following commands to update the alias information:
      LCConfigService.updateConfig("profiles.directory.service.extension.enabled",
       "true")
    4. Open the LotusConnections-config.xml file in a text editor, and then add the following values to the <sloc:serviceReference serviceName="directory"> element in the file:
      <sloc:serviceReference serviceName="directory" 
      communities_directory_service_extension_auth_alias="<alias_you_created>" 
      communities_directory_service_extension_enabled="true" 
      profiles_directory_service_extension_auth_alias="<alias_you_created>" 
      />
      where alias_you_created is the alias you created in Step 1.
    5. After making changes, you must check the configuration files back in and you must do so during the same wsadmin session in which you checked them out for the changes to take effect. See Applying common configuration property changes for information about how to save and apply your changes.
  5. Restart the application servers hosting the applications for which you created user roles.
Updating the messaging bus configuration when the connectionsAdmin user ID changes

If the connectionsAdmin alias is changed to use a different user ID than was previously configured, complete this procedure to ensure that applications can still communicate event information to the news service.

Procedure
  1. Stop all IBM Connections applications.
  2. In the WebSphere Application Server administration console, select Service Integration > Buses > ConnectionsBus.
  3. Under Additional Properties, click Security.
  4. Under Authorization Policy, click Users and groups in bus connector role.
  5. Select the check box next to the existing entry of type User that contains the old user ID, and then click Delete.
  6. Click New, and then follow the wizard instructions to add the new user ID defined for the connectionsAdmin alias.
  7. Click OK, and then save the changes.
  8. From Service Integration > Buses > ConnectionsBus, click Destinations.
  9. From the list of destinations, click connections.events.
  10. In the Message Points section, click Publication Points.
  11. For each entry in the list, click the name of the publication point, for example: connections.events@LCCluster1.000-ConnectionsBus
  12. Click the Runtime tab.
  13. Under Additional Properties, click Subscriptions.
  14. Select the check box against each subscription, so that they are all selected, and then click Delete.
  15. Repeat steps 11-14 for each publication point for the connections.events destination. There will be one publication point for each cluster in your deployment.
  16. Repeat steps 9-15 for the connections.platformCommands destination.
  17. Restart all clusters.
Changing administrative credentials for the LDAP global unique ID

When you change the credentials of the administrative user ID that serves as the global unique ID for IBM Connections, you must also update the federated repository configuration for IBM Connections.

Before you begin
This is an optional procedure.
Procedure
  1. In the WebSphere Application Server administration console, expand Security, and then select Global security.
  2. Under User account repository, make sure Federated repositories is selected from the list, and then click Configure.
  3. Click the repository identifier value of the LDAP directory you are using with IBM Connections.
  4. Update the Bind ID and Bind password fields to specify a temporary LDAP ID, and then apply your changes.
  5. Synchronize the change to all application server nodes, and then stop all application servers and restart them. Verify that you can still log in to the Integrated Solutions Console after the Deployment Manager restarts.
  6. Reset the actual production bind password in LDAP.
  7. Repeat Steps 2 through 5 to replace the temporary values that you specified for the Bind ID and password with the new ones.
  8. Restart the servers hosting IBM Connections.
Changing the password for the mail administrative user

If mail is configured to be sent from a dedicated mail server that requires authentication and you must update the credentials associated with it, you can change the password associated with mail.

Before you begin
This is an optional procedure.
Procedure
  1. Log into the IBM websphere Application Server Integrated Solutions Console, and then click Resources > Mail > Mail Sessions.
  2. Select Cell scope, and then click the session with the mail/notification JNDI name.
  3. In the Outgoing Mail Properties section, change the value in the Password field, verify the changed password, and then apply and save your changes.
  4. Restart the servers hosting IBM Connections.

Managing users

As employees come and go from your organization, the corporate directory changes, and there are some steps that you, as the administrator, must take to make sure that those changes are reflected in the product by keeping the IBM Connections membership tables up-to-date with the changes that occur in your corporate directory.

If the Profiles application is installed, when you inactivate a user or make changes to user data, such as change a person's last name or email address in the Profiles database, that change is automatically pushed out to the membership and login tables of the other IBM Connections applications.

If Profiles is not installed in your deployment, you must apply the changes to the membership tables for each application separately. The only way to update user data in the membership tables for the other applications is through a set of administrative synchronization commands.

User life cycle details

With version 3, support was added to the product to better identify whether people in the directory are "active," meaning current employees or "inactive," meaning were once listed in the directory, but have since left the company.

This feature enables users who are "inactive" to be kept in the product membership and login tables as opposed to having to be removed from the product databases entirely. This change both conserves the data the inactive user created and makes it possible for inactive employees to return to the organization and regain access to their previously created data.
Attention: This feature implements the following behavior:
  • In searches and membership selection fields, only active people are displayed by default.
  • Useful data that people no longer in the company contributed to IBM Connections applications does not have to be removed; it can remain for use by others, but the product user interface reflects the fact that the contributing user is currently inactive.
  • People who return to the company can be reactivated and can regain access to their old data.
  • Support is available to search for inactive people specifically.
Managing users when the Profiles application is installed

Managing users is easier if the Profiles application is installed and you accept the default configuration in which the Profiles directory service extension is used to retrieve data from the Profiles database instead of retrieving it from the LDAP directory. Starting with version 3, when you make changes to user status and data in the Profiles database, the changes are automatically propagated to the other application databases.

You can use one of the following methods to update user data in the Profiles database:
  • Profiles Administrative API
  • Profiles administrative commands
  • IBM Tivoli Directory Integrator scripts
Managing user data using the Profiles Administration APIs

Use the Profiles Administration APIs to synchronize data between the Profiles database and the corporate directory. You can use the APIs as an alternative to running IBM Tivoli Directory Integrator scripts to initiate changes.

See Profiles Administration API for more details.

Managing user data using Profiles administrative commands

Use administrative commands to manage Profiles users by setting their status to inactive.

Before you begin
Important: The commands in this topic are provided only as a last resort to allow the administrator to modify the data associated with a specific user in the Profiles and application databases. User data is normally automatically updated from the repository using the IBM Tivoli Directory Integrator scripts or the Profiles Administration API. The commands to update, activate, and inactivate users can introduce discrepancies between the application databases and the repository if not used carefully. It is very strongly advised that you check the data of the user in the repository prior to using these commands to avoid introducing discrepancies.

These commands should not be used to propagate directory ID changes. If the Profiles database contains an updated directory ID for a user, it will not be able to identify that user to other component applications that contain an earlier version. These commands can be useful for propagating other profile updates. If profiles in other applications remain out of synch after TDI or admin API commands have been issued, see Synchronizing user data using administrative commands.

Install and configure the IBM HTTP Server before attempting to synchronize data between the Profiles database and other application databases. See Configuring IBM HTTP Server for details.

About this task
You can manage users in Profiles to allow for situations in which employees leave the organization. For example, you can set a user's status to inactive, which allows you to reuse the associated email address and login details for new employees. You can also reactivate a user's status in situations where the user leaves the organization temporarily. For example, if a profile owner goes on sabbatical or personal leave, you can set his status to inactive and then reactivate the user's status when he returns.

When you set a user's status to inactive, that user's name is displayed in italic, gray text in membership lists, and their name is not returned in searches of the company directory. The inactive user's name no longer displays when you use type-ahead, and the person no longer receives email notifications from IBM Connections.

Procedure
  1. Start the wsadmin client from the following directory of the system on which you installed the deployment manager:
    app_server_root\profiles\dm_profile_root\bin
    Note: You must start the client from this directory or subsequent commands that you try to run will not execute properly. See Starting the wsadmin client for more details.
  2. Start the Profiles Jython script interpreter.
    1. Enter the following command to access the Profiles configuration files:
      execfile("profilesAdmin.py")
      If prompted to specify a service to connect to, type 1 to pick the first node in the list. Most commands can run on any node. If the command writes or reads information to or from a file using a local file path, you must pick the node where the file is stored.
  3. Use the following commands to manage the user life cycle:
    Table 54. Profiles user life-cycle commands
    Command Description
    ProfilesService.inactivateUser(String user_email_addr) Inactivates the user with the specified email address.

    After you run this command, the user is no longer active in the system. The email address is removed from all member tables and the status of the user changes from active (0) to inactive (1). All the user's login values are removed from the login tables and the login values associated with the user in the PROFILE_LOGIN table are removed. An event is created in which Profiles propagates these changes to the member and login tables of all installed applications to make sure the user's information is updated consistently across the application databases. The status of inactive users can be reactivated at a later time using the ProfilesService.activateUserByUserId command.

    For example:
    ProfilesService.inactivateUser("john.smith@example.com")
    ProfilesService.inactivateUserByUserId(String userID) Inactivates the user with the specified user ID. This command has the same behavior as the ProfilesService.inactivateUser command, except that it takes a user ID instead of an email address as an argument.

    After you run this command, the user is no longer active in the system. The email address is removed from all member tables and the status of the user changes from active (0) to inactive (1). All the user's login values are removed from the login tables and the login values associated with the user in the PROFILE_LOGIN table are removed. An event is created in which Profiles propagates these changes to the member and login tables of all installed applications to make sure the user's information is updated consistently across the application databases. The status of inactive users can be reactivated at a later time using the ProfilesService.activateUserByUserId command.

    Note: The userID parameter is defined in the profiles-config.xml file by the lconnUserIdField tag. The default value is guid, which is stored in Prof_guid in the profiles database. The values for Prof_guid must match the values for UserID.
    For example:
    ProfilesService.inactivateUserByUserId("ec8a89c0-f41d-102c-9b60-f225bc6c4af4")
    ProfilesService.activateUserByUserId(String user_external_id, updated_properties_list) Activates the user with the specified external ID with new properties, which are passed as parameters using updated_properties_list. The default status of any user in IBM Connections is active.

    The user_external_id parameter is the unique ID defined in the profiles-config.xml file by the lconnUserIdField tag. The default value is guid, which is stored in Prof_guid in the Profiles database.

    The valid properties for updated_properties_list are:
    • email
    • loginId. The value stored in the PROF_LOGIN field in the EMPLOYEE table.
    • logins. The list of logins stored in the PROFILE_LOGIN table.
    • displayName
    • directoryId (guid). The value stored in the PROF_GUID field in the EMPLOYEE table.
    You should specify at least one of the properties that will allow the user to log in, and it must be specified using a name-value pair.

    The status change and all property updates are propagated to all the installed IBM Connections applications.

    Examples:
    ProfilesService.activateUserByUserId("ec8a89c0-f41d-102c-9b60-f225bc6c4af4", email="jsmith@example.com", loginId="jsmith")
    ProfilesService.activateUserByUserId("ec8a89c0-f41d-102c-9b60-f225bc6c4af4", email="ajretired1@example.com", logins=["alanjones1","ajonesRetired1"])
    ProfilesService.activateUserByUserId("ec8a89c0-f41d-102c-9b60-f225bc6c4af4", email="speters_Retired1@example.com")
    ProfilesService.updateUser(String user_email_addr, updated_properties_list) Replaces the existing properties for the user with the specified email address with new properties, which are passed as parameters using updated_properties_list.
    The valid properties for updated_properties_list are:
    • email
    • displayName
    • directoryId (guid). The value stored in the PROF_GUID field in the EMPLOYEE table.
    • loginId. The value stored in the PROF_LOGIN field in the EMPLOYEE table.
    • logins. The list of logins stored in the PROFILE_LOGIN table. The list must be passed using the format: ["login1", "login2"]
    The properties are all optional and they must be specified using name-value pairs. The updated values are pushed out to all the applications in IBM Connections using a platform command.
    For example, the following command updates the email address and the login for the user john.smith@example.com.
    ProfilesService.updateUser("john.smith@example.com", email="update_email@example.com", loginId="updated_login")
    The following command replaces the existing list of logins with the new one, ("login1", "login2").
    ProfilesService.updateUser("john.smith@example.com", logins=["login1, "login2"])
    ProfilesService.updateUserByUserId(String userID, updated_properties_list) Replaces the existing properties for the user with the specified user ID with new properties, which are passed as parameters using updated_properties_list. This command has the same behavior as the ProfilesService.updateUser command, but it takes a user ID instead of an email address as an argument.
    The valid properties for updated_properties_list are:
    • email
    • displayName
    • directoryId (guid). The value stored in the PROF_GUID field in the EMPLOYEE table.
    • loginId. The value stored in the PROF_LOGIN field in the EMPLOYEE table.
    • logins. The list of logins stored in the PROFILE_LOGIN table. The list must be passed using the format: ["login1", "login2"]
    The properties are all optional and they must be specified using name-value pairs. The updated values are pushed out to all the applications in IBM Connections using a platform command.
    Note: The userID parameter is defined in the profiles-config.xml file by the lconnUserIdField tag. The default value is guid, which is stored in Prof_guid in the profiles database. The values for Prof_guid must match the values for UserID.
    For example:
    ProfilesService.updateUserByUserId("ec8a89c0-f41d-102c-9b60-f225bc6c4af4", email="update_email@example.com", loginId="updated_login")
    ProfilesService.swapUserAccessByUserId(String userToActivate, String userToInactivate) Associates the following properties of the external ID assigned to the person returning to the organization with the external ID used by the person before leaving the organization:
    • email
    • uid. The value stored in the PROF_UID field in the EMPLOYEE table.
    • guid. The value stored in the PROF_GUID field in the EMPLOYEE table.
    • loginId. The value stored in the PROF_LOGIN field in the EMPLOYEE table.
    • logins. The list of logins stored in the PROFILE_LOGIN table. The list must be passed using the format: ["login1", "login2"]
    The displayName property is not changed; it is assumed to be the same.

    Users can have access to the data associated with one or the other ID only. When you swap IDs to give a person access to the data associated with an old ID, he loses access to any data he created using the new ID. Run this command soon after the user returns to the organization to limit the amount of new data he can create and subsequently lose access to as a result of the swap.

    The following parameters are required.

    Parameters:
    userToActivate
    Current user ID of the person before leaving the organization and had his user state set to inactivate. Data that was created by this person and that is associated with this ID exists in the Lotus Connections databases and you want the person to be able to regain access to it.
    userToInactivate
    New user ID that was assigned to the person upon his return to the organization.

    Example: ProfilesService.swapUserAccessByUserId("DRcuidk001retired13","DRcuidk001rehired25")

    These changes are propagated across all the installed applications in IBM Connections.
    ProfilesService.publishUserData(String user_email_addr) Publishes an update command to all the IBM Connections applications for the user with the specified email address.

    The command publishes the data that is currently stored for the user in the Profiles database (email, displayName, logins, directoryId). If one of the applications misses an update event for some reason and the incorrect email address or name is displaying for a user, for example, you can use this command to force all the applications to resynchronize their data.

    For example:
    ProfilesService.publishUserData("john.smith@example.com")
    ProfilesService.publishUserDataByUserId(String userID) Publishes an update command to all the IBM Connections applications for the user with the specified user ID. This command has the same behavior as the ProfilesService.publishUserData command, except that it takes a user ID instead of an email address as an argument.

    The command publishes the data that is currently stored for the user in the Profiles database (email, displayName, logins, directoryId). If one of the applications misses an update event for some reason and the incorrect email address or name is displaying for a user, for example, you can use this command to force all the applications to resynchronize their data.

    Note: The userID parameter is defined in the profiles-config.xml file by the lconnUserIdField tag. The default value is guid, which is stored in Prof_guid in the profiles database. The values for Prof_guid must match the values for UserID.
    For example:
    ProfilesService.publishUserDataByUserId("ec8a89c0-f41d-102c-9b60-f225bc6c4af4")
Managing user data using Tivoli Directory Integrator scripts

There are a number of scenarios in which you might want to synchronize changes between the Profiles database and the LDAP directory, using IBM Tivoli Directory Integrator.

When you want to update user information in the Profiles database, the model typically used is to update the information in the LDAP directory and then synchronize the changes back to the Profiles database. For example, if your organization has taken over a new division, you can add new employees to Profiles by importing their details into the LDAP directory and then synchronizing the changes to the Profiles database. One way to keep your profiles data synchronized with changes to the LDAP directory is to use the sync_all_dns task. For more information, see Synchronizing LDAP directory changes with Profiles.

However, there might be instances in which your organization wants to allow users to update their information directly in the Profiles database. For example, if users want to update their personal cell phone details, as administrator, you might allow them to make the changes in Profiles themselves. These changes must be synchronized back to the LDAP directory from Profiles. To start the synchronization process, you need to define values for the DSML server-related properties in the profiles_tdi.properties file and then run the appropriate process_draft_updates script. For more information, see Synchronizing user data between Profiles and LDAP.

Although it is not expected to be a frequent occurrence, there might also be instances in which you want to change your LDAP directory. In this scenario, you can run scripts that are provided with IBM Connections to synchronize the user information used in Profiles with the user information stored in your new LDAP directory. For more information, see Updating Profiles when changing LDAP directory.

Related information is available in the IBM Tivoli Directory Integrator solutions for IBM Connections real-world scenarios wiki article.

Synchronizing source changes such as LDAP with Profiles

As administrator, you need to synchronize changes from your LDAP directory to the Profiles database to ensure that your organizational information is kept up-to-date. Use the sync_all_dns task to keep your profiles data synchronized with changes to the LDAP directory. It is recommended that you run this task on a regular basis.

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 and collect_dns_iterate 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.

The sync_all_dns 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 and sync_updates_clean_temp_files=false properties.

Note: 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.
  • employee.adds
  • employee.delete
  • employee.error
  • employee.skip
  • employee.update

Like the other IBM Tivoli 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 folder.

Procedure

To synchronize LDAP directory changes with Profiles, perform the following steps.

  1. 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.
    Note: 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 and process_ad_changes commands.
    Option Description
    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.

  2. 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:
    Note: These properties can only be used with the sync_all_dns task; they cannot be used with the process_tds_changes and process_ad_changes commands.
    Option Description
    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:
    ldap://{hostname}:port/ldap_search_base?ldap_search_filter
  3. 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.
  4. Process changes using one of the following options:
    • IBM AIX or Linux:

      chmod +x sync_all_dns.sh

      ./sync_all_dns.sh

    • Microsoft Windows:

      sync_all_dns.bat

Example
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 55. Example employee table correlating initial employee UID and DN values
uid distinguishedName (DN)
A ldap_branch1
B ldap_branch1
C ldap_branch1
X ldap_branch2
Y ldap_branch2
Z ldap_branch2
To synchronize the ldap_branch2 users, set the following properties:
  • source_ldap_url=ldap_branch2
  • sync_store_source_url=true
  • sync_source_url_enforce=true
  • sync_source_url_override=false

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:
  • source_ldap_url=ldap_branch3
  • sync_store_source_url=true
  • sync_source_url_enforce=true
  • sync_source_url_override=true
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 56. Example employee table correlating changed employee UID and DN values
uid distinguishedName
A ldap_branch3
B ldap_branch3
C ldap_branch3
X ldap_branch2
Y ldap_branch2
Z ldap_branch2
Synchronizing IBM Tivoli Directory Server and Microsoft Active Directory LDAP changes

To keep your profiles synchronized with your LDAP directory, use the generic sync_all_dns command. However, if your LDAP directory is IBM Tivoli Directory Server or Microsoft Active Directory, you can use the process_tds_changes or process_ad_changes commands.

About this task
The process_tds_changes and process_ad_changes commands do not support synchronizing multiple LDAP directories or multi-branch LDAP directories. If you have populated your profiles database with data from multiple locations, running the process_tds_changes and process_ad_changes commands applies changes related to the current LDAP directory only.
Procedure

To synchronize Tivoli Directory Server and Microsoft Active Directory LDAP directory changes with Profiles, perform the following steps.

  1. Update the change log properties in the profiles_tdi.properties file so that the changes to the LDAP directory can be reflected back to the Profiles database. The change log properties are the set of properties that begin with <LDAP_type>_changelog_*.
  2. Process changes using one of the following options:
    • For Tivoli Directory Server, use the following script to process changes made to the LDAP directory and have those changes made to the corresponding records in your database repository:
      • IBM AIX or Linux:

        chmod +x process_tds_changes.sh

        ./process_tds_changes.sh

      • Microsoft Windows:

        process_tds_changes.bat

    • For Microsoft Active Directory, use the following script to process changes made after the initial population:
      • AIX or Linux:

        chmod +x process_ad_changes.sh

        ./process_ad_changes.sh

      • Microsoft Windows:

        process_ad_changes.bat

  3. The process_tds_changes task keeps track of the changelog number in a persistent field. If your LDAP directory is reset, you can do one of the following:
    • Delete the changelog number value using the following script:
      • AIX or Linux:

        chmod +x reset_changelog_state.sh

        ./reset_changelog_state.sh

      • Microsoft Windows:

        reset_changelog_state.bat

    • Set a particular value using the following script and passing it the count value to set:
      • AIX or Linux:

        chmod +x set_changelog_count.sh

        ./set_changelog_count.sh

      • Microsoft Windows:

        set_changelog_count.bat

Synchronizing user data between Profiles and the LDAP directory

To update profiles data, you typically update the LDAP directory first and then synchronize the changes to the Profiles database. However, there are some cases where you might want to allow your users to make their own changes to their profiles, and these changes need to be written from the Profiles database back to the LDAP directory.

Before you begin
Be sure to install and configure the IBM HTTP Server before attempting to synchronize data between the Profiles database and the LDAP server. See Configuring IBM HTTP Server for more information.
About this task
You can ensure that data in the LDAP directory is kept current by synchronizing any changes made to the Profiles directory back to the LDAP server. For example, users in your organization might need to update their cell phone details in Profiles. They cannot change the LDAP directory directly and, as administrator, you can allow them to make the changes directly in Profiles. These changes need to be reflected back to the LDAP directory using the drafting process.

The draft table stores values that you edit and which you specify using the draftableAttribute element in the profiles-config.xml file. For example:

<profileDataModel>
   <!-- =================================================================================== -->
   <!-- This section is used to define attributes that are updated via the drafting process -->
   <!-- In most deployments you should never edit the config for this section.   -->
   <!-- Example: <draftableAttribute>displayName</draftableAttribute>  -->
   <!-- Example: <draftableExtensionAttribute extensionIdRef="tieline"/>  -->
   <!-- =================================================================================== -->
   <draftableAttribute>telephoneNumber</draftableAttribute>
</profileDataModel>
The Profiles database is updated immediately with the specified values.
Important: You must configure a Directory Services Markup Language (DSML) server service to receive the update requests. The Profiles application does not provide this service because each implementation of an LDAP server is unique.

To synchronize changes between the draft table and the LDAP server, you must run a script that initializes a daemon process that monitors the Profiles database for updates and, when one is made, formats the update as a DSML request and transmits it to a configured DSML server.

Procedure

To synchronize changes from the Profiles database back to your LDAP directory, complete the following steps.

  1. Define values for the DSML server-related properties in the profiles_tdi.properties file. The DSML server-related properties are the properties with names that begin with monitor_changes_ and dsml_server_. Typically, you must update the following properties:
    • monitor_changes_dsml_server_url
    • monitor_changes_dsml_server_username
    • monitor_changes_dsml_server_password
  2. After providing values for the necessary properties, start the synchronization server process by running the following scripts:
    • IBM AIX or Linux:
      chmod +x process_draft_updates.sh
      ./process_draft_updates.sh
    • Microsoft Windows:
      process_draft_updates.bat
    Note: The process_draft_update script tracks the database change record number in a persistent field. Your task cannot run successfully in the following situations:
    • You recreate the Profiles database after you have already run the IBM Tivoli Directory Integrator Solution at least once.
    • You clear the content of the CHG_EMP_DRAFT and EMP_DRAFT tables manually.
    In such situations, reset the persistent field and run the script again. You can reset the persistent field by performing one of the following steps:
    • Delete the database change record number value using the following script:
      • AIX or Linux:
        chmod +x reset_draft_iterator_state.sh
        ./reset_draft_iterator_state.sh
      • Microsoft Windows:
        reset_draft_iterator_state.bat
    • Set a particular value using the following script and pass it the count value to set:
      • AIX or Linux:
        chmod +x set_draft_iterator_count.sh
        ./set_draft_iterator_count.sh
      • Microsoft Windows:
        set_draft_iterator_count.bat
Understanding how the sync_all_dns process works

Use the sync_all_dns process to keep your profiles data synchronized with changes to the LDAP directory. The sync_all_dns process is a long running process comprised of multiple phases.

As each phase of the sync_all_dns process runs, console output indicates current progress. The number of records in the LDAP source, and in the Profiles database, enable you to estimate the running time of the process.
Note: The properties mentioned in this topic reside in the profiles_tdi.properties file.

Temporary files are created during synchronization and stored in the directory denoted by the sync_updates_working_directory=sync_updates property. By default, the temporary files are deleted at the end of synchronization. If you want to keep the files or need to troubleshoot problems, set sync_updates_clean_temp_files=false to ensure that the temporary files are not deleted.

Phase 1

The first phase processes the database. Progress is output every 10,000 records including a timestamp.

Example:
CLFRN1275I: Begin to hash records in database.
CLFRN0028I: 20120806100604 Iterations: 10000.
CLFRN1269I: Finish hash records in database.
Phase 2

The second phase processes the source with the same progress indicators as Phase 1.

Example:
CLFRN1271I: Begin to hash records in source repository.
CLFRN0028I: 20120806110738 Iterations: 10000.
CLFRN0028I: 20120806110937 Iterations: 20000.
CLFRN0028I: 20120806111137 Iterations: 30000.
CLFRN1273I: Finish hash records in source repository.
Phase 3

The third phase performs a comparison between the data retrieved in Phase 1 and 2.

Example:
**********
CLFRN1268I: After processing partition 0, 3,772 records added to creates.ldiff; 1,947 records added to deletes.dbids.
**********
CLFRN1268I: After processing partition 1, 3,823 records added to creates.ldiff; 1,951 records added to deletes.dbids.
**********
...
**********

This comparison determines if an operation should occur on a particular record from the LDAP source or from the Profiles database.

Because the operation is not complete at this point in the processing, the numbers listed in this phase do not always match the final phase numbers.

The processing is delimited by the number of partitions specified by the sync_updates_hash_partitions=10 property.

The creates.ldiff and deletes.dbids files included in this example are stored in the location specified by the sync_updates_working_directory=sync_updates property.

Phase 4

The fourth phase performs the configured delete operation using the deletes.dbids file from Phase 3 for input.

Example:
CLFRN1270I: Begin processing the data to be deleted or inactivated.
CLFRN0028I: 20120806122644 Iterations: 10000.
CLFRN1272I: Finish processing the data to be deleted or inactivated.
The operation is determined by the following properties:
  • sync_delete_or_inactivate=delete – Determines the action to be performed if a record is no longer found in the source LDAP but is present in the Profiles database.
    Note: If you want to perform additional processing during this phase, you can create and configure a custom delete option. See Customizing the logic used for the delete operation for details.
  • sync_updates_double_check=true
  • sync_check_if_remove={name-of-your-adapter.xml}:/AssemblyLines/{name-of-your-custom-delete-al}
Phase 5

The fifth phase performs the add or update operations, using the create.ldiffs file from Phase 3 for input.

Example:
CLFRN1276I: Begin processing the data to be added.
CLFRN0028I: 20120806124006 Iterations: 10000.
CLFRN0028I: 20120806124513 Iterations: 20000.
CLFRN0028I: 20120806125021 Iterations: 30000.
CLFRN1274I: Finish processing the data to be added.
Summary phase

A summary is displayed at the end of the sync_all_dns process.

Example:
CLFRN0037I: After synchronization, added or modified records is 37971, deleted or inactivated record
s is 19551, unchanged records 0, and failure records is 0. 
Lists of the users for each of the operations are stored in the following files in the solution directory. You can examine these files when the synchronization process has completed. These files are not considered temporary and are not removed at the end of the synchronization process.
  • employee.adds – These records were added to the database
  • employee.delete – These records were deleted or inactivated in the database
  • employee.error – There was an error processing these records
  • employee.skip – These records were not changed in the database
  • employee.update – These records were updated in the database
Updating Profiles when changing LDAP directory

When you need to change to a new LDAP directory, you must synchronize the user data stored in profiles with the information in your new LDAP directory. You can run a command that synchronizes the information in the Profiles database with the user information stored in your new LDAP deployment.

Before you begin
You must ensure that the values of either the uid or the email address in the existing data source match those in the new deployment LDAP directory. If neither of these properties have matching values, you cannot use the scripts provided with IBM Connections to synchronize the IDs.
Procedure

To use the scripts provided with IBM Connections to synchronize the IDs and update Profiles, complete the following steps:

  1. Open the profiles_tdi.properties file from the IBM Tivoli Directory Integrator 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
    For more information about these properties and how they are used, see Tivoli Directory Integrator properties.
  2. Ensure that the guid property in the map_dbrepos_from_source.properties file is set to the appropriate value for your environment:
    • 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
    • eNovelle System Directory Server:
      guid={unction_map_from_GUID}
  3. Identify a database attribute, either uid or email, with the same value per member in the old LDAP deployment as in the and the new deployment, and then set the sync_updates_hash_field property in the profiles_tdi.properties file to this attribute. The names of the LDAP attributes are immaterial.
    sync_updates_hash_field=uid
  4. 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
    • Microsoft Windows:
      sync_all_dns.bat
    For more information about the properties that you can set when synchronizing LDAP data with Profiles, see Synchronizing LDAP directory changes with Profiles.
Deleting or inactivating users in the Profiles database

You can use an IBM Tivoli Directory Integrator assembly line command to delete or inactivate users in the Profiles database.

About this task
You can use the delete_or_inactivate_employees assembly line command to delete specific users from the Profiles database or set their status to inactive.
Procedure

To delete or inactivate specific users from the Profiles database, complete the following steps:

  1. Create a text file named delete_or_inactivate_employees.in that contains the distinguished names and user IDs for the users that you want to delete from the database. Use the following format to represent a user:
    $dn:user_dn
    uid:user_uid
    .
    where:
    • user_dn corresponds to the PROF_SOURCE_UID in the Profiles database.
    • user_uid corresponds to the PROF_UID in the Profiles database.
    Note: When deleting multiple users, there must be a period separator (.) between each entry. The "." must be added after the row containing the user's UID. If the separator is omitted, an error occurs when you use the delete command to delete the users from the database.
    Note: Do not add a space after the colon and before the value.
    Here is an example of an entry from the delete_or_inactivate_employees.in file:
    $dn:cn=Amy Jones3,cn=Users,l=WestfordFVT,st=Massachusetts,c=US,ou=Lotus,o=Software Group,dc=ibm,dc=com
    uid:Amy Jones3
    .
    When loading multiple users, there must be a period separator between each entry.
    For example:
    $dn:cn=Amy Jones3,cn=Users,l=WestfordFVT,st=Massachusetts,c=US,ou=Lotus,o=Software Group,dc=ibm,dc=com
    uid:Amy Jones3
    .
    $dn:cn=Amy Jones8,cn=Users,l=WestfordFVT,st=Massachusetts,c=US,ou=Lotus,o=Software Group,dc=ibm,dc=com
    uid:Amy Jones8
    .
  2. Place the file in the Tivoli Directory Integrator location specified for your deployment. For more information, see Configuring Tivoli Directory Integrator.
  3. Run the delete_or_inactivate_employees.sh or delete_or_inactivate_employees.bat script to delete the users from the database. The following table shows the properties that are used by the command and their default values. These properties can be found in the profiles_tdi.properties file.
    Note:

    The file path is relative to the TDI solution directory.

    Table 57. Properties used with the delete_or_inactivate_employees command
    Property Description
    delete_or_inactivate_employees_simple_file File that you created in Step 1, which lists the people to be deleted or inactivated. The default value is delete_or_inactivate_employees.in.
    sync_delete_or_inactivate Specifies whether to delete or inactivate the people listed in the file specified using the delete_or_inactivate_employees_simple_file property. The options are:
    delete
    Removes the user from the Profiles database and, if the user exists in member or login tables for any of the other applications, deletes the user from those applications. The person’s email address is removed, all login values associated with the person are removed, and the photo and pronunciation files associated with the employee are deleted from the photo and pronunciation tables. You cannot add deleted users back into the directory and you cannot recover any data that they created after you delete them.
    inactivate
    Sets the person's status to inactive. Unlike deleting people, when you inactivate people, you can reinstate them later if necessary. See Managing user data using Profiles administrative commands for more details. Any data created by the inactive person is preserved. An inactive person is identifiable in the product user interface because the person's name is greyed out, but information they contributed, to a community or forum, for example, is retained. An inactive person’s name is not included in searches and membership selection fields.

    The default value is inactivate.

    The inactivation of the person is propagated to the member and login tables for all the applications.

Customizing the logic used for the delete operation

You can customize the delete logic to use when deleting users from the Profiles database.

About this task
IBM Connections provides a plug-in point for defining and using custom IBM Tivoli Directory Integrator (TDI) assembly lines that contain their own delete logic as part of the sync_all_dns task. This delete logic is used to identify when a user needs to be deleted from the Profiles database. An assembly line named sync_all_dns_check_if_remove, which checks whether a user should be deleted, is provided by default. You can add custom delete logic without making changes to the existing profiles_tdi.xml file.
Procedure
  1. Configure your development environment for creating a delete logic script by following the steps in the topic, Setting up your development environment.
  2. Define an assembly line that contains your delete logic in the file. Your assembly line must return one of the following values:
    • remove. Specifies that the current entry should be added to the delete list.
    • updated. Specifies that the current entry should be updated, not deleted.
    These values are case-sensitive.
    Return the value as follows:
    1. Retrieve the checkResult attribute field from the work object into your assembly line. The attribute name is case-sensitive.
    2. Set your checking result to the value of the checkResult attribute.
    For example:
    checkingResult = work.getAttribute("checkResult");
    checkingResult.setValue("updated");

    For more information about how to create an assembly line, go to the following web page:
    http://publib.boulder.ibm.com/infocenter/tivihelp/v2r1/index.jsp?topic=/com.ibm.IBMDI.doc_7.0/CreatingyourfirstassemblyLine.htm

  3. Use the publish feature to export the assembly line as a Tivoli Directory Integrator adapter.
    1. Right-click the assembly line in the Navigator and select Publish.
    2. Enter the name of the adapter in the Package ID field.
    3. Specify the following directory in the File Path field, and then click Finish.
      profiles_tdisoln/packages
  4. Add a reference to the profiles property store to your adapter files by running the fixup_tdi_adapters.sh or fixup_tdi_adapters.bat command.
    Note: This reference is required to use the Profiles Tivoli Directory Integrator adapter. Even if you do not believe that your adapter file requires access to the profiles property store, there is no penalty for adding the reference so it is strongly advised that you run this command regardless.
  5. Open the profiles_tdi.properties file from the following location:

    tdisol.tar|zip/tdisol/TDI

  6. Set the following properties in the file:
    sync_updates_double_check
    Specifies whether your checking assembly line is used. When set to true, your deletion-checking assembly line is used. When set to false, the checking operation is not performed. The default value is false.
    For example:
    sync_updates_double_check=true
    sync_check_if_remove
    Specifies the name of your checking assembly line:
    sync_check_if_remove=name_of_your_adapter_xml_file:/AssemblyLines/name_of_your_assemblyline
    By default, the assembly line's name is set to sync_all_dns_check_if_remove.
    For example, if you publish the assembly line with the file name deleteCheckRoutines and the assembly line is example_check_if_user_really_deleted, use the following statement to set this property:
    sync_check_if_remove=deleteCheckRoutines:/AssemblyLines/example_check_if_user_really_deleted
    sync_delete_or_inactivate
    Controls what happens to a user record when the delete action is performed. This property can be set to one of the following values:
    • delete. Specifies that the user record is deleted.
    • inactivate. Specifies that the user record is inactivated.

      The inactive status is propagated to the member and login tables for all the applications. An event is generated for each of the following: Activities, Blogs, Bookmarks, Communities, Files, Forums, Profiles, Wikis, and News (which includes both Home page and Search). These events inactivate the user in every application by removing the user from the login tables and setting the user's status to 1 in all member tables.

    These values are case-sensitive so type them with care. The default value is inactivate.
    For example:
    sync_delete_or_inactivate=inactivate
  7. Save your changes to the profiles_tdi.properties file.
Managing users when the Profiles application is not installed

If the Profiles application is not installed, you must manage changes to user status and data in each application database independently. The only way to update user data in the databases for the other applications is through a set of administrative synchronization commands.

These commands can also be used on IBM Connections deployments that do have Profiles installed to resolve situations where an application's membership database table needs to be corrected.

Synchronizing user data using administrative commands

Synchronize user data between the IBM Connections application membership tables and the configured directory for the deployment.

Each Connections application has its own database with membership tables containing a users external ID and user data related to that application. These databases must be synchronized with the configured directory in the deployment. The configured directory is typically the Profiles database in deployments where Profiles is installed and Profiles integration is enabled. If Profiles is not installed or is installed but Profiles integration is not enabled, then the configured directory is the corporate LDAP directory.

The commands documented in this topic synchronize user data between the application databases and the configured directory in your environment. They also log entries in the application_name\UlcSyncCmd.log file that reports updated data items.

Note: When Profiles is installed, you should not generally use these commands. Profiles automatically synchronizes its user data with the application databases. Also, there is a set of Profiles administration commands for synchronizing in that environment. However, you can use these commands to resolve situations where an application database needs to be corrected. For example, if synchronization occurs for all but one application and you have a mismatch in that application’s database.

Many of the synchronization commands have a matching preview command that shows you what the synchronization command would do if you ran it. For example, the FilesMemberService.previewSyncAllMembersByExtId command generates a log showing what the FilesMembersService.syncAllMemberByExtId command would do if you ran it. This can be useful when mismatches are suspected. The logs are located in the standard logging directory for the server, for example where the cluster’sSystemOut.log file is located, and the name is application_name\UlcSyncCmd.log. Output is appended if the log file already exists.

You should run preview versions of commands before running the actual commands. When you are sure the command will do what you want, run the actual command.

The following commands, identified by the leading wsadmin> parameter, update the Communities membership database.
  1. Initialize the Communities commands and then preview what the synchronize all command would do.
    wsadmin>execfile("communitiesAdmin.py")
    wsadmin>CommunitiesMemberService. previewSyncAllMembersByExtId({"updateOnEmailLoginMatch":
    "true", "verbose" : "true"}
    UpDt ExtId: f1a8d8c0-a59b-1030-85a9-c32c2f3a2ad1XX Name: Jane Doe has a superseded external ID,
    and would have been updated: New ExtId: f1a8d8c0-a59b-1030-85a9-c32c2f3a2ad1
    [2012-08-07 14:50:54] Additional application possibly-stale member data: Email:
    jane_doe@us.acme.com Logins: [Doe, jane_doe@us.acme.com, Jane Doe]
    [2012-08-07 14:50:54] Directory service basic user data: Display name: Jane Smith Update
    External id: f1a8d8c0-a59b-1030-85a9-c32c2f3a2ad1
    [2012-08-07 14:50:54] Directory service email and logins: Email: sTestuser5@janet.iris.com
    Logins: [Smith, Jane Smith, jane_doe@us.acme.com]

    The command reveals that the user’s external ID in Communities is obsolete.

  2. Run the following command to update the user’s external ID. Note that the preview sync all users command has been replaced by the more specific sync by email. You could use the syncAllMembersByExtId() parameter associated with the preview but it is best to use the most specific command.
    wsadmin>CommunitiesMemberService.syncMemberExtIdByEmail("jane_doe@us.acme.com ")
    
    CLFWY0263I: The synchronize command found that active member Jane Smith [current external id:
    f1a8d8c0-a59b-1030-85a9-c32c2f3a2ad1XX, application id 6a716827-5fc8-438a-beb2-777f6f5d96df]
    could not be matched via external id, but could be matched via login or email to external id
    f1a8d8c0-a59b-1030-85a9-c32c2f3a2ad1. 
    The member was updated because this action was enabled by the command.
Only use the commands in this topic to synchronize user data in the following situations:
  • Profiles is not installed, or Profiles integration is disabled.
  • You have just migrated from an earlier version of Connections.
  • You want to synchronize data for a specific application or a specific person in a specific application.
  • You want to determine if any application member data is out of sync with the configured directory.
Administrative commands

Use the following commands to update the identifying data and state (active or inactive) of the users listed in the application database, except for Profiles where you would use Tivoli Directory Integrator (TDI) to synchronize users in the Profiles database with a source LDAP database.

The use of square brackets indicates that the enclosed parameters are optional; the square brackets are not part of the command line.

The application_name variable represents the name of the application. The following options are available:
  • Activities
  • Blogs
  • For Bookmarks, specify Dogear
  • Communities
  • Files
  • Forums
  • News repository: The Home page, News repository, and Search applications share the same database, so running the synchronization command against News repository applies to all three areas.
  • Profiles
  • Wikis
  • Metrics
application_nameMemberService.syncAllMembersByExtId( {"updateOnEmailLoginMatch": ["true" | "false"] } )
This checks to see if the external ID found in the member database table is present in the configured directory as follows:
  • If the external ID is present, then the command gets the display name, email address, and login names from the configured directory and updates the application database tables with the values from the directory, if they are different. This refresh update operation is not logged to the output file.
  • If a match for the user's external ID is not found in the directory, then the command uses the email address and login names contained in the application database tables to continue to search for the user in the configured directory. When none of the credentials match the user is inactivated. How the command works when a match on the login names or email address is found differs depending on the parameter you specified with the command:
    Parameter: updateOnEmailLoginMatch: String. Options are true or false. The default is false.
    true
    Specifies that when a match is found in the configured directory based on the login names or email address of the user, the external ID in the application database is automatically updated with the external ID in the configured directory.
    false
    Specifies that when a match is found in the configured directory based on the login names or email address of the user, the external ID in the application database is written to the application_nameUIcSyncCmd.log file. You can manually make the update after confirming that the change should be made.
  • If a match for the user's external ID is not found in the configured directory, nor is a match found for the user's email address and login names, then the state of the user is changed to inactive in the application database.
Note: When none of the credentials match, the Boolean (true or false) parameter is ignored; the user is always inactivated.
application_nameMemberService.previewSyncAllMembersByExtId( {"updateOnEmailLoginMatch": ["true" | "false" ][, “multiLine” : ["true" | "false"] ] [, “verbose” : ["false" | "true"] ] }] )

The preview command reports the action the corresponding syncAllMembersByExtId command would take (or not take) depending on the updateOnEmailLoginMatch parameter value. The results are placed in the application_nameUlcSyncCmd.log file.

There are two optional parameters, multiLine and verbose, both of which take a Boolean string value. The default value is true for multiLine and false for verbose. If multiLine is true, each action report is broken into multiple short lines to make it easier to read. If multiline is false, each action report is a single line for ease of searching the file programmatically, for example with a grep utility. If verbose is false, only out of sync results are reported independent of the value of updateOnEmailLoginMatch. This includes members that would simply be refreshed. A member is refreshed if the member is active and the external ID is a match, but the display name, email, or the logins don’t match. If verbose is true, all members are reported, including active and inactive members.

The format of each reported action is timestamp, action code, action data and action message. The code is a four letter code, listed at the end of this section. At the end of the file five numbers are reported. These are also explained at the end of this section. At the very end of the file is a number that is the total actionable items found.

application_nameMemberService.syncMemberByExtId("currentExternalId"[, {"newExtId" : "id-string" [, "allowExtIdSwap" : ["true" | "false"] ] } ] )
This determines whether the user identified by the first parameter, which is an eternal ID, should be is active or inactive by checking the configured directory for the external ID. The main purpose of this command is to reactivate a user.
Note: This is a complicated command that should be used carefully, particularly when swap is allowed.
You can perform the following tasks with this command:
  • When only currentExternalId parameter is provided, the intent is to correct the state information for that user in the application database.
    Parameters:
    currentExternalId
    String. Unique external ID that represents a user. The command looks for this external ID in the application member table. If it does not find the ID, an error is generated. If the member is found, but is currently defined as inactive, an attempt is made to activate the member. To do so, the command looks up whether the member exists in the configured directory, and if so, then the member is activated in the application member table and the associated display name, email and login values for that member are restored. When this action is taken, the update is logged in the applicationUIcSyncCmd.log file. If the member is found and is currently defined as "active" in the application database, the code first looks up currentExternalId in the configured directory. If currentExternalId is not found, the command attempts to find the member by email or login value. If this succeeds, the external ID is updated along with a refresh of display name, email, and logins, and the change is logged. If this does not succeed, then the user is inactivated and the change is logged.
    Example:
    CommunitiesMemberService.syncMemberByExtId("F8E59CA4-7FE1-4195-AA96-A49CE5F8E17F")
  • When multiple parameters are provided, the intent is to activate the user identified by currentExternalId with the identity of the user defined by the newExtId. This command might be used when a user has application content, such as a Community, on the server but then leaves the company. The user is removed from the LDAP and the user's state is set to inactive in the application database tables. However, if that person is rehired by the company, the person is added back into LDAP and is assigned a new external ID. For this person to gain access to their old content, you can use the following command to swap their external IDs.
    Parameters:
    currentExternalId
    String. Unique ID that represents a user.
    newExtId
    Optional. String. If you provide this parameter:
    1. The same person is being represented by two different external IDs: the currentExternalId is in the application database where the member is marked as inactive and the newExtId, is stored in the configured directory.
    2. The newExtId updates that person’s external ID in the application database and the person is marked active.
    Important: Only use this command when you are sure that the two IDs represent the same person.
    allowExtIdSwap
    Optional. String. Accepts the values true or false. The default value is false. Specifies whether to swap the new and current ID of the user in the two records that represent the same person. This parameter is only needed if the user was previously employed by the organization and existed in the application member tables with the current ID, departed the organization, and was given a new ID upon returning. After that person logs in to an application for the first time with their new ID, the new ID is added to the application member tables. If you want this new user to have access to the content that she created previously using the current ID, provide this parameter and set it to true. However, be sure to run this command soon after the person returns because once the IDs are swapped, the user is not able to access any new content that she created using the new ID, just her previous content. You cannot merge the data associated with the current and new IDs. If you provide this parameter and set it to false, an error message is displayed in the wsadmin client that indicates that the command could not complete because the newExtId already exists.
    Example:
    CommunitiesMemberService.syncMemberByExtId("7d71d8b2-7de511df-80b6c81b-5330ca0e", 
     {"newExtId": "7d71d8b3-7de511df-80b6c81b-5330ca0e", "allowExtIdSwap": "true"})
application_nameMemberService.inactivateMemberByEmail("email-address")
This marks the person identified by email-address as inactive in the application's membership database tables, for example it changes the state of the specified user to inactive. In addition, the email address and login names for this user are removed from the application's database tables. The user's external ID and Display Name are not modified. The command also writes a status message to the application_nameUlcSyncCmd.log file indicating that the user has been deactivated.
Parameter:
email-address
String. Email address of the user you want to mark as inactive in the application membership database tables.
application_nameMemberService.inactivateMemberByExtId("externalID")
This marks the person identified by external ID as inactive in the application's membership database tables. This command changes the state of the specified user to inactive. In addition, the email address and login names for this user are removed from the application's database tables. The user's external ID and Display Name are not modified. The command also writes a status message to the application_nameUlcSyncCmd.log file indicating that the user has been deactivated.
Parameter:
externalID
String. Unique ID that represents the user you want to mark as inactive in the application membership database tables.
application_nameMemberService.getMemberExtIdByEmail("email")
This retrieves the external ID of the person identified in the email parameter and returns it to the wsadmin console. The external ID returned from this command can be used as input to some of the other wsadmin commands that require the user's external ID as an input parameter.
Parameter:
email
String. Email address of the user whose external ID you want to retrieve.
Example:
  • Command:
    wsadmin>CommunitiesMemberService.getMemberExtIdByEmail("userB@example.com")
  • Result:
    510b99c0-0101-102e-8923-f78755f7e0ed
application_nameMemberService.getMemberExtIdByLogin("login")
This retrieves the external ID of the person identified in the login parameter and returns it to the wsadmin console. The external ID returned from this command can be used as input to some of the other wsadmin commands that require the user's external ID as an input parameter.
Parameter:
login
String. Login name of the user whose external ID you want to retrieve.
Example:
  • Command:
    wsadmin>CommunitiesMemberService.getMemberExtIdByLogin("User A")
  • Result:
    806edb40-e8ba-102e-91cd-d74ea1c96b51
Additional administrative commands
The following commands were available in previous releases. Some have been updated to enable you to change the user state of a person from active to inactive or inactive to active. You might want to use these commands in the following cases:
  • To synchronize a batch of users from a file based on their login names and emails instead of external IDs.
  • To synchronize a particular user by login name or email, instead of by external ID.
The application_name variable represents the name of the application. The following options are available:
  • Activities
  • Blogs
  • For Bookmarks, specify Dogear
  • Communities
  • Files
  • Forums
  • News repository: The Home page, News repository, and Search applications share the same database, so running the synchronization command against News repository applies to all three areas.
  • Profiles
  • Wikis
Note: The application_nameMemberService.syncAllMemberExtIds() command was deprecated in version 3.
application_nameMemberService.syncBatchMemberExtIdsByEmail("emailFile" [, {"allowInactivate" : ["true" | "false"] } ] )

The command application_nameMemberService.syncBatchMemberExtIds(filename) was deprecated in version 2.5. Use this command or the syncBatchMemberExtIdsByLogin(loginFile) command instead.

This synchronizes a list of users contained in the specified text file. The text file must define one email address per line. If a match is found, for example the email address identifies a member, the command retrieves the external ID in the application member table and looks it up in the configured directory. If the external ID is found, then the user's display name and any additional login names are refreshed if needed, so that they match those in the configured directory. The refresh operation is not logged.

If the external ID is not found in the configured directory, then a synchronize operation is performed based on the email and login values and the user's external ID in the member table is updated with the external ID in the configured directory. Also, the user's display name, and any additional login names are refreshed. Each user that is synchronized by this operation is logged in the log file. If the user cannot be found in the configured directory by any means (external ID, login names, or email) then the user may be inactive. The command can do one of two things in this situation, depending on whether the following allowInactivate input parameter is set to true or false.

Parameters:
emailFile
String. Path and name of text file that contains one entry per line of user email addresses (jdoe@example.com).
allowInactivate
String. Options are true or false. Specify one of these values to allow changes to the state of the user.
If true, the user is inactivated in the member table of the application database if there is no match. The user's email and login names are deleted from the table and the state flag is set to inactive.
If false or null, the user is not made inactive. Instead, a log message is written to the log file.
For example:
ActivitiesMemberService.syncBatchMemberExtIdsByEmail("c:/foo/bar/my_sync_file.txt", 
 { "allowInactivate":"true"})
application_nameMemberService.previewSyncBatchMemberExtIdsByEmail("emailFile"[, { "allowInactivate" : ["true" | "false"] [, "multiLine" : ["true" | "false"] ] [, "verbose" : ["true" | " false"] ] } ] )
See the description of preview commands under the previewSyncAllMembersByExtId() command at the beginning of this section. Note that the default value for the verbose parameter is true.
application_nameMemberService.syncBatchMemberExtIdsByLogin("loginFile" [, {"allowInactivate" : ["true" | "false"] } ] )

The command application_nameMemberService.syncBatchMemberExtIds(filename) was deprecated in version 2.5. Use this command or the application_nameMemberService.syncBatchMemberExtIdsByEmail(emailFile) command instead.

This synchronizes a list of users contained in the specified text file. The text file must define one login name per line. For each login name, if a match is found the command checks the external ID in the application member table against the value in the configured directory to see if it matches. If the external ID matches, then the user's email address and display name and any additional login names are refreshed if needed so that they match those in the configured directory. The refresh operation is not logged.

If the external ID is not found in the configured directory, then a synchronize operation is performed based on the email and login values and the user's external ID in the member table in the application database is updated with the external ID in the configured directory. Also, the user's email, display name, and any additional login names are refreshed. Each user that is synchronized by this operation is logged in the log file. If the user cannot be found in the configured directory by any means (external ID, login names, or email) then the user may be inactive. The command can do one of two things in this situation, depending on whether the allowInactivate input parameter is set to true or false (see the following explanation of the two flags).

Parameters:
loginFile
String. Path and name of a text file that contains one user login name entry per line.
allowInactivate
String. Options are true or false. Specify one of these values to allow changes to the state of the user.
If true, the user is inactivated in the member table of the application database if there is no match. The user's email and login names are deleted from the table and the state flag is set to inactive.
If false or null, the user is not made inactive. Instead, a log message is written to the log file.
This command does not return anything.
For example:
ActivitiesMemberService.syncBatchMemberExtIdByLogin("c:/foo/bar/login_sync_file.txt", 
 { "allowInactivate":"false"})
application_nameMemberService.previewSyncBatchMemberExtIdsByLogin("loginFile" [, { "allowInactivate" : ["true" | "false"] [, "multiLine" : ["true" | "false"] ] [, "verbose" : ["true" | " false"] ] } ] )
See the description of preview commands under the previewSyncAllMembersByExtId() command at the beginning of this section. Note that the default value for the verbose parameter is true.
application_nameMemberService.syncMemberExtIdByEmail("email" [, { "allowInactivate" : ["true" | "false"] } ])

The command application_nameMemberService.syncMemberExtId(java.lang.String key) was deprecated in version 2.5. Use this command or the syncMemberExtIdByLogin(java.lang.String loginName) command instead.

This synchronizes the member record in the application member table identified by the member's email address parameter. If a match is found, for example the email address identifies a member, the command retrieves the external ID in the application member table and looks it up in the configured directory. If the external ID is found, then the user's email address and display name and any additional login names are refreshed as needed so that they match those in the configured directory. The refresh operation is not logged.

If the external ID is not found in the configured directory, then a synchronize operation is performed based on the email and login values and the user's external ID in the member table is updated with the external ID in the configured directory. Also, the user's email, display name, and any additional login names are refreshed. Each user that is synchronized by this operation is logged in the log file. If the user cannot be found in the configured directory by any means (external ID, login names, or email) then the user may be inactive. The command can do one of two things in this situation, depending on whether the allowInactivate input parameter is set to true or false (see the following explanation of the two flags).

Parameters:
email
String. A user's email address.
allowInactivate
String. Options are true or false. Specify one of these values to allow changes to the state of the user.
If true, the user is inactivated in the member table of the application database if there is not match. The user's email and login names are deleted from the table and the state flag is set to inactive.
If false or null, the user is not made inactive. Instead, a log message is written to the log file.
For example:
ActivitiesMemberService.syncMemberExtIdByEmail("jdoe@example.com", 
 {"allowInactivate":"false"})
application_nameMemberService.previewSyncMemberExtIdByEmail("emailAddr" [, { "allowInactivate" : ["true" | "false"] [, "multiLine" : ["true" | "false"] ] [, "verbose" : ["true" | " false"] ] } ] )
See the description of preview commands under the previewSyncAllMembersByExtId() command at the beginning of this section. Note that the default value for the verbose parameter is true.
application_nameMemberService.syncMemberExtIdByLogin("name" [, {"allowInactivate": ["true" | "false"] } ])

The command application_nameMemberService.syncMemberExtId(java.lang.String key) was deprecated in version 2.5. Use this command or the application_nameMemberService.syncMemberExtIdByEmail(java.lang.String emailAddress) command instead.

This synchronizes the member record in the application member table identified by the user login name parameter. If a match is found, for example the email address identifies a member, the command retrieves the external ID in the application member table and looks it up in the configured directory. If the external ID is found, then the user's email address and display name and any additional login names are updated so that they match those in the configured directory. The refresh operation is not logged.

If the external ID is not found n the configured directory, then a synchronize operation is performed and the user's external ID in the member table is updated with that of the external ID in the configured directory. Also, the user's email, display name, and any additional login names are refreshed. Each user that is synchronized by this operation is logged in the log file. If the user cannot be found in the configured directory by any means (external ID, login names, or email) then the user may be inactive. The command can do one of two things in this situation, depending on whether the allowInactivate input parameter is set to true or false.

Parameters:
name
String. User login name.
allowInactivate
String. Options are true or false. Specify one of these values to allow changes to the state of the user.
If true, the user is inactivated in the member table of the application database if there is not match. The user's email and login names are deleted from the table and the state flag is set to inactive.
If false or null, the user is not made inactive. Instead, a log message is written to the log file.
For example:
ActivitiesMemberService.syncMemberExtIdByLogin("jdoe", {"allowInactivate":"true"})

To understand the ‘preview’ version of the command see the explanation of preview under the previewSyncAllMembersByExtId() command at the beginning of this section. Note that the default value for the verbose parameter is true.

application_nameMemberService.previewSyncMemberExtIdByLogin("name"[, { "allowInactivate" : ["true" | "false"] [, "multiLine" : ["true" | "false"] ] [, "verbose" : ["true" | " false"] ] } ])
See the description of preview commands under the previewSyncAllMembersByExtId() command at the beginning of this section. Note that the default value for the verbose parameter is true.
Sample user management scenarios

The following scenarios address some of the common tasks involved in managing user data within an organization.

User management commands allow the administrator to push LDAP changes from Profiles to the other applications so that as data in Profiles is added and updated, these changes can be easily captured and propagated to the rest of IBM Connections. An extension hook to IBM Tivoli Directory Integrator is also provided, allowing administrators to add custom logic for determining if a user has left the system or has been affected by a human resources action that might prevent Tivoli Directory Integrator from being able to match their old employee record with their new employee record. Examples of such actions typically include users moving from part-time to full-time or transferring from one country to another.

Improving directory synchronization

Use this procedure to help keep track of users as they transition from part-time to full-time or from one country to another and enable your IBM Tivoli Directory Integrator solution to handle actions that could otherwise lead to orphaned user data.

Before you begin
To strengthen your Tivoli Directory Integrator (TDI) scripts, your organization must maintain data in the LDAP directory that allows you to connect the old employee record with the new employee record.
About this task
Certain HR-related actions can result in orphaned user data by causing the value in the uid field in the LDAP directory to change. Tivoli Directory Integrator uses the uid field to synchronize data so any action that changes the value of the field will cause the user to appear as a completely new user to the Tivoli Directory Integrator scripts. Examples of HR actions that can have this effect include moving users from part-time to full-time or from one country to another country.

To strengthen your Tivoli Directory Integrator solution, define and use a custom assembly line that specifies the delete logic to use to identify when a user needs to be deleted from the Profiles database.

Procedure
  1. Configure your development environment for creating a delete logic script by following the steps in the topic, Setting up your development environment.
  2. Define an assembly line that contains your delete logic in the file. Your assembly line must return one of the following values:
    • remove. Specifies that the current entry should be added to the delete list.
    • updated. Specifies that the current entry should be updated, not deleted.
    These values are case-sensitive.
    Return the value as follows:
    1. Retrieve the checkResult attribute field from the work object into your assembly line. The attribute name is case-sensitive.
    2. Set your checking result to the value of the checkResult attribute.
    For example:
    checkingResult = work.getAttribute("checkResult");
    checkingResult.setValue("updated");

    For more information about how to create an assembly line, go to the following web page:
    http://publib.boulder.ibm.com/infocenter/tivihelp/v2r1/index.jsp?topic=/com.ibm.IBMDI.doc_7.0/CreatingyourfirstassemblyLine.htm

  3. Use the publish feature to export the assembly line as a Tivoli Directory Integrator adapter.
    1. Right-click the assembly line in the Navigator and select Publish.
    2. Enter the name of the adapter in the Package ID field.
    3. Specify the following directory in the File Path field, and then click Finish.
      profiles_tdisoln/packages
  4. Add a reference to the profiles property store to your adapter files by running the fixup_tdi_adapters.sh or fixup_tdi_adapters.bat command.
    Note: This reference is required to use the Profiles Tivoli Directory Integrator adapter. Even if you do not believe that your adapter file requires access to the profiles property store, there is no penalty for adding the reference so it is strongly advised that you run this command regardless.
  5. Open the profiles_tdi.properties file from the following location:

    tdisol.tar|zip/tdisol/TDI

  6. Set the following properties in the file:
    sync_updates_double_check
    Specifies whether your checking assembly line is used. When set to true, your deletion-checking assembly line is used. When set to false, the checking operation is not performed. The default value is false.
    For example:
    sync_updates_double_check=true
    sync_check_if_remove
    Specifies the name of your checking assembly line:
    sync_check_if_remove=name_of_your_adapter_xml_file:/AssemblyLines/name_of_your_assemblyline
    By default, the assembly line's name is set to sync_all_dns_check_if_remove.
    For example, if you publish the assembly line with the file name deleteCheckRoutines and the assembly line is example_check_if_user_really_deleted, use the following statement to set this property:
    sync_check_if_remove=deleteCheckRoutines:/AssemblyLines/example_check_if_user_really_deleted
    sync_delete_or_inactivate
    Controls what happens to a user record when the delete action is performed. This property can be set to one of the following values:
    • delete. Specifies that the user record is deleted.
    • inactivate. Specifies that the user record is inactivated.

      The inactive status is propagated to the member and login tables for all the applications. An event is generated for each of the following: Activities, Blogs, Bookmarks, Communities, Files, Forums, Profiles, Wikis, and News (which includes both Home page and Search). These events inactivate the user in every application by removing the user from the login tables and setting the user's status to 1 in all member tables.

    These values are case-sensitive so type them with care. The default value is inactivate.
    For example:
    sync_delete_or_inactivate=inactivate
  7. Save your changes to the profiles_tdi.properties file.

Using the LDAP directory as the user directory

Edit configuration property settings to disable IBM Connections directory service extensions.

Before you begin
Be sure that you have configured the LDAP directory properly before you configure it to be the user directory. See Setting up federated repositories for more details.
About this task

IBM Connections directory service extensions are protocols that propagate Profiles data between the applications. When the directory service extension is enabled, you can use the Profiles database to store user information instead of having to access the LDAP directory for each request. If you install the Profiles application, the Profiles database is set up to be the user directory for IBM Connections by default. If you decide that you want to use the LDAP directory as the user directory instead, you can disable the Profiles directory service extension.

When you disable the Profiles directory service extension, LDAP services handle authentication, group membership search, and all user profiles queries except browser based searches requested within the Profiles application.

Procedure
  1. Start the wsadmin client from the following directory of the system on which you installed the deployment manager:
    app_server_root\profiles\dm_profile_root\bin
    Note: You must start the client from this directory or subsequent commands that you try to run will not execute properly. See Starting the wsadmin client for more details.
  2. Use the wsadmin client to access and check out the IBM Connections configuration files.
    1. Enter the following command to access the IBM Connections configuration file: execfile("connectionsConfig.py")

      If prompted to specify a service to connect to, type 1 to pick the first node in the list. Most commands can run on any node. If the command writes or reads information to or from a file using a local file path, you must pick the node where the file is stored. This information is not used by the wsadmin client when you are making configuration changes.

    2. Enter the following command to check out the IBM Connections configuration files:

      LCConfigService.checkOutConfig("working_directory","cell_name")

      where:
      • working_directory is the temporary working directory to which the configuration XML and XSD files are copied and are stored while you make changes to them. Use forward slashes to separate directories in the file path, even if you are using the Microsoft Windows operating system.

        AIX and Linux only: The directory must grant write permissions or the command does not run successfully.

      • cell_name is the name of the WebSphere Application Server cell hosting the IBM Connections application. This argument is case-sensitive, so type it with care. If you do not know the cell name, type the following command while in the wsadmin command processor:print AdminControl.getCell()
      For example:
      • AIX or Linux:LCConfigService.checkOutConfig("/opt/temp","foo01Cell01")
      • Microsoft Windows:LCConfigService.checkOutConfig("c:/temp","foo01Cell01")
  3. Use the following command to disable the Profiles directory service extension:
    LCConfigService.updateConfig("profiles.directory.service.extension.enabled","false")
  4. After making changes, you must check the configuration files back in and you must do so during the same wsadmin session in which you checked them out for the changes to take effect. See Applying common configuration property changes for information about how to save and apply your changes.
Using the Profiles database as the user directory

Edit configuration property settings to enable IBM Connections directory service extensions.

Before you begin
You only need to perform this task if you did not install the Profiles application initially and now want to install Profiles and set its database as the user directory for IBM Connections.
About this task

IBM Connections directory service extensions are protocols that propagate Profiles data between the applications. When the directory service extension is enabled, you can use the Profiles database to store user information instead of having to access the LDAP directory for each request. If you install the Profiles application, the Profiles database is set up to be the user directory for IBM Connections by default.

When you set the Profiles database to be the user directory, only authentication and group membership search requests are sent to LDAP; the Profiles directory handles all user profile search requests

Procedure
  1. Start the wsadmin client from the following directory of the system on which you installed the deployment manager:
    app_server_root\profiles\dm_profile_root\bin
    Note: You must start the client from this directory or subsequent commands that you try to run will not execute properly. See Starting the wsadmin client for more details.
  2. Use the wsadmin client to access and check out the IBM Connections configuration files.
    1. Enter the following command to access the IBM Connections configuration file: execfile("connectionsConfig.py")

      If prompted to specify a service to connect to, type 1 to pick the first node in the list. Most commands can run on any node. If the command writes or reads information to or from a file using a local file path, you must pick the node where the file is stored. This information is not used by the wsadmin client when you are making configuration changes.

    2. Enter the following command to check out the IBM Connections configuration files:

      LCConfigService.checkOutConfig("working_directory","cell_name")

      where:
      • working_directory is the temporary working directory to which the configuration XML and XSD files are copied and are stored while you make changes to them. Use forward slashes to separate directories in the file path, even if you are using the Microsoft Windows operating system.

        AIX and Linux only: The directory must grant write permissions or the command does not run successfully.

      • cell_name is the name of the WebSphere Application Server cell hosting the IBM Connections application. This argument is case-sensitive, so type it with care. If you do not know the cell name, type the following command while in the wsadmin command processor:print AdminControl.getCell()
      For example:
      • AIX or Linux:LCConfigService.checkOutConfig("/opt/temp","foo01Cell01")
      • Microsoft Windows:LCConfigService.checkOutConfig("c:/temp","foo01Cell01")
  3. Use the following command to enable the Profiles directory service extension:
    LCConfigService.updateConfig("profiles.directory.service.extension.enabled","true")
  4. After making changes, you must check the configuration files back in and you must do so during the same wsadmin session in which you checked them out for the changes to take effect. See Applying common configuration property changes for information about how to save and apply your changes.
What to do next

Enable single sign-on between all the applications. For more information, see the Enabling single sign-on between all applications topic.

Groups

In IBM Connections 4, content owners can use LDAP groups to control access to resources in the Communities, Activities, Files, and Wikis applications. For this reason, it is important to consider the effect that updating LDAP groups will have on the existing membership of these resources.

For example, if a user is given access to content in IBM Connections via group membership and is then removed from that group, they might still receive email notifications and activity stream updates relating to that content until they log into the relevant application that contains the content. When the user logs in, the access controls are updated to reflect current group membership and any following subscriptions to content that is no longer accessible are removed at this time.

For more information about how group access works in different applications, refer to the help for the Communities, Activities, Files, and Wikis applications.

Customizing the deployment

Perform optional tasks to customize your IBM Connections deployment.

Hiding email addresses

Run a script provided with the product to configure IBM Connections to prevent email addresses from being displayed in the product and protect the privacy of your users.

Before you begin
Install all of the applications and test notifications to make sure that your mail servers are set up correctly before you configure the product to prevent email addresses from being displayed. Also, edit the notification-config.xml file to define a valid email address for the global administrator and alternate addresses for the different types of notifications sent by each application. See Defining valid administrator email address for more details.
Attention: Do not configure IBM Connections to hide email addresses if you are using any of the IBM Connections extensions. The extensions, such as the IBM Connections Plug-in for Notes or IBM Connections Plug-in for Sametime, require addresses to be exposed because they rely on email addresses to identify users. See the Extending section of the product documentation for a list of available IBM Connections extensions.
About this task
When you prevent emails from displaying, email addresses are hidden in the following places:
  • Members fields. When you begin to type a name into a name field, such as while adding members or creating a name field in an activity entry, a list of options is displayed. By default, this list is composed of email addresses. If you configure IBM Connections to hide email addresses, the list is composed of display names instead.
  • URLs. email addresses are often sent as parameters in URLs generated by actions that you can perform in the product. This setting prevents the email address from being used in URLs. A customer ID is used instead.
  • Notifications. Some actions that you perform in the product generate email notifications. For example, when you add members to an activity, they receive email notifications informing them about the activity. Other notifications are generated automatically by the server. For example, automatic notifications are sent to activity owners to warn them that an activity will be marked complete due to lack of use. When you indicate that you do not want to expose email addresses, all emails are shown to originate from the administrator email address defined for the application in the notification-config.xml file. In addition, the email addresses of the recipients are added to the blind carbon copy (BCC) field of the notification, which hides recipient email addresses from recipients.
  • Profiles business card. The email address that usually is displayed in business cards is not displayed nor is the Send Mail button.
Note to programmers: If you configure IBM Connections to keep email addresses private, you cannot use the email parameter to represent a person in GET requests sent to retrieve Atom feeds. Instead, you must use the userid parameter. See Determining whether email addresses are hidden in the Developing section for more details.

To hide email addresses, complete the following steps:

Procedure
  1. Open a command prompt, and then change to the following directory on the WebSphere Application Server hosting the IBM Connections server:
    • AIX or Linux:
      /opt/IBM/Connections/ConfigEngine
    • Microsoft Windows:
      C:\IBM\Connections\ConfigEngine
  2. Enter the following command to run the script that configures IBM Connections to hide email addresses on the WebSphere Application Server profile to which you installed the applications. For a network deployment, run it on the system hosting the deployment manager, which is typically the first node.
    • AIX or Linux:
      ./ConfigEngine.sh action-hide-email > /tmp/hide_email.log 2>&1 
    • Microsoft Windows:
      ConfigEngine.bat action-hide-email > D:/hide_email.log 2>&1 
    For example, on the Microsoft Windows operating system, you would enter the following command:
    ConfigEngine.bat action-hide-email > D:/hide_email.log 2>&1 
  3. You must perform some additional steps to remove email address references from user profiles. Follow the steps in the topic Configuring advanced search.
  4. Restart the server.

Exposing email addresses

If you configured IBM Connections to prevent email addresses from being displayed, and later decide that you want to allow email addresses to be exposed in the product, perform this procedure.

Before you begin
Only perform this procedure if you configured IBM Connections to prevent email addresses from being displayed. See Hiding email addresses for more details.
Procedure
  1. Open a command prompt, and then change to the following directory on the WebSphere Application Server hosting IBM Connections:
    • AIX or Linux:
      /opt/IBM/Connections/ConfigEngine
    • Microsoft Windows:
      C:\IBM\Connections\ConfigEngine
  2. Enter the following command to run the script that configures IBM Connections to display email addresses on each WebSphere Application Server profile to which you installed an application:
    • AIX or Linux:
      ./ConfigEngine.sh action-expose-email > /tmp/expose_email.log 2>&1 
    • Microsoft Windows:
      ConfigEngine.bat action-expose-email > D:/expose_email.log 2>&1
    For example, on the Microsoft Windows operating system, you would enter the following command:
    ConfigEngine.bat action-expose-email > D:/expose_email.log 2>&1
  3. You must perform some additional steps to add the email address references that were removed from user profiles. Follow the steps in the topic Configuring advanced search.
  4. Restart the servers.

Enabling users to set a language preference

By default, the IBM Connections user interface (UI) is displayed in the language identified in the locale settings of the web browser being used. You can set it up to allow users to explicitly select the language in which the product is displayed.

Before you begin

Before you begin this procedure, determine which subset of supported languages you want to support. For a full list of the languages that are supported by IBM Connections, see Supported languages.

About this task

After performing this procedure, users can select a language from the language selector in the product's menu bar.

You can also use this configuration to force the user interface to be displayed in only a single language. For example, to display the user interface in French only, you can use the following settings: enabled=true, defaultLanguage=fr, and make sure that no language elements are defined.

To enable users to set their language preference, complete the following steps:
Procedure
  1. Start the wsadmin client from the following directory of the system on which you installed the deployment manager:
    app_server_root\profiles\dm_profile_root\bin
    Note: You must start the client from this directory or subsequent commands that you try to run will not execute properly. See Starting the wsadmin client for more details.
  2. Use the wsadmin client to access and check out the IBM Connections configuration files.
    1. Enter the following command to access the IBM Connections configuration file: execfile("connectionsConfig.py")

      If prompted to specify a service to connect to, type 1 to pick the first node in the list. Most commands can run on any node. If the command writes or reads information to or from a file using a local file path, you must pick the node where the file is stored. This information is not used by the wsadmin client when you are making configuration changes.

    2. Enter the following command to check out the IBM Connections configuration files:

      LCConfigService.checkOutConfig("working_directory","cell_name")

      where:
      • working_directory is the temporary working directory to which the configuration XML and XSD files are copied and are stored while you make changes to them. Use forward slashes to separate directories in the file path, even if you are using the Microsoft Windows operating system.

        AIX and Linux only: The directory must grant write permissions or the command does not run successfully.

      • cell_name is the name of the WebSphere Application Server cell hosting the IBM Connections application. This argument is case-sensitive, so type it with care. If you do not know the cell name, type the following command while in the wsadmin command processor:print AdminControl.getCell()
      For example:
      • AIX or Linux:LCConfigService.checkOutConfig("/opt/temp","foo01Cell01")
      • Microsoft Windows:LCConfigService.checkOutConfig("c:/temp","foo01Cell01")
  3. Navigate to the working directory that you specified in the previous step and open the LotusConnections-config.xml file in a text editor.
  4. Find the <languageSelector> element, and then make the following changes:
    1. Change the value of the enabled attribute from false to true.
    2. By default, the defaultLanguage attribute is blank and the product user interface is displayed in the language specified as the preferred language by each user's web browser. You can use the defaultLanguage attribute to define a fallback language in which to display the user interface if the preferred language is not one that is supported by IBM Connections. The language that you specify here is displayed in the language selector in the product's navigation bar. Specify the language using the exact strings listed in the following example.
      Note: Use the language code iw to specify Hebrew.
    3. The default cookie name is lcLang. If you want to change it, specify a name in the cookieName attribute.
    4. No cookie domain is used by default, but you can specify a domain by adding the domain name of your deployment as the value of the cookieDomain attribute. The domain name must be a valid, fully qualified domain name of the server where the cookie resides. For example: .acme.com. Note that the domain name begins with a period (.). When you provide this value for the cookie domain property, you enable the language setting to work across multiple servers, such as both profiles.acme.com and activities.acme.com.
    5. By default, the cookie persists for the duration of the web browser session. To create a persistent cookie that has an expiry date of ten years from the date it was created, set the usePermanentCookie to true.
    6. Within the <languageSelector> element, add one <language> element for each language that you want users to be able to select from the language selector list in the product menu bar. Include a lang attribute that specifies the ISO country code associated with the language. Provide the language name as it should be displayed in the list as the value of the language element. Specify non-Latin characters in JavaScript-escaped unicode format. You can only specify languages that the product supports. For a list of languages, see Supported languages.

      Also, remove any of the language elements that are included in the languageSelector element by default if you do not want them to be displayed from the drop-down list of language options in the product menu bar. They are English, French, Chinese, and Arabic. For example:

      <languageSelector 
       enabled="true" 
       defaultLanguage="" 
       cookieName="conxnsCookie"
       cookieDomain=".acme.com" 
       usePermanentCookie="true">
        <language lang="en">English</language>
        <language lang="zh">\u4e2d\u6587\uff08\u7b80\u4f53\uff09</language>
        <language lang="zh_tw">\u4e2d\u6587 (\u7e41\u9ad4)</language>
        <language lang="ja">\u65e5\u672c\u8a9e</language>
        <language lang="ko">\ud55c\uad6d\uc5b4</language>
        <language lang="fr">Fran\u00e7ais</language>
        <language lang="de">Deutsch</language>
        <language lang="it">Italiano</language>
        <language lang="es">Espa\u00f1ol</language>
        <language lang="pt_br">Portugu\u00eas (Brasil)</language>
        <language lang="cs">\u010ce\u0161tina</language>
        <language lang="da">Dansk</language>
        <language lang="nl">Nederlands</language>
        <language lang="fi">suomi</language>
        <language lang="el">\u0395\u03bb\u03bb\u03b7\u03bd\u03b9\u03ba\u03ac</language>
        <language lang="hu">Magyar</language>
        <language lang="no">Norsk (Bokm\u00e5l)</language>
        <language lang="pl">polski</language>
        <language lang="pt">Portugu\u00eas (Portugal)</language>
        <language lang="ru">\u0420\u0443\u0441\u0441\u043a\u0438\u0439</language>
        <language lang="sl">slovenščina</language>
        <language lang="sv">Svenska</language>
        <language lang="tr">T\u00fcrk\u00e7e</language>
        <language lang="iw">\u05e2\u05d1\u05e8\u05d9\u05ea</language>
        <language lang="ar">\u200f\u0627\u0644\u0639\u0631\u0628\u064a\u0629\u200f</language>
        <language lang="ca">Catal\u00e0</language>
        <language lang="kk">\u049a\u0430\u0437\u0430\u049b\u0448\u0430</language>
        <language lang="th">\u0e44\u0e17\u0e22</language>
      </languageSelector>
      The following table identifies the languages based on the lang property value:
      Table 58. Language code values
      Lang property value Language
      ar Arabic
      ca Catalan
      cs Czech
      da Danish
      de German
      en English
      el Greek
      es Spanish
      fi Finnish
      fr French
      hu Hungarian
      it Italian
      iw Hebrew
      ja Japanese
      kk Kazakh
      ko Korean
      nl Dutch
      no Norwegian
      pl Polish
      pt Portuguese
      pt_br Brazilian Portuguese
      ru Russian
      sl Slovenian
      sv Swedish
      th Thai
      tr Turkish
      zh Simplified Chinese
      zh_tw Traditional Chinese
  5. Save your changes to the LotusConnections-config.xml file.
  6. After making changes, you must check the configuration files back in and you must do so during the same wsadmin session in which you checked them out for the changes to take effect. See Applying common configuration property changes for information about how to save and apply your changes.

Changing application URLs

Change the context root of URLs that point to IBM Connections applications.

Before you begin

If you decide to change the context roots of the applications, do so before you map the applications to IBM HTTP Server or before you edit the IBM HTTP Server configuration file for any other reason,such as to redirect HTTP requests to support third-party authentication mechanisms.

This is an optional task.

About this task

The web address for an IBM Connections application contains a default context root value. After installing the application, you can change this value to a different context root to conform to corporate restrictions or to policies that limit where server applications can be deployed and how they can be addressed.

For example, the Blogs application is available from your_host_server/blogs by default. You can change that base web address to your_host_server>/IBMConnectionsBlogs to differentiate it from any other available blogging service or to conform to corporate guidelines.

To change the context root of an application, complete the following steps:
Procedure
  1. Log into the WebSphere Application Server Integration Solutions Console for the server hosting the IBM Connections application for which you want to change the context root.
  2. Expand Applications > Application Types, and then select WebSphere enterprise applications.
  3. Click the name of the server hosting the application with the context root that you want to change, and then under Web Module Properties, click Context Root For Web Modules.
  4. Edit the values in the Context Root column of the table to change the term that identifies the application. The paths must continue to begin with a forward slash (/) and must not contain spaces.

    Do not specify a single forward slash (/) as the full context root because it prevents applications from being able to retrieve Atom feeds properly. Using the default application context ("/") is not supported.

  5. Click OK, and then click OK from the server properties page to save the change.
  6. Start the wsadmin client from the following directory of the system on which you installed the deployment manager:
    app_server_root\profiles\dm_profile_root\bin
    Note: You must start the client from this directory or subsequent commands that you try to run will not execute properly. See Starting the wsadmin client for more details.
  7. Update the IBM Connections configuration file to reflect this context root change. Use the wsadmin client to access and check out the IBM Connections configuration files.
    1. Enter the following command to access the IBM Connections configuration file: execfile("connectionsConfig.py")

      If prompted to specify a service to connect to, type 1 to pick the first node in the list. Most commands can run on any node. If the command writes or reads information to or from a file using a local file path, you must pick the node where the file is stored. This information is not used by the wsadmin client when you are making configuration changes.

    2. Enter the following command to check out the IBM Connections configuration files:

      LCConfigService.checkOutConfig("working_directory","cell_name")

      where:
      • working_directory is the temporary working directory to which the configuration XML and XSD files are copied and are stored while you make changes to them. Use forward slashes to separate directories in the file path, even if you are using the Microsoft Windows operating system.

        AIX and Linux only: The directory must grant write permissions or the command does not run successfully.

      • cell_name is the name of the WebSphere Application Server cell hosting the IBM Connections application. This argument is case-sensitive, so type it with care. If you do not know the cell name, type the following command while in the wsadmin command processor:print AdminControl.getCell()
      For example:
      • AIX or Linux:LCConfigService.checkOutConfig("/opt/temp","foo01Cell01")
      • Microsoft Windows:LCConfigService.checkOutConfig("c:/temp","foo01Cell01")
  8. Update the value of the href prefix using the following command:
    LCConfigService.updateConfig("<web_module_name.href.prefix",
     "new_context_root_value")
    where:
    web_module_name
    Name of the web module for the application. Each application has one or more web modules that are configured in WebSphere Application Server. The options are the following:
    Table 59. Application web modules
    Application or Service name Web modules
    Activities activities
    Blogs blogs
    Communities communities
    Dogear dogear
    Files files
    Forums forums
    Home page homepage, news
    Metrics metrics
    Mobile mobile
    Moderation moderation
    Profiles personTag, profiles
    Search search
    Wikis wikis
    new_context_root_value
    Value you defined for the application's web UI context root in Step 4.
    Note: Do not specify a single forward slash (/) as the full context root because it prevents applications from being able to retrieve Atom feeds properly.
    For example, to change the context root of the Profiles application, you would use the following commands:
    LCConfigService.updateConfig("profiles.href.prefix","/contacts")
    LCConfigService.updateConfig("personTag.href.prefix","/contacts")
  9. Save your changes to the LotusConnections-config.xml file.
  10. After making changes, you must check the configuration files back in and you must do so during the same wsadmin session in which you checked them out for the changes to take effect. See Applying common configuration property changes for information about how to save and apply your changes.
  11. Files and Wikis only: Perform the following steps:
    1. Check out the Files and Wikis configuration files. See the topic Changing configuration property values in the Administering Files and Administering Wikis sections of the product documentation.
    2. Locate the following property:
      <security>
         <logout href="/files/ibm_security_logout" />
      </security>
    3. Change it to this:
      <security>
         <logout href="new_context_root_value>/ibm_security_logout" />
      </security>
  12. Perform either of the following actions to update existing links to uploaded files:
    • Update the old links manually.
    • Redirect requests made to links that contain the old context root to links with the new one by completing the following steps:
      Note: You can only use this option if the old and new context roots are defined on the same IBM HTTP Server.
      1. Open the configuration file for the IBM HTTP Server. It is called httpd.conf and is located in the following directory:

        AIX: /usr/IBM/HTTPServer/conf

        Linux: /opt/IBM/HTTPServer/conf

        Microsoft Windows: C:\IBM\HTTPServer\conf

      2. Uncomment the following line or add it if it is not present:
        LoadModule rewrite_module modules/mod_rewrite.so
      3. Add redirection rules for each application for both HTTP and secure HTTP. The following XML is an example of redirection rules added for the Blogs application:
        Listen 0.0.0.0:443
        <VirtualHost  *:443>
        RewriteEngine on
        RewriteRule /blogs/(.*) https://<your_host_server>/LotusConnectionsBlogs/$1 [R,L]
        ServerName  <your_host_server>
        SSLEnable
        </VirtualHost>
        SSLDisable
        
        RewriteEngine on
        RewriteRule /blogs/(.*) http://<your_host_server>/LotusConnectionsBlogs/$1 [R,L]
      4. Save and close the httpd.conf file, and then restart the IBM HTTP Server.
  13. Regenerate the plugin-cfg.xml file for the IBM HTTP Server in the WebSphere Application Server Integrated Solutions Console. To do so, complete the following steps:
    1. Open the WebSphere Application Server Integrated Solutions Console.
    2. Expand Servers > Server Types, and then select Web servers.
    3. Select the check box next to the IBM HTTP Server name. For example: webserver1.
    4. Click Generate Plug-in to regenerate the plugin-cfg.xml file.
    5. If necessary. click Propagate Plug-in to copy the plugin-cfg.xml file from the local directory where the Application Server is installed to the remote machine.
  14. Restart the IBM HTTP Server.
  15. Rebuild the search index by deleting the index and letting the indexing task recreate it when it runs. By default, the indexing task runs every 15 minutes. See Deleting the index for more information.
  16. Update any non-browser clients to point to the new URL. See the client documentation for required steps.
  17. Run the BlogsAdminService.fixBrokenUrls command to fix the absolute URLs used by embedded images and attachments in Blogs. See Replacing URLs in Blogs.
  18. If you have many users with bookmarks or email links to the original URL, consider creating a landing page for the old URL that redirects to the new URL.

Adding Sametime awareness though the Sametime client

If you have an IBM Sametime 8.0.1 client or later and the Profiles application deployed, you can enable presence awareness in IBM Connections.

Before you begin
Note: This is an optional configuration.

When you enable presence awareness in IBM Connections, a person's online status is indicated by a set of icons and an associated status message that is available from the person's profile and business card. Presence awareness tells you whether the person is available to chat, busy in a meeting, or away from their computer.

You must have the following software enabled to be able to add presence awareness to IBM Connections:
  • IBM Sametime 8.5 or later stand-alone client.
    Note: Alternatively, you can use Sametime embedded in Notes if the Notes client version is Notes 8.5 or later.
  • IBM Sametime 8.0.1 stand-alone client.
    Note: Alternatively, you can use IBM Sametime embedded in Notes if the Notes client version is Notes 8.0.2 with Interim Application Release 1 (IFR1).
    When using Sametime 8.0.1, the following limitations apply:
    • Users defined in the Sametime directory must have the same email address as the users defined in the Profiles directory.
  • The Profiles application of IBM Connections must be deployed.
SSL support: If you have configured the product to send traffic over SSL, presence awareness can be retrieved over SSL for the following Sametime clients:
  • IBM Sametime 8.5 or later standalone client
  • Notes 8.5.1 or later embedded client
For more information about enabling SSL for Sametime, refer to the documentation provided with the Sametime SDK, which is available from the following web site: http://www.ibm.com/developerworks/lotus/downloads/toolkits.html
Note: After downloading the toolkit, the documentation can be found in the <sdk>/client/connectWebApi/doc/ConnectWebApiDevguide.pdf directory.
Procedure
  1. Start the wsadmin client from the following directory of the system on which you installed the deployment manager:
    app_server_root\profiles\dm_profile_root\bin
    Note: You must start the client from this directory or subsequent commands that you try to run will not execute properly. See Starting the wsadmin client for more details.
  2. Edit the profiles-config.xml file to indicate that you want to enable awareness. Start the wsadmin client. Use the following commands to access and check out the Profiles configuration files:
    1. Enter the following command to access the Profiles configuration files:
      execfile("profilesAdmin.py")
      If prompted to specify a service to connect to, type 1 to pick the first node in the list. Most commands can run on any node. If the command writes or reads information to or from a file using a local file path, you must pick the node where the file is stored.
    2. Enter the following command to check out the Profiles configuration files:
      ProfilesConfigService.checkOutConfig("working_directory", "cell_name")where:
      • working_directory is the temporary working directory to which the configuration XML and XSD files are copied and are stored while you make changes to them. Use forward slashes (/) to separate directories in the file path, even if you are using the Microsoft Windows operating system.
        Note: AIX and Linux only: The directory must grant write permissions or the command does not complete successfully.
      • cell_name is the name of the WebSphere Application Server cell hosting the Profiles application. This argument is required. It is also case-sensitive, so type it with care. If you do not know the cell name, you can determine it by typing the following command in the wsadmin command processor:
        print AdminControl.getCell()
      For example:
      • AIX or Linux:
        ProfilesConfigService.checkOutConfig("/opt/prof/temp","foo01Cell01")
      • Microsoft Windows:
        ProfilesConfigService.checkOutConfig("c:/prof/temp","foo01Cell01")
  3. From the temporary directory to which you checked out the configuration files, open the profiles-config.xml file in a text editor.
  4. Find the <sametimeAwareness> element, and then set the enabled attribute equal to true, specify web addresses for the href and ssl_href attributes, and specify which input type should be used for identifying the person: an email address or a user ID. For example:
    <sametimeAwareness 
     enabled="true" 
     href="http://localhost:59449/stwebapi"  
     ssl_href="http://localhost:59449/stwebapi" 
     sametimeInputType="email" />
    If IBM Connections is configured to hide email addresses, define the user ID as the input type by setting the sametimeInputType attribute equal to uid. For example:
    <sametimeAwareness 
     enabled="true" 
     href="http://localhost:59449/stwebapi"  
     ssl_href="http://localhost:59449/stwebapi" 
     sametimeInputType="uid" />
  5. Sametime 8.5 stand-alone and Notes 8.5.1 embedded client only: If you have configured the product to send traffic over SSL, edit the ssl_href attribute to specify the web address with the HTTPS protocol. For example:
    <sametimeAwareness 
     enabled="true" 
     href="http://localhost:59449/stwebapi"  
     ssl_href="https://localhost:59669/stwebapi" 
     sametimeInputType="email" />
    Do not make this change for releases earlier than Sametime 8.5 or the Notes 8.5.1 embedded client or awareness will stop working properly.
  6. Save and close the profiles-config.xml file.
  7. Check in the changed configuration files using the following wsadmin client command:
    ProfilesConfigService.checkInConfig()
  8. To exit the wsadmin client, type exit at the prompt.
  9. If you are using a Sametime client that is embedded in a version of Notes later than 8.0.2 (IFR1), you must configure Notes to display awareness information because it is disabled by default. To do so, complete the following steps:
    1. Exit the Notes client.
    2. Open the plugin_customization.ini file in a text editor.

      By default, the plugin_customization.ini file is stored in the following directory:

      C:\notes\framework\rcp
    3. Search for the com.ibm.collaboration.realtime.webapi/startwebContainer property. If it is set to false, set it equal to true. If you do not find it, add the property using the follow syntax:
      com.ibm.collaboration.realtime.webapi/startwebContainer=true
    4. Save and close the plugin_customization.ini file.
  10. Stop and restart the WebSphere Application Server hosting the Profiles application.
  11. Start the stand-alone Sametime client or Notes client in which Sametime is embedded.

    It is not recommended that you run more than one Sametime client on a single machine at one time. If awareness does not seem to be enabled in IBM Connections, make sure you do not have an earlier version of the Sametime client running on your machine. If you do, stop the clients and be sure to restart the Sametime Connect 8.0.1 client or the Sametime client embedded in Notes 8.0.2 (IFR1) or later before restarting any other clients.

  12. Confirm that this procedure worked by accessing one of the IBM Connections applications, and then opening a person's business card. It may take a few seconds for the person's presence information to display the first time.

Adding Sametime awareness through the Sametime server

If you have an IBM Sametime Proxy server configured in your enterprise and have the Profiles application deployed, you can enable presence awareness and simple chats in IBM Connections.

Before you begin
Note: This is an optional configuration.
You must have the following software enabled to be able to add presence awareness to IBM Connections:
Complete the following procedures before attempting to enable awareness.
About this task

When you enable presence awareness using the Sametime Proxy server, a person's online status is indicated by a set of icons and an associated status message that is available from the person's profile and business card. Presence awareness tells you whether the person is available to chat, busy in a meeting, or away from their computer. In addition to seeing a person's availability, you can carry on a chat with that person even when no Sametime client is installed.

SSL support: If you have configured the product to send traffic over SSL, presence awareness can be retrieved over SSL. For more information about enabling SSL for Sametime, refer to the documentation provided with the Sametime SDK, which is available from the following web site: http://www.ibm.com/developerworks/lotus/downloads/toolkits.html
Note: After downloading the toolkit, the documentation can be found in the sdk/client/connectWebApi/doc/ConnectWebApiDevguide.pdf directory.
Procedure
  1. Start the wsadmin client from the following directory of the system on which you installed the deployment manager:
    app_server_root\profiles\dm_profile_root\bin
    Note: You must start the client from this directory or subsequent commands that you try to run will not execute properly. See Starting the wsadmin client for more details.
  2. Use the wsadmin client to access and check out the IBM Connections extension configuration files.
    1. Enter the following command to access the IBM Connections configuration file: execfile("connectionsConfig.py")

      If prompted to specify a service to connect to, type 1 to pick the first node in the list. Most commands can run on any node. If the command writes or reads information to or from a file using a local file path, you must pick the node where the file is stored. This information is not used by the wsadmin client when you are making configuration changes.

    2. Enter the following command to check out the LotusConnections-config (LCC.xml) file:
      LCConfigService.checkOutConfig("working_directory","cell_name")
      where:
      • working_directory is the temporary working directory to which the configuration XML and XSD files are copied and are stored while you make changes to them. Use forward slashes to separate directories in the file path, even if you are using the Microsoft Windows operating system.

        AIX and Linux only: The directory must grant write permissions or the command does not run successfully.

      • cell_name is the name of the WebSphere Application Server cell hosting the IBM Connections application. This argument is case-sensitive, so type it with care. If you do not know the cell name, type the following command while in the wsadmin command processor:print AdminControl.getCell()
      For example:
      • AIX or Linux:LCConfigService.checkOutLcConfig("/opt/temp","foo01Cell01")
      • Microsoft Windows:LCConfigService.checkOutLcConfig("c:/temp","foo01Cell01")
  3. From the directory you specified as the working directory in the previous step, open the LCC.xml file in a text editor, and then find the sametimeProxy service section:
    <sloc:serviceReference enabled="false" isConnectClient="false" serviceName="sametimeProxy" ssl_enabled="false">
    <sloc:href>
    <sloc:hrefPathPrefix/>
    <sloc:static href="admin_replace" ssl_href="admin_replace"/>
    <sloc:interService href="admin_replace"/>
    </sloc:href>
    </sloc:serviceReference>
  4. Specify the attributes according to the following example:
    <sloc:serviceReference enabled="true" isConnectClient="true" serviceName="sametimeProxy" ssl_enabled="true"><sloc:href><sloc:hrefPathPrefix/>
    <sloc:static href="http://sametimeProxyServer.enterprise.example.com" ssl_href="https://sametimeProxyServer.enterprise.example.com:9444"/>
    <sloc:interService href="https://sametimeProxyServer.enterprise.example.com:9444"/>
    </sloc:href>
    </sloc:serviceReference>
    Where:
    • sloc:serviceReference enabled="true" displays the Sametime action bar in Connections and connects to Sametime via the specified Sametime Proxy server.
    • ssl_enabled="true" connects to the Sametime proxy server on the secure port.
    • isConnectClient="true" automatically connects to Sametime via the UIM client, rather than the Sametime Proxy server.
  5. Scan your LCC.xml file for any third party applications that are enabled in your environment. If the third party application is not configured to the reverse proxy, add 'isExternal' attribute to the service as shown in following example:
    <sloc:serviceReference enabled="true" serviceName="sametimeProxy" ssl_enabled="true" isConnectClient="true"><sloc:href> <sloc:hrefPathPrefix/> 
    <sloc:static href="http://sametimeProxyServer.enterprise.example.com" ssl_href="https://sametimeProxyServer.enterprise.example.com:9444" isExternal="true"/> 
    <sloc:interService href="https://sametimeProxyServer.enterprise.example.com:9444"/> 
    </sloc:href> '
    </sloc:serviceReference>
  6. Save and close the LCC.xml file.
  7. To check in the changed configuration files, use the following command:
    LCConfigService.checkInLcConfig(working_directory,cell_name)
  8. After making updates, type the following command to deploy the changes:
    synchAllNodes()
  9. To exit the wsadmin client, type exit at the prompt.
  10. Stop and restart all of the IBM Connections application servers.
  11. Confirm that this procedure worked by accessing one of the IBM Connections applications, and then opening a person's business card. It may take a few seconds for the person's presence information to display the first time. If you can start a chat with the person, then enabling awareness through the proxy server was successfully completed.

Disabling an application

You might decide to disable an application temporarily for maintenance or if, for example, you are deploying the product and this application is not yet ready for use.

Before you begin
Only perform this task if you want to disable an application temporarily.
Note: Do not disable applications that are used by all of the other applications, such as the News or Search applications.
Procedure
  1. Open the Integrated Solutions Console of the WebSphere Application Server that is hosting the application.
  2. Expand Applications > Application Types, and then select WebSphere enterprise applications.
  3. Click the name of the application that you want to disable.
  4. Click Target specific application status.
  5. Select the check box next to the cluster name, and then click Disable Auto Start.
  6. Click Save to save your changes.
  7. Click Apply, and then click OK.
  8. Start the wsadmin client from the following directory of the system on which you installed the deployment manager:
    app_server_root\profiles\dm_profile_root\bin
    Note: You must start the client from this directory or subsequent commands that you try to run will not execute properly. See Starting the wsadmin client for more details.
  9. Remove the link to the application from the navigation bar by editing the IBM Connections configuration file.
    1. Enter the following command to access the IBM Connections configuration file: execfile("connectionsConfig.py")

      If prompted to specify a service to connect to, type 1 to pick the first node in the list. Most commands can run on any node. If the command writes or reads information to or from a file using a local file path, you must pick the node where the file is stored. This information is not used by the wsadmin client when you are making configuration changes.

    2. Enter the following command to check out the IBM Connections configuration files:

      LCConfigService.checkOutConfig("working_directory","cell_name")

      where:
      • working_directory is the temporary working directory to which the configuration XML and XSD files are copied and are stored while you make changes to them. Use forward slashes to separate directories in the file path, even if you are using the Microsoft Windows operating system.

        AIX and Linux only: The directory must grant write permissions or the command does not run successfully.

      • cell_name is the name of the WebSphere Application Server cell hosting the IBM Connections application. This argument is case-sensitive, so type it with care. If you do not know the cell name, type the following command while in the wsadmin command processor:print AdminControl.getCell()
      For example:
      • AIX or Linux:LCConfigService.checkOutConfig("/opt/temp","foo01Cell01")
      • Microsoft Windows:LCConfigService.checkOutConfig("c:/temp","foo01Cell01")
  10. To see a list of the properties and their current settings, use the following command:
    LCConfigService.showConfig()
  11. Enter the following commands:
    LCConfigService.updateConfig("application_name.enabled", "false")
    LCConfigService.updateConfig("application_name.ssl.enabled", 
     "false")
    where application_name is the name of the application that you are disabling.
  12. After making changes, you must check the configuration files back in and you must do so during the same wsadmin session in which you checked them out for the changes to take effect. See Applying common configuration property changes for information about how to save and apply your changes.
  13. Stop the WebSphere Application Server clusters, and then restart the WebSphere Application Server clusters.

Disabling microblogging

You can remove microblogging functionality from your deployment by disabling the microblogging service reference in the LotusConnections-config.xml file. Microblogging is enabled by default in IBM Connections.

Before you begin
To edit configuration files, you must use the wsadmin client. See Starting the wsadmin client for information about how to start the wsadmin command-line tool.
About this task
Disabling the microblogging service in the LotusConnections-config.xml file automatically removes all the features provided by the service. The options that enable users to post status updates are removed from the product user interface, and the indexing process associated with the microblogging service is also disabled.
When you disable microblogging:
  • Users cannot post status updates in IBM Connections
  • Users cannot post messages to other users' profiles or to communities
  • Status updates cannot be searched from the Search user interface
Note: Existing status updates are not removed from the user interface, and are still visible in the Home page, Profiles, and Communities applications.
Procedure

To disable microblogging in your deployment, complete the following steps.

  1. Use the wsadmin client to access and check out the IBM Connections configuration files:
    1. Enter the following command to access the IBM Connections configuration file: execfile("connectionsConfig.py")

      If prompted to specify a service to connect to, type 1 to pick the first node in the list. Most commands can run on any node. If the command writes or reads information to or from a file using a local file path, you must pick the node where the file is stored. This information is not used by the wsadmin client when you are making configuration changes.

    2. Enter the following command to check out the IBM Connections configuration files:

      LCConfigService.checkOutConfig("working_directory","cell_name")

      where:
      • working_directory is the temporary working directory to which the configuration XML and XSD files are copied and are stored while you make changes to them. Use forward slashes to separate directories in the file path, even if you are using the Microsoft Windows operating system.

        AIX and Linux only: The directory must grant write permissions or the command does not run successfully.

      • cell_name is the name of the WebSphere Application Server cell hosting the IBM Connections application. This argument is case-sensitive, so type it with care. If you do not know the cell name, type the following command while in the wsadmin command processor:print AdminControl.getCell()
      For example:
      • AIX or Linux:LCConfigService.checkOutConfig("/opt/temp","foo01Cell01")
      • Microsoft Windows:LCConfigService.checkOutConfig("c:/temp","foo01Cell01")
  2. Optional: If you want to find out the current value of a property, you can list the current configuration settings and values using the following command: LCConfigService.showConfig()
  3. To disable microblogging capabilities across IBM Connections, enter the following command:
    LCConfigService.updateConfig("microblogging.enabled","false")
What to do next

Check the configuration files back in during the same wsadmin session in which you checked them out. For more information, see the Applying common configuration property changes topic.

Disabling the social analytics service

The social analytics widgets help users to discover how they are connected to other users and content, and suggest network contacts and content that might interest them. The social analytics service is enabled by default.

Before you begin
To edit configuration files, you must use the wsadmin client. See Starting the wsadmin client for information about how to start the wsadmin command-line tool.
About this task
Disabling the social analytics service automatically removes all the features provided by the service, including the social analytics widgets that are available in Profiles, Communities, and the Home page. The indexing process associated with the social analytics service is also disabled.
When you disable the social analytics service, the following widgets are removed from the user interface:
  • Do You Know (Profiles)
  • Recommendations (Communities)
  • Recommendations (Home page)
  • Who Connects Us? (Profiles)
  • Things in Common
You disable the social analytics service by using wsadmin commands to set the sand.enabled and sand.ssl.enabled properties in the LotusConnections-config.xml file to false. For more information about changing common configuration properties, see Changing common configuration property values.
<sloc:serviceReference serviceName="sand" 
        enabled="false"
        ssl_enabled="false">
        <sloc:href>
            <sloc:hrefPathPrefix>/news/common/sand</sloc:hrefPathPrefix>
        <sloc:static href="admin_replace" ssl_href="admin_replace"/>
        </sloc:href>
    </sloc:serviceReference>
Procedure

To disable the social analytics service, complete the following steps.

  1. Use the wsadmin client to access and check out the IBM Connections configuration files:
    1. Enter the following command to access the IBM Connections configuration file: execfile("connectionsConfig.py")

      If prompted to specify a service to connect to, type 1 to pick the first node in the list. Most commands can run on any node. If the command writes or reads information to or from a file using a local file path, you must pick the node where the file is stored. This information is not used by the wsadmin client when you are making configuration changes.

    2. Enter the following command to check out the IBM Connections configuration files:

      LCConfigService.checkOutConfig("working_directory","cell_name")

      where:
      • working_directory is the temporary working directory to which the configuration XML and XSD files are copied and are stored while you make changes to them. Use forward slashes to separate directories in the file path, even if you are using the Microsoft Windows operating system.

        AIX and Linux only: The directory must grant write permissions or the command does not run successfully.

      • cell_name is the name of the WebSphere Application Server cell hosting the IBM Connections application. This argument is case-sensitive, so type it with care. If you do not know the cell name, type the following command while in the wsadmin command processor:print AdminControl.getCell()
      For example:
      • AIX or Linux:LCConfigService.checkOutConfig("/opt/temp","foo01Cell01")
      • Microsoft Windows:LCConfigService.checkOutConfig("c:/temp","foo01Cell01")
  2. Optional: If you want to find out the current value of a property, you can list the current configuration settings and values using the following command: LCConfigService.showConfig()
  3. To disable the social analytic service, enter the following commands:
    LCConfigService.updateConfig("sand.enabled","false")
    LCConfigService.updateConfig("sand.ssl.enabled","false")
What to do next

Check the configuration files back in during the same wsadmin session in which you checked them out. For more information, see the Applying common configuration property changes topic.

Adding or removing sections from the help system's table of contents

If you installed a subset of the IBM Connections applications, remove the help files associated with the applications that you did not install from the help table of contents. If you add an application, or install IBM Connections Mail, you can add that product's help to the table of contents.

Before you begin
This procedure is not required.
About this task
The help system enables users to navigate from the help for one application to another application by providing a table of contents that lists each application as a separate section and includes help topics within the section. However, if you choose to install only a subset of the available applications, you must manually remove the other help sections from the help system table of contents after installing the product or users see help for applications to which they do not have access. You can also add help if you add an application.
Procedure
  1. Start the wsadmin client from the following directory of the system where you installed the deployment manager:
    app_server_root\profiles\dm_profile_root\bin
    Note: You must start the client from this directory or subsequent commands that you try to run will not execute properly. See Starting the wsadmin client for more details.
  2. Enter the following command to access the IBM Connections configuration files:
    execfile("connectionsConfig.py")
  3. Enter the following command to specify which applications you want to include in the help system's table of contents:
    Important: If you want to add an extra application to the existing help, you still need to list all the applications for which you are already providing help. Only the help files for applications that you list as parameters in the LCConfifigHelp.setHelp command will appear in the table of contents.
    LCConfigHelp.setHelp("temp_directory","application_name","application_name")
    where:
    • temp_directory is the name of a temporary directory on your system. The directory you specify can be any directory, but it must exist before you enter the command. When you enter the command, an XML file called helpData.xml is added to this directory and is used by the command.

      AIX and Linux only: The directory must grant write permissions or the command does not complete successfully.

    • application_name is the name of the application whose help section you want to include in the table of contents. List each application name separated by commas. The options are:
      • activities
      • blogs
      • bookmarks
      • communities
      • files
      • forums
      • homepage
      • profiles
      • wikis
      • icmail
    For example, if you installed all the applications except Wikis and Connections Mail, you can run the following command to include all sections but Wikis and Connections Mail in the help system:
    LCConfigHelp.setHelp("c:/temp","activities","blogs","bookmarks","communities","files","forums","homepage","profiles")
  4. To force the table of contents in the help system to reflect the change, stop the help application, and delete the temporary help directory on each node where help runs.

    For example, delete the following directory:
    C:\IBM\WebSphere\AppServer\profiles\AppSrv01\temp\node-name\cluster-name\Help.

    This directory is recreated when the application restarts.

Results
When a user opens the product help system, the table of contents lists only those sections that you wanted it to include.
Attention: If a help topic links to a topic in a section that you have removed from the help system, the link text continues to be displayed, but returns an error when clicked.

Administering Activities

Configure Activities to best meet the needs of your environment.

For example, if you have limited disk space, you can specify smaller maximum file upload sizes or decrease the interval of time after which unused activities are marked complete. If you want to gauge how many people are using the product and to what extent, you can collect statistics and retrieve metrics on usage. You can also perform tasks such as synchronizing members IDs between the Activities database and the LDAP server and enabling virus scanning.

Changing Activities configuration property values

Configuration settings control how and when various Activities operations take place. You can edit the settings to change the ways that activities behave.

About this task

Configure Activities using scripts accessed with the wsadmin client. These scripts use the AdminConfig object available in WebSphere Application Server wsadmin client to interact with the Activities configuration file. Changes to Activities configuration settings require node synchronization and a restart of the Activities server before they take effect.

Checking out the Activities configuration files

You can edit the Activities configuration files in two ways: by using the wsadmin client or by editing the configuration XML files directly. In both cases, you must first check out the configuration files and later check them back in using the wsadmin client.

Procedure
  1. Start the wsadmin client by completing the following steps:
    1. Open a command prompt, and then change to the following directory of the system on which you installed the deployment manager:
      app_server_root\profiles\dm_profile_root\bin
      where app_server_root is the WebSphere Application Server installation directory and dm_profile_root is the Deployment Manager profile directory, typically dmgr01. For example, on Windows:
      C:\Program Files\IBM\WebSphere\AppServer\profiles\Dmgr01\bin
      Attention: You must run the following command to start the wsadmin client from this specific directory because the Jython 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 does not work correctly.
    2. Enter the following command to start the wsadmin client:
      • AIX or 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 a person in the Administrator role on the IBM WebSphere Application Server.
      • admin_password is the password of the WebSphere Application Server administrator.
      • SOAP_CONNECTOR_ADDRESS Port is the SOAP port for the WebSphere Application Server deployment manager server. 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 WebSphere Application Server Integrated Solution Console. To look up the SOAP port number, perform the following steps:
        1. Open the WebSphere Application Server Integrated Solution Console for the deployment manager, and then select System Administration > Deployment Manager.
        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 or Linux:
        ./wsadmin.sh -lang jython -username primaryAdmin -password p@assword -port 8879
      • Microsoft Windows:
        wsadmin -lang jython -username primaryAdmin -password p@assword -port 8879
  2. Access and check out the Activities configuration files.
    1. Use the following command to access the Activities configuration file:
      execfile("activitiesAdmin.py")

      If prompted to specify a service to connect to, type 1 to pick the first node in the list. Most commands can run on any node. If the command writes or reads information to or from a file using a local file path, you must pick the node where the file is stored.

    2. Check out the Activities configuration files using the following command:
      ActivitiesConfigService.checkOutConfig("working_directory","cell_name")
      where:
      • working_directory is the temporary working directory to which the configuration XML and XSD files are copied and are stored while you make changes to them. Use forward slashes to separate directories in the file path, even if you are using the Microsoft Windows operating system.
        Note: AIX and Linux only: The directory must grant write permissions or the command will not run successfully.
      • cell_name is the name of the WebSphere Application Server cell hosting the IBM Connections application. This argument is case-sensitive, so type it with care. If you do not know the cell name, you can determine it by typing the following command in the wsadmin command processor:
        print AdminControl.getCell()
      For example:
      • AIX/Linux:
        ActivitiesConfigService.checkOutConfig("/opt/act/temp","foo01Cell01")
      • Microsoft Windows:
        ActivitiesConfigService.checkOutConfig("c:/act/temp","foo01Cell01")
  3. Optional: If you want to find out the current value of a property, you can list the current configuration settings and values using the following command:
    ActivitiesConfigService.showConfig()
  4. Some properties must be edited using the wsadmin client; others can only be edited by editing the configuration XML file directly. To change an Activities configuration setting, do one of the following command:
    • To edit a property using the wsadmin client, use the following command:
      ActivitiesConfigService.updateConfig("property","value")
      where property is one of the editable Activities configuration properties and value is the new value with which you want to set that property. See Activities configuration properties for a complete list of editable properties. For example:
      ActivitiesConfigService.updateConfig("activeContentFilter.enabled", "true")
    • To edit the value of a property in a configuration file directly, from the temporary directory to which you checked it out, open the file in a text editor, and then make your changes.
What to do next
After making changes, you must check the configuration files back in and you must do so during the same wsadmin session in which you checked them out for the changes to take effect. See Applying property changes for details.

Activities configuration properties

Edit Activities configuration properties to change the default behavior of the activities created by your users.

The following list identifies the Activities configuration properties that you can edit.
activeContentFilter.enabled

When enabled prevents the addition of active content (JavaScript, for example) in any text input field.

This property accepts the following String values: true or false.

Note: Disabling this filter introduces vulnerability to cross-site scripting (XSS) and other types of malicious attacks. See Securing applications from malicious attack for additional information.

jobs.30MinStats.enabled
Specifies whether to run the job that saves statistics for Activities to disk every 30 minutes. This property accepts the following String values: true or false.
jobs.30MinStats.interval
Determines the frequency with which to run the scheduled job. This property accepts a chronological expression specified as a String.*
jobs.AutoComplete.autoCompletionPeriod
Determines the time period in days that an activity must be inactive before it is automatically completed. This property accepts a number value specified as a String.
jobs.AutoComplete.enabled
Specifies whether or not to run the job that automatically completes inactive activities. This property accepts the following String values: true or false.
jobs.AutoComplete.interval
Determines the frequency with which to run the job that automatically completes inactive activities. This property accepts a chronological expression specified as a String.*
jobs.AutoComplete.prenotification
Specifies whether an activity owner is notified before an inactive activity is automatically completed. This property accepts the following String values: true or false.
jobs.DailyStats.enabled
Specifies whether to run the job that saves statistics for Activities to disk daily. This property accepts the following String values: true or false.
jobs.DailyStats.interval
Determines the frequency with which to run the scheduled job. This property accepts a chronological expression specified as a String.*
jobs.DatabaseRuntimeStats.enabled
Specifies whether to run the job that periodically collects database statistics for Activities. This property accepts the following String values: true or false.
jobs.DatabaseRuntimeStats.interval
Determines the frequency with which to run the scheduled job. This property accepts a chronological expression specified as a String.*
jobs.TrashAutoPurge.daysRetention
Determines the number of days that data must have been deleted for before being purged from the system. This property accepts an number value specified as a String.
jobs.TrashAutoPurge.enabled
Specifies whether or not to run the job that permanently removes content from the Activities trash. This property accepts the following String values: true or false.
jobs.TrashAutoPurge.interval
Determines the frequency with which to run the scheduled job. This property accepts a chronological expression specified as a String.*
objectStore.id

This property cannot be modified by the Administrator using the ActivitiesConfigService.updateConfig command. It is configured initially during installation, and its value is displayed using the ActivitiesConfigService.showConfig command.

This property displays a String value of filesystem which cannot be changed.

objectStore.maxConcurrentDownloads

Determines the number of threads that are simultaneously dedicated to servicing file download requests in the Activities server.

This property accepts a number value specified as a String.

*For information on how to format the value of an interval attribute, see Scheduling tasks.

Applying property changes in Activities

After you have edited the Activities configuration properties, check the changed configuration file in, and restart the servers to apply the changes.

Before you begin

You must perform the check in during the same wsadmin session in which you checked out the files for the changes that you made to take effect.

Procedure
  1. Check in the changed configuration property keys using the following wsadmin client command:
    ActivitiesConfigService.checkInConfig()
  2. Update the value of the version stamp configuration property in the LotusConnections-config.xml file to force users' browsers to pick up this change. See Required post-customization step for more details.
  3. To exit the wsadmin client, type exit at the prompt.
  4. Stop and restart the server hosting the Activities application.

Changing the save frequency of entries

Edit configuration property settings to change how frequently work in activity entries is automatically saved.

Before you begin

To edit configuration files, you must use the wsadmin client. See Starting the wsadmin client for details.

About this task

As users create or edit entries, their work is automatically saved every 5 minutes, unless you change the interval. If users leave an entry in an unsaved state when they accidentally close their browser, the next time they log in, a notification appears in the My Activities view reminding them that they have an unsaved entry. Autosave is not meant for backing up. This feature is provided to help you recover from unexpected events.

To change how frequently their work is automatically saved, complete the following steps

Procedure
  1. Use the wsadmin client to access and check out the Activities configuration files.
    1. Use the following command to access the Activities configuration file:
      execfile("activitiesAdmin.py")

      If prompted to specify a service to connect to, type 1 to pick the first node in the list. Most commands can run on any node. If the command writes or reads information to or from a file using a local file path, you must pick the node where the file is stored.

    2. Check out the Activities configuration files using the following command:
      ActivitiesConfigService.checkOutConfig("working_directory","cell_name")
      where:
      • working_directory is the temporary working directory to which the configuration XML and XSD files are copied and are stored while you make changes to them. Use forward slashes to separate directories in the file path, even if you are using the Microsoft Windows operating system.
        Note: AIX and Linux only: The directory must grant write permissions or the command will not run successfully.
      • cell_name is the name of the WebSphere Application Server cell hosting the IBM Connections application. This argument is case-sensitive, so type it with care. If you do not know the cell name, you can determine it by typing the following command in the wsadmin command processor:
        print AdminControl.getCell()
      For example:
      • AIX/Linux:
        ActivitiesConfigService.checkOutConfig("/opt/act/temp","foo01Cell01")
      • Microsoft Windows:
        ActivitiesConfigService.checkOutConfig("c:/act/temp","foo01Cell01")
  2. From the temporary directory to which you just checked out the oa-config.xml file, open the file in a text editor.
  3. Edit the elements in the file to set how frequently entries are automatically saved. The save interval is in minutes.
    <Autosave interval="5"/>

    Deleting this element does not turn off the autosave feature. If you delete the element, entries are saved at the default interval of 5 minutes.

  4. Save and close the oa-config.xml file.
  5. After editing, you must check the configuration files back in. You must do so during the same wsadmin session in which you checked them out for the changes to take effect. You must also restart the server. See Applying property changes for details.
  6. After restarting the Activities server, review the WebSphere Application Server SystemOut.log file to ensure that the Activities application was able to initialize with the modified configuration.

Running Activities administrative commands

Use administrative commands to perform tasks that manipulate Activities content.

Before you begin

Administrative commands interact with the Activities application and its resources through scripts. These scripts use the AdminControl object available in WebSphere Application Server wsadmin tool to interact with the Activities server. Each script uses managed Java beans (MBeans) to get and set server administration properties.

Unlike with configuration properties, when you use these commands to change server administration properties, you do not have to check out any files nor restart the server for the changes to take effect. You do, however, need to understand a bit about how to manipulate Java objects. When you perform server operations using the commands, the activities, member information, and access level information are represented as hash tables. Many of the commands, in fact, return a vector of hash tables that represent Activities resources. Commands you can use to perform tasks, such as deleting, archiving, and restoring activities, all take parameters formatted as vectors of hash tables. See Narrowing down results for some tips on how to retrieve a distinct set of activities or other resources that you can then pass to commands that perform server tasks.

When an administrative command is invoked, a SOAP request is made to the Activities application. The number of seconds that the wsadmin client waits for a response to a SOAP request is specified in the com.ibm.SOAP.requestTimeout property specified in the soap.client.props file in the following directory: {WAS_HOME}\profiles\{PROFILE_NAME}\properties. If an Activities command takes longer to complete than the value of the com.ibm.SOAP.requestTimeout property, an error is displayed on the wsadmin console, and any value returned from the invoked method is lost. The Activities command continues to be processed by the Activities application, but the connection that the Activities application had to the client that invoked it is gone. This detail is important to note because some Activities commands take a long time to run. For example, in a system with a large number of Activities, the ActivityService.fetchActivities() command can take a long time to complete. You can monitor the status of these operations by scanning the SystemOut.log file for success and failure messages.

To increase the time interval that passes before a request fails, edit the com.ibm.SOAP.requestTimeout property in the soap.client.props file. This property is a configuration property, so after editing the property, you must restart the server for the change to take effect.

Activities administrative commands

Use administrative commands to run administrative tasks on the server.

The following sections define the administrative commands that you can use when working with Activities. Each section describes the commands for a specific service. The MemberService and ActivityService commands are described in the first two sections because they are the most commonly used services. The remaining sections describe the remaining services in alphabetic order.
ActivitiesMemberService
Note:
  • The ActivitiesMemberService is the same as the MemberService. MemberService was deprecated in version 2.5.
  • The ActivitiesMemberService.updateMemberExtId(java.lang.String oldId, java.lang.String newId) command was deprecated in version 2.5.
  • The ActivitiesMemberService.syncAllMemberExtIds() and ActivitiesMemberService.updateMember(java.util.Hashtable pb) commands were deprecated in version 3.
ActivitiesMemberService.fetchCommunitiesByName (java.lang.String name)

Returns a list of communities with names that begin with the specified string. This command returns a java.util.Vector object; each object in the vector is a java.util.Hashtable object that describes one community.

Parameters:
name
The name of a community. You can provide the first word or words and any communities with names that begin with that word or words is returned. For example, "Sales community".
Note: This command was added in version 2.5.
ActivitiesMemberService.fetchMemberByEmail(java.lang.String mail)

Returns a member identified by the supplied email address. This command returns a java.util.Hashtable object that describes the member.

Parameters:
mail
A member's email address specified as a String value. For example, "paul_smith@example.com".
ActivitiesMemberService.fetchMemberById(java.lang.String id)

Returns a member identified by the supplied Activities ID. The member can be either an individual user or a group. The returned value is a java.util.Hashtable object that describes the member.

Parameters:
id
The member's unique ID as issued by the Activities application. Specify the ID as a String value. For example, "ACF1093191092345B4DB336C9B5BF9000055".
ActivitiesMemberService.fetchMemberByLogin(java.lang.String name)

Returns a member whose login name is an exact match of the supplied login name. The returned value is a java.util.Hashtable object that describes the member. This command does not return groups.

Parameters:
name
The login name specified as a String value. For example, "Paul Smith".
ActivitiesMemberService.fetchMemberByName(java.lang.String name)

Returns a member whose name is an exact match of the supplied name. This command returns both users and groups. The returned value is a java.util.Hashtable object that describes the member.

Parameters:

name
The member or group name specified as a String value. For example, "Paul Smith".
ActivitiesMemberService.fetchMembers(java.lang.String filter)

Returns a set of members whose names match the string you specify. Each member can be either an individual user or a group. The set is returned as a java.util.Vector object; each object in the vector is a java.util.Hashtable object that describes one member.

Parameters:
filter
Search query string; indicate a wildcard using an asterisk (*). The string is case insensitive.
For example, the following command returns any user or group whose name ends with "Smith":
ActivitiesMemberService.fetchMembers("*Smith")
ActivitiesMemberService.getMemberExtIdByEmail("email")
See Synchronizing user data using administrative commands for information about this command.
ActivitiesMemberService.getMemberExtIdByLogin("login")
See Synchronizing user data using administrative commands for information about this command.
ActivitiesMemberService.inactivateMemberByEmail("email")
See Synchronizing user data using administrative commands for information about this command.
ActivitiesMemberService.inactivateMemberByExtId("externalID")
See Synchronizing user data using administrative commands for information about this command.
ActivitiesMemberService.syncAllMembersByExtId({"updateOnEmailLoginMatch": ["true" | "false"] } )
See Synchronizing user data using administrative commands for information about this command.
ActivitiesMemberService.syncAllMemberExtIds()

This command was deprecated in version 3. See Synchronizing user data using administrative commands for information about the new and updated synchronization commands you can use instead.

ActivitiesMemberService.syncBatchMemberExtIdsByEmail("emailFile" [, {"allowInactivate" : ["true" | "false"] } ])
See Synchronizing user data using administrative commands for information about this command.
ActivitiesMemberService.syncBatchMemberExtIdsByLogin("loginFile" [, {"allowInactivate" : ["true" | "false"] } ])
See Synchronizing user data using administrative commands for information about this command.
ActivitiesMemberService.syncMemberByExtId("currentExternalId" [, { "newExtId" : "id-string", [ { "allowExtIdSwap" : ["true" | "false"] ] } ])
See Synchronizing user data using administrative commands for information about this command.
ActivitiesMemberService.syncMemberExtIdByEmail("email" [, {"allowInactivate" : ["true" | "false"] } ])
See Synchronizing user data using administrative commands for information about this command.
ActivitiesMemberService.syncMemberExtIdByLogin("name" [, {"allowInactivate" : ["true" | "false"] } ])
See Synchronizing user data using administrative commands for information about this command.
ActivityService
ActivityService.deleteActivities (java.util.Vector activities)

Moves the specified activities to the Trash view. Activities in the Trash view can be restored as long as they are restored before the trash is emptied. Returns a java.util.Vector; each object in the vector is a java.util.Hashtable that describes one activity that could not be deleted. A returned empty vector indicates complete success.

Parameters:
activities
Vector of hash tables describing the activities to be deleted. For example, joesactivities.
ActivityService.exportSyncedResourceInfo (filePath,eventType)

Writes a report that lists all of the community activities and identifies their associated communities. The file is saved to the directory path that you specify.

Parameters:
filePath
String that specifies the full directory path in which to store the file that is returned by the command. Include the file name in the file path and use forward slashes. For example: "C:/temp/activity_output.xml"
eventType
Identifies the type of synchronization events to report about. The only supported value for this parameter is community. Specify this value as a singular community and in lower case.
For example: ActivityService.exportSyncedResourceInfo("C:/temp/activity_output.xml","community")

You can use this command to restore backed up data. See Comparing remote application data with the Communities database for more details.

ActivityService.fetchActivities()

Gets a list of all the activities, except those that are in the Trash view.

Returns a java.util.Vector object. Each object in the vector is a java.util.Hashtable object that describes one activity.

ActivityService.fetchActivitiesByCommunityExId (java.lang.String communityUUID)

Gets a list of the community activities associated with a specific community. Returns a java.util.Vector; each object in the vector is a java.util.Hashtable that describes a community activity.

Parameters:
communityUUID
The unique ID of the community. For example, "f29b4e8e-6fad-44f4-9fca-58c46f29c38d". To find out the unique ID of a community, use ActivitiesMemberService.fetchCommunitiesByName to retrieve the community of interest, and then get the value of the externalId key of that community from the hashtable.
Note: This command was added in version 2.5.
ActivityService.fetchActivitiesByDate(java.lang.String dateType, java.lang.String beginTime, java.lang.String endTime, java.lang.String lastUUID)

Gets a list of activities that were created or modified between a date range. The maximum number of activities in the returned list is 50. To obtain all of the activities that match the criteria if the number is greater than 50, call this method in a loop providing the UUID of the 50th activity from the previous list as the lastUUID parameter. Returns a java.util.Vector object. Each object in the vector is a java.util.Hashtable object that describes one activity.

Parameters:
dateType
Date field of interest. Options are created and modified.
beginTime
Start timestamp of the range, using a yyyy.mm.dd format.
endTime
Finish timestamp of the range, using a yyyy.mm.dd format.
lastUUID
Unique ID of the last activity retrieved from a previous call of this command. Specify empty double quotes if you expect less than 50 activities in the response, or if you are running this command for the first time.
For example, the following command gets the first set of 50 activities that were created from 1 Mach 2008 through 31 March 2008:
ActivityService.fetchActivitiesByDate("created","2008.03.01","2008.03.31","")
Note: This command does not return activity templates that were created during the specified date range. This command does include in the activities that it returns any activities present in the Trash view that were created during the specified date range.
ActivityService.fetchActivityById(java.lang.String activityId)

Gets the activity identified by the given universal identifier. Returns a java.util.Hashtable object that describes the activity.

Parameters:
activityId
Unique identifier of the activity. For example, "3F9G09219392F4733F40F82A4E8D5F000083".
ActivityService.fetchActivitiesByMember(java.util.Hashtable member)

Gets a list of activities to which the specified member has access, except those that are in the Trash view. This command does not return community activities. Returns a java.util.Vector object; each object in the vector is a java.util.Hashtable object that describes one activity. It does not provide any results if the specified member is a group or a community.

Parameters:
member
java.util.Hashtable object representing the member returned from the MemberService object. For example, jane.
ActivityService.fetchActivitiesByOwner(java.util.Hashtable member)

Gets a list of activities that are owned by the specified member, except those that are in the Trash view. This command does not return community activities either. Returns a java.util.Vector object; each object in the vector is a java.util.Hashtable object that describes one activity.

Parameters:
member
java.util.Hashtable object representing the owner returned from the MemberService object. For example, paul_smith.
ActivityService.fetchActivitiesCreatedByMember(java.util.Hashtable member)

Gets a list of activities that were created by the specified member, except those that are in the Trash view. This command does not return community activities. Returns a java.util.Vector object; each object in the vector is a java.util.Hashtable object that describes one activity.

Parameters:
member
java.util.Hashtable object representing the member returned from the MemberService object. For example, paul_smith.
ActivityService.fetchCompletedActivities()

Gets a list of all completed activities in the service, which are activities that have been marked complete and are displayed in the Completed view. Completed activities are not included in the Trash view; it is not until a completed activity is deleted that it is moved to the Trash view.

Returns a java.util.Vector object. Each object in the vector is a java.util.Hashtable object that describes one activity.

ActivityService.fetchDeletedActivities()

Gets a list of all deleted activities in the service. These are activities that are currently in the Trash view.

Returns a java.util.Vector object. Each object in the vector is a java.util.Hashtable object that describes one activity.

AccessControlService
Note: You cannot use the AccessControlService commands to fetch, set, or delete access to community activities. See Communities administrative commands for information about the command you can use to add a person to a community.
AccessControlService.deleteAccess(java.util.Vector activities, java.util.Vector members)

Removes access privileges to the specified activities for the specified members. Returns a java.util.Vector object; each object in the vector is a java.util.Hashtable object that describes one activity whose access could not be deleted. A returned empty vector indicates success.

Parameters:
activities
Vector of hash tables representing the activities whose access will be modified. For example, joesactivities.
members
Vector of hash tables representing the members returned from the MemberService object.
AccessControlService.fetchAccess(java.util.Hashtable activity)
Gets a list of all of the members that have access to the specified activity. Returns a java.util.Vector object; each object in the vector is a java.util.Hashtable object that describes one entry, either a user or group, in the access list. The elements returned in the Hashable are:
  • displayName
  • email: Returns for members only, not groups.
  • externalId
  • loginNames: Returns for members only, not groups.
  • memberId
  • memberType
  • role
  • staticProfile
Parameters:
activity
Hash table representing the activity.
The following code is an example of what is returned by this command:

[{memberId=675G09219107D9BB025252223E2BC9000001, displayName=Amy Jones, loginNames=[Amy Jones, ajones@acme.com], staticProfile=false, externalId=3AB586F4-A4D2-43C8-92DB-2DC3B2291803, email=ajones@acme.com, memberType=person, role=owner}, {memberId=D76G0921910768409A3F871F14596C000088, displayName=Amy Jacobs, loginNames=[Amy Jacobs, ajacobs@acme.com], staticProfile=false, externalId=DE1D832B-1024-43B1-A12C-F1B643C2B6A2, email=ajacobs@acme.com, memberType=person, role=reader}, {memberId=812G09219107D9BB025252223E2BC900000A, displayName=ajonesgroup, staticProfile=false, externalId=41565591-1A33-4F9B-88D9-335D96BFB3B2, memberType=group, role=reader}]

AccessControlService.setMembersAccess(java.util.Vector activities, java.util.Vector members)

Sets the specified members as members with author access to the specified activities. Returns a java.util.Vector object; each object in the vector is a java.util.Hashtable object that describes one activity whose access could not be modified. A returned empty vector indicates success.

Parameters:
activities
Vector of hash tables representing the activities whose access will be modified.
members
Vector of hash tables representing the members returned from the MemberService object.
Note: In 2.5, this command named changed from setMemberAccess to setMembersAccess.
AccessControlService.setOwnerAccess(java.util.Vector activities, java.util.Hashtable owner)

Sets the specified member as an owner of the specified activities. Returns a java.util.Vector object; each object in the vector is a java.util.Hashtable object that describes one activity whose access could not be modified. A returned empty vector indicates success.

Parameters:
activities
Vector of hash tables representing the activities whose access will be modified.
owner
Hash table representing the member returned from the MemberService object.
AccessControlService.setOwnersAccess(java.util.Vector activities, java.util.Vector owners)

Sets the specified members as owners of the specified activities. Returns a java.util.Vector object; each object in the vector is a java.util.Hashtable object that describes one activity whose access could not be modified. A returned empty vector indicates success.

Parameters:
activities
Vector of hash tables representing the activities whose access will be modified.
owners
Vector of hash tables representing the members to whom you want to give owner access.
Note: This command was added in version 2.5.
AccessControlService.setReadersAccess(java.util.Vector activities, java.util.Vector members)

Sets the specified members as readers of the specified activities. Returns a java.util.Vector object; each object in the vector is a java.util.Hashtable object that describes one activity whose access could not be modified. A returned empty vector indicates success.

Parameters:
activities
Vector of hash tables representing the activities whose access will be modified.
members
Vector of hash tables representing the members returned from the MemberService object.
Note: In 2.5, this command named changed from setReaderAccess to setReadersAccess.
AccessControlService.syncAllCommunityShares()
Updates the Activities data store to reflect changes made to the name or access level of a community. If the community no longer exists, the membership of the activity is updated to remove the community.
Note: This command was added in version 3.
ActivitiesConfigService
ActivitiesConfigService.checkOutConfig("working_directory", "cell_name")

Checks Activities configuration files out to a temporary directory.

working_directory
Temporary working directory to which the configuration files are copied. The files are kept in this working directory while you make changes to them. When you specify a path to the working directory on a system running Microsoft Windows, use a forward slash for the directory. For example: "C:/temp".
Note: AIX and Linux only: The working directory must grant write permissions or the command will not run successfully.
cell_name
Name of the WebSphere Application Server cell hosting the Lotus Connections application. If you do not know the cell name, type the following command while in the wsadmin command processor:
print AdminControl.getCell()
For example:
  • AIX/Linux:
    ActivitiesConfigService.checkOutConfig("/opt/my_temp_dir", "CommServerNode01Cell")
  • Microsoft Windows:
    ActivitiesConfigService.checkOutConfig("c:/temp","foo01Cell01")
ActivitiesConfigService.showConfig()
Displays the current configuration settings. You must check out the configuration files with ActivitiesConfigService.checkOutConfig before running ActivitiesConfigService.showConfig.
ActivitiesConfigService.updateConfig("property_name", "new_value")
Updates configuration properties.
property_name

See Activities configuration properties for configuration properties and descriptions.

new_value
The new value for the property. Acceptable values for properties can be restricted, for example to either true or false. See Activities configuration properties for configuration properties and descriptions.
ActivitiesConfigService.checkInConfig()

Checks in Activities configuration files. Run from the wsadmin command processor.

ActivitiesScheduler
ActivitiesScheduler.getTaskDetails(java.lang.String taskName)

Gets the list attributes of the named task. Returns a java.util.Hashtable object that contains the attributes.

Parameters:
taskName
Name of the task specified as a String value. For example:
  • "30MinStats"
  • "ActivityAutoCompleteJob"
  • "DailyStats"
  • "DatabaseRuntimeStats"
  • "TrashAutoPurgeJob"
ActivitiesScheduler.pauseSchedulingTask(java.lang.String taskName)

Suspends scheduling of a task. Has no effect on currently running tasks. Returns a 1 to indicate that the task has been paused. Paused tasks remain paused until you explicitly resume them, even if the server is stopped and restarted.

Parameters:
taskName
Name of the task specified as a String value. For example:
  • "30MinStats"
  • "ActivityAutoCompleteJob"
  • "DailyStats"
  • "DatabaseRuntimeStats"
  • "TrashAutoPurgeJob"
ActivitiesScheduler.resumeSchedulingTask(java.lang.String taskName)

Resumes the start of a paused task. Returns a 1 to indicate that the task has been resumed.

Parameters:
taskName
Name of the task specified as a String value. For example:
  • "30MinStats"
  • "ActivityAutoCompleteJob"
  • "DailyStats"
  • "DatabaseRuntimeStats"
  • "TrashAutoPurgeJob"
ArchiveService
ArchiveService.createActivities(java.lang.String directory, java.util.Vector activities)

Creates new activities from the previously exported activities specified by the vector. If an activity being imported with this command already exists, a second activity is created. Returns a java.util.Vector object; each object in the vector is a java.util.Hashtable object that describes one activity that could not be created. A returned empty Vector indicates success.

Parameters:
directory
Directory on the file system from which to import the activities. For example, "C:/AllExports".
activities
Vector of hash tables; each hash table describes an Activity to be created. For example, allexports.
ArchiveService.deleteActivities(java.lang.String directory, java.util.Vector activities)

Deletes the previously exported activities specified by the vector from the specified directory. Use this command to delete activities from the archive repository, not from the Activities server or database. Returns a java.util.Vector object; each object in the vector is a java.util.Hashtable object that describes one activity that could not be deleted. A returned empty vector indicates success.

Parameters:
directory
Archive directory on the file system from which to delete the activities. For example, "C:/AllExports".
activities
Vector of hash tables; each hash table describes an activity to be deleted. For example, janesactivities.
ArchiveService.exportActivities(java.lang.String directory, java.util.Vector activities)

Exports the activities specified by the Vector into the specified directory; this method will overwrite an activity if it already exists in the specified directory. Returns a java.util.Vector object; each object in the vector is a java.util.Hashtable object that describes one activity that could not be exported. A returned empty Vector indicates success.

Parameters:
directory
Directory on the file system to which to export the activities. For example, "C:/temp/zips".
activities
Vector of hash tables; each hash table describes an activity to be exported. For example, activities.
ArchiveService.fetchActivities(java.lang.String directory)

Gets a list of all archived activities in the specified directory. Returns a java.util.Vector object; each object in the vector is a java.util.Hashtable object describing an archived activity in the directory.

Parameters:
directory
Directory on the file system that contains the archived activities. For example, "C:/AllExports".
ArchiveService.fetchActivitiesByMember(java.lang.String directory , java.util.Hashtable member)

Gets a list of all archived activities in the specified directory to which the specified member has access. Returns a java.util.Vector object; each object in the vector is a java.util.Hashtable object describing an archived activity in the directory. This command does not return community activities.

Parameters:
directory
Directory on the file system that contains the archived activities. For example, "C:/AllExports".
member
Hash table representing the members returned from the MemberService object. For example, paul_smith.
Note: Do not use this command to fetch activities that were exported from a different deployment of IBM Connections. This commands uses the member ID to find the activities, and member IDs are not persisted across different deployments. Only use this command to collect activities when you are importing the activities to the same server from which they were exported. If you are importing the activities to a different server, use the ArchiveService.fetchActivities(directory) command instead.
ArchiveService.fetchActivitiesByOwner(java.lang.String directory , java.util.Hashtable member)

Gets a list of all archived activities in the specified directory that are owned by the specified member. Returns a java.util.Vector object; each object in the vector is a java.util.Hashtable objects describing an archived activity in the directory. This command does not return community activities.

Parameters:
directory
Directory on the file system that contains the archived activities. For example, "C:/AllExports".
member
Hash table representing the owners of archived activities returned from the MemberService object. For example, paul_smith.
Note: Do not use this command to fetch activities that were exported from a different deployment of IBM Connections. This commands uses the member ID to find the activities, and member IDs are not persisted across different deployments. Only use this command to collect activities when you are importing the activities to the same server from which they were exported. If you are importing the activities to a different server, use the ArchiveService.fetchActivities(directory) command instead.
ArchiveService.fetchActivitiesCreatedByMember(java.lang.String directory, java.util.Hashtable member)

Gets list of all archived activities in the specified directory that were created by the specified member. Returns a java.util.Vector object; each object in the vector is a java.util.Hashtable object describing an archived activity in the directory. This command does not return community activities.

Parameters:
directory
Directory on the file system that contains the archived activities. For example, "C:/AllExports".
member
Hash table representing the member who created the archived activities returned from the MemberService object. For example, jane.
Note: Do not use this command to fetch activities that were exported from a different deployment of IBM Connections. This commands uses the member ID to find the activities, and member IDs are not persisted across different deployments. Only use this command to collect activities when you are importing the activities to the same server from which they were exported. If you are importing the activities to a different server, use the ArchiveService.fetchActivities(directory) command instead.
ArchiveService.importActivities(java.lang.String directory, java.util.Vector activities)

Imports the activities specified by the Vector whose archives are located in the specified directory into the Activities application. This method overwrites an activity if it already exists. Returns a java.util.Vector object; each object in the vector is a java.util.Hashtable object that describes one activity that could not be imported. A returned empty Vector indicates success.

Parameters:
directory
Directory on the file system from which to import the activities. For example, "c:/temp/zips".
activities
Vector of hash tables; each hash table describes an activity to be imported. For example, activitiesToImport.
ListService
ListService.filterActivitiesByName(inList, toMatch)

Represents a script that can be used to filter or narrow down a list of activities matching certain criteria. This script is useful for locating a subset of activities that can then be used as input for a subsequent command. A typical example is creating a list of activities for export. Returns a list of activities whose Title field matches the pattern criteria.

Parameters:
inList
Previously fetched list of activities.
toMatch
Java regular expression pattern representing match criteria. This pattern is used to search the title of the activity. The pattern must match the full name and is case sensitive. You can use the following keys:
  • Period (.) matches any character.
  • Plus sign (+) matches one or more instances of the previous character. For example, .+ matches all sequences of one or more characters.
  • Asterisk (*) matches zero or more instances of the previous character. For example, * matches all sequences of characters.
  • [chars] matches any one character within the brackets ([]). For example, [Gg] matches either an upper or lower case G.
  • [A-Z] matches a range of characters.
Example:
execfile("activitiesAdmin.py")


# Fetch all activities and save
# to variable named "all"

all=ActivityService.fetchActivities()

# From the list of all activities,
# Extract activities whose name 
# begins with "Sales"

sales=ListService.filterActivitiesByName(all,"Sales.*")

# Activities in "all" that begin 
# with "Sales" are saved in the 
# variable named "sales". The 
# variable "sales" can be used as 
# input for other commands, such 
# as the command to export 
# activities. The following command
# will export all the activities 
# whose name begins with "Sales" to
# the /opt/foo folder.

ArchiveService.exportActivities(
 "/opt/foo", "Sales.*")