IBM Connections 4 Part 1: Overview, Planning, Installing, Migrating

IBM Connections 4 Documentation Part 1: Overview, Planning, Installing, Migrating

Product overview

Learn how to deploy, customize, and administer the IBM® Connections social networking product.

What is IBM Connections?

IBM Connections is social networking software that consists of these applications: Activities, Blogs, Bookmarks, Communities, Files, Forums, Home page, Metrics, Profiles, and Wikis.

Use the IBM Connections applications to accomplish the following goals:

Activities
Collaboration tool for collecting, organizing, sharing, and reusing work that is related to a project goal.
Blogs
Online journals that you can use to deliver timely information with a personal touch. You can use a blog to present your ideas and get feedback from others or learn from the expertise of others who blog.
Bookmarks
Social bookmarking tool for saving, organizing, and sharing Internet and intranet bookmarks. Discover bookmarks that have been created by others with similar interests and expertise.
Note: The application was previously named Dogear.
Communities
A website where people who share a common interest can interact with one another, share information, and exchange ideas. Community members can participate in community-specific activities and forums, and can share blogs, bookmarks, feeds, and files.
Files
A common repository in which you can upload files and share them with others. Store versions of a file, view who has downloaded a file or commented on it, and see highly recommended files.
Forums
A place to brainstorm and collect feedback on topics that are relevant to you and your colleagues. Statements and comments are collected in a format that captures the exchange of ideas and presents them as an ongoing conversation.
Home page
A central location that provides a snapshot of the latest updates collected from IBM Connections. Perform in-context actions on entries in your activity stream, check the latest updates from the content and people that you are following, stay up to date with the latest notifications and updates that require a response from you, or post your own status updates.
Profiles
Directory of the people in your organization, including the information you need to form and encourage effective networks across your organization.
Metrics
Statistics tool that collects and displays information about how people use Connections applications. Community metrics show details on a particular community while global metrics show information across all of Connections.
Wikis
A tool for creating wikis that individuals, groups, and communities can use to capture, share, and coauthor information. View page changes, recommendations, and comments.

Together, these tools will help you and your colleagues interact with one another more effectively.

What's new in IBM Connections 4?

Find out what has changed or been added with this release of IBM Connections.

What's new in using?

IBM Connections:

  • Share a status update or file from anywhere in IBM Connections. Log in and then click the Share link in the header.
  • The activity stream displays an aggregated view of the latest updates from people or events that you are following and people in your network. To view more information about an update, repost it, or like it, click the entry to launch the embedded experience.
  • IBM Connections now introduces an enhanced Metrics application. Metrics employs the analytic capabilities of the IBM Cognos® Business Intelligence server, which is provided as part of the IBM Connections installation to support the collection of metrics data. Administrators and designated users can work with interactive displays of global metrics by clicking Server Metrics in the footer. Community owners can view non-interactive reports for their communities by clicking Metrics in the navigation pane.
  • The rich text editor, which is used across the IBM Connections applications, has been upgraded to CKEditor 3.6.3 in this release. There are a number of new features in the Wikis editor.
  • Profiles has been updated to include the activity stream, which shows the profile owner's latest updates from across IBM Connections.
  • When viewing your search results, you can filter the results from Profiles to exclude inactive profiles by selecting Exclude Inactive People from the Show menu on the Profiles Search Results page.
  • The social analytic widgets now recommend private as well as public content, based on your existing relationships with public and private content in IBM Connections.
  • The Trending widget displays a list of the hot topics that are trending in your organization. The widget displays when you filter your search results using the Status Updates option.
  • Status updates and microblogging content are now included in the analysis of the relationships that are used to recommend content and people in the social analytics widgets.

Activities:

  • Activity members are now displayed in a Members view within the activity instead of in a Members section in the navigation pane.
  • Standard activity owners can go to the Members view to make an activity public.
  • Titles and descriptions in activity entries are automatically saved so that if you are unexpectedly disconnected from the application, you do not lose your latest changes.
  • In an activity entry, you can link to files and folders in the Files application.
  • Activity owners can convert an entry into a to do item.

Blogs:

User interface improvements make it easier for you to go directly to your blogs.

Bookmarks:

The following features are new for Bookmarks:
  • A new user interface makes it easier for you to access and manage bookmarks.
  • When you install the Add Bookmark browser button, you also have the option to install a Discuss This and Related Community browser buttons for posting web pages to an IBM Connections forum or linking together related communities.

Communities:

  • The Events widget allows community owners to share information about upcoming events with the rest of the community.
  • For deployments that make use of owner moderation of communities, owners can disable content approval and content flagging on individual communities.
  • Use the Related Communities widget to suggest communities for colleagues to join.
  • Share status with members of your community.
  • The Recent Updates view provides a centralized place to see what is new in a community.
  • You can add more information to the community description and it is collapsible.
  • LDAP groups can now be added as members of a community.

Files:

  • Files now enables you to do the following actions:
    • Upload multiple files at the same time.
    • Download all of the files in a view.
    • Add files to a folder during upload.
    • Select and perform actions on multiple files at one time.
    • Delete a file version.
    • Share folders with communities.
    • Give community members access to edit files you own.
    • Move files uploaded to a community to trash; from trash you and others can restore or delete the files.
    • Stop sharing a file in one action, including removing the file from any shared folders and communities.
    • Stop sharing files that were shared with you. For example, if someone shared a file with you, and then you shared the file with a community, you can stop sharing with the community.
  • A file’s owners and editors can lock and unlock the file.
  • The file lock icon displays a red key in the owner’s view when the file is locked by another user. The file owner can unlock the file at any time.
  • A graphic Like option is now available on the file page; the Recommend file option has been changed to a Like file option.
  • For files that you are adding or have added to a folder, you can give access to those files to anyone who has access to the folder.
  • The files summary page and tabs have been redesigned to provide more information, such as in which folders the file resides and whether the file is referenced by status updates.
  • The Communities application contains an option for displaying files that are shared through the community.
  • Files that are referenced in one or more status updates are noted as such.

Forums:

  • When a user is notified by email that someone has added a topic to a forum, the user can click a Reply to this topic link in the email. This creates a response email the user can add content to and send. This create a new forum topic as a response to the topic they were notified about in the email. Attachments in the email are added to the response topic.
  • You can add content from any web page or IBM Connections source to a forum topic by clicking a button in your browser tool bar. Click Bookmark or Discuss This, and then follow the steps for installing the Discuss This button. Then navigate to any web or IBM Connections page, click Discuss This, and select a forum to post the content to.

Home page:

  • The Home page user interface has been updated so that it is easier to find information that is important to you. The Updates tab and the Widgets tab have been replaced by a single page with different views available from the navigation sidebar. Use these views to filter the display and check for your latest updates and notifications. For example, you can check the Action Required view for items that require a response from you. The My Notifications view now includes responses to topics in addition to notifications that you have sent and received. For more information about the different views, see Home page views.
  • The improved microblogging experience allows you to gather information in a meaningful way and act on it in context. You can now attach files to your status updates, and use hashtags to tag your updates and make them easier for other users to find. You can repost status updates to share information with the people who are following you, or click Like to recommend an update. You can also preview images and download files to work on them locally.
  • The steps for following tags from the Home page have changed.
  • The Events widget helps you to keep track of upcoming community events that you are attending and that you are following. The widget is available from the activity stream views.

Profiles:

  • The The Board tab has been replaced with the Recent Updates tab on the user’s profiles page. The Recent Updates list of posts is similar to the board in that it displays status messages and responses. It also includes information about other actions performed by the profile owner, such as sharing a file or adding a post to a blog. The message posting area itself is essentially identical to the earlier version, enabling you and others to view and post messages to a user’s wall.
  • The Recent Posts tab on the Profiles page has been removed. Recent posts appear under the profile owner’s Recent Updates tab.
  • Use the Recent Updates area on your profile page to post a status message.
  • The business card has been redesigned for improved layout and access.
  • On the Invite to My Network page, the Also Follow option is enabled by default.
  • You can now accept a network invitation from the inviter's profile page.
  • The Network Contact or Pending Invitation indicator label now displays next to the person’s name on their profile page.
  • You can now accept an invitation to join a person’s network from that person’s profile page.

Wikis:

  • There are no longer My Wikis and Public Wikis tabs. All views are together in the same list.
  • See wikis you are following by clicking I'm Following.
  • Pages can be removed from a wiki by moving them to the trash. From the trash, pages can be deleted or restored to the wiki.
  • You can now download a version of a page from the page comparison view, as an HTML file.
  • The wiki editor has been updated. Administrators can divide toolbars into multiple toolbars. You can navigate between toolbars with the Tab key. Also, toolbars now include a button for adding and editing iFrames.
  • The wiki editor has two new features: the editor area expands downward as you add content. As your editing space expands, a toolbar displays even if scrolling is required.

What's new in installing?

  • The installation wizard is based on IBM Installation Manager 1.4.4.
  • You can install and configure IBM Cognos Business Intelligence, obtained separately, by using the scripts, models, and specifications that are included with IBM Connections.
  • Console Mode is available. Use this character-based interface to install, modify, or uninstall the product when you do not have access to the graphical interface.
  • Silent installation has been extended so that you can install both IBM Connections and IBM Installation Manager in silent mode.
  • The initial configuration of administrators for Home page and Blogs is now handled automatically during installation. However, to configure widgets, you still need to assign a Home page administrator.

What's new in administering?

IBM Connections:
  • You can run Profiles synchronization commands in preview mode. See Synchronizing user data using administrative commands.
  • There is an entirely new interface for viewing metrics. The Metrics application uses IBM Cognos Business Intelligence to collect and display statistics that show how people use Connections. With the new Metrics application, community owners can view metrics for their own communities, and system administrators plus designated users can view and interact with server-level metrics that show information across all of Connections.
  • All of the applications now use Freemarker templates for notifications. This has no effect on email notifications.
  • There are several changes to the configuration of IBM Sametime® awareness through the Sametime server. See Adding Sametime awareness through the Sametime server
  • You can remove microblogging functionality from your deployment by disabling the microblogging service reference in the LotusConnections-config.xml file.
Activities:
  • The underlying implementation of the Activities content store is changing with release 4. If you are installing Activities for the first time, the new implementation is used to store resources associated with Activities automatically. If you are upgrading from a previous version of Activities, Activities data continues to be stored in the existing content store, which uses the old implementation. If you want to gain the benefits of the new implementation, you can create an additional content store which uses it. See Defining multiple content stores for Activities for more details.
Blogs:
  • The Blogs frontpage blog is now created for you by default when you install the Blogs service.
  • A new configuration property, connections.blogs.feed.return401_fornopermission_toviewblog, lets you change the error page returned when a user cannot access a blog page from 401 to 403.
  • A new configuration property, connections.blogs.onlymembercanvote lets you limit voting in an Ideation blog to community members.
  • A new configuration property, connections.blogs.lastModifierDisabled, controls whether or not to display the last modifier information in blogs entries.
  • Blogs notification is simplified so that you have fewer notification templates to configure.
Bookmarks:
  • Administrators can control whether Bookmarks links are redirected from the Bookmarks application or whether external links directly access external web pages.
Communities:
  • You can create an administrator who can edit the content of all communities, public and restricted. For more information, see Administering community content.
  • You can configure Linked Library widgets (formerly named Custom Library widgets) in communities by editing a new library-config.xml file. Properties in that file control functionality such as whether to display the person card for the ECM users, whether to download files through a proxy or directly from the ECM server, and whether to display the Views dropdown on the main document list. For more information, see Managing Linked Libraries.
Files:
Forums:
  • Use the ForumsService.filterInput command to retrieve a subset of forums on which you want to perform an operation.
  • You can now manually recalculate the count of forums and forum topics in your organization using administrative commands.
  • You can enable and disable a that allows users to click a button to add the contents of a current web or IBM Connections page to a forum. When enabled, users can click Bookmark or Discuss This in the footer of any IBM Connections page and add a Discuss This button to their browser tool bar. When they click it, then select a forum they have posting access to, the current content of the page is added to a new forum topic.
  • There is a new command, ForumsTrashService.filterForumsByName(), to help you restore forums from the trash by filtering on forum names.
  • You can ensure that only a topic or replay creator can edit their topic or reply.
Home page:
  • The Home page administrative user interface has been updated to include options for adding custom widgets that are based on the OpenSocial gadget specification.
News:
Profiles:
Search:
Note: IBM Connections 4 includes new and enhanced APIs for Search. These APIs are now documented in the following wiki:
http://www-10.lotus.com/ldd/appdevwiki.nsf/xpViewCategories.xsp?lookupName=Product%20Documentation
  • This release of IBM Connections introduces a new folder structure in which each application has its own index folder. The Search application also uses new folders to contain backup indexes, provide a staging location for the index, store the XML files that are created after an application is crawled, and store the content extracted from files.
  • The crawling and indexing processes are now carried out in separate phases so that the process of crawling an application is completed before indexing for that application begins. This update to the two-stage indexing process results in improved reliability and performance.
  • When you build the index for the first time, you no longer need to manually copy the index to each node that is running the Search application. This process is now automated.
  • The resumption of interrupted or failed crawling and file content extraction now takes place automatically, and is always enabled for both initial and incremental indexing.
  • The Search application now has much faster file content extraction due to direct access to the file system used by Files and Wikis to store file content.
  • A reduced need for server restarts means that you can now build a new Search index using the background indexing SearchService commands and switch over a production deployment to the new index without a server restart. Similarly, you can update Search configuration options and apply them without a server restart using the reloadSearchConfiguration command.
  • Status updates and community events are now included in the content that is indexed by the Search application.
  • A new facet known as trending is applied to search results that are specific to status updates. Using this facet, keywords are extracted from recent status updates and weighted based on frequency of use.
  • Language guessing has been improved for field-level searches to ensure more accurate search results.
  • The command for creating a stand-alone index has been extended to include two additional parameters. These parameters allow you to persist application seedlists to a specified location and also to specify a file content extraction location if you have already extracted file content using the SearchService.startBackgroundFileContentExtraction command or during a previous run of the SearchService.startBackgroundIndex command.
  • If you are experiencing problems with crawling, use the SearchService.startBackgroundCrawl command to run a background crawl and verify that the process is completing successfully.
  • The SearchService.startBackgroundFileContentExtraction command allows you to extract file content outside of the indexing process.
  • By updating a configuration setting in the search-config.xml file, you can specify that interrupted or failed indexing tasks are automatically resumed..
  • Additional globalization settings are available for Search. In addition to configuring accent-insensitive searching, you can enable settings to ignore punctuation in search terms and perform a one-to-two mapping in search terms.
  • You can perform a number of steps to verify that the Search is working as expected.
  • Verbose logging can help you to monitor the progress of the Search crawling and indexing operations. For more information, see Configuring verbose logging.
  • The following commands that were previously used for enabling and disabling indexing tasks according to task type have been replaced. Use the SearchService.enableTask(String taskName) and SearchService.disableTask(String taskName) to enable and disable indexing tasks instead.
    • SearchService.enableFileContentTask(String taskName)
    • SearchService.enableIndexingTask(String taskName)
    • SearchService.disableFileContentTask(String taskName)
    • SearchService.disableIndexingTask(String taskName)
  • A new SearchService command enables you to get a list of the tasks that are currently running for the Search application.
  • You can delete all scheduled tasks for Search using the SearchService.deleteAllTasks() command. For more information, see Deleting scheduled tasks for Search.
  • If you want to delete all scheduled tasks from the Home page database and restore the default tasks that are automatically configured when you first install the product, use the SearchService.resetAllTasks() command.
  • Use the SearchService.retryIndexing command when you want to reindex content that was not indexed successfully during initial or incremental indexing.
  • A new administrative command allows you to free up disk space by deleting persisted seedlist data from your system.
  • Use the SearchService.listIndexingNodes() command to verify the names of the Search indexing nodes in your deployment. For more information, see Listing indexing nodes.
  • When restoring the Search index, the steps that you perform depend on what type of environment you are using. For more information, see Restoring the Search index.
  • You can edit settings in the search-config.xml file to specify the maximum number of seedlist threads used when indexing.
  • When you add a new node to your deployment after installing IBM Connections, you need to manually create Search work managers for the newly-added node.
  • New commands are available to allow you to reload the Search index and configuration without having to restart the Search application.
  • You can edit settings for persisted data to specify whether the data is deleted after a successful incremental index and also specify the maximum age for persisted pages.
  • Update the seedlistSettings.maximumIncrementalQuerySpanInDays property when you want to avoid performance hits by avoiding unnecessary full search crawls.
  • The seedlistSettings.maximumPageSize property allows you to specify the maximum number of items on a search results page.
  • You can specify the default timeout for seedlist requests by creating an IBM WebSphere Application Server environment variable named SEARCH_SEEDLIST_TIMEOUT and setting the required value of the timeout.
  • You can change your deployment settings so that search results related to inactive users are automatically included in search results.
  • A new SearchService administrative command enables you to list the indexing tasks defined for the social analytics service.
  • The SearchCellConfig.setSandIndexerTuningcommand lets you tune the social analytics indexing process by configuring the number of iterations used by the indexing jobs. For more information, see Tuning social analytics indexing.
  • You can now configure dynamic, global properties for the social analytics service using SearchService commands.
Wikis:
  • There are no Wikis administrative updates in this release.

What's new in customizing?

Important: If you customized the IBM Connections user interface in a previous release of the product, note that there is no migration path provided for importing your changes into IBM Connections 4. Before upgrading to IBM Connections 4, review and make a note of your existing customizations so that you can verify them post-migration and rework if necessary.
  • Review the customization tips and best practices provided to help you to implement and manage customizations in your IBM Connections deployment.
  • Many of the customization paths have changed since the previous release of IBM Connections. For more information, refer to the individual task topics in the Customizing section of the product documentation.
  • You can customize sprited images by modifying the images and copying them to the appropriate customization directory.
  • When you want to completely change the behavior of a Dojo module and you need the change to take effect as soon as the module is loaded, you can override the JavaScript files used by IBM Connections.
  • You can extend the user interface by packaging your JavaScript, HTML, and CSS resources as an OSGi bundle when you want to add new functionality, widgets, or scripts to the product.
  • In this release of the product, you can extend your deployment by adding custom JSTL tags. For more information, see Extending JSP files with custom tags.
  • Customize notifications by modifying existing template files or by replacing files with custom templates created by you. You can also edit the text strings and images used in notifications.

What's new in security?

  • OAuth support – You can now use OAuth to support API access to IBM Connections. See Allowing third-party applications access to data and the API Reference and Open Authorization sections of the IBM Social Business Development wiki for details.
  • Users can allow applications access to their Connections data without sharing credentials, and revoke that access at any time.
  • Also, users can report a malicious application to an administrator who can remove it from the list of applications enabled for OAuth.

What's new in mobile?

  • Starting with the IBM Connections 3.0.1 July 2011 Mobile release, you can access IBM Connections from a mobile device using an app designed specifically for that device. With the Connections 4 release, these native apps have been enhanced. To support the enhancements, there is now a database associated with the Mobile application and a configuration file that administrators can edit to customize the native applications.

What's new in developing?

The Connections API documentation has been moved to the API Reference section of the IBM Social Business Development wiki.

What's new in troubleshooting and support?

Supported languages

The IBM Connections user interface is available in multiple languages.

The following languages are supported:
  • Arabic
  • Catalan
  • Chinese - simplified and traditional
  • Czech
  • Danish
  • Dutch
  • Finnish
  • French
  • German
  • Greek
  • Hebrew
  • Hungarian
  • Italian
  • Japanese
  • Kazakh
  • Korean
  • Norwegian
  • Polish
  • Portuguese -- Brazilian and traditional
  • Russian
  • Slovenian
  • Spanish
  • Swedish
  • Thai
  • Turkish
The following languages are supported by the product installation wizard:
  • Brazilian Portuguese
  • Chinese - simplified and traditional
  • Czech
  • Danish
  • English
  • French
  • German
  • Greek
  • Hungarian
  • Italian
  • Japanese
  • Korean
  • Polish
  • Russian
  • Spanish
  • Turkish
The product documentation is sourced in English and translated into a subset of the languages supported by the product. See the IBM Translated Product Documentation page of the wiki for more information.
Related tasks:
Related reference:

Administrators: Deploying a preview guide to your users

The IBM Connections 4 preview guide is available for you to distribute to your users for new installations and upgrades to IBM Connections 4. This guide is designed to help your users become productive on the new software quickly, and to provide them with links to documentation resources for further help.

About this task

This guide provides the following information for this release:
  • Overview of several new applications
  • Important changes from the previous release
  • Familiar applications that remain the same
  • Links to product tours, reference cards, and product documentation
  • A few key productivity tips
You can download the preview guide from the IBM Connections wiki at http://www-10.lotus.com/ldd/lcwiki.nsf. There are two files available to you:
  • An Adobe PDF file, ready for emailing, printing, or distributing to your organization.
  • An IBM Symphony™ ODT file that can be customized for your organization; for example, you can add contact information for your Help Desk.
    Note: This file includes instructions in blue text for customizing information. Remember to remove these instructions before rolling out the file to your organization.

It is recommended that you distribute the guide to your users before their new IBM Connections software is installed or updated.

Accessibility

Accessibility applications help users who have a disability, such as restricted mobility or limited vision, to use information technology products successfully.

IBM strives to provide products with usable access for everyone, regardless of age or ability.

The major accessibility features in this product enable users to do the following tasks:
  • Use assistive technologies, such as screen-reader software and digital speech synthesizer, to hear what is displayed on the screen. Consult the product documentation of the assistive technology for details about using those technologies with this product.
  • Operate specific or equivalent features using only the keyboard.
  • Customize display attributes such as color, contrast, and font size.
  • Magnify what is displayed on the screen.
Note: The accessibility of IBM Connections is optimized when using a Microsoft Windows XP client, Microsoft Windows Server 2003 or later, FireFox 3.6 or later, and JAWS 12 or later.
In addition, the documentation was modified to include the following features to aid accessibility:
  • All documentation is available in HTML formats to give the maximum opportunity for users to apply screen-reader software technology.
  • All images in the documentation are provided with alternative text so that users with vision impairments can understand the contents of the images.

IBM Connections user interface

This product uses standard Windows navigation keys. Refer to the Product accessibility topic in the Using section of this product documentation for information about any unique keys that are used by the individual applications.

To display the business card, hover over a person's name, and then press Ctrl + Enter to open the business card. Press Tab to set focus to the first element in the business card

For JAWS users: To activate buttons in the user interface, press the Enter key, even when JAWS announces to use the space bar.

For administrators installing the product

For optimal accessibility when installing IBM Connections, follow the instructions to install the product in console mode. See Accessibility applications for installing IBM Connections for more details.

IBM and accessibility

See the IBM Human Ability and Accessibility Center for more information about the commitment that IBM has to accessibility:

Planning

Before installing IBM Connections, study the system requirements, deployment options, and documentation conventions.

Audience

This Installation Guide assumes that you have prior experience with products that support enterprise web applications.

IBM Connections has dependencies on a number of other products. This guide assumes that you have a basic knowledge of those products, including how to:
  • Install, configure, secure, and administer IBM WebSphere Application Server.
  • Install IBM Tivoli Directory Server, Microsoft Active Directory, Sun Java™ System Directory Server, or IBM Lotus Domino® LDAP directory, and then configure WebSphere Application Server to use that LDAP directory with federated repositories.
  • Create, manage, and drop IBM DB2®, Oracle, or Microsoft SQL Server databases.
  • Install IBM HTTP Server, and then configure it to interact with IBM WebSphere Application Server over HTTP and HTTPS.

Directory path conventions

Directory variables are abbreviations for the default installation paths for IBM AIX®, Linux, and Microsoft Windows. This topic defines the directory variable and its matching default installation directory for each supported operating system.

Notes:
  • The term Linux in this documentation includes the Linux for System z® platform, unless otherwise specified.
  • Many examples of directory and file paths in this documentation use the UNIX '/' separator to denote AIX, Linux, and Windows path separators, even though the Windows convention is to use the '\' separator. Where applicable, substitute the '\' separator for the '/' separator.
Table 1. Directory variable values
Directory variable Default installation root
app_server_root

IBM WebSphere Application Server installation directory

 AIX:

/usr/IBM/WebSphere/AppServer

Linux:

/opt/IBM/WebSphere/AppServer

Windows:

drive:\Program Files\IBM\WebSphere\AppServer

where drive is the system drive on which the file directory is stored. For example: C or D.
profile_root

WebSphere Application Server installation directory

 AIX:

/usr/IBM/WebSphere/AppServer/profiles/profile_name

Linux:

/opt/IBM/WebSphere/AppServer/profiles/profile_name

Windows:

drive:\Program Files\IBM\WebSphere\AppServer\profiles\profile_name

where profile_name is the name of the profile on which the application is installed or the profile name of the deployment manager. drive is the system drive on which the file directory is stored. For example: C or D.
ibm_http_server_root

IBM HTTP Server installation directory

 AIX:

/usr/IBM/HTTPServer

Linux:

/opt/IBM/HTTPServer

Windows:

drive:\Program Files\IBM\HTTPServer

where drive is the system drive on which the file directory is stored. For example: C or D.
connections_root

IBM Connections installation directory

 AIX or Linux:

/opt/IBM/Connections

Windows:

drive:\Program Files\IBM\Connections

where drive is the system drive on which the file directory is stored. For example: C or D.
local_data_directory_root

Local content stores

 AIX or Linux:

/opt/IBM/Connections/data/local

Windows:

drive:\Program Files\IBM\Connections\data\local

where drive is the system drive on which the directory is stored. For example: C or D.
shared_data_directory_root

Shared content stores

 AIX or Linux:

/opt/IBM/Connections/data/shared

Windows:

drive:\Program Files\IBM\Connections\data\shared\

where drive is the system drive on which the directory is stored. For example: C or D.
IM_root

IBM Installation Manager installation directory

 AIX:

/opt/IBM/InstallationManager

Linux:

/var/IBM/InstallationManager

Windows:

drive:\Program Files \IBM\Installation Manager

where drive is the system drive on which the file directory is stored. For example: C or D.
shared_resources_root

Shared resources directory

 AIX or Linux:

/opt/IBM/SSPShared

Windows:

drive:\Program Files\IBM\SSPShared

where drive is the system drive on which the file directory is stored. For example: C or D.
db2_root

DB2 database installation directory

 AIX or Linux:

/usr/IBM/db2/version

Linux:

/opt/ibm/db2/version

Windows:

drive:\Program Files\IBM\SQLLIB\version

where drive is the system drive on which the file directory is stored, for example: C or D, and version is the version of DB2 installed, for example: V9.5 or V9.7.
oracle_root

Oracle database installation directory

 AIX or Linux:

/home/oracle/oracle/product/version/db_1

Windows:

drive:\oracle\product\version\db_1

where version is the supported Oracle number and drive is the system drive on which the file directory is stored. For example: C or D.
sql_server_root

Microsoft SQL Server database installation directory

 Windows:

drive:\Program Files\Microsoft SQL Server

where drive is the system drive on which the file directory is stored, for example: C or D.
Cognos_BI_install_path

IBM Cognos BI Server installation directory

 AIX or Linux:

/opt/IBM/Cognos64

Windows:

drive:\Program Files\IBM\Cognos64

where drive is the system drive on which the file directory is stored. For example: C or D.
Note: You specify the installation directory in the cognos-setup.properties file during installation.
Cognos_Transformer_install_path

Cognos Transformer installation directory

 AIX or Linux:

/opt/IBM/Cognos

Windows:

drive:\Program Files\IBM\Cognos

where drive is the system drive on which the file directory is stored. For example: C or D.
Note: You can specify the installation directory in the cognos-setup.properties file during installation.

Deployment options

Install IBM Connections in one of three deployment topologies to achieve optimum scaling, load balancing, and failover.

A network deployment can consist of a single server that hosts all IBM Connections applications or two or more sets of clustered servers that share the workload. You must configure an additional system with WebSphere Application Server Network Deployment Manager.

IBM Cognos Business Intelligence is an optional component in the deployment. If used, Cognos must be federated to the same Deployment Manager as the IBM Connections servers. However, Cognos servers cannot be configured within an IBM Connections cluster.

A network deployment provides the administrator with a central management facility and it ensures that users have constant access to data. It balances the workload between servers, improves server performance, and facilitates the maintenance of performance when the number of users increases. The added reliability also requires a larger number of systems and the experienced administrative personnel who can manage them.

When you are installing IBM Connections, you have three deployment options:
Small deployment
Install all IBM Connections applications on a single node in a single cluster. This option is the simplest deployment but has limited flexibility and does not allow individual applications to be scaled up. All the applications run within a single Java Virtual Machine (JVM).
Note: The diagram depicts a topology with up to 8 servers. If you install the servers on shared systems, you do not need to deploy 8 separate systems.
Figure 1. Small deployment topology 

Small deployment topology




Medium deployment


Install a subset of applications in separate clusters. IBM Connections provides three predefined
cluster names shared among all of its applications. Use this option
to distribute applications according to your usage expectations. For
instance, you might anticipate higher loads for the Profiles application
and install it in its own cluster, while other applications could
be installed in a different cluster. This option allows you to maximize
the use of available hardware and system resources to suit your needs.
Figure 2. Medium deployment topology 

Medium deployment topology




Large deployment


Install each application in its own cluster. IBM Connections provides a predefined cluster
name for each application. This option provides the best performance
in terms of scalability and availability options but also requires
more system resources. In most cases, you should install the News
and Home page applications in the same cluster.
Figure 3. Large deployment
topology 

Large deployment topology








Notes: 
  • In a multi-node cluster, you must configure network share directories
as shared content stores. When using NFS, use NFS v4 because NFS v3
lacks advanced locking capability. When using Microsoft SMB Protocol for file-sharing,
use the UNC file-naming convention; for example: \\machine-name\share-name.
    • 

  • You can assign various combinations of applications to clusters
in many different ways, depending on your usage and expectations.
For more information, visit the IBM Connections
wiki to read articles about deployment.
    • 

  • The number of JVMs that you need for each cluster depends on the
user population and workload. For failover, you must have two JVMs
per application, or two nodes for each cluster, scaled horizontally.
Horizontal scaling refers to having multiple JVMs per application
with each JVM running on a WebSphere Application
Server instance. Vertical scaling refers to running multiple JVMs
for the same application on a single WebSphere Application Server instance.
Vertical scaling is not officially supported in IBM Connections. However, it is typically not
needed unless your server has several CPUs.
    • 

  • For performance and security reasons, consider using a proxy server
in your deployment. 
    • 

  • IBM Cognos Business Intelligence does not have
to be deployed before you install the Metrics application. Even if
you do not plan to deploy Cognos now,
you should install the Metrics application so that events are recorded
in the Metrics database for use when Cognos is
available to provide reports.
    • 

  • For added security when you are planning to run 3rd party OpenSocial
gadgets, such as those from iGoogle, you must configure locked domains.
 Locked domains are required to isolate these gadgets from access
to your intranet and SSO information.  The basic configuration of
locked domains is as follows:
    • A second top-level domain that is not in your SSO domain. For
example, if you organization's SSO domain is example.com, you will
require a distinct top level domain, such as example-modules.com. 
      • 

    • A wild card SSL certificate for this domain name.
      • 

    

    No additional server instances are required for the basic
configuration. See the Configuring locked domains topic
under the Installing > Post-installation
tasks > Optional post-installation tasks section for more details.
    

    • 











IBM Connections system
requirements


A variety of hardware and software
is required to run IBM Connections.


To view the hardware and software
requirements, go to the Detailed system requirements for IBM Connections web page.








IBM Connections support
statement


The statement proposes revisions to the
definition of "supported"
and "unsupported" with respect to the various products on which IBM Connections depends for proper
operation. 


To view the support statement,
go to the IBM Connections
support statements web page.








Worksheet for installing IBM Connections


Record your installation and configuration data.


Recording installation data
While installing
and configuring IBM Connections,
it can be difficult to remember all the user IDs, passwords, server
names, and other information that you need during and after installation.
Print out and use this worksheet to record that data. 


LDAP server details
Table 2. LDAP server details
LDAP data type
Details




LDAP server type and version 
For
example: Lotus Domino 8.5		
 



Primary host name 
For
example: domino_ldap.example.com		
 



Port 
For example:
389		
 



Bind distinguished name 
For
example: cn=lcadmin,ou=People,dc=example,dc=com		
 



Bind password
 



Certificate mapping
 



Certificate filter
 



Login attribute 
For
example: mail or uid		
 










WebSphere Application Server details
Table 3. WebSphere Application Server
details
WebSphere Application Server item
Details




WebSphere Application Server version 
For
example: V7.0 fix pack 21		
 



Installation location 
For
example: C:\IBM\WebSphere\AppServer		
 



Update installer location 
For
example: C:\IBM\WebSphere\UpdateInstaller		
 



Administrator ID 
For
example: wsadmin		
 



Administrator password
 



WebSphere Application Server URL 
For
example: http://was.example.com:9060/ibm/console		
 



WebSphere Application Server secure URL 
For
example: https://was.example.com:9043/ibm/console		
 



WebSphere Application Server host name
 



HTTP transport port
 



HTTPS transport port
 



SOAP connector port
 



Run application server as a
service? (True/False)
 










Database details
Table 4. Database server details
Database item
Details




Database type and version 
For
example: Oracle Database 10g Enterprise Edition Release 2 10.2.0.4		
 



Database instance or service
name
 



Database server host name 
For
example: database.example.com		
 



Port 
The default
values are: DB2=50000; Oracle=1433; MS SQL Server=1523.		
 



JDBC driver fully qualified
file path 
For example: C:\IBM\SQLLIB		
 



Database client name and version 
For
example: MS SQL Server Management Studio Express® v9.0.2 		
 



Database client user ID 
The
default is db2admin. 		
 



Database client user password
 



DB2 administrators group (Windows only) 
The default is DB2ADMNS.		
 



DB2 users group  (Windows only) 
The default is DB2USERS.		
 



Activities database server host
name
 



Activities database server port
number
 



Activities database name. 
The
default name is OPNACT.		
 



Activities database application
user ID
 



Activities database application
user password
 



Blogs database server host name
 



Blogs database server port number
 



Blogs database name. 
The
default name is BLOGS.		
 



Blogs database application user
ID
 



Blogs database application user
password
 



Cognos database server host
name
 



Cognos database server port
number
 



Cognos database name. 
The
default name is COGNOS.		
 



Cognos database application
user ID
 



Cognos database application
user password
 



Communities database server
host name
 



Communities database server
port number
 



Communities database name 
The
default name is SNCOMM.		
 



Communities database application
user ID
 



Communities database application
user password
 



Dogear database server host
name
 



Dogear database server port
number
 



Dogear database name. 
The
default name is DOGEAR.		
 



Dogear database application
user ID
 



Dogear database application
user password
 



Files database server host name
 



Files database server port number
 



Files database name. 
The
default name is FILES.		
 



Files database application user
ID
 



Files database application user
password
 



Forums database server host
name
 



Forums database server port
number
 



Forums database name. 
The
default name is FORUM.		
 



Forums database application
user ID
 



Forums database application
user password
 



Home page database server host
name
 



Home page database server port
number
 



Home page database name. 
The
default name is HOMEPAGE.		
 



Home page database application
user ID
 



Home page database application
user password
 



Metrics database server host
name
 



Metrics database server port
number
 



Metrics database name. 
The
default name is METRICS.		
 



Metrics database application
user ID
 



Metrics database application
user password
 



Mobile database server host
name
 



Mobile database server port
number
 



Mobile database name. 
The
default name is MOBILE.		
 



Mobile database application
user ID
 



Mobile database application
user password
 



Profiles database server host
name
 



Profiles database server port
number
 



Profiles database name. 
The
default name is PEOPLEDB.		
 



Profiles database application
user ID
 



Profiles database application
user password
 



Wikis database server host name
 



Wikis database server port number
 



Wikis database name. 
The
default name is WIKIS.		
 



Wikis database application user
ID
 



Wikis database application user
password
 










Tivoli Directory
Integrator details
Table 5. Tivoli Directory Integrator details
Tivoli Directory Integrator item
Details




Tivoli Directory Integrator installation location 
For
example: C:\IBM\TDI\		
 



Tivoli Directory Integrator version. 
For example:
7.1 fix pack 2.		
 



Solutions Directory path 
For
example: C:\IBM\TDISOL\TDI		
 










LDAP-Profiles mapping details
Note: This table
is derived from the map_dbrepos_from_source.properties file.


Table 6. LDAP-Profiles mapping details
Profiles database attribute 
LDAP attribute (example)
Profiles database column 




alternateLastname
null
PROF_ALTERNATE_LAST_NAME



bldgId
null
PROF_BUILDING_IDENTIFIER 



blogUrl
null
PROF_BLOG_URL



calendarUrl
null
PROF_CALENDAR_URL



countryCode 
c
PROF_ISO_COUNTRY_CODE



courtesyTitle
null
PROF_COURTESY_TITLE



deptNumber
null
PROF_DEPARTMENT_NUMBER 



description
description
PROF_DESCRIPTION



displayName
cn
PROF_DISPLAY_NAME 



distinguishedName 
$dn
PROF_SOURCE_UID 



email 
mail
PROF_MAIL



employeeNumber
employeenumber
PROF_EMPLOYEE_NUMBER



employeeTypeCode
employeetype
PROF_EMPLOYEE_TYPE



experience
null
PROF_EXPERIENCE



faxNumber
facsimiletelephonenumber
PROF_FAX_TELEPHONE_NUMBER



floor
null
PROF_FLOOR



freeBusyUrl
null
PROF_FREEBUSY_URL



givenName
givenName
PROF_GIVEN_NAME



givenNames
givenName
 



groupwareEmail
null
PROF_GROUPWARE_EMAIL



guid 
(Javascript function: {func_map_from_GUID})
PROF_GUID 



ipTelephoneNumber
null
PROF_IP_TELEPHONE_NUMBER



isManager
null
PROF_IS_MANAGER



jobResp
null
PROF_JOBRESPONSIBILITIES



loginId
employeenumber
PROF_LOGIN and PROF_LOGIN_LOWER



logins
mail
PROF_LOGIN



managerUid
$manager_uid 
Note: This attribute represents
a lookup of the UID of a manager using DN in the manager field.


PROF_MANAGER_UID



mobileNumber
mobile
PROF_MOBILE



nativeFirstName
null
PROF_NATIVE_FIRST_NAME



nativeLastName
null
PROF_NATIVE_LAST_NAME



officeName
physicaldeliveryofficename
PROF_PHYSICAL_DELIVERY_OFFICE



orgId
ou
PROF_ORGANIZATION_IDENTIFIER 



pagerId
null
PROF_PAGER_ID



pagerNumber
null
PROF_PAGER



pagerServiceProvider
null
PROF_PAGER_SERVICE_PROVIDER



pagerType
null
PROF_PAGER_TYPE



preferredFirstName
null
PROF_PREFERRED_FIRST_NAME



preferredLanguage
preferredlanguage
PROF_PREFERRED_LANGUAGE



preferredLastName
null
PROF_PROF_PREFERRED_LAST_NAME



profileType
null
PROF_TYPE



secretaryUid
$secretaryUid
Note: This attribute represents
a lookup of the UID of a secretary using DN in the secretary field.


PROF_SECRETARY_UID



shift
null
PROF_SHIFT



surname
sn
PROF_SURNAME



surnames
sn
PROF_SURNAME



telephoneNumber
telephonenumber
PROF_TELEPHONE_NUMBER



timezone
null
PROF_TIMEZONE



title
null
PROF_TITLE



uid 
(Javascript function - {func_map_to_db_UID})
PROF_UID 



workLocationCode
postallocation
PROF_WORK_LOCATION










IBM Connections
details
Table 7. IBM Connections details
IBM Connections
item
Details




IBM Connections installation location 
For example:
C:\IBM\Connections		
 



Response file directory path. 
For
example: C:\IBM\Connections\InstallResponse.txt		
 



DNS host name 
For
example: connections.example.com		
 



Choose: DNS MX Records or Java Mail Session?
 



DNS MX Records only: Local mail
domain 
For example: example.com		
 



Java Mail Session only: DNS server name or SMTP relay host 
For
example: dns.example.com; relayhost.example.com		
 



Domain name for Reply-to email
address
 



Suffix or prefix for Reply-to
email address
 



Server that receives Reply-to
emails
 



User name and password for that
server
 



URL and ports for admin and
user access
Note: You can look up the URLs for each application in
the text files that the installation wizard generates. These files
are located under the connections_root directory. 


 



Activities server name
 



Activities cluster member name
 



Activities URL 
For
example: http://www.example.com:9080/activities		
 



Activities secure URL 
For
example: https://www.example.com:9446/activities		
 



Activities statistics files
directory path
 



Activities content files directory
path
 



Blogs server name
 



Blogs cluster member name
 



Blogs URL 
For example:
http://www.example.com:9080/blogs		
 



Blogs secure URL 
For
example: https://www.example.com:9446/blogs		
 



Blogs upload files directory
path
 



Bookmarks server name
 



Bookmarks cluster member name
 



Bookmarks URL 
For
example: http://www.example.com:9080/dogear		
 



Bookmarks secure URL 
For
example: https://www.example.com:9446/dogear		
 



Bookmarks favicon files directory
path
 



Communities server name
 



Communities cluster member name
 



Communities URL 
For
example: http://www.example.com:9080/communities		
 



Communities secure URL 
For
example: https://www.example.com:9446/communities		
 



Communities statistics files
directory path
 



Communities discussion forum
content directory path
 



Files server name
 



Files cluster member name
 



Files URL 
For example:
http://www.example.com:9080/files		
 



Files secure URL 
For
example: https://www.example.com:9446/files		
 



Files content store directory
path 
 



Forums server name
 



Forums cluster member name
 



Forums URL 
For
example: http://www.example.com:9080/forums		
 



Forums secure URL 
For
example: https://www.example.com:9446/forums		
 



Forums content store directory
path 
 



Home page server name
 



Home page  cluster member name
 



Home page  URL 
For
example: http://www.example.com:9080/homepage 		
 



Home page  secure URL 
For
example: https://www.example.com:9446/homepage		
 



Home page  content store directory
path 
 



Metrics server name
 



Metrics cluster member name
 



Moderation server name
 



Moderation cluster member name
 



Moderation URL 
For
example: http://www.example.com:9080/moderation		
 



Moderation secure URL 
For
example: https://www.example.com:9446/moderation		
 



Profiles server name
 



Profiles cluster member name
 



Profiles URL 
For
example: http://www.example.com:9080/profiles		
 



Profiles secure URL 
For
example: https://www.example.com:9446/profiles		
 



Profiles statistics files directory
path 
 



Profiles cache directory path 
 



Search server name
 



Search cluster member name
 



Search dictionary directory
path 
 



Search index directory path 
 



Wikis server name
 



Wikis cluster member name
 



Wikis URL 
For example:
http://www.example.com:9080/wikis		
 



Wikis secure URL 
For
example: https://www.example.com:9446/wikis		
 



Wikis content directory path
 










IBM HTTP Server
Table 8. IBM HTTP Server details
IBM HTTP
Server item
Details




IBM HTTP Server installation location 
For example:
C:\IBM\HTTPServer\		
 



IBM HTTP Server version 
For example: V7.0 fix pack
21.		
 



IBM HTTP Server httpd.conf file directory path 
For
example: C:\IBM\HTTPServer\conf\		
 



web server definition name 
For
example: webserver1		
 



web server plugin-cfg.xml file
directory path 
For example: C:\IBM\HTTPServer\Plugins\config\webserver1\		
 



IBM HTTP Server host name
 



IBM HTTP Server fully qualified host name
 



IBM HTTP Server IP address
 



IBM HTTP Server communication port 
For example:
80		
 



IBM HTTP Server administration port 
For example:
8008		
 



Run IBM HTTP Server as a service? (Y/N)
 



Run IBM HTTP administration as a service? (Y/N)
 



IBM HTTP Server administrator ID
 



IBM HTTP Server administrator password
 










Cognos BI Server and Transformer
Table 9. Cognos BI Server and Transformer details
Cognos BI Server and Transformer item
Details




Cognos BI Server and Transformer
Refer to the cognos-setup.properties file. 














IBM Connections release
notes


The release notes for IBM Connections
4 explain compatibility, installation, and other getting-started issues.


Contents




Description
IBM Connections
4 introduces metrics for Communities. Metrics data is available for
the entire product as well as for individual communities. Metrics
employs the analytic capabilities of the IBM Cognos® Business Intelligence
server, which is provided as part of the IBM Connections installation
to support the collection of metrics data.




Announcement
The IBM Connections 4 announcement is available at
www.ibm.com/common/ssi/index.wss. See the announcement for the following
information:
  • Detailed product description, including a description of new function
    • 

  • Product-positioning statement
    • 

  • Packaging and ordering details
    • 

  • International compatibility information
    • 







System requirements
For
information about hardware and software compatibility, see the IBM
Connections system requirements topic. 




Installing IBM Connections
4
For
step-by-step installation instructions, refer to the Installing section
of the product documentation.
Note: Once mandatory tasks are completed,
go to fix central to obtain the latest iFixes and apply them using
"Updating IBM Connections 4.0" to ensure the
deployment will have the latest set of Software Fixes. 






Known problems
Known problems are documented
in the form of individual technotes in the Support Portal at http://www-947.ibm.com/support/entry/portal/Overview/Software/Lotus/Lotus_Connections.
As problems are discovered and resolved, the IBM Support team updates the knowledge base.
By searching the knowledge base, you can quickly find workarounds
or solutions to problems.


 The following links launch customized
queries of the live Support knowledge base: 











Installing


To install IBM Connections,
you need to follow a detailed series of procedures.


What's new


Find out what's new and what's been updated.


IBM Connections
4.0
  • The installation wizard is based on IBM Installation Manager 1.4.4.
    • 

  • You can install and configure IBM Cognos Business
Intelligence, obtained separately,  by using the scripts, models,
and specifications that are included with IBM Connections. 
    • 

  • Console Mode is available. Use this character-based interface
to install, modify, or uninstall the product when you do not have
access to the graphical interface.
    • 

  • Silent installation has been extended so that you can install
both IBM Connections and IBM Installation Manager in silent
mode.
    • 

  • The initial configuration of administrators for Home page and
Blogs is now handled automatically during installation. However, to
configure widgets, you still need to assign a Home page administrator.
    • 







Migrating to this release
  • After migration to IBM Connections
4.0, you can reuse content stores from 3.0.1.
    • 

  • In Profiles, the data model for profile-type definitions has been
moved into a dedicated profiles-types.xml file
and the rules for presentation of a profile have been moved into a
set of FreeMarker template files. For details, see Post-migration steps for
profile types and profile policies.
    • 

  • During the database migration process, data from the Profiles
database is copied to the Home page database. 
    • 

  • The migration tool no longer migrates content stores, which must
be manually migrated.
    • 









The installation process


Review the steps that are required to install IBM Connections.


About this task
Installing IBM Connections
in a production environment involves several procedures to deploy
the different components of the environment.


Procedure
  1. Review the software and hardware requirements for the systems
that will host IBM Connections.  For more information, see the IBM Connections system requirements topic.
    2. 

  2. Install the required software, choosing a supported product
in each case: 
    • WebSphere Application
Server
      • 

    • LDAP directory
      • 

    • Database server
      • 

    • Tivoli Directory Integrator
      • 

    • IBM Cognos (optional)
      • 

    

    3. 

  3. If you plan to use mail notification, ensure that you have
the SMTP and DNS details of your mail infrastructure available at
installation time.
    4. 

  4. Prepare the LDAP directory, install WebSphere Application Server, and create
databases for the IBM Connections
applications that you plan to use. For more information,
see the Pre-installation tasks topic.
    5. 

  5. Install IBM Connections.
For more information, see the Installing IBM Connections topic.
    6. 

  6. Complete the post-installation tasks that apply to your
configuration. For example, map the installed applications to IBM HTTP Server. For more information,
see the Post-installation tasks topic
    7. 





Accessibility
applications for installing IBM Connections


Learn about the accessibility applications for installing IBM Connections.


Using the
wizards
IBM Connections wizards provide
non-graphical console modes for installation and other tasks. You
can use accessibility applications in the following wizards:
  • IBM Connections installation
    
    • 

  • Database creation
    • 

  • Profiles population 
    • 

  • Connector
installation 
    • 

  • Update installation
    • 



See the related
topics for more information about accessing
the wizards.




IBM and accessibility
Go
to the IBM Human Ability and Accessibility
Center for more information about the commitment that IBM has to accessibility.










Pre-installation tasks


Complete the following tasks before installing IBM Connections.


Important: 
If you are migrating from IBM Connections version 3.0.1, do not complete
the tasks for creating databases or populating the Profiles database.
The migration process handles those tasks automatically.






Preparing to configure the LDAP directory


Determine which Lightweight Directory Access Protocol (LDAP)
attributes you want to use as the identifiers for IBM Connections users.


Before you begin
Ensure that you have installed a supported LDAP directory.
For more information about supported LDAP directories, see the IBM Connections detailed system
requirements topic.
To ensure that the Profiles population
wizard can return the maximum number of records from your LDAP directory,
set the Size Limit parameter in your LDAP configuration to match the
number of users in the directory. For example, if your directory has
100,000 users, set this parameter to 100000. For more information,
see the documentation for your LDAP directory. If you cannot set the
Size Limit parameter, you could run the wizard multiple times. Alternatively,
you could write a JavaScript function to split the original LDAP search filter, then run the collect_dns_iterate.bat file, and finally run the populate_from_dns_files.bat file.
Note: For information
about a limitation in environments with a Turkish locale, see the Base entry comparison for Turkish locale technote.






About this task
To prepare to configure your LDAP directory with IBM WebSphere Application Server, complete
the following steps:




Procedure
  1. Identify LDAP attributes to use for the following roles.
If no corresponding attribute exists, create one. You can use an attribute
for multiple purposes. For example, you can use the mail attribute
to perform the login and messaging tasks. 
    Display name
    

    The cn LDAP attribute is used to display a person's name in the
product user interface. Ensure that the value you use in the cn attribute
is suitable for use as a display name.
    

    Log in
    

    Determine which attribute or attributes you want people to be
able to use to log in to IBM Connections. For example: uid. See Choosing log in values for important considerations when deciding which attributes to use.
    Note: The login name must be unique in the LDAP directory.
    

    

    Messaging
    

    (Optional.) Determine which attribute to use to define the email
address of a person. The email address must be unique in the LDAP
directory. If a person does not have an email address and does not
have an LDAP attribute that represents the email address, that person
cannot receive notifications.
    

    Global unique identifier (GUID)
    

    Determine which attribute to use as the unique identifier of each
person and group in the organization. This value must be unique across
the organization. For more information, see the Specifying the
global ID attribute for users and groups topic.
    

    

    2. 

  2. Collect the following information about your LDAP directory
before configuring it for WebSphere Application Server: 
    • Directory Type. Identifies and selects a directory service from
the available vendors and versions.
      • 

    • Primary host name
      • 

    • Port
      • 

    • Bind distinguished name
      • 

    • Bind password
      • 

    • Certificate mapping
      • 

    • Certificate filter, if applicable.
      • 

    • LDAP entity types or classes. Identifies and selects LDAP object
classes.  For example, select the LDAP inetOrgPerson object class
for the Person Account entity, or the LDAP groupOfUniqueNames object
class for the Group entity.
      • 

    • Search base. Identifies and selects the distinguished name (DN)
of the LDAP subtree as the search scope.  For example, select o=ibm.com
to allow all directory objects underneath this subtree node to be
searched. For example: Group, OrgContainer, PersonAccount, or inetOrgPerson.
      • 

    

    3. 







Creating the Cognos administrator
account


Create a new user, or select an existing user in the LDAP
directory to serve as the administrator of the IBM Cognos BI
Server component (you will add the administrator credentials to a
configuration script when you deploy Cognos Business
Intelligence).


About this task
Attention: The Cognos administrator
account must reside in the same LDAP directory used by IBM Connections.


If you will use an
existing LDAP account, take note of the user name and password. For
example, if your organization already has a Cognos deployment, you might choose to use
the same administrator account with Connections.


If an acceptable
account does not exist already, create it now; again, note the credentials
for use later.


For
more information on using an LDAP directory with Cognos, see Configuring IBM Cognos Components to Use an Authentication
Provider in the Cognos information
center.








Installing IBM WebSphere Application Server


Install IBM WebSphere Application Server
.


Before you begin
WebSphere Application
Server Network Deployment is provided with IBM Connections.


To establish an environment
with one Deployment Manager and one or more managed nodes, use the
following table to determine the installation option that you should
choose. The IBM Connections
installation wizard creates server instances that require each node
to have an application server. Choose one of these options when installing WebSphere Application Server
to ensure that each node has an application server.


Table 10. WebSphere Application
Server options
IBM Connections deployment




Deployment Manager and one node on the same
system



Deployment Manager and nodes on separate
systems
Note: You can deploy one node on the same system as the DM
but you must use separate systems for all other nodes in a cluster.














About this task
To install and configure WebSphere Application Server, complete the following tasks:


Procedure
  1. Install WebSphere Application Server Network Deployment. For more information,
go to the WebSphere Application Server 7.0 information center.
    Note: Enable security
when the installation wizard requests it. The administrative user
ID that you create must be unique and must not exist in the LDAP repository
that you plan to federate.
    

    2. 

  2. Apply the available fix packs. See the IBM Connections system requirements topic for details.
    3. 

  3. Configure WebSphere Application Server to communicate with the LDAP directory. For more
information, see the Setting up federated repositories topic. 
    Note: 
    • Perform this step on the Deployment Manager Integrated Solutions
Console.
      • 

    • Configure the LDAP for Cognos separately. For more information,
see the Configuring support for LDAP authentication for Cognos
Business Intelligence topic.
      

      • 

    

    

    4. 

  4. Configure Application
Security after you have completely installed WebSphere Application Server Network Deployment.
For an overview of application server security, go to the Administering security topic in the WebSphere Application Server
information center. 
    Note: Perform this step on the Deployment
Manager Integrated Solutions Console.
    

    5. 

  5. Optional: Add further nodes, if required, to
the cell. Complete the following steps for each node that you want
to add to the cell:
    1. Open a command prompt and change to the app_server_root/profiles/profile/bin directory, where profile is the name of the WebSphere Application Server
installation on the node. 
      2. 

    2. Enter the following command:  
      addNode.sh|bat DM_host DM_SoapPort -username AdminUserId -password AdminPwd 
      

      where:
      • DM_host is the host name of the Deployment
Manager
        • 

      • DM_SoapPort is the SOAP port number of the
Deployment Manager
        • 

      • AdminUserId is the user ID for the Deployment
Manager
        • 

      • AdminPwd is the password for the Deployment
Manager
        • 

      

      

      3. 

    3. Repeat this step for each additional node that your
want to add to the cell.
      4. 

    4. Synchronize all the nodes.
      5. 

    
 
    Note: You can also add nodes after you have deployed IBM Connections. For more information,
see the Adding a node to a cluster topic. 
    

    6. 







Setting up federated repositories


Use federated repositories with IBM WebSphere Application Server to manage and secure user and group identities.


Before you begin
Ensure that you have completed the steps described in the Preparing to configure the LDAP directory topic. 


You
can configure the user directory for IBM Connections to be populated with users from more than one
LDAP directory. 


Important: Ensure that you meet the
following guidelines for entity-object class mapping:
  • If you are using IBM Tivoli Directory Server, decide
whether your deployment will rely on the LDAP groupOfNames or groupOfUniqueNames
object class for group entities. WebSphere Application Server uses groupOfNames by default. In
most cases, you need to delete this default mapping and create a new
mapping for group entities using the LDAP groupOfUniqueNames object
class.
    • 

  • If you are using the groupOfUniqueNames object class for group
entities, use the uniqueMember attribute for the group member attribute.
    • 

  • If you are using the groupOfNames object class group entities,
use the member attribute for the group member attribute. 
    • 





Configure the LDAP for Cognos separately. For more information,
see the Configuring support for LDAP authentication for Cognos
Business Intelligence topic.




About this task
To set up federated repositories in WebSphere Application Server, complete
the following steps:


Procedure
  1. Start WebSphere Application Server and log in to the Integrated Solutions Console
on the Deployment Manager by going to the following web address: http://websphere_Application_Server_host_name:9060/ibm/console
    2. 

  2. Click Log in and enter the credentials
of the administrative user ID that you specified during the installation
of WebSphere Application
Server. 
    3. 

  3. Click Security > Global Security.
    4. 

  4. Select Federated Repositories from the Available
realm definitions field, and then click Configure.
    5. 

  5. Click Add Base entry to Realm, and
then, on the Repository reference page, click Add Repository. 
    6. 

  6. On the New page, type a repository
identifier, such as myFavoriteRepository into
the Repository identifier field. 
    7. 

  7. Specify the LDAP directory that you are using in the Directory type field. 
    The following table
identifies the LDAP directories that WebSphere Application Server V7 and IBM Connections 4.0 support. 
    Table 11. Options to specify a supported LDAP directory
    Directory type option
LDAP directory supported by IBM Connections

    
    

    IBM Tivoli Directory Server
IBM Tivoli Directory Server 6.1,
6.2, 6.3

    

    z/OS® Integrated
Security Services LDAP Server
 

    

    IBM Lotus Domino
IBM Lotus Domino 8.0 or later, 8.5 or later

    

    Novell Directory Services
eDirectory 8.8

    

    Sun Java System Directory Server
Sun Java System Directory Server 7

    

    Microsoft Windows Active Directory
Microsoft Active Directory 2008

    

    Microsoft Active Directory Application Mode
Microsoft Active Directory Application Mode
    Note: Referred to as Active Directory
Lightweight Directory Services (AD LDS) in Windows Server 2008.
    
    		

    
    

    

    

    

    8. 

  8. Type the host name of the primary LDAP directory server
in the Primary host name field. The host name
is either an IP address or a domain name service (DNS) name.
    9. 

  9. If your directory does not allow LDAP attributes to be
searched anonymously, provide values for the Bind distinguished
name and Bind password fields.
For example, the Domino LDAP
directory does not allow anonymous access, so if you are using a Domino directory, you must specify
the user name and password with administrative level access in these
fields. 
    10. 

  10. Specify the login attribute or attributes that you want
to use for authentication in the Login properties field. Separate multiple attributes with a semicolon. For example: uid;mail. See the Choosing login values topic for information about the types of login values that can be
used.
    Note: If you are using Active Directory and you use an email
address as the login, specify mail as the value
for this property. If you use the samAccountName attribute as the
login, specify uid as the value for this property.
    

    

    11. 

  11. Click Apply and then click Save.
    12. 

  12. On the Repository reference page,
the following fields represent the LDAP attribute type and value pairs
for the base element in the realm and the LDAP repository. (The type
and value pair are separated by an equal sign (=), for example: o=example.
These can be the same value when a single LDAP repository is configured
for the realm or can be different in a multiple LDAP repository configuration.)  
    Distinguished name of a base entry that uniquely identifies
this set of entries in the realm
    

    Identifies entries in the realm. For example, on a Domino LDAP server: cn=john doe, o=example.
    

    Distinguished name of a base entry in this repository
    

    Identifies entries in the LDAP directory. For example, cn=john
doe, o=example. 
    This value defines the location in the LDAP directory information
tree from which the LDAP search begins. The entries beneath it in
the tree can also be accessed by the LDAP search. In other words,
the search base entry is the top node of a subtree which consists
of many possible entries ben it. For example, the search base entry
could be o=example and one of the entries underneath this search base
could be cn=john doe, o=example. 
    Note: If you have defined
flat groups in the Domino directory, do not enter a value in this field. Flat groups are group
names such as SalesGroup, as opposed to: cn=SalesGroup,ou=Groups.
If you configure a search base in this Step, you will not be able
to access the groups. If you plan to set up single sign-on, see the Enabling single sign-on for Domino topic.
    

    

    

    

    13. 

  13. Click Apply and then click Save.
    14. 

  14. Click OK to return the Federated Repositories page.
    15. 

  15. In the Repository Identifier column, click the link for
the repository or repositories that you just added.
    16. 

  16. In the Additional Properties area, click the LDAP entity types link.
    17. 

  17. Click
the Group entity type and modify the object
classes mapping. You can also edit the Search bases and Search filters fields, if necessary.
Enter LDAP parameters that are suitable for your LDAP directory. 
    Note: You can accept the default object classes value for Group.
However, if you are using Domino, change the value to dominoGroup.
    

    18. 

  18. Click Apply and then click Save.
    19. 

  19. Click the PersonAccount entity type
and modify the default object classes mapping. You can also edit the Search bases and Search filters fields, if necessary. Enter LDAP parameters that are suitable for
your LDAP directory. Click Apply, and then
click Save to save this setting. 
    Note: If you are using a Domino LDAP, replace the default mapping with dominoPerson and dominoGroup
object classes for person account and group entities.
    

    20. 

  20. In the navigation links at the beginning of the page, click
the name of the repository that you have just modified to return to
the Repository page. 
    21. 

  21. Optional: If your applications rely on group
membership from LDAP, complete the following steps:
    1. Click the Group attribute definition link in the Additional Properties area, and then click the Member attributes link.
      2. 

    2. Click New to create a group attribute
definition.
      3. 

    3. Enter group membership values in the Name
of member attribute and Object class fields.
      4. 

    4.  Click Apply and then click Save.
      5. 

    
 
    Notes: 
    • If you have already accepted the default groupOfNames value for
Group, then you can also accept the default value for Member.
      • 

    • If you changed objectclass for Group to dominoGroup earlier, you must add dominoGroup
to the definition of Member.
      • 

    • If you do not configure the group membership attribute, then the
group member attribute is used when you search group membership. If
you need to enable searches of nested group membership, then you must
configure the group membership attribute.
      • 

    • Consider an example of group membership attribute for using Activities:
the Member attribute type is used by the groupOfNames object class,
and the uniqueMember attribute type is used by groupOfUniqueNames.
      • 

    

    

    22. 

  22. If you want to support more than one LDAP directory, repeat
steps 8-22 for each additional LDAP directory. 
    23. 

  23. Set the new repository as the current respository:
    1. Click Global Security in the
navigation links at the beginning of the page.
      2. 

    2. Select Federated Repositories from the Available realm definitions field,
and then click Set as current.
      3. 


      4. 

    

    24. 

  24.  Enable login security on WebSphere Application Server:
    1. Select the Administrative Security and Application Security check boxes. For
better performance, clear the Java 2 security check box.
      2. 

    2.  Click Apply and then click Save.
      3. 

    
 The administrative user name and password are now required
because you set up security on WebSphere Application Server.
    25. 

  25. Create an administrator for WebSphere Application Server:
    1. Click Users and Groups > Administrative user roles and
then click Add.
      2. 

    2. Select Adminstrator from the
Roles box and then search for a user.
      3. 

    3. Select the target user and click the right arrow to
move the user name to the Mapped to role box.
      4. 

    4. Click OK and then click Save.
      5. 

    5. Log out of the DM.
      6. 

    6. Restart the DM and the nodes.
      7. 

    7. Log in to the DM using the new administrator credentials.
      8. 

    
 
    Notes: 
    • Ensure that this user ID does not have spaces in the name.
      • 

    

    

    26. 

  26. Set a primary administrative user:
    1. Click Security > Global Security.
      2. 

    2. Select Federated Repositories from the Available realm definitions field,
and then click Configure.
      3. 

    3. Enter the user name that you mapped in the previous
step in the Primary administrative user name box.
      4. 

    4.  Click Apply and then click Save.
      5. 

    

    27. 

  27. Log out of the DM and restart WebSphere Application Server. 
    28. 

  28. When WebSphere Application Server is running again, log in to the Integrated Solutions
Console using the primary administrative user name and password.  
    29. 

  29. Optional: Test the new configuration by adding
some LDAP users to the WebSphere Application Server with administrative roles.
    30. 

  30. Optional: If you are using SSL for LDAP, add
a signer certificate to your trust store by completing the following
steps:
    1. From the WebSphere Application Server Integrated Solutions Console, select SSL Certificate and key management > Key Stores and certificates > CellDefaultTrustStore > Signer Certificates > Retrieve from
port.
      2. 

    2. Type the DNS name of the LDAP directory in the Host  field.
      3. 

    3. Type the secure LDAP port in the Port field (typically 636).
      4. 

    4. Type an alias name, such as LDAPSSLCertificate, in the Alias field.
      5. 

    5.  Click Apply and then click Save.
      6. 

    

    31. 

  31. Optional: If you plan to enable single sign-on
(SSO) for IBM Connections, prepare
the WebSphere Application
Server environment by completing the following steps:
    1. From the WebSphere Application Server Integrated Solutions Console, select Security > Global security > web and SIP security > Single sign-on
(SSO).
      2. 

    2. Select Enabled, Interoperability
Mode, and web inbound security attribute propagation.
      3. 

    3. Return to the Global security page and click web and SIP security > General settings.
      4. 

    4. Select Use available authentication data
when an unprotected URI is accessed.
      5. 

    5.  Click Apply and then click Save.
      6. 

    
 
    Note: For more information about SSO security, see the Configuring single sign-on topic. For more information about
setting the SSO domain name, see the Setting the single sign-on
domain name topic.
    

    32. 

  32. Optional: Verify that users in the LDAP directory
have been successfully added to the repository:
    1. From the WebSphere Application Server Integrated Solutions Console, select Users and Groups > Manage Users.
      2. 

    2. In the Search by field, enter
a user name that you know to be in the LDAP directory and click Search. If the search succeeds, you have partial verification
that the repository is configured correctly. However, this check cannot
check for the groups that a user belongs to.
      3. 

    

    33. 



Results
You have configured WebSphere Application Server to use a federated repository.




Choosing login values


Determine which LDAP attribute or attributes you want to
use to log in to IBM Connections.


The following scenarios are supported:
Single LDAP attribute with a single value


For example: uid=jsmith.


Multiple LDAP attributes, each with a single value


To specify multiple attributes, separate them with a semicolon
when you enter them in the Login properties field (while adding the repository to IBM WebSphere Application
Server). For example, where uid=jsmith and mail=jsmith@example.com,
you would enter: uid; mail.


Single LDAP attribute with multiple values


For example, mail is the login attribute and it accepts two different
email addresses: an intranet address and an extranet address. For
example: mail=jsmith@myCompany.com or mail=jsmith@example.com. 


Multiple LDAP attributes, each with multiple values


For example: uid=jsmith or uid=john_smith and mail=jsmith@example.com
or mail=john_smith@example.com or mail=jsmith@MyCompany.com.


Multiple LDAP directories


For example: One LDAP directory uses uid as the login attribute
and the other uses mail. You must repeat the steps in Setting
up federated repositories for each LDAP directory.






Multi-valued  attributes
You can map multiple
values to common attributes such as uid or mail.


If, for example,
you mapped the following attributes for a user called Sample User,
all three values for the user are populated in the PROFILE_LOGIN table
in the Profiles database:
  • mail=suser@example.com
    • 

  • mail=sample_user@example.com
    • 

  • mail=user_sample@example.com
    • 





A similar example for the uid property would have the
following attributes:
  • uid=suser
    • 

  • uid=sampleuser
    • 

  • uid=user_sample
    • 





By default, the population wizard only allows you to choose
one attribute for logins, so you can't select mail and uid. You can,
however, write a custom function to union multiple attributes.




Custom attributes
The Profiles population
wizard populates uid and mail during the population process but maps
the loginID attribute to null. You can specify a custom attribute
if your directory uses a unique login attribute other than, for example,
uid, mail, or cn. The login value can be based on any attribute that
you have defined in your repository. You can specify that attribute
by setting loginID=attribute when you populate the Profiles database. 


The following sample extract from the profiles-config.xml file shows the standard login attributes:		 


<loginAttributes> 
<loginAttribute>uid</loginAttribute> 
<loginAttribute>email</loginAttribute> 
<loginAttribute>loginId</loginAttribute> 
</loginAttributes> 




The value for the loginID
attribute is stored in the Prof_Login column of the Employee table
in the Profiles database. For more information, see the Mapping
fields manually topic.




Using Profiles or LDAP as the repository
The default login attributes that are defined in the profiles-config.xml file are uid, email, or loginID


If you change the default IBM Connections configuration to
use the LDAP directory as the user repository, WebSphere Application Server maps uid as
the login default.     








Specifying the global ID attribute for users and groups


Determine which attribute to use as the unique identifier
of each person and group in the organization. This identifier must
be unique across the organization. 


By default, WebSphere Application Server reserves the following attributes as unique identifiers
for the following LDAP directory servers: 
  • IBM Tivoli Directory Server:
    ibm-entryUUID
    

    • 

  • Microsoft Active Directory:
    objectGUID
    

    If you are using Active Directory,
remember that the samAccountName attribute has a 20-character limit;
other IDs used by IBM Connections
have a 256-character limit.
    

    • 

  • IBM Domino Enterprise Server:
    dominoUNID
    

    Note: If the bind ID for the Domino LDAP does not have sufficient manager access to the Domino directory, the Virtual
Member Manager (VMM) does not return the correct attribute type for
the Domino schema query;
DN is returned as the VMM ID. To override VMM's default ID setting,
add the following line to the <config:attributeConfiguration> section of the wimconfig.xml file:
    <config:externalIdAttributes  
    

    name="dominoUNID"/>
    

    

    • 

  • Sun Java System Directory
Server:
    nsuniqueid
    

    • 

  • eNovell Directory Server:
    GUID
    

    • 

  • Custom ID:
    If your organization already uses a unique identifier
for each user and group, you can configure IBM Connections to use that identifier. For more
information, see the Specifying a custom ID attribute for users
or groups topic.
    

    • 


The wimconfig.xml file is stored in the
following location:
AIX


/usr/IBM/WebSphere/AppServer/profiles/<profile_name>/config/cells/<cell_name>/wim/config


Linux


/opt/IBM/WebSphere/AppServer/profiles/<profile_name>/config/cells/<cell_name>/wim/config


Microsoft Windows


<drive>:\IBM\WebSphere\AppServer\profiles\<profile_name>\config\cells\<cell_name>\wim\config






Note: IBM recommends that you
do not allow the GUID of a user to change. If you change the GUID,
the user will not have access to their data unless you re-synchronize
the LDAP and Profiles database with the new GUID. When you change
the GUID and run the sync_all_dns batch file,
the user's GUID is changed only in the Profiles database, and not
in the databases for other IBM Connections applications. Similarly, if you delete users and re-add
them to the LDAP, the GUID value that the LDAP generates is now different
than the value that is stored in the other application databases.
To resolve this discrepancy, use the SWAP command. For more information,
see the Managing user data using Profiles administrative commands topic.
 To allow deletes and adds, or migration across various
LDAP servers (for example, from staging to production), use an LDAP
attribute that is fixed across various directories or when entries
are recreated.








Specifying a custom ID attribute for users or groups


Specify custom global unique ID attributes to identify
users and groups in the LDAP directory.


Before you begin
This is an optional
task.


By default, IBM Connections
looks for LDAP attributes to use as the global unique IDs (guids)
to identify users and groups in the LDAP directory. The identifiers
assigned by LDAP directory servers are usually unique for any LDAP
entry instance. If the user information is deleted and re-added, or
exported and imported into another LDAP directory, the guid changes.
Changes like this are usually implemented when employees change status,
a directory record is deleted and added again, or when user data is
ported across directories.


When the guid of a user changes,
you must synchronize the LDAP with the Profiles database before that
user logs in again. Otherwise, the user will have two accounts in IBM Connections and the user's
previous content will appear to be lost as it is associated with the
previous guid. If you assign a fixed attribute to each record, you
can minimize the possibility of accidentally introducing dual accounts
for a user in IBM Connections.


The wimconfig.xml file governs a single ID attribute for all supported objects such
as users, groups, and organizations in WebSphere Application Server.
You can use the LotusConnections-config.xml file to override
the ID attribute in the wimconfig.xml file. For example,
you could use the wimconfig.xml file to specify the ibm-entryUUID
attribute as the ID Key attribute for users and groups in all applications
running on WebSphere Application Server, and then modify the LotusConnections-config.xml file to specify the employeeID
as the ID Key attribute for IBM Connections applications.




About this task
You can change
the default setting to use a custom ID to identify users and groups
in the directory. 


A custom
ID must meet the following requirements:
  • The ID must be static and unique. It must not be reassigned across
users and groups in the directory.
    • 

  • The ID must not exceed
256 characters in length. To achieve faster search results, use a
fixed-length attribute for the ID.
    Note: If you are planning to install
the Files or Wikis application, the ID cannot exceed 252 characters
in length.
    

    • 

  • The ID must have a one-to-one mapping per directory object. You
cannot use an attribute with multiple values as a unique ID.
    • 





To specify a custom
attribute as the unique ID for users or groups, complete the following
steps:




Procedure
  1. From the VMM_HOME/model directory,
open the wimxmlextension.xml file. If no file
with this name exists, create one. 
    VMM_HOME is the directory where the Virtual Member Manager files are located.
This location is set to either the wim.home system property or the user.install.root/config/cells/local.cell/wim directory.
    

    2. 

  2. Add the definitions of the new property types and the entity
types to which they apply. Ensure that the XML is well-formed and
conforms to the schema defined in wimschema.xsd. 
    • To select a single ID attribute for both users and groups,
use the following sample XML, which defines a new property type called
enterpriseID and adds this property type to the PersonAccount and
Group entity types:
      <?xml version="1.0" encoding="UTF-8"?>
<sdo:datagraph xmlns:sdo="commonj.sdo" 
xmlns:wim="http://www.example.com/websphere/wim">
<wim:schema>
<wim:propertySchema 
nsURI="http://www.example.com/websphere/wim" 
dataType="STRING" multiValued="false" 
propertyName="enterpriseID">
<wim:applicableEntityTypeNames>PersonAccount
</wim:applicableEntityTypeNames>
</wim:propertySchema>
<wim:propertySchema 
nsURI="http://www.example.com/websphere/wim" 
dataType="STRING" multiValued="false" 
propertyName="enterpriseID">
<wim:applicableEntityTypeNames>Group
</wim:applicableEntityTypeNames>
</wim:propertySchema>
</wim:schema>
</sdo:datagraph> 
      

      

      • 

    • To use two different ID attributes, one for users and a different
one for groups, use the following sample XML, which defines a property
type called customUserID and adds it to the PersonAccount entity type,
and also defines a property type called customGroupID and adds it
to the Group entity type:
      <?xml version="1.0" encoding="UTF-8"?>
<sdo:datagraph xmlns:sdo="commonj.sdo" 
xmlns:wim="http://www.example.com/websphere/wim">
<wim:schema>
<wim:propertySchema 
nsURI="http://www.example.com/websphere/wim" 
dataType="STRING" multiValued="false" 
propertyName="customUserID">
<wim:applicableEntityTypeNames>PersonAccount
</wim:applicableEntityTypeNames>
</wim:propertySchema>
<wim:propertySchema 
nsURI="http://www.example.com/websphere/wim" 
dataType="STRING" multiValued="false" 
propertyName="customGroupID">
<wim:applicableEntityTypeNames>Group
</wim:applicableEntityTypeNames>
</wim:propertySchema>
</wim:schema>
</sdo:datagraph> 
      

      

      • 

    
 
    Note: The customUserID and customGroupID properties are not
related to the properties of the login ID.
    

    3. 

  3. Add the new property types to each repository adapter.
Open the wimconfig.xml file in a text editor. 

    

    Option
Description
    

    AIX
/usr/IBM/WebSphere/AppServer/profiles/<profile_name>/config/cells/<cell_name>/wim/config

    

    Linux
/opt/IBM/WebSphere/AppServer/profiles/<profile_name>/config/cells/<cell_name>/wim/config

    

    Microsoft Windows
C:\IBM\WebSphere\AppServer\profiles\<profile_name>\config\cells\<cell_name>\wim\config

    

    

    4. 

  4. Find and edit the <config:attributeConfiguration> element,
adding one of the following texts: 
    • To use a single ID attribute for both users and groups, using
a string called enterpriseid, add the following text:
      <config:attributeConfiguration>
	<config:externalIdAttributes 
name="enterpriseID" syntax="String"/>
</config:attributeConfiguration>  
      

      

      • 

    • To use two different ID attributes, one for users and the
other for groups, add the following text:
      <config:attributeConfiguration>
	<config:attributes name="userPassword" 
propertyName="password"/>
	<config:attributes name="customUserID" 
propertyName="customUserID"/>
	<config:attributes name="customGroupID" 
propertyName="customGroupID"/>
	<config:propertiesNotSupported 
name="homeAddress"/>
	<config:propertiesNotSupported 
name="businessAddress"/>
</config:attributeConfiguration> 
      

      

      • 

    

    5. 

  5. Save and close the wimconfig.xml  file.
    6. 



What to do next
If you specified different ID attributes for users and
groups, complete the steps in the Configuring the custom ID
attribute for users or groups topic in the Post-installation
tasks section of the product documentation. The steps in that task
configure IBM Connections to
use the custom ID attributes that you specified in this task.


When you map fields in the Profiles database, ensure that you add
the custom ID attribute to the PROF_GUID field in the EMPLOYEE table.
See the Mapping fields manually topic.










Creating databases


Create databases for the applications that you plan to
install. You can use the database wizard or run the SQL scripts that
are provided with IBM Connections.


Note: If you are migrating from Lotus Connections version 3.0.1, do not complete
the tasks for creating databases. The migration process manages those
tasks automatically. However, you must create the following new databases
if you plan to use the associated applications:
  • Cognos
    • 

  • Metrics
    • 

  • Mobile
    • 





Each IBM Connections application
requires its own database, except Moderation, News, and Search. The
Moderation application does not have an associated database or content
store, while the News and Search applications share the Home page
database. 


The database wizard automates the process of creating databases
for the applications that you plan to install. It is a more reliable
method for creating databases because it validates the databases as
you create them.


Consult your database documentation for detailed information about
preparing your databases.
Note: You must have already created and started
a database instance before you can create databases.




Complete the procedures that are appropriate for your deployment:




Creating multiple database instances


Create multiple instances of a database for a more versatile
database environment.


Before you begin
This is an optional procedure. If you need to have only one
database instance (in Oracle terminology, one database), you can skip
this task.
(Windows only) Complete the following steps for each instance
that you plan to create: 
  1. Create a new user and add it to the Administrators group.
    Note: If you are using DB2, add the new user to the DB2ADMNS group as well.
    

    2. 

  2. Remove the user account from the Users group.
    3. 

  3. In the Local Security Policy utility, add these rights to the
new user:
    • Act as part of the operating system
      • 

    • Adjust memory quotas|Increase quotas for a process
      • 

    • Create a token object 
      • 

    • Debug programs
      • 

    • Lock pages in memory
      • 

    • Log on as a service
      • 

    • Replace a process level token
      • 

    

    4. 



Note: The new account uses the local system as the domain.  
   






About this task
A database environment with multiple instances provides
several benefits: 
  • the ability to use different instances for development and production.
    • 

  • restricted access to sensitive information.
    • 

  • an optimized configuration for each instance.
    • 





For example, if you need to make changes to one of the
instances, you can restart just that instance instead of restarting
the whole system. Similarly, if you need to take an instance offline,
only the databases that are hosted on that instance are unavailable
during the outage, while your other databases are unaffected.


Multiple instances require additional system resources.


To
create multiple instances of a database, complete the following steps:




Procedure
Choose your database type:
  • DB2
    Notes: 
    • For each instance that you want to create, log in as the instance
owner before creating the instance.
      • 

    • Use the DB2 Command Line
Processor to enter commands.
      • 

    • After creating the instance, add the instance to the user environment
variable. The instance is then visible in the DB2 Control Center.
      • 

    

    

    • AIX: 
      An instance called db2inst1 is created during DB2 installation.
      

      1. Create a group for DB2:
        mkgroup db2iadm1
        

        

        2. 

      2. Create a user for DB2:
        mkuser groups=db2iadm1 db2instN
        

        

        where db2instN is the name of
a user. DB2 prompts you to enter
a password for the user. Repeat this step to create enough users to
match the number of database instances. 
        

        3. 

      3. Create DB2 instances:
        Login with root user and go to /opt/IBM/db2/V9.5/instance.
        

        ./db2icrt -u db2instN db2instN
        
where db2instN is the name of a user
and also the name of an instance. Repeat this step to create enough
instances to match the number of databases. 
        

        4. 

      4. Set the port number of the instance: 
        Edit the/etc/services file and add the following line: 
        

        db2c_instance_name instance_port/tcpwhere instance_name is the name of the instance
and instance_port is the port number of that instance.
Repeat this step for each instance. 
        

        5. 

      5. Set the communication protocols for the instance:
        db2 update database manager configuration using svcename db2c_instance_name
db2set DB2COMM=tcpip
db2stop
db2start
        
Repeat this step for each instance. 
        

        6. 

      6. Edit your firewall configuration
to allow the new instances to communicate through their listening
ports.
        7. 

      

      • 

    • Linux: 
      An instance called db2inst1 is created during DB2 installation, along with three users: db2inst1,
db2fenc1, and dasusr1.
      

      1. Create groups for DB2:
        groupadd -g 999 db2iadm1 
groupadd -g 998 db2fadm1 
groupadd -g 997 dasadm1 
        

        

        2. 

      2. Create users for DB2 in
the db2iadm1 group:
        useradd -u 1100 -g db2iadm1 -m -d /home/db2instN db2instN -p db2instX
        

        

        where db2instN is the name of
a user and db2instX is the password for that user.
Create enough users to match the number of database instances. 
        

        3. 

      3. Create the db2fenc1 user for DB2 in the db2fadm1 group:
        useradd -u 1101 -g db2fadm1
-m -d /home/db2fenc1 db2fenc1 -p db2instX
        

        4. 

      4. Create the dasusr1 user for DB2 in the dasadm1 group:
        useradd -u 1102 -g dasadm1	-m
-d /home/dasadm1 dasusr1 -p db2instX
        

        5. 

      5. Create new DB2 instances:
        Login with root user and go to /opt/ibm/db2/V9.5/instance.
        

        ./db2icrt -u db2fenc1 db2instN
        

        Create enough instances to match the number of
databases. 
        

        6. 

      6. Set the port number of the instance: 
        Edit the /etc/services file and add the following line: 
        

        db2c_<instance_name>
<instance_port>/tcp
        
where instance_name is the name of the instance and instance_port is the port number of that instance. Repeat this step for each instance. 
        7. 

      7. Log in as the database instance and set the communication protocols
for the instance:
        su - db2instN
db2 update database manager configuration using svcename 
 db2c_instance_name
db2set DB2COMM=tcpip
db2stop
db2start
        

        
Repeat this step for each instance. 
        8. 

      8. Edit your firewall configuration
to allow the new instances to communicate through their listening
ports.
        9. 

      

      • 

    • Microsoft Windows:
      1. Create an instance by running the following command:
        db2icrt instance_name -s ese -u db2_admin_user
        

        where instance_name is the
name of the instance and db2_admin_user is the
user account for that instance.
        

        2. 

      2. Set the port number of the instance: 
        Edit the C:\WINDOWS\system32\drivers\etc\services file and add the following line: 
        

        db2c_instance_name instance_port/tcp
        

        3. 

      3. Set the current instance parameter:
        set DB2INSTANCE=instance_name
        

        

        4. 

      4. Set the communication protocols for the instance:
        db2 update database manager configuration using svcename 
 db2c_instance_name
db2set DB2COMM=npipe,tcpip
db2stop
db2start
        

        

        5. 

      5. Edit your firewall configuration
to allow the new instances to communicate through their listening
ports.
        6. 

      

      • 

    

    • 

  • Oracle:
    Each database is a database instance.
    

    Use the Oracle Database Configuration Assistant (DBCA) to create
Oracle a new database:
    1. Open the DBCA tool:
      • AIX or Linux:
        1. Change login user to oracle
          2. 

        2. $ export [[ORACLE_HOME]]=...
          3. 

        3. $ export PATH=$PATH:$ORACLE_HOME/bin
          4. 

        4. $ export DISPLAY=hostname:displaynumber.screennumber 
          Note: where hostname:displaynumber.screennumber represents the client system, monitor number, and window number.
For example: localhost:0.0
          

          5. 

        5. $ dbca &
          6. 

        

        • 

      • Windows:
        1. Click Start
          2. 

        2.  Select Oracle > Oracle_home_name > Configuration and
Migration Tools > Database Configuration Assistant.
          where Oracle_home_name is the
Oracle home on your system. For example: OraDB10g_Home1.
          

          3. 

        

        • 

      

      2. 

    2. On the Operations page, accept the default option to Create a database and click Next.
      3. 

    3. On the Database Templates page, accept the General
Purpose default option and click Next.
      4. 

    4. On the Database Identification page, enter LSCONN in the Global
Database Name and SID fields and click Next.
      5. 

    5. On the Management Options page, accept the default option to Configure the database with Enterprise Manager and click Next.
      6. 

    6. On the Database Credentials page, enter the database password
and click Next.
      7. 

    7. On the Storage Options page, accept the File System storage option
and click Next.
      8. 

    8. On the Database File Locations page, accept the Database File
Locations from Template default option and click Next.
      9. 

    9. On the Recovery Configuration page, accept the Specify Flash Recovery
Area default option and click Next.
      10. 

    10. On the Database Content page, accept the defaults and click Next.
      11. 

    11. On the Initialization Parameters page, click the Character
Sets tab and select the Use Unicode (AL32UTF8) option.
Click Next.
      12. 

    12. On the Database Content page, accept the defaults and click Next.
      13. 

    13. On the Creation Options page, accept the Create Database default
option and click Next.
      14. 

    

    

    • 

  • SQL Server
    1. Run the SQL Server installation wizard. On the Instance Name panel
of the installation wizard, select Named instance, and then specify a new instance name in the field. 
      2. 

    2. Edit your firewall configuration
to allow the new instances to communicate through their listening
ports.
      3. 

    3. Ensure
that Named Pipes is enabled in the SQL Server Network Configuration
for all instances. For more information, refer to your SQL Server
documentation. 
      

      4. 

    

    Notes: 
    • Use the same collation that you are using for the application
databases; that is: Latin1_General_BIN. Ensure that the ancillary
databases, such as the master, model, tempdb, and msdb databases,
use that collation.
      • 

    • For Authentication mode, use Mixed Mode (Windows Authentication and SQL Server Authentication).
      • 

    • If you receive any warnings or errors from the System Configuration
Check dialog, correct them from the SQL Server 2005 instance installation.
      • 

    

    
For more information, go to the Microsoft SQL Server Developer Center web site to view the SQL Server
documentation:
    

    • 





What to do next
When you create multiple database instances, you must install
the databases on each instance. If you are using the database wizard
to install the databases, you must prepare and run the database wizard
once for each instance and if you are using the scripts to install
the databases, you must run the scripts once for each instance.






Registering the DB2 product
license key


Register the DB2 product
license key for the version of DB2 that
is included with IBM Connections.


Before you begin
Only perform this
procedure if you are using the version of DB2 that was included with IBM Connections. If you installed IBM Connections and DB2 from
the product DVD, the license key was
already provided.
If you used DB2 with
an earlier version of IBM Connections,
your installation of DB2 is
already registered and you can skip this task.


Note:  Install DB2 before beginning
this task but do not create any application databases until after
you have completed this task.




About this task
To register
the DB2 product license key,
complete the following steps:


Procedure
  1. Navigate
to the IBM Passport Advantage® web
site and log in.  
    Note:  If you installed IBM Connections and DB2 from the product DVD, the license key was
already provided. You can skip Steps 1-3 and begin at Step 4.
    

    2. 

  2. Choose Find
by Part Number and search
for part number CZ381ML.
    3. 

  3. Download
the part and extract the DB2_ESE_Restricted_QS_Activation_97.zip file,
making a note of the download location. 
    4. 

  4. Log into DB2 using an ID with SYSADM authority.
    5. 

  5. Open a command prompt, change to the directory where the
license file is stored, and run the following command: 
    Note: On
the DVD image, the license is stored in the DB2.License directory.
    

    db2licm
-a path_to_lic_file/db2ese_o.lic
    

    where path_to_lic_file is
the directory to which you extracted the db2ese_o.lic file. 
    

    Note: For
more information about using the db2licm command,
see the DB2 information
center.
    

    6. 

  6. Verify that the license
is registered by running the following
command: 
    db2licm -l 
    

    If
the license is correctly registered, the details of your DB2 installation are displayed.
    

    7. 

  7. Restart DB2.
    8. 



What to do next
Create your IBM Connections
application databases.






Creating a dedicated DB2 user


Create a dedicated IBM DB2 database user
named lcuser with restricted privileges.


About this task
Perform this task to create a DB2 database user, called lcuser, with a limited
set of privileges. The scripts that are provided with IBM Connections grant the appropriate rights
to lcuser and are written with the assumption that the
user name is lcuser. Always use lowercase characters
for this user name.
To create a dedicated DB2 database user named lcuser,
complete the following steps:




Procedure
Choose your operating system:
  • AIX or Linux:
    • Log into the DB2 server
as the root user, and then type the following command to create a
new user:
      useradd -u 1004 -g db2iadm1 -m -d /db2home/lcuser
lcuser -p password
      

       where password is new password for the new user. The command
assumes that your DB2 users
group is db2iadm1 and that your home directory for DB2 is db2home. If these values are different
in your environment, modify the command accordingly.
      

      • 

    

    • 

  • Windows
    1. Click  Start > Control
Panel and select Administrative Tools > Computer Management.
      2. 

    2. From the Computer Management console, select System Tools > Local Users and Groups.
      3. 

    3. Right-click Users and select New User.
      4. 

    4. Add a user named lcuser. Enter the required
details, including the password. Clear the User must change
password at next logon check box. Click Create.
      5. 

    5. Click Close.
      6. 

    6. Open the Users object, right-click lcuser, and select Properties from the context menu.
      7. 

    7. Click the Member Of tab and then click
the Add button.
      8. 

    8. Type DB2USERS in the Enter the
object names to select field, and click OK. Click OK again to save your changes.
      Note:  If the DB2USERS group is not found, extended security for DB2 on Windows might not be enabled. See the DB2 documentation for information
about Extended Windows security
using DB2ADMNS and DB2USERS groups. 
      

      9. 

    

    • 





What to do next
For more information about granting privileges to users,
go to the DB2 information
center.








Configuring the DB2 databases
for unicode


You must configure each DB2 database
used in the IBM Connections
deployment for unicode.


About this task
Configuring the DB2 databases
for unicode ensures that DB2 tools
like export and import do not  corrupt unicode data.




Procedure
You must perform the following steps on each DB2 instance in the deployment:
  1. Stop any WebSphere server
connected to the DB2 database
you are configuring.
    2. 

  2. Log in to the DB2 server
as the DB2 instance owner.
    3. 

  3. Open the DB2 command
window.
    4. 

  4. Run the following commands: 
    db2set DB2CODEPAGE=1208
db2stop force
db2start
    

    5. 

  5. Run the following commands to check the new configuration: 
    db2set
    
 This should
return DB2CODEPAGE=1208. If not, it is not configured
correctly and you should try Step 4 again.
    6. 







Creating databases with the database wizard


Use the database wizard to create databases for the IBM Connections applications. You
must be logged in with the database administrator account.




Preparing the database wizard


Before you can use the wizard to create databases for your IBM Connections deployment, prepare
the database server.


Before you begin
Ensure that you have given the necessary permissions to
the user IDs that need to log in to the database system and access
the IBM Connections Wizards
directory.


Notes: 
  • If you are planning to create multiple database instances, prepare
and run the database wizard once for each instance. 
    • 

  • (DB2 only) Create a dedicated IBM DB2 database user named lcuser. For more information, see the Creating a dedicated DB2 user topic.
    

    • 

  • (Oracle only) Ensure
that the Statement cache size for the data sources on WebSphere Application
Server is no larger than 50. A higher value could lead to Out Of Memory
errors on the application server instance.
    

    • 

  • (AIX only) If you are downloading the wizard, the TAR program available
by default with AIX does not
handle path lengths longer than 100 characters. To overcome this restriction,
use the GNU file archiving program instead. This program is an open
source package that IBM distributes
through the AIX Toolbox for Linux Applications at the IBM AIX Toolbox web site. Download
and install the GNU-compatible TAR package. You do not need to install
the RPM Package Manager because it is provided with AIX. 
    

    After you have installed the GNU-compatible
TAR program, change to the directory where you downloaded the IBM Connections TAR file, and enter
the following command to extract the files from it:
    

    gtar -xvf Lotus_Connections_wizard_aix.tar
    

    This command creates a directory named after the wizard. 
    

    • 

  • (AIX only) Download and install the
following packages from the AIX Toolbox
for Linux Applications webpage: 
    

    gtk2-2.10.6, pango-1.14.5, fontconfig-2.4.2,
pkg-config-0.19, libjpeg-6b, freetype2-2.3.9, expat-2.0.1, zlib-1.2.3,
xft-2.1.6, xcursor-1.1.7, glib-1.2.10, glib2-2.12.4, atk-1.12.3, gettext-0.10.40,
libpng-1.2.32, and libtiff-3.8.2
    

    Note: Some of these
packages have dependencies on other packages. The AIX package installer alerts you to any additional
packages that might be required.
    

    

    • 









About this task
To prepare the database wizard, complete the following
steps:




Procedure
  1. Log in to your
database server as the root user or system administrator.
    2. 

  2. (AIX and Linux only) Grant display authority to all
users by running the following commands under the root user or system
administrator:	 
    xhost +	// Grant display
authority to other users
    Note: If granting display authority
to all users is a security concern for you, change the command to
grant display authority to a specific user or users. For more information
about this command, consult your AIX or Linux administrator
guide.
    

    

    echo $DISPLAY // Echo the value of
DISPLAY under the root user
    

    3. 

  3. (AIX and Linux only) Ensure that the current user is
qualified or else switch to a qualified user by running the following
commands:
    • DB2
      su – db2inst1 // db2inst1
is the default DB2 administrator
      

      export
DISPLAY=hostname:displaynumber.screennumber 
      

      where hostname:displaynumber.screennumber represents the client system, monitor number, and window number.
For example: localhost:0.0
      

      xclock // Display the clock, confirming that the current user has
display authority and can run the wizard 			 
      

      // Press Ctrl + C to close the clock and return to the command prompt
      

      • 

    • Oracle
      Note:  Before running the database wizard,
you must create an Oracle database instance.
      

      su
– oracle // oracle is the Oracle database administrator 
      

      export DISPLAY=hostname:displaynumber.screennumber 	
      

      xclock //Display the clock, confirming
that the current user has display authority and can run the wizard		
      

      // Press Ctrl + C to close the clock and return
to the command prompt
      

      where hostname:displaynumber.screennumber represents the client system, monitor number, and window number.
For example: localhost:0.0
      

      • 

    
 
    Note: If you can see the xclock application running after issuing
the xclock command, then you have permission to run the database wizard.
If you cannot see the xclock application, run the xhost + command
as root user and then run the su command.
    

    4. 

  4. Start the database instance: 
    Note: Run the database
commands under the user account that has administrative access to
the database. 
    

    • AIX or Linux:
      • DB2
         db2start // Start the current DB2 instance
        

        Note: For more information about starting a DB2 instance, go to the Setting the current instance environment variables web page in the DB2 information
center.
        

        • 

      • Oracle (login as oracle or use the su oracle command
to change to oracle)
        export ORACLE_SID=orcl // Specify
the current Oracle database
        

        export ORACLE_HOME=/home/oracle/oracle/product/10.2.0/db_1
// Specify the Oracle home directory
        

        cd $ORACLE_HOME/bin 
        

        ./sqlplus "/ as
sysdba" 
        

        startup // Start the current
Oracle database
        

        • 

      

      • 

    • Microsoft Windows:
      Note: Windows registers most database instances
as a service. You can start or stop a database service manually if
necessary.
      

      • DB2
        1. Log in to the Control Center.
          2. 

        2. In Object View, right-click the database instance.
          3. 

        3. In the menu, click Start to start the database
manager.
          4. 

        

        • 

      • Oracle
        1. Open the Windows Services
panel: Click Start > All Programs > Administrative Tools > Services.
          2. 

        2. Right-click the Oracle service.
          3. 

        3. From the menu, click Start to start the
database service.
          4. 

        

        • 

      • SQL Server
        1. Open SQL Server Management Studio.
          2. 

        2. Connect the database instance.
          3. 

        3. Start the database instance from the studio.
          4. 

        

        • 

      

      • 

    

    5. 

  5. Copy the Wizards directory in the IBM Connections installation media to the system
that hosts the database server.  
    Notes: 
    • If you have more instances, exit from the current instance and
repeat this step for each instance.
      • 

    • (AIX and Linux only) Ensure that users other than root have permission to access the IBM Connections Wizards directory.
      • 

    • (DB2 only) For more information about working with multiple instances,
see the Setting the current instance environment variables topic in the DB2 information
center.
      • 

    

    

    6. 







Using the database wizard


Use the database wizard to create databases for the IBM Connections applications that
you plan to install.


Before you begin
Before using the wizard for the first time, you must complete
the steps described in the Preparing the database wizard topic.
When you are
creating a database either with the database wizard or SQL scripts,
you must log into the system where the database is hosted with the
database administrator account. The default values for DB2 are db2admin on Microsoft Windows, and db2inst1 on Linux and AIX. For Oracle, the default
value on AIX and Linux is oracle, and system administrator on Windows. For SQL Server, the
default value is the system administrator.


Oracle and SQL Server connect to IBM Connections databases with the user accounts that are configured
during database creation. The passwords of those user accounts are
defined later in this task. 


(Oracle only) Ensure
that the Statement cache size for the data sources on WebSphere Application
Server is no larger than 50. A higher value could lead to Out Of Memory
errors on the application server instance.


(DB2 only) If you use only one database
instance and if that instance includes other databases besides IBM Connections, configure the numdb
parameter to match the total number of databases on the instance.
For more information, go to the numdb webpage in the DB2 information center.
Notes: 
  • If you migrated from IBM Connections 3.0.1, the numdb parameter was set to 12, the maximum
number of IBM Connections 4.0
databases. If the instance has additional databases, increase the
value of the numdb parameter to match the total number of databases
on the instance.
    • 

  • You can use the following command to change the parameter: 
    db2 UPDATE DBM CFG USING NUMDB nn
    

    where nn is a number of databases.
    

    • 







DB2 uses a user account called
lcuser. If  you are creating a DB2 database with SQL scripts, you must manually create the lcuser account
on your operating system and then run the appGrants.sql script to grant the appropriate privileges to the lcuser account.
When you use the database wizard, this script runs automatically.
For more information, see the Creating a dedicated DB2 user topic. 


Notes: 
  • If you are using Linux on IBM System
z with the DASD driver, the SQL scripts are located in the connections.s390.sql/application_subdirectory directory of the IBM Connections
set-up directory or installation media.
    • 

  • If you are using Linux on IBM System z with the SCSI
driver, back up the connections.s390.sql directory
and rename the connections.sql directory to connections.s390.sql.
    • 

  • (AIX only) Download and install the
following packages from the AIX Toolbox
for Linux Applications webpage: 
    

    gtk2-2.10.6, pango-1.14.5, fontconfig-2.4.2,
pkg-config-0.19, libjpeg-6b, freetype2-2.3.9, expat-2.0.1, zlib-1.2.3,
xft-2.1.6, xcursor-1.1.7, glib-1.2.10, glib2-2.12.4, atk-1.12.3, gettext-0.10.40,
libpng-1.2.32, and libtiff-3.8.2
    

    Note: Some of these
packages have dependencies on other packages. The AIX package installer alerts you to any additional
packages that might be required.
    

    

    • 









About this task
Use the IBM Connections
database wizard to create, update, and remove databases. 
You can
review the scripts that the wizard executes by looking in the connections.sql directory in the installation media. On DB2, the commands are shown in the
log that the wizard creates. On Oracle and SQL Server, the log shows
the results of the commands.


To create databases with the wizard,
complete the following steps:




Procedure
  1. (DB2 on Windows 2008 64-bit.) On Windows 2008, you must perform DB2 administration tasks with full
administrator privileges.
    1. Logged in as the instance owner, open a command prompt
and change to the DB2 bin directory.
For example: C:\Program Files\IBM\SQLLIB\BIN. 
      2. 

    2. Enter the following command: db2cwadmin.bat. This command opens the DB2 command line processor while also setting your DB2 privileges.
      3. 

    

    2. 

  2. From the IBM Connections
Wizards directory, open the following file to launch the wizard:
    • AIX: ./dbWizard.sh 
      • 

    • Linux: ./dbWizard.sh 
      • 

    • Microsoft Windows: dbWizard.bat 
      • 

    

    3. 

  3. Click Next to continue.
    4. 

  4. Select the option to Create a database
and click Next.
    5. 

  5. Enter the details of the database you wish to create and
then click Next:
    1. Select a database type.
      2. 

    2. Select the location of the database. 
      Note: For an Oracle database on Windows 2008 64-bit, enter the value of the
ORACLE_HOME registry key. For example, the key for Oracle 11g on Windows 2008 64-bit is HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE\Key_OraDb11g_home1
and the value is C:\app\Administrator\product\11.2.0\dbhome_1.
      

      3. 

    3. Specify a database instance. 
      Note: The database
instance that you specify must already exist on your system. 
      

      4. 

    

    6. 

  6. Select an application and click Next. 
    Notes: 
    • If you are creating databases in this task, only applications
that have not already been installed to a database instance are available.
If you are updating databases, you can only choose applications that
are already installed.
      • 

    • The News and Search databases are contained in the Home page database.
      • 

    • The Metrics application has some additional requirements:
      • If you select the Metrics application, you must also select the IBM Cognos application.
        • 

      • If you have already deployed Cognos components and have a Cognos Content Store available, you do not need to create another.
        • 

      • If you do create a Cognos Content Store, only the container is created now; the tables are
created when you start the Cognos BI Server for the first time.
        • 

      • You do not need a dedicated database server for Cognos or for the Metrics application; you
can host the Metrics database and the Cognos Content Store on the same database server as the other
Connections databases.
        • 

      • Even if you do not plan to deploy Cognos yet, you should create the Metrics database and the Cognos Content Store now so that IBM Connections can begin collecting
event data immediately.
        • 

      

      • 

    

    

    7. 

  7. (Oracle and SQL Server databases only) Enter the password for the
databases and then click Next. Choose one of
the following options: 
    • Use the same password for all applications. Enter the password in the Password and Confirm password fields. 
      • 

    • Create different passwords for each application. Enter a different password for each application database, and confirm
the password in the confirm field.
      • 

    

    8. 

  8. (SQL Server only) Specify the
location of the database file and then click Next.
    • Use the same database file location for all applications. Enter the location of the database or click Browse to choose a location.  
      • 

    • Use different database file locations for each
application. For each application, enter the location
of the database file or click Browse to choose
a location. 
      • 

    

    9. 

  9. Review the Pre Configuration Task Summary to ensure that
the values you entered on previous pages in the wizard are correct.
If you want to make a change, click Back to
edit the value. Click Create to begin creating
databases. 
    Note: Click Show detailed database
commands to preview each SQL command before it is executed
by the wizard. If you choose to save the commands, you must have write-access
to the folder you choose to save them in.
    

    10. 

  10. Review the Post Configuration Task Summary panel and, if
necessary, click View Log to open the log file.
Click Finish to exit the wizard. 
    11. 



What to do next
(DB2 for Linux on System z only.) To
improve database performance, enable the NO FILE SYSTEM CACHING option.
For more information, see the Enabling NO FILE SYSTEM CACHING
for DB2 on System z topic.








Using the database wizard in silent mode


Run the database wizard in silent mode when you need an
identical installation on multiple servers.


Before you begin
Ensure that the wizard has created the response.properties file in the user_settings/lcWizard/response/dbWizard directory.


To create a response file, run the wizard in standard
mode and specify that you would like to create a response file. You
can modify the existing response file or create your own, using a
text editor. For more information, see the Database wizard response
file topic.


(DB2 only) If you use only one database
instance and if that instance includes other databases besides IBM Connections, configure the numdb
parameter to match the total number of databases on the instance.
For more information, go to the numdb webpage in the DB2 information center.
Notes: 
  • If you migrated from IBM Connections 3.0.1, the numdb parameter was set to 12, the maximum
number of IBM Connections 4.0
databases. If the instance has additional databases, increase the
value of the numdb parameter to match the total number of databases
on the instance.
    • 

  • You can use the following command to change the parameter: 
    db2 UPDATE DBM CFG USING NUMDB nn
    

    where nn is a number of databases.
    

    • 







(Oracle only) Ensure
that the Statement cache size for the data sources on WebSphere Application
Server is no larger than 50. A higher value could lead to Out Of Memory
errors on the application server instance.




About this task
To create databases in silent mode, complete the following
steps:


Procedure
  1. (DB2 on Windows 2008 64-bit.) On Windows 2008, you must perform DB2 administration tasks with full
administrator privileges.
    1. Logged in as the instance owner, open a command prompt
and change to the DB2 bin directory.
For example: C:\Program Files\IBM\SQLLIB\BIN. 
      2. 

    2. Enter the following command: db2cwadmin.bat. This command opens the DB2 command line processor while also setting your DB2 privileges.
      3. 

    

    2. 

  2. From a command prompt, change to the directory where the
wizard is located. 
    3. 

  3. Launch the wizard by running the following command:  
    • AIX: ./dbWizard.sh -silent response_file 
      • 

    • Linux: ./dbWizard.sh -silent response_file 
      • 

    • Microsoft Windows: dbWizard.bat
-silent  response_file
      • 

    

    where response_file is the file path to
the response file.
    Note: If the path to the response_file contains
a space, this parameter must be enclosed in double quotation marks
(").
    

    

    4. 



What to do next
After the wizard has finished, check the log file in the Lotus_Connections_set-up_directory/Wizards/DBWizard directory for messages. The log file name uses the time as a postfix.
For example: dbConfig_20110308_202501.log.




The database wizard response file


The IBM Connections
database wizard can record your input in a response file that you
can use for silent installations.


When you want to run the database wizard in silent mode,
use the response file to duplicate the settings that you selected
when you ran the wizard in interactive mode. You can start the wizard
from a command prompt and then pass the response file in as a parameter.
The wizard uses the values in the response file rather than requiring
you to interact with it. 


There is a sample response file called dbWizard_response.properties in the Wizards/samples directory on the IBM Connections
set-up directory or installation media.




The response.properties file collects
a specific set of values. Those values are described in the following
table: 


Table 12. Typical properties of the response.properties
file 
Property
Value
Description




dbtype
db2 | oracle | sqlserver
The database system that you want to use.
Choose from IBM DB2, Oracle, or Microsoft SQL Server.



dbInstance
database_instance_name
The instance name of the database that you
want to use. For example: 
  • DB2 (DB2 on Windows) 
    • 

  • db2inst1 (DB2 on AIX or Linux)
    • 

  • orcl (Oracle) 
    • 

  • \\ (SQL Server)
    Note: The first '\' is an escape
character. 
    

    • 






dbHome
database_location
File path to the database.
Note: If you encounter
an Invalid database instance error, the file path to the database
might be incorrect.
If the dbHome value is, for example, /home/oracle/oracle/product/10.2.0/db_1/, then you must
remove the final / character. This limitation applies only on Oracle
databases.


On Windows, you need to add an escape character
'\'.  For example, activities.filepath=C\:\\SQLSERVER.







action
create | delete | upgrade
The action performed by the wizard. The
options are create, delete, or upgrade.



dbVersion
DB2: 9 | Oracle: 10 or 11| SQL Server 2005:9  SQL Server 2008: 10
The major version number of the database
type. 
For example, if you use SQL Server 2005, enter 9. If you use SQL Server 2008, enter 10. 





applications
activities, blogs, cognos, communities,
dogear, files, forum, homepage, metrics, mobile, profiles, wikis
IBM Connections applications for which the wizard creates databases.
Use a comma (,) character to separate multiple applications.








If you are creating Oracle or SQL Server
databases, you must add the additional properties described in the
following table:
Table 13. Additional properties for Oracle or
SQL Server databases
Property
Value
Description




<application>.password
Password for application databases
Password for the applications. 
Note: The
passwords will be removed from the response file after the wizard
has finished processing.





<application>.filepath
File path to the directory where database
files are stored
(SQL Server only) File path to the database
file location.
Note: On Windows, you must add an escape character '\'.  For example, activities.filepath=C\:\\SQLSERVER.












If you are upgrading databases and a JDBC connection
is needed, you must add the additional properties described in the
following table:
Table 14. Additional properties for upgrading
databases with JDBC
Property
Recommended value
Description




port

  • DB2 default
is 50000 
    • 

  • Oracle default is 1521
    • 

  • SQL Server default is 1433
    • 



Database server port for starting JDBC



administrator

  • DB2 default on Windows is db2admin
    • 

  • DB2 default on AIX and Linux is db2inst1
    • 

  • Oracle default is system
    • 

  • SQL Server default is sa
    • 



Database administrator account for starting
JDBC



adminPassword
 
Database administrator password for starting
JDBC



storyLifetimeInDays
 
The Home page upgrade requires this parameter.
It should be the same as the value in the news-config.xml file.



profiles.db.name profiles.db.hostname profiles.db.port
profiles.db.admin profiles.db.adminPassword
 
The Home page migration process copies data
from the Profiles database. For this reason, you must update the Home
page database before updating the Profiles database. The migration
process supports the use of different instances to host the Home page
and Profiles databases.



jdbcLibPath
 
(SQL Server only) JDBC library path for
starting JDBC.
Note: On Windows, you must add an escape character '\'.  For example, jdbcLibPath=C\:\\sqljdbc4.jar






















Creating
databases with SQL scripts


Create IBM Connections
databases using the SQL scripts that are provided on the installation
media. 


About this task
Using the SQL scripts
to create databases for IBM Connections
takes longer than using the wizard,
and does not validate the databases, but might be necessary in some
circumstances. 




Creating IBM DB2 databases manually


Create IBM DB2 databases with SQL scripts instead
of using the IBM Connections
database wizard.


Before you begin
Use this procedure if you do not want to use the database
wizard to create your databases. 
The
SQL scripts are located in a compressed file called connections.sql.zip|tar, located in the IBM_Connections_Install/IBMConnections/connections.sql directory of the IBM Connections
set-up directory or installation media. Extract this file before proceeding.
When extracted, the SQL scripts are located in the IBMConnections/connections.sql/application_subdirectory directory of the IBM Connections set-up directory
or installation media, where application_subdirectory is the directory that contains the SQL scripts for each application. 


If you are using AIX, see the note in the Preparing the
database wizard topic about decompressing TAR files.


Notes: 
  • If you are using Linux on IBM System z with the DASD
driver, the SQL scripts are located in the Lotus_Connections_Install_s390/LotusConnections/connections.s390.sql directory.
    • 

  • If you are using Linux on IBM System z with the SCSI
driver, back up the connections.s390.sql directory
and rename the connections.sql directory to connections.s390.sql.
    • 





If
the database server and IBM Connections
are installed on different systems, copy the SQL scripts to the system
that hosts the database server.


(AIX only) Configure the AIX system that hosts the DB2 databases to use the enhanced
journaled file system (JFS2), which supports file sizes larger than
2 GB. To enable large files in the JFS system, complete the following
steps:
  1. In the SMIT tool, select System Storage Management>File System>Add/Change/Show/Delete
File Systems
    2. 

  2. Select the file system type you want to use and specify other
characteristics as wanted. If you use a Journaled File System, set
the Large File Enabled setting to true.
    3. 


See the AIX documentation for more options.


Notes: 
  • When you are
creating a database either with the database wizard or SQL scripts,
you must log into the system where the database is hosted with the
database administrator account. The default values for DB2 are db2admin on Microsoft Windows, and db2inst1 on Linux and AIX. For Oracle, the default
value on AIX and Linux is oracle, and system administrator on Windows. For SQL Server, the
default value is the system administrator.
    

    • 







About this task
You must perform this task for each IBM Connections application that you are installing.
Note: To
capture the output of each command to a log file, append the following
parameter to each command: >> /file_path/db_application.log
where file_path is the full path to the log file and application is the name of the log file. For example:


db2 -tvf createDb.sql >> /home/db2inst1/db_activities.log


Ensure that you have write permissions for the directories
and log files.






To create the application databases,
complete the following steps:




Procedure
  1. Optional:  (Only required if the database server
and IBM Connections are installed
on different systems.) Copy the IBM Connections SQL scripts to the DB2 database system. Authorize a user ID that can create the
databases.
    2. 

  2. Log in to the DB2 database system with the user ID of the owner of the database instance.
The user ID must have privileges to create a database, a tablespace,
tables, and indexes.  
    Notes: 
    • If you created multiple database instances, specify the user ID
for the first instance.
      • 

    • The default administrative ID for Microsoft Windows is db2admin.
      • 

    

    

    3. 

  3. Start the DB2 command
line processor in command mode and enter the following command: 
    db2start
    

    4. 

  4. For Home page and Profiles, change to the directory where
the SQL scripts for each application are stored, and then enter the
following command to run the script: 
     db2
-tvf createDb.sql
    

    5. 

  5. For Home page, run the following script: 
    db2 -tvf initData.sql
    
 
    6. 

  6. For Activities, Communities, Blogs, Bookmarks, Files, Forums,
Mobile, and Wikis, change to the directory where the SQL scripts for
each application are stored, and then enter the following command
to run the script:   
    db2 -td@ -vf createDb.sql
    

    Note: The SQL scripts for Bookmarks are stored in the dogear directory.
    

    7. 

  7. Run the following command to grant access privileges to
the lcuser account for the Home page and Profiles databases: 
    db2 -tvf <application_subdirectory>/appGrants.sql
    

    8. 

  8. Run the following command to grant access privileges to
the lcuser account for the Activities, Communities, Blogs, Bookmarks,
Files, Forums, Mobile, and Wikis databases: 
    db2 -td@ -vf application_subdirectory/appGrants.sql 
    

    9. 

  9. Run the following commands to generate statistics for the
Home page database: 
    db2 -tvf application_subdirectory/reorg.sql
    

    db2 -tvf application_subdirectory/updateStats.sql
    

    10. 

  10. Run the following commands to create Calendar tables in
the Communities database: 
    db2 -td@ -vf communities/calendar-createDb.sql
    

    db2 -td@ -vf communities/calendar-appGrants.sql
    

    11. 

  11. If you plan to use the Metrics application, run the following
commands to create the Metrics and Cognos databases: 
    db2 -td@ -vf metrics/createDb.sql
    

    db2 -td@ -vf metrics/appGrants.sql
    

    db2 -td@ -vf cognos/createDb.sql
    

    db2 -td@ -vf cognos/appGrants.sql
    

    Note: The first two of these commands create the Metrics database and the
following two commands create the Cognos database. The Cognos database tables are created when you start the Cognos BI Server for the first time. 
    

    12. 

  12. Close the DB2 command
line processor.
    13. 

  13. Optional: When you install IBM Connections, the JDBC configuration page
of the installation wizard asks you to provide a user ID and password
for the Application User. The user ID that you specify on that page
must have read and write access to the database. You can provide the
user ID of an administrative user or you can create a dedicated user
ID with fewer privileges. See the Creating a dedicated DB2 user topic for more information.
    14. 



What to do next
(DB2 for Linux on System z only.) To
improve database performance, enable the NO FILE SYSTEM CACHING option.
For more information, see the Enabling NO FILE SYSTEM CACHING
for DB2 on System z topic.








Creating Oracle databases manually


Create Oracle databases with SQL scripts instead of using
the IBM Connections database
wizard.


Before you begin
Follow this procedure if you do not want to use the database
wizard to create your databases. 


The
SQL scripts are located in a compressed file called connections.sql.zip|tar, located in the IBM_Connections_Install/IBMConnections/connections.sql directory of the IBM Connections
set-up directory or installation media. Extract this file before proceeding.
When extracted, the SQL scripts are located in the IBMConnections/connections.sql/application_subdirectory directory of the IBM Connections set-up directory
or installation media, where application_subdirectory is the directory that contains the SQL scripts for each application. 


If
the database server and IBM Connections
are installed on different systems, copy the SQL scripts to the system
that hosts the database server.


Note: 
You must specify the Unicode AL32UTF8 character set.






About this task
This task describes how to use SQL scripts to create Oracle
databases for IBM Connections
applications. Complete this task only if you do not want to use the
database wizard.


Note: To capture the output of each command to a log file, run the following
commands before starting this task: 
sql> spool on


sql> spool output_file


where output_file is the full path and
name of the file where the output is captured.


When you have
completed this task, run the following command: sql> spool
off


To manually create the application database
tables, complete the following steps:






Procedure
  1. Log in with the same user ID that you used to install the
Oracle database system.
    2. 

  2. Create an Oracle
user ID with system database administrator privileges that you can
use to manage the database tables. Alternatively, use an existing
ID that has administrative privileges, such as SYS.
    3. 

  3. Set the ORACLE_SID. 
    If you created multiple
databases, specify the database on which to install the tables by
providing the SID for that database.
    

    4. 

  4. Run SQL Plus by entering the following command: 
    sqlplus /NOLOG
    

    5. 

  5. Log in as an administrator with the sysdba role by entering
the following command: 
    connect as sysdba
    

    Note: If not logged in as sysdba, the statistics gathering job
for the Bookmarks database is not created or correctly scheduled.
As a result, database performance is impacted.
    

    6. 

  6. Enter the Oracle user ID and password.
    7. 

  7. For each application, change to that application's SQL
scripts directory and enter the following command to create the application's
database tables: 
    @application_subdirectory/createDb.sql password
    

    Notes: 
    • Repeat this step for each IBM Connections application that you plan to install.
      • 

    • Begin the command with the @ symbol.
      • 

    • The createDB script creates a dedicated user
ID for the JDBC connector for an application database. Later, when
you run the IBM Connections
installation wizard, you must provide the user ID that you specify
in this step. You can specify one of the following default user IDs:
      • Activities: OAUSER
        • 

      • Blogs: BLOGSUSER
        • 

      • Bookmarks: DOGEARUSER
        • 

      • Cognos: COGNOS
        • 

      • Communities: SNCOMMUSER
        • 

      • Files: FILESUSER
        • 

      • Forums: DFUSER
        • 

      • Home page: HOMEPAGEUSER
        • 

      • Metrics: METRICSUSER
        • 

      • Mobile: MOBILEUSER
        • 

      • Profiles: PROFUSER
        • 

      • Wikis: WIKISUSER
        • 

      

      Notes: 
      • Each of these default user IDs has a narrower set of privileges
than an administrative user ID. 
        • 

      • You can change the passwords for these database users later in
Oracle Enterprise Manager Console. If you change the passwords there,
you must also change them in the J2C authentication alias settings
in the WebSphere Application
Server Integrated Solutions Console.
        • 

      • If you plan
to install the Metrics application, you can create the database now
but the tables are not created until you start the Cognos BI Server
for the first time.
        • 

      

      

      • 

    

    

    8. 

  8. Optional: (Communities only.) Run the following
commands: 
    @application_subdirectory/calendar-createDb.sql 
    

    @application_subdirectory/calendar-appGrants.sql 
    

    9. 

  9. Optional: (Dogear only.) Run the following
command: 
    @application_subdirectory/createHistogramStatsJob.sql 
    
 
    Note: 
    • This script creates a job to collect histogram statistics.
      • 

    • You must run this command while logged in with the SYS ID.
      • 

    

    

    10. 

  10. (Home page only.) Run the following command: 
    @application_subdirectory/initData.sql
    

    11. 

  11. Run the following command to grant access privileges for
each application: 
    @application_subdirectory/appGrants.sql
    

    12. 

  12. Close the SQL Plus window.
    13. 







Creating SQL Server databases manually


Create Microsoft SQL Server databases with SQL scripts instead of using the IBM Connections database wizard.


Before you begin
Follow this procedure if you do not want to use the database
wizard to create your databases. 


The
SQL scripts are located in a compressed file called connections.sql.zip|tar, located in the IBM_Connections_Install/IBMConnections/connections.sql directory of the IBM Connections
set-up directory or installation media. Extract this file before proceeding.
When extracted, the SQL scripts are located in the IBMConnections/connections.sql/application_subdirectory directory of the IBM Connections set-up directory
or installation media, where application_subdirectory is the directory that contains the SQL scripts for each application. 


If
the database server and IBM Connections
are installed on different systems, copy the SQL scripts to the system
that hosts the database server.


Before beginning the task, decide whether to use SQL Server
with or without an instance name, and with or without an A-Record
Alias.


If you installed SQL Server with a default instance,
you do not need to supply details of the sql_server_instance_name. For example, in a default instance
  • The name of the server is ServerA.
    • 

  • You configured the default instance when setting up SQL Server.
    • 

  • Use only the server name.
    • 





Alternatively, in an instancename example:
  • ServerB is the name of the server
    • 

  • You configured the instancename as Connections when setting up
SQL Server.
    • 

  • Use the ServerB\Connections naming format.
    • 





 Finally, where the A-Record is specified as an Alias
for SQL Server:
  • ServerC is the name of the server
    • 

  • You configured the default instance when setting up SQL Server.
    • 

  • You created an A-Record to use as an alias for a new SQL Server
called ServerC.
    • 

  • Use the name of the new A-Record. For example, use A-Record-Name\sqlserver_server_instance_name>
    • 


 




About this task
This task describes how to use SQL scripts to create SQL
Server databases for IBM Connections
applications. 


Download
the SQL Server JDBC 2 driver from the Microsoft web site and follow the instructions
to extract the driver files. IBM Connections uses the sqljdbc4.jar file.


IBM recommends that you obtain this Microsoft hotfix for the JDBC 2 driver for production deployments.


Note: To capture the output
of each command to a log file, append the following parameter to each
command:
>> \file_path\db_application.log

 
where file_path is the full path to the log file and application is the name of the log file. 


For example:


 sqlcmd >> \home\admin_user\lc_logs\db_activities.log


where sqlcmd is a command with parameters and admin_user is
the logged-in user. Ensure that you have write permissions for the
directories and log files.



To create the application database
tables, complete the following steps:


Procedure
  1. Configure SQL Server account mode and Windows Authentication mode:
    1. Create a SQL Server Account such as lcuser.
      2. 

    2. Apply sysadmin permissions.
      3. 

    

    2. 

  2. Configure Local Account Mode:
    1. Create a local account, such as lcuser, on the system
that is hosting SQL Server.
      2. 

    2. Add the local account to SQL Server with sysadmin permissions. 
      3. 

    3. Add the local account to the Local Administrators group. 
      4. 

    
 
    Note: You must specify these credentials later as parameters
of the U and P flags for the sqlcmd command.
    

    3. 

  3. Create a directory on the SQL Server system where you can
store the application databases.  
    Later on, you need
to specify these directories as parameters of the file path flag for
the sqlcmd command.
    

    4. 

  4. Create a SQL Server user ID with system database administrator
privileges that you can use to manage the database tables or use an
existing ID that has administrative privileges, such as sa.  
    You will specify these credentials as parameters
of the U and P flags for the sqlcmd
command later.
    

    5. 

  5. Perform the following steps once per application to create
each database: 
    1. Open a command prompt and change to the directory to
which you copied the database creation scripts for the application.
      2. 

    2. Enter the following command to create the application
database table: 
      Note: If your database server has multiple
SQL Server instances, add the following parameter as the first parameter
in each command:
      -S sqlserver_server_name\sqlserver_server_instance_name 
      

      
 
      sqlcmd -U admin_user -P admin_password -i "createDb.sql" -v filepath="path_to_db" password="password_for_application_user"
      
 where 
      • admin_user and admin_password are the credentials for the user ID that you created in a previous
step or an existing ID with administrative privileges.
        • 

      • path_to_db is the directory in which the created
database is stored. 
        • 

      • password_for_application_user is the password
for each application database. 
        • 

      • The database user IDs are named as follows:
        • Activities: OAUSER
          • 

        • Blogs: BLOGSUSER
          • 

        • Bookmarks: DOGEARUSER
          • 

        • Cognos:COGNOSUSER
          • 

        • Communities: SNCOMMUSER
          • 

        • Files: FILESUSER
          • 

        • Forums: DFUSER
          • 

        • Home page: HOMEPAGEUSER
          • 

        • Metrics: METRICSUSER
          • 

        • Mobile: MOBILEUSER 
          • 

        • Profiles: PROFUSER
          • 

        • Wikis: WIKISUSER
          • 

        
Specify the password to be associated with this user ID.
        • 

      

      Notes: 
      • When you run the installation wizard, you are asked to provide
a user ID for the JDBC provider. Specify the user ID created by the
database creation script and the password that you defined in this
step.
        • 

      • You
can change the passwords for these database users later in SQL Server
Management Studio. If you change the passwords there, you must also
change them in the J2C authentication alias in the WebSphere Application Server Integrated
Solutions Console.
        

        • 

      • If you plan
to install the Metrics application, you can create the database now
but the tables are not created until you start the Cognos BI Server for the first time.
        • 

      
 
      

      Example for SQL Server Account Mode:
      

      sqlcmd -S sql_server_name\sql_server_instance_name -U sql_server_account -P sql_server_account_password -i "createDb.sql" -v filepath="sql_server_data_path" password="password_for_application_user"
      

      Example for Local Account Mode:
      

      sqlcmd -S sql_server_name\sql_server_instance_name -U servername \local_account -P local_account_password -i "createDb.sql" -v
filepath="sql_server_data_path" password="password_for_application_user"
      
where 
      • sql_server_account andsql_server_account_password  are the credentials for SQL Server. These credentials do not apply
for Windows Local Account
or Windows Domain Account.
        • 

      • servername \local_account are the credentials for the user ID.
        • 

      • sql_server_data_path is the directory in which
the created database is stored. 
        • 

      

      3. 

    

    6. 

  6. (Home page only) Perform the following steps for the Home
page application: 
    1. Open a command prompt and change to the directory to
which you copied the database creation scripts for this application.
      2. 

    2. Enter the following command to create the application
database table: 
      sqlcmd -U admin_user -P admin_password -i initData.sql
      

      3. 

    

    7. 

  7. Optional: (Communities only) Run the following
commands: 
    sqlcmd -U admin_user -P admin_password -i calendar-createDb.sql 
    

    sqlcmd -U admin_user -P admin_password -i calendar-appGrants.sql 
    

    8. 

  8. Perform the following steps to grant access privileges
for the applications: 
    1. Open a command prompt and change to the directory to
which you copied the database creation scripts for each application.
      2. 

    2. Enter the following command: 
      sqlcmd -U admin_user -P admin_password -i appGrants.sql
      

      3. 

    

    9. 



What to do next
For more information about Microsoft SQL Server 2005 and 2008, go to the Microsoft SQL Server web site. 








Enabling NO FILE SYSTEM CACHING for DB2 on System z


When your operating system is Linux on System z, enable the NO FILE SYSTEM CACHING option for IBM DB2 databases to improve performance.


Before you begin
  • Important: Enabling the NO FILE
SYSTEM CACHING option on an unsupported device could cause your database
to become inaccessible. Ensure that your file system supports the
NO FILE SYSTEM CACHING option and that it meets the requirements for creating table spaces without file
system caching. 
    

    • 

  • Create a backup copy of the DB2 database using native database tools. 
    • 

  • If the database server and IBM Connections are installed on different systems, copy the SQL scripts
to the system that hosts the database server.
    • 

  • The SQL scripts for DB2 for Linux on System z are located in the connections.s390.sqlapplication_subdirectory directory of the IBM Connections set-up directory
or installation media, where application_subdirectory is the directory that contains the SQL scripts for each application. 
    • 

  • You can enable the NO FILE SYSTEM CACHING option for the Activities,
Communities, and Profiles databases only. 
    • 





About this task
When you create DB2 databases for IBM Connections
under Linux on System z, the IBM Connections database wizard and  the createDb.sql script create table spaces with the FILE SYSTEM CACHING option enabled.
If you are storing DB2 table
spaces on devices where Direct I/O (DIO) is enabled, such as Small
Computer System Interface (SCSI) disks that use Fibre Channel Protocol
(FCP), you can improve database performance by enabling the NO FILE
SYSTEM CACHING option.  


To enable the NO FILE SYSTEM CACHING
option, complete the following steps:




Procedure
  1. Log in to the DB2 database system with the user ID of the owner of the database instance.
The user ID must have privileges to create a database, a table space,
tables, and indexes.  
    Note: If you created
multiple database instances, specify the user ID for the first instance.
    

    2. 

  2. Enable the NO FILE SYSTEM CACHING option for the Activities
table space by entering the following commands: 
    CONNECT TO OPNACT
    

    ALTER TABLESPACE OAREGTABSPACE
NO FILE SYSTEM CACHING
    

    CONNECT RESET
    

    3. 

  3. Enable the NO FILE SYSTEM CACHING option for the Communities
table space by entering the following commands: 
    CONNECT TO SNCOMM
    

    ALTER TABLESPACE SNCOMMREGTABSPACE
NO FILE SYSTEM CACHING
    

    ALTER TABLESPACE
DFREGTABSPACE NO FILE SYSTEM CACHING
    

    CONNECT RESET
    

    4. 

  4. Enable the NO FILE SYSTEM CACHING option for the Forums
table space by entering the following commands: 
    CONNECT TO FORUM
    

    ALTER TABLESPACE DFREGTABSPACE
NO FILE SYSTEM CACHING
    

    CONNECT RESET
    

    5. 

  5. Enable the NO FILE SYSTEM CACHING option for the Profiles
table space by entering the following commands: 
    CONNECT TO PEOPLEDB
    

    ALTER TABLESPACE
USERSPACE4K NO FILE SYSTEM CACHING
    

    ALTER
TABLESPACE TEMPSPACE4K NO FILE SYSTEM CACHING
    

    ALTER TABLESPACE USERSPACE32K NO FILE SYSTEM CACHING
    

    ALTER TABLESPACE TEMPSPACE32K NO FILE SYSTEM CACHING
    

    CONNECT RESET
    

    6. 

  6. Close the DB2 command
line processor.
    7. 









Populating the Profiles database


Populate the Profiles database with data from the LDAP
directory.


Before you begin
  • Spend time planning your Profiles population, integration, and
customization. 
    • 

  • Involve all the relevant stakeholders at an early stage of the
planning process.
    • 

  • If possible, phase the Profiles rollout and get feedback from
pilot users. 
    • 

  • Prepopulate Profiles photos.
    • 

  • Plan for business card use and for Sametime presence awareness.
    • 

  • Ensure that Tivoli Directory
Integrator is correctly configured.
    • 

  • Consider using Tivoli Directory Integrator to populate the LDAP and then to populate the
Profiles database. 
    • 





Note: 
If you are migrating from IBM Connections version 3.0.1 or 3.0.1.1, do
not complete the tasks for populating the Profiles database. The migration
process handles those tasks separately. 








Related concepts:





Related reference:





Configuring Tivoli Directory
Integrator


Configure IBM Tivoli Directory Integrator (TDI)
to synchronize and exchange information between the Profiles database
and your LDAP directory. 


Before you begin
Ensure that you have installed all the required software,
including a database server and LDAP directory, and that you have
created the Profiles database. 
Note: 
The internal name of the Profiles
database is PEOPLEDB.






About this task
Use Tivoli Directory
Integrator to populate the Profiles database repository from an LDAP
directory.


You can manually run various Profiles tasks by using
the appropriate scripts in the TDI Solution directory. For more information
about these tasks, see the Batch files for processing Profiles
data topic.


To configure Tivoli Directory
Integrator, complete the following steps:




Procedure
  1. Install Tivoli Directory
Integrator, if it is not already installed. 
    When
prompted for the location of the Solution directory, select Do
not specify. Use the current working directory at startup time.
    

    At
the end of the installation process, clear the Start the
Configuration editor check box. 
    

    After you have
configured Tivoli Directory
Integrator, update it with the recommended fix packs. 
    

    2. 

  2. Make the database libraries available to Tivoli Directory Integrator by doing one of
the following:
    • DB2: Copy the db2jcc.jar and db2jcc_license_cu.jar files
from the java subdirectory of the directory where
you installed DB2. Paste the
files into a temporary location. The wizard will eventually paste
the drivers into the jvm/jre/lib/ext subdirectory
of Tivoli Directory Integrator.
      For
example, if you installed Tivoli Directory
Integrator on a Linux system
in /opt/IBM/TDI/V7.1, the path would be /opt/IBM/TDI/V7.1/jvm/jre/lib/ext. 
      

      • 

    • Oracle: Copy the ojdbc6.jar file from
the jdbc/lib subdirectory of the directory where
you installed Oracle. Paste the files into a temporary location. The
wizard will eventually paste the drivers into the jvm/jre/lib/ext subdirectory
of Tivoli Directory Integrator.
      For
example, if you installed Tivoli Directory
Integrator on a Linux system
in /opt/IBM/TDI/V7.1, the path would be /opt/IBM/TDI/V7.1/jvm/jre/lib/ext. 
      

      • 

    • SQL Server: 
      Download
the SQL Server JDBC 2 driver from the Microsoft web site and follow the instructions
to extract the driver files. IBM Connections uses the sqljdbc4.jar file.
      

      IBM recommends that you obtain this Microsoft hotfix for the JDBC 2 driver for production deployments.
      

      Paste
the files into a temporary location. The wizard will eventually paste
the drivers into the jvm/jre/lib/ext subdirectory
of Tivoli Directory Integrator.
      

      For example: If
you installed Tivoli Directory
Integrator on a Windows system
in C:\Program Files\IBM\TDI\V7.1, the path would
be C:\Program Files\IBM\TDI\V7.1\jvm\jre\lib\ext.
      

      • 

    
 If the database is hosted on a separate system, copy the database
JAR file to the system hosting Tivoli Directory
Integrator.
    3. 

  3. Edit the ibmdisrv file to increase
runtime memory and disable the JIT compiler. To increase the runtime
memory, add the two -Xms256M -Xmx1024M space-separated
arguments to the Java invocation
command; to disable the JIT compiler, add the -Xnojit argument.
The ibmdisrv file is stored in the TDI directory.
    • AIX or Linux: ibmdisrv
      After
you add the new arguments, the Java invocation
command is similar to the following text:
      "$TDI_JAVA_PROGRAM" -Xms256M -Xmx1024M $TDI_MIXEDMODE_FLAG -Xnojit -cp 
"$TDI_HOME_DIR/IDILoader.jar" "$LOG_4J" com.ibm.di.loader.ServerLauncher "$@" &
      

      

      • 

    • Windows: ibmdisrv.bat
      After
you add the new arguments, the Java invocation
command is similar to the following text: 
      "%TDI_JAVA_PROGRAM%" -Xms256M -Xmx1024M -Xnojit -classpath "%TDI_HOME_DIR%\IDILoader.jar" 
%ENV_VARIABLES% com.ibm.di.loader.IDILoader com.ibm.di.server.RS %*"  
      

      

      • 

    

    4. 

  4. (AIX or Linux only.) Ensure that there is a localhost
entry in the /etc/hosts file. For
example:
    127.0.0.1    localhost
    

    5. 





Related tasks:





Introduction to IBM Tivoli Directory Integrator


IBM Connections uses IBM Tivoli Directory Integrator to transform, move, and synchronize
data from your LDAP directories to the Profiles database.


AssemblyLines
The main tool within Tivoli Directory Integrator is the AssemblyLine. An AssemblyLine processes
data such as entries, records, items, and objects from an LDAP directory,
transforms it, and outputs it to the Profiles database. When you import
data from multiple LDAP directories, the AssemblyLine processes, transforms,
and combines all the source data before outputting it.


How data
is organized can differ greatly from system to system. For example,
databases usually store information in records with a fixed number
of fields. Directories usually work with variable objects called entries,
and other systems use messages or key-value pairs. 




Connectors
Connectors are the components
that you need to build an AssemblyLine. Connectors are designed so
that you do not need to deal with the technical details of working
with various data stores, systems, services, or transports. Each type
of connector uses a specific protocol or API to handle the details
of data source access. You can create your own connectors to support
different functions or use the connectors that are provided with IBM Connections.


For more
information about creating connectors, see the Developing custom Tivoli Directory Integrator assembly
lines for Profiles topic.




work Entries
Tivoli Directory Integrator collects and stores
all types of information in a Java data container called a work Entry. The data values are kept in
objects called Attributes that the work Entry holds and manages. AssemblyLine
components process the information in the work Entry by joining in
additional data, verifying content, computing new attributes and values,
as well as changing existing ones, until the data is ready for delivery
to the Profiles database. 


Tivoli Directory Integrator internal attribute mapping, business
rules, and transformation logic do not need to deal with type conflicts. 




Attribute mapping
Attribute Maps are your
instructions on which attributes are brought into the AssemblyLine
during input, or included in output operations. An AssemblyLine is
designed and optimized for working with one item at a time, such as
one data record, one directory entry or one registry key. If you want
to perform multiple updates or multiple deletes, then you must write
AssemblyLine scripts.










Adding source data to the Profiles database


Populate the Profiles database with information from the
source server by using the Profiles population wizard or by populating
the database manually.


About this task
The Profiles population wizard provides an interface to
make it easier for you to populate the Profiles database with information
from your LDAP directory. Alternatively, if you do not want to use
the wizard, you can populate the database manually by manually updating
the profiles_tdi.properties file in the TDI directory.
Note: Although
LDAP is the default source, and the only source supported by the Profiles
population wizard, other sources are available if you are manually
populating the Profiles database. See Manually populating the
Profiles database for more information.


Note: You can
create custom TDI connectors to add, update, and synchronize your
source data and Profiles database content. See topics such as Developing
custom Tivoli Directory Integrator assembly lines for Profiles and Using
the ProfileConnector for more information.






Procedure
To populate the Profiles database with information from
the LDAP server, do one of the following:
  • Run the Profiles population wizard on the server where Tivoli Directory Integrator is
installed. For more information, see Using the Profiles population
wizard.
    • 

  • Populate the Profiles database manually by updating the property
values relevant to your configuration in the profiles_tdi.properties file.
For more information, see Manually populating the Profiles database.
    • 







Related concepts:





Using the Profiles population wizard


Use the Profiles population wizard to populate the IBM Connections Profiles database
with data from the LDAP directory.


Before you begin
You can populate the Profiles database with the help of
the population wizard, as described here, or manually as described
in the Manually populating the Profiles database topic.
You might choose to use the population wizard to simplify the properties
mapping process from your source to the target Profiles database.


Ensure
that you have created a Profiles database, and installed and configured Tivoli Directory Integrator and
an LDAP directory.
Notes: 
  • Run the population wizard on the system where Tivoli Directory Integrator is installed. 
    • 

  • If you need to configure multiple systems with Profiles data,
you can run the wizard in silent mode. For more information, see the Using
the Profiles population wizard in silent mode topic.
    • 

  • The population wizard populates only those entries where the value
for surname is not null.
    • 

  • You can run the population wizard before, during, or after installing IBM Connections.
    • 







Note: Additional
and related information about configuration and mapping properties
may be available in the Manually populating the Profiles database topic.




About this task
To populate the Profiles database, complete the following
steps:


Procedure
  1. Log into the system where Tivoli Directory
Integrator is installed as the root user or system administrator.
    2. 

  2. (AIX and Linux only): Grant display authority to all users
by running the following commands under the root user or system administrator:  
    xhost + // Grant display authority to other users
    

    Note: If
granting display authority to all users is a security concern for
you, change the command to grant display authority to a specific user
or users. For more information about this command, consult your AIX
or Linux administrator guide.
    echo $DISPLAY // Echo the value of DISPLAY under the root user
    

    

    3. 

  3. Copy the Wizards directory from the IBM Connections installation media to the system
where Tivoli Directory Integrator
is installed. 
    Important: Microsoft Windows:
If you are installing from disk or ISO, change the permissions for
the Wizards folder from Read Only to Write or the population wizard
will fail. 
    

    4. 

  4. Run the following script from the Wizards directory:
    • AIX: ./populationWizard.sh
      • 

    • Linux: ./populationWizard.sh
      Note: If
the wizard does not run correctly, you might need to edit the populationWizard.sh file
and enter the correct JRE/JVM path for your system The populationWizard.sh file
expects the path to be jvm/linux/jre/bin.
      

      • 

    • Microsoft Windows: populationWizard.bat 
      • 

    

    5. 

  5. On the Welcome page of the wizard, click Launch
Information Center to open the IBM Connections Information Center in a browser
window. Click Next to continue.
    6. 

  6. Select Default settings or, if you
are resuming an earlier session, click Last successful
default settings and click Next.  
    Note: This page is shown only if you have already used the wizard
to populate the Profiles database.
    

    7. 

  7. Enter the location of Tivoli Directory
Integrator and then click Next.  
    Note: This
page is shown only if the wizard cannot automatically detect your Tivoli Directory Integrator directory.
    

    8. 

  8. Select a database type and click Next. 
    9. 

  9. Enter the following information about the database, and
then click Next: 
    Host name
    

    The name of the system that hosts the database.
    

    Port
    

    The communications port for connecting to the database. Add a
new port number or choose one of the following default port numbers: 
    DB2
    

    50000
    

    Oracle
    

    1521
    

    SQL Server
    

    1433
    

    

    

    Database name
    

    The default name of the database is PEOPLEDB.
    Note: There is no
default name for the Oracle database, Instead, enter the name of the
database instance.
    

    

    JDBC driver library path
    

    Enter the path to the JDBC driver on the host machine. For example: IBM/sqllib/java.
    DB2
    

    You can find the db2jcc.jar and db2jcc_license_cu.jar files
in the IBM/DB2/v9.7/SQLLIB/java directory. 
    

    Oracle
    

    You can find the ojdbc6.jar file in the oracle/product/11.2.0/db_1/jdbc/lib directory.
    

    SQL Server
    

    Download the SQL Server JDBC 2 driver from the Microsoft web site and follow the instructions
to extract the driver files. IBM Connections
uses the sqljdbc4.jar file. 
    

    

    

    User ID 
    

    Enter your user ID. This must be a database user who has write
access to the Profiles database. For DB2,
the default value is LCUSER. For Oracle and SQL Server, default value
is PROFUSER. These user names are automatically created when you create
the database.
    

    Password 
    

    Enter your password.
    

    

    10. 

  10. Enter the following properties for the LDAP server, and
then click Next:  
    LDAP server name 
    

    The host name or IP address of the LDAP server.
    

    LDAP server port
    

    The default port is 389. If SSL is selected, the default port
is 636.
    

    Use SSL communication
    

    Select the check box to enable SSL.
    

    

    11. 

  11. (Optional) Create an empty truststore file where you can
store trusted LDAP server certificates. (Complete this step if you
want to use SSL. If you already have a truststore file that contains
your LDAP server certificates, you can skip this step.) The Profiles
population wizard downloads the LDAP server certificates from your
LDAP directory for you.
    1. Start the iKeyman utility by running the following file: 
      • AIX or Linux:TDI_Install_directory/jvm/jre/bin/./ikeyman 
        • 

      • Windows: TDI_Install_directory\jvm\jre\bin\ikeyman.exe
        • 

      

      where TDI_Install_directory is the directory
where Tivoli Directory Integrator
is installed.
      

      Note: On the Windows 7
and Windows 2008 operating
systems, right-click ikeyman.exe and select Run
as administrator.
      

      2. 

    2. Click Key Database File from
the menu bar and then click New.
      3. 

    3. Select JKS or PKCS12 as
the key database type.
      4. 

    4. Save the new file to an appropriate location and click OK.
      5. 

    5. Enter a password in the Password Prompt dialog
box and then confirm the password. Click OK.  
      Note: You need this password when you use the Profiles population
wizard.
      

      6. 

    6. Exit the iKeyman utility. 
      7. 

    
 The Profiles population wizard can use the new truststore
file to communicate with your LDAP server in SSL handshaking mode.
It can also use the file when fetching data from your LDAP.
    12. 

  12. Optional: If you selected SSL when you entered
the LDAP properties, you are asked to enter the following keystore
properties:  
    Truststore file 
    

    File where trusted server certificates are stored. Used when SSL
handshaking is performed.
    

    Keystore password 
    

    Password to access the keystore.
    

    Keystore type
    

    Format of the trusted server certificate. Currently only JKS and
PKCS12 are supported in Java.
    

    

    If the LDAP server certificate is not in the truststore,
an Accept permanently message appears that
asks you to permanently accept the certificate in the truststore file.
If you do not accept it, the wizard cannot connect to the LDAP server
with SSL and will not continue with the population task.
    

    Note: Ensure
that the global.properties file in Tivoli Directory Integrator (TDI) is configured
with the file trust store name, password and type you just created.
See the Tivoli Directory
Administrator’s Guide for Client SSL Configuration of TDI Components for
further instructions. The Understanding IBM Tivoli Directory Integrator for IBM Connections white paper
is also helpful.
    

    Note: Oracle 10gR2 is supplied with the ojdbc14.jar JDBC
driver while Oracle 11gR2 is supplied with ojdbc6.jar.
    

    13. 

  13. Enter the authentication details for the Bind
distinguished name (DN) and Bind password,
and then click Next. 
    Note: The Profiles
population wizard does not support anonymous binding for LDAP. If
you wish to populate the Profiles database using anonymous binding,
you must populate the database manually.
    

    14. 

  14. Enter the details of the Base distinguished
name (LDAP user search base) and LDAP user
search filter, and then click Next. 
    15. 

  15. Map LDAP attributes or JS
Functions to the Profiles database fields. For more information about each attribute and function, see Table 134 in the Mapping fields manually topic.
    Notes: 
    • For each user in the LDAP, Tivoli Directory
Integrator will create a row in the database, mapping each LDAP attribute
or JavaScript function
to the corresponding column in the database. The wizard automatically
validates each mapping. If you need to change the default mapping,
select the required LDAP attributes or JavaScript functions and create or modify
the field.
      • 

    • The uid, guid, dn, surname,
and displayName attributes are always required.
      • 

    • You can use the Group By filter in Metrics
to categorize the metrics report by a particular user attribute. To
do so, ensure correct mapping between the LDAP attribute and the Profiles
database field. Metrics defines the Group By attributes
by default as country, organization and title.
See the Metrics documentation for more information.
      • 

    

    

    16. 

  16. Optional: You can choose to run the following
additional tasks: 
    Countries
    

    Add country data to each profile.
    

    Departments
    

    Add department data to each profile.
    

    Organizations
    

    Add organization data to each profile.
    

    Employee types
    

    Add employee-type data to each profile.
    

    Work locations
    

    Add location data to each profile.
    

    
Select Yes if you want to mark
the profiles of each manager. 
    Notes: 
    • For all the entries in this list (except Mark managers),
you need to prepare corresponding CSV files with the required information.
An Employee Type CSV file might include regular=IBM Employee and 
manager=IBM Manager. You can edit the profiles-config.xml file
to specify whether you want to display the code or the value, where regular or manager are
the employee type codes stored in LDAP and IBM Employee or IBM Manager are the values.
      • 

    • Examine the CSV files in the Wizards/TDIPopulation/TDISOL/OS/samples directory,
where OS is your operating system, to see the input
file format of the optional tasks:
      Countries task
      

      isocc_sample.csv 
      

      Departments task
      

      deptinfo_sample.csv
      

      Organizations task
      

      orginfo_sample.csv
      

      Employee types task
      

      emptype_sample.csv
      

      Work locations task
      

      workloc_sample.csv
      

      

      • 

    

    

    17. 

  17. Review the Summary page to ensure that the information
you entered in the previous panels is correct. To make changes, click Back to
return to the relevant page and edit the information. Otherwise, click Configure to
begin populating the database.
    18. 

  18. Review the message on the Result page. If necessary, click View
log to examine the log in detail. Click Finish to
exit the wizard.
    19. 



Results
The Profiles population wizard has populated the Profiles
database with data from your LDAP directory.






Using the Profiles population wizard in silent mode


You can run the Profiles population wizard in silent mode
to populate the Profiles database. 


Before you begin
When you run the Profiles population wizard in silent mode,
it creates the map_dbrepos_from_source.properties file,
located in the Wizards\TDIPopulation\platform\TDI directory,
and updates this file with data from the mappings.properties file.


Note: When you use the Profiles
population wizard in interactive mode, the wizard creates a response
file called tdisettings.properties in the Wizards\TDIPopulation directory
in the Wizards\TDIPopulation directory. You can
modify the existing response file or create a new one. It also creates
a mappings.properties file, which contains properties
very similar to those in map_dbrepos_from_source.properties file.


If you need to configure multiple systems with Profiles
data, you can run the wizard in silent mode.


You can also modify
the mappings files manually. For more information, see the Mapping
fields manually topic.


Note: 
  • (AIX only) If you are downloading the wizard, the TAR program available
by default with AIX does not
handle path lengths longer than 100 characters. To overcome this restriction,
use the GNU file archiving program instead. This program is an open
source package that IBM distributes
through the AIX Toolbox for Linux Applications at the IBM AIX Toolbox web site. Download
and install the GNU-compatible TAR package. You do not need to install
the RPM Package Manager because it is provided with AIX. 
    

    After you have installed the GNU-compatible
TAR program, change to the directory where you downloaded the IBM Connections TAR file, and enter
the following command to extract the files from it:
    

    gtar -xvf Lotus_Connections_wizard_aix.tar
    

    This command creates a directory named after the wizard. 
    

    • 







About this task
To run the Profiles population wizard in silent mode,
complete the following steps:




Procedure
  1. Log in to your
database server as the root user or system administrator.
    2. 

  2. (AIX and Linux only) Grant display authority to all
users by running the following commands under the root user or system
administrator:	 
    xhost +	// Grant display
authority to other users
    Note: If granting display authority
to all users is a security concern for you, change the command to
grant display authority to a specific user or users. For more information
about this command, consult your AIX or Linux administrator
guide.
    

    

    echo $DISPLAY // Echo the value of
DISPLAY under the root user
    

    3. 

  3. Ensure that the Profiles population wizard has created
the tdisettings.properties response file in the TDIPopulation directory.
    4. 

  4. Open a command prompt, change to the TDIPopulation directory,
and enter the following commands to launch the wizard in silent mode:
    • AIX/Linux:
      • populationWizard.sh -silent response_file
        

        [
-mappingFile mapping_file] 
        

        [
-dbPassword db_password] 
        

        [
-ldapPassword ldap_password] 
        

        [
-sslPassword ssl_password]
        

        [
-help | -? | /help | /? | -usage]
        

        • 

      

      • 

    • Windows:
      • populationWizard.bat -silent response_file
        

        [
-mappingFile mapping_file] 
        

        [
-dbPassword db_password] 
        

        [
-ldapPassword ldap_password] 
        

        [
-sslPassword ssl_password]
        

        [
-help | -? | /help | /? | -usage]
        

        • 

      

      • 

    
 
    where response_file is the full path to
the tdisettings.properties response file, mapping_file is
the full path to the mappings.properties file, dbPassword is
the password for the Profiles database, ldapPassword is
the password for bind user in the LDAP directory, and sslPassword is
the password for the SSL key store.
    

    Note: 
    If you do not specify
a mapping file, the default mapping file for your LDAP directory type
is used. These mapping files are located in the Wizards/TDIPopulation directory,
where you can edit the file for your LDAP directory type. For more
information about editing the mapping file, see the Mapping
fields manually topic. The following table lists the mappings
files for applicable LDAP directory types:
    Table 15. Options to
specify a supported LDAP directory
    Directory type
Mapping file

    
    

    IBM Lotus Domino
defaultMapping_domino.properties

    

    IBM Tivoli Directory Server
defaultMapping_tivoli.properties

    

    Microsoft Active
Directory Application Mode
defaultMapping_adam.properties

    

    Microsoft Windows Server 2003 Active Directory
defaultMapping_ad.properties

    

    Novell Directory Services
defaultMapping_nds.properties

    

    Sun ONE
defaultMapping_sun.properties

    
    

    

    

    

    
 The parameters for running the population
wizard in silent mode are described in the following table:
    Table 16. Command parameters
    Parameter
Value
Description

    
    

    responseFile (required)
full path to the tdisettings.properties response
file
After running the population wizard successfully,
the tdisettings.properties response file is stored
in the Wizards\TDIPopulation directory in the IBM Connections set-up directory.

    

    mappingFile (optional)
full path to the mappings.properties file
The mappings.properties file is
stored in the Wizards\TDIPopulation directory
in the IBM Connections set-up
directory. If you do not use specify a different file with the -mappingFile parameter,
the wizard uses this file to map properties to the LDAP directory.

    

    dbPassword (optional)
Database password
Overwrites the database password in the response
file. If you do not specify the database password here, you must specify
it in the response file.

    

    ldapPassword (optional)
LDAP password
Overwrites the LDAP password in the response
file. If you do not specify the LDAP password here, you must specify
it in the response file.

    

    sslPassword (optional)
SSL key store password
Overwrites the SSL key store password in the
response file. If you do not specify the SSL password here, you must
specify it in the response file.

    
    

    

    

    5. 



Results
After the wizard has finished, check the log file in the <user
home>/lcwizard/log/tdi/ directory for messages. The log
file name uses the time as a suffix. For example: tdi_20090912_163536.log. 




The tdisettings.properties file


When you run the Profiles population wizard, you can record
your selections in two response files: a tdisettings.properties file
and a mapping file. 


After running the Profiles population wizard in interactive
mode, you can repeat the same configuration in silent mode by starting
the wizard from the command line and passing the response files in
as an argument. The wizard uses the values in the response files rather
than requiring you to interact with it.




The tdisettings.properties file collects
the values that are described in the following table. 


Table 17. Common properties of the tdisettings.properties file
Property
Description
Value




db.hostname
Host name of the database server.
 



db.jdbcdriver
Location of the JDBC driver.
Example: C\:\\IBM\\SQLLIB\\java
Note: The
extra "\" symbol is an escape character.





db.name
Name of the Profiles database.
Default: PEOPLEDB



db.password
Password for connecting to the database.
The property is required if you do not specify -dbPassword as a command
parameter.

  • DB2 default: 50000 
    • 

  • Oracle default: 1521
    • 

  • SQL Server default: 1433
    • 






db.port
Database server port for invoking JDBC.

  • DB2 default: 50000 
    • 

  • Oracle default: 1521
    • 

  • SQL Server default: 1433
    • 






db.type
DB2,
Oracle, or SQL Server.
db2 | oracle | sqlserver



db.user
Name of the database user, such as lcuser.
Example: lcuser



ldap.dn.base
LDAP distinguished name search base.
Example: dc=example, dc=com



ldap.enable.ssl
Boolean value that determines if SSL is
enabled. If the value of this property is yes, you must also provide
values for the ssl.keystore, ssl.password, and ssl.type properties.

yes | no





ldap.filter
Filter for the LDAP.
Example: (&(uid=*)(objectclass=inetOrgPerson)) 



ldap.hostname
Host name of the LDAP server.
 



ldap.password
Password for connecting to the LDAP directory. 
Default: 389 or 663 (SSL)



ldap.port
Communications port of the LDAP server.
Default: 389 or 663 (SSL)



ldap.user
Distinguished name of the LDAP administrative
user.
 



ssl.keyStore
File path to the keystore. Required only
if the ldap.enable.ssl property is set to yes.
 



ssl.password
SSL password. Required only if the ldap.enable.ssl
property is set to yes.
 



ssl.type
SSL standard. Required only if the ldap.enable.ssl
property is set to yes.
JKS | PKCS12



task.list
Tasks that the Profiles population wizard
can perform. You can choose from the following options: LDAP_OPTIONAL_TASK_MARK_MANAGER,
LDAP_OPTIONAL_TASK_FILL_COUNTRIES, LDAP_OPTIONAL_TASK_FILL_DEPARTMENT,
LDAP_OPTIONAL_TASK_FILL_ORGANIZATION, LDAP_OPTIONAL_TASK_FILL_EMPLOYEE,
and LDAP_OPTIONAL_TASK_FILL_WORK_LOCATION
To execute
multiple tasks, separate the tasks with the comma symbol.


Example: LDAP_OPTIONAL_TASK_MARK _MANAGER,LDAP_OPTIONAL
_TASK_FILL_COUNTRIES



task.country.csv
File path to the isocc.csv file.
Required if you specify LDAP_OPTIONAL_TASK_FILL_COUNTRIES in the task.list
property.
Example: C\:\\build\\isocc.csv
Note: The
extra "\" symbol is an escape character.





task.department.csv
File path to the deptinfo.csv file.
Required if you specify LDAP_OPTIONAL_TASK_FILL_DEPARTMENT in the
task.list property.
Example: C\:\\build\\deptinfo.csv
Note: The
extra "\" symbol is an escape character.





task.empoyeetype.csv 
File path to the emptype.csv file.
Required if you specify LDAP_OPTIONAL_TASK_FILL_EMPLOYEE in the task.list
property.
Example: C\:\\build\\emptype.csv
Note: The
extra "\" symbol is an escape character.





task.organization.csv
File path to the orginfo.csv file.
Required if you specify LDAP_OPTIONAL_TASK_FILL_ORGANIZATION in the
task.list property.
Example: C\:\\build\\orginfo.csv
Note: The
extra "\" symbol is an escape character.





task.worklocation.csv
File path to the workloc.csv file.
Required if you specify LDAP_OPTIONAL_TASK_FILL_ORGANIZATION in the
task.list property.
Example: C\:\\build\\workloc.csv
Note: The
extra "\" symbol is an escape character.





TDI.dir
Installation location of Tivoli Directory Integrator.
Example: C\:\\IBM\\TDI\\V7.1
Note: The
extra "\" symbol is an escape character.










Note: For more information about using CSV files to provide
additional data for Profiles, see the Supplemental user data
for Profiles topic. For information about TDI properties, see Tivoli
Directory Integrator solution properties for Profiles.










Manually populating the Profiles database


Instead of using the Profiles population wizard, you can
manually populate the database.


Before you begin
You can populate the Profiles database manually, as described
here, or with the help of the population wizard as described in the Using
the Profiles population wizard topic. You might choose to manually
populate the database to take advantage of functionality not provided
by the wizard, such as anonymous LDAP access, large data sets, and
property configuration other than what is provided by the wizard,
for example alternate source options. 


Note: Additional and related
information about configuration and mapping properties may be available
in the Using the Profiles population wizard topic.


Before starting
this task, you must complete the steps in the Mapping fields
manually topic. You must set up the mapping file before starting
this task.


(AIX only).
An AIX limitation causes a file
naming error when you extract the tdisol.tar archive.
The system renames the profile-links.xsd to profile-links.xs.
To resolve this issue, use the GNU Tar program, version 1.14 or higher,
to extract the archive. Download the program from ftp://ftp.gnu.org/gnu/tar/ and
install it as the default tar utility in the path. The default location
for GNU Tar is /usr/local/bin. 


The internal name of the Profiles
database is PEOPLEDB.






About this task
After installing the Profiles database and defining mapping
and validation, complete the following steps to populate the Profiles
database:


Procedure
  1. Update the profiles_tdi.properties file
to specify values for the following properties.  
    Note: To locate this file, extract the tdisol.tar|zip file
from the tdisol directory in your IBM Connections installation media. After extraction,
the file is located in the tdisol.tar|zip/tdisol/TDI directory.
    

    The
following list contains properties that you must review. Edit any
property values that require editing for your configuration.
    

    source_ldap_url
    

    Universal resource locator of the LDAP directory. Enables programs
to access the LDAP directory.  Use the following syntax to specify
the value:
     source_ldap_url=ldap://myldap.enterprise.example.com:389 
    

    

    source_ldap_user_login
    

    If you cannot use Anonymous search, a user login name is required
. Use the following syntax to specify the value:
    source_ldap_user_login=uid=wpsbind,cn=users,l=Bedford Falls,
st=New York,c=US,ou=Enterprise,o=Sales Division,dc=example,dc=com
    

    

    source_ldap_user_password
    

    If you cannot use anonymous search, a user password is required,
along with user login name. Use the following syntax to specify the
value:
    {protect}-source_ldap_user_password=wpsbind  
    

    Note: Tivoli Directory Integrator automatically
encrypts any properties which have the {protect} prefix. If you do
not want to encrypt these properties, remove the {protect} prefix.
    

    

    source_ldap_search_base
    

    A portion of the LDAP DN that must be part of all entries processed.
This base usually contains the expected organization (o) value, such
as source_ldap_search_base=o=ibm.com. Use the following
syntax to specify the value:
    source_ldap_search_base=l=Bedford Falls,st=New York,c=US,
ou=Enterprise,o=Sales Division,dc=example,dc=com   
    
   
    

    source_ldap_search_filter
    

    A search filter to further refine the entries used. A typical
value might be source_ldap_search_filter=cn=*. Use
the following syntax to specify the value:
    source_ldap_search_filter=(&(uid=*)(objectclass=inetOrgPerson))   
    

    

    source_ldap_use_ssl
    

    Required only if you are using SSL to authenticate. Specifies
whether to use Secure Sockets Layer for the connection. Options are true or false.
    

    dbrepos_jdbc_driver
    

    JDBC driver used to access the Profiles database repository. The
default value of the properties file references the DB2 database provided with Profiles as follows:
    dbrepos_jdbc_driver=com.ibm.db2.jcc.DB2Driver
    
If you are using DB2,
you do not need to modify this value. If you are using an Oracle database,
change the value to reference an Oracle database. The following values
are examples:
    dbrepos_jdbc_driver=oracle.jdbc.driver.OracleDriver
    

    dbrepos_jdbc_driver=oracle.jdbc.pool.OracleConnectionPoolDataSource
    
If
you are using SQL Server, change the value to reference the SQL Server
database. The following value is an example:
    com.microsoft.sqlserver.jdbc.SQLServerDriver
    

    

    dbrepos_jdbc_url
    

    Universal resource locator of the database that you created. This
value specifies the peopledb database, and must include the port number.
For example:
    • DB2:
       jdbc:db2://localhost:50000/peopledb
      

      • 

    • Oracle:
      jdbc:oracle:thin:@localhost:1521:PEOPLEDB
      

      • 

    • SQL Server:
      jdbc:sqlserver://enterprise.example.com:1433;DatabaseName=PEOPLEDB
      

      • 

    
.
    

    dbrepos_username
    

    The user name used to authenticate to the database that you created.
Use the following syntax to specify the value:
    dbrepos_username=<db_admin_id>   
    

    

     dbrepos_password
    

     The password used to authenticate to the database that you created.
Use the following syntax to specify the value:
    {protect}-dbrepos_password=act1vities   
    

    

    

    You can provide values for additional properties
if necessary, see Tivoli Directory Integrator solution properties
for Profiles for details.
    

    2. 

  2. Ensure that you have completed the steps in the Mapping
fields manually task. You must complete the mapping task before
continuing.
    3. 

  3. Run the ./collect_dns.sh or collect_dns.bat script
to create a file containing the distinguished names (DNs) to be processed
from the source LDAP directory.  
    Note: Before
starting the script, ensure that you have completed the steps in the Mapping
fields manually task.
    

    Note: If the script does not run,
you might need to enable its Executable attribute by running the chmod command
first. The Executable attribute of a script can become disabled after
the script is copied from a read-only medium such as DVD.
    
 
    The new file is named collect.dns by
default but you can rename it if necessary. If you change the file
name, update the source_ldap_collect_dns_file parameter
in the profiles_tdi.properties file.
    

    After
the script runs, it creates a log file called ibmdi.log in
the tdisol.tar|zip/tdisol/TDI directory.
Examine this file to find out whether any errors occurred during the
process.
    

    4. 

  4. Populate the database repository from the source LDAP directory
by running the ./populate_from_dn_file.sh or populate_from_dn_file.bat script. 
    Depending on how many records you are processing, this step
could take many hours. For example, 5,000 records might take a few
minutes, while half a million records could take over 12 hours. Tivoli Database Integrator prints
a message to the screen after every 1,000 iterations to inform you
of its progress.
    

    Note: If a failure occurs during processing, such
as loss of the network connection to the LDAP directory server, start
processing the names from where it was interrupted. Examine the PopulateDBFromDNFile.log file
in the logs subdirectory to find out which distinguished name was
last successfully processed. The ibmdi.log file
also tracks the tasks that you run. Edit the collect.dns file
to remove all entries up to and including the last successfully processed
entry. Start the task again. You can repeat this step as many times
as necessary until all the distinguished names are processed.
    

    5. 

  5. Optional: If you are setting the PROF_IS_MANAGER field
based on PROF_MANAGER_UID references in other employee
records, run the ./mark_managers.sh or mark_managers.bat script. 
    For more information, see Configuring the Manager designation
in user profiles for details.
    

    Note: Manager identification
is not performed as part of the previous record population step because
it must run across all the records and it is possible that the initial
record population step does not complete in a single pass for large
organizations. 
    

    Note: If the manager designation was not part
of the source records for your data set, you can run this task to
analyze all the records after population. This task will take each
user record and see if it is referenced as the manager for any other
users. If yes, the user will be marked as a manager.  If not, the
user will be marked as not a manager.  If you need to use this process
to set this profile attribute, you will also need to run it periodically
to perform updates. For more information, see Synchronizing
user data between Profiles and the LDAP directory.
    

    

    6. 

  6. Optional: Run additional and optional scripts
to populate additional fields. For example, run the ./fill_country.sh or fill_country.bat script
to populate the Country table from the isocc.csv file. 
    For more information, see Supplemental user data for
Profiles.
    

    7. 





Related reference:





Tivoli Directory Integrator solution properties for Profiles


IBM Connections maps
LDAP, database, and other properties with Tivoli Directory Integrator configuration
parameters. 


The properties described in this topic are found in the
supplied profiles_tdi.properties file.


The TDI
parameter column in the tables contains the name of the
parameter in the LDAP connector.  See the Tivoli Directory Integrator product documentation for
more information. 


You can find additional information about
LDAP properties at ibm.com® and
other sites. 


Note: All
file paths specified are relative to the TDI solution directory.




The following properties are associated in an LDAP directory
that will be used as the source for the data. If you wish to use a
source other than LDAP, see Manually populating the Profiles
database.


Table 18. LDAP Properties
Property 
TDI parameter
Definition




source_ldap_url
LDAP URL hostname and LDAP URL Port

Required.


The LDAP web address used
to access the source LDAP system. The port is required and is typically
389 for non-SSL connections. 


Express this value in the form
of ldap://host:port. For example: ldap://myservername.com:389.


If
using the population wizard, this property is configured using the LDAP
server name and LDAP server port on
the LDAP server connection page.


Note: The LDAP query constructed
from the source URL, search base, and search filter are stored in
a source url property, which can be used to segment the Profiles database
user set during synchronization. Using different values for this property,
which may be equivalent (for example referencing the LDAP server by
IP address or DNS name) is not advised.


The default value
is ldap://localhost:389.





source_ldap_use_ssl
LDAP URL Use SSL connection

Required if you are using SSL to authenticate. 


Set
to either true or false. 


Set to true if you are using SSL (for
example if you are using port 636 in the LDAP URL). 


The default
value is false.


If using the population wizard, this property
is configured with the Use SSL communication checkbox
on the LDAP server connection page.





source_ldap_user_login
Login user name

Login user name used for authentication.
You can leave this blank if no authentication is required.


If
using the population wizard, this property is configured in the Bind
distinguished name (DN) field on the LDAP authentication
properties page.





source_ldap_user_password
Login password

Login password used for authentication. Leave
this blank if no authentication is required. The value will be encrypted
in the file the next time it is loaded.


If using the population
wizard, this property is configured in the Bind password field
on the LDAP authentication properties page.





source_ldap_search_base or source_ldap_user_search_base
Search Base

The search base (the location from where
the search begins) of the iterating directory. The search begins at
this point in the ldap directory structure and searches all records
underneath. This should be a distinguished name. 
Note: Most directories
require a search base, and as such it must be a valid distinguished
name. Some directory services allow you to specify a blank string
which defaults to whatever the server is configured to do.




A
default value is not specified.


If using the population wizard,
this property is configured in the LDAP user search base field
on the LDAP page. 





source_ldap_search_filter or source_ldap_user_search_filter
Search Filter

Search filter used when iterating the directory.


 This
determines which objects are included or excluded in the search. If
using the search base and the specified search filter properties do
not allow you to adequately construct your search set, use the source_ldap_required_dn_regex property.


Note: Search
filters are used by those directories to select entries from which
data is retrieved from a search operation. Care should be taken when
specifying search filters as they can affect performance of the directory
being searched. The directory server schema being queried can impact
performance. 


A default value is not specified.


If
using the population wizard, this is the LDAP user search
filter field on the LDAP authentication properties page.





source_ldap_sort_page_size
Page size

If specified, the LDAP Connector tries to
use paged mode search. Paged mode causes the directory server to return
a specific number of entries (called pages) instead of all entries
in one chunk. Not all directory servers support this option. The default
value is 0, which indicates that paged mode is disabled. 


The
default value is 0.


This parameter is not configurable when
using the population wizard. 





 
 
 



source_ldap_authentication_method
Authentication Method

Options include the following:


Anonymous


This method provides minimal security.


Simple


This method uses a login user name and password to authenticate.
It is treated as anonymous if no user name and password are provided.


CRAM-MD5


Challenge/Response Authentication Mechanism using Message Digest
5. This method provides reasonable security against various attacks,
including replay.


SASL


Simple Authentication and Security Layer. This method adds authentication
support to connection-based protocols. Specify parameters for this
type of authentication using the Extra Provider Parameters option.




This parameter is not configurable when using the
population wizard.





source_ldap_collect_dns_file
 

Name of the file used to collect distinguished
names (DNs) by the collect_dns.bat/sh process
from the source, and then used during population by the populate_from_dn_file.bat/sh processes
to look up entries to add to the database repository. 


This
file can also be constructed by hand to populate an explicit set of
users.


The default value is collect.dns.


This
parameter is not configurable when using the population wizard.





source_ldap_escape_dns
 

Indicates that special characters have not
been escaped properly and identifies them so the processor can find
those characters and escape them. Special characters are:


  • , (comma)
    • 

  • = (equals)
    • 

  • + (plus)
    • 

  • < (less than)
    • 

  • > (greater than)
    • 

  • # (number sign)
    • 

  • ; (semicolon)
    • 

  • \ (backslash)
    • 

  • " (quotation mark)
    • 



The backslash is used to escape special characters. A plus
sign is represented by \+ and a backslash is represented
by \\. 


if your distinguished names contains
these special characters and you receive errors when running the collect_dns/populate_from_dn_file
process, set this property to true so that the characters
are escaped.


The default value is false.


This parameter
is not configurable when using the population wizard.





source_ldap_required_dn_regex
 

Allows a regular expression to be used to
limit the distinguished names (DNs) which are processed by providing
a regular expression which must be matched. If the regular expression
is not matched, that particular record is skipped. Although the search
filter property gives some flexibility, in case this is not sufficient,
you can use a more powerful regular expression.


A default value
is not specified.


This parameter is not configurable when using
the population wizard.





source_ldap_sort_attribute
Sort Attribute

Specifies server-side sorting. This parameter
instructs the LDAP server to sort entries matching the search base
on the specified field name. Server-side sorting is an LDAP extension.
The iterating directory must be able to support this sorting extension. 


A
default value is not specified.


This parameter is not configurable
when using the population wizard.





source_ldap_iterate_with_filter
 

This property 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 iteration 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.


This parameter is not configurable
when using the population wizard.


The default value is false.





source_ldap_binary_attributes
Binary Attributes

By default, this property is set internally
to GUID, objectGUID, objectSid, sourceObjectGUID. Any additional values
specified in the property are appended to the list. 


This parameter
is not configurable when using the population wizard.


The default
value is GUID.





source_ldap_time_limit_seconds
Time Limit

Specifies the maximum number of seconds that
can be used when searching for entries; 0 = no limit.


This parameter
is not configurable when using the population wizard.


The default
value is 0.





source_ldap_map_functions_file
 

Specifies the location of any referenced
function mappings.


When using the population wizard, the functions
shown in the mapping dialog are read from and written to this file.


The
default value is profiles_functions.js.





source_ldap_logfile
 

In addition to the standard logs/ibmdi.log file,
output from the populate_from_dn_file.bat or populate_from_dn_file.sh task
is written to this file.


This parameter is not configurable
when using the population wizard.


The default value is logs/PopulateDBFromSource.log.





source_ldap_compute_function_for_givenName
 

Connections allows Javascript functions for
setting values of common LDAP fields such as cn, sn, givenName to
execute before Connections performs its mapping. For example, sn and/or givenName can
be parsed from cn (common name).


This parameter
is not configurable when using the population wizard.


A default
value is not specified.





source_ldap_compute_function_for_sn
 

Connections allows Javascript functions for
setting values of common LDAP fields such as cn, sn, givenName to
execute before Connections performs its mapping. For example, sn and/or givenName can
be parsed from cn (common name).


This parameter
is not configurable when using the population wizard.


A default
value is not specified.





source_ldap_collect_updates_file
 

This property is no longer used.





source_ldap_manager_lookup_field
 

This property is no longer used.





source_ldap_secretary_lookup_field
 

This property is no longer used.










Many
properties in the TDI LDAP connector are not mapped to Profiles TDI
properties. To configure properties other than those listed here,
consider using an alternate source repository and creating your own
specialized configuration. Use the LDAP iterator and connectors provided
with the TDI solution directory as a starting point, see Using
a custom source repository connector for more information.


The
following properties are associated with the Profiles database repository.
Note: The
following properties must be set in the profiles_tdi.properties file,
even if developing your own assembly lines using the connectors provided
in the Profiles TDI solution directory. These properties are not configured
in the Connector panels, but rather in the profiles_tdi.properties file.
See Developing custom Tivoli Directory Integrator assembly lines for
Profiles for more information.


Table 19. Profiles
Database Properties
Property 
TDI parameter
Definition




dbrepos_jdbc_driver
JDBC Driver

Required.


The JDBC driver implementation
class name used to access the Profiles database repository. 


For
DB2, the default is com.ibm.db2.jcc.DB2Driver. For
example:
dbrepos_jdbc_driver=com.ibm.db2.jcc.DB2Driver




For
Oracle, the default is oracle.jdbc.driver.OracleDriver.
For example:
dbrepos_jdbc_driver=oracle.jdbc.driver.OracleDriver




If
you are using a Microsoft SQL Server database, change the value to
reference a SQL Server driver, for example:
dbrepos_jdbc_driver=com.microsoft.sqlserver.jdbc.SQLServerDriver




This
corresponds to the JDBC driver path in the population wizard. If not
using the wizard, this library must be present in the CLASSPATH of
Tivoli Directory Integrator, or Tivoli Directory Integrator cannot
load the library when initializing the Connector and cannot communicate
with the Relational Database (RDBMS). 


To install a JDBC driver
library so that Tivoli Directory Integrator can use it, copy it into
the TDI_install_dir/jars directory, or a subdirectory
such as TDI_install_dir/jars/local.





dbrepos_jdbc_url
JDBC URL

Required.


JDBC web address used to
access the Profiles database repository. 


You must modify the
hostname portion and port number to reference your server information. 
Note: You
can find this information by accessing the WebSphere Application Server Administration
Console (http://yourhost:9060),
and then selecting Resources > JDBC > Data sources > profiles.

 


The default
syntax is for DB2, unless using the wizard, but the default uses a
local host. If the DB2 is not on the same system as the TDI solution
directory, update the URL with the host name.


If you are using
an Oracle database, use the following syntax: 
dbrepos_jdbc_url=jdbc:oracle:thin:@<host_name>:1521:orcl




 If
you are using a SQL Server database, use the following syntax: 
dbrepos_jdbc_url=jdbc:sqlserver://<host_name>:1433;databaseName=PEOPLEDB







dbrepos_username
User name

Required.


User name under which the
database tables, which are part of the Profiles database repository,
are accessed.





dbrepos_password
Password

Required.


Password associated with
the username under which the database tables, which are part of the
Profiles database repository, are accessed.





dbrepos_mark_manger_if_referenced
 

This property is no longer used.












The following properties are associated with the task
that monitors the Profiles employee draft table for changes and transmits
them through a DSML v2 connector.
Table 20. Change Monitoring
Properties
Property 
TDI parameter
Definition




monitor_changes_dsml_server_authentication
 

Type of authentication used by the DSML server
update requests. Options include the following: 


HTTP basic authentication


A method designed to allow a web browser, or other client program,
to provide credentials, in the form of a user name and password, when
making a request.


Anonymous


This method provides minimal security.







monitor_changes_dsml_server_url
 
Required if you are transmitting
user changes back to the source repository. 
Web address
of the DSML server to which the DSML update requests should be sent.





monitor_changes_dsml_server_username
 
Required if you are transmitting
user changes back to the source repository. 
User name
used for authentication to the DSML server.





monitor_changes_dsml_server_password
 
Required if you are transmitting
user changes back to the source repository. 
Password
used for authentication to DSML server that the DSML update requests
should be sent to.





monitor_changes_map_functions_file
 

Path to the file containing mapping functions
for mapping from a changed database field to a source. for example
LDAP field. This is only needed if changes made to the source based
on database repository field changes are not mapped one-to-one. You
can use the same file you use to map from source to database repository
fields, assuming the functions are named appropriately.





monitor_changes_sleep_interval
 

Polling interval, in seconds, between checks
for additional changes when no changes exist.












The following properties are associated
with the Tivoli Directory
Integrator processing that reads a Tivoli Directory
Server change log and subsequently updates the database repository
with those changes.
Table 21. Tivoli Directory Server Change Log Properties
Property 
TDI parameter
Definition




ad_changelog_ldap_url
 

LDAP web address used to access the LDAP
system that was updated. For example:
ldap://host:port







ad_changelog_ldap_user_login
 

Login user name to use to authenticate with
an LDAP system that has been updated. You can leave this blank if
no authentication is needed.





ad_changelog_ldap_user_password
 

Login user name to use to authenticate with
an LDAP that has been updated. You can leave this blank if no authentication
is needed. The value will be encrypted in the file the next time it
is loaded.





ad_changelog_ldap_search_base
 
 



ad_changelog_ldap_use_ssl
 

Defines whether or not to use SSL in authenticating
with an LDAP system that was updated. The options are true and false.





ad_changelog_timeout
 
 



ad_changelog_sleep_interval
 

Polling interval, in seconds, between checks
for additional changes when no changes exist.





ad_changelog_use_notifications
 

Indicates whether to use changelog notifications
rather than polling. If true, the tds_changelog_sleep_interval is
not applicable since polling is not used. The options are true and
false. 





ad_changelog_ldap_page_size
 
 



ad_changelog_start_at 
 

Change number in the Active Directory changelog
to start at. Typically this is an integer, while the special value
EOD means start at the end of the changelog.





ad_changelog_ldap_required_dn_regex. 
 
 



tds_changelog_ldap_authentication_method
Authentication Method

Authentication method used to connect to
LDAP to read records. Options include the following:


Anonymous


This method provides minimal security.


Simple


This method uses a login user name and password to authenticate.
It is treated as anonymous if no user name and password are provided.


CRAM-MD5


Challenge/Response Authentication Mechanism using Message Digest
5. This method provides reasonable security against various attacks,
including replay.


SASL


Simple Authentication and Security Layer. This method adds authentication
support to connection-based protocols. Specify parameters for this
type of authentication using the Extra Provider Parameters option.







tds_changelog_ldap_changelog_base
ChangelogBase

Changelog base to use when iterating through
the changes. This is typically cn=changelog.





tds_changelog_ldap_time_limit_seconds
Time Limit

Searching for entries must take no more than
this number of seconds; 0 = no limit.





tds_changelog_ldap_url
LDAP URL

LDAP web address used to access the LDAP
system that was updated. For example:
ldap://host:port







tds_changelog_ldap_use_ssl
Use SSL

Defines whether or not to use SSL in authenticating
with an LDAP system that was updated. The options are true and false. 





tds_changelog_ldap_user_login
 Login user name

Login user name to use to authenticate with
an LDAP system that has been updated. You can leave this blank if
no authentication is needed.





tds_changelog_ldap_user_password
Login password

Login user name to use to authenticate with
an LDAP that has been updated. You can leave this blank if no authentication
is needed. The value will be encrypted in the file the next time it
is loaded.





tds_changelog_sleep_interval
 

Polling interval, in seconds, between checks
for additional changes when no changes exist.





tds_changelog_start_at_changenumber
 

Change number in the Tivoli Directory Server changelog to start
at. Typically this is an integer, while the special EOD value means
start at the end of the changelog.





tds_changelog_use_notifications
 

Indicates whether to use changelog notifications
rather than polling. If true, the tds_changelog_sleep_interval is
not applicable since polling is not used. The options are true and
false. 












The following properties are
available in the profiles_tdi.properties file
and are associated with Tivoli Directory
Integrator debug activities. 
Note: The debug properties enable TDI
debugging for an entire assembly. In addition, enabling debug_update_profile which
enables debugging for the commands that use the Profiles Connector,
also enables Java debugging for the following packages. 
  • log4j.logger.com.ibm.lconn.profiles.api.tdi=ALL
    • 

  • log4j.logger.com.ibm.lconn.profiles.internal.service=ALL
    • 

  • log4j.logger.java.sql=ALL
    • 





Note: The following properties are not configurable when
using the population wizard.


Table 22. Tivoli Directory Integrator Debug
and Trace Properties
Property 
TDI parameter
Definition




sync_all_dns
 
For information about sync_all_dns,
see Understanding how the sync_all_dns process works.



debug_managers
 

Flag that instructs TDI to log additional
debug information for the following command(s).


The options
are true and false. 


To enable, set as debug_managers=true.


This
property maps as follows:
debug_managers
    mark_managers




The default setting is false.





debug_photos
 

Flag that instructs TDI to log additional
debug information for the following command(s).


The options
are true and false. 


This property maps as follows:
debug_photos
    load_photos_from_files
    dump_photos_to_files




The default setting is
false.





debug_pronounce
 

Flag that instructs TDI to log additional
debug information for the following command(s).


The options
are true and false. 


This property applies to the following
command(s):
debug_pronounce
    load_pronounce_from_files, 
    dump_pronounce_to_files




The default setting
is false.





debug_fill_codes
 

Flag that instructs TDI to log additional
debug information for the following command(s).


The options
are true and false. 


This property applies to the following
command(s):
debug_fill_codes
    fill_country
    fill_department
    fill_emp_type
    fill_organization
    fill_worklok




The default setting is false.





debug_draft
 

Flag that instructs TDI to log additional
debug information for the following command(s).


The options
are true and false. 


This property applies to the following
command(s):
debug_draft
    process_draft_updates
    reset_draft_iiterator_state
    set_draft_iterator_count




The default setting
is false.





debug_update_profile
 

Flag that instructs TDI to log additional
debug information for the following command(s).


The options
are true and false. 


This property applies to the following
command(s):
debug_update_profile
    populate_from_dn_file
    delete_or_inactivate_employees
    populate_from_xml_file
    process_ad_changes
    process_tds_changes




The default setting is false.





debug_collect
 

Flag that instructs TDI to log additional
debug information for the following command(s).


The options
are true and false. 


This property applies to the following
command(s):
debug_collect
    collect_dns




The default setting is false.





debug_special
 

Flag that instructs TDI to log additional
debug information for the following command(s).


The options
are true and false. 


This property applies to the following
command(s):
debug_special
    unused at present




The default setting is false.





trace_profile_tdi_javascript
 

Enables generation of an internal Javascript
trace file. 


Options are OFF, FATAL, ERROR, WARN, INFO, DEBUG,
TRACE, ALL ( values are not case-sensitive).


The
default setting is OFF.

 		
















Batch files for processing Profiles data


IBM Connections provides
several batch files that automate the collection and processing of
LDAP data for the Profiles database.


Batch file
functions
Note: The name of each
batch file ends with the .sh suffix for the IBM AIX and Linux operating
systems and with the .bat suffix for the Microsoft Windows operating system.


The following
list describes each batch file and its functions. You can search for
more information about these files in the help topics.


clearLock


Delete the lock file that is generated by the sync_all_dns batch
file.


collect_dns


Create a file
called collect.dns that contains
the distinguished names from the LDAP directory. This batch file is
used in the first step of the process to populate the Profiles database.


delete_or_inactivate_employees


Deactivate
employee records in the Profiles database. The records
are not removed from the Profiles database but are set to an inactive
state and the employee login and mail address values are removed.
 These changes are propagated to the member and login tables in the
databases of installed applications. The records to be deactivated
are defined in the delete_or_inactivate_employees.in file.
To remove users from only the Profiles database, change the
value of the sync_delete_or_inactivate property in the profiles_tdi.properties file
to delete.
Note: You must manually create the delete_or_inactivate_employees.in file.
Use the following format for adding entries:
$dn:cn=Any
User3,cn=Users,l=WestfordFVT,st=Massachusetts,c=US,ou=Lotus,o=Software
Group,dc=ibm,dc=com uid:Any User3 






dump_photos_to_files


Copy all the photos from
the PHOTO table in the Profiles database
to a folder on the local system called dump_photos.
This batch file also creates a local file called collect_photos.in that
contains the UID and URL of each photo.


dump_pronounce_to_files


Copy all the pronunciation files from the PRONUNCIATION table
in the Profiles database to a folder on the local system called dump_pronounce.
the local files. This batch file also
creates a local file called collect_pronounce.in that
contains the UID and URL of each pronunciation file.


fill_country


Populate the COUNTRY table in the
Profiles database from the isocc.csv file.


fill_department 


Populate the DEPARTMENT
table in the Profiles database from the deptinfo.csv file.


fill_emp_type 


Populate the EMP_TYPE
table in the Profiles database from the emptype.csv file.


fill_organization 


Populate the ORGANIZATION
table in the Profiles database from
the orginfo.csv file.


fill_workloc 


Populate the WORKLOC table in the Profiles database from the workloc.csv file.


load_photos_from_files


Load all the
photos from the dump_photos folder
on the local system to the PHOTO table in the Profiles database. This
batch file reads the collect_photos.in file and
the dump_photos folder that you created with
the dump_photos_to_files batch file. This batch
file loads photos only for people who are already recorded in the
database.


load_pronounce_from_files


Load
all the pronunciation files from the dump_pronounce folder
on the local system to the PRONUNCIATION table in the Profiles
database. This batch file reads the collect_pronounce.in file
and the dump_pronounce folder that you
created with the dump_pronounce_to_files batch
file. This batch file loads pronunciation files only for people who
are already recorded in the database.


mark_managers


Set the PROF_IS_MANAGER field in the Profiles database, based
on the value of the PROF_MANAGER_UID field in the employee records.


populate_from_dn_file


Populate the
Profiles database from the source LDAP directory.
This batch file reads the collect.dns data file
that you created with the collect_dns batch file.
The batch file also updates existing employee records in the Profiles
database.


process_ad_changes


Synchronize
LDAP directory changes with the Profiles database
when your LDAP directory type is Microsoft Active
Directory. This batch file is stored in the solution-dir/Samples directory.
For
more information, go to the Active Directory Change Detection Connector topic
in the Tivoli Directory
Integrator information center. For information about permissions,
go to the How
to poll for object attribute changes topic on the Microsoft Support website.
Note: The sync_all_dns script
is recommended when you want to synchronize changes in the
LDAP directory with the Profiles database.




process_draft_updates


Synchronize changes from
the Profiles database back to the LDAP
directory.


process_tds_changes


Synchronize
LDAP directory changes with the Profiles database
when your LDAP directory type is IBM Tivoli Directory
Server. This batch file is stored in the solution-dir/Samples directory.
Note: The sync_all_dns script
is recommended when you want to synchronize changes in the
LDAP directory with the Profiles database.




sync_all_dns


Update the Profiles database
to capture changes to the LDAP directory.
This synchronization process includes updates to employee records
and additions and deletions of records.


tdienv


Set the correct environment for IBM Tivoli Directory
Integrator. This batch file sets the path to the Tivoli Directory Integrator program, the Tivoli Directory Integrator host,
and the Tivoli Directory
Integrator port. If you installed Tivoli Directory
Integrator to a custom location, modify the
path to that location before using this batch file.










Populating a large user set


Populate the Profiles database from an LDAP directory with
a large user population.


In very large organizations, the number of users in the LDAP directory
exceeds the capacity of the Tivoli Directory
Integrator assembly lines for Profiles. To overcome this restriction,
you can populate the database by using manual TDI assembly lines.
You cannot use the Profiles population wizard.


For related information and details, see Tivoli Directory Integrator help. 


Limits with large user sets
The LDAP administrator
can change the LDAP size limit. The capacity of the standard assembly
lines provided with IBM Connections
is 100,000 users. In some cases, you can modify the maximum number
of entries returned from the LDAP or adjust the source_ldap_page_size parameter
in the profiles_tdi.properties file. For example,
set the parameter to the maximum number of records your LDAP repository
will return, using the following sample statement:
source_ldap_page_size=1000 

If
you receive the following, adjust the source_ldap_page_size parameter
in the profiles_tdi.properties file.
LDAP: error code 4 - Sizelimit Exceeded




If
neither of these alternatives is successful, use a special set of
assembly lines to populate your Profiles database from your LDAP directory.




Alternative population process
If you have
a very large set of data, set the source_ldap_iterate_with_filter property
in the profiles_tdi.properties file to true.
This uses the collect_ldap_dns_generator.js file
to retrieve search criteria for a batch of records. The batch is always
smaller than the limit of the LDAP retrieval.


The collect_ldap_dns_generator.js file
constructs a search filter with a portion of UIDs but does not modify
the search base. It is data-specific so you need to modify it for
your own deployment. Modify suppliesSearchBase() or suppliesSearchBase(),
depending on which filter is used in the LDAP retrieval.


If
one of the filters is changed to return true (in
the supplied file, suppliesSearchBase returns true),
the corresponding function, either getNextSearchBase() or getNextSearchFilter(),
is called in iterations. Each time the function is called it returns
a string with the next search base or filter to use. When it reaches
the end of the batch, it returns null.  


In
the sample file, the UID is examined over a range of its first characters.
 The process first uses some special characters and then examines
the first two characters of the UID string, or example aa*, ab*, and
so on.  After it reaches zz* it returns null and
the collect_dns assembly line stops processing.
 You can then run populate_from_dn_file. 










Mapping fields manually


To populate the Profiles database with data from the enterprise
LDAP directory, map the content of the fields in the database to the
fields in the LDAP directory.


About this task
Edit the map_dbrepos_from_source.properties file
to map fields between the Profiles database and the LDAP directory.
Open the profiles_functions.js file to see the
options for the different mapping functions. You can add your own
functions if necessary.


Note: When you run the Profiles population
wizard in interactive mode, it generates two property files in the Wizards\TDIPopulation directory:
a tdisetting.properties file and a mappings.properties file.
The properties in mappings.properties are very
similar to those in map_dbrepos_from_source.properties.




The internal name of the Profiles
database is PEOPLEDB.


To
map fields, complete the following steps:




Procedure
  1. On the system hosting your Tivoli Directory
Integrator installation, create a subdirectory in which to store the Tivoli Directory Integrator solution
directory. Make sure that the file path does not contain spaces. Do
not, for example, create the subdirectory in the Program
Files directory in Microsoft Windows.
    2. 

  2. Copy the tdisol compressed file from
the TDISOL directory of the IBM Connections installation media to the system
where you installed Tivoli Directory
Integrator.
    3. 

  3. Using appropriate
tools, extract the tdisol file to the directory
that you created in Step 1. This process creates a Tivoli Directory Integrator Solution directory
called TDI.
    4. 

  4. From the TDI solution directory, open
the tdienv.bat or tdienv.sh file in a text editor.
Ensure that the path to the Tivoli Directory
Integrator installation directory is specified correctly in the TDIPATH variable.
If the path is not correct, edit the TDIPATH environment
variable.
    • AIX or Linux: 
      The default value for TDIPATH is: 
      export TDIPATH=/opt/IBM/TDI/V7.1 
      

      

      • 

    • Windows: 
      The
default value for TDIPATH is: 
      SET TDIPATH=C:\Program Files\IBM\TDI\V7.1
      

      

      • 

    
 Other scripts in the solution directory use this Tivoli Directory Integrator path
or tdienv.bat or tdienv.sh file to find Tivoli Directory Integrator files. 
    5. 

  5. Edit the properties files to define the mapping between
the LDAP directory and the Profiles database. Consider using LDAP
viewer software to help you map the fields. To define the mappings
that are used when populating the Profiles database from the enterprise
directory: 
    1. From the TDI directory, open the map_dbrepos_from_source.properties file
in a text editor. 
      2. 

    2. Add or modify the field values. Any values that you omit or set
to null are not populated in the database. You can modify the values
in one of the following ways:
      1:1 mapping
      

      If one field in the Profiles database matches one field in the
enterprise directory, type the name of the field in the Profiles database
and set it equal to the associated source database LDAP property.
For example:
      bldgId=buildingname
      

      

      Complex mapping
      

      If there is a more complex relationship between the fields in
the Profiles database and enterprise directory, such as the content
of the property in the enterprise LDAP directory must be split into
multiple fields in the Profiles database, use a JavaScript function to define the relationship.
Define the function in the profiles_functions.js file
and wrap the name of the JavaScript function
in braces {}. Begin function names with func_ so
that you can more easily identify them. For example:
      bldgId={func_map_to_db_bldgId}
      

      

      

      Note: See Example complex mapping of Profiles
data for an example of complex mapping.
      

      Notes: 
      • The uid, guid, dn, surname,
and displayName attributes are always required.
        • 

      • See Table 2 for a list of the default values for the fields.
        • 

      

      

      3. 

    

    6. 

  6. Open the tdi-profile-config.xml file. After the IBM Tivoli Directory Integrator Solution
files are extracted, the file is located in the following directory:
    TDI/conf/LotusConnections-config
    

    7. 

  7. Modify the file to configure the extension attribute, specifying
the property's name and mapping from the source. Use the following
parameters: 
    Table 23. Custom extension attribute parameters
    Parameter
Description

    
    

    extensionId
The ID of the extension attribute.
    This parameter
is required.
    
    		

    

    sourceKey
The name of the attribute from the source.
    This
parameter is required.
    
    		

    
    

    

    

    For example, to add a simple attribute called spokenLangs,
the configuration would look like the following extract from the tdi-profiles-config.xml file:
    

    <simpleAttribute extensionId="spokenLangs"
    sourceKey="spokenLang"/>
    

    Note: The formatting between
the tdi-profile-config.xml and the profiles-config.xml files
is compatible, so you can copy and paste configuration information
between the files. For the extension to be displayed in the user interface,
the modifications must be made in profiles-config.xml.
For more information, see Extension properties in the data model in
the Customizing Profiles section. 
    

    Note: To leverage the
custom attribute in the Profiles user interface or REST API, you must
configure the application per the instructions in the Customizing
Profiles section. For a detailed example that uses custom attributes,
see Creating a simple profile data model and template customization.
    

    8. 

  8. Save your changes to the tdi-profile-config.xml file.
    9. 

  9. Optional: Write a JavaScript function that combines different
attributes from your LDAP directory to map a customized extension
attribute for the Profiles database:
    1. Add the extension attribute function definition in the map_dbrepos_from_source.properties file,
using the following format:  
      extattr.spokenLangs={func_map_to_langs}
      

      Note: The extensionAttribute name
must match the specified extensionId in the tdi-profiles-config.xml extension
attribute definition.
      

      2. 

    2. Add a new func_map_to_db_extensionAttribute JavaScript function in the TDISolution\TDI\profiles_functions.js file.
Write logic for the function that specifies the new extension attribute
mapping.
      3. 

    3. Repeat these steps for each JavaScript function.
      4. 

    

    10. 



What to do next
The properties in the map_dbrepos_from_source.properties file
have the default values defined in the following table. Many of them
are null. You must determine which LDAP properties to map to your
database fields and edit this file to specify values that apply to
your configuration. Any values that you omit or set to null are not
populated in the database.


Note: See Attribute mapping
for Profiles for a table of additional attribute mapping field
values.


Table 24. Default
values for properties in the map_dbrepos_from_source.properties file
TDI property
Default LDAP attribute mapping




alternateLastname
null



bldgId
null



blogUrl
null



calendarUrl
null



countryCode
c



courtesyTitle
null



deptNumber
null



description
null



displayName
cn
Required.





distinguishedName
$dn 
Required.





email
mail



employeeNumber
employeenumber



employeeTypeCode
employeetype



experience
null



faxNumber
facsimiletelephonenumber 



floor
null



freeBusyUrl
null



givenName
givenName 



givenNames
gn



groupwareEmail
null



guid
See the note at the foot of this table about
mapping the guid, uid, and loginId.
Required





ipTelephoneNumber
null



isManager
null 



jobResp
null



loginId
See the note at the foot of this table about
mapping the guid, uid, and loginId.



logins
null



managerUid
$manager_uid 
This property represents a lookup
of the UID of the manager using the Distinguished Name in the manager
field.





mobileNumber
mobile 



nativeFirstName
null 



nativeLastName
null 



officeName
physicaldeliveryofficename 



orgId
ou



pagerId
null



pagerNumber
null 



pagerServiceProvider
null 



pagerType
null 



preferredFirstName
null 



preferredLanguage
preferredlanguage 



preferredLastName
null 



secretaryUid
null 



shift
null



surname
sn 
You must provide this field because the
Search application expects to find it in the Profiles database.


Required.





surnames
sn



telephoneNumber
telephonenumber 



timezone
null



title
null



uid
See the note at the foot of this table about
mapping the guid, uid, and loginId.
Required.





workLocationCode
postallocation








Mapping the guid, uid, and loginId: The guid property
identifies the global unique ID of a user. This property's value
is created by the LDAP directory and is unique, complex, and never
changes. It is essential in that it maps each user's IBM Connections data to their User ID when using
the Profiles database as the user repository. The mapping of the guid property
must be handled differently depending on the type of LDAP directory
that you are using:
  • Microsoft Active Directory
    guid={function_map_from_objectGUID}
    
You
must use a JavaScript function
to define the value for Active Directory because objectGUID is stored
in Active Directory as a binary value, but is mapped to guid,
which is stored as a string in the Profiles database. Also, the samAccountName property
used by Active Directory has a 20 character limit, as opposed to the
256 character limit of the other IDs used by IBM Connections.
    • 

  • IBM Lotus Domino 
  
    guid={function_map_from_dominoUNID}
    

    • 

  • IBM Directory Server
    guid=ibm-entryUuid
    

    • 

  • Sun Java System Directory
Server
    guid=nsUniqueID
    

    • 

  • Novell eDirectory
    guid={function_map_from_GUID}
    

    • 


If you edited the wimconfig.xml file to
use a custom global unique ID, be sure to specify that custom ID here.

The uid property,
not to be confused with the guid property, defines
the unique ID of a user. This property differs from a guid in
that it is the organization-specific permanent identifier for a user
– often a login ID or some value based on the user's employee
code. The uid is a critical field in the Profiles
database. By default, this property links a given person's user record
back to LDAP data. The value you map to uid must
meet the following requirements:
  • It must be present in every entry that is to be added to the database.
    • 

  • It must be unique.
    • 

  • In a multi-LDAP environment, it must be unique across LDAP directories.
    • 

  • It must be 256 characters or fewer in length.
    • 


In Active Directory, although there often is a UID field available,
this field is not always the best choice for mapping to uid because
it is not guaranteed to be present for all entries. A better choice
is sAMAccountName because it usually does exist for all entries. Other
values are acceptable also, as long as they meet the requirements. 
Notes: 
  • If you are mapping the uid from an LDAP field,
specify the name of the field. However, if you need to parse it from
the distinguished name and it is in the DN in the form of uid=value,
use the following mapping function: 
    {func_map_to_db_UID}
    

    • 

  • Use the isManager and managerUid properties
to set up the organizational structure of the organization. The isManager field
determines whether the current person is a manager or not. You must
assign a Y (Yes) or N (No) value to this property for each entry.
Y identifies the person as a manager. The managerUid identifies
the UID of the current person's manager. By default, managerUid is
mapped to $manager_uid, which represents a lookup
of the UID of the manager (using the Distinguished Name contained
in the LDAP manager field). If a user's manager information is not
contained in the $manager_uid field, you should
adjust the mapping accordingly. These two properties work together
to identify manager/employee relationships and create a report-to
chain out of individual user entries.
    • 

  • If users intend to log into Profiles using a single-valued user
name other than the value specified in the uid or email properties,
you must map that user name value to the loginId property.
To do so, complete the following step:
    • Set the loginId property in the map_dbrepos_from_source.propeties file
equal to the LDAP property that you want to use as the login ID. For
example, if you want to use employeeNumber as the
login property, edit the property value as follows:
      loginId=employeeNumber
      

      • 

    

    If you have more than one additional login ID (such as with
a long and short form user ID) and you want to allow users to login
with either of their login IDs, you can populate multiple additional
login IDs by using one of the following settings: 	
    

    logins=multiValuedLdapAttribute
    

    or
    

    logins={function_to_get_multiple_ldap_values}
    
 
	
    • 







For more information, see the Tivoli Directory
Integrator product documentation.


Adding profile types: 
IBM Connections supports
the ability to classify a profile using a profile type. The profile
type allows the application to provide the set of properties that
are intended for a given profile object. For more information, see Profile-types.








Example complex mapping of Profiles data


This example illustrates a sample complex mapping using
Javascript functions to define mapping between the LDAP directory
and the Profiles database. 


When manually mapping Profiles fields you can perform 1:1
or complex mapping as described in the Mapping fields manually topic.


In this example, the mapping pertains to
the surnames list. The primary CRUD functions (create, retrieve, update
and delete) are illustrated context. The example is intended for illustrative
purposes only.


The map_dbrepos_from_source.properties mapping
file contains the following statement:
surname=sn
surnames={func_surNames_basic}




This means there
is an LDAP field named sn which contains a list
of surnames. The first property (surname=sn) causes
the first entry in the list to be stored in the surname field
or row in the Profiles user table. If the second property were also
assigned to sn, this would cause the list to be
placed in the Profiles SURNAME table. However,
the following function has been specified. 
function func_surNames_basic( fieldName) {
var fieldName str = fieldName.toString(); // be cautious, make sure it is a string.
var result = work.getAttribute("sn"); // get the list
if(result == null) {
result = "no sn work element"; // return bogus value. See the function
// func_compute_givenName() in profiles_functions.js
// for a more realistic approach.
}
else
{
result = result.clone();
var len = result.size();
for (var i = 0; i <len; i++) {
var val = result.getValue(i);
if (!(val instanceof java.lang.String)) {
val = java.lang.String.valueOf(val);
val = val + " Esq // append ‘Esq.
result.setValue(i, val); // update value
}
}
}
result.setValue(len, fieldNamestr);
return result;
}




In the first line the fieldName value
is the name of the property, in this example the surnames property.
This makes it possible to use the same function for a number of items. 


In
the third line the sn list is a variable named result.
The argument of the getAttribute() must be the
value of a property, in this example the sn property
value. 


A test for sn not being available
occurs at the fourth line in the result = "no sn work element" statement.


Given
that the list is available, we clone it to avoid changing the entry
list. We next iterate through the list testing to verify that each
value is a string. This is a best practice even though in this case
it may seem unnecessary. The line containing “result.getValue(i);” gets
the next item in the list; this represents the R element of CRUD.
The result.setValue(i, val); line shows how to modify
a value; this represents the U element of CRUD. After the iteration
we add the fieldname to the list in the result.setValue(len,
fieldNamestr); statement; this represents the C element of
CRUD. The example  uses the same setValue method
for both the create and update functions.


Further, let’s suppose
we don’t want any more than five names in the surnames list. Adding
the following entry after the for (var i = 0; i <len; i++)
{ demonstrate how the delete function works. 
if (i > 4)
{
result.removeValue(i);
len--; i--;
continue;
}












Attribute mapping for Profiles


When the Profiles directory service is enabled, IBM Connections relies on the Profiles
database to provide user data such as user name, ID, and email. 


The internal name of the Profiles
database is PEOPLEDB.


The
following table shows the mapping relationships between Profiles,
the Profiles directory service, Virtual Member Manager, and LDAP.




Table 25. Attribute mapping table
Profiles database column 
Profiles Directory Service
Virtual Member Manager 
LDAP 




PROF_GUID
ID
uniqueId
UUID/GUID/UNID (defined in RFC4122)



PROF_DISPLAY_NAME
Name
cn/displayName
cn/displayName



PROF_MAIL
Mail
mail/ibm-primaryEmail 
mail/ibm-primaryEmail



PROF_SOURCE_UID
DN
uniqueName
DN



PROF_UID
UID
UID
UID or samAccountName (in MS
AD/ADAM only)



PROF_LOGIN
LOGIN
Login attributes other than
UID and mail
LDAP login attributes other
than UID and mail










The following table shows the population functions
that are used in TDI scripts to populate ID into PROF_GUID.


Table 26. Population functions for populating ID into PROF_GUID
LDAP implementations
LDAP attribute type names
LDAP syntax
TDI scripts with functions




IBM Lotus Domino Server
dominoUNID
Directory String (in Byte String
Format)

{function_map_from_dominoUNID}





Novell eDirectory Server
GUID
Octet String (in Binary Format)

{function_map_from_GUID}





Microsoft AD/ADAM Server/Service
objectGUID
Octet String (in Binary Format)

{function_map_from_objectGUID}





Microsoft AD/ADAM Server/Service
objectSID
Octet String (in Binary Format)

{function_map_from_objectSID}





IBM Tivoli Directory Server
ibm-entryUUID
Directory String (in Canonical
Format)
n/a



Sun Java Directory Server
nsuniqueid
Directory String (in Canonical
Format)
n/a
















Configuring the Manager designation in user profiles


When you map manager data in the Profiles database, you
can mark manager profiles and also create report-to chains.


Each profile contains a manager_uid field
which stores the uid value of that person's manager.
This information is used to build the Reports To display
widget in the Profiles user interface. For information about the manager_uid field,
see Mapping fields manually. 


Additionally, the isManager field
(which equates to the Mark manager mapping
task in the Profiles population wizard) is used to mark the user profile
as being a manager. This information is used to build the People
Managed display widget in the Profiles user interface. A Y or N attribute
is assigned to an employee to indicate whether the employee is listed
as a manager of other employees. 


You can set the isManager field
as described in the Mapping fields manually topic (using
either 1:1 mapping or function mapping) or by running the Mark manager
task (using the population wizard or by running the mark_manager.bat or mark_manager.sh script).
For more information about these options see Using the Profiles
population wizard and Manually populating the Profiles
database.


If you are setting the ismanager field
using a 1:1 mapping, ensure that you specified how to set the field
in the map_dbrepos_from_source.properties file.
For example, if your LDAP has an  ismanager field
that is set to a value of Y or N, your map_dbrepos_from_source.properties file
could specify the following property:
PROF_IS_MANAGER=ismanager




If
the manager information is supplied directly from the source, the
Mark manager task is not necessary. 


The Mark manager task will
iterate through the profiles, and see if that particular profile is
referenced as the manager for any other profiles. If yes, it will
mark that profile as a manager. If that profile is not referenced
as anyone else's manager, it will be marked as not a manager.


For
information about configuring the display of the Reports
To and People Managed widgets for your
organization, see Enabling the display of organizational structure
information.








Supplemental user data for Profiles


You can supplement user profiles data using a mapping table,
the profiles_tdi.properties file, and CSV files.


Mapping user data
You can map additional
user data to supplemental tables within the Profiles database and
then display that data in a user's profile. 


When the LDAP directory
provides a code or abbreviation for a particular setting, the supplemental
table can provide extra data. For example, an employeeType of P in
the LDAP directory might correspond to Permanent. If the employee-type
table is populated with data such as p;permanent,
this extra data can be displayed in the profile.




The profiles_tdi.properties file stores
the settings that determine how the files are formatted.
Note: These
properties are supplied in the profiles_tdi.properties file.
The file path specified is relative to the TDI solution directory.




The mapping task for Profiles maps your user data to the
following entities:
Fill countries


Add country data to each profile.


Fill departments


Add department data to each profile. 


Fill organization


Add organization data to each profile.


Fill employee types


Add employee-type data to each profile.


Fill work locations


Add location data to each profile.






CSV files
A CSV (comma separated value)
file is required as input for each of these tasks.


The following
properties pertain to the CVS files used by these tasks:
country_table_csv_separator=;
country_table_csv_file=isocc.csv

department_table_csv_separator=;
department_table_csv_file=deptinfo.csv

emp_type_table_csv_separator=;
emp_type_table_csv_file=emptype.csv

organization_table_csv_separator=;
organization_table_csv_file=orginfo.csv

workloc_table_csv_separator=;
workloc_table_csv_file=workloc.csv




The separator
character separates the different tokens in each line. The second
property is the name of the file, relative to the solution directory. 


The
first token is the code. The next attributes are read in order for
each additional field. No other fields are required. 


The data
that can be populated in these tables is usually provided as two values
per line: code;description.

For
the workloc code, the values can be code;addr1;addr2;city;state;zip.
For example: WSF;FIVE TECHNOLOGY PARK DR;;WESTFORD;MA;01886-3141.
Fields
that you do not require in your mapping can be omitted from the file;
this example uses only one addr field.


The default file name
for each codes is shown in the following list:
countryCode


isocc.csv 


deptNumber


deptinfo.csv


orgId


orginfo.csv


employeeTypeCode


emptype.csv 


workLocationCode


workloc.csv 








Sample CSV file
This sample shows some lines
from the isocc.csv file, which can be used to
fill countries data:


ad;Andorra, Principality of
ae;United Arab Emirates
af;Afghanistan, Islamic State of
ag;Antigua and Barbuda
ai;Anguilla
al;Albania
am;Armenia
an;Netherlands Antilles
ao;Angola
aq;Antarctica
ar;Argentina


You can find more sample CSV files in the wizard_files_directory/TDIPopulation/TDISOL/aix|lin|win/samples directory,
where the wizard_files_directory is the location
of the various Wizard files that you downloaded or received on disk,
and aix|lin|win is the AIX, Linux,
or Microsoft Windows version of the directory.










Installing Cognos Business
Intelligence


IBM Cognos Business Intelligence collects, manages,
and displays statistical information for the Metrics application in IBM Connections. Installing Cognos Business Intelligence
involves installing IBM WebSphere Application Server
Network Deployment, plus a database client, in addition to the Cognos components. 


Before you begin
This documentation assumes you are deploying Cognos Business Intelligence before you install IBM Connections. If you choose to
deploy Cognos later, you
can ignore any Cognos-related validation errors during the Connections
installation process and then return to this section later for instructions
on deploying the Cognos components.
Even if you are not deploying Cognos now,
you can create the raw Metrics database and install the Metrics application
so that Connections can immediately begin capturing event data for
later use.




About this task
IBM Connections
requires a customized version of Cognos Business
Intelligence, which is installed using the provided script. You cannot
use previously deployed Cognos Business
Intelligence components with the Metrics application. For best performance,
use a separate computer for the customized version of Cognos Business Intelligence.


To
install the Cognos Business
Intelligence and its supporting software, complete these tasks:






Installing required patches on the Cognos BI Server system


Before installing IBM Cognos Business Intelligence
and its related software, prepare the server environment by applying
required patches to the operating system and other third-party components.


About this task
Any required patches must be installed before you attempt
to deploy the Cognos server.




Procedure
  1. Review IBM technote
7022463, Cognos BI
10.1.1 Software Environments - Required Patches. 
    Note: Open
Motif libraries are still required (as mentioned in the technote)
for headless Linux systems.
    

    2. 

  2. Install the patches specified for your server environment.
    3. 

  3. Restart the server to make sure all patches take effect.
    4. 







Installing WebSphere Application
Server for Cognos Business
Intelligence


Install IBM WebSphere Application Server
Network Deployment on the computer that will host IBM Cognos Business
Intelligence, so that the server can be managed by the Deployment
Manager used with IBM Connections.


About this task
The WebSphere node
hosting the Cognos BI server
will be federated to the same dedicated Deployment Manager as your IBM Connections deployment. Do not
use a WebSphere node that
has already been federated to a different Deployment Manager.




Procedure
  1. Install WebSphere Application
Server Network Deployment as described in the WebSphere Application
Server Version 7.0 information center. 
    This server
should be installed using the Application server profile;
you will federate it to the Deployment Manager in a later task.
    

    If
you will use a server where the appropriate version of WebSphere Application Server Network Deployment
is already deployed, you do not have to install it again; just create
a new Application server profile for Cognos Business Intelligence
as follows:
    

    IBM AIX, Linux
    manageprofiles.sh -create -templatepath  WAS_install_root/profileTemplates/default -adminUserName was_admin_name -adminPassword was_admin_password
    

    

    Microsoft Windows
    manageprofiles.bat -create -templatepath  WAS_install_root\profileTemplates\default -adminUserName was_admin_name -adminPassword was_admin_password
    

    
 
    You can verify that the installation was successful
by reviewing the WebSphere Application
Server log stored in: Cognos_WAS_node_profile/logs/Cognos_server_name/SystemOut.log;
for example on Windows:
    C:\Program Files\IBM\WebSphere\AppServer\profiles\CognosNode01\logs\cognos_server\SystemOut.log
    

    

    2. 

  2. On the newly installed server, set the system clock to
match the time (and time zone) on the Deployment Manager’s computer. 
    Attention: The node’s clock must be synced to within
1 minute of the Deployment Manager’s clock to ensure that federation
does not fail in a later task.
    

    3. 







Installing Cognos Business
Intelligence components


Install IBM Cognos Business Intelligence
on the computer where you previously installed IBM WebSphere Application
Server Network Deployment and the database client. The Cognos product consists of two components
(Cognos BI Server and Cognos Transformer); you must
install both components as part of this deployment.


Before you begin
The following conditions must be satisfied to ensure that
the Cognos Business Intelligence
components installs correctly:
  • The Cognos Content Store
database must have been created on the database server, and that database
server must be running (see Creating
databases
    • 

  • The Deployment Manager must be running.
    • 

  • The database client must have been installed on the current server,
but does not have to be running.
    • 

  • The current server must reside within the same domain as the IBM Connections servers so you can
enable SSO (Single Sign-On) as required for generating reports.
    • 

  • The user running the Cognos installation
script must have permissions to use the database client.
    • 







About this task
Installing Cognos Business
Intelligence requires two Cognos packages
(BI Server and Transformer) in addition to the scripts provided in
the IBM Connections kit.


Note: The
installation packages for Cognos Business
Intelligence components are available in the IBM Connections kit as separate downloads.


Table 27. . Package names for Cognos components to be installed for use
with IBM Connections.
Operating System
Cognos BI
Server package name
Cognos Transformer
package name




IBM AIX
IBM Cognos Business Intelligence
Server 64-bit 10.1.1 AIX Multilingual
IBM Cognos Business Intelligence
Transformer 10.1.1 AIX Multilingual 



Linux
IBM Cognos Business Intelligence
Server 64-bit 10.1.1 Linux x86
Multilingual
IBM Cognos Business Intelligence
Transformer 10.1.1 Linux x86
Multilingual 



Microsoft Windows
IBM Cognos Business Intelligence
Server 64-bit 10.1.1 Windows Multilingual 
IBM Cognos Business Intelligence
Transformer 10.1.1 Windows Multilingual 



zLinux (System
z)
IBM Cognos Business Intelligence
Server 64-bit 10.1.1 Linux on System z Multilingual (CI5W5ML
IBM Cognos Business Intelligence
Transformer 10.1.1 Linux on System z Multilingual (CI2QHML) 










Procedure
  1. Create a shared network folder where Cognos Transformer can publish metrics data
(in the form of PowerCubes) for reports to access. 
    The
shared network folder is used when you cluster multiple Cognos servers; you can use any name you want
for the folder. Record this location so you can assign it to the cognos.cube.path property
when you set up the cognos-setup.properties file
in step 6.
    

    2. 

  2. Prepare the Cognos BI
Server package:
    1. Download the Cognos BI
Server package to a temporary location on the server.
      2. 

    2. Create a directory to contain the expanded package;
for example: 
      • AIX or Linux: /opt/biserver_10.1.1
        • 

      • Windows: C:\biserver_10.1.1
        • 

      

      3. 

    3. Expand the package into the new directory.
      4. 

    

    3. 

  3. Prepare the Cognos Transformer
package:
    1. Download the Cognos Transformer
package to a temporary location on the server.
      2. 

    2. Create a directory to contain the expanded package;
for example: 
      • AIX or Linux: /opt/transformer_10.1.1
        • 

      • Windows: C:\transformer_10.1.1
        • 

      

      Important: Due to potential file name conflicts,
the Transformer package cannot share a directory with the BI Server
package. Extracting the packages to the same location will overwrite
libraries and result in a non-functioning server.
      

      3. 

    3. Expand the package into the new directory.
      4. 

    

    4. 

  4. Prepare the Cognos server
setup package: 
    CognosConfig.zip or CognosConfig.tar can
be found in the /Cognos folder within the Connections
product media.
    

    1. Download the CognosConfig package
to a temporary location on the server.
      2. 

    2. Create a directory to contain the expanded package;
for example: 
      • AIX or Linux: /opt/CognosSetup
        • 

      • Windows: C:\CognosSetup
        • 

      

      3. 

    3. Expand the package into the new directory.
      4. 

    

    5. 

  5. Set up the JDBC driver:
    1. Locate the  type 4 JDBC driver provided by your database
server product.
      2. 

    2. Copy the JDBC driver to the following location: /CognosSetup/BI-Customization/JDBC
      3. 

    

    6. 

  6. Prepare the cognos-setup.properties file
by filling in a value for each property. 
    The cognos-setup.properties file
is located in the CognosSetup directory where
you expanded the Cognos server
setup package in step 4. This file provides values that are used during
installation; each property setting in the file is accompanied by
a description.
    

    Notes® on
the settings in this file:
    • The shared network folder is represented by the cognos.cube.path property;
set this property to the name you used for the shared network folder
that you created in step 1.
      • 

    • The Cognos administrator
account specified for the cognos.admin.username setting
must represent a valid LDAP user – this is not the WebSphere administrator. You should have
already set up a user in the LDAP for this purpose; for information
see Creating the Cognos administrator.
      • 

    • (Oracle database) When you installed the Oracle database
client, you should have written down the database settings
hat you will use in the cognos-setup.properties file;
refer to those settings now.
      • 

    • Any passwords stored in this file will be removed after the script
finishes running; if you need to run the script again you will need
to insert the passwords before the next run. If you prefer, you can
omit the passwords from the properties file and supply them on the
command line when you run the script, as shown in step 9.
      • 

    

    

    7. 

  7. (RedHat Linux 6
64-bit systems) Run the following command to preload libraries needed
for the setup scripts used in the next step: 
    export LD_PRELOAD=/usr/lib64/libfreebl3.so
    

    8. 

  8. (SuSE 11 zLinux systems) Create a symbolic link to the libXm.so.3 package: 
    The openmotif22-libs-32bit-2.2.4-138.18.1 kit
includes libXm.so.4, while the Cognos installer
program issetup script links with libXm.so.3 and
encounters an error if it is not available. Prevent this error by
creating a symbolic link to libXm.so.3 with the
following command:
    

    ln -s /usr/lib/libXm.so.4 /usr/lib/libXm.so.3
    

    9. 

  9. (Microsoft SQL
Server) If you are using Microsoft SQL
Server as your database management system, you must configure it to
support remote connections before running the cognos-setup.bat|sh script,
or the database validation will fail. For information on enabling
remote connections in SQL Server, see the Microsoft site.
    10. 

  10. Run the cognos-setup.sh|bat script
to install the Cognos BI
Server and Transformer components. 
    Any of the properties
specified in the cognos-setup.properties file
can be passed in as parameters when you run this script. In particular,
you might want to supply passwords using this method rather than adding
them into the properties file because they will be deleted from the
file after it runs. For any properties you supply at run time, use
the following syntax:
    cognos-setup.sh|bat -property_name1=property_value1 -property_name2=property_value2
    

    

    For
example, the properties file contains settings for four passwords.
You can pass all of them in at run time by including them on the command
line as shown:
    cognos-setup.sh -was.local.admin.password=WASadmin_pwd -cognos.admin.password=CognosAdmin_pwd -cognos.db.password=CognosContentStore_pwd -metrics.db.password=Metrics_DB_pwd
    

    
 
    Output from this operation is stored in the /CognosSetup/cognos-setup.log.
    

    Attention: If you encounter an error when running the cognos-setup.bat|sh script,
correct the error and run the script again before proceeding to the
next step. For example, if you provided an incorrect password in the cognos-setup.properties file,
modify the password and then run the cognos-setup.sh|bat script
again. Remember that if you added passwords to the properties file,
they were deleted after the previous run, and must be provided again.
If you encounter other problems, see Troubleshooting Cognos Business Intelligence components for
possible solutions. 
    

    11. 

  11. Now run the cognos-configure.sh|bat script
to configure the Cognos server
and set up database connections. 
    Any of the properties
specified in this script can be passed in as parameters when you run
this script, using the syntax shown in the previous step.
    
 
    Output from this operation is stored in the /CognosSetup/cognos-configure.log.
    

    Attention: If you encounter an error when running the cognos-configure.sh|bat script,
correct the error and run the script again before proceeding to the
next step.  For example, if you provided an incorrect password in
the cognos-setup.properties file, modify the
password and then run the cognos-setup.sh|bat script
again. Remember that if you added passwords to the properties file,
they were deleted after the previous run, and must be provided again.
If you encounter other problems, see Troubleshooting Cognos Business Intelligence components for
possible solutions. 
    

    12. 

  12. Leave the Cognos server
stopped for now; you will start the server after federating it to
the Deployment Manager in the next task. 
    Note: In the future,
whenever you want to stop the Cognos server,
you must stop the WebSphere Application
Server hosting it; wait at least 1 full minute to ensure that all
of the Cognos processes (AIX or Linux: cgsServer.sh and CAM_LPSvr processes; Windows: cgsLauncher.exe and CAM_LPSvr processes)
have completely stopped before you attempt to start the server again.
    

    13. 



Results
The Cognos BI
Server and Transformer components are installed into the directories
that you specified in the cognos-setup.properties file;
for example:
  • Cognos BI Server: cognos.biserver.install.path
    • AIX or Linux: /opt/IBM/Cognos64
      • 

    • Windows: C:\Program
Files\IBM\Cognos
      • 

    

    • 

  • Cognos Transformer: cognos.transformer.install.path
    • AIX or Linux: /opt/IBM/Cognos
      • 

    • Windows: C:\Program
Files (x86)\IBM\Cognos
      • 

    

    • 





Note: During the installation, you might see the following
message: ERROR: The system cannot find the file specified.
If this message is followed by "success" messages" similar to those
shown here, then the installation was successful and you can ignore
the error message.
<date><time> : daily refresh success

<date><time> : rebuild <year><month> success




You
can verify that the components were installed successfully by reviewing
the installation logs at the following locations:
  • Cognos BI Server installation
log: Cognos_BI_install_path/logs/cogserver.log
    • AIX or Linux: /opt/IBM/Cognos64/logs/cogserver.log
      • 

    • Windows: C:\Program
Files\IBM\Cognos\logs\cogserver.log
      • 

    

    • 

  • Cognos Transformer installation
log: Cognos_Transformer_install_path/logs/cogserver.log: 
    • AIX or Linux: /opt/IBM/Cognos/logs/cogserver.log
      • 

    • Windows: C:\Program
Files (x86)\IBM\Cognos\logs\cogserver.log
      • 

    

    • 











Installing the database client for Cognos Transformer


Install a database client on the computer where you will
host IBM Cognos Business Intelligence. The Cognos Transformer component
requires the use of a database client to ensure proper access to the
database server for PowerCube generation and reporting.


Installing the DB2 database
client for Cognos Transformer


Install the IBM DB2 database client on the computer
where you will host IBM Cognos Business Intelligence.


Before you begin
Before you install the database client, the database server
must be installed and running, and you must have created the Metrics
database and the Cognos Content
Store database.




Procedure
  1. Install the database client on the server where you will
deploy Cognos Business Intelligence,
using the instructions provided with your database product. 
    For
instructions on installing the IBM DB2 client, see the Installation methods for IBM data server clients in the DB2 information center.
    

    2. 

  2. (DB2 on Linux only) Ensure that the DB2 client library is properly sourced:
    1. In the DB2 client
installation directory, open the /etc/ld.so.conf file
for editing.
      2. 

    2. Add the following library /opt/ibm/db2/V9.7/lib32 to
the file.
      3. 

    3. Save and close the file.
      4. 

    4. Run the ldconfig command to regenerate
dynamic link libraries (DLLs).
      5. 

    

    3. 

  3. Create a connection between the client and the database. 
    First, connect the client to the node (the DB2 server) where the database is hosted by completing
the following steps.
    

    1. Log on to the client computer as a user with at least DB2 SYSADM authority. 
      You
cannot catalog a node as a root authority.
      

      2. 

    2. Change to the home directory of instance. 
      The
substeps below refer to this directory as INSTHOME.
      

      3. 

    3. (AIX or Linux) Set up the instance environment
by running the startup script: 
      bash, Bourne, or Korn
shell
      

      . INSTHOME/sqllib/db2profile
      

      C
shell
      

      source INSTHOME/sqllib/db2cshrc
      
where INSTHOME indicates
the home directory of the instance.
      4. 

    4. Open the DB2 command
line processor: 
      AIX or Linux
      

      db2
      

      Windows
      

      db2cmd
      
where INSTHOME indicates
the home directory of the instance.
      5. 

    5. Catalog the DB2 server
by entering the following commands in the command line processor: 
      db2 => catalog tcpip node Node_name remote Host_name|IP_address
       server Service_name|DB2_Instance_Port

db2 => terminate
      
Where: 
      • Node_name indicates a local
nickname (for example, the short host name) that you can set for the DB2 server. 
        • 

      • Host_name|IP_address indicates
the host name or IP address of the server instance where the database
resides (both IPv4 and IPv6 addresses are accepted). 
        • 

      • Service_name|DB2_Instance_Port indicates
the service name or DB2 instance
port used for the connection (typically port 50000 for DB2).
        • 

      
For example, connect to the server called "db2node" with the
IP address "2001:DB8:0:0:0:0:0:0" on port 50000 as follows: 
      db2 =>  catalog tcpip node db2node remote 2001:DB8:0:0:0:0:0:0 server 50000 
DB20000I  The CATALOG TCPIP NODE command completed successfully.
DB21056W  Directory changes may not be effective until the directory cache is refreshed.

db2 =>  terminate 
DB20000I  The TERMINATE command completed successfully.
      

      6. 

    
 
    Now connect the client to the DB2 database
itself by completing the following steps.
    

    For DB2, configure the client to use Metrics as
both the Database name and the Database
alias. 
    

    1. Run the following commands in the DB2 command line processor: 
      db2 => catalog database Database_name as Database_alias at node Node_name

db2 => connect to Metrics user Metrics_db_user

db2 => terminate
      
Where the DB2 server
is the node you just connected to, and the database information matches
the values specified in the cognos-setup.properties file
that is used during installation:
      • Database_name indicates the
name of the Metrics database (the metrics.db.name setting;
the default value is METRICS).
        • 

      • Database_alias indicates the
alias for the Metrics database (the metrics.db.local setting;
the default value is METRICS).
        • 

      • Node_name is the same local
nickname that you used to connect to the DB2 server
earlier in this step.
        • 

      • Metrics_db_user indicates
the user name that will be used to access the database (the metrics.db.user setting;
the default value is LCUSER).
        • 

      
For example, catalog the METRICS database on the server "db2node"
as the user "LCUSER" and then test the connection with the following
commands:
      db2 =>  catalog database METRICS as METRICS at node db2node 
DB20000I  The CATALOG DATABASE command completed successfully.
DB21056W  Directory changes may not be effective until the directory cache is refreshed.

db2 =>  connect to METRICS user LCUSER 
Database Connection Information     
Database server = DB2 9.7.0     
SQL authorization ID = LCUSER     
Local database alias = METRICS

db2 =>  terminate 
DB20000I  The TERMINATE command completed successfully.
      

      2. 

    2. When you have successfully cataloged the database, close
the DB2 command line processor
with the following command: 
      db2 =>  quit 
      

      3. 

    
 
    For more information on connecting the DB2 client to the DB2 server
and database (including optional arguments), see Configuring client-to-server connections using the
command line processor in the DB2 information
center.
    

    4. 







Installing the Oracle database client for Cognos Transformer


Install the Oracle database client on the computer where
you will host IBM Cognos Business Intelligence.


Before you begin
Before you install the database client, the database server
must be installed and running, and you must have created the Metrics
database and the Cognos Content
Store database.


For troubleshooting information on configuring
the Oracle database client for use with Cognos, see the IBM technote, Resolving Oracle connection errors.




Procedure
  1. Install the standard 32-bit database client on the server
where you will deploy Cognos Business
Intelligence; for information see Installing
Oracle Database Client. 
    Important: Be
sure to install the standard 32-bit client rather than the Instant
Client, which is not supported by Cognos.
If you installed the 64-bit client, you must uninstall it before installing
the 32-bit client.
    

    2. 

  2. Copy the following files to the Cognos_Transformer_install_path/bin directory: 
    • Oracle_client_install_path/lib/libclntsh.so.11.1
      • 

    • Oracle_client_install_path/lib/libnnz11.so
      • 

    

    Note: If you are using a different version of the Oracle client,
you should find similar files (named for the version) in the same
location, and can use those files instead.
    

    3. 

  3. (AIX or Linux) If you are not logged in as root,
change the permissions on the two files using chmod 755.
    4. 

  4. Restart the server:
    1. Stop the IBM WebSphere Application Server
that hosts the Cognos server. 
      2. 

    2. Wait at least 1 full minute to ensure that all Cognos processes have stopped: 
      • AIX or Linux: cgsServer.sh and CAM_LPSvr processes
        • 

      • Windows: cgsLauncher.exe and CAM_LPSvr processes
        • 

      

      3. 

    3. Start WebSphere Application
Server.
      4. 

    4. Start the Cognos server.
      5. 

    
 
     If possible restart the server and then start Cognos service. If you cannot restart the
server, just restarting the Cognos service
should do.
    

    5. 

  5. Define the ORACLE_HOME, TNS_ADMIN, and LD_LIBRARY_PATH
locations: 
    ORACLE_HOME=/u01/app/oracle/product/11.2.0/client_1
LD_LIBRARY_PATH=Cognos_Transformer_install_path/bin; ORACLE_HOME/lib
TNS_ADMIN=ORACLE_HOME/network/admin
    

    6. 

  6. Edit the Oracle_client_install_path/network/admin/tnsnames.ora file
and add the following TNS settings into the file: 
    The
TNS setting on the Oracle client should look like the example that
follows:
    METRICS =
  (DESCRIPTION =
    (ADDRESS_LIST =
      (ADDRESS = (PROTOCOL = TCP)(HOST = Oracle_database_server_host_name)(PORT = Port))
    )
    (CONNECT_DATA =
      (SERVICE_NAME = Database_service_name)
    )
  )
    
where:
    • Oracle_database_server_host_name is
the host name of the server hosting the Oracle database server; for
example: oradb.example.com.
      • 

    • Port is port on which the
Oracle database server is listening; typically port 1521.
      • 

    • Database_service_name is the
database service name; for example orcl.
      • 

    

    

    7. 

  7. Write down the following settings so you can enter them
into the cognos-setup.properties file in a later
task: 
    Use the same values for the Oracle_database_server_host_name,
the Port, and the Database_instance_name that
you used in the Oracle tnsnames.ora file.
    

    cognos.db.type=oracle
cognos.db.host=Oracle_database_server_host_name:Port
cognos.db.name=Database_instance_name
cognos.db.user=cognos           //created by installer
cognos.db.password=pass

metrics.db.type=oracle
metrics.db.host=Oracle_Database_Server:1521
metrics.db.name=orcl

metrics.db.local.name=METRICS   //local TNS name
metrics.db.user=metricsuser     //created by installer
metrics.db.password=pass
    

    8. 

  8. Verify that the client can connect to the Metrics database. 
    If the Oracle client encounters errors connection to the
Metrics database, refer to the IBM technote, Resolving Oracle connection errors.
    

    9. 









Federating the Cognos server
to the Deployment Manager


The computer hosting the IBM Cognos Business Intelligence
server must be federated to the same dedicated Deployment Manager
used by IBM Connections.


Before you begin
Before attempting to federate the Cognos node to the Deployment Manager, make
sure that:
  • The Deployment Manager is running.
    • 

  • The Cognos server is
stopped (if you started it after installation, stop it now by stopping
the IBM WebSphere Application Server hosting it).
    • 

  • The system clock on the Cognos server
is set to within 1 minute of the time (and time zone) of the system
clock on the Deployment Manager.
    • 

  • The Deployment Manager and the Cognos server
are either both registered in the DNS or are referenced in each other’s etc/hosts file.
    • 







About this task
This task involves working on the newly installed Cognos Business Intelligence
server to add the node to the Deployment Manager, and then working
on the Deployment Manager to create virtual ports for the new node.




Procedure
  1. On the Deployment Manager, disable Java 2 security: 
    1. Log into the Integrated Solutions Console as the WebSphere administrator.
      2. 

    2. Click Security > Global Security
      3. 

    3. Look under "Java 2 security" and clear the selection
for  Use Java 2 security to restrict application access
to local resources.
      4. 

    4. Click Apply.
      5. 

    5. Click OK.
      6. 

    

    2. 

  2. Use the computer hosting the Cognos components to federate the new node
to the Deployment Manager:
    1. On the computer hosting the Cognos components, open a command window and
navigate to the/bin directory in the WebSphere Application Server
installation root; for example: 
      • IBM AIX, Linux: /opt/IBM/WebSphere/AppServer/bin
        • 

      • Microsoft Windows: C:\Program
Files\IBM\WebSphere\AppServer\bin
        • 

      

      2. 

    2. Run the addNode command to federate
the node to the Deployment Manager as follows: 
      addNode.bat|sh DM_host_name DM_port -profileName Cognos_profile_name -includeapps -username DM_admin_user_name -password DM_admin_password
      

      where:
      • DM_host_name is the fully
qualified host name of the Deployment Manager.
        • 

      • DM_port is the SOAP_CONNECTOR
port that the Deployment Manager is listening on; the default port
is 8879.
        You can determine the port by checking the SOAP_CONNECTOR_ADDRESS value
in the following file on the computer hosting the Deployment Manager:: 
        

        WAS_install_root/profiles/DM_Name/properties/portdef.props;
for example on Windows:
        C:\Program Files\IBM\WebSphere\AppServer\profiles\Dmgr01\properties\portdef.props
        

        

        • 

      • Cognos_profile_name is the
profile name where Cognos Business Intelligence is installed (in case
multiple profiles are installed on the same server). 
        Tip: If
you only installed one WebSphere profile on the server, you can omit
this parameter.
        

        If you are not sure of the Deployment Manager’s
profile name, you can determine it by looking at the directory name
where it was installed; for example on Linux: 
        /opt/IBM/WebSphere/AppServer/profiles/Cognos_profile_name
        

        

        • 

      • DM_admin_user_name is the
user name of the WebSphere administrator
on the Deployment Manager, and DM_admin_password is
the associated password.
        • 

      

      Important: Make sure you specify -includeapps as
shown in the example. 
      

      

      For example:
      addNode.bat lc40.example.com 8879 -profileName AppSrv01 -includeapps -username wasadmin -password my_WASadmin_pwd
      

      

      3. 

    3. Now start the node agent by running the startNode command
(from within the same directory); for example: 
      • AIX or Linux: startNode.sh
        • 

      • Windows: startNode.bat
        • 

      

      4. 

    

    3. 

  3. Move back to the Deployment Manager and create virtual
ports for the new node:
    1. Log into the Integrated Solutions Console as the WebSphere administrator.
      2. 

    2. In the navigation tree, click Servers > Server Types > WebSphere Application
servers > Cognos_server_name > Ports.
      3. 

    3. Note the values for the following ports, for use in
the next step: 
      • WC_defaulthost
        • 

      • WC_defaulthost_secure
        • 

      

      4. 

    4. Back in the navigation tree, click Environment > Virtual Hosts > default_host > Host Aliases.
      5. 

    5. Click the New button in the ports
table and add a port representing WC_defaulthost;
then click OK: 
      • Host name: *
        • 

      • Port: use the value of the WC_defaulthost port
that you noted earlier.
        • 

      

      6. 

    6. Click the New button again and
add a port representing WC_defaulthost_secure; then
click OK: 
      • Host name: *
        • 

      • Port: use the value of the WC_defaulthost_secure port
that you noted earlier.
        • 

      

      7. 

    7. Save the changes to the master configuration by clicking
the Save link in the "Messages" box at the
top of the page.
      8. 

    

    4. 

  4. Synchronize the new node to the Deployment Manager:
    1. On the navigation tree, click System
Administration > Nodes.
      2. 

    2. In the nodes table, click the checkbox that precedes
the new node (the Cognos server).
      3. 

    3. Click the Synchronize button
in the table and wait for the operation to finish before proceeding
to the next step. 
      Synchronization might take several
minutes to complete; be sure to allow sufficient time before restarting
the Cognos server in the
next task.
      

      4. 

    

    5. 

  5. Restart the Cognos server:
    1. Stop the IBM WebSphere Application Server
that hosts the Cognos server.
      2. 

    2. Wait at least 1 full minute to ensure that all Cognos processes have stopped: 
      • AIX or Linux: cgsServer.sh and CAM_LPSvr processes
        • 

      • Windows: cgsLauncher.exe and CAM_LPSvr processes
        • 

      

      3. 

    3. Start WebSphere Application
Server.
      4. 

    4. Start the Cognos server.
      5. 

    

    6. 







Validating the Cognos BI
server installation


Verify that the IBM Cognos Business
Information server is correctly installed by viewing its content manager
and dispatcher pages.


Before you begin
Make sure the Cognos server
is running.




About this task
For configuration tips and information on troubleshooting
the Cognos Business Intelligence
installation, see Troubleshooting Cognos Business Intelligence.




Procedure
  1. From any browser, navigate to the Cognos server’s content manager at the following
address:  
    http://Host_Name:Port/Context_Root/servlet
    

    where:
    • Host_Name is the fully qualified
host name of the Cognos server;
for example, host.example.com.
       This value is specified
in the was.fqdn.hostname property in the cognos-setup.properties file
used for installing the server.
      

      • 

    • Port is the port that the Cognos server is listening on.
      • 

    • Context_Root is the context
root to which you installed the Cognos server;
for example, cognos. 
      This value is specified in
the cognos.context_root property in the cognos-setup.properties file
using for installing the server (the default value was set to cognos).
      

      • 

    
For example:
    

    http://cognosserver.example.com:9083/cognos/servlet
    
 
    The IBM Cognos Content Manager displays the following
information: build number, server start time, current time, and current
server state. The state should be running; if it
is not, see Troubleshooting
Cognos Business Intelligence components for possible problems
and suggested solutions.
    

    2. 

  2. Next, verify the dispatcher:
    1. In the browser, navigate to the dispatcher’s address: 
      • If you have not yet federated the node to the Deployment Manager,
use the following URL:
        http://Host_Name:Port/Context_Root/servlet/dispatch/ext
        

        • 

      • If you have already federated the node to the Deployment Manager,
use the following URL:
        http://Host_Name:Port/Context_Root/servlet/dispatch
        

        Note: Images
and icons may not display properly for this URL, but it is sufficient
to validate that the IBMConnectionsMetrics folder
and subfolders exist. 
        

        • 

      

      where the Host_Name, Port,
and Context_Root values are the
same as those used in step 1. For example:
      

      http://cognosserver.example.com:9083/cognos/servlet/dispatch
      
 
      The dispatcher displays tabs listing public and private
folders.
      

      2. 

    2. In the dispatcher, click the Public tab;
in the list of public folders click the IBMConnectionsMetrics folder
and verify that it contains three subfolders (Metrics, MetricsCubeDS,
and MetricsDBQuery).
      3. 

    

    3. 



What to do next
If you deployed Cognos Business
Intelligence as a prerequisite step to installing IBM Connections, continue the next section, Installing IBM Connections. You will complete the Cognos configuration tasks after
you install the Connections applications.


If you originally
installed IBM Connections without
first deploying Cognos Business
Intelligence and are now deploying the Cognos server, skip the Connections installation
topics (which you have already completed) and instead go directly
to Configuring Cognos Business Intelligence.












Installing IBM Connections


Select the IBM Connections
applications that you plan to use and install them in a clustered
deployment.


An IBM Connections deployment
consists of the following components:
  • WebSphere Application
Server nodes:
    • One node with IBM WebSphere Application Server
Network Deployment Manager (DM) installed.
      • 

    • One or more WebSphere Application Server nodes that can be federated into the DM cell.
These nodes are hosts for cluster members.
      • 

    

    • 

  • A system with a database server installed.
    • 

  • An LDAP server.
    • 

  • A system with IBM HTTP Server
installed.
    • 





Important: Before beginning the installation, you must
understand the prerequisites for IBM Connections 4.0. For more information, see the Before
installing topic and ensure that you meet all the conditions
that are prescribed for your deployment environment. 




Before installing


Verify that all necessary prerequisite conditions are complete
before installing IBM Connections. 


Prerequisites
  • Check the Release notes for late-breaking issues.
    • 

  • If you previously installed IBM Installation Manager, update it to V1.4.4 or higher. For more information,
go to the IBM Installation
Manager updates webpage.
    Note: Use the same user account to
install IBM Installation Manager
and IBM Connections.
    

    • 

  • IBM Installation Manager
presents three options for the type of deployment that you can install.
For more information about these options, see the Deployment
options topic.
    • 

  • The IBM Connections installation
process supports the creation of new server instances and clusters.
Do not use existing clusters to deploy IBM Connections. 
    • 

  • You can install IBM Connections
with either root or non-root accounts on AIX and Linux, or administrator
or non-administrator accounts on Microsoft Windows.
For more information, see the Installing as a non-root user topic.
    • 

  • Complete the Pre-installation tasks.
    Note: If
you are migrating from IBM Connections
3.0.1, you need to complete only the following tasks:
    • Preparing to configure the LDAP directory
      • 

    • Installing IBM WebSphere Application Server if you are installing on the same host as 3.0.1.
      • 

    • Setting up federated repositories
      • 

    • Do not complete the Pre-installation tasks for creating databases
or populating the Profiles database. The migration process handles
those tasks separately. 
      • 

    

    

    • 

  • Install IBM WebSphere Application Server Network Deployment
(Application Server option) on each node. IBM Connections is installed on the system where WebSphere Application Server
Deployment Manager is installed. For more information, see the Installing IBM WebSphere Application Server topic. 
    • 

  • Back up the profile_root/Dmgr01 directory. 
    • 

  • Configure WebSphere Application Server to communicate with the LDAP directory. For more
information, see the Setting up federated repositories topic.
    • 

  • Prepare directories to use as content stores. You need to provide
shared content stores on network share devices and local content stores
on each node. Both shared and local content stores must be accessible
using the same path from all nodes and from the Deployment Manager.
    • 

  • Set the system clocks on the Deployment Manager and the nodes
to within 1 minute of each other. If these system clocks are further
than 1 minute apart, you might experience synchronization errors. 
    • 

  • Copy the JDBC files for your database type to the Deployment Manager
(DM) and then from the DM to each node. Place the copied files in
the same location on each node as their locations on the DM. If, for
example, you copied the db2jcc.jar file from
the C:\IBM\SQLLIB directory on the DM, place
the copy in the C:\IBM\SQLLIB directory on each
node. See the following table to determine which files to copy:
    Table 28. JDBC files
    Database type
JDBC files

    
    

    DB2

    db2jcc.jar
    

    db2jcc_license_cu.jar
    
    		

    

    Oracle

    ojdbc6.jar
    Note: Ensure that you are using the latest version of the ojdbc6.jar file.
    

    
    		

    

    SQL Server

    sqljdbc4.jar
    
    		

    
    

    

    

    • 

  •  If you are going to use a trusted SSL certificate, ensure that
is available before you begin the installation.
    • 

  • If you do not plan to deploy IBM Cognos Business
Intelligence now to support metrics, you can still install the Metrics
application along with the other IBM Connections applications. This enables Connections to begin
collecting event data immediately and store it in the Metrics database
for use when Cognos is available
to provide reports.
    • 

  • (Microsoft Windows) You must use an administrator account
to install IBM Connections on Windows. If you are installing
on Windows Server 2008, you
must use a local administrator account. If you use a domain administrator
account, the installation might fail. 
    • 

  • (Linux only) If you receive an error
message after attempting to start IBM Installation Manager, you might need to install additional
32-bit libraries. For more information about required Linux libraries, see the Linux libraries topic. For more information
about IBM Installation Manager
errors, go to the Unable to install Installation Manager on RHEL 6.0/6.1
(64-bit) webpage.
    • 

  • (AIX and Linux) Ensure that the directory paths that
you enter contain no spaces.
    • 

  • (AIX and Linux) Ensure that the Open File Descriptor
limit is 8192.  For information about setting the file limit, go to
the Installation error messages topic and search for error code CLFRP0042E.
    • 

  • (AIX only) IBM Installation Manager requires additional
libraries for the AIX operating
system. For more information, go to the Required filesets on AIX for Installation Manager webpage. 
    • 

  • (AIX only) If IBM Installation Manager hangs while being installed
on your system, you might need to update your version of the software.
For more information, read the IBM Installation
Manager hangs on 64-bit AIX systems technote.
    • 

  • (AIX only) If you are downloading IBM Installation Manager, the TAR
program available by default with AIX does not handle path lengths longer than 100 characters.
To overcome this restriction, use the GNU file archiving program instead.
This program is an open source package that IBM distributes through the AIX Toolbox for Linux Applications at the IBM AIX Toolbox website. Download
and install the GNU-compatible TAR package. You do not need to install
the RPM Package Manager because it is provided with AIX.
    After installing the GNU-compatible compression
program, change to the directory where you downloaded the IBM Connections tar file. Enter
the following command to extract the files from the file:
    

    gtar -xvf Lotus_Connections_wizard_aix.tar
    

    This command creates a directory named after IBM Installation Manager. 
    

    • 



Tips: 
  • Establish naming conventions for nodes, servers, clusters, and
web servers.
    • 

  • Use a worksheet to record the user IDs, passwords, server names,
and other information that you need during and after installation.
For more information, see the Worksheet for installing IBM Connections topic.
    • 

  • Installing and configuring IBM Connections is a complex process;
not only should you read the instructions but you must also pay attention
to the Before you begin prerequisites in each topic.
    • 









Linux libraries


The complete list of Linux libraries required for deploying IBM Connections 4.0.


Linux
Ensure that you have installed the following Linux packages and libraries:
Note: Ensure that
the GTK library is available on your system. Even when you are installing
on a 64-bit system, you still need the 32-bit version of the GTK library. 


compat-libstdc++-33.x86_64


libcanberra-gtk2.i686


PackageKit-gtk-module


gtk2.i686


compat-libstdc++-33.i686


compat-libstdc++-296


compat-libstdc++


libXtst.i686




Cognos
If you plan to install Cognos, you also need the libraries listed in the Cognos BI
10.1.1 Software Environments - Required Patches technote.
Note: Both 32-bit and 64-bit versions are required.












Installing as a non-root user


Grant permissions to a non-root user to install IBM Connections.


Before you begin
Ensure
that you complete all the prerequisite tasks that are relevant for
your environment. For more information, see the Before installing topic.




About this task
This task applies to the AIX and Linux operating
systems only. 
By default, only root users have the necessary permissions
to install an IBM Connections
deployment. On  the AIX and Linux operating systems, you can
permit non-root users to install the product by changing their permissions
to access certain data directories. On the Windows operating system, the user must be
a member of the administrator group. 


Note: The non-root user must
be the same user who installed IBM WebSphere Application
Server. 


To grant the necessary permissions to a non-root
user, complete the following steps:




Procedure
  1. Unless it already exists, create the non-root user account
that you want to use to install IBM Connections. 
    2. 

  2. If it does not already exist, create a home directory for
the user.
    3. 

  3. Edit the install.ini file:
    1. Open the install.ini file for editing
from the following location: 
      • AIX: IBM_Connections_set-up directory/IM/aix/install.ini
        • 

      • Linux: IBM_Connections_set-up directory/IM/linux/install.ini
        • 

      • Linux on System z: IBM_Connections_set-up
directory/IM/zlinux/install.ini
        • 

      

      2. 

    2. In the second line of the file, change admin to nonadmin.
      3. 

    3. Save and close the file.
      4. 

    

    4. 

  4. Open a command prompt and grant the appropriate permissions
to the user by entering the commands shown in the following table: 
    • AIX or Linux:
      Note: Use either the chmod or chown commands,
depending on your security environment. Use the chown commands to
grant permissions to a user and group but ensure that the group includes
the user account that installed WebSphere Application Server. 
      

      Table 29. Non-root
user permissions
      Directory
Permissions
chmod command
chown command

      
      

      app_server_root
RWX
chgrp -R non-root_user_group app_server_root chmod -R g+wrx app_server_root
      where non-root_user_group is a
user group that contains the non-root user account.
      
      		
chown -R non-root_ID:group app_server_root
      where non-root_ID is the non-root user account
and group is the user group that contains this
account.
      
      		

      

      IBM_ Connections set-up directory
      
      		
RWX
chgrp -R non-root_user_group IBM_Connections_set-up_directory chmod -R g+wrx IBM_Connections_set-up_directory
chown -R non-root_ID:group IBM_connections_set-up_directory

      

      connections_root
RWX
chgrp -R non-root_user_group connections_root chmod -R g+wrx connections_root
chown -R non-root_ID:group connections_root

      

      IM_root
RWX
chgrp -R non-root_user_group IM_root chmod -R g+wrx IM_root
chown -R non-root_ID:group IM_root

      

      shared_resources_root
RWX
chgrp -R non-root_user_group shared_resources_root chmod -R g+wrx shared_resources_root
chown -R non-root_ID:group  shared_resources_root

      

      var/ibm/InstallationManager
      
      		
RWX
chmod -R ugo+rwx /var/ibm/InstallationManager
      Note: Grant permissions to this folder only if the root user installed IBM Installation Manager.
      
      		
chown -R non-root_ID:group /var/ibm/InstallationManager

      
      

      

      

      • 

    

    5. 

  5. Install IBM Connections
using either the wizard, the console, or a silent installation method.
    6. 



Example
Grant permissions to a non-root
user who wants to install an IBM Connections deployment on Linux.


Assumptions:
  • The app_server_root directory is /opt/IBM/Websphere/Appserver.
    • 

  • The IBM_Connections_set-up_directory directory
is /opt/ConnectionsSetup.
    • 

  • The connections_root, IM_root, and shared_resources_root directories are subdirectories
of the /opt/ConnectionsInstallation directory.
    • 

  • The non-root user account is a member of the ConnectionsInstallers
group.
    • 





Procedure:


  1. Create a non-root user account called ConnectionsInstaller.
    2. 

  2. Create a home directory for the new user account.
    3. 

  3. Add the new user account to the ConnectionsInstallers group.
    4. 

  4. Open a command prompt and enter the following commands:
    1. chgrp -R ConnectionsInstallers /opt/IBM/Websphere/Appserver
chmod -R g+wrx /opt/IBM/Websphere/Appserver chown -R ConnectionInstaller:ConnectionsInstallers
/opt/IBM/Websphere/Appserver
      2. 

    2. chgrp -R ConnectionsInstallers /opt/ConnectionsSetup
chmod -R g+wrx /opt/ConnectionsSetup chown -R ConnectionInstaller:ConnectionsInstallers
/opt/IBM/Websphere/Appserver
      3. 

    3. chgrp -R ConnectionsInstallers /opt/ConnectionsInstallation
chmod -R g+wrx /opt/ConnectionsInstallation chown -R ConnectionInstaller:ConnectionsInstallers
/opt/IBM/Websphere/Appserver
      4. 

    

    5. 









Installing IBM Connections
4.0


Install IBM Connections.


Before you begin
Ensure
that you complete all the prerequisite tasks that are relevant for
your environment. For more information, see the Before installing topic.




About this task
To install IBM Connections,
run the IBM Installation Manager
 wizard on the system where the Deployment Manager is installed.


If an error occurs during installation, IBM Installation Manager cancels the installation
and rolls back the installation files. Installation errors are usually
caused by environment problems such as insufficient disk space, privilege
issues, or corruption of a WebSphere profile. If your installation is canceled, complete
the following steps:
  1. Identify and resolve the error that caused the cancellation. After
canceling the installation, IBM Installation Manager displays an error message with an error code.
You can look up the error code in the Installation error messages topic or check the log files.
    2. 

  2. Restore the Deployment Manager profile from your backup.
    3. 

  3. Delete the connections_root directory.
    4. 

  4. Start this task again.
    5. 





To install IBM Connections,
complete the following steps:




Procedure
  1. On each
node, stop any running instances of WebSphere Application Server and WebSphere node agents. 
    2. 

  2. Start WebSphere Application Server
Network Deployment Manager.
    3. 

  3. Copy
the installation files to the system hosting the Deployment Manager. 
    Note: Ensure that the directory path that you enter contains
no spaces.
    

    4. 

  4. From the Connections setup directory, run the file to start
the IBM Connections launchpad:
    • AIX or Linux: Connections set-up/launchpad.sh
      • 

    • Windows: Connections set-up\launchpad.exe 
      • 

    
 
    Note: The launchpad needs a web browser to run. If your system
does not have a web browser, take one of the following actions:
    • Install a web browser.
      • 

    • Install IBM Connections
in silent mode. For more information, see the Installing silently topic.
      • 

    • Start IBM Installation Manager
manually:
      1. Open a command prompt.
        2. 

      2. Change to the Connections_install/IM/OS directory, where OS is your operating
system.
        3. 

      3. Enter ./install.sh -input response.xml.
        4. 

      

      • 

    

    

    5. 

  5. Click Install IBM Connections 4.0 and then click Launch the IBM Connections 4.0 install
wizard. 
    Note: Click the links to Documentation,
Pre-installation tasks, or Post-installation tasks to view the product
documentation. 
    

    6. 

  6. In the Select packages to install window, select the packages
that you want to install and click Next to
continue. 
    Notes: 
    • Accept the default setting for Show all versions.
      • 

    • If you are using an earlier version of IBM Installation Manager than 1.4.4, the 1.4.4
package is selected in this window.
      • 

    • Click Check for Other Versions and Extensions to search for updates to IBM Installation Manager.
      • 

    

    

    7. 

  7. Review and accept the license agreement by clicking I accept the terms in the license agreements. Click Next. 
    8. 

  8. Specify the location of shared directories for IBM Installation Manager. 
    1. Specify the location of the Shared Resources
Directory.
      2. 

    2. Specify the location of the Installation
Manager Directory. This option appears only if you have
not previously installed IBM Installation Manager. 
      3. 

    3. Click Next.
      4. 

    
 
    Notes: 
    • The Shared Resources directory stores resources that can be shared
by multiple packages. If you used IBM Installation Manager before, the wizard automatically enters
this value.
      • 

    • The Installation Manager directory stores resources that are unique
to the packages that you are installing.
      • 

    

    

    9. 

  9. Choose to Use the existing package group or Create a new package group.  
    Note: If you are using the wizard for the first time, the Use the existing package group option is not available.
    

    10. 

  10. Specify the location of the installation directory for IBM Connections. You can accept
the default directory location, enter a new directory name, or click Browse to select an existing directory. Click Next.
    11. 

  11. Confirm the applications that you want to install and click Next. You can select from the following options:  
    Important: 
    • The
wizard always installs the Home page, News, and Search applications.
      • 

    • To
use media gallery widgets in the Communities application, you must
install the Files application. Media gallery widgets store photo and
video files in the Files database.
      • 

    • Even
if you are not configuring Cognos yet, install Metrics now so that
your application data is captured from the moment that IBM Connections
is deployed. Metrics captures your deployment data whereas Cognos
is used for viewing data reports. If you install Metrics at a later
stage, you will not have any data reports for the period before you
installed Metrics.
      • 

    

    


    

    Option
Description
    

    IBM Connections 4.0
Install all IBM Connections
applications.

    

    Activities
Collaborate with colleagues.

    

    Blogs
Write personal perspectives about projects.

    

    Communities
Interact with people on shared projects.

    

    Bookmarks
Bookmark important websites.

    

    Files
Share files among users.

    

    Forums
Discuss projects and exchange information.

    

    Metrics
Identify and analyze usage and trends.

    

    Mobile
Access IBM Connections
from mobile devices.

    

    Moderation
Forum and community owners can moderate the content of forums.

    

    Profiles
Find people in the organization.

    

    Wikis
Create content for your website.

    

    

    12. 

  12. Enter the details of your WebSphere Application Server environment: 
    1. Select
the WebSphere Application Server installation location that contains the Deployment Manager.  
      Note the default
path to the WebSphere Application
Server installation:
      • AIX: /usr/IBM/WebSphere/AppServer
        • 

      • Linux: /opt/IBM/WebSphere/AppServer
        • 

      • Windows: C:\Program
Files\IBM\WebSphere\AppServer
        • 

      

      

      2. 

    2. Enter
the properties of the WebSphere Application Server Deployment Manager (DM):  
      Deployment Manager profile
      

      Name of the DM to use for IBM Connections. The wizard automatically detects any available DMs.
      

      

      Host name
      

      Name of the host DM server.
      

      

      Administrator ID
      

      The administrative ID of the DM.
      Note: This ID is set to
the connectionsAdmin J2C authentication alias, which is mapped to
the following J2EE roles: dsx-admin, widget-admin, and search-admin.
It is also used by the service integration bus. If you plan to use
security management software such as Tivoli Access Manager or SiteMinder, the ID that you specify
here must exist in the LDAP directory. For more information, see the Switching to unique administrator IDs for system level communication topic. 
      

      

      

      Administrator Password
      

      The password for the administrative ID of the DM.
      

      

      SOAP port number
      

      The SOAP port number of the DM. The wizard automatically detects
this value.
      

      

      3. 

    3. Click Validate to verify the
DM information that you entered and that application security is enabled
on WebSphere Application
Server. If the verification fails, IBM Installation Manager displays an error message. 
      Note: (AIX and Linux) The validation process checks the number
of open files that are supported by your system. If the value for
this parameter, known as the Open File Descriptor limit, is too low,
a file open error, memory allocation failure, or connection establishment
error could occur. If one of these errors occurs, exit the installation
wizard and increase the open file limit before restarting the wizard.
To set the file limit, go to the Installation error messages topic and search for error code CLFRP0042E. The recommended value
for IBM Connections is 8192.
For more information about the Open File Descriptor limit, see the
documentation for your operating system.
      

      4. 

    4. When the verification test is successful, click Next.
      5. 

    
 The
wizard creates a dmInfo.properties file under WebSphere Application Server
to record details of the cell, node, and server.
    13. 

  13. Configure your topology. For more information about each
option, see the Deployment options topic. 
    Note: 
    If
you return to this page from a later page in the installation wizard,
your settings are still present but not visible.  If you want to change
any settings, you must enter all of the information again. If you
do not want to change your initial settings, click Next.
    

    

    • Small deployment:
      1. Select the Small deployment topology. 
        2. 

      2. Enter a Cluster name for the topology. 
        3. 

      3. Select a Node.
        4. 

      4. Click Next.
        5. 

      

      • 

    • Medium deployment:
      1. Select the Medium deployment topology. 
        2. 

      2. Select the default
value or enter a Cluster name for each application
or for groups of applications. For example, use Cluster1 for Activities,
Communities, and Forums. 
        Note: IBM Installation Manager creates servers and
clusters when required.
        

        3. 

      3. Select a Node for each cluster. Accept the predefined node or
select a different node.
        Note: These nodes host
application server instances that serve IBM Connections applications. You can assign multiple nodes
to a cluster, where each node is a server member of that cluster.
        

        4. 

      4. Enter a Server member name for the selected node. Choose the
default or enter a custom name.
        Note: If you enter a custom server
member name, the name must be unique across all nodes in your deployment.
        

        5. 

      5. Click Next.
        6. 

      

      • 

    • Large deployment:
      1. Select the Large deployment topology. 
        2. 

      2. Enter a Cluster name for each application. 
        Note: IBM Installation Manager creates servers and
clusters when required.
        

        3. 

      3. Select a Node for each cluster. Accept the predefined node or
select a different node.
        Note: These nodes host
application server instances that serve IBM Connections applications. You can assign multiple nodes
to a cluster, where each node is a server member of that cluster.
        

        4. 

      4. Enter a Server member name for the selected node. Choose the
default or enter a custom name.
        Note: If you enter a custom server
member name, the name must be unique across all nodes in your deployment.
        

        5. 

      5. Click Next.
        6. 

      

      • 

    

    14. 

  14. Enter the database information:  
    Note: 
    If
you return to this page from a later page in the installation wizard,
your settings are still present but not visible.  If you want to change
any settings, you must enter all of the information again. If you
do not want to change your initial settings, click Next.
    

    

    1. Specify whether the installed applications use the same
database server or instance: Select Yes or No. 
      Note: If allowed by your database configuration,
you can select multiple database instances as well as different database
servers.
      

      2. 

    2. Select
a Database type from one of the following options: 
      • IBM DB2 Universal Database™
        • 

      • Oracle Enterprise Edition
        • 

      • Microsoft SQL Server Enterprise
Edition
        • 

      

      3. 

    3. Enter
the Database server host name. For example: appserver.enterprise.example.com 
      If your
installed applications use different database servers, enter the database
host name for each application.
      

      4. 

    4. Enter
the Port number of the database server. The
default values are: 50000 for DB2, 1521 for Oracle, and 1433 for SQL Server. 
      If your
installed applications use different database servers or instances,
enter the port number for each database server or instance.
      

      5. 

    5. Enter
the JDBC driver location. For example: 
      • AIX:
        /usr/IBM/WebSphere/AppServer/lib
        

        • 

      • Linux:
        /opt/IBM/WebSphere/AppServer/lib
        

        • 

      • Windows:
        C:\IBM\WebSphere\Appserver\lib
        

        • 

      

      6. 

    6. Ensure
that the following JDBC driver libraries are present in the JDBC directory: 
      DB2
      

      db2jcc.jar and db2jcc_license_cu.jar
      Note: Ensure that your user account has the necessary permissions
to access the DB2 JDBC files.
      

      

      Oracle
      

      ojdbc6.jar
      

      SQL Server
      

      Download the SQL Server JDBC 2 driver from the Microsoft website to a local directory
and enter that directory name in the JDBC driver library field.
      The directory must not contain the sqljdbc.jar file, only the sqljdbc4.jar file. Even though
the data source is configured to use the sqljdbc4.jar file, an exception occurs if both files are present in the same
directory.
      

      IBM recommends that you obtain this Microsoft hotfix for the JDBC 2 driver for production deployments.
      

      

      

      7. 

    7. Enter the User ID and Password for each database. If each database
uses the same user credentials, select the Use the same
password for all applications check box and then enter
the user ID and password for the first database in the list.
      Note: 
      If your database
type is Oracle, you must connect to the database with the user ID
that you used when you created the application database. 
      

      

      8. 

    8. Click Validate to verify your
database settings. If the validation fails, check your database settings.
When the validation succeeds, click Next. 
      IBM Installation Manager tests your
database connection with the database values that you supplied. You
can change the database configuration later in the WebSphere Application Server Integrated
Solutions Console.
      

      9. 

    

    15. 

  15. Specify your Cognos configuration details as explained in the table, and then click Validate to verify your connection. 
    Note: 
    • The IBM Cognos configuration panel appears only if you chose to install
the Metrics application earlier in this task.
      • 

    • Ensure that Cognos Business Intelligence Server is running because
the wizard pings the server during the validation process.
      • 

    • If you do not want to deploy Cognos now, enter dummy values for
user ID and password, click Load node info,
and then click Validate. Ignore the error message
that appears. To continue installing IBM Connections, click Next. For information about deploying Cognos, see the Installing Cognos Business Intelligence topic. For information
about resolving Cognos validation problems, see the Troubleshooting
Cognos validation problems topic.
      • 

    

    


    

    Option
Description
    

    Administrator user ID
Type the user name of the administrator account that you selected
for Cognos Business Intelligence.
This user must be included in the LDAP directory used with Connections.

    

    Administrator password
Type the password for the Cognos administrator.

    

    Name
Click the Load node info button to
retrieve the list of available nodes and profiles, then click the
arrow and select the WebSphere profile that hosts the Cognos BI server. The profile you select here must match the profile you
specified as the was.profile.name in the cognos-setup.properties file.

    

    Host name
    
    		

    This is a non-editable field that is populated when you
select a profile in the Name field. Seeing
the associated host name for each profile/node can help you choose
the correct node where the Cognos BI Server is running.
    
    		

    

    Server name
There might be multiple servers installed on the same computer
as the Cognos BI server;
click the arrow and select the instance that represents the Cognos server. This value must
match what you specified as the cognos.was.server.name in the cognos-setup.properties file.
    Tip: A default value of cognos_server was assigned
in the properties file, so unless you changed that value, use it now.
    
    		

    

    Port
Type the number of the port that the Cognos BI Server is listening on; this defaults
to port 9080 but might have been changed. You can determine the port
by checking the WC_defaulthost value in the following
file: WAS_install_root/config/cells/Cell_Name/nodes/Node_Name/serverindex.xml; for example on Windows: 
    C:\Program Files\IBM\WebSphere\AppServer\profiles\AppSvr01\config\cells\lc40Cell01\nodes\lc40CellManager01\serverindex.xml
    
    		

    

    Web context root
The context root determines which requests will be delegated
to the Cognos application
for processing (any request beginning with this string will be handled
by Cognos). This value must
match the cognos.contextroot that you specified in
the cognos-setup.properties file.
    Tip: A default value of cognos was assigned in the properties
file, so unless you changed that value, use it now.
    
    		

    

    
 
    If you deployed Cognos Business Intelligence and the validation fails at this
point, you can click Next and continue installing IBM Connections. After the installation
is complete, you can correct the validation issue as explained in
the topic, Troubleshooting Cognos validation problems.
    

    16. 

  16. Specify the locations of the content stores. All nodes
in a cluster must have read-write access to shared content. Both shared
and local content stores must be accessible using the same path from
all nodes and from the DM. Each content store is represented by a
corresponding WebSphere variable that is further defined as shared or local. Local content
is node-specific. 
    Note: If you are migrating from IBM Connections 3.0.1, you can reuse
your existing content stores in 4.0. For more information, see the Content store migration topic.
    

    1. Enter
the location of the Shared content store. The shared content store usually resides in a shared repository
that grants read-write access to the DM 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: (Windows only) If you use Remote
Desktop Connection to map shared folder drives, ensure that you use
the same session to start the node agents. Otherwise, the shared drives
might be invisible to the nodes.
        

        • 

      

      2. 

    2. Enter
the location of the Local content store.
      3. 

    3. Click Validate to verify that
the account that you are using to install IBM Connections has write access to the content
store.
      4. 

    4. Click Next.
      5. 

    

    17. 

  17. Select
a Notification solution. Notifications are email messages to users
about new information and events in your IBM Connections deployment. 
    • Enable Notification only.
      Use notifications but without
the ReplyTo capability.
      

      • 

    • Enable Notification and ReplyTo.
      Use notifications and the
ReplyTo capability. To use ReplyTo, your mail server must be able
to receive all the replies and funnel these replies into a single
inbox. IBM Connection connects
to the mail server using the IMAP protocol.
      

      • 

    • None. 
      Do not use a notification solution in your IBM Connections deployment. You
can configure notifications after installation.
      

      • 

    

    18. 

  18. Select and specify a mail server solution and then click Next.
    • WebSphere Java Mail Session: Use a single mail server
for all notifications. Select this option if you can access an SMTP
server directly using the host name.
      

      Complete the following
fields to identify the mail server to use for sending email:
      Host name of SMTP messaging server
      

      Enter the host name or IP address of the preferred SMTP mail server.
      

      This SMTP server requires authentication
      

      Select the check box to force authentication when mail is sent
from this server.
      

      User ID
      

      If the SMTP server requires authentication, enter the user ID.
      

      Password
      

      If the SMTP server requires authentication, enter the user password.
      

      Encrypt outgoing mail traffic to the SMTP messaging server using
SSL
      

      Select this check box if you want to encrypt outgoing mail to
the SMTP server.
      

      Port
      

      Accept the default port of 25, or enter port 465 if you are using
SSL.
      

      

      

      • 

    • DNS MX
Records: Use information from DNS to determine which mail servers
to use. Select this option if you use a Domain Name System (DNS) server
to access the SMTP messaging server.
      

      Messaging domain name
      

      Enter the name or IP address of the messaging domain.
      

      Choose a specific DNS server
      

      Select this check box if you want to specify a unique SMTP server.
      

      DNS server for the messaging servers query
      

      Enter the host name or IP address of the DNS server.
      

      DNS port used for the messaging servers query 
      

      Enter the port number that is used for sending queries using the
messaging server.
      

      This SMTP server requires authentication
      

      Select the check box to force authentication when notification
mail is sent from this server.
      

      User ID
      

      If SMTP authentication is required, enter the administrator user
ID for the SMTP server.
      

      Password
      

      If SMTP authentication is required, enter the password for the
administrator user of the SMTP server.
      

      Encrypt outgoing mail traffic to the SMTP messaging server using
SSL
      

      Select the check box if you want to use the Secure Sockets Layer
(SSL) when connecting to the SMTP server.
      

      Port
      

      Specify the port number to use for the SMTP server connection.
The default port number for the SMTP protocol is 25. The default port
number for SMTP over SSL is 465.
      

      

      • 

    • If you click Do not enable Notification, IBM Installation Manager
skips the rest of this step. You can configure notification later.
      • 

    

    19. 

  19. If you selected the Notification and ReplyTo option, configure
the ReplyTo email settings. IBM Connections uses a unique ReplyTo address to identify both the person
who replied to a notification and the event or item that triggered
the notification. 
    1. Enter
a domain name. For example: mail.example.com. 
      Note: This domain name is used to build the ReplyTo address.
The address consists of the suffix or prefix, a unique key, and the
domain name. 
      

      2. 

    2. The
reply email address is given a unique ID by the system. You can customize
the address by adding a prefix or suffix, using a maximum of 28 characters.
This extra information is useful if the domain name is already in
use for other purposes. Select one of the following options:  
      None
      

      Use the ID generated by the system.
      

      Prefix
      

      Enter a prefix in the Example field.
      

      Suffix
      

      Enter a suffix in the Example field.
      

      

      As you select an option, the wizard creates an example
of the address, combining your selection with the ID generated by
the system.
      

      For example: 
      • unique_id@domain
        • 

      • prefix_unique_id@domain 
        • 

      • unique_id_suffix@domain - 
        • 

      

      

      3. 

    3. Specify
the details of the mail file to which ReplyTo emails are sent: 
      Server
      

      The domain where your mail server is located. For example: replyTo.mail.example.com.
      

      User ID
      

      The user account for the mail server. The user ID and password
are credentials that IBM Connections
will use to poll the inbox on the mail server to retrieve the replies
and process the content. IBM Connections connects to the mail server
using IMAP.
      

      Password
      

      Password for the user account. The user ID and password are credentials
that IBM Connections will use
to poll the inbox on the mail server to retrieve the replies and process
the content. IBM Connections connects to the mail server using IMAP.
      

      

      4. 

    4. Click Next.
      5. 

    
 
    Note: You
can modify the ReplyTo settings after installation. To edit the domain
name and prefix or suffix, edit the news-config.xml file. For more information, see the Post-migration step for
status updates topic. To edit the server and authentication
details, log in to the WebSphere Application Server Integrated Solutions Console and navigate to
the Mail Sessions page, where you can edit the configuration. 
    

    20. 

  20. Review the information that you have entered. To revise
your selections, click Back. To finalize the
installation, click Next.
    21. 

  21. Review the result of the installation. Click Finish to exit the installation wizard.
    22. 

  22. Restart
the Deployment Manager: 
    • AIX or Linux: Open a command prompt and change to
the profile_root/Dmgr01/bin directory. Enter the ./stopManager.sh
command and then enter the ./startManager.sh command.
      • 

    • Windows: Stop and restart
the Deployment Manager service.
      • 

    

    23. 

  23. Start
all the federated nodes and enter the startNode command. Repeat these steps for each node:
    1. Log in to a node.
      2. 

    2. From a command line, change to the profile_root/bin directory.
      3. 

    3. Enter the startNode command for
your operating system: 
      • AIX or Linux: ./startNode.sh
        • 

      • Windows: startNode.bat
        • 

      

      4. 

    

    24. 

  24. Log in
to the Integrated Solutions Console on the DM to perform a full synchronization
of all nodes.
    1. Go to System administration > Nodes.
      2. 

    2.  Select the nodes and click Full Resynchronize.
      3. 

    
 
    Note: Wait until the
DM copies all the application EAR files to the installedApps directory on each of  the nodes. This process can take up to 30
minutes. 
    To verify that the DM has distributed the application
EAR files to the nodes, check the SystemOut.log file of each node agent. The default path to the SystemOut.log file on a node is profile_root/logs/nodeagent.
    

    Look for a message such as the following example: ADMA7021I: Distribution of application application_name completed successfully. where application_name is the name of an IBM Connections
application.
    

    

    25. 

  25. Restart
the Deployment Manager.
    26. 

  26. Start
all your IBM Connections clusters:
    1. Log in to the Integrated Solutions Console
on the DM
      2. 

    2. Go to Servers > Clusters > WebSphere Application server
clusters.
      3. 

    3. Select the IBM Connections clusters and click Start.
      4. 

    
 
    Notes: 
    • If you installed a cluster with multiple Search nodes, you must
create the initial index. For more information about creating the
Search index, see the Creating the initial Search index topic.
      1. If you are installing a non-English language deployment, enable
Search dictionaries. For more information, see the Enabling
Search dictionaries topic.
        2. 

      2. The index is ready when the INDEX.READY and CRAWLING_VERSION files are present in the index directory.
        3. 

      

      • 

    • If some applications do not start, the file-copying process might
not have completed. Wait a few minutes and start the applications.
      • 

    

    

    27. 



Results
The installation wizard has installed IBM Connections in a network deployment.


To
confirm that the installation was successful, open the log files in
the connections_root/logs directory. Each IBM Connections application that you installed
has a log file, using the following naming format: application_nameInstall.log, where application_name is the name of an IBM Connections application. Search for the words error or exception to check whether any errors
or exceptions occurred during installation. 


To view the log
file for system events that occurred during the installation, open
the date_time.xml file, where date_time represents the date and time of the installation.
The file is located by default in the following directory: 
  • AIX or Linux (root user): /var/ibm/InstallationManager/logs
    • 

  • AIX or Linux (non-root user): /home/user/var/ibm/Installation Manager/logs where user is the non-root user name
    • 

  • Windows Server 2008 64-bit: C:\ProgramData\IBM\Installation Manager\logs
    • 







What to do next
Complete
the post-installation tasks that are relevant to your installation.
For more information, see the Post-installation tasks topic.


Accessing network shares:


If you installed WebSphere Application Server
on Microsoft Windows and configured it to run as a service,
ensure that you can access network shares. For more information, see
the Accessing Windows network shares topic.








Installing in console mode


Install IBM Connections
in console mode. This method is convenient if you cannot or do not
want to use the graphical mode.


Before you begin
Ensure
that you complete all the prerequisite tasks that are relevant for
your environment. For more information, see the Before installing topic.




About this task
Use console mode to complete the installation process in
a non-graphical environment. This mode is useful when you have to
install IBM Connections on a
system that does not have a video card. 
In steps where you enter
custom information, such as server details, you can type P at any
time to return to the previous input choice in that step. However,
you cannot type P to return to a previous step.


To install IBM Connections, you need to use IBM Installation Manager, which
manages the installation process. 


To install IBM Connections in console mode, complete the
following steps:




Procedure
  1. On each
node, stop any running instances of WebSphere Application Server and WebSphere node agents. 
    2. 

  2. Start WebSphere Application Server
Network Deployment Manager.
    3. 

  3. Copy
the installation files to the system hosting the Deployment Manager. 
    Note: Ensure that the directory path that you enter contains
no spaces.
    

    4. 

  4. Start IBM Installation
Manager in console mode: 
    Note: Run IBM Installation Manager on the
system where the Deployment Manager is installed.
    

    • If Installation Manager is already installed, open a command
prompt and change to the IBM Installation Manager installation directory. Then run the following
command:
      • AIX or Linux: /opt/IBM/InstallationManager/eclipse/tools/imcl
-c
        • 

      • Windows: \Program
Files\IBM\Installation Manager\eclipse\tools\imcl.exe -c
        • 

      

      • 

    • To install both IBM Installation
Manager and IBM Connections,
open a command prompt and change to the IBM Installation Manager installation directory. Then run the
following command:
      • AIX: Lotus_Connections_Install/IM/aix/install.console.sh
        • 

      • Linux: Lotus_Connections_Install/IM/linux/install.console.sh
        • 

      • Windows: Lotus_Connections_Install\IM\windows\install.console.bat
        • 

      

      The batch script calls a response file which contains information
about the repositories for both IBM Installation Manager and IBM Connections.
      

      • 

    • To use another language for the installation process, open
a command prompt, change to the IBM Installation Manager installation directory, and run the following
command: 
      • AIX: Lotus_Connections_Install/IM/aix/tools/imcl
-c -nl language_code
        • 

      • Linux: Lotus_Connections_Install/IM/linux/tools/imcl
-c -nl language_code
        • 

      • Windows: \Program
Lotus_Connections_Install\IM\windows\tools\imcl.exe -c -nl language_code
        • 

      

      where language_code is the two-letter code
for a language, such as fr for French.
      

      • 

    

    5. 

  5. In the console window, specify the IBM Connections repository: 
    Note: If you chose the option to run the install.console.bat|sh file in Step 4, you
can skip this step.
    

    1. Type P to edit preferences.
      2. 

    2. Type 1 to specify repositories.
      3. 

    3. Type D to add a repository.
      4. 

    4. Type the repository path for IBM Connections 4.0, for example: Lotus_Connections/repository.xml.
      5. 

    5. Type A to save the repository
information.
      6. 

    6. Type C to return to the console
window.
      7. 

    

    6. 

  6. In the Select packages to install step, type 1 to select the package and then type N to proceed.
    7. 

  7. Review the license agreement by typing the appropriate
number to view license information. To accept the license agreement,
type A. Type N to proceed.
    8. 

  8. Specify the location of the shared resources directory
for IBM Installation Manager. 
    1. Enter the location of the Shared Resources
Directory.
      2. 

    2. Type N to proceed.
      3. 

    
 
    Notes: 
    • The Shared Resources directory stores resources that can be shared
by multiple packages. If you used IBM Installation Manager before, the wizard automatically enters
this value.
      • 

    • Ensure that
the directory path that you enter contains no spaces.
      • 

    

    

    9. 

  9. Specify the location of the IBM Installation Manager installation directory. 
    1. Enter the location of the Installation Manager
Directory. 
      2. 

    2. Type N to proceed.
      3. 

    
 
    Notes: 
    • This option is available only if you have not previously installed IBM Installation Manager. 
      • 

    • The Installation Manager directory stores resources that are unique
to the packages that you are installing. 
      • 

    • Ensure that
the directory path that you enter contains no spaces.
      • 

    

    

    10. 

  10. Specify the locations of the package group for IBM Installation Manager and the
installation directory for IBM Connections:
    1. The wizard automatically detects the IBM Connections package group. Type M to change the default location where the package group
will be installed.
      2. 

    2. Type N to proceed.
      3. 

    3. To accept the default location for the IBM Connections installation directory, type N.  To specify a new directory name, type M and enter the new directory name and path. 
      4. 

    4. Type N to proceed.
      5. 

    

    11. 

  11. Select the applications that you want to install and then
type N to proceed. You can select from the
following options:  
    Important: 
    • The
wizard always installs the Home page, News, and Search applications.
      • 

    • If you clear the selections of the Home page, News, or Search
applications, the wizard will exit.
      • 

    • To
use media gallery widgets in the Communities application, you must
install the Files application. Media gallery widgets store photo and
video files in the Files database.
      • 

    • Even
if you are not configuring Cognos yet, install Metrics now so that
your application data is captured from the moment that IBM Connections
is deployed. Metrics captures your deployment data whereas Cognos
is used for viewing data reports. If you install Metrics at a later
stage, you will not have any data reports for the period before you
installed Metrics.
      • 

    

    


    

    Option
Description
    

    IBM Connections 4.0
Install all IBM Connections
applications.

    

    Activities
Collaborate with colleagues.

    

    Blogs
Write personal perspectives about projects.

    

    Communities
Interact with people on shared projects.

    

    Bookmarks
Bookmark important websites.

    

    Files
Share files among users.

    

    Forums
Discuss projects and exchange information.

    

    Metrics
Identify and analyze usage and trends.

    

    Mobile
Access IBM Connections
from mobile devices.

    

    Moderation
Forum and community owners can moderate the content of forums.

    

    Profiles
Find people in the organization.

    

    Wikis
Create content for your website.

    

    

    12. 

  12. Enter the details
of your WebSphere Application
Server environment: 
    1. Select
the WebSphere Application Server installation location that contains the Deployment Manager.  
      Note the default
path to the WebSphere Application
Server installation:
      • AIX: /usr/IBM/WebSphere/AppServer
        • 

      • Linux: /opt/IBM/WebSphere/AppServer
        • 

      • Windows: C:\Program
Files\IBM\WebSphere\AppServer
        • 

      

      

      2. 

    2. Enter
the properties of the WebSphere Application Server Deployment Manager (DM):  
      Deployment Manager profile
      

      Name of the DM to use for IBM Connections. The wizard automatically detects any available DMs.
      

      

      Host name
      

      Name of the host DM server.
      

      

      Administrator ID
      

      The administrative ID of the DM.
      Note: This ID is set to
the connectionsAdmin J2C authentication alias, which is mapped to
the following J2EE roles: dsx-admin, widget-admin, and search-admin.
It is also used by the service integration bus. If you plan to use
security management software such as Tivoli Access Manager or SiteMinder, the ID that you specify
here must exist in the LDAP directory. For more information, see the Switching to unique administrator IDs for system level communication topic. 
      

      

      

      Administrator Password
      

      The password for the administrative ID of the DM.
      

      

      SOAP port number
      

      The SOAP port number of the DM. The wizard automatically detects
this value.
      

      

      3. 

    3. Press Enter to verify the DM
information that you entered. The verification process also checks
that application security is enabled on WebSphere Application Server. If the verification
fails, IBM Installation Manager
displays an error message. 
      Note: (AIX and Linux) The validation process checks the number
of open files that are supported by your system. If the value for
this parameter, known as the Open File Descriptor limit, is too low,
a file open error, memory allocation failure, or connection establishment
error could occur. If one of these errors occurs, exit the installation
wizard and increase the open file limit before restarting the wizard.
To set the file limit, go to the Installation error messages topic and search for error code CLFRP0042E. The recommended value
for IBM Connections is 8192.
For more information about the Open File Descriptor limit, see the
documentation for your operating system.
      

      4. 

    4. If
the verification check is successful, type N to proceed. If verification fails, press B to re-enter the required information.
      5. 

    
 The
wizard creates a dmInfo.properties file under WebSphere Application Server
to record details of the cell, node, and server.
    13. 

  13. Configure your topology. For more information about each option,
see the Deployment options topic.
    • Small deployment:
      1. Type 1 to select the Small deployment topology. 
        2. 

      2. Enter a Cluster name for the topology. 
        3. 

      3. Select a Node.
        4. 

      4. Enter a Server member name for the node. 
        5. 

      5. Type N to
proceed.
        6. 

      

      • 

    • Medium deployment:
      1. Type 2 to select the Medium
deployment topology. 
        2. 

      2. Select the default
value or enter a Cluster name for each application
or for groups of applications. For example, use Cluster1 for Activities,
Communities, and Forums. 
        Note: IBM Installation Manager creates servers and
clusters when required.
        

        3. 

      3. Select a Node for each cluster. Accept the predefined node or
select a different node.
        Note: These nodes host
application server instances that serve IBM Connections applications. You can assign multiple nodes
to a cluster, where each node is a server member of that cluster.
        

        4. 

      4. Enter a Server member name for the selected node. Choose the
default or enter a custom name.
        Note: If you enter a custom server
member name, the name must be unique across all nodes in your deployment.
        

        5. 

      5. The topology
that you specified is displayed. To re-specify any details, type the
number that corresponds to the application; for example, type 1 for Activities. 
        6. 

      6. Type N to
proceed.
        7. 

      

      • 

    • Large deployment:
      1. Type 3 to select the Large deployment topology. 
        2. 

      2. Enter a Cluster name for each application. 
        Note: IBM Installation Manager creates servers and
clusters when required.
        

        3. 

      3. Select a Node for each cluster. Accept the predefined node or
select a different node.
        Note: These nodes host
application server instances that serve IBM Connections applications. You can assign multiple nodes
to a cluster, where each node is a server member of that cluster.
        

        4. 

      4. Enter a Server member name for the selected node. Choose the
default or enter a custom name.
        Note: If you enter a custom server
member name, the name must be unique across all nodes in your deployment.
        

        5. 

      5. The topology
that you specified is displayed. To re-specify any details, type the
number that corresponds to the application; for example, type 1 for Activities. 
        6. 

      6. Type N to
proceed.
        7. 

      

      • 

    

    14. 

  14. Enter the database information: 
    1. Specify whether the installed applications use the same
database server or instance: Type 1 to specify
that the applications use same database server or instance; type 2 to specify that they use different database servers
or instances. 
      Note: If allowed by your database configuration,
you can select multiple database instances as well as different database
servers.
      

      2. 

    2. Select
a Database type from one of the following options: 
      • IBM DB2 Universal Database
        • 

      • Oracle Enterprise Edition
        • 

      • Microsoft SQL Server Enterprise
Edition
        • 

      

      3. 

    3. Enter
the Database server host name. For example: appserver.enterprise.example.com 
      If your
installed applications use different database servers, enter the database
host name for each application.
      

      4. 

    4. Enter
the Port number of the database server. The
default values are: 50000 for DB2, 1521 for Oracle, and 1433 for SQL Server. 
      If your
installed applications use different database servers or instances,
enter the port number for each database server or instance.
      

      5. 

    5. Enter
the JDBC driver location. For example: 
      • AIX:
        /usr/IBM/WebSphere/AppServer/lib
        

        • 

      • Linux:
        /opt/IBM/WebSphere/AppServer/lib
        

        • 

      • Windows:
        C:\IBM\WebSphere\Appserver\lib
        

        • 

      

      6. 

    6. Ensure
that the following JDBC driver libraries are present in the JDBC directory: 
      DB2
      

      db2jcc.jar and db2jcc_license_cu.jar
      Note: Ensure that your user account has the necessary permissions
to access the DB2 JDBC files.
      

      

      Oracle
      

      ojdbc6.jar
      

      SQL Server
      

      Download the SQL Server JDBC 2 driver from the Microsoft website to a local directory
and enter that directory name in the JDBC driver library field.
      The directory must not contain the sqljdbc.jar file, only the sqljdbc4.jar file. Even though
the data source is configured to use the sqljdbc4.jar file, an exception occurs if both files are present in the same
directory.
      

      IBM recommends that you obtain this Microsoft hotfix for the JDBC 2 driver for production deployments.
      

      

      

      7. 

    7. Enter the User ID and Password for each database. If each database
uses the same user credentials, confirm the Use the same
password for all applications question and then enter
the user ID and password for the first database in the list.
      Note: 
      If your database
type is Oracle, you must connect to the database with the user ID
that you used when you created the application database. 
      

      

      8. 

    8. If you need to make changes, type the number that corresponds
to the application that you want to change. Alternatively, type R to reset all the database specifications to their default
values.
      9. 

    9. Press Enter to verify your database
settings. If the validation fails, check your database settings. When
the validation succeeds, click Next. 
      IBM Installation Manager tests your
database connection with the database values that you supplied. You
can change the database configuration later in the WebSphere Application Server Integrated
Solutions Console.
      

      10. 

    10. If
the verification check is successful, type N to proceed. If verification fails, press B to re-enter the required information.
      11. 

    

    15. 

  15. Specify your Cognos configuration.  
    Notes: 
    • The IBM Cognos configuration panel appears only if you chose to install
the Metrics application earlier in this task.
      • 

    • If you do not want to configure Cognos now, enter dummy values
for user ID and password, and select any values from the list of nodes
and servers. Then press Enter and ignore the
validation error message that appears. To continue installing IBM
Connections, type N. For information about
configuring Cognos after installation, see the Installing Cognos
Business Intelligence topic. For information about resolving
Cognos validation problems, see the Troubleshooting Cognos validation
problems topic.
      • 

    

    

    1. Enter the LDAP user ID for the Cognos administrator.
      2. 

    2. Enter the password for the Cognos administrator.
      3. 

    3. Select the node where the Cognos BI Server is installed.
      4. 

    4. Enter the port number of the Cognos server.
      5. 

    5. Enter the web context root.
      6. 

    6. Press Enter to validate the configuration.
      7. 

    7. Type N to
proceed.
      8. 

    

    16. 

  16. Specify the locations of the content stores. Shared content
must be read/write accessible by all nodes in a cluster. Both shared
and local content stores must be accessible using the same path from
all nodes and the DM. Local content is node-specific. Each content
store is represented by a corresponding WebSphere variable that is further defined
as shared or local. 
    Note: If you are migrating from IBM Connections 3.0.1, you can reuse
your existing content stores in 4.0. For more information, see the Content store migration topic.
    

    1. Enter
the location of the Shared content store. The shared content store usually resides in a shared repository
that grants read-write access to the DM 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: (Windows only) If you use Remote
Desktop Connection to map shared folder drives, ensure that you use
the same session to start the node agents. Otherwise, the shared drives
might be invisible to the nodes.
        

        • 

      

      2. 

    2. Enter
the location of the Local content store.
      3. 

    3. Press Enter to verify that the
account that you are using to install IBM Connections has write access to the content store.
      4. 

    4. Click Next.
      5. 

    

    17. 

  17. Select
a Notification solution. Notifications are email messages to users
about new information and events in your IBM Connections deployment. 
    • Enable Notification only.
      Use notifications but without
the ReplyTo capability.
      

      • 

    • Enable Notification and ReplyTo.
      Use notifications and the
ReplyTo capability. To use ReplyTo, your mail server must be able
to receive all the replies and funnel these replies into a single
inbox. IBM Connection connects
to the mail server using the IMAP protocol.
      

      • 

    • None. 
      Do not use a notification solution in your IBM Connections deployment. You
can configure notifications after installation.
      

      • 

    

    18. 

  18. If you chose a mail notification option, select and specify
a mail server solution.
    • WebSphere Java Mail Session: Use a single mail server
for all notifications. Select this option if you can access an SMTP
server directly using the host name.
      

      Identify the mail server to use for sending email:
      Host name of SMTP messaging server
      

      Enter the host name or IP address of the preferred SMTP mail server.
      

      This SMTP server requires authentication
      

      Enter Y to force authentication when mail
is sent from this server.
      

      User ID
      

      If the SMTP server requires authentication, enter the user ID.
      

      Password
      

      If the SMTP server requires authentication, enter the user password.
      

      Encrypt outgoing mail traffic to the SMTP messaging server using
SSL
      

      If you want to encrypt outgoing mail to the SMTP server, press Y.
      

      Port
      

      Press Enter to accept the default port
of 25, or enter 465 if you are using SSL.
      

      

      

      • 

    • DNS MX
Records: Use information from DNS to determine which mail servers
to use. Select this option if you use a Domain Name System (DNS) server
to access the SMTP messaging server.
      

      Messaging domain name
      

      Enter the name or IP address of the messaging domain.
      

      Choose a specific DNS server
      

      To specify a unique SMTP server, press Y.
      

      DNS server for the messaging servers query
      

      Enter the host name or IP address of the DNS server.
      

      DNS port used for the messaging servers query 
      

      Enter the port number that is used for sending queries using the
messaging server.
      

      This SMTP server requires authentication
      

      Enter Y to force authentication when mail
is sent from this server.
      

      User ID
      

      If SMTP authentication is required, enter the administrator user
ID for the SMTP server.
      

      Password
      

      If SMTP authentication is required, enter the password for the
administrator user of the SMTP server.
      

      Encrypt outgoing mail traffic to the SMTP messaging server using
SSL
      

      If you want to encrypt outgoing mail to the SMTP server, press Y.
      

      Port
      

      Press Enter to accept the default port
of 25, or enter 465 if you are using SSL.
      

      

      • 

    • If you specify Do not enable Notification, IBM Installation Manager
skips the rest of this step. You can configure notification later.
      • 

    

    19. 

  19. If you selected the Notification and ReplyTo option, configure
the ReplyTo email settings. IBM Connections uses a unique ReplyTo address to identify both the person
who replied to a notification and the event or item that triggered
the notification. 
    1. Enter
a domain name. For example: mail.example.com. 
      Note: This domain name is used to build the ReplyTo address.
The address consists of the suffix or prefix, a unique key, and the
domain name. 
      

      2. 

    2. The
reply email address is given a unique ID by the system. You can customize
the address by adding a prefix or suffix, using a maximum of 28 characters.
This extra information is useful if the domain name is already in
use for other purposes. Select one of the following options:  
      None
      

      Use the ID generated by the system.
      

      Prefix
      

      Enter a prefix in the Example field.
      

      Suffix
      

      Enter a suffix in the Example field.
      

      

      As you select an option, the wizard creates an example
of the address, combining your selection with the ID generated by
the system.
      

      For example: 
      • unique_id@domain
        • 

      • prefix_unique_id@domain 
        • 

      • unique_id_suffix@domain - 
        • 

      

      

      3. 

    3. Specify
the details of the mail file to which ReplyTo emails are sent: 
      Server
      

      The domain where your mail server is located. For example: replyTo.mail.example.com.
      

      User ID
      

      The user account for the mail server. The user ID and password
are credentials that IBM Connections
will use to poll the inbox on the mail server to retrieve the replies
and process the content. IBM Connections connects to the mail server
using IMAP.
      

      Password
      

      Password for the user account. The user ID and password are credentials
that IBM Connections will use
to poll the inbox on the mail server to retrieve the replies and process
the content. IBM Connections connects to the mail server using IMAP.
      

      

      4. 

    4. Click Next.
      5. 

    
 
    Note: You
can modify the ReplyTo settings after installation. To edit the domain
name and prefix or suffix, edit the news-config.xml file. For more information, see the Post-migration step for
status updates topic. To edit the server and authentication
details, log in to the WebSphere Application Server Integrated Solutions Console and navigate to
the Mail Sessions page, where you can edit the configuration. 
    

    20. 

  20. Review the information that you entered. To revise your
selections, press B. To continue installing,
 press N.
    21. 

  21. To install the product, press I. To generate a response
file, press G.
    22. 

  22. Review the result of the installation. Press F to exit the installation wizard.
    23. 

  23. Restart
the Deployment Manager: 
    • AIX or Linux: Open a command prompt and change to
the profile_root/Dmgr01/bin directory. Enter the ./stopManager.sh
command and then enter the ./startManager.sh command.
      • 

    • Windows: Stop and restart
the Deployment Manager service.
      • 

    

    24. 

  24. Start
all the federated nodes and enter the startNode command. Repeat these steps for each node:
    1. Log in to a node.
      2. 

    2. From a command line, change to the profile_root/bin directory.
      3. 

    3. Enter the startNode command for
your operating system: 
      • AIX or Linux: ./startNode.sh
        • 

      • Windows: startNode.bat
        • 

      

      4. 

    

    25. 

  25. Log in
to the Integrated Solutions Console on the DM to perform a full synchronization
of all nodes.
    1. Go to System administration > Nodes.
      2. 

    2.  Select the nodes and click Full Resynchronize.
      3. 

    
 
    Note: Wait until the
DM copies all the application EAR files to the installedApps directory on each of  the nodes. This process can take up to 30
minutes. 
    To verify that the DM has distributed the application
EAR files to the nodes, check the SystemOut.log file of each node agent. The default path to the SystemOut.log file on a node is profile_root/logs/nodeagent.
    

    Look for a message such as the following example: ADMA7021I: Distribution of application application_name completed successfully. where application_name is the name of an IBM Connections
application.
    

    

    26. 

  26. Restart
the Deployment Manager.
    27. 

  27. Start
all your IBM Connections clusters:
    1. Log in to the Integrated Solutions Console
on the DM
      2. 

    2. Go to Servers > Clusters > WebSphere Application server
clusters.
      3. 

    3. Select the IBM Connections clusters and click Start.
      4. 

    
 
    Notes: 
    • If you installed a cluster with multiple Search nodes, you must
create the initial index. For more information about creating the
Search index, see the Creating the initial Search index topic.
      1. If you are installing a non-English language deployment, enable
Search dictionaries. For more information, see the Enabling
Search dictionaries topic.
        2. 

      2. The index is ready when the INDEX.READY and CRAWLING_VERSION files are present in the index directory.
        3. 

      

      • 

    • If some applications do not start, the file-copying process might
not have completed. Wait a few minutes and start the applications.
      • 

    

    

    28. 



Results
The installation wizard has installed IBM Connections in a network deployment.


To
confirm that the installation was successful, open the log files in
the connections_root/logs directory. Each IBM Connections application that you installed
has a log file, using the following naming format: application_nameInstall.log, where application_name is the name of an IBM Connections application. Search for the words error or exception to check whether any errors
or exceptions occurred during installation. 


To view the log
file for system events that occurred during the installation, open
the date_time.xml file, where date_time represents the date and time of the installation.
The file is located by default in the following directory: 
  • AIX or Linux (root user): /var/ibm/InstallationManager/logs
    • 

  • AIX or Linux (non-root user): /home/user/var/ibm/Installation Manager/logs where user is the non-root user name
    • 

  • Windows Server 2008 64-bit: C:\ProgramData\IBM\Installation Manager\logs
    • 







What to do next
Complete
the post-installation tasks that are relevant to your installation.
For more information, see the Post-installation tasks topic.


Accessing network shares:


If you installed WebSphere Application Server
on Microsoft Windows and configured it to run as a service,
ensure that you can access network shares. For more information, see
the Accessing Windows network shares topic.








Installing silently


Silent installation is a tool for installing the same IBM Connections profile on multiple
computers without using the IBM Installation
Manager. This simplifies the installation process in enterprises that
need multiple, identical instances of IBM Connections.


Silent installation uses installation parameters in a response
file to install identical IBM Connections
profiles on different computers. To specify silent installation parameters
you can edit the default response file provided with IBM Connections, or create a new file.


In addition to silently installing IBM Connections,
you can use the silent installation process to modify, update, or
uninstall IBM Connections.




Installing IBM Connections
in silent mode (with an existing IBM Installation Manager)


Use a silent installation to perform an identical installation
of IBM Connections on multiple
systems.


Before you begin
Ensure
that you complete all the prerequisite tasks that are relevant for
your environment. For more information, see the Before installing topic.


Ensure that IBM Installation
Manager is installed on your system. To prevent errors caused by using
the wrong version of  IBM Installation
Manager, remove the following line from the default response file: 
<offering id='com.ibm.cic.agent' version='1.4.4000.20110525_1254' profile='IBM Installation Manager' features='agent_core,agent_jre' installFixes='none'/>




To create a customized version of the default response file,
run the installation wizard in interactive mode. For more information,
see the Creating a response file topic.




About this task
Using
a response file for your intended deployment, install IBM Connections on multiple systems without needing
to interact with the installation wizard. 


To
perform a silent installation, complete the following steps:




Procedure
  1. Open
a command prompt and navigate to the IM_root/eclipse/tools directory. 
    2. 

  2. Enter
the following command: 
    • AIX or Linux: ./imcl -input response_file -log log_file -acceptLicense
      • 

    • Windows: imcl.exe -input response_file -log log_file
-acceptLicense
      Note: The IM_root/eclipse directory contains a similar
file called IBMIM.exe but that file is not suitable
for silent installation.
      

      • 

    
 
    where response_file is the full path and
name of the response file and log_file is the full
path and name of the log file. The default name of the response file
is LC.rsp. By default, the response file is in
the following directory:

    
 Compare the following examples to your environment:
    • AIX or Linux: ./imcl -input /opt/IBM_Connections_Install/IBMConnections/LC.rsp
-log /mylog/silent_install_log.xml  -acceptLicense
      • 

    • Windows: imcl.exe
-input E:\IBM_Connections_Install\IBMConnections\LC.rsp -log \mylog\silent_install_log.xml
-acceptLicense
      • 

    

    3. 



Results
IBM Installation Manager writes
the result of the installation command to the log file that you specified
with the -log parameter. 


To check the complete
details of the installation, open each of the log files in the connections_root/logs directory. Each IBM Connections application that you installed
has a log file, using the following naming format: applicationInstallog.txt, where application is the name of an IBM Connections
application. 


If the installation is successful, the log files are empty. For example: 
<?xml version="1.0" encoding="UTF-8"?>
<result>
</result>

The log file contains an error element if
the operation was not completed successfully. A successful installation
adds a value of 0 to the log file. An unsuccessful installation adds
a positive integer to the log file.


The log file for IBM Installation Manager records
the values that you entered when you ran IBM Installation Manager in interactive mode. To review the
log file for IBM Installation
Manager, open the date_time.xml file, where date_time represents the date and
time of the installation. The file by default is in the following
directory: 
  • AIX or Linux (root user): /var/ibm/InstallationManager/logs
    • 

  • AIX or Linux (non-root user): user_home/var/ibm/InstallationManager/logs where user_home is the non-root user account directory
    • 

  • Windows (administrator): C:\ProgramData\IBM\Installation Manager\logs
    • 

  • Windows (non-administrator): C:\Documents and Settings\user\Application Data\IBM\Installation
Manager\logs  where user is the non-administrator
user account
    • 







What to do next
Complete
any applicable post-installation tasks. For more information, see
the Post-installation tasks topic.








Installing IBM Connections
and IBM Installation Manager
in silent mode


Use a silent installation to perform an identical installation
of IBM Connections and IBM Installation Manager on multiple
systems.


Before you begin
This task assumes that IBM Installation Manager is not installed on your system.


Ensure
that you complete all the prerequisite tasks that are relevant for
your environment. For more information, see the Before installing topic.


Note: However, do not complete the prerequisite tasks that relate
to IBM Installation Manager.


Edit the default response file to suit your environment. For more
information, see the Using the default response file topic.




About this task
Using
a response file for your intended deployment, install IBM Connections on multiple systems without needing
to interact with the installation wizard. 


To
perform a silent installation, complete the following steps:




Procedure
  1. Open a command prompt and go to the location of the silent
installation file. The file is stored in the IBM_Connections_set-up/IBM_Connections_install/IM/OS directory,
where IBM_Connections_set-up is the directory or
media where the IBM Connections
installation files are located and OS represents
your operating system 
    Note: To change the paths to the
response file and log file, edit the lc_install.ini file. The file is located in the IBM_Connections_set-up/IBM_Connections_install/IM/OS directory. 
    

    2. 

  2. Run the silent installation script: 
    • AIX or Linux (root user): ./installc -input response_file -log log_file -acceptLicense
      • 

    • AIX or Linux (non-root user): ./userinstc
-input response_file -log log_file -acceptLicense
      • 

    • Windows (administrator):
 installc.exe -input response_file -log log_file -acceptLicense
      • 

    • Windows (non-administrator):
 userinstc.exe -input response_file -log log_file -acceptLicense
      • 

    
 
    where response_file is the full path and
name of the response file and log_file is the full
path and name of the log file. The default name of the file is LC.rsp.
    

    By default, the response file is stored
in the IBM_Connections_set-up/IBM_Connections_install/IBMConnecgtions directory on the installation media.
    

    3. 



Results
IBM Installation Manager writes
the result of the installation command to the log file that you specified
with the -log parameter. 


To check the complete
details of the installation, open each of the log files in the connections_root/logs directory. Each IBM Connections application that you installed
has a log file, using the following naming format: applicationInstallog.txt, where application is the name of an IBM Connections
application. 


If the installation is successful, the log files are empty. For example: 
<?xml version="1.0" encoding="UTF-8"?>
<result>
</result>

The log file contains an error element if
the operation was not completed successfully. A successful installation
adds a value of 0 to the log file. An unsuccessful installation adds
a positive integer to the log file.


The log file for IBM Installation Manager records
the values that you entered when you ran IBM Installation Manager in interactive mode. To review the
log file for IBM Installation
Manager, open the date_time.xml file, where date_time represents the date and
time of the installation. The file by default is in the following
directory: 
  • AIX or Linux (root user): /var/ibm/InstallationManager/logs
    • 

  • AIX or Linux (non-root user): user_home/var/ibm/InstallationManager/logs where user_home is the non-root user account directory
    • 

  • Windows (administrator): C:\ProgramData\IBM\Installation Manager\logs
    • 

  • Windows (non-administrator): C:\Documents and Settings\user\Application Data\IBM\Installation
Manager\logs  where user is the non-administrator
user account
    • 







What to do next
Complete
any applicable post-installation tasks. For more information, see
the Post-installation tasks topic.








The default response file


Response files provide input parameters for silent installations
of IBM Connections. 


The default response file for AIX and Linux is called LC.rsp and is located in the IBM Connections set-up directory or installation
media. You can edit this file and use it as input for a silent installation. 
Note: IBM does not provide a default response file on Windows because it
is more convenient if you to generate the file yourself. For information
about generating a response file, see the Creating a response
file topic.




Instead
of generating a new response file, you can edit the default response
file that is provided with the product. However, if you edit the default
response file, you need to add encrypted passwords to the file. For
more information, see the Creating encrypted passwords for a
response file topic.






Using the default response file


Use the default response file to specify silent installation
parameters for your environment.


Before you begin
Encrypt your administrator passwords. For more information
about encrypting passwords, see the Creating encrypted passwords
for a response file topic.


About this task
Silent installation uses the parameters in a response
file to install the same IBM Connections profile on multiple computers. 


If you are silently
installing IBM Connections as
a non-root user in an AIX or Linux environment, you must specify
that parameter in the silent-install.ini file.




Procedure
  1. Navigate to the connections_root directory and open the LC.rsp response file.
    2. 

  2. Specify your installation parameters. For more information,
see the Default response file topic.
    3. 

  3. Add the encrypted passwords to the relevant elements of
the response file. The following example shows the elements for the
Activities passwords: 
    <data key='user.activities.adminuser.password' value='encrypted_password'/>
    

    <data key='user.activities.dbUserPassword value='encrypted_password'/>
    

    where encrypted_password is the password after you encrypted it.
    

    4. 

  4. Change the default WebSphere Application Server administrator name from wasadmin if your administrator name is different.
    5. 

  5. Save your changes.
    6. 

  6. If you are performing the silent installation as a non-root
user on AIX or Linux systems, complete the following steps:
    1. Open the silent-install.ini file
for editing from the following location: 
      • AIX: IBM_Connections_set-up/IBM_Connections_install/IM/aix/silent-install.ini 
        • 

      • Linux: IBM_Connections_set-up/IBM_Connections_install/IM/linux/silent-install.ini 
        • 

      • Linux on System z: IBM_Connections_set-up/IBM_Connections_install_s390/IM/zlinux/silent-install.ini 
        • 

      

      where IBM_Connections_set-up is the IBM Connections set-up directory
or installation media.
      

      2. 

    2. In the second line of the file, change admin to nonadmin.
      3. 

    3. Save and close the file.
      4. 

    

    7. 







Creating a response file


Use a response file to install, modify, update, or uninstall IBM Connections without user interaction.


Before you begin
You can create a response file by using IBM Installation Manager or by editing the file
that is provided with the product. For more information about editing
the file, see the Default response file topic.


Ensure that IBM Installation
Manager is installed. For more information, see the Installing IBM Connections 4.0 topic. 


To ensure that the response file captures the details of your
SSL certificates, start IBM WebSphere Application Server.


The default location of a response file that you generate is the connections_root/silentResponseFile directory. To specify
a different location, edit the generate_install_responsefile.bat|sh file or generate_other_responsefile.bat|sh file,
depending on the task that you want to carry out.


Instead of
creating your own response file, you can edit the file that is provided
with the product. The file is in the IBM_Connections_set-up/IBM_Connections_install/IBMConnections directory.  However,
this default file is applicable only for installation. The response
files for modifying, updating, rolling back, and uninstalling the
product are based on the response file for installation. Before you
create a response file for any of those procedures, you must first
run the silent installation procedure.


For more information
about creating response files with IBM Installation Manager, go to the Recording a response file with Installation Manager webpage. 




About this task
This task describes the procedure to generate a response
file for the following procedures:
  • Installing IBM Connections
    • 

  • Modifying an existing installation by adding or removing IBM Connections applications
    • 

  • Updating an existing installation by installing a fix pack
    • 

  • Rolling back an update
    • 

  • Uninstalling IBM Connections
    • 





For each procedure, run a simulated instance of the IBM Installation Manager and record
your input to a response file. Later, you can run a silent command
that uses this response file as an input parameter.


Default
response files on AIX or Linux:
Install


LC.rsp


Modify - Add


LC_modify_add.rsp


Modify - Remove


LC_modify_remove.rsp


Update


LC_update.rsp


Roll back


LC_rollback.rsp


Uninstall


LC_uninstall.rsp






To create a response file, complete the following
steps:




Procedure
  1. Open a command prompt and go to the IM_root/eclipse directory.
    2. 

  2. Ensure that the IBM_Connections_set-up/IBM_Connections_install/IM/OS/skip directory allows write access, where IBM_Connections_set-up is the directory or media where the IBM Connections installation files are located, and OS represents your operating system. 
    3. 

  3. Run the command to record a response file. This command
uses the -skipInstall agentDataLocation argument, which records the
installation commands without installing IBM Connections. Substitute your own file name and path for
the response file. Verify that the file paths that you enter exist
because IBM Installation Manager
does not create directories for the response file. 
    • AIX and Linux: ./IBMIM -record /response_files/install_product.xml
-skipInstall agentDataLocation
      • 

    • Microsoft Windows: IBMIM.exe -record responseFile
-skipInstall agentDataLocation
      • 

    

    where agentDataLocation is the file path
to the skip directory, which stores IBM Installation Manager data files.
    

    Note: 
    • The -log option is not available when recording a response file.
      • 

    • Use quotation marks around file paths that contain spaces.
      • 

    • You can use the same agentDataLocation parameter in the next recording
session to update, modify, roll back or uninstall IBM Connections. However, if you want to record
a new installation, you must specify a new agentDataLocation parameter.
      • 

    

    

    4. 

  4. Enter the required information in the IBM Installation Manager.
    • To install a new deployment, open Files > Preferences, and enter the path to the IBM Connections repository; for example: C:\build\\IBM_Connections_Install\IBMConnections. Click Install and enter the required information
as if you were installing the product. For more information, see the Installing IBM Connections 4.0 topic.
      • 

    

    • To modify an existing installation, click Modify and enter the required information.
      • To add applications, select the applications that you want to
add in the Application Selection pane.
        Note: Ensure that all the currently
installed applications are also selected.
        

        • 

      • To remove applications, clear the check boxes of the applications
that you want to remove in the Application Selection pane.
        • 

      

      For more information, see the Modifying the installation
in interactive mode topic.
      

      • 

    

    • To update an existing installation, click Update and enter the required information.
      • 

    

    • To roll back an update, click Rollback and enter the required information
      • 

    

    • To uninstall IBM Connections,
click Uninstall and enter the required information.
For more information, see the Uninstalling a deployment topic.
      • 

    

    5. 

  5. Confirm that the new response file is present.
    6. 



What to do next
Use the response file to silently install, modify, update,
roll back, or uninstall IBM Connections. 
If you are running IBM Installation
Manager as a non-administrator and plan to use the response file to
install the product on another user's system, you must change the
file paths in your response file from absolute paths to relative paths.








Creating encrypted passwords for a response file


Add encrypted passwords to your edited version of the default
response file.


Before you begin
You can create a response file using IBM Installation Manager or by editing the file
that is provided with the product. For more information about editing
the file, see the Default response file topic.




About this task
When you edit the default response file to suit your own
environment, you must create encrypted passwords and add them to the
file. Create encrypted passwords for both WebSphere Application Sever and your databases.


To create encrypted passwords for a response file, complete the
following steps:




Procedure
  1. Open a command prompt and change to the IBM_Connections_setup/IBM_Connections_Install/IM/OS/tools directory, where OS is your operating system.
    2. 

  2. Run the following command: 
    • AIX or Linux: ./imutilsc encryptString Password -silent -noSplash
      • 

    • Windows:  imutilsc.exe
encryptString Password -silent -noSplash
      where Password  is your password.
      

      • 

    

    3. 

  3. Add the encrypted password to the relevant line in the
response file. You usually need to enter passwords for both the WebSphere Application Server
administrator and the database user. For example: 
    <data key='user.activities.adminuser.password' value='encrypted_password'/>
    

    <data
key='user.activities.dbUserPassword value='encrypted_password'/>
    

    where encrypted_password is the value generated by the command.
    

    You might also need
to change the default WebSphere Application Server administrator name from wasadmin, if different
from your administrator name.
    

    4. 

  4. Repeat these steps for each unique password.
    5. 



What to do next
Use the response file to silently install, modify, update,
roll back, or uninstall IBM Connections. 








Directory paths for IBM Installation Manager


IBM Installation
Manager uses default directory paths for its installation files.


Purpose
This topic describes the default directory
paths for IBM Installation Manager.


IBM Installation
Manager
Each instance of Installation Manager must have
its own installation directory and agent data directory. 


The
directories where IBM Installation
Manager is installed are determined by the type of user account that
you used to install the product.


Any changes that you make to
an installation of IBM Installation
Manager that you installed with a root user or non-administrator account
do not affect an installation of IBM Installation Manager that you installed with a non-root
user or non-administrator account. The reverse is also true. 


The following table indicates the location of the relevant directories. 


Table 30. Default installation directories for IBM Installation Manager
Directory
Root/Administrator
Non-root/non-administrator




Default installation directory

AIX or Linux: /opt/IBM/InstallationManager/eclipse


Windows: C:\Program Files\IBM\Installation Manager\eclipse



AIX or Linux: /<user/IBM/InstallationManager/eclipse


Windows XP Professional, Windows Server 2003: C:\Documents and Settings\<user>\IBM\Installation Manager\eclipse


Windows Vista, Windows Server 2008, Windows 7: C:\Users\<user>\IBM\Installation
Manager\eclipse





Eclipse log file

AIX or Linux: /var/ibm/InstallationManager/pluginState/.metadata


Windows Server 2008: C:\ProgramData\IBM\Installation Manager\pluginState\.metadata



AIX or Linux: /<user/var/ibm/InstallationManager/pluginState/.metadata


Windows Server 2008: C:\Users\<user\IBM\Installation ManagerInstaller\pluginState\.metadata





Default agent data location.
For more information
about agent data, go to the Agent data location page in the IBM Installation Manager information center.



AIX or Linux: /var/ibm/InstallationManager


Windows Server 2008: C:\ProgramData\IBM\Installation Manager



AIX or Linux: /<user>/var/ibm/InstallationManager


Windows Server 2008: C:\Users\<user>\AppData\Roaming\IBM\Installation Manager










To find the location of IBM Installation Manager, complete the following steps:
  • AIX or Linux: 
    1. Open the /etc/.ibm/registry/InstallationManager.dat file. 
      2. 

    2. Examine the location entry. For example, location=/var/ibm/InstallationManager.
      3. 

    

    • 

  • Windows:
    1. Open the Windows Registry.
      2. 

    2. Search for the following registry key: HKLM\SOFTWARE\Wow6432Node\IBM\Installation
Manager\location.
      3. 

    3. Open the key and examine its value.
      4. 

    

    • 













Modifying the installation in interactive mode


Modify your deployment of IBM Connections by adding or removing applications.


About this task
Use the Modify function of the IBM Installation Manager to add or remove IBM Connections applications.
To modify your
installation, complete the following steps:




Procedure
  1. Open a command prompt and change to the  IM_root directory.
    2. 

  2. Run the following command: 
    • AIX or Linux: ./launcher
      • 

    • Windows: launcher.exe
      • 

    

    3. 

  3. From the IBM Installation
Manager menu, click File > Preferences.
    4. 

  4. Click Repositories.
    5. 

  5. In the Repositories area, select the repositories that
you want to modify.
    6. 

  6. Click OK to save your selections.
    7. 

  7. Click Modify.
    8. 

  8. Select IBM Connections
and click Next.
    9. 

  9. In the Application Selection page, choose the applications
you want to add or remove and then click Next.  
    • Add applications: Select the check boxes of any applications
that are not already installed and that you want to add to your deployment.
      • 

    • Remove applications: Clear the check boxes of any installed
applications that you want to remove from your deployment. 
      • 

    
 
    Notes: 
    • All installed applications are selected by default.
      • 

    • The Home page, News, and Search applications are required and
cannot be removed.
      • 

    

    

    10. 

  10. Enter the administrative ID and password of the Deployment Manager. 
    Note: This ID is set to
the connectionsAdmin J2C authentication alias, which is mapped to
the following J2EE roles: dsx-admin, widget-admin, and search-admin.
It is also used by the service integration bus. If you plan to use
security management software such as Tivoli Access Manager or SiteMinder, the ID that you specify
here must exist in the LDAP directory. For more information, see the Switching to unique administrator IDs for system level communication topic. 
    

    11. 

  11. Configure
your topology: 
    Notes: 
    • The panel described in this step appears only if you selected
new applications to install.
      • 

    • If you select an existing cluster on which to deploy applications,
the nodes in that cluster are fixed and cannot be modified.
      • 

    

    

    • Small deployment:
      1. Select the Small deployment topology. 
        2. 

      2. Enter a Cluster name for the topology. 
        3. 

      3. Select a Node.
        4. 

      4. Click Next.
        5. 

      

      • 

    • Medium deployment:
      1. Select the Medium deployment topology. 
        2. 

      2. Select the default
value or enter a Cluster name for each application
or for groups of applications. For example, use Cluster1 for Activities,
Communities, and Forums. 
        Note: IBM Installation Manager creates servers and
clusters when required.
        

        3. 

      3. Select a Node for each cluster. Accept the predefined node or
select a different node.
        Note: These nodes host
application server instances that serve IBM Connections applications. You can assign multiple nodes
to a cluster, where each node is a server member of that cluster.
        

        4. 

      4. Enter a Server member name for the selected node. Choose the
default or enter a custom name.
        Note: If you enter a custom server
member name, the name must be unique across all nodes in your deployment.
        

        5. 

      5. Click Next.
        6. 

      

      • 

    • Large deployment:
      1. Select the Large deployment topology. 
        2. 

      2. Enter a Cluster name for each application. 
        Note: IBM Installation Manager creates servers and
clusters when required.
        

        3. 

      3. Select a Node for each cluster. Accept the predefined node or
select a different node.
        Note: These nodes host
application server instances that serve IBM Connections applications. You can assign multiple nodes
to a cluster, where each node is a server member of that cluster.
        

        4. 

      4. Enter a Server member name for the selected node. Choose the
default or enter a custom name.
        Note: If you enter a custom server
member name, the name must be unique across all nodes in your deployment.
        

        5. 

      5. Click Next.
        6. 

      

      • 

    

    12. 

  12. Enter the database information.  
    Note: The panel described
in this step appears only if you selected new applications to install
and if the new applications require database configuration.
    

    1. Specify whether the installed applications use the same
database server or instance: Select Yes or No. 
      Note: If allowed by your database configuration,
you can select multiple database instances as well as different database
servers.
      

      2. 

    2. Select
a Database type from one of the following options: 
      • IBM DB2 Universal Database
        • 

      • Oracle Enterprise Edition
        • 

      • Microsoft SQL Server Enterprise
Edition
        • 

      

      3. 

    3. Enter
the Database server host name. For example: appserver.enterprise.example.com 
      If your
installed applications use different database servers, enter the database
host name for each application.
      

      4. 

    4. Enter
the Port number of the database server. The
default values are: 50000 for DB2, 1521 for Oracle, and 1433 for SQL Server. 
      If your
installed applications use different database servers or instances,
enter the port number for each database server or instance.
      

      5. 

    5. Enter
the JDBC driver location. For example: 
      • AIX:
        /usr/IBM/WebSphere/AppServer/lib
        

        • 

      • Linux:
        /opt/IBM/WebSphere/AppServer/lib
        

        • 

      • Windows:
        C:\IBM\WebSphere\Appserver\lib
        

        • 

      

      6. 

    6. Ensure
that the following JDBC driver libraries are present in the JDBC directory: 
      DB2
      

      db2jcc.jar and db2jcc_license_cu.jar
      Note: Ensure that your user account has the necessary permissions
to access the DB2 JDBC files.
      

      

      Oracle
      

      ojdbc6.jar
      

      SQL Server
      

      Download the SQL Server JDBC 2 driver from the Microsoft website to a local directory
and enter that directory name in the JDBC driver library field.
      The directory must not contain the sqljdbc.jar file, only the sqljdbc4.jar file. Even though
the data source is configured to use the sqljdbc4.jar file, an exception occurs if both files are present in the same
directory.
      

      IBM recommends that you obtain this Microsoft hotfix for the JDBC 2 driver for production deployments.
      

      

      

      7. 

    7. Enter the User ID and Password for each database. If each database
uses the same user credentials, select the Use the same
password for all applications check box and then enter
the user ID and password for the first database in the list.
      Note: 
      If your database
type is Oracle, you must connect to the database with the user ID
that you used when you created the application database. 
      

      

      8. 

    8. Click Validate to verify your
database settings. If the validation fails, check your database settings.
When the validation succeeds, click Next. 
      IBM Installation Manager tests your
database connection with the database values that you supplied. You
can change the database configuration later in the WebSphere Application Server Integrated
Solutions Console.
      

      9. 

    

    13. 

  13. In the summary panel, confirm your selection and click Modify.
    14. 

  14. When the modification process is complete, restart the
Deployment Manager and all the nodes. 
    Note: Wait until the
DM copies all the application EAR files to the installedApps directory on each of  the nodes. This process can take up to 30
minutes. 
    To verify that the DM has distributed the application
EAR files to the nodes, check the SystemOut.log file of each node agent. The default path to the SystemOut.log file on a node is profile_root/logs/nodeagent.
    

    Look for a message such as the following example: ADMA7021I: Distribution of application application_name completed successfully. where application_name is the name of an IBM Connections
application.
    

    
 
    To
confirm that the installation was successful, open the log files in
the connections_root/logs directory. Each IBM Connections application that you installed
has a log file, using the following naming format: application_nameInstall.log, where application_name is the name of an IBM Connections application. Search for the words error or exception to check whether any errors
or exceptions occurred during installation. 
    

    15. 







Modifying
the installation in silent mode


Modify your deployment
of IBM Connections
by adding or removing applications in silent mode.


About this task
With the help of
a response file, use the Modify function
of the IBM Installation Manager
to add or remove IBM Connections
applications.
To modify your installation in silent mode, complete
one of the following tasks:






Adding applications in silent mode


Add applications to your deployment of IBM Connections without using the installation
wizard.


Before you begin
Create
a response file for this task by running a simulated modification.
For more information, see the Creating a response file topic. 


Instead
of generating a new response file, you can edit the default response
file that is provided with the product. However, if you edit the default
response file, you need to add encrypted passwords to the file. For
more information, see the Creating encrypted passwords for a
response file topic.




About this task
A silent modification uses a response file to automate
the addition of applications to your deployment. 


To perform
a silent modification, complete the following steps:




Procedure
  1. Open
a command prompt and navigate to the IM_root/eclipse/tools directory. 
    2. 

  2. Enter
the following command: 
    • AIX or Linux: ./imcl -input response_file -log log_file -acceptLicense
      • 

    • Windows: imcl.exe -input response_file -log log_file
-acceptLicense
      Note: The IM_root/eclipse directory contains a similar
file called IBMIM.exe but that file is not suitable
for silent installation.
      

      • 

    
 
    where response_file is the full path and
name of the response file and log_file is the full
path and name of the log file. The default name of the response file
is LC.rsp. By default, the response file is in
the following directory:

    
 Compare the following examples to your environment:
    • AIX or Linux: ./imcl -input /opt/IBM_Connections_Install/IBMConnections/LC.rsp
-log /mylog/silent_install_log.xml  -acceptLicense
      • 

    • Windows: imcl.exe
-input E:\IBM_Connections_Install\IBMConnections\LC.rsp -log \mylog\silent_install_log.xml
-acceptLicense
      • 

    

    3. 



Results
IBM Installation Manager writes
the result of the installation command to the log file that you specified
with the -log parameter. 


To check the complete
details of the installation, open each of the log files in the connections_root/logs directory. Each IBM Connections application that you installed
has a log file, using the following naming format: applicationInstallog.txt, where application is the name of an IBM Connections
application. 


If the installation is successful, the log files are empty. For example: 
<?xml version="1.0" encoding="UTF-8"?>
<result>
</result>

The log file contains an error element if
the operation was not completed successfully. A successful installation
adds a value of 0 to the log file. An unsuccessful installation adds
a positive integer to the log file.


The log file for IBM Installation Manager records
the values that you entered when you ran IBM Installation Manager in interactive mode. To review the
log file for IBM Installation
Manager, open the date_time.xml file, where date_time represents the date and
time of the installation. The file by default is in the following
directory: 
  • AIX or Linux (root user): /var/ibm/InstallationManager/logs
    • 

  • AIX or Linux (non-root user): user_home/var/ibm/InstallationManager/logs where user_home is the non-root user account directory
    • 

  • Windows (administrator): C:\ProgramData\IBM\Installation Manager\logs
    • 

  • Windows (non-administrator): C:\Documents and Settings\user\Application Data\IBM\Installation
Manager\logs  where user is the non-administrator
user account
    • 











Removing applications in silent mode


Silently remove applications from your deployment of IBM Connections.


Before you begin
Create
a response file for this task by running a simulated modification.
For more information, see the Creating a response file topic. 


Instead
of generating a new response file, you can edit the default response
file that is provided with the product. However, if you edit the default
response file, you need to add encrypted passwords to the file. For
more information, see the Creating encrypted passwords for a
response file topic.




About this task
A silent modification uses a response file to automate
the removal of applications from your deployment. 


To
perform a silent modification, complete the following steps:




Procedure
  1. Open
a command prompt and navigate to the IM_root/eclipse/tools directory. 
    2. 

  2. Enter
the following command: 
    • AIX or Linux: ./imcl -input response_file -log log_file -acceptLicense
      • 

    • Windows: imcl.exe -input response_file -log log_file
-acceptLicense
      Note: The IM_root/eclipse directory contains a similar
file called IBMIM.exe but that file is not suitable
for silent installation.
      

      • 

    
 
    where response_file is the full path and
name of the response file and log_file is the full
path and name of the log file. The default name of the response file
is LC.rsp. By default, the response file is in
the following directory:

    
 Compare the following examples to your environment:
    • AIX or Linux: ./imcl -input /opt/IBM_Connections_Install/IBMConnections/LC.rsp
-log /mylog/silent_install_log.xml  -acceptLicense
      • 

    • Windows: imcl.exe
-input E:\IBM_Connections_Install\IBMConnections\LC.rsp -log \mylog\silent_install_log.xml
-acceptLicense
      • 

    

    3. 



Results
IBM Installation Manager writes
the result of the installation command to the log file that you specified
with the -log parameter. 


To check the complete
details of the installation, open each of the log files in the connections_root/logs directory. Each IBM Connections application that you installed
has a log file, using the following naming format: applicationInstallog.txt, where application is the name of an IBM Connections
application. 


If the installation is successful, the log files are empty. For example: 
<?xml version="1.0" encoding="UTF-8"?>
<result>
</result>

The log file contains an error element if
the operation was not completed successfully. A successful installation
adds a value of 0 to the log file. An unsuccessful installation adds
a positive integer to the log file.


The log file for IBM Installation Manager records
the values that you entered when you ran IBM Installation Manager in interactive mode. To review the
log file for IBM Installation
Manager, open the date_time.xml file, where date_time represents the date and
time of the installation. The file by default is in the following
directory: 
  • AIX or Linux (root user): /var/ibm/InstallationManager/logs
    • 

  • AIX or Linux (non-root user): user_home/var/ibm/InstallationManager/logs where user_home is the non-root user account directory
    • 

  • Windows (administrator): C:\ProgramData\IBM\Installation Manager\logs
    • 

  • Windows (non-administrator): C:\Documents and Settings\user\Application Data\IBM\Installation
Manager\logs  where user is the non-administrator
user account
    • 













Modifying the installation in console mode


Using console mode, modify your deployment of IBM Connections by adding or removing applications.


About this task
Use IBM Installation
Manager in console mode to add or remove IBM Connections applications. This method is convenient if you
cannot or do not want to use the interactive mode.
To modify your
installation, complete the following steps:




Procedure
  1. On each
node, stop any running instances of WebSphere Application Server and WebSphere node agents. 
    2. 

  2. Start WebSphere Application Server
Network Deployment Manager.
    3. 

  3. Open a command prompt and change to the  IM_root/tools directory.
    4. 

  4. Run the following command to start IBM Installation Manager in console mode: 
    • AIX or Linux: ./imcl -c
      • 

    • Windows: imcl.exe -c
      • 

    

    5. 

  5. Type 1 to begin modifying the deployment.
    6. 

  6. In the Select packages to install step, type 1 to select the package and then type N to proceed.
    7. 

  7. Select the applications that you want to add or remove
and then type N.  
    • Add applications: Type the numbers corresponding to applications
that are not already installed and that you want to add to your deployment.
      • 

    • Remove applications: Type the numbers corresponding to installed
applications that you want to remove from your deployment. The Home
page, News, and Search applications are required and can't be removed. 
      • 

    
 
    Notes: 
    • All installed applications are selected by default.
      • 

    

    

    8. 

  8. Enter the administrative ID and password of the Deployment Manager. 
    Note: This ID is set to
the connectionsAdmin J2C authentication alias, which is mapped to
the following J2EE roles: dsx-admin, widget-admin, and search-admin.
It is also used by the service integration bus. If you plan to use
security management software such as Tivoli Access Manager or SiteMinder, the ID that you specify
here must exist in the LDAP directory. For more information, see the Switching to unique administrator IDs for system level communication topic. 
    

    9. 

  9. Configure your topology. For more information about each option,
see the Deployment options topic.
    • Small deployment:
      1. Type 1 to select the Small deployment topology. 
        2. 

      2. Enter a Cluster name for the topology. 
        3. 

      3. Select a Node.
        4. 

      4. Enter a Server member name for the node. 
        5. 

      5. Type N to
proceed.
        6. 

      

      • 

    • Medium deployment:
      1. Type 2 to select the Medium
deployment topology. 
        2. 

      2. Select the default
value or enter a Cluster name for each application
or for groups of applications. For example, use Cluster1 for Activities,
Communities, and Forums. 
        Note: IBM Installation Manager creates servers and
clusters when required.
        

        3. 

      3. Select a Node for each cluster. Accept the predefined node or
select a different node.
        Note: These nodes host
application server instances that serve IBM Connections applications. You can assign multiple nodes
to a cluster, where each node is a server member of that cluster.
        

        4. 

      4. Enter a Server member name for the selected node. Choose the
default or enter a custom name.
        Note: If you enter a custom server
member name, the name must be unique across all nodes in your deployment.
        

        5. 

      5. The topology
that you specified is displayed. To re-specify any details, type the
number that corresponds to the application; for example, type 1 for Activities. 
        6. 

      6. Type N to
proceed.
        7. 

      

      • 

    • Large deployment:
      1. Type 3 to select the Large deployment topology. 
        2. 

      2. Enter a Cluster name for each application. 
        Note: IBM Installation Manager creates servers and
clusters when required.
        

        3. 

      3. Select a Node for each cluster. Accept the predefined node or
select a different node.
        Note: These nodes host
application server instances that serve IBM Connections applications. You can assign multiple nodes
to a cluster, where each node is a server member of that cluster.
        

        4. 

      4. Enter a Server member name for the selected node. Choose the
default or enter a custom name.
        Note: If you enter a custom server
member name, the name must be unique across all nodes in your deployment.
        

        5. 

      5. The topology
that you specified is displayed. To re-specify any details, type the
number that corresponds to the application; for example, type 1 for Activities. 
        6. 

      6. Type N to
proceed.
        7. 

      

      • 

    

    10. 

  10. Enter the database information: 
    1. Specify whether the installed applications use the same
database server or instance: Type 1 to specify
that the applications use same database server or instance; type 2 to specify that they use different database servers
or instances. 
      Note: If allowed by your database configuration,
you can select multiple database instances as well as different database
servers.
      

      2. 

    2. Select
a Database type from one of the following options: 
      • IBM DB2 Universal Database
        • 

      • Oracle Enterprise Edition
        • 

      • Microsoft SQL Server Enterprise
Edition
        • 

      

      3. 

    3. Enter
the Database server host name. For example: appserver.enterprise.example.com 
      If your
installed applications use different database servers, enter the database
host name for each application.
      

      4. 

    4. Enter
the Port number of the database server. The
default values are: 50000 for DB2, 1521 for Oracle, and 1433 for SQL Server. 
      If your
installed applications use different database servers or instances,
enter the port number for each database server or instance.
      

      5. 

    5. Enter
the JDBC driver location. For example: 
      • AIX:
        /usr/IBM/WebSphere/AppServer/lib
        

        • 

      • Linux:
        /opt/IBM/WebSphere/AppServer/lib
        

        • 

      • Windows:
        C:\IBM\WebSphere\Appserver\lib
        

        • 

      

      6. 

    6. Ensure
that the following JDBC driver libraries are present in the JDBC directory: 
      DB2
      

      db2jcc.jar and db2jcc_license_cu.jar
      Note: Ensure that your user account has the necessary permissions
to access the DB2 JDBC files.
      

      

      Oracle
      

      ojdbc6.jar
      

      SQL Server
      

      Download the SQL Server JDBC 2 driver from the Microsoft website to a local directory
and enter that directory name in the JDBC driver library field.
      The directory must not contain the sqljdbc.jar file, only the sqljdbc4.jar file. Even though
the data source is configured to use the sqljdbc4.jar file, an exception occurs if both files are present in the same
directory.
      

      IBM recommends that you obtain this Microsoft hotfix for the JDBC 2 driver for production deployments.
      

      

      

      7. 

    7. Enter the User ID and Password for each database. If each database
uses the same user credentials, confirm the Use the same
password for all applications question and then enter
the user ID and password for the first database in the list.
      Note: 
      If your database
type is Oracle, you must connect to the database with the user ID
that you used when you created the application database. 
      

      

      8. 

    8. If you need to make changes, type the number that corresponds
to the application that you want to change. Alternatively, type R to reset all the database specifications to their default
values.
      9. 

    9. Press Enter to verify your database
settings. If the validation fails, check your database settings. When
the validation succeeds, click Next. 
      IBM Installation Manager tests your
database connection with the database values that you supplied. You
can change the database configuration later in the WebSphere Application Server Integrated
Solutions Console.
      

      10. 

    10. If
the verification check is successful, type N to proceed. If verification fails, press B to re-enter the required information.
      11. 

    

    11. 

  11. Review the information that you have entered. To revise
your selections, press B. To finish modifying,
 press M.
    12. 

  12. Review the result of the installation. Press F to exit the installation wizard.
    13. 

  13. Restart
the Deployment Manager: 
    • AIX or Linux: Open a command prompt and change to
the profile_root/Dmgr01/bin directory. Enter the ./stopManager.sh
command and then enter the ./startManager.sh command.
      • 

    • Windows: Stop and restart
the Deployment Manager service.
      • 

    

    14. 

  14. Start
all the federated nodes and enter the startNode command. Repeat these steps for each node:
    1. Log in to a node.
      2. 

    2. From a command line, change to the profile_root/bin directory.
      3. 

    3. Enter the startNode command for
your operating system: 
      • AIX or Linux: ./startNode.sh
        • 

      • Windows: startNode.bat
        • 

      

      4. 

    

    15. 

  15. Log in
to the Integrated Solutions Console on the DM to perform a full synchronization
of all nodes.
    1. Go to System administration > Nodes.
      2. 

    2.  Select the nodes and click Full Resynchronize.
      3. 

    
 
    Note: Wait until the
DM copies all the application EAR files to the installedApps directory on each of  the nodes. This process can take up to 30
minutes. 
    To verify that the DM has distributed the application
EAR files to the nodes, check the SystemOut.log file of each node agent. The default path to the SystemOut.log file on a node is profile_root/logs/nodeagent.
    

    Look for a message such as the following example: ADMA7021I: Distribution of application application_name completed successfully. where application_name is the name of an IBM Connections
application.
    

    

    16. 

  16. Start
all your IBM Connections clusters:
    1. Log in to the Integrated Solutions Console
on the DM
      2. 

    2. Go to Servers > Clusters > WebSphere Application server
clusters.
      3. 

    3. Select the IBM Connections clusters and click Start.
      4. 

    
 
    Notes: 
    • If you installed a cluster with multiple Search nodes, you must
create the initial index. For more information about creating the
Search index, see the Creating the initial Search index topic.
      1. If you are installing a non-English language deployment, enable
Search dictionaries. For more information, see the Enabling
Search dictionaries topic.
        2. 

      2. The index is ready when the INDEX.READY and CRAWLING_VERSION files are present in the index directory.
        3. 

      

      • 

    • If some applications do not start, the file-copying process might
not have completed. Wait a few minutes and start the applications.
      • 

    

    

    17. 









Post-installation tasks


After installation, you need to perform further tasks to
ensure an efficient deployment.


After running the wizards to install applications and create
databases, check which of the following additional tasks you need
to complete. 


Tasks to be completed
Some post-installation
tasks are mandatory while others are optional and depend on your deployment
choices.


Important: After you complete the mandatory post-installation
tasks, update the deployment with the latest fixes. For more information,
see the Updating IBM Connections 4.0 topic.


Each post-installation task is described
in separate topics:






Mandatory post-installation tasks


Complete the following post-installation tasks.


Important: After you complete the mandatory post-installation
tasks, update the deployment with the latest fixes. For more information,
see the Updating IBM Connections 4.0 topic.




Reviewing the JVM heap size


Review the size of the Java Virtual Machine heap and adjust it, if necessary, to avoid
out-of-memory errors or to suit your hardware capabilities. 


About this task
If you selected the Small or Medium deployment option
when you installed IBM Connections, IBM Installation Manager set the
Maximum Heap Size of the Java Virtual Machine (JVM) on each application server. This setting is
designed to avoid out-of-memory errors.


Review the heap size
on each server to ensure that you are allocating enough memory for IBM Connections but also to ensure
that you are not allocating more memory than the physical capabilities
of the systems where the JVMs are deployed.


Whether you installed
a Small, Medium, or Large deployment of IBM Connections, you should review the JVM heap sizes in your
deployment and make adjustments, if necessary. 


To review the
JVM heap size, complete the following steps:




Procedure
  1. Log into the WebSphere Application Server Integrated Solutions Console and select Servers > Server Type > WebSphere application servers.
    2. 

  2. Click server,
where server is the name of an IBM Connections server. You might have several
servers in your deployment, so you might need to repeat these steps
for each server.
    3. 

  3. In the Server Infrastructure area, click Java
and Process Management and then click Process Definition > Java Virtual Machine.
    4. 

  4. Review the Maximum heap size. IBM Installation Manager sets the following default values: 
    • Small deployment:
      Maximum Heap Size
      

      2506 MB
      

      

      • 

    • Medium deployment:
      Maximum Heap Size
      

      2506 MB
      

      

      • 

    • Large deployment:
      Each application in a Large deployment, except
News and Search, has a default Heap size of 256 MB. The News and Search
applications have a default Heap size of 784 MB.
      

      • 

    

    Note: Ensure that you are not allocating more memory than the
physical capacity of the system where the JVM is installed.
    

    5. 

  5. Adjust the current values of the heap size up or down to
suit the needs of your deployment and your hardware capabilities.
    6. 

  6. Click OK and then click Save.
    7. 

  7. Repeat these steps for any additional servers in your deployment.
    8. 







Configuring IBM HTTP
Server


Configure IBM HTTP
Server to manage web requests to IBM Connections.


When you have successfully
installed IBM Connections to
run on WebSphere Application
Server, you can configure IBM HTTP
Server to handle web traffic by completing
the following tasks:




Defining IBM HTTP Server


Define IBM HTTP Server to manage web connections.


Before you begin
Install web server plug-ins for IBM HTTP Server, if they are not already installed. For more information, go to the Installing web server plug-ins web site. 




About this task
IBM Connections uses a web server as the entry point for all the applications.


This procedure describes how to create a web server using the Integrated Solutions Console. There are other ways to create the web server. See the IBM WebSphere Application Server information center for more information.


To define IBM HTTP Server, complete the following steps:




Procedure
  1. Start the IBM HTTP Administration Server: 
    • AIX or Linux:
      1. Open a command prompt and navigate to the following directory: 
        • AIX: /usr/IBM/HTTPServer/bin
          • 

        • Linux: /opt/IBM/HTTPServer/bin
          • 

        

        2. 

      2. Enter the following command: ./adminctl start
        3. 

      

      • 

    • Windows:
      1. Open the Services window in the Windows Control Panel.
        2. 

      2. Verify that the IBM HTTP Administration Server service is started. If this service is not running, start it
        3. 

      

      • 

    

    2. 

  2. Log in to the WebSphere Application Server Integrated Solutions Console on the Deployment Manager and select System administration > Nodes > Add Node.
    3. 

  3. Select Unmanaged node and click Next.
    4. 

  4. Specify the properties of the node by providing values in the following fields: 
    Name
    

    Enter the name of the node.
    

    Host Name
    

    Enter the fully qualified DNS host name for IBM HTTP Server. For example: webserver.example.com.
    

    Platform
    

    Select the operating system type that hosts your IBM HTTP Server.
    

    
Click OK and then click Save.
    5. 

  5. Select Servers > Server Types > Web servers and click New.
    6. 

  6. Provide values for the following fields: 
    Select node
    

    Select the node that you specified in Step 4.
    

    Server name
    

    Enter the name of the your web server. The default value is webserver1.
    

    Type
    

    Select IBM HTTP Server. 
    

    

    7. 

  7. Click Next.
    8. 

  8. Select the default web server template and click Next.
    9. 

  9. On the Enter the properties for the new web server page, check the paths and make adjustments if necessary, and then enter the user name and password that you specified when you installed IBM HTTP Server. Confirm the password and click Next.
    10. 

  10. Confirm that you want to create the new web server.
    11. 

  11. Click Finish and then click Save.
    12. 

  12. Synchronize all the nodes.
    13. 

  13. Select Servers > Server Types > Web servers and click the link to your webserver.
    14. 

  14. Click Generate Plug-in.
    15. 

  15. Select the check box for your webserver.
    16. 

  16. Click Propagate Plug-in. 
    17. 

  17. Select Servers > Server Types > Web servers and click the link to your webserver.
    18. 

  18. Click Plug-in properties and then click Copy to Web Server key store directory. 
    Note: If the plugin-key.kdb file is on a different system from the IBM HTTP Server system, copy it manually from the WebSphere Application Server system to the IBM HTTP Server system. 
    

    19. 

  19. Restart IBM HTTP Server.
    20. 



What to do next
Complete the steps in the Configuring IBM HTTP Server for SSL topic.


Configure IBM HTTP Server to handle file downloads from the Files and Wikis applications. For information on this configuration, see the Configuring Files and Wikis downloads topic. 








Configuring IBM HTTP
Server for SSL


Configure IBM HTTP
Server to use the SSL protocol.


About this task
To support SSL, create a self-signed certificate and then
configure IBM HTTP Server for
SSL traffic. If you use this certificate in production, users might
receiver warning messages from their browsers. In a typical production
deployment, you would use a certificate from a trusted certificate
authority. 


To configure IBM HTTP
Server for SSL, complete the following steps:




Procedure
  1. Create a key file. 
    1. Start the iKeyman user interface. For more information,
go to the Starting the Key Management utility page in
the IBM HTTP Server information
center.
      2. 

    2. Click Key Database File in the
main user interface, then click New. Select CMS for
the Key database type. IBM HTTP
Server does not support database types other than CMS.
      3. 

    3. Enter a name for the new key file. For example, hostname-key.kdb.
Click OK.
      4. 

    4. Enter your password in the Password Prompt dialog box,
and confirm the password. Select Stash the password to
a file and then click OK.  The
new key database should display in the iKeyman utility with default
signer certificates. Ensure that there is a functional, non-expiring
signer certificate for each of your personal certificates. 
      5. 

    

    2. 

  2. Create a self-signed certificate:
    1. Start the iKeyman user interface.
      2. 

    2. Click Key Database File and then
click Open.
      3. 

    3. Enter your key file name in the Open dialog box and
click OK.
      4. 

    4. In the Password Prompt dialog box, enter your password
and click OK. 
      5. 

    5. Click Personal Certificates in
the Key Database content frame, and then click New Self-Signed.
      6. 

    6. Enter the required information about the key file, your
webserver, and organization in the dialog box.
      7. 

    7. Click OK. 
      8. 

    
 
    Note: Save the new self-signed certificate with a unique file
name; do not overwrite the default Plugin-key.kdb file
because that file might be accessed by other applications.
    

    3. 

  3. Stop IBM HTTP Server.
    4. 

  4. Log in to the WebSphere Application
Server Integrated Solutions Console for the Deployment Manager and
select Servers > Server
types > Web servers.
    5. 

  5. From the list of web servers, click the web server that
you defined for this profile. 
    6. 

  6. On the Configuration page for this web server, click Edit for
the Configuration file name field. This action
opens the httpd.conf configuration file on the
Deployment Manager.
    7. 

  7. Add the following text to the end of the configuration
file:  
    LoadModule  ibm_ssl_module   modules/mod_ibm_ssl.so 
    

    <IfModule
mod_ibm_ssl.c> 
    

    Listen 0.0.0.0:443 
    

    <VirtualHost
 *:443> 
    

    ServerName  server_name 
    

    #DocumentRoot C:\IBM\HTTPServer\htdocs 
    

    SSLEnable 
    

    </VirtualHost> 
    

    </IfModule> 
    

    SSLDisable 
    

    Keyfile
"path_to_key_file" 
    

    SSLStashFile
"path_to_stash_file"
    

    where
    • server_name is the host name of the IBM HTTP Server.
      • 

    • path_to_key_file is the path to the key file
that you created with the iKeyman utility.
      • 

    • path_to_stash_file is the path to the associated
stash file.
      • 

    
 For example: 
    • AIX:
      • Keyfile: /usr/IBM/keyfiles/key_file.kdb
        • 

      • SSLStashFile: /usr/IBM/keyfiles/key_file.sth
        • 

      

      • 

    • Linux:
      • Keyfile: /opt/IBM/keyfiles/key_file.kdb
        • 

      • SSLStashFile: /opt/IBM/keyfiles/key_file.sth
        • 

      

      • 

    • Microsoft Windows:
      • Keyfile: C:\IBM\keyfiles\key_file.kdb
        • 

      • SSLStashFile: C:\IBM\keyfiles\key_file.sth
        • 

      

      • 

    
where key_file is the name that you have given
to your key file and stash file.
    

    8. 

  8. Click Apply and then click OK.
    9. 

  9. Restart IBM HTTP
Server to apply the changes.
    10. 

  10. Test the new configuration: Open a web browser and ensure
that you can successfully reach https://server_name.
You might be prompted to accept the self-signed certificate on your
browser. 
    11. 



Results
IBM Connections users
can access applications through the SSL protocol.
Attention: If
you receive an error message about failing to load a GSK library (libgsk7ssl.so),
install the libgsk7ssl.so GSK library. For more
information, go to the following Support page: Failure attempting to load GSK library when using
SSL with IBM HTTP Server.




What to do next
For more information about securing web communications,
go to the IBM WebSphere Application Server
Information Center or read the IBM WebSphere Application Server
V7.0 Security Handbook.


For more information about the
key store and setting up the IBM HTTP
Server, see the Securing communications topic in the WebSphere Application Server
Information Center.

The key file can be shared between two webservers,
thus providing failover capability.




Mapping applications to IBM HTTP Server


Map IBM Connections
applications to IBM HTTP Server. 


Before you begin
Complete this task if you installed and configured IBM HTTP Server before installing IBM Connections.


If you plan
to configure a reverse proxy, see the Configuring a reverse
caching proxy topic.




About this task
If
you installed and configured IBM HTTP Server after installing IBM Connections, your IBM Connections
applications are automatically mapped to the web server. However,
if you installed and configured IBM HTTP Server before installing IBM Connections, you must manually map the applications.


To map your IBM Connections
applications to IBM HTTP Server
and regenerate the plugin, complete the following steps:




Procedure
  1. Open the WebSphere Application Server Integrated Solutions Console on the system where
you installed the Deployment Manager.
    2. 

  2. Select Applications > Application Types > WebSphere enterprise
applications. 
    3. 

  3. Map an IBM Connections application to IBM HTTP Server: 
    Note: This step instructs you to
select webserver1. Ensure that you have defined this web server before
you attempt to complete these steps. For more information, see the Defining IBM HTTP Server topic.
    

    1. Select application > Manage Modules,
where application is an IBM Connections application.
      2. 

    2. In the Clusters and Servers box,
select the cluster and server on which you installed the application.
If necessary, use the Ctrl key to select both targets.
      3. 

    3. Select the check boxes for all the modules and click Apply.  
      4. 

    4. Review the Server details and ensure that both servers
are listed there. Click OK and then click Save.
      5. 

    5. Repeat this step for each IBM Connections application.
      6. 

    

    4. 

  4. From the WebSphere Application Server
Integrated Solutions Console, select Servers > Server Types > Web servers and then click the web server (webserver1).
    5. 

  5. Click Generate
Plug-in.
    6. 

  6. Click
your web server again and then click Propagate Plug-in. 
    Note: If you have trouble propagating the plug-in on Linux, restart IBM HTTP Server using the following commands:
     ./adminctl start
 ./apachectl -k stop
 ./apachectl -k start
    

    

    7. 

  7. Stop and restart
the web server.
    8. 

  8. Synchronize the nodes.
    9. 

  9. Restart all IBM Connection
clusters.
    10. 

  10. Restart the Deployment Manager.
    11. 



What to do next
To
verify that the mappings are correct, complete the steps in the Verifying application mappings topic. 


Test the mappings:
open a web browser and try to access each of the applications by specifying
the web address using the following syntax:


http://hostname/application_name


where hostname is the host name of the
web server to which you mapped the application and application_name is the name of the application. Do not specify the port number.








Verifying application mappings


Verify that IBM Connections
applications are mapped to your webserver.


About this task
If
you installed and configured IBM HTTP Server after installing IBM Connections, your IBM Connections
applications are automatically mapped to the web server. However,
if you installed and configured IBM HTTP Server before installing IBM Connections, you must manually map the applications.

To verify whether the mappings exist, complete the following
steps:


Procedure
  1. From the WebSphere Application Server
Integrated Solutions Console, select Servers > Server Types > Web servers and then click the web server (webserver1).
    2. 

  2. Click Generate
Plug-in.
    3. 

  3. Click
your web server again and then click Propagate Plug-in. 
    Note: If you have trouble propagating the plug-in on Linux, restart IBM HTTP Server using the following commands:
     ./adminctl start
 ./apachectl -k stop
 ./apachectl -k start
    

    

    4. 

  4. Wait until a confirmation message is displayed; for example:  
    PLGC0062I: The plug-in configuration file is propagated from /opt/IBM/WebSphere/AppServer/profiles/Dmgr01/config/cells/servernameCell01/nodes/webserver1/servers/webserver1/plugin-cfg.xml to /opt/IBM/HTTPServer/Plugins/config/webserver1/plugin-cfg.xml.
    

    The message identifies where the plugin-cfg.xml file
is on the system that hosts IBM HTTP Server. In this example, the file path is: /opt/IBM/HTTPServer/Plugins/config/webserver1/plugin-cfg.xml.
    

    5. 

  5. Log on to the system that hosts IBM HTTP Server and open the plugin-cfg.xml file.
    6. 

  6. Verify that the URIs for the installed IBM Connections applications are present. For
example:  
    <UriGroup Name="default_host_Cluster1_URIs">      
<Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid" Name="/activities/*"/>      
<Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid" Name="/activities/quickrpicker/*"/>      
<Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid" Name="/communities/*"/>      
<Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid" Name="/communities/calendar/*"/>      
<Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid" Name="/communities/recomm/*"/>      
<Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid" Name="/forums/*"/>      
<Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid" Name="/metrics/service/*"/>      
<Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid" Name="/metrics/*"/>      
<Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid" Name="/profiles/*"/>      
<Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid" Name="/profiles/seedlist/*"/>   
</UriGroup>
    

    If the IBM Connections URIs are not present, complete the steps in
the Mapping applications to IBM HTTP Server topic.
    

    7. 









Adding certificates to the WebSphere trust store


Import a self-signed IBM HTTP Server certificate into the default trust store of IBM WebSphere Application Server.


Before you begin
Before you complete this procedure, ensure that IBM HTTP Server is configured to support SSL.
For more information, see the Configuring IBM HTTP Server for SSL topic.
This
topic describes the procedure to configure certificates in a deployment
with one webserver. 




About this task
To establish trusted server to server communication for IBM Connections, import signer certificates
from IBM HTTP Server into the WebSphere Application Server
default trust store. 


There are different types of certificates
that you can use. This procedure describes how to import a self-signed
certificate. You can also import a certificate that you purchased
from a third-party Certificate Authority. To help decide a key file
strategy for your environment, go the IBM HTTP Server
information center.


To import a public certificate from IBM HTTP Server to the default trust
store in IBM WebSphere Application Server, complete
the following steps:




Procedure
  1. Log into the IBM WebSphere Application Server
Integrated Solutions Console and select Security > SSL Certificate and key management > Key stores and certificates.
    2. 

  2. Click CellDefaultTrustStore.
    3. 

  3. Click Signer Certificates.
    4. 

  4. Click Retrieve from port.
    5. 

  5. Enter the Host name, SSL Port, and Alias of the webserver.
    6. 

  6. Click Retrieve Signer Information and then click OK. The root certificate is
added to the list of signer certificates.
    7. 



Results
If your configuration changes aren't successful, ensure
that you have applied the instructions to configure a default personal
certificate.




What to do next
Verify that users can create a private community and add
other widgets, such as Activities, Blogs, Dogear, and so on, to it.
 Ensure that there are no errors when these widgets are added. If
problems are reported, consult the Communities SystemOut.log file.


The proxy-config.tpl file allows
a proxy to work with self-signed certificates. This is true for an
out-of-the-box deployment but for improved security you should set
the value of the unsigned_ssl_certificate_support property to false when your deployment is ready for production.


Ensure that you are ready to renew your certificate before it
expires. WebSphere Application
Server provides a utility for monitoring certificates. For more information,
go to the Configuring certificate expiration monitoring topic in the WebSphere Application Server information center.






Adding certificates to IBM HTTP Server


Add
signer certificates to an IBM HTTP Server plug-in.


Before you begin
Before you complete
this procedure, ensure that IBM HTTP Server is configured to support SSL. For more information,
see the Configuring IBM HTTP Server for SSL topic.


About this task
To establish trusted communication between IBM HTTP Server and a web browser, import signer
certificates from WebSphere Application Server. 
Note: 
There are different types of certificates
that you can use. This procedure describes how to import the self-signed
certificate that is shipped with WebSphere Application Server. You can also import a certificate
that you purchased from a third-party Certificate Authority, or create
a new self-signed certificate. 





To import a public WebSphere Application Server
certificate into the IBM HTTP
Server plug-in, complete the following steps:


Procedure
  1. Copy the plugin-key.kdb file from the ibm_http_server_root/Plugins/config/webserver1 directory
to the app_server_root/profiles/AppSrv01/config/cells/cell_name/nodes/node_name/servers/webserver_name directory. 
    where cell_name, node_name, and webserver_name are the names of your WebSphere Application Server cell, the name of the node that you are configuring,
and your web server.
    

    2. 

  2. Log into the IBM WebSphere Application Server
Integrated Solutions Console and select Security > SSL Certificate and key management > Key stores and certificates.
    3. 

  3. Click CellDefaultTrustStore.
    4. 

  4. Click Personal Certificates.
    5. 

  5. Select the check box beside the default certificate and click Extract.
    6. 

  6. Enter a fully-qualified Certificate file name. If you do not specify a directory path, the certificate is stored
in the app_server_root/profiles/profile_name/etc directory, where profile_name is the name of
the current WebSphere Application
Server profile.
    7. 

  7. Click OK to extract the file.
    8. 

  8. In the IBM WebSphere Application Server
Integrated Solutions Console, select Servers > Server Types > Web servers.
    9. 

  9. Click webserver_name, where webserver_name is the name of your IBM HTTP Server web server. 
    10. 

  10. Click Plug-in properties and then
click Manage keys and certificates.
    11. 

  11. Under Additional Properties, click Signer certificatesand then click Add.
    12. 

  12. Enter the certificate Alias and
its fully-qualified File nameand then click OK. 
    13. 

  13. Click Save to import the file.
    14. 

  14. In the IBM WebSphere Application Server
Integrated Solutions Console, select Servers > Server Types > Web servers > webserver_name > Plug-in properties.
    15. 

  15. Click Copy to web server key store directory to synchronize the KDB file with IBM HTTP Server.
    16. 

  16.  To apply the changes, restart IBM HTTP Server.
    17. 



Results
If your configuration changes are not successful, ensure
that you have applied the instructions to configure a default personal
certificate.




What to do next
The proxy-config.tpl file allows
the proxy to work with self-signed certificates. For improved security,
set the value of the unsigned_ssl_certificate_support property to
false when your deployment is ready for production.










Determining which files to compress


If you are not compressing content with the IBM WebSphere Application
Server Edge components or a similar device, configure the IBM HTTP Server to compress certain
types of content to improve browser performance.  


Before you begin
This is an optional configuration. You do not need to perform
this procedure if you are compressing content elsewhere in your network.
Compression requires a significant amount of CPU; you must monitor
resource availability if you choose to use this option.


About this task
The directives discussed here do not compress images, but
do compress JavaScript. 
To
specify which types of files to compress, complete the following steps:




Procedure
  1. Using a text editor, open the httpd.conf file.
The file is stored in the following directory by default: 
    • AIX: /usr/IBM/HTTPServer/conf
      • 

    • Linux: /opt/IBM/HTTPServer/conf
      • 

    • Microsoft Windows: C:\IBM\HTTPServer\conf
      • 

    

    2. 

  2. Find the following entry in the configuration file: 
    LoadModule deflate_module modules/mod_deflate.so
    

    If
this entry is not present, add it.
    

    3. 

  3. Add the following statements to compress multiple content
types used by IBM Connections: 
    #Only the specified MIME types will be compressed.

AddOutputFilterByType DEFLATE application/atom+xml
AddOutputFilterByType DEFLATE application/atomcat+xml
AddOutputFilterByType DEFLATE application/javascript
AddOutputFilterByType DEFLATE application/json
AddOutputFilterByType DEFLATE application/octet-stream
AddOutputFilterByType DEFLATE application/x-javascript
AddOutputFilterByType DEFLATE application/xhtml+xml
AddOutputFilterByType DEFLATE application/xml
AddOutputFilterByType DEFLATE text/css
AddOutputFilterByType DEFLATE text/html
AddOutputFilterByType DEFLATE text/javascript
AddOutputFilterByType DEFLATE text/plain
AddOutputFilterByType DEFLATE text/xml
AddOutputFilterByType DEFLATE text/xsl
    

    4. 

  4. Add the following statement to specifically indicate that
image files and binaries must not be compressed to prevent web browser
hangs: 
    # Ensures that images and executable binaries are not compressed
SetEnvIfNoCase Request_URI \\.(?:gif|jpe?g|png|exe)$ no-gzip dont-vary
    

    5. 

  5. Add the following statement to ensure that proxy servers
do not modify the User Agent header needed by the previous statements: 
    # Ensure that proxies do not deliver the wrong content
Header append Vary User-Agent env=!dont-vary
    
If the following
line is commented out, remove the commenting from it:
    LoadModule headers_module modules/mod_headers.so

    

    6. 

  6. Save and close the configuration file.
    7. 

  7. Restart IBM HTTP
Server.
    8. 







Updating web addresses in IBM HTTP Server


Update the web addresses that IBM HTTP Server uses to access IBM Connections applications. 


Before you begin
If
you installed and configured IBM HTTP Server after installing IBM Connections, your IBM Connections
applications are automatically mapped to the web server. However,
if you installed and configured IBM HTTP Server before installing IBM Connections, you must manually map the applications.


Before
continuing with this task, map the application modules to IBM HTTP Server. For more information,
see the Mapping applications to IBM HTTP Server topic.


If you are using the Files
or Wikis applications, configure IBM HTTP Server to handle file downloads from those applications.
For more information, see the Configuring Files and Wikis downloading topic. 


If you choose to let the WebSphere Application Server redirect servlet
manage file downloading, you must configure the server to transfer
data synchronously instead of asynchronously. This configuration helps
avoid errors caused by using too much memory. See the Excessive native memory use in IBM WebSphere Application Server technote for instructions.




About this task
If you
do not install a web server such as IBM HTTP Server, users must include the correct port number
in the web address that they use to access the application. When you
use a webserver, users can access the applications without using port
numbers. 


By
default, the web address that you enter to access IBM Connections applications includes the port
number for each application. To avoid using port numbers, update the
web addresses by editing the LotusConnections-config.xml file. IBM HTTP Server can
then redirect requests to the appropriate port for each application.


For more information about editing
configuration files, see the Editing configuration files topic. 


To update the web addresses to your IBM Connections applications, complete the following
steps:




Procedure
  1. Stop WebSphere Application Server.
    2. 

  2. Check out the LotusConnections-config.xml file. The file is stored by default in the following directory: 
    • AIX: /usr/IBM/WebSphere/AppServer/profiles/profile_name/config/cells/cell_name/LotusConnections-config 
      • 

    • Linux: /opt/IBM/WebSphere/AppServer/profiles/profile_name/config/cells/cell_name/LotusConnections-config 
      • 

    • Windows: C:\IBM\WebSphere\AppServer\profiles\profile_name\config\cells\cell_name\LotusConnections-config 
      • 

    
	  
    3. 

  3. For each application, update the web addresses specified
in the href and ssl_href properties: 
    <sloc:href>
<sloc:hrefPathPrefix>/application</sloc:hrefPathPrefix>
<sloc:static
href="http://webserver:port"
ssl_href="https://webserver:port">
<sloc:interService 
href="https://webserver:port">
</sloc:href>
    

    where
    • webserver is the domain name of IBM HTTP Server, such as webserver.example.com.
      • 

    • port is the default port number of the application.
Remove the port number when you specify a webserver. 
      • 

    • application is the name of an IBM Connections application.
      • 

    

    

    Note: 
    Each href attribute in the LotusConnections-config.xml file is case-sensitive and
must specify a fully-qualified domain name.
    

    

    For example, to update the web address for Communities, add the
following specifications to the file:
    

    <sloc:href> 
    

    <sloc:hrefPathPrefix>/communities</sloc:hrefPathPrefix> 
    

    <sloc:static href="http://webserver.example.com"
    

    ssl_href="https://webserver.example.com">
    

    <sloc:interService  href="https://webserver.example.com"> 
    

    </sloc:href>
    

    Note: If you plan to use a reverse proxy,
the web addresses defined in this file must be updated to match the
appropriate proxy server URLs. Go to the IBM Connections wiki for
more information about deployment scenarios, including how to configure
a reverse proxy.
    

    

    4. 

  4. Save and check in the LotusConnections-config.xml file.
    5. 

  5. Synchronize the nodes.
    6. 

  6. Log on to each application to ensure that the web addresses
in the navigation bar are correct.
    7. 



Results
You can access each application without needing to specify
a port number.








Configuring the Home page administrator


Create an administrator for Home page so that you can make
changes to the application such as adding and removing widgets.


Before you begin
IBM Connections administrators
must be dedicated users. Their only purpose should be application
administration.




About this task
Only a Home page administrator can add, remove, enable,
or disable widgets on the Home page. For more information, see the Administering
the Home page from the user interface topic.
Note: You can also
create global administrators for any of the applications, for the
purpose of managing content. For more information, see the Administering
application content topic.




To
configure administrative access to the Home page application, complete
the following steps:




Procedure
  1. Log in to the WebSphere Application
Server Integrated Solutions Console on the Deployment Manager.
    2. 

  2. Select Applications > Application Types > WebSphere enterprise
applications. 
    3. 

  3. Click the link to the Home page application.
    4. 

  4. Click the Security role to user/group mapping link. 
    5. 

  5. Select the check box beside the admin role and then click Map
Users.
    6. 

  6. In the Search String box, type the
name of the person whom you would like to set as an administrator,
and then click Search. If the user name exists
in the LDAP directory, it is found and displayed in the Available box.
    7. 

  7. Select the name from the Available box
and then move it into the Selected column by
clicking the right arrow button. 
    8. 

  8. Repeat Steps 4 and 5 to add more users to the administrative
role.
    9. 

  9. Click OK. 
    10. 

  10. From the Enterprise Applications > <application> > Security role to
user/group mapping page, click OK and
then click Save. 
    11. 

  11. Synchronize and restart all your WebSphere Application Server instances.
    12. 







Enabling Search dictionaries


During installation,
only the English language dictionary
is enabled by default. When your organization spans multiple geographies
and multiple languages, you need to enable the relevant language dictionaries
for your deployment to ensure that Search returns optimum results
for your users.


For non-English deployments,
enabling multilingual support for
Search is a mandatory post-installation step that needs to be performed
before you start your IBM Connections
Search server for the first time. Without multiple dictionary support,
for languages other than English, Search only returns results where
there is an exact match between the search term and content term.
Enabling multiple dictionaries ensures better quality search results
when your user base is multilingual.


For information about how
to enable multilingual support, see Configuring
dictionaries for Search.




Related concepts:







Creating the initial Search index


When you install IBM Connections,
Search indexing is automatically configured. To create the initial
Search index, all you need to do is wait for one of the default indexing
tasks to run.


Before you begin
When you are installing a non-English language deployment,
you must enable the relevant language dictionaries for your deployment
before creating the initial Search index. Without multiple dictionary
support, for languages other than English, Search only returns results
where there is an exact match between the search term and the content
term. Enabling multiple dictionaries ensures better quality search
results when your user base is multilingual. For more information,
see Configuring dictionaries for Search.


About this task
Initial index creation occurs when any scheduled indexing
task fires and an index does not yet exist. As part of the initial
index creation process, the index is automatically rolled out to the
secondary nodes in your deployment. Each node running the Search application
must have the Search index stored locally on the node's file system.
Because there are multiple indexes in a clustered environment, they
must all be kept in synchronization with each other. 
The Search
index directory is defined by the IBM WebSphere Application Server
variable SEARCH_INDEX_DIR. You can change the location of the index
by editing this variable. For more information, see Changing
the location of the Search index.


After the initial index
has been built and optimized, the contents of the index directory
are copied to a staging folder. When the newly-built index is successfully
posted, JMS messages are broadcast so that each node automatically
downloads the index from the staging folder and loads it. The index
management tables are populated at the same time. For Search to function
properly, the initial index must have completed successfully and it
must be deployed to all nodes.
Important: Do not stop your
deployment until the index has been copied to all nodes. If the server
is stopped during this process, the index will not be successfully
rolled out to all nodes. In this event, you need to manually copy
the index from the staging location to the other nodes.




You
can change the location of the Search index staging folder by editing
the WebSphere Application
Server variable, SEARCH_INDEX_SHARED_COPY_LOCATION.






Related concepts:





Related tasks:







Related reference:







Copying Search conversion tools to local nodes


To enable full indexing of data, copy the Search conversion
tools to local nodes.


Before you begin
Perform this task only on nodes in the Search cluster.
If you added a node to an existing cluster, as described in the Adding a node to a cluster topic, complete this task only
if the new node is a member of the Search cluster. References to nodes
in the steps of this task apply only to nodes in the Search cluster.


Steps 1-3 and 6-7 are required for all supported operating systems.
However, if your deployment has only one node, skip steps 1-3. Steps
4-5 are required only if you are using the AIX or Linux operating system.




About this task
The Search conversion tools index Files and Wiki attachments.
The tools work best when they are available locally on each node.
However, when IBM Connections
was installed, the conversion tools were deployed on a network share.
Therefore, you must copy the tools to each node in the Search cluster.


To copy Search conversion tools to local nodes, complete the following
steps:




Procedure
  1. Identify the nodes in the Search cluster.
    1. Log in to the Integrated Solutions Console and click Servers > Clusters > WebSphere application server clusters.
      2. 

    2. Click cluster_name, where cluster_name is the name of the Search
cluster.
      3. 

    3. In the Additional Properties area, expand Cluster members and then click Details.
      4. 

    4. In the table of cluster members, make a note of the
nodes that host the cluster members.
      5. 

    

    2. 

  2. Copy the shared_data_directory_root/search/stellent directory from the shared content folder to a local directory on
each node. Use exactly the same path on each node. The
following path is an example only and might be different on your operating
system: 
    • AIX or Linux: /opt/IBM/Connections/data/local/search/stellent
      • 

    • Windows: C:\IBM\Connections\data\local\search\stellent
      • 

    

    

    The new directory contains the exporter executable file.
    

    3. 

  3. On the Deployment Manager, update the FILE_CONTENT_CONVERSION
Websphere variable to point to the exporter file
in the local directory on each node. 
    For example: /opt/IBM/Connections/data/local/search/stellent/dcs/oiexport/exporter 
    

    The exporter file must be in the same file path on all nodes. 
    
 
    For more information about WebSphere variables, see the Changing WebSphere Application Server
environment variables topic.
    

    4. 

  4. (AIX and Linux only) Back up the setupCmdLine.sh file on each node. This file is in the app_server_root/AppServer/bin directory. 
    5. 

  5. (AIX and Linux only) Add the following text to the end
of the setupCmdLine.sh file on each node:
    1. export PATH=$PATH:SearchBinariesHome/dcs/oiexport
       
      where SearchBinariesHome is the path to the directory that you specified in Step 2.
      

      2. 

    2. Choose the option for your operating system: 
      • AIX: export LIBPATH=$LIBPATH:SearchBinariesHome/dcs/oiexport
        • 

      • Linux: export
LD_LIBRARY_PATH=$LD_LIBRARY_PATH:SearchBinariesHome/dcs/oiexport
        • 

      

      3. 

    

    6. 

  6. Restart all node agents.
    7. 

  7. Restart WebSphere Application Server on each node.
    8. 







Accessing Windows network shares


Configure a user account to access network shares in an IBM Connections deployment on the Microsoft Windows operating system


Before you begin
This task applies
only to deployments of IBM Connections
environments where the data is
located on network file shares, and where you have installed WebSphere Application Server
on Microsoft Windows and configured it to run as a service.


About this task
When WebSphere Application
Server runs as a Windows service,
it uses the local system account to log in
with null credentials. When WebSphere Application
Server tries to access an IBM Connections
network share using Universal
Naming Convention (UNC) mapping, the access request fails because
the content share is accessible only to valid user IDs. 
Note: When
using a Windows service
to start WebSphere Application
Server, you must use UNC mapping; you cannot use drive letters to
reference network shares.


To resolve this problem, configure
the WebSphere Application
Server service login attribute to log in with a user account that
is authorized to access the content share. 


To configure the WebSphere Application Server
service, complete the following steps:




Procedure
  1. Click
 Start > Control Panel and select Administrative Tools > Services.
    2. 

  2. Open
the service for the first node in the list of WebSphere Application Server
services.
    3. 

  3. Click the Log On tab
and select This account.
    4. 

  4. Enter
a user account name or click Browse to search
for a user account.
    5. 

  5. Enter the account password,
and then confirm the password. 
    6. 

  6. Click OK to
save your changes and
click OK again to return to the Services window.
    7. 

  7. Stop and restart the service.
    8. 

  8. Repeat
steps 3-7 for each node.
    9. 



What to do next
Your corporate
password policy might require that you change
this login attribute periodically. If so, remember to update this
service configuration. Otherwise, your access to network shares might
fail.






Configuring
Moderation


Configure moderation so that moderators
can review content
for blogs, forums, and community files from a central interface.


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. Moderated
content can be:
  • Blog entries and comments. These can be in
stand-alone blogs or
community blogs.
    • 

  • Forum posts and replies. These can be in
stand-alone forums or
community forums.
    • 

  • Files and comments within a community.
    • 





To enable moderation, follow these steps:
  1. Install
the Moderation application as part of the Connections
installation or migration.
    2. 

  2. Assign users to the role of global
moderator so they can moderate
content from a central interface.
    3. 

  3. Configure moderation in
the contentreview-config.xml file if you
want to enable moderation features such as owner moderation or assign
content reviewers for flagged content.
    4. 







Designating global moderators


Assign users to the role of global-moderator so they can
moderate content for blogs, forums, and community files from a central
interface.


About this task
In order for a user to moderate content, they must be
assigned the global-moderator role for the Moderation application
and for the applications you want moderated, which can be Blogs, Forums,
Files, and Communities.




Procedure
To map users to a global moderator role, complete the
following steps:
  1. Map a user to a global-moderator role:
    1. Expand Applications > Application Types, and then select WebSphere
enterprise applications. Find and click the link to the
application that you want to configure.
      2. 

    2. Click Security role to user/group mapping.
      3. 

    3. Select the check box for the global-moderator role,
and then click Map users.
      4. 

    4. In the Search String box, type
the name of the user to assign to the role, and then click Search.
If the user exists in the directory, it is displayed in the Available list.
      5. 

    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. 

    6. Click OK.
      7. 

    7. Click OK, and then click Save to
save the changes.
      8. 

    

    2. 

  2. Synchronize and restart all your WebSphere Application Server instances.
    3. 







Configuring J2C Aliases for the moderation proxy service


Configure J2C Aliases so that community owners can moderate
their community Blogs, Forums, and Files applications.


About this task
Moderation actions are performed by a moderation API.
Community owners cannot access that API, so IBM Connections handles their moderation requests
through a proxy service. The proxy service uses J2C Aliases to pass
the requests. Proxy service alias users must be in the global-moderator
roles of the appropriate applications, and they must be able to log
in to IBM Connections.


By default the proxy service uses the
connectionsAdmin J2C Alias provided during installation. That user
is mapped to the global-moderator roles for Blogs, Forums, Files,
Moderation, and Communities by the installation program, and can log
in to IBM Connections. However, you can create different moderation
aliases for each of the different supported applications. You can
create the following aliases:
  • For Blogs create an alias called moderationBlogsAlias.
    • 

  • For Files create an alias called moderationFilesAlias.
    • 

  • For Forums create an alias called moderationForumAlias.
    • 





The different applications recognize these specific aliases.
You can map any users to these aliases, but all users must be in the
global-moderator roles of the appropriate application, and they must
be able to log into IBM Connections. For example, the moderationBlogsAlias
user must be in the global-moderator role for Blogs. See Roles.


The
proxy service logs its actions, so if the users (other than the connectionAdmin
user) are only used for this purpose, it will make reading the log
more clear.




Procedure
To create moderation aliases and then map them to a global
moderator role, complete the following steps:
  1. Create a moderation alias:
    1. From the IBM WebSphere Application Server
Integrated Solutions Console, expand Security,
and then click Global security.
      2. 

    2. In the Authentication area, expand Java
Authentication and Authorization Service, and click J2C
authentication data.
      3. 

    3. Click New.
      4. 

    4. Name the alias, for example moderationFilesAlias.
      5. 

    5. Type the name and password of a user for the alias.
      6. 

    6. Click OK.
      7. 

    

    2. 

  2. Map an alias user to a global-moderator role:
    1. Expand Applications > Application Types, and then select WebSphere
enterprise applications. Find and click the link to the
application that you want to configure.
      2. 

    2. Click Security role to user/group mapping.
      3. 

    3. Select the check box for the global-moderator role,
and then click Map users.
      4. 

    4. In the Search String box, type
the name of the user to assign to the role, and then click Search.
If the user exists in the directory, it is displayed in the Available list.
      5. 

    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. 

    6. Click OK.
      7. 

    7. Click OK, and then click Save to
save the changes.
      8. 

    

    3. 

  3. Synchronize and restart all your WebSphere Application Server instances.
    4. 









Synchronizing files shared with communities


After upgrading, you must synchronize files that have been
shared with communities.


About this task
After upgrading the IBM Connections applications and databases,
but before any users have access, you must synchronize files shared
with communities.


Procedure
To run the command FilesDataIntegrityService.syncAllCommunityShares()
follow the steps detailed in the topic Running Files administrative
commands.




Related tasks:







Configuring Cognos Business
Intelligence


Configure your IBM Cognos  Business Intelligence
environment to work with IBM Connections.


After you have installed Cognos Business
Intelligence, configure the environment by completing the following
tasks:




Applying fix packs to update the Cognos server


Apply available fix packs to the Cognos Business Intelligence server to provide
important product corrections. These fixes must be applied after Cognos Business Intelligence
has been installed.


Before you begin
Install Cognos Business
Intelligence and federate the server to the IBM Connections Deployment Manager as explained
in Installing Cognos Business Intelligence in the Pre-installation section
of this documentation.


For additional information on updating Cognos Business Intelligence
with fix packs, see Installing Fix Packs in the Cognos information center.




About this task
Download the latest fix pack and apply it to the Cognos server. At a minimum,
you will need to apply the fix pack listed below, but you should check
with IBM Fix Central in
case additional fix packs were made available after this documentation
was published. Fix packs are cumulative; when you install the latest
fix pack, it includes updates from all previous fix packs.




Procedure
  1. Stop IBM WebSphere Application Server
and verify that all Cognos services
have stopped before proceeding to the next step. 
    After
stopping the server, wait at least 1 full minute to ensure that all Cognos processes have stopped:
 
    • IBM AIX or Linux: cgsServer.sh and CAM_LPSvr processes
      • 

    • Microsoft Windows: cgsLauncher.exe and CAM_LPSvr processes
      • 

    

    

    2. 

  2. Download fix packs for Cognos Business
Intelligence 10.1.1 from IBM Fix Central. 
    Table 31. Fix packs required for a new deployment of IBM Cognos for IBM Connections
    Operating system
Fix pack

    
    

    AIX
10.1.1-BA-CBI-AIX64-FP001

    

    Linux
10.1.1-BA-CBI-Linuxi38664-FP001 

    

    Windows
10.1.1-BA-CBI-Win64-FP001

    

    zLinux
10.1.1-BA-CBI-zLinux64-FP001 

    
    

    

    

    1. Review the fix pack prerequisites and make sure your
deployment satisfies all requirements.
      2. 

    2. Download the appropriate compressed tar file
for your operating system using the links in the "Download Package"
section. 
      Some browsers might change a downloaded file’s
type from .tar.gz to a file type not recognized by
the operating system. To correct this, change the file type back to .tar.gz after
the download is complete. Using Download Director will prevent inadvertent
renaming of files at download.
      

      3. 

    

    3. 

  3. Expand the downloaded fix pack. 
     AIX or Linux
    1. Open command prompt or terminal window.
      2. 

    2. Change to the directory where you have downloaded the fix pack.
      3. 

    3. Run the following command to expand the package using either GNU Zip (gzip)
or GNU Tar (tar):
      gunzip fix_pack_file_name.tar.gz | tar xvf – 
      

      4. 

    

    

     Windows
    1. Open a command prompt.
      2. 

    2. Change to the directory where you have downloaded the fix pack.
      3. 

    3. Expand the package using your file compress and decompress utility
(if you are using WinZip, select the option "Use folder names" to
retain the package’s folder structure).
      4. 

    

    

    4. 

  4. Apply the fix pack: 
    AIX or Linux:
    

    1. Change to the directory where you expanded the fix pack.
      2. 

    2. Now change to the following subdirectory: 
      • AIX: /aix64h
        • 

      • Linux: /linuxi38664h
        • 

      • zLinux: /zlinux64h
        • 

      

      3. 

    3. Run the following command: ./issetup 
      If you do not use XWindow, run an unattended installation
as explained in Set Up an Unattended Installation Using a File From
an Installation on Another Computer in the Cognos information center.
      

      4. 

    4. Follow the instructions in the installation wizard,
install the fix pack in the same location as your existing IBM Cognos components. 
      This installation location is the path specified for the cognos.biserver.install.path property
in the cognos-setup.properties file.
      

      5. 

    
 
    Windows:
    

    1. Change to the directory where you expanded the fix pack.
      2. 

    2. Now change to the \win64h subdirectory.
      3. 

    3. Run the following command: issetup.exe
      4. 

    4. Follow the instructions in the installation wizard,
install the fix pack in the same location as your existing IBM Cognos components. 
      This installation location is the path specified for the cognos.biserver.install.path property
in the cognos-setup.properties file.
      

      5. 

    

    5. 

  5. Generate a new Cognos BI
Server EAR file with the fix pack:
    1. Locate the cognos-setup-update.sh|bat script
in the directory where you expanded the CognosConfig.zip or CognosConfig.tar when
you installed Cognos Business Intelligence components as
part of the pre-install task.
      2. 

    2. Edit the cognos-setup.properties file
and verify that it contains the appropriate values for each property. 
      All passwords were removed from this file the last time it
was used, so you must either add the passwords again, or pass them
in from the command line when you run the cognos-setup-update.sh|bat script.
      

      3. 

    3. Run the cognos-setup-update.sh|bat script.
      4. 

    

    6. 

  6. Apply the new EAR file to the Cognos server by running an update in the WebSphere Integrated Solutions
Console:
    1. On the server where Cognos BI
Server is installed, start WebSphere Application
Server.
      2. 

    2. Log in to the Integrated Solutions Console as the WebSphere administrator.
      3. 

    3. Click Servers > Enterprise Applications.
      4. 

    4. In the list of applications, select the Cognos where you generated the new EAR file,
and click the Update button in the table.
      5. 

    5. Browse to the newly built EAR file residing in the Cognos_BI_Server_install_path directory,
and click Next.
      6. 

    6. Complete the remaining screens by accepting the default
values and clicking Next.
      7. 

    7. Click Finish to complete the
update.
      8. 

    

    7. 

  7. If necessary, enable anonymous access to the Cognos server: 
    If you disabled
anonymous access to the Cognos server,
you must enable it now because the script that updates the configuration
requires that anonymous access be enabled. There are two ways to enable
anonymous access. You can run the Cognos Configuration
tool or, if your Cognos server
runs on AIX or Linux and does not provide a graphical user
interface, you can enable anonymous access manually.
    

    Note: It is
not necessary to disable anonymous access again when you complete
this task because you will do that when you configure LDAP authentication
in the next task. 
    

    Enabling anonymous access with the Cognos Configuration tool:
    

    1. Navigate to the /bin directory
of the Cognos BI Server installation
directory: 
      For example:
      • AIX or Linux: /opt/IBM/Cognos64/bin/
        • 

      • Windows: C:\Program
Files\IBM\Cognos\bin
        • 

      

      

      2. 

    2. Start the Cognos Configuration
tool by running the following command: 
      • AIX or Linux: ./cogconfig.sh
        • 

      • Windows: cogconfig.bat
        • 

      

      3. 

    3. Expand Local Configuration > Security > Authentication > Cognos and set Allow
anonymous access? to True.
      4. 

    4. Exit the Cognos Configuration
tool, making sure to select No at the following
prompt: The service 'IBM Cognos' is not running
on the local computer. Before you can use it your computer must start
the service. Do you want to start this service before exiting?
      5. 

    5. Restart IBM WebSphere Application Server.
      6. 

    
 
    Enabling anonymous access manually:
    

    1. Navigate to the /configuration directory
within the Cognos BI Server
installation directory: 
      For example:
      • AIX or Linux: /opt/IBM/Cognos64/bin/
        • 

      • Windows: C:\Program
Files\IBM\Cognos\bin
        • 

      

      

      2. 

    2. Open the working copy of the cogstartup.xml file
for editing.
      3. 

    3. Within the <crn:instance name="Cognos" class="Cognos"> section,
change the allowAnon parameter: 
      From:
      

      <crn:parameter name="allowAnon">
<crn:value xsi:type="xsd:boolean"> false </crn:value>
</crn:parameter>
      

      To:
      

      <crn:parameter name="allowAnon">
<crn:value xsi:type="xsd:boolean"> true </crn:value>
</crn:parameter>
      

      4. 

    4. Save and close the file.
      5. 

    5. Restart WebSphere Application
Server.
      6. 

    

    8. 

  8. Run the cognos-configure.sh|bat script
to configure the Cognos server
and set up database connections, just as you did when you originally
deployed the Cognos server. 
    Output from this operation is stored in the /CognosSetup/cognos-configure.log file.
    

    Attention: If you encounter an error when running the cognos-configure.sh|bat script,
correct the error and run the script again before proceeding to the
next task.
    

    9. 







Configuring support for LDAP authentication for Cognos Business Intelligence


Configure the IBM Cognos Business Intelligence
server to support the use of an LDAP directory for user authentication. 


About this task
Configure Cognos Business
Intelligence to use the same LDAP directory that IBM Connections uses for authentication. Configuring
LDAP authentication involves disabling anonymous access and restricting
access to the namespace. Be sure to use the namespace specified by
the cognos.namespace property in the cognos-setup.properties file;
by default, that namespace is called IBMConnections.


For
general information on LDAP authentication in Cognos, see the Cognos information
center.
Attention: If you will be configuring LDAP
authentication over SSL, see the IBM technote Configuring LDAPS (LDAP via SSL) for CRN/Cognos 8 (also
applicable to later versions of the product).






Procedure
Set the values for the LDAP properties as shown in this
example, which configures Cognos for IBM Directory Server. For detailed
instructions, see Configure LDAP support in the Cognos information center.
  1. Start the Cognos Configuration
tool. 
    Note: The Cognos Configuration
tool provides a graphical user interface for defining LDAP properties.
If your IBM AIX or Linux server
does not support a graphical user interface, see the topic Configuring LDAP settings
manually for instructions on configuring these LDAP authentication
settings manually.
    

    2. 

  2. Navigate to the /bin directory of
the Cognos BI Server installation
directory. 
    For example:
    • IBM AIX or Linux: /opt/IBM/Cognos64/bin/
      • 

    • Microsoft Windows:C:\Program Files\IBM\Cognos\bin
      • 

    

    

    3. 

  3. Start the Cognos Configuration
tool by running the following command: 
    • AIX or Linux: ./cogconfig.sh
      • 

    • Windows:cogconfig.bat
      • 

    

    4. 

  4. Expand Local Configuration > Security > Authentication > IBMConnections and set the values
shown here for the following properties: 
    IBMConnections is
the namespace, specified in the cognos.namespace property
of the cognos-setup.properties file used for
deploying the Cognos server.
    

    Note: These
settings are for IBM Directory
Server; you might need different settings for another LDAP directory.
    

    • User lookup: (uid=${userID})  
      • 

    • Use external identity? True  
      • 

    • External identify mapping: (uid=${environment("REMOTE_USER")}) 
      • 

    

    5. 

  5. Expand Local Configuration > Security > Authentication > Cognos and set Allow
anonymous access? to False.
    6. 

  6. Exit the Cognos Configuration
tool, making sure to select No at the following
prompt: The service 'IBM Cognos' is not running
on the local computer. Before you can use it your computer must start
the service. Do you want to start this service before exiting?
    7. 

  7. Restart the Cognos server:
    1. Stop the IBM WebSphere Application Server
that hosts the Cognos server.
      2. 

    2. Wait at least 1 full minute to ensure that all Cognos processes have stopped: 
      • AIX or Linux: cgsServer.sh and CAM_LPSvr processes
        • 

      • Windows: cgsLauncher.exe and CAM_LPSvr processes
        • 

      

      3. 

    3. Start WebSphere Application
Server.
      4. 

    4. Start the Cognos server.
      5. 

    

    8. 



What to do next
After you have configured LDAP authentication for Cognos
Business Intelligence, you must add users to the IBMConnectionsMetricsAdmin
within the Cognos deployment as described in Configuring the IBMConnectionsMetricsAdmin
role on Cognos.






Configuring LDAP settings manually


If your IBM Cognos Business Intelligence
server runs on IBM AIX or Linux and
does not provide a graphical user interface, you can configure LDAP
authentication settings manually.


About this task
You can configure the use of the LDAP directory by adding
a component to the Cognos server’s cogstartup.xml file
and then customizing it for your deployment.


For general information
on LDAP authentication in Cognos,
see the Cognos information
center.
Attention: If you will be configuring LDAP
authentication over SSL, see the IBM technote Configuring LDAPS (LDAP via SSL) for CRN/Cognos 8 (also
applicable to later versions of the product).






Procedure
  1. On the computer where you installed Cognos Business Intelligence, navigate to
the /configuration directory within the installation
location of the BI Server component (specified by the cognos.biserver.install.path property
in the cognos-setup.properties file); for example: 
    • IBM AIX or Linux: /opt/IBM/Cognos64/configuration
      • 

    • Microsoft Windows: C:\Program Files\IBM\Cognos\configuration
      • 

    

    2. 

  2. Make a backup copy of the cogstartup.xml file.
    3. 

  3. Open the working copy of the cogstartup.xml file
for editing.
    4. 

  4. Now open the Authentication sample file for your locale,
stored in the /samples subdirectory. 
    The
file name includes the locale code; for example, open the Authentication_en.xmlfile
if you are using English.
    

    5. 

  5. Within the Authentication_language_code.xml file,
locate and copy the section of code for your LDAP directory product. 
    Look for the (Begin of)LDAP template and (End
of)LDAP template comments that enclose the section, and be
sure to copy everything between them (the entire crn_instance).
    

    <!--
===============================================
(Begin of) LDAP template
-->
 <crn:instance name="LDAP Name" class="LDAP"...>

...

</crn:instance> 
<!--
(End of) LDAP template
===============================================
-->
    

    6. 

  6. Paste the copied code into the cogstartup.xml file. 
    You can insert the new code before the closing </crn:instances> line
at the end of the file. 
    

           </crn:instances>     </crn:value>
  </crn:parameter>
</crn:parameters>
    

    7. 

  7. Update the new code by making the following changes:  
    Note: The settings shown in substeps a, b, and c are for IBM Directory Server; you might
need different settings for another LDAP directory.
    

    1. Change the userLookup parameter: 
      From:
      

      <crn:parameter name="userLookup">
<crn:value xsi:type="xsd:string"> ${userID} </crn:value>
</crn:parameter>
      

      To:
      

      <crn:parameter name="userLookup">
<crn:value xsi:type="xsd:string"> (uid=${userID}) </crn:value>
</crn:parameter>
      

      2. 

    2. Change the useExternalIdentity parameter: 
      From:
      

      <crn:parameter name="useExternalIdentity">
<crn:value xsi:type="xsd:boolean"> false </crn:value>
</crn:parameter>
      

      To:
      

      <crn:parameter name="useExternalIdentity">
<crn:value xsi:type="xsd:boolean"> true </crn:value>
</crn:parameter>
      

      3. 

    3. Change the externalIdentityMapping parameter: 
      From:
      

      <crn:parameter name="externalIdentityMapping">
<crn:value xsi:type="xsd:string"> ${environment("REMOTE_USER")} </crn:value>
</crn:parameter>
      

      To:
      

      <crn:parameter name="externalIdentityMapping">
<crn:value xsi:type="xsd:string"> (uid=${environment("REMOTE_USER")}) </crn:value>
</crn:parameter>
      

      4. 

    4. Within the <crn:instance name="Cognos" class="Cognos"> section,
change the allowAnon parameter: 
      From:
      

      <crn:parameter name="allowAnon">
<crn:value xsi:type="xsd:boolean"> true </crn:value>
</crn:parameter>
      

      To:
      

      <crn:parameter name="allowAnon">
<crn:value xsi:type="xsd:boolean"> false </crn:value>
</crn:parameter>
      

      5. 

    

    8. 

  8. Save and close the file.
    9. 

  9. Validate the modified file by running the following command: ./cogconfig.sh
-config
    10. 

  10. Restart the Cognos server:
    1. Stop the IBM WebSphere Application Server
that hosts the Cognos server.
      2. 

    2. Wait at least 1 full minute to ensure that all Cognos processes have stopped: 
      • AIX or Linux: cgsServer.sh and CAM_LPSvr processes
        • 

      • Windows: cgsLauncher.exe and CAM_LPSvr processes
        • 

      

      3. 

    3. Start WebSphere Application
Server.
      4. 

    4. Start the Cognos server.
      5. 

    

    11. 



What to do next
After you have configured LDAP authentication for Cognos
Business Intelligence, you must add users to the IBMConnectionsMetricsAdmin
within the Cognos deployment as described in Configuring the IBMConnectionsMetricsAdmin
role on Cognos.










Granting access to global metrics


Configure the metrics-report-run security role to grant
users the authority to view and interact with global metrics.


About this task
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. 




Procedure
Configure the metrics-report-run security role in IBM WebSphere Application Server.


  1. On the Deployment Manager, log in to the Integrated Solutions
Console as the WebSphere administrator.
    2. 

  2. In the navigation tree, click Enterprise
Applications > Metrics > Security
role to user/group mapping.
    3. 

  3. In the roles table, click the check box next to the metrics-report-run role.
    4. 

  4. Click the Map Groups button in the
table.
    5. 

  5. Add one or more user groups to the metrics-report-run role,
giving those users the ability to view and interact with global metrics
reports. 
    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  slow performance,
as update requests are processed in sequence.
    

    6. 

  6. Click OK.
    7. 

  7. Save the change to the master configuration by clicking
the Save link in the "Messages" box.
    8. 

  8. Synchronize all nodes in the cell to the Deployment Manager,
and then restart the node agents:
    1. On the navigation tree, click System
Administration > Nodes.
      2. 

    2. Click the Full Resynchronize button
in the table.
      3. 

    3. Return to the navigation tree and click System Administration > Node agents.
      4. 

    4. In the nodes table, click the box in front of each node.
      5. 

    5. Click the Restart button in the
table.
      6. 

    

    9. 







Granting access to community metrics


Configure the community-metrics-run security role to grant
users the authority to view community metrics using static reports.


About this task
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.




Procedure
Configure the community-metrics-run security role
in IBM WebSphere Application Server.


  1. On the Deployment Manager, log in to the Integrated Solutions
Console as the WebSphere administrator.
    2. 

  2. In the navigation tree, click Enterprise
Applications > Metrics > Security
role to user/group mapping.
    3. 

  3. In the roles table, click the check box next to the community-metrics-run role.
    4. 

  4. Click the Map Groups button in the
table.
    5. 

  5. Add one or more user groups to the community-metrics-run
role, giving those users the ability to view community metrics as
static reports. 
    6. 

  6. Click OK.
    7. 

  7. Save the change to the master configuration by clicking
the Save link in the "Messages" box.
    8. 

  8. Synchronize all nodes in the cell to the Deployment Manager,
and then restart the node agents:
    1. On the navigation tree, click System
Administration > Nodes.
      2. 

    2. Click the Full Resynchronize button
in the table.
      3. 

    3. Return to the navigation tree and click System Administration > Node agents.
      4. 

    4. In the nodes table, click the box in front of each node.
      5. 

    5. Click the Restart button in the
table.
      6. 

    

    9. 







Configuring the IBMConnectionsMetricsAdmin role on Cognos


Configure the IBMConnectionsMetricsAdmin in Cognos Business Intelligence to ensure that
the Metrics administrator has access to features and reports.


About this task
After you have configured LDAP authentication for Cognos Business Intelligence,
you must configure the IBMConnectionsMetricsAdmin so
that specified LDAP users can access Cognos features.
In particular, you will want to add the following users to this role:
  • The user assigned to the Cognos administrator account
    The Cognos administrator is the primary
person responsible for configuring Cognos features
and reports.
    

    • 

  • All users who have been assigned to the admin role for Connections
    Anyone
tasked with administering the Connections deployment should have access
to Cognos features to ensure
they can manage the full deployment as needed.
    

    • 

  • All users who have been assigned to the metrics-report-run role
    Users
who have been authorized to run global metrics reports require access
to Cognos before they can
work with the reports.
    

    • 







Procedure
  1. Use a browser to navigate to the Cognos deployment with the following address: http://Host_Name:Port/Context_Root/servlet/dispatch/ext 
    where:
    • Host_Name is the fully qualified
host name of the Cognos server;
for example, host.example.com. This value is
specified in the was.fqdn.hostname property in the cognos-setup.properties file
used for installing the server.
      • 

    • Port is the port that the Cognos server is listening on.
      • 

    • Context_Root is the context
root to which you installed the Cognos server;
for example, cognos.
      • 

    
 
    

    2. 

  2. Log in to Cognos using
an IBM Connections administrator
account.
    3. 

  3. On the Cognos dashboard,
click Log On.
    4. 

  4. On the next page, click Launch and
then select IBM Cognos Administration.
    5. 

  5. Select the Security tab.
    6. 

  6. On the Directory page, select Cognos from
the list and then select the IBMConnectionsMetricsAdmin role.
    7. 

  7. Add users to the IBMConnectionsMetricsAdmin role:
    1. With the IBMConnectionsMetricsAdmin role
selected, click the Set properties Set properties icon icon. 
      2. 

    2. In the properties window, click the Members tab,
and then click Add.
      3. 

    3. In the Add window, click Show users in the
list.
      4. 

    4. Select all users who require administrator access to Cognos Business Intelligence,
click Add to add them to the role. 
      Remember
to add at least the following users:
      • The Cognos administrator
        • 

      • All Connections administrators
        • 

      • All users assigned to the metrics-report-run role
        • 

      

      

      5. 

    5. Click OK to save the change.
      6. 

    6. Save the change to the master configuration by clicking Save in
the "Messages" box.
      7. 

    

    8. 

  8. Back in the users list, select the System Administrators role
and limit access to the role by removing Everyone from
the members list:
    1. With the System Administrators role
selected, click the Set properties Set properties icon icon. 
      2. 

    2. In the properties window, click the Members tab.
      3. 

    3. In the Members window, select Everyone,
and then click Remove to delete it from the
list of members.
      4. 

    4. Click OK to save the change.
      5. 

    5. Save the change to the master configuration by clicking Save in
the "Messages" box.
      6. 

    

    9. 







Configuring PowerCube refresh schedules


By default, IBM Cognos Transformer refreshes
each PowerCube with incremental updates once each day, and replaces
the cube’s data for the current month once a week. These jobs are
scheduled by default but you might need to modify the schedules to
avoid conflicts with other activities.


About this task
When scheduling the refresh jobs, keep the following issues
in mind:
  • These jobs should run at times when the Cognos system usage is relatively low, to
minimize the impact on normal usage. You should adjust these times
based on your system's usage pattern.
    • 

  • The weekly refresh should run only once every week; since it will
take longer to complete, you should schedule it for the time when
system usage is lowest (for example, on the weekend).
    • 

  • The daily refresh should run early in the morning (for example,
just after midnight), so users can see the latest metrics for the
previous day.
    • 







Procedure
On the computer hosting Cognos Transformer,
schedule the PowerCube updates, making sure the schedules for the
daily and weekly jobs do not collide:
  • AIX or Linux:
    Edit the cron jobs
in the system crontab.
    

    • 

  • Windows:
    Edit the
MetricsCubeDailyRefresh job to ensure it does not collide with the
weekly refresh. You can modify the job’s properties in the Task Scheduler
Library; for more information see the next topic.
    

    • 







Configuring the job scheduler for Cognos Transformer on Windows


Rather than store administrative credentials in a script,
you can add them to the job properties of the IBM Cognos Transformer
to enable scheduled tasks on Microsoft Windows.


About this task
Finish configuring the job scheduler to run the Transformer
periodically by adding the Windows Administrator
credentials to the MetricsCubeDailyRefresh scheduler job. 




Procedure
  1. Click Start > Control
Panel > Administrative Tools and click Task Scheduler.
    2. 

  2. In the navigation tree, click Task Scheduler
Library.
    3. 

  3. In the list of scheduled tasks, click MetricsCubeDailyRefresh to
view its properties.
    4. 

  4. In the MetricsCubeDailyRefresh Properties window,
open the General tab and click the Change
User or Group button.
    5. 

  5. In the Select user or group dialog
box, type administrator in the Enter
the object name to select field, and then click the Check
Names button. 
    The Task Scheduler compiles a list accounts with administrative
access on this Windows server.
    

    6. 

  6. When the Task Scheduler dialog box
prompts to Enter the user account information to run
this task, select the Windows Administrator
user name that will be associated with the MetricsCubeDailyRefresh
task, and type the password associated with that account; then click OK. 
    The selected administrator account now has the authority
to run the MetricsCubeDailyRefresh task.
    

    7. 

  7. Click OK to save the change and
close the MetricsCubeDailyRefresh Properties window.
    8. 

  8. Close the Task Scheduler.
    9. 









Configuring Cognos Business
Intelligence to use IBM HTTP
Server


IBM Cognos Business Intelligence uses the same IBM HTTP Server as IBM Connections, but you must configure Cognos Business Intelligence
to work with that server. 


About this task
After you have configured IBM HTTP
Server as described in the section Configuring IBM HTTP Server, complete
these tasks to configure the Cognos BI
Server and the Cognos Transformer
components to use HTTP:






Configuring Cognos BI
Server to use HTTP


Configure the Cognos BI
Server to use the IBM HTTP Server
that operates with the IBM Connections
deployment.


About this task
Use the Cognos Configuration
tool to specify settings that enable Cognos BI
Server to operate with IBM HTTP
Server.


Note: The Cognos Configuration
tool provides a graphical user interface. If your IBM AIX or Linux server does not support a
graphical user interface, see the topic Configuring HTTP manually
for Cognos BI Server for
instructions on configuring these settings manually.




Procedure
  1. Navigate to the /bin directory of
the Cognos BI Server installation
directory. 
    For example:
    • IBM AIX, Linux: /opt/IBM/Cognos64/bin/
      • 

    • Microsoft Windows:C:\Program Files\IBM\Cognos\bin
      • 

    

    

    2. 

  2. Start the Cognos Configuration
tool by running the following command: 
    • AIX, Linux: ./cogconfig.sh
      • 

    • Windows:cogconfig.bat
      • 

    

    3. 

  3. Expand Local Configuration > Environment and edit the URLs
for the following properties by removing any reference to ports 908x and
replacing them with port 80: 
    Attention: The URLs must be updated to point to the HTTP server's
host name and port number. The port number must be included even if
it's the standard port 80.
    

    • Gateway Settings
      In this section, change only the "Dispatch
URIs for gateway" attribute.
      

      • 

    • Other URI Settings
      • 

    

    4. 

  4. Save your changes.
    5. 

  5. Exit the Cognos Configuration
tool, making sure to select No at the following
prompt: The service 'IBM Cognos' is not running
on the local computer. Before you can use it your computer must start
the service. Do you want to start this service before exiting?
    6. 

  6. Restart the Cognos server:
    1. Stop the IBM WebSphere Application Server
that hosts the Cognos server.
      2. 

    2. Wait at least 1 full minute to ensure that all Cognos processes have stopped: 
      • AIX or Linux: cgsServer.sh and CAM_LPSvr processes
        • 

      • Windows: cgsLauncher.exe and CAM_LPSvr processes
        • 

      

      3. 

    3. Start WebSphere Application
Server.
      4. 

    4. Start the Cognos server.
      5. 

    

    7. 





Configuring HTTP manually for Cognos BI
Server


If your IBM Cognos Business Intelligence
server runs on IBM AIX or Linux and
does not provide a graphical user interface, you can configure HTTP
settings manually.


About this task
You can configure HTTP by adding a component to the Cognos BI Server’s cogstartup.xml file
and then customizing it for your deployment.


For more information,
see the Cognos information
center.




Procedure
  1. On the computer where you installed Cognos Business Intelligence, navigate to
the /configuration directory within the installation
location of the BI Server component (specified by the cognos.biserver.install.path property
in the cognos-setup.properties file); for example:  
    •  AIX or Linux: /opt/IBM/Cognos64/configuration
      • 

    • Microsoft Windows: C:\Program Files\IBM\Cognos\configuration
      • 

    

    2. 

  2. Make a backup copy of the cogstartup.xml file.
    3. 

  3. Open the working copy of the cogstartup.xml file
for editing.
    4. 

  4. In the file, locate the following parameters and update
their URI port references from 90xx to
port 80: 
    In this file, the URLs must
be updated to point to the HTTP server's host name and port number.
The port number must be included even if it's the standard port 80.
    

    <crn:parameter
name=
    

    • gateway
      • 

    • gatewayDispatcherURIList
      • 

    • sdk
      • 

    • contentManagers
      • 

    

    After your changes, those parameters should look like the
ones that follow:
    

     <crn:parameter name=" gateway ">
 	   <crn:value xsi:type="xsd:anyURI">http://cognos.example.com: 80 /ibmcognos/cgi-bin/cognos.cgi</crn:value>
 </crn:parameter>
	
	 <crn:parameter name=" gatewayDispatcherURIList " opaque="true">
   		<crn:value xsi:type="cfg:sortedArray">
      		<crn:item xsi:type="xsd:anyURI" order="0">http://cognos.example.com: 80 /cognos/servlet/dispatch/ext</crn:item>
  		 </crn:value>
 </crn:parameter>
	
	 <crn:parameter name=" sdk ">
     <crn:value xsi:type="xsd:anyURI">http://cognos.example.com: 80 /cognos/servlet/dispatch</crn:value>
 </crn:parameter>

<crn:parameter name=" contentManagers ">	
	    <crn:value xsi:type="cfg:array">
	        <crn:item xsi:type="xsd:anyURI">http://cognos.example.com: 80 /cognos/servlet</crn:item>
  	 </crn:value>
<crn:parameter>
    

    5. 

  5. Save and close the file.
    6. 

  6. Validate the modified file: 
    1. Set JAVA_HOME to the WAS_install_path/java directory.
      2. 

    2. Run the configuration script: 
      • AIX or Linux: ./cogconfig.sh -config
        • 

      • Windows: cogconfig.bat
-config
        • 

      

      3. 

    3. Check the Cognos_BI_Server_install_path/logs/cogconfig_response.csv file
for a success message.
      4. 

    

    7. 

  7. Restart the Cognos server:
    1. Stop the IBM WebSphere Application Server
that hosts the Cognos server.
      2. 

    2. Wait at least 1 full minute to ensure that all Cognos processes have stopped: 
      • AIX or Linux: cgsServer.sh and CAM_LPSvr processes
        • 

      • Windows: cgsLauncher.exe and CAM_LPSvr processes
        • 

      

      3. 

    3. Start WebSphere Application
Server.
      4. 

    4. Start the Cognos server.
      5. 

    

    8. 









Configuring Cognos Transformer
to use HTTP


Configure the Cognos Transformer
to use the IBM HTTP Server that
operates with the IBM Connections
deployment.


About this task
Use the Cognos Configuration
tool to specify settings that enable Cognos Transformer
to operate with IBM HTTP Server.


Note: The Cognos Configuration tool provides
a graphical user interface. If your IBM AIX or Linux server does not support a graphical user
interface, see the topic Configuring HTTP manually
for Cognos Transformer for
instructions on configuring these settings manually.




Procedure
  1. Navigate to the /bin directory of
the Cognos Transformer installation
directory. 
    For example:
    • AIX, Linux: /opt/IBM/Cognos/bin/
      • 

    • Windows:C:\Program
Files (x86)\IBM\Cognos\bin
      • 

    

    

    2. 

  2. Start the Cognos Configuration
tool by running the following command: 
    • AIX, Linux: ./cogconfig.sh
      • 

    • Windows:cogconfig.bat
      • 

    

    3. 

  3. Expand Local Configuration > Environment and edit the URLs
for the following properties by removing any reference to ports 908x and
replacing them with port 80: 
    Attention: The URLs must be updated to point to the HTTP server's
host name and port number. The port number must be included even if
it's the standard port 80.
    

    • Gateway Settings
      • 

    • Other URI Settings
      • 

    

    4. 

  4. Save your changes.
    5. 

  5. Exit the Cognos Configuration
tool. 
    You do not need to restart the Transformer component.
    

    6. 





Configuring HTTP manually for Cognos Transformer


If your IBM Cognos Business Intelligence
server runs on IBM AIX or Linux and
does not provide a graphical user interface, you can configure HTTP
settings manually.


About this task
You can configure HTTP by adding a component to the Cognos Transformer’s cogstartup.xml file
and then customizing it for your deployment.


For more information,
see the Cognos information
center.




Procedure
  1. On the computer where you installed Cognos Business Intelligence, navigate to
the /configuration directory within the installation
location of the Transformer component (specified by the cognos.transformer.install.path property
in the cognos-setup.properties file); for example: 
    • IBM AIX or Linux: /opt/IBM/Cognos/configuration
      • 

    • Microsoft Windows: C:\Program
Files (x86)\IBM\Cognos\configuration
      • 

    

    2. 

  2. Make a backup copy of the cogstartup.xml file.
    3. 

  3. Open the working copy of the cogstartup.xml file
for editing.
    4. 

  4. In the file, locate the following parameters and update
their URI port references from 90xx to
port 80: I
    In this file, the URLs must
be updated to point to the HTTP server's host name and port number.
The port number must be included even if it's the standard port 80.
    

    <crn:parameter
name=
    

    • gateway
      • 

    • gatewayDispatcherURIList
      • 

    

    After your changes, those parameters should look like the
ones that follow:
    

     <crn:parameter name=" gateway ">
 	   <crn:value xsi:type="xsd:anyURI">http://cognos.example.com: 80 /ibmcognos/cgi-bin/cognos.cgi</crn:value>
 </crn:parameter>
	
	 <crn:parameter name=" gatewayDispatcherURIList " opaque="true">
   		<crn:value xsi:type="cfg:sortedArray">
      		<crn:item xsi:type="xsd:anyURI" order="0">http://cognos.example.com: 80 /cognos/servlet/dispatch/ext</crn:item>
  		 </crn:value>
 </crn:parameter>
    

    5. 

  5. Save and close the file.
    6. 

  6. Validate the modified file: by running the following command: ./cogconfig.sh
-config
    1. Set the path as shown for your operating system:  
      • AIX: LIBPATH=Cognos_BI_Server_install_path/bin64
        • 

      • Linux: LD_LIBRARY_PATH=Cognos_BI_Server_install_path/bin64
        • 

      • Windows: PATH=Cognos_BI_Server_install_path/bin64;%PATH%
        • 

      

      2. 

    2. Set JAVA_HOME to the WAS_install_path/java directory.
      3. 

    3. Run the configuration script: 
      • AIX or Linux: ./cogconfig.sh -config
        • 

      • Windows: cogconfig.bat
-config
        • 

      

      4. 

    4. Check the Cognos_Transformer_install_path/logs/cogconfig_response.csv file
for a success message.
      5. 

    
 
    You do not need to restart the Transformer component.
    

    7. 















Optional post-installation
tasks


Complete the post-installation tasks that
are relevant
to your deployment.


Related tasks:







Adding a node to a cluster


Add a node to an existing cluster.


Before you begin
You must already have a cluster with at least one member. 
Ensure that you installed IBM WebSphere Application
Server Network Deployment (Application Server option) on the new node.


If you are adding a node to a Search cluster, do not use these
instructions. Instead, use the instructions in the Adding an
additional Search node to a cluster topic.


Although the IBM Cognos Business Intelligence server is managed by the same Deployment
Manager as IBM Connections,
you cannot add that node to the Connections cluster.




About this task
To add a node to a cluster, complete the following steps:




Procedure
  1. Add a node to the DM cell:
    1. Log on to the new node.
      2. 

    2. Open a command prompt and change to the bin directory
of the local WebSphere Application Server profile:  
      app_server_root/profiles/profile_name/bin
      

      where profile_name is the name of the applicable WebSphere Application Server
profile on this node.
      

      3. 

    3. Run the addNode command to add this node to the DM cell:
. 
      addnode [dmgr_host]
[dmgr_port] [-username uid]
[-password pwd] [-localusername localuid] [-localpassword localpwd]
      

      where 
      • dmgr_host is the host name of the Deployment
Manager
        • 

      • dmgr_port is the SOAP port of the deployment
manager (the default is 8879)
        • 

      • uid and pwd are the DM administrator user
name and password
        • 

      • localuid and localpwd are
the user name and password for the WebSphere Application Server administrator of the node
        • 

      

      

      4. 

    4. Open the addNode.log file and confirm
that the node was successfully added to the DM cell. The file is stored
in the following location:  
      app_server_root/profiles/profile_name/log/addNode.log
      

      5. 

    

    2. 

  2. Copy the relevant JDBC files from the DM node to this node,
placing them in the same location as the JDBC files on the DM. If,
for example, you copied the db2jcc.jar file from
the C:\IBM\SQLLIB directory on the DM, you must
copy the same file to the C:\IBM\SQLLIB directory
on this node. See the following table to determine which files to
copy. See the following table to determine which files to copy: 
    Table 32. JDBC files
    Database type
JDBC files

    
    

    DB2

    db2jcc.jar
    

    db2jcc_license_cu.jar sql
    
    		

    

    Oracle

    ojdbc6.jar
    
    		

    

    SQL Server

    sqljdbc4.jar
    
    		

    
    

    

    

    3. 

  3. Ensure that the shared folders that are used for the application
content stores in the cluster are accessible from the new node: from
the new node, try to access the shared directories.
    4. 

  4. Add additional members
to an existing IBM Connections
cluster:
    1. Log on to the Deployment Manager Integration Solutions
Console.
      2. 

    2. Click Servers > Clusters > cluster_name > Cluster members > New. Specify the following information about the new cluster
member: 
      Member name
      

      The name of the server instance that is created for the cluster.
The DM creates a server instance with this name.
      Note: Each member
name in the same cluster must be unique. The Integration Solutions
Console prevents you from reusing the same member name in a cluster.
      

      

      

      Select node
      

      The node where the server instance is located.
      

      

      Click Add Member to add this
member to the cluster member list.
      

      3. 

    3. Click Next to go to the summary
page where you can examine detailed information about this cluster
member. Click Finish to complete this step
or click Previous to modify the settings.
      4. 

    4. Click Save to save the configuration.
      5. 

    5. Click Server > Servers > Clusters > cluster_name > Cluster members. In the member list, click the new member that you
added in the previous step.
      6. 

    6. On the detailed configuration page, click Ports to expand the port information of the member. Make
a note of the WC_defaulthost and WC_defaulthost_secure port numbers.
For example, the WC_defaulthost port number is typically 9084, while
the WC_defaulthost_secure port number is typically 9447.
      7. 

    7. Click Environment > Virtual Hosts > default_host > Host Aliases > New. Enter the following information for the host alias
for the WC_defaulthost port: 
      Host name
      

      The IP address or DNS host name of the node where the new member
is located.
      

      

      Port: 
      

      The port number for WC_defaulthost. For example, 9084.
      

      

      Click OK to complete the
virtual host configuration.
      

      8. 

    8. Click Save to save the configuration.
      9. 

    9. Repeat the previous two substeps to add the host alias
for the WC_defaulthost_secure port.
      10. 

    10. Click System administration > Nodes.
      11. 

    11. In the node list page, select all the nodes where the
target cluster members are located and then click Synchronize. 
      12. 

    

    5. 



What to do next
Configure IBM HTTP
Server to connect to this node. For more information, see the Configuring IBM HTTP Server and Defining IBM HTTP
Server for a node topics.


Repeat this
task for each new node that you want to add to a cluster.


(AIX or Linux only) If you installed the Search application
on the new node, configure the path variables to point to that application.
For more information, see the Copying Search conversion tools
to local nodes topic. 


If you experience interoperability
failure, you might be running two servers on the same host with the
same name. This problem can cause the Search and News applications
to fail. For more information, go to the NameNotFoundException from JNDI lookup operation web page.








Configuring a reverse caching proxy


Configure a reverse proxy that directs all traffic to your IBM Connections deployment to a
single server.


Before you begin
This is an optional configuration. It is recommended for optimal
performance, especially if users are accessing IBM Connections from a wide area network (WAN).
Ensure that you have installed IBM WebSphere Edge Components
which is supplied with WebSphere Application Server Network Deployment. For more information, go
to the WebSphere Edge Components information center.


You must also have
completed the basic configuration of WebSphere Edge Components, set up a target
backend server, and created an administrator account.




About this task
The IBM WebSphere Application Server
Edge components provide a caching proxy that you can use to optimize
your deployment. Edge components are provided with the WebSphere Application Server Network Deployment
software.


A reverse proxy configuration intercepts browser requests,
forwards them to the appropriate content host, caches the returned
data, and delivers that data to the browser. The proxy delivers requests
for the same content directly from the cache, which is much quicker
than retrieving it again from the content host. Information can be
cached depending on when it will expire, how large the cache should
be, and when the information should be updated. 


This topic
describes how to configure the Edge components to optimize the performance
of IBM Connections.




Procedure
  1. Open the ibmproxy.conf configuration
file for the Edge components in a text editor. The file is stored
in the following directory: 
    • AIX or Linux: /etc/
      • 

    • Microsoft Windows: C:\Program Files\IBM\edge\cp\etc\
      • 

    

    2. 

  2. Make the following edits to the file: 
    1. In the SendRevProxyName Directive section, add or enable
the following rule: 
      SendRevProxyName    
 yes
      

      2. 

    2. In the PureProxy Directive section, add or enable the
following rule: 
      PureProxy       off
      

      3. 

    3. In the SSL Directives section, add or enable the following
rules: 
      SSLEnable       On
      

      SSLCaching       On
      

      4. 

    4. In the Keyring Directive section, add or enable the
following rules: 
      KeyRing       C:\ProxyKey\proxykey.kdb
      

      KeyRingStash     C:\ProxyKey\proxykey.sth
      

      5. 

    5. In the Mapping Rules section, add the following reverse
pass rules: 
      ReversePass http://httpserver/* http://proxyserver/*
      

      ReversePass https://httpserver/* https://proxyserver/*
      

      where httpserver is the host name of the HTTP server. The HTTP server is usually IBM HTTP Server, but could be a
load balancer or another proxy, depending on your deployment. proxyserver is the host name of the proxy server.
      Note: You can specify * in the URL (to indicate that all URLs for the server
can be passed) only if IBM Connections
is the only application installed on the server. Alternatively, you
can use a more specific URL such as http://httpserver/connections/*. You can use more than one ReversePass rule if you
need to specify different servers for each component. 
      

      

      6. 

    6. Also in the Mapping Rules section, add the following
proxy rules: 
      Proxy   /*    http://<httpserver>/*
:80
      

      Proxy   /*    https://<httpserver>/*
:443
      

      7. 

    7. Set the CacheTimeMargin rule to zero seconds. When a
document's expiry date is set to “soon” and soon is defined by the
CacheTimeMargin rule, setting this rule to zero disables the calculation
and forces all documents to be cached, regardless of their expiry
date. This setting is required for Blogs caching to function properly;
it does not negatively affect the other applications. 
      CacheTimeMargin	0 seconds
      

      8. 

    8. Prevent the validation of a cache object from sending
multiple requests for the same resource to the backend server by setting
the KeepExpired rule to on. An expired or stale
copy of the resource will be returned for the brief time that the
resource is being updated on the proxy. 
      KeepExpired	
On
      

      9. 

    9. In the Method Directives section, add the following
methods: 
      Enable     CONNECT 
      

      Enable     PUT 
      

      Enable
    DELETE
      

      10. 

    10. Add the following rule to the CacheQueries Directives
section: 
      CacheQueries PUBLIC
      

      11. 

    11. Configure the proxy to allow large file uploads by editing
and uncommenting the LimitRequestBody directive: 
      LimitRequestBody n M
      

      where n is the maximum file size in MB. For example: LimitRequestBody 50 M allows a file size of up to 50 MB.
      

      12. 

    

    3. 

  3. Save and close the ibmproxy.conf file. 
    4. 

  4. Update the dynamicHosts attribute in the LotusConnections-config.xml file to reflect the URL of the proxy server: 
    <dynamicHosts enabled="true">         
    

    <host href="http://proxy.example.com" 
    

    ssl_href="https://proxy.example.com"/>     
    

    </dynamicHosts>
    

    Notes: 
    • The dynamic hosts settings does not affect interservice URLs.
Therefore, even when the proxy server is enabled, IBM Connections still routes internal communication
between the applications through their own interservice URLs. You
can force this internal traffic to be routed over the proxy server
by updating the interservice URLs to use the proxy server.
      • 

    • Each href attribute in the LotusConnections-config.xml file is case-sensitive and
must specify a fully-qualified domain name.
      

      • 

    

    

    5. 

  5. Optional: Using iKeyman, extract certificates
from IBM Connections and add
them to the proxy server key database:
    1. Open the IBM Connections
kdb file and extract the certificates. 
      2. 

    2. Open the kdb file on the proxy server and add the certificates
that you extracted from IBM Connections. 
      3. 

    
 For more information about iKeyman, go to the Importing and exporting keys topic in the IBM HTTP Server information center.
    6. 

  6. Restart the Edge server.
    7. 







Enabling locked domains


Assuming that you have completed the server setup previously
described, to enable locked domains in IBM Connections,
specify an additional atrribute in the LotusConnections-config.xml
to ensure that only ConnectionsOpensocial application is mapped to
the locked domain host.


For added security, only the ConnectionsCommon.ear should
be mapped to the locked host.  Although no SSO tokens will be flowing
from the host, this extra precaution limits exposure of your Connections
infrastructure to potentially malicious gadgets. For more information
about locked domains refer to Understanding and configuring
locked domains on the IBM Social Business Toolkit wiki.
  1. Add the new attribute to the LotusConnections-config.xml file
by completing the following steps:
    1. Start the wsadmin tool. 
      2. 

    2. Use the following command to access the Connections configuration
file: 
      execfile("<$WAS_HOME>/profiles/<DMGR>/config/bin_lc_admin/ connectionsConfig.py")
      
If
you are prompted to specify which server to connect to, enter 1.
This information is not used by the wsadmin client when you are making
configuration changes. 
      3. 

    3. Check out the Connections configuration files using the following
command: 
      LCConfigService.checkOutConfig("/working_directory", "cell_name")
      
where:
      • working_directory is the temporary working
directory where the configuration XML and XSD files are copied to.
The files are kept in this working directory while you change them.
 
        • 

      • cell_name is the name of the WebSphere Application Server cell hosting
the Connections application. This argument is case sensitive. If you
do not know the cell name, you can determine it by entering the following
command in the wsadmin command processor:  print AdminControl.getCell(),
for example:
        LCConfigService.checkOutConfig("/temp","foo01Cell01")
        

        • 

      

      4. 

    4. From the temporary directory where you checked out the Connections
configuration files to, open the LotusConnections-config.xml file
in a text editor.
      5. 

    5. Add this attribute to the LotusConnections-config.xml file.
      <sloc:serviceReference bootstrapHost="{locked.host.name}" bootstrapPort="2809" clusterName="" enabled="true" serviceName="opensocialLocked" ssl_enabled="true">
        <sloc:href>
            <sloc:hrefPathPrefix>/connections/opensocial</sloc:hrefPathPrefix>
            <sloc:static href="http://{locked.host.name.authority/http}" ssl_href="https://{locked.host.name.authority/https}"/>
            <sloc:interService href="https://{locked.host.name.authority/https}"/>
        </sloc:href>
    </sloc:serviceReference>

      

      6. 

    6. Save the LotusConnections-config.xml file.
      7. 

    7. Check in the changed configuration property files using the following
command: LCConfigService.checkInConfig() 
      8. 

    8. After making updates, enter the following command to deploy the
changes: synchAllNodes()
      9. 

    

    2. 

  2. Restart your Connections server. 
    3. 





For example, this configuration could look like the following
sample:
<sloc:serviceReference bootstrapHost="hern120w.dyn.webahead.renovations.com" bootstrapPort="2809" clusterName="" enabled="true" serviceName="opensocialLocked" ssl_enabled="true">
        <sloc:href>
            <sloc:hrefPathPrefix>/connections/opensocial</sloc:hrefPathPrefix>
            <sloc:static href="http://hern120w.locked.com:9080" ssl_href="https://hernw120.locked.com:9443"/>
            <sloc:interService href="https://hern120w.dyn.webahead.renovations.com:9443"/>
        </sloc:href>
    </sloc:serviceReference>








Separating Common and Widget Container applications from the
News cluster


Run the ConfigEngine script to configure IBM® Connections
to separate critical user interface components to a new cluster. Doing
so provides high availability and failover capability for the Connections
Web user interface features. 


Before you begin
Install all of the applications you need, and make sure all
your applications works correctly after installing.


About this task
Understand these applications to better evaluate whether
or not you want to separate them out to a dedicated cluster in your
particular environment:      
  • The Common application is responsible for serving up static content,
including images, css, and javascript to all IBM Connections applications. Additionally as
an OSGi container, it is the component that enables Social Mail. 
    • 

  • The WidgetContainer application provides the ability to render
gadgets, proxies requests to remote services, and handles REST requests.
With the requirement to proxy requests, it has the potential to be
very resource intensive.
    • 

  • After installation, if the cluster fails, not all Web user interface
elements will render.
    • 


 To separate the Common and WidgetContainer application or both
from the cluster where the News repository is located (referred to
as the News cluster in this procedure), complete the following steps:


Procedure
  1. Add new nodes if needed as described in Installing IBM WebSphere Application Server. 
    2. 

  2. Stop all clusters in the IBM Connections
deployment.
    3. 

  3. On the deployment manager, open a command prompt, and then
change to the following directory on the WebSphere® Application Server
hosting the IBM Connections
server:
    • On AIX® or Linux: 
      connections_root/ConfigEngine
      

      • 

    • On Microsoft Windows: 
      connections_root\ConfigEngine
      

      • 

    

    4. 

  4. Enter the following command, if needed, to run the script
that removes the Common application from the News cluster. In addition,
the script removes the associated dynacache objects: 
    • On AIX or Linux:.
      ./ConfigEngine.sh remove-common-ear -DWasUserid=<was_admin_username> -DWasPassword=<was_admin_password> > /tmp/remove-common-ear.log 2>&1
      

      • 

    • On Microsoft Windows: 
      ConfigEngine.bat remove-common-ear -DWasUserid=<was_admin_username> -DWasPassword=<was_admin_password> > C:\remove-common-ear.log 2>&1
      

      • 

    
 For example, on the Microsoft Windows operating system, you
would enter the following command: 
    ConfigEngine.bat remove-common-ear -DWasUserid=wasadmin -DWasPassword=yourpassword > C:\remove-common-ear.log 2>&1
    

    5. 

  5. Check for a success message in the log file. 
    6. 

  6. Enter the following command, if needed, to run the script
that removes the WidgetContainer application from the News cluster.
In addition, the script removes the associated dynacache objects: 
    • AIX or Linux: 
      ./ConfigEngine.sh remove-widgetcontainer-ear -DWasUserid=<was_admin_username> -DWasPassword=<was_admin_password> > /tmp/remove-widgetcontainer-ear.log 2>&1 
      

      • 

    • Microsoft Windows: 
      ConfigEngine.bat remove-widgetcontainer-ear -DWasUserid=<was_admin_username> -DWasPassword=<was_admin_password> > C:\remove-widgetcontainer-ear.log 2>&1
      

      • 

    
 For example, on the Microsoft Windows operating system, you
would enter the following command: 
    ConfigEngine.bat remove-widgetcontainer-ear -DWasUserid=wasadmin -DWasPassword=yourpassword > C:\remove-widgetcontainer-ear.log 2>&1
    

    7. 

  7. Check for a success message in the log file. 
    8. 

  8. Change to the ./properties directory to open and edit the
wkplc_comp.properties file according to the following settings for
separating out Common or WidgetContainer or both: 
    Table 33. Property values for commonear
    Property Name
Description

    
    

    commonear.ClusterName
Desired cluster name for Common.

    

    commonear.FirstNodeName
Name of first node of the cluster.

    

    commonear.SecondaryNodesNames
Comma-delimited list of secondary node names.

    

    commonear.<FirstNodeName>.ServerName
Name of the server on the first node, note that
the <FirstNodeName> needs to be an actual name.

    

    commonear.<SecondaryNodesNames1>.ServerName
Name of the server on the secondary node 1,
note that the <SecondaryNodesNames1> needs to be an actual name.

    

    ...
...

    

    commonear.<SecondaryNodesNamesN>.ServerName
Name of the server on the secondary node n,
note that the <SecondaryNodesNamesN> needs to be an actual name.

    
    

    

    
 
    Table 34. Property values for the widgetcontainer
    Property
Description

    
    

    widgetcontainer.ClusterName 
Desired cluster name for the WidgetContainer.

    

    widgetcontainer.FirstNodeName 	
Name of first node of the cluster.

    

    widgetcontainer.SecondaryNodesNames
Comma-delimited list of secondary node names.

    

    widgetcontainer.<FirstNodeName>.ServerName
	
Name of the server on the first node, note that
the <FirstNodeName> needs to be an actual name.

    

    widgetcontainer.<SecondaryNodesNames1>.ServerName
Name of the server on the secondary node 1,
note that the <SecondaryNodesNames1> needs to be an actual name.

    

    ...
...

    

    widgetcontainer.<SecondaryNodesNamesN>.ServerName
Name of the server on the secondary node n,
note that the <SecondaryNodesNamesN> needs to be an actual name.

    
    

    

    

    Note: Ensure the server name(s) selected is/are not already
in use.
    

    9. 

  9. Enter the following command, if needed, to run the script
that creates a new cluster and deploys the Common application onto
it.  In addition, the script will create associated dynacache objects,
set the cluster as bus member of the ConnectionsBus, and update the
cluster name in the LotusConnections-config.xml for the Common application's
service entry: 
    • AIX or Linux:
      ./ConfigEngine.sh install-common-ear -DWasUserid=<was_admin_username> -DWasPassword=<was_admin_password> > /tmp/install-common-ear.log 2>&1
      

      • 

    • Microsoft Windows:
      ConfigEngine.bat install-common-ear -DWasUserid=<was_admin_username> -DWasPassword=<was_admin_password> > C:\install-common-ear.log 2>&1
      

      • 

    
  For example, on the Microsoft Windows operating system, you
would enter the following command: 
    ConfigEngine.bat install-common-ear -DWasUserid=wasadmin -DWasPassword=yourpassword > C:\install-common-ear.log 2>&1
    

    10. 

  10. Check for a success message in the log file. 
    11. 

  11. Enter the following command, if needed, to run the script
that creates a new cluster and deploys the WidgetContainer application
onto it. In addition, the script will create associated dynacache
objects, set the cluster as bus member of the ConnectionsBus, and
update the cluster name in the LotusConnections-config.xml for the
WidgetContainer application's service entry: 
    • AIX or Linux:
      ./ConfigEngine.sh install-widgetcontainer-ear -DWasUserid=<was_admin_username> -DWasPassword=<was_admin_password> > /tmp/install-widgetcontainer-ear.log 2>&1
      

      • 

    • Microsoft Windows:
      ConfigEngine.bat install-widgetcontainer-ear -DWasUserid=<was_admin_username> -DWasPassword=<was_admin_password> > C:\install-widgetcontainer-ear.log 2>&1
      

      • 

    
 For example, on the Microsoft Windows operating system, you
would enter the following command: 
    ConfigEngine.bat install-widgetcontainer-ear -DWasUserid=wasadmin -DWasPassword=yourpassword > C:\install-widgetcontainer-ear.log 2>&1
    

    12. 

  12. Check for a success message in the log file. 
    13. 

  13. Configure IHS to refresh the application mapping according
to the instructions contained in the topic Mapping applications
to IBM HTTP Server. 
    Note: For the users who have not yet deployed IHS, the ports
for the servers that host the Common (webresources ) and WidgetContainer
(opensocial) applications (as specified in the <profile_root>/config/cells/<cell_name>/LotusConnections-config/LotusConnections-config.xml file)
remain the old ports and need to be updated manually to the new ports.
 The new http port and secure http port can be found in <LC_HOME>/<new_server>.properties.
    
For
example, this entry in LotusConnections-config.xml is for Common:

    <sloc:serviceReference clusterName="CommonCluster" enabled="true" serviceName="webresources" ssl_enabled="true">
<sloc:href>
<sloc:hrefPathPrefix>/connections/resources</sloc:hrefPathPrefix>
<sloc:static href="http://yourserver.renovations.com:9081" ssl_href="https://yourserver.renovations.com:9444"/>
<sloc:interService href="https://yourserver.renovations.com:9444"/>
</sloc:href>
</sloc:serviceReference>
    

    14. 

  14. Restart Connections.
    15. 

  15. Restart IHS.
    16. 







Configuring
the custom ID attribute for users or groups


Configure IBM Connections
to use custom ID attributes to identify users and groups in the LDAP
directory.


Before you begin
  • If
you specified a single ID attribute for both users and groups,
you don't need to complete this task. This task is required only
if you specified a custom ID attribute for users or groups in the Specifying
a custom ID for users or groups topic. 
    • 

  • Ensure that
you have completed the steps to specify different
ID attributes for users and groups in the Specifying a custom
ID for users or groups topic. 
    • 





About this task
You can change
the default setting to use a custom ID to identify users and groups
in the directory. 

To
configure IBM Connections to
use the custom ID attribute that you
specified earlier, complete the following steps:


Procedure
  1. Add the new attribute to the LotusConnections-config.xml file.
To do so, complete the following steps:
    1. Start
the wsadmin tool.
      2. 

    2. Use the following command
to access the IBM Connections
configuration file: 
      execfile("<$WAS_HOME>/profiles/<DMGR>/config/bin_lc_admin/
 connectionsConfig.py")
      

      If you are prompted to specify
which server to connect to, enter 1. This information is not used
by the wsadmin client when you are making configuration changes.
      

      3. 

    3. Check out the IBM Connections
configuration files using the following command: LCConfigService.checkOutConfig("/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 change them. 
        • 

      • cell_name is the name of the IBM WebSphere Application
Server cell hosting the IBM Connections
application. This argument is case sensitive. If you do not know the
cell name, you can determine it by entering the following command
in the wsadmin command processor: 
        print AdminControl.getCell()
        

        • 

      

      
 
      For example:
      

      LCConfigService.checkOutConfig("/temp","foo01Cell01")
      

      4. 

    4. From the temporary directory to which you
checked out
the IBM Connections configuration
files, open the LotusConnections-config.xml file
in a text editor.
      5. 

    5. Add the new custom
properties to the LotusConnections-config.xml file.
For example: 
      <sloc:serviceReference serviceName="directory"
...
custom_user_id_attribute="customUserID"
custom_group_id_attribute="customGroupID"/> 
      

      6. 

    6. Save the LotusConnections-config.xml file.
      7. 

    7. Check in the changed configuration property
files using
the following command:LCConfigService.checkInConfig()
      8. 

    8. After making updates, enter the following
command to
deploy the changes: synchAllNodes()
      9. 

    

    2. 

  2. Stop and restart the WebSphere Application
Server instance hosting IBM Connections.
    3. 







Configuring Files and Wikis downloading


You can make downloading files from the Files and Wikis
applications much more efficient by configuring an IBM HTTP Server to handle most of the download
instead of the WebSphere Application
Server. It is strongly recommended that you configure production deployments
this way.


Before you begin
Install an IBM HTTP
Server in your WebSphere Application
Server environment. See the topic Configuring IBM HTTP Server for information.


In
network deployments, Files and Wikis data must be stored on a shared
file system, as described in the topic Deployment options.
All IBM HTTP Servers in the
deployment must have read access to the files, and all WebSphere Application Servers must have
write access.


If you choose not to configure
the IBM HTTP Server to download
files, you must configure the WebSphere Application
Server to transfer data synchronously instead of asynchronously in
order to avoid errors related to using too much memory. See the tech
note Excessive native memory use in IBM WebSphere Application
Server for instructions.




About this task
In the default deployment with an IBM HTTP Server, file download requests are passed
from the IBM HTTP Server to
the WebSphere Application
Server. The WebSphere Application
Server accesses the binary files in a data directory on the file system
and returns them to the IBM HTTP
Server, which passes them to the browser.


This is inefficient
in deployments where large numbers of users are downloading files,
partly because WebSphere Application
Server has a limited thread pool that is tuned for short-lived transactions,
and optimized for J2EE applications and not file downloads. In this
environment it is possible that you would need to create a cluster
to handle downloads, especially if you have slow transfer rates, for
example caused by people in different geographies downloading 2MB
at 2KB per second. This would cause problems, such as making it impractical
to properly tune the thread pool.


Configuring the IBM HTTP Server to download the binary files
instead makes downloading far more efficient, since IBM HTTP Server is designed specifically for
serving files. This leaves WebSphere Application
Server to perform tasks such as security checking and cache validation
while leaving downloading to the  IBM HTTP
Server.


To configure this environment, you install an add-on
module to the IBM HTTP Server.
As in typical deployments, download requests are passed from the IBM HTTP Server to the WebSphere Application Server. But instead
of responding with the binary data, the WebSphere Application Server only adds
a special header to its response. The add-on module recognizes the
header and directs the IBM HTTP
Server to download the binary data.


This configuration requires
making the Files and Wikis data directories available to the IBM HTTP Server using an alias.
This creates a security concern, so you must configure the access
control at the IBM HTTP Server
level. After you configure security, access to the Files and Wikis
data directories is denied unless a specific environment variable
is set. Requests to the Files and Wikis applications on WebSphere Application Server are then configured
to set the variable. In other words, only requests passing through WebSphere Application Server
are able to access the data directory, with WebSphere Application Server acting as
the authorizer.


If you use the add-on module you must use an IBM HTTP Server address for the IBM Connections "inter-service"
URL. See the topic Troubleshooting
inter-server communication for information on setting an inter-service
URL.


Do the following tasks to configure IBM HTTP Server downloading:




Procedure
  1. Install the IBM Connections
Files or Wikis applications.
    2. 

  2. On the server that you installed IBM Connections on, navigate to the connections_root/plugins/ihs/mod_ibm_local_redirect/platform directory
to find the module file (mod_ibm_local_redirect.so) appropriate to
your IBM HTTP Server operating
system. These are the platform directories: 
    • /aix_ppc32-ap20
      • 

    • /aix_ppc32-ap22
      • 

    • /linux390-ap20
      • 

    • /linux390-ap22
      • 

    • /linux_ia32-ap20
      • 

    • /linux_ia32-ap22
      • 

    • /win_ia32-ap20
      • 

    • /win_ia32-ap22
      • 

    

    For example, on Linux computers:
    

    /IBM/Connections/plugins/ihs/mod_ibm_local_redirect/linux_ia32-ap20/mod_ibm_local_redirect.so
    

    Note: 
    • You can use these whether you installed IBM HTTP Server from the 32-bit or 64-bit supplemental
package on all supported platforms, as the IBM HTTP Server process is 32-bits in both cases
and requires 32-bit modules. See this support document for more information on this
topic. For IBM HTTP Server 6.1.x
releases, use the ap20 versions; for version 7.x releases use the
ap22 version.
      • 

    

    

    3. 

  3. Copy the module to the appropriate directory location on
your IBM HTTP Server. By default,
modules are located in the ibm_http_server_root/modules
directory.
    4. 

  4. Open the IBM HTTP
Server httpd.conf file (in the ibm_http_server_root/conf
directory by default) and add the following statements to load the ibm_local_redirect_module,
and the required mod_env environment variable module:
    • LoadModule ibm_local_redirect_module path_to_module/mod_ibm_local_redirect.so
      
For
example: LoadModule ibm_local_redirect_module modules/mod_ibm_local_redirect.so
      • 

    • LoadModule env_module path_to_mod_env/mod_env.so
      
For
example: LoadModule env_module modules/mod_env.so
      • 

    
 
    Note: By default, the mod_env module is installed
in the /modules directory. It might already be
loaded, or it might be a commented-out line that you can remove comments
from to load.
    

    5. 

  5. Do one of the following, according to your IBM HTTP Server operating system:
    • Microsoft Windows: Give the IBM HTTP Server user READ access to the data
directory root. For optimal security, do not give the user WRITE access.
      • 

    • AIX and Linux: Give the IBM HTTP
Server user READ and EXECUTE access to the data directory root.
      • 

    
 
    Note: You can find the data_directory_root path
in the files-config.xml or wikis-config.xml file,
in the file.storage.rootDirectory attribute. This attribute will contain
either the path itself, or a WebSphere Application
Server variable whose value is the path. If it contains a variable,
you can find the path by opening the WebSphere Application Server console, clicking Environment > WebSphere Variables, and finding the variable. For example, if the element's
value is ${FILES_CONTENT_DIR}, find FILES_CONTENT_DIR in the console
to find the path. See the topic Changing configuration property
values for information on opening the files-config.xml or wikis-config.xml file.
    

    6. 

  6. On all virtual hosts in the same domain as Files or Wikis,
including both HTTP and HTTPS, do the following to expose the data
directory root:
    1. Open the httpd.conf file.
      2. 

    2. Add the following to create an alias for the data directory
root: 
      Alias /<alias> "data_directory_root"
      
For
example, if the Files data directory root is /opt/IBM/Connections/Data/Files
(on Linux), the following line creates the alias files_content for
that directory:
      Alias /files_content /opt/IBM/Connections/Data/Files
      

      3. 

    
 
    Note: 
    • Do not use the application context root (/files or /wikis by default)
as part of the alias, but you can use any other value. For example,
use /files_content, but not /files/content. The application context
root is the last part of the application URL, for example the application
context root of a Files application with the URL www.my.enterprise.com/files
is /files. You can see the value in the files.href.prefix property
in the LotusConnections-config.xml file. See the
topic Changing common configuration property values for
information on opening the configuration file.
      • 

    • Include quotes around the file path on Windows computers, and
always use forward slashes, for example: "C:/Program Files/IBM/Connections/Data/Files"
      • 

    • The example assumes the HTTP server is on the same computer as
IBM Connections. If the HTTP server is on a different computer (as
is common), specify the data directory using the network share path
appropriate to your environment. For example, use a UNC network share
format such as: Alias /files_content "//<server>/<sharename>/Files"
      • 

    

    

    7. 

  7. In the httpd.conf file, add these lines
after the lines you added in Step 6, to make the alias more secure: 
    <Directory "data_directory_root">
 Order Deny,Allow
 Deny from all
 Allow from env=REDIRECT_FILES or WIKIS_CONTENT
 </Directory>
    
For example:
    <Directory "/opt/IBM/Connections/Data/Files">
 Order Deny,Allow
 Deny from all
 Allow from env=REDIRECT_FILES_CONTENT
 </Directory>
    

    Note: 
    • This secures the data by only allowing requests where REDIRECT_FILES_CONTENT
or REDIRECT_WIKIS_CONTENT is specified. Use any environment variable
you want, as long as it is not already in the IBM HTTP Server environment.
      • 

    • The example assumes the HTTP server is on the same computer as
IBM Connections. If the HTTP server is on a different computer (as
is common), specify the data directory using the network share path
appropriate to your environment. For example, use a UNC network share
format such as: <Directory "//<server>/<sharename>/Files">
      • 

    

    

    8. 

  8. In the httpd.conf file, add these lines
after the lines you added in Step 7, to enable the module for Files
or Wikis: 
    <Location application_context_root>
 IBMLocalRedirect On
 IBMLocalRedirectKeepHeaders X-LConn-Auth,Cache-Control,Content-Type,Content-Disposition,
Last-Modified,ETag,Content-Language,Set-Cookie
 SetEnv FILES or WIKIS_CONTENT true
</Location>
    
For example:
    <Location /files>
 IBMLocalRedirect On
 IBMLocalRedirectKeepHeaders X-LConn-Auth,Cache-Control,Content-Type,Content-Disposition,
Last-Modified,ETag,Content-Language,Set-Cookie
 SetEnv FILES_CONTENT true
</Location>
    

    Note: 
    • The application_context_root value is the last
part of the application URL, for example the application context root
of a Files application with the URL www.my.enterprise.com/files is
/files. This is /files or /wikis by default, but can be changed during
post-installation steps. You can see the value in the files.href.prefix property
in the LotusConnections-config.xml file. See the
topic Changing common configuration property values for
information on opening the configuration file.
      • 

    • Specifying IBMLocalRedirectKeepHeaders instructs
the plugin to keep the specified headers from the application server,
instead of recomputing them. This is critical because the applications
set such directives as the content-type and content-disposition that
the IBM HTTP Server would not
know about.
      • 

    • If your environment requires additional headers (for example for
a proxy cache), you can add them to the comma-delimited IBMLocalRedirectKeepHeaders list
to ensure that the module retains them during redirection.
      • 

    • Header names must be comma-delimited with no space before or after
commas. Also, all header names must be on one line regardless of how
many there are.
      • 

    • The SetEnv value sets the token that the data directory requires
to be accessible. It must match the value after REDIRECT_ that
you set in Allow from env= in Step 7. For example,
if you set REDIRECT_FILES_CONTENT in Step 7,
this value must be SetEnv FILES_CONTENT true.
      • 

    • You can think of this as a lock and key mechanism: only requests
that go through the Files or Wikis applications get a key, and the
applications ensure that only authorized users can unlock particular
files.
      • 

    

    

    9. 

  9. Do the following to test that the IBM HTTP Server is configured properly and securely:
    1. Restart the IBM HTTP
Server. Make sure it loads properly and there are no log errors about
loading modules or configuration. If there are problems, make sure
the load module and configuration directives do not contain typos.
      2. 

    2. Try to access the alias directory directly at http/https:host/alias and
make sure you are denied permission. If you can access the directory,
make sure that the Order Deny, Allow; Deny from All; Allow
from env from Step 7 are all there.
      3. 

    3. Access the application and download a file to make sure
it functions. The module is not yet enabled.
      4. 

    

    10. 

  10. Check out the files-config.xml or wikis-config.xml file
using the steps in the topic Changing configuration property
values, and specify the following property attributes: 
    <download>
<modIBMLocalRedirect enabled="true" hrefPathPrefix="/alias" />
</download>
    

    Note: The alias must have a forward slash
in front of it.
    

    11. 

  11. Restart Files or Wikis.
    12. 

  12. Download a file to make sure it works.
    13. 

  13. Do the following to test whether the IBM HTTP Server is downloading the files:
    1. Open the httpd.conf file and add # characters to comment
out the last line in the <Directory> element, for example: 
      <Directory "data_directory_root">
 Order Deny,Allow
 Deny from all
 #Allow from env=REDIRECT_FILES or WIKIS_CONTENT
</Directory>
      
For example:
      <Directory "C:\Program Files\IBM\Connections\Data\Files">
 Order Deny,Allow
 Deny from all
 #Allow from env=REDIRECT_FILES_CONTENT
</Directory>
      

      2. 

    2. Save the file.
      3. 

    3. Try to download a file from Files or Wikis. You should
be denied. Test over both HTTP and HTTPS protocols (if HTTPS is enabled).
      4. 

    4. Open the httpd.conf file and remove
the # characters from the last line specified in Step a.
      5. 

    
 
    Check the standard IBM HTTP
Server error and request logs for any problems.
    

    14. 



What to do next
  • If you get a permission denied error trying to download a file, IBM HTTP Server might not have access
to the content. You can temporarily disable security on the directory,
and ensure you can access it directly first, then re-enable security.
Note that you can tell if WebSphere or IBM HTTP Server is encountering
an issue by the error page displayed, and by the path. If IBM HTTP Server is having a problem
with the module invoked, the path will include /<alias>.
    • 

  • If you get log errors about loading the module, make sure that
it is only loaded once, that you have selected the correct binary,
and that you are on a supported platform.
    • 

  • If it works for HTTP but not HTTPS (or vice versa), make sure
that the configuration lines are in a global context or in each virtual
host, depending on your setup.
    • 







Related reference:












Uninstalling IBM Connections


Uninstall IBM Connections.




Removing applications


Remove selected applications from IBM Connections.


About this task
If you no longer need to keep certain applications, you
can remove them from your deployment. You cannot remove core applications
such as Home page, News, and Search.


To remove selected applications
from IBM Connections, complete
the following steps:




Procedure
  1. Start
the IBM WebSphere Application Server Deployment
Manager. 
    2. 

  2. Stop
all instances of WebSphere Application Server, including node agents, in your deployment.
    3. 

  3. Open
a command prompt and change to the IM_root/eclipse directory.
    4. 

  4. Start
the installation wizard by opening the following file: 
    • AIX or Linux:
      ./launcher 
      

      • 

    • Windows:
      launcher.exe
      

      • 

    

    5. 

  5. Click Modify.
    6. 

  6. Select IBM Connections and click Next.
    7. 

  7. Clear the check boxes of the applications that you want
to remove. 
    8. 

  8. Click Next.
    9. 

  9. Enter the details of your WebSphere Application Server environment.
    10. 

  10. Click Next.
    11. 

  11. In the Summary page, verify that the details are correct.
    12. 

  12. Click Modify to begin removing applications.
    13. 

  13. When
the process is complete, restart the Deployment Manager.
    14. 

  14. Restart
all instances of WebSphere Application Server, including node agents.
    15. 

  15. Synchronize the
nodes.
    16. 

  16. To check the details of the procedure, open the log files in
the