Professional Documents
Culture Documents
GI11-7976-01
This edition applies to version 1, release 0, modification 1 of IBM Lotus Connections (product number 5724-S68)
and to all subsequent releases and modifications until otherwise indicated in new editions.
© Copyright International Business Machines Corporation 2007, 2007. All rights reserved.
US Government Users Restricted Rights – Use, duplication or disclosure restricted by GSA ADP Schedule Contract
with IBM Corp.
Contents
Chapter 1. IBM Lotus Connections Linking features . . . . . . . . . . . . 86
installation overview . . . . . . . . . 1
Product overview . . . . . . . . . . . . . 1 Chapter 6. Setting up a network
Audience . . . . . . . . . . . . . . . 1 deployment . . . . . . . . . . . . . 91
Planning a production installation . . . . . . . 2 Preinstallation tasks for a network deployment . . 91
Installation checklist . . . . . . . . . . . . 4 Setting up Java 2 security . . . . . . . . . 91
Creating a cluster . . . . . . . . . . . . 92
Chapter 2. Pilot installation overview . . 5 Installing the first node . . . . . . . . . 93
Creating a user information file . . . . . . . . 5 Installing a subsequent node . . . . . . . 96
Installing a pilot server . . . . . . . . . . . 7 Defining the IBM HTTP Server for a node . . . 97
Adding authentic users to the pilot . . . . . . 10
Administering the pilot . . . . . . . . . . 12 Chapter 7. Mapping the features to the
Removing a pilot installation . . . . . . . . 13 IBM HTTP Server . . . . . . . . . . 99
Mapping multiple profiles to a single IBM HTTP
Chapter 3. Hardware and software Server . . . . . . . . . . . . . . . . 102
requirements . . . . . . . . . . . . 15
Hardware requirements . . . . . . . . . . 15 Chapter 8. Installing updates . . . . . 109
Software requirements . . . . . . . . . . . 17 Using the Lotus Connections update installer. . . 109
updateLC command . . . . . . . . . . 110
Chapter 4. Preinstallation tasks . . . . 21 Lotus Connections version 1.0.1 . . . . . . . 114
Preparing the LDAP server to communicate with Bringing down Lotus Connections for
IBM WebSphere Application Server . . . . . . 21 maintenance work . . . . . . . . . . . 115
Installing IBM WebSphere Application Server . . . 21 Updating a stand-alone server . . . . . . . 115
Setting up profiles and server processes on Updating a network deployment . . . . . . 117
WebSphere Application Server . . . . . . . 22 Updating Profiles feature data . . . . . . . 122
Setting up federated repositories . . . . . . 25 Uninstalling updates . . . . . . . . . . 123
Configuring the IBM HTTP Server for SSL . . . 28 Installing an interim fix . . . . . . . . . . 124
Adding certificates to the IBM HTTP Server . . 28
Defining the IBM HTTP Server for a profile . . 29 Chapter 9. Uninstalling Lotus
Registering the DB2 product license key . . . . . 30 Connections . . . . . . . . . . . . 127
Creating the feature databases . . . . . . . . 31 Uninstalling a stand-alone deployment of Lotus
Creating IBM DB2 databases for the features . . 31 Connections . . . . . . . . . . . . . . 128
Creating Oracle database tables for the features 34 Uninstalling a Lotus Connections cluster . . . . 132
Creating the Profiles database . . . . . . . 36
Chapter 10. Performing a silent
Chapter 5. Setting up a stand-alone installation . . . . . . . . . . . . 135
deployment . . . . . . . . . . . . . 55 InstallResponse.txt file . . . . . . . . . . 135
Installing a Lotus Connections feature . . . . . 56
Installing Activities . . . . . . . . . . . 61
Chapter 11. Troubleshooting . . . . . 141
Installing Blogs . . . . . . . . . . . . 68
Lotus Connections log file . . . . . . . . . 142
Installing Communities . . . . . . . . . 74
Error messages . . . . . . . . . . . . . 143
Installing Dogear . . . . . . . . . . . 76
Installing Profiles . . . . . . . . . . . 81
Adding a new feature after an update . . . . . 85 Notices . . . . . . . . . . . . . . 197
Administering a stand-alone deployment . . . . 86 Trademarks . . . . . . . . . . . . . . 198
Before you install Lotus Connections make sure that you are familiar with the product features, review
the hardware and software requirements, and select an installation type: stand-alone or network. The
hardware and software resources you will need and administrative personnel that will have to be
involved in the process differ depending on the type of installation you choose to perform.
Product overview
IBM Lotus Connections is social networking software that consists of five features: Activities, Blogs,
Communities, Dogear, and Profiles.
Audience
This Installation Guide assumes that you have some prior experience with products that support
enterprise Web applications.
You can install all of the Lotus Connections features or choose fewer to implement. Before you begin the
installation, determine which features – Activites, Blogs, Communities, Dogear, or Profiles – that you
want to implement.
Deployment options
Lotus Connections is hosted by IBM WebSphere Application Server. When you install the product, you
must determine how you want to configure it on WebSphere Application Server. WebSphere Application
Server identifies an application as an application server process. You can group server processes so that
you can administer them as a unit; WebSphere Application Server refers to such a group of server
processes as a profile.
Note: The term profiles, when used in relation to WebSphere Application Server is a different concept
from the term Profiles, which is the name of one of the Lotus Connections features.
When planning the installation, you must decide whether you want to install:
v Each feature on its own profile on the default server process
v All five features on a single profile, but each feature on its own server process
Note: Installing all five features on a single profile and single server process is not supported.
Stand-alone deployment – An installation of one or more features on one or more systems that are
administered separately. This option requires a minimum of two dedicated systems to be hosted
successfully.
The easiest way to administer the product is to install the Websphere Application Server Network
Deployment Manager and use it to federate the multiple profiles into a single cell. Adding the profiles to
a cell enables you to administer them centrally. If you do not want to buy and install the WebSphere
Application Server Network Deployment Manager, you have the following options:
v A single profile with five server processes – In this configuration you must use the wsadmin tool to
create a new server process for each feature. The WebSphere Application Server Integrated Solutions
Console is available on the default server process for the profile (server1) only, which means that you
can administer only one feature using the WebSphere Application Server Integrated Solutions Console.
You must use the wsadmin tool to administer the other features. The advantages of this configuration
are:
– You do not have to edit the feature configuration files to link the features together after the
installation. If you do not set up a network deployment and you install the features to separate
profiles, you must edit the configuration file created for each feature profile to include information
about the other features.
See the Administering Lotus Connections section of the Lotus Connections information center for more
information about the wsadmin tool.
Network deployment – An installation on two or more sets of servers that are grouped to share the
product’s workload. A advantage of a network deployment of Lotus Connections is that it 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. Each instance of Lotus
Connections requires a set of two dedicated systems, and you must also configure an additional system
with the WebSphere Application Server Network Deployment Manager, which enables you to build,
manage, and tune the clustered servers.
Note: If you use this configuration, you must install all the features before you can add any of them to
the cluster. Lotus Connections does not support running the installer on a managed node. A managed
node is an application server that has been federated into a Deployment Manager cell. For example, if
you installed Activities and Profiles in two separate server processes in the same profile, and then
completed the steps in the topic, Installing the first node, to add them to a cell, you would not be able to
then install another feature, like Dogear, in a separate server process in the same profile.
v Mix and match – You can choose to set up a combination of these options. Determine the best
deployment scenario per feature based on the network and hardware resources available to you and
the amount of use you anticipate each feature to experience.
Related tasks
“Mapping multiple profiles to a single IBM HTTP Server” on page 102
You can map five profiles to one IBM HTTP Server by defining a Web server for each profile,
mapping each profile separately, and then merging the resulting configuration files.
Installation checklist
The installation checklist describes the steps and the order in which to perform them.
1. Decide whether to set up a stand-alone or network deployment of Lotus Connections.
2. Review the hardware requirements for the systems that will host Lotus Connections. See “Hardware
requirements” on page 15
3. Install the required software. In the following cases, more than one product is supported. You must
choose an option.
v Operating system
v Database server
v Directory server
See “Software requirements” on page 17.
4. Chapter 4, “Preinstallation tasks,” on page 21
5. Install Lotus Connections by completing one of the following steps:
v If you are setting up a stand-alone deployment, see Chapter 5, “Setting up a stand-alone
deployment,” on page 55.
v If you are setting up a network deployment, see Chapter 6, “Setting up a network deployment,” on
page 91.
A pilot installation supports the quick and easy deployment of Lotus Connections. A pilot installation
includes all the ancillary software required to run Lotus Connections, including WebSphere Application
Server and DB2 Express. A pilot installation is not capable of supporting production environment usage
or loads. It does not support clustering or failover, and it must be contained on a single server instance.
A pilot installation makes all five Lotus Connections features available for evaluation and use. Features
are installed on the same WebSphere Application Server server process. This basic environment provides
you with an opportunity to learn which of the Lotus Connections features might be most appropriate in
your enterprise, and also gives insight into how you might deploy each feature.
After you decide to move from a pilot installation to a production deployment, you can easily migrate
data created during the pilot installation phase (activities, bookmarks, blog postings, communities entries,
etc.) to the production environment.
A pilot installation is designed to minimize the administrator input and simplify configuration. Pilot
installation software performs the following tasks:
v Installs WebSphere Application Server 6.1.0.3 and all required fixpacks
v Installs DB2 V9.1 Express
v Installs one or more Lotus Connections features (Activities, Blogs, Communities, Dogear, Profiles)
v Creates pre-configured DB2 databases for each installed feature
v Creates a pre-populated Profiles database incorporating structured user data
The hardware requirements of a pilot installation are the same as those of a single-server production
installation. Please refer to production installation documentation for specifics. See Installing a pilot server
for disk space requirements.
A pilot installation allows you to install one, several or all five Lotus Connections features. However, if
you install some but not all features, and later decide you want to install additional features, you cannot
simply add them to an existing pilot installation. Instead, you must remove the existing pilot installation
and perform a new pilot installation that includes the additional features you want.
This means that you will lose all user data created in the initial installation. For this reason, it is
recommended that you install all five features at the outset, and deploy only the features you need
during the course of your product evaluation. Doing so gives you the option to easily activate and use an
additional feature at a later time.
Note: This procedure is optional. You can also use the sample data provided with the pilot installation to
test out the features. However, if you plan to migrate from the pilot installation to a production
installation, you must complete this procedure because the pilot users must have user IDs that will be
recognized by the LDAP directory you will use in the production installation.
Option Description
preferredLanguage Preferred or primary spoken language
displayName Screen name
initials Initials used in a name
labeledURI Uniform Resource Locator with an optional label. For
example: http://www.ibm.com/developerworks/lotus/
documentation/ Lotus Documentation
carLicense Automobile registration plate number
telephoneNumber Business phone number
facsimileTelephoneNumber Business FAX number
pager Business pager number
6. Save and close the text file. Make a note of its location.
uid=jdoe,pwd=passw0rd,cn=John Doe,sn=Doe,mail=john_doe@acme.com,preferredLanguage=German
uid=mdoe,pwd=f00bar,cn=Mary Doe,sn=Doe,mail=mary_doe@acme.com,roomNumber=967
uid=bdoe,pwd=barf00,cn=Bob Doe,sn=Doe,mail=Bob_doe@acme.com,businessCategory=marketing
uid=jgreen,pwd=pword1,cn=John Green,sn=Green,mail=john_green@acme.com,countryName=China
uid=jbrown,pwd=secretpword,cn=John Brown,sn=Brown,mail=john_brown@acme.com,manager=psmith
...
uid=jblack,pwd=apw0rd,cn=John Black,sn= Black,mail=john_black@acme.com,telephoneNumber=1234567890
Related tasks
“Installing a pilot server”
Installing a pilot server allows you to quickly and easily deploy Lotus Connection in a single server
environment. This type of installation is suitable for product evaluation purposes only and is not
intended for use in a production environment.
If you want to provide real user data to be used during the evaluation, create a user information file
before you begin the pilot installation. Providing real user data is recommended if you plan to migrate
from the pilot installation to a production installation. You can also create the user data file and add it to
the pilot user repository after the installation.
The pilot installation places any Lotus Connections features you choose to install onto a single machine.
It also installs the following supporting software packages:
v DB2 Express – Database repository; it is pre-populated with sample data.
v IBM WebSphere Application Server – Web application server.
Note: This user ID is used to access WebSphere Application Server only. Remember what you
specify here. You can subsequently use these credentials to log into the WebSphere Application
Server Integrated Solutions Console to configure and manage Lotus Connections features.
13. Type an ID to use as the administrative user ID for IBM DB2 Express Edition and a corresponding
password into the appropriate fields. Type the password again to confirm it, and then click Next.
Note: The installer creates a new user in the operating system user registry with these credentials.
This ID will have DB2 administrative privileges. Do not specify a user ID that already exists; this
must be a new and unique user ID. Remember what you specify here. You will subsequently use
this user ID to administer DB2 instances, create schema definitions, and set up access to the
databases for Lotus Connections features.
14. Select the check boxes next to the features you want to install from the following options:
v Activities
v Blogs
v Communities
v Dogear
v Profiles
Note: You cannot add a feature to an existing pilot installation. You can, however, install all the
features and only implement those you want to use now. Doing so ensures that all the features are
available should you subsequently decide to evaluate the full suite. Otherwise, you would have to
uninstall and reinstall the pilot to access any features that you did not install initially.
Click Next.
15. Accept the default host name for the WebSphere Application Server. Make a note of the default host
name; it forms the Web address that you will use to access the features later. Click Next.
16. Review the installation summary to ensure that the values you entered on previous screens are
correct. If you want to make a change, click Back to edit a value. Otherwise, click Next to begin the
installation.
17. After the installation is completed successfully, click Next.
18. On the user registration panel, you can either accept the default users.txt file to use sample user data
or click Browse to retrieve the user information file containing real user data that you created
previously. Click Next.
See Creating a user information file for details about how to provide real user data.
19. Click Finish to close the installation wizard and start the server that hosts the features.
20. To access and use a feature, open a Web browser and go to the following Web address:
v Activities:
http://<WebSphere_Application_Server_hostname>:9080/activities
v Blogs:
http://<WebSphere_Application_Server_hostname>:9080/blogs
v Communities:
http://<WebSphere_Application_Server_hostname>:9080/communities
v Dogear:
http://<WebSphere_Application_Server_hostname>:9080/dogear
v Profiles:
http://<WebSphere_Application_Server_hostname>:9080/profiles
The content stores for each feature are created in the following file locations:
v Activities:
– Content store:
C:\Program Files\IBM\LotusConnections\Data\Activities\AppSrv01\contentstore
– Statistics:
C:\Program Files\IBM\LotusConnections\Data\Activities\AppSrv01_server1\
statistics
v Blogs:
– Index file:
C:\Program Files\IBM\LotusConnections\Data\Blogs\AppSrv01_server1\
index
– Uploaded files:
C:\Program Files\IBM\LotusConnections\Data\Blogs\roller_data\uploads
v Communities index file:
C:\Program Files\IBM\LotusConnections\Data\Communities\AppSrv01_server1\index
v Dogear:
– Index file:
C:\Program Files\IBM\LotusConnections\Data\Dogear\AppSrv01_server1\index
– Favorite icons:
C:\Program Files\IBM\LotusConnections\Data\Dogear\favicons
v Profiles index file:
C:\Program Files\IBM\LotusConnections\Data\Profiles\AppSrv01_server1\index
Related tasks
“Creating a user information file” on page 5
The pilot installation supports the use of real user identifies and data. Before you can register real
users, you must create a user information file.
Perform this procedure if you have already installed the pilot version of Lotus Connections 1.0.1 and did
not use a user information file to register users during the initial installation.
You must create a user information file before you can complete this procedure.
To add authentic users to the pilot’s user repository after installing it, complete the following steps:
This program collects each database entry that contains PROF_SOURCE_UID and compares the
values of the PROF_GUID property in the Profiles database with the value returned by mapping
the production LDAP values. If the GUID values do not match, it writes the UID and globally
unique ID (GUID) values that are different to the collect_employees.in file.
– Run the following file to replace any incorrect globally unique identifiers in the Profiles database
with the correct values from the production LDAP directory:
Microsoft Windows:
update_employees_from_file.bat
v If the value of the PROF_SOURCE_UID property in the EMPLOYEE table is not the same as the
distinguished name specified in the production LDAP directory, but the corporate e-mail address is
unique and the same in both the Profiles database and production LDAP directory, complete the
following steps:
– Update the value of the PROF_SOURCE_UID property in the
map_dbrepos_from_source.properties file to be equal to the distinguished name (DN) value in
the production LDAP directory by setting it equal to $dn. Update the value of the PROF_GUID
property in the map_dbrepos_from_source.properties file to contain the globally unique identifier
defined in the production LDAP directory. See Mapping fields for information on the specific
values to use; this differs depending on the LDAP directory you are using.
– Run the following file:
Microsoft Windows:
collect_guid_and_source_uid_updates.bat
This program collects each database entry that contains an e-mail value and compares the value
of the PROF_GUID and PROF_SOURCE_UID properties in the Profiles database with the values
returned by the production LDAP directory. If one or both of the values are not the same, it
writes the UID and the values that are different to the collect_employees.in file.
– Run the following file to replace the globally unique identifiers in the Profiles database with
values from the production LDAP directory:
Microsoft Windows:
update_employees_from_file.bat
To administer a feature from the WebSphere Application Server Integrated Solutions Console, access it
from the following Web site:
http://<WebSphere_Application_Server_hostname>:9060/admin
where <WebSphere_Application_Server_hostname> is the name of the pilot server. Log in using the
administrative user ID and password that you specified during the pilot installation.
Refer to Administering Lotus Connections for additional information about administering Lotus Connections
features.
The Blogs and Dogear features support SSL operations. However, if you want to force login credentials
for these features to be submitted over a secure channel, you must install the IBM HTTP Server and Web
server plug-ins.
After you install the IBM HTTP Server and the Web server plug-ins, configure the IBM HTTP Server to
support encrypted traffic. See Configuring the IBM HTTP Server for SSL for more information.
Managing users
Whether you populate the user repository with names provided from a user information file or choose to
use the sample names provided with the product, you can view a list of the pilot users, edit their
passwords, and add new users from the WebSphere Application Server Integrated Solutions Console.
Changing passwords
As an administrator, you can change a pilot user’s password from the WebSphere Application Server
Integrated Solutions Console as described above. In addition, pilot users can change their own passwords
using a Web application. This functionality minimizes the administrative load and empowers users. To
change a password, the user of a feature can access the following Web address:
http://<WebSphere_Application_Server_hostname>:9080/password
Password changes take effect immediately and do not require a restart of the server.
Related tasks
Use the uninstall program to remove the artifacts of a pilot installation. This program removes Lotus
Connections, its related features, and the WebSphere Application Server. It also removes DB2 Express
Edition, but leaves the feature databases on the system. The databases must be explicitly removed by you
after you have either migrated to a production installation or determined that you no longer need the
data.
If you choose to migrate from a pilot installation to a production installation, perform the migration
before completing this procedure. See Migrating a pilot installation in the Administering Lotus Connections
section of the Lotus Connections information center for more information.
Note: Do not remove the WebSphere Application Server and DB2 or their supporting files before using
the uninstall program to remove the Lotus Connections features installed as part of the pilot. You may
have difficulty removing the pilot features from the system if these supporting software products are no
longer installed.
Note: If you are not removing all of the features, do not select the prerequisite software check box.
This software must be installed on the machine for any remaining features to continue to function
properly.
7. When prompted for the WebSphere Application Server administrative user ID and password,
provide them, and then click Next.
8. Review the summary screen. Click Back to return to previous pages and make changes, or click Next
to continue.
9. After the features are removed, click Next.
If you are removing all of the features, the prerequisite software is removed next.
You can access the message log from the specified directory to see if any warning messages were
generated during the removal process.
10. Click Finish.
Note: Be sure you have complete the migration before you perform these steps.
– Remove the files that enable users to change their passwords from the system by deleting the
changePassword.ear and changePassword.war files from the following directory:
C:\Program Files\IBM\LotusConnections\installableApps
– Remove the IBM DB2 Express Edition license file from the system by deleting the db2exp_o.lic
file from the following directory:
C:\Program Files\IBM\LotusConnections\DB2.License\
v If you are not migrating to a production installation, complete the following steps:
– Remove the Lotus Connections pilot installation directory from the system:
C:\Program Files\IBM\Lotus Connections
– Remove DB2 Express and each feature database created by the pilot installation from the
system. Follow these steps to do so:
a. Remove each feature database created by the pilot installation. See Uninstalling a stand-alone
deployment of Lotus Connections for information about manually removing feature databases.
b. Remove the Windows operating system administrative user ID for IBM DB2 Express Edition that
you created during the installation from the system.
c. Remove the C:\DB2 directory from the system.
12. You must restart the machine after running the uninstall program before the features you uninstalled
will be removed fully.
Related tasks
“Uninstalling a stand-alone deployment of Lotus Connections” on page 128
You can uninstall the entire Lotus Connections product, or individual Lotus Connections features, by
running the uninstaller program. Follow this procedure to remove a stand-alone deployment of Lotus
Connections from your system.
Hardware requirements
The following hardware is required for the systems that host IBM Lotus Connections services.
v At least two Intel® 64 or IA-32 based server machines
Note: See Planning and Software requirements to determine how many systems you need.
v Two CPUs per server, 2.6 GHz cpu speed or higher
v Minimum 4 GB of memory per machine
v 80 GB of available disk space after installation and configuration of the base operating system
v Make sure the servers are connected to an IP network that can be accessed by users.
The systems that host Lotus Connections must have the following amount of disk space:
v The temporary directory of the operating system on which you plan to run the installer must have at
least 150 MB of space.
v The Lotus Connections installer creates a directory in the following file path of WebSphere Application
Server:
– Linux®:
/opt/IBM/WebSphere/LotusConnections
– Windows:
C:\IBM\WebSphere\LotusConnections
This directory requires 110 MB of available space.
In addition, each Lotus Connections feature requires the following amounts of disk space for the initial
installation:
– Activities – 40 MB
– Blogs – 60 MB
– Communities – 40 MB
– Dogear – 60 MB
– Profiles – 40 MB
Note: The sizes of these directories, especially those that store indexes and objects, must grow as the
number of users grows and the longer the deployment is running. Take steps to optimize the full text
indexes that you use and to monitor the space availability, so you will know when an increase in capacity
is needed. See the Administration section of the Lotus Connections information center for more
information.
Related tasks
“Installing Activities” on page 61
Follow these steps to finish installing the Activities feature.
“Installing Blogs” on page 68
Follow these steps to finish installing the Blogs feature.
“Installing Communities” on page 74
Follow these steps to finish installing the Communities feature.
“Installing Dogear” on page 76
Perform the following steps to finish installing the Dogear feature.
“Installing Profiles” on page 81
Follow these steps to finish installing the Profiles feature.
Chapter 3, “Hardware and software requirements,” on page 15
Software requirements
The following software is required to run IBM Lotus Connections.
Table 2. Software Requirements
Item Details
Operating system (server-side) The following operating systems are supported:
v Red Hat Enterprise Linux ES release 4 (Nahant Update 4)
v Microsoft Windows 2003 Server - Standard Edition
v Microsoft Windows 2003 Server - Enterprise Edition
Operating system (client-side) The following operating systems are supported:
v Microsoft Windows XP Pro SP2
v SUSE Linux Enterprise Desktop 10 XGL
Web browser The following Web browsers are supported:
v Microsoft Internet Explorer 6.0 and later.
v Mozilla Firefox 2.0 (Windows and Linux)
The fix pack for 6.1.0.3 is available from the following Web
site:http://www-1.ibm.com/support/docview.wss?rs=180
&uid=swg24013772
Note: If you are planning to install the Communities and
Profiles features, edit the Java™ Virtual Machine settings to
increase the initial and maximum heap sizes. The size
required depends on the size of your directory and whether
or not you plan to enable the display of report-to
information. For information on editing the Java Virtual
Machine settings in WebSphere Application Server, go to the
following Web site: http://publib.boulder.ibm.com/
infocenter/wsphelp/index.jsp?topic=/
com.ibm.websphere.nd.doc/info/ae/ae/
urun_rconfproc_jvm.html
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/
topic/com.ibm.websphere.base.doc/info/aes/ae/
cins_webserver.html
Feed reader software Any feed reader that supports the Atom protocol
Caching and load balancing software IBM WebSphere Edge Components
Note: Not required.
For product information, go to the following Web site:
http://www-306.ibm.com/software/webservers/appserv/
was/network/edge.html
Virus detection software Any product supporting Internet Content Adaptation
Note: Not required. Protocol (ICAP) 1.0.
Service-specific software prerequisites
Profiles v IBM Tivoli Directory Integrator 6.1.0 with fix pack 1
(version 6.1.0.1, not version 6.1.1)
v To enable presence awareness in Profiles:IBM Lotus
Sametime® 7.5 or later.
For product documentation, go to the following Web
site:http://www-12.lotus.com/ldd/doc/sametime/7.5/
sthelpad.nsf
Related tasks
Chapter 3, “Hardware and software requirements,” on page 15
To prepare the LDAP server to communicate with WebSphere Application Server, complete the following
steps:
1. Install a supported LDAP server.
2. Populate the LDAP directory with user data.
After installing Websphere Application Server, verify that you can communicate with the LDAP server
machine from the WebSphere Application Server machine through the desired port (for example, 636)
without firewall interference.
You must prepare the WebSphere Application Server to host Lotus Connections before you begin the
Lotus Connections installation.
To prepare WebSphere Application Server to host your Lotus Connections deployment, complete the
following steps:
1. To create a profile on WebSphere Application Server, see Creating a WebSphere Application Server profile.
2. If you choose to install multiple features into a single profile, create a separate server process for each
feature. See Creating WebSphere Application Server processes.
A profile is a concept introduced with version 6.1 of WebSphere Application Server. It enables you to
group together server processes that you want to manage as a unit. For more information, see the
WebSphere Application Server information center: http://publib.boulder.ibm.com/infocenter/wasinfo/
v6r1/topic/com.ibm.websphere.base.doc/info/aes/ae/cpro_overview.html
You must write the script, and then run it to create the server processes.
### *** PLEASE READ THIS IMPORTANT NOTE REGARDING FOLLOWING CODE ***
### Create a server using the supplied server name and node
### createConnectionsServer.jacl
###
### Create the servers for Lotus Connections
### About:
### This script uses the given node and server arguments to create
### Lotus Connections servers on a Webphere Application Server.
###
### Usage:
### wsadmin.sh -username system \
### -password password \
### -f /createConnectionsServer.jacl server
###
### Parameters:
### arg1 - server to create
###
### Servers:
### Activities - ActivitiesServer
### Blogs - BlogServer
### Communities - CommunitiesServer
### Dogear - DogearServer
### Profiles - ProfilesServer
###
###
### Globals
###
global AdminConfig
global AdminControl
global AdminApp
###
### Is a server by this name already running on the node?
###
###
### Save the change
###
###
### Main
###
if { !($argc == 1) } {
puts "createConnectionsServer: This script requires a parameter: \r
the server to create"
puts "e.g.: createConnectionsServer.jacl ActivitiesServer"
puts " createConnectionsServer.jacl BlogsServer"
puts " createConnectionsServer.jacl CommunitiesServer"
puts " createConnectionsServer.jacl DogearServer"
puts " createConnectionsServer.jacl ProfilesServer"
} else {
set serverArg [lindex $argv 0]
createserver $serverArg
}
If you already have WebSphere Application Server configured to use a Standalone LDAP User Registry,
you must change the configuration to use federated repositories instead. To do so, you must set up a
sub-tree of the LDAP repository which combines all the existing LDAP parameters under a single
Federated Repository realm. Lotus Connections currently supports a single sub-tree of LDAP within the
Federated Repository realm only. WebSphere Application Server will let you add more than one LDAP
directory to the realm, but this is not supported by Lotus Connections. For more information, go to the
following external Web site to see the Websphere Application Server information center:
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/topic/com.ibm.websphere.base.doc/info/aes/
ae/cwim_fedrepos.html
To set up federated repositories in a WebSphere Application Server, complete the following steps:
1. After you install the WebSphere Application Server, make sure the server is started, and then log on
to the WebSphere Application Server Integrated Solutions Console by going to the following Web
address in a browser:
http://<Websphere_Application_Server_host_name>:9060/ibm/console
2. Click Log in to log in to the Welcome page. Security must be disabled on the WebSphere Application
Server.
3. Click Security → Secure Administration, applications and infrastructure.
4. Select Federated Repositories from the Available realm definitions field, and then click Configure.
5. On the Federated repositories page, do not change the default Realm name. Add an administrative
user ID (wasadmin, for example) to the Primary administrative user name field.
Note: This administrative user ID must be unique, and must not already exist in the LDAP
repository to be federated. When you save the user ID, you must provide a password.
6. Select Automatically generated server identity if it is not selected by default as the server user
identity.
7. Click Apply, and then click Save to save this setting.
8. Click Add Base entry to Realm, and then click Add Repository from the Repository reference page.
9. On the New page, provide values for the required fields.
v Repository identifier – Type a repository identifier, such as ″myFavoriteRepository.″
v Directory type – Specify one of the following options:
– IBM Tivoli Directory Server
– Microsoft Windows Server 2003 Active Directory
v Primary host name – Host name of the primary LDAP server. The host name is either an IP
address or a domain name service (DNS) name.
v Login properties – LDAP property to use for login authentication. Be sure to specify a set of
properties that has a unique value per user.
Note: The Bind distinguished name and Bind password are only required when your specific J2EE
application requires LDAP attributes that cannot be searched anonymously.
10. Click Apply, and then click Save to save this setting.
11. On the Repository reference page, type the distinguished name values in the following fields:
v Distinguished name of a base entry that uniquely identifies this set of entries in the realm
v Distinguished name of a base entry in this repository
The entries in these fields are the LDAP attribute type and attribute value pairs for the base element
in the realm and the LDAP repository separated by an equal sign, for example: o=acme. They may be
the same value when a single LDAP repository is configured for the realm or may be different in a
multiple LDAP repository configuration. The first field identifies entries in the realm and the second
field identifies entries in the LDAP repository.
12. Click Apply, click Save to save this setting, and then click OK to return the Federated Repositories
page.
13. Click Apply, and then click Save to save this setting.
14. Click the Repository Identifier link for the repository you just added in the repository table.
15. Click Apply, and then click Save to save this setting.
16. Click the LDAP entity types link, and then click the Group and PersonAccount entity types and
modify the default object classes mappings, and optionally, the search bases and search filters. Set up
LDAP parameters that are suitable for your LDAP server. Click Apply, and then click Save to save
this setting.
17. Click the Repository name in the navigation links at the top of the page to return to the Repository
page.
18. If your applications rely on group membership from LDAP, click the Group attribute definition
link, and then click the Member attributes link. Set up a proper group membership attribute type
and object class, and then click Apply, and then click Save to save this setting. For example, the
group membership attribute is required for using groups in Activities. For Activities, the member
attribute type is used by the groupOfNames object class, and the uniqueMember attribute type is
used by groupOfUniqueNames.
19. Select Secure Administration, applications and infrastructure → Web Security and then click
General settings. Select the Use available authentication data when an unprotected URI is
accessed check box.
20. Click Apply, and then click Save to save this setting.
21. Enable Administrative Security and Application Security. If you want to restrict your application
access to local resources, you can also select the Java 2 security check box.
22. Click Apply, and then click Save to save this setting.
23. Log out of the WebSphere Application Server Integrated Solutions Console, and then restart the
WebSphere Application Server.
Note: The administrative user name and password are now required because you set up security on
the server.
24. Log in to the WebSphere Application Server Integrated Solutions Console using your Primary
administrative user name and password after the server restarts. You have successfully configured
WebSphere Application Server with federated repositories.
Note: The attribute you use as the global unique ID must be an ID that is unique and will never change.
By default, Lotus Connections expects you to use the following LDAP attributes as the global unique ID
to identify users and groups from the directory:
v IBM Tivoli Directory Server:
ibm-entryUUID
v Microsoft Active Directory:
objectGUID
To get Lotus Connections to recognize a different global unique ID, you must edit the wimconfig.xml
configuration file on the WebSphere Application Server. There is currently no facility for editing this file
using the Integrated Solutions Console, so you must edit the file directly.
Note: Be careful when editing the wimconfig.xml file; use the correct XML syntax and do not change or
remove any other elements in this file.
To specify an attribute other than the defaults as the global unique ID, complete the following steps:
1. From the following directory, open the wimconfig.xml file in a text editor.
v Linux:
opt/IBM/WebSphere/AppServer/profiles/<profile_name>/config/cells/
<cell_name>/wim/config
v Windows:
C:\IBM\WebSphere\AppServer\profiles\<profile_name>\config\cells\
<cell_name>\wim\config
2. Find the <config:repositories> element, and then add the following line within the
<config:attributeConfiguration> element block:
<config:externalIdAttributes name="<custom_attribute>"
syntax="<attribute_syntax>"/>
where <custom_attribute> is the customer LDAP attribute you want to use and <attribute_syntax>
identifies the syntax. The syntax is optional; you should include the syntax attribute if the syntax is
something other than String.
For example, to configure Lotus Connections to use an existing attribute that is the global ID for your
enterprise and is a String value, such as enterpriseid, as the internal identifier, edit the file to include
the following element:
<config:externalIdAttributes name="enterpriseid"/>
If the attribute was not a String, you would identify its syntax as well. For example:
<config:externalIdAttributes name="enterpriseid" syntax="octetString"/>
3. Save and close the wimconfig.xml file.
The Blogs and Dogear features require that you install the IBM HTTP Server and Web server plug-ins if
you want to configure the features to force login credentials to be submitted over a secure channel. After
you install the IBM HTTP Server and Web server plug-ins, you must then configure the IBM HTTP
Server to support encrypted traffic by configuring it to support SSL.
See the following external Web site for detailed information about securing IBM Websphere Application
Server: http://www.redbooks.ibm.com/abstracts/sg246316.html
To configure the IBM HTTP Server for SSL, complete the following steps:
1. Use the IBM HTTP Server Key Management Utility to create a key file and a stash file.
2. Import the WebSphere Application Server key. If you are setting up a network deployment, import the
WebSphere Application Server key for the server hosting the node. This key is a self-signed certificate
that is automatically generated for the server.
Note: This is not the only option you have; you can use other types of keys to encrypt traffic. See the
IBM HTTP Server information center for information about other options:
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/topic/com.ibm.websphere.base.doc/info/
aes/ae/tsec_securecomm.html
3. Open the httpd.conf configuration file from the /opt/IBM/HTTPServer/conf directory, and then edit it
as follows:
RewriteEngine on
LoadModule ibm_ssl_module modules/mod_ibm_ssl.so
Listen 0.0.0.0:443
<VirtualHost *:443>
ServerName <server_name>
#DocumentRoot C:\IBM\HTTPServer\htdocs
SSLEnable
#SSLClientAuth required
</VirtualHost>
SSLDisable
Keyfile "<path_to_key_file>"
SSLStashFile "<path_to_stash_file>"
where <path_to_key_file> represents the file path to the KDB file and <path_to_stash_file> represents the
file path to associated stash file. For example, the paths may look like this:
Keyfile "C:\IBM\HTTPServer\Plugins\config\<web_server>\plugin-key.kdb"
SSLStashFile "C:\IBM\HTTPServer\Plugins\config\<web_server>\plugin-key.sth"
4. Save and close the file.
5. Restart the IBM HTTP Server to apply the changes.
After you configure the server for SSL, you can access the home page of the Lotus Connections features
over both HTTP and HTTPS.
Related concepts
“Administering the pilot” on page 12
Use the WebSphere Application Server Integrated Solutions Console to make configuration changes.
Configure the IBM HTTP Server to support SSL before you complete this procedure.
To import the public IBM WebSphere Application Server certificate into the IBM HTTP Server, complete
the following steps:
1. From the IBM WebSphere Application Server Integrated Solutions Console, select SSL certificate and
key management → Key Stores and certificates, and then select NodeDefaultKeyStore for a
stand-alone deployment or CellDefaultKeyStore for a network deployment.
2. Click Personal Certificates, select the default check box, and then click Extract.
3. Give the extracted file a name and save it in a place you will remember.
Note: The default password from WebSphere Application Server is WebAS (case sensitive).
10. Click Personal Certificates, and then select Signer Certificates.
11. Click Add.
12. Find the file you exported with the *.arm extension, select it, and then click OK.
13. Save and exit.
14. Restart the IBM HTTP Server to apply the changes.
Network deployment: Do not complete this procedure. Define one or more Web servers for the nodes in
the cluster after you create it by completing the steps described in Defining the IBM HTTP Server for a node
instead.
Note: 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:
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/topic/com.ibm.websphere.base.doc/info/aes/
ae/twsv_plugin.html
After you define the IBM HTTP Server in the WebSphere Application Server, you can map application
servers to it and stop and start the IBM HTTP Server using the WebSphere Application Server Integrated
Solutions Console.
Related tasks
Chapter 7, “Mapping the features to the IBM HTTP Server,” on page 99
After you install the features, map them to the IBM HTTP Server. This task updates the plugin-cfg.xml
file on the IBM HTTP Server, which is the configuration file that defines how the IBM HTTP Server
should access the features when they are requested from a Web browser.
Note: Install DB2 before beginning this procedure. Do not create feature databases until after you have
completed these steps.
See the DB2 information center for more information about the registering a product key:
http://publib.boulder.ibm.com/infocenter/db2luw/v9/topic/com.ibm.db2.udb.uprun.doc/doc/
t0006749.htm
To register the DB2 product license key, complete the following steps:
1. Log into DB2 using an ID with SYSADM authority.
2. Open a command prompt, and then execute the following command:
db2licm -a <path_to_lic_file>
where the <path_to_lic_file> is the directory in which the db2ese_o.lic file is stored.
v If you downloaded the product and extracted the files, the license file is stored in the following
directory:
– Linux:
Lotus_Connections_Install/DB2.License
– Microsoft Windows:
<Lotus_Connections_Installation_directory>\DB2.License
v On the DVD image, it is stored in the DB2.License directory.
This procedure describes how to use the script files, which are included with the product, to create DB2
databases for all of the features, except Profiles. To create the Profiles database, which includes first
installing the Tivoli Directory Integrator, see Creating the Profiles database.
This is an optional procedure; perform it only if you want to create a database user with a more limited
set of privileges. Also, only perform this procedure if you are using a DB2 database.
When you create the new user, name it lcuser. The scripts that are provided with Lotus Connections,
which grant the appropriate rights to the user, are written with the assumption that the user name is
lcuser.
To create a dedicated DB2 database user named lcuser, complete the following steps:
1. Do one of the following:
v Linux:
– Log into the DB2 server as the root user, and then type the following commands to create a new
user:
useradd lcuser
passwd lcuser
When prompted for the new password, type it, and then confirm it.
– Change to the home directory for lcuser, and then add the following lines to the appropriate
shell file. For bash, add the following lines to the .bashrc file:
# The following three lines have been added for UDB DB2.
if [ -f <path_to_home_directory_of_DB2_instance_user>/
sqllib/db2profile ]; then
. <path_to_home_directory_of_DB2_instance_user>/sqllib/
db2profile
fi
where <path_to_home_directory_of_DB2_instance_user> is the path to the home directory of lcuser.
For bourne or korn shell:
Note: These steps apply to Windows XP; the steps may vary slightly for other versions of
Windows.
– Select StartSettingsControl PanelUser Accounts, and then select the Advanced tab.
– Press the Advanced button, right-click Users, and then select New User.
– In the User name and Full name fields, type lcuser.
– Deselect the Must change password at first login check box, and then click Create.
– Click Close. Right-click lcuser, and then from the Local Users and Groups dialog, select
Properties from the menu.
– Click the Member Of pane, and then click the Add button. Type DB2USERS in the Enter object
name to select box, and then click OK.
–
Note: If the object name is not found, extended security for DB2 on Windows may not be enabled.
The default is for it to be enabled. Consider enabling it. See the DB2 documentation for information
about Extended Windows security using DB2ADMNS and DB2USERS groups. Alternatively, assign
lcuser the appropriate system rights by selecting Local Security Settings → User Rights
Assignment, and then selecting the following rights:
– Access this computer from the network
– Create global objects
To see the DB2 information center, go to the following external Web site: http://
publib.boulder.ibm.com/infocenter/db2luw/v8/index.jsp?topic=/com.ibm.db2.udb.cc.doc/
db2_udb/usergroupdialog2.htm
2. Grant the lcuser ID the required privileges to edit the Lotus Connections databases by logging into
DB2 using the lcuser ID, and then typing the following command:
db2 -tvf <path_to_file>/appGrants.sql
where <path_to_file> is the path to the directory in which the appGrants.sql file is stored per feature;
each feature has its own SQL file and you must run each separately. The SQL scripts are stored in the
following directory:
v Linux:
/Lotus_Connections_Install/connections.sql/
<feature_subdirectory>/db2
v Windows:
\Lotus_Connections_Install\connections.sql\
<feature_subdirectory>\db2
where <feature_subdirectory> is the script file storage directory of the feature for which you are
creating a dedicated user. Choose one of the following subdirectories:
v activities
v blogs
v communities
This procedure describes how to use the script files, which are included with the product, to create
Oracle database tables for all of the features, except Profiles. To create the Profiles database, which
includes first installing the Tivoli Directory Integrator, see Creating the Profiles database.
Note: If you have an existing database that you want to use, you can do so. When you run the
database creation scripts for the features, tables are added to that existing database.
3. If the Oracle database server and WebSphere Application Server are on different machines, copy the
database creation scripts to the Oracle machine. If the database server resides on the host machine or
the Oracle client is installed on the host machine, copy the database creation scripts to a directory on
the host machine. The database table creation scripts in the following subdirectory:
v Linux:
/Lotus_Connections_Install/connections.sql/
<feature_subdirectory>/oracle
v Windows:
\Lotus_Connections_Install\connections.sql\
<feature_subdirectory>\oracle
where <feature_subdirectory> is the script file storage directory of the feature for which you are
creating the database. Choose one of the following subdirectories:
v activities
v blogs
v communities
v dogear
You must run the database scripts for one feature at a time.
4. Create an Oracle 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 sys.
5. Run SQL Plus by typing the following command:
sqlplus /NOLOG
6. Type the following command to log in as an administrator with the sysdba role:
connect as sysdba
7. Enter the sysdba user ID and password.
8. Type the following command to create the feature database tables:
Note: The createDB script creates a dedicated User ID for each feature that has a narrower set of
privileges than an administrative user would. When you run the installation program, you are asked
to provide a user ID for the JDBC provider. You can specify one of these dedicated user IDs. The
options are as follows:
v Activities: ACTIVITIES
v Blogs: BLOGS
v Communities: SNCOMM
v Dogear: DOGEAR
10. Dogear only: Run the createHistogramStatsJob.sql script included with the Dogear scripts to create
a job that collects histogram statistics. This helps improve the performance of Dogear.
a. Run SQL Plus by typing the following command:
sqlplus /NOLOG
b. Type the following command to log in as an administrator with the sysdba role:
connect as sysdba
c. When asked to enter a user name, type the sysdba user ID, and then provide the associated
password.
d. Run the following command:
@<path_to_copied_sql_file>\createHistogramStatsJob.sql
e. Close the SQL Plus window.
Before completing this procedure, see if a listener has already been defined for Oracle as follows:
v Linux: From $ORACLE_HOME/bin, run the lsnrctl command, and then type status to see a list of
running services.
v Microsoft Windows: From the Start menu, select Control Panel → Administrative Tools → Services.
Look for a process named OracleOraDb_10g_home1TNSListener or one with a name that ends with the
TNSListener suffix. If there is a TNSListener process running, you do not need to complete this task. If
no TNSListener process is running, complete this task.
A listener is software that listens for requests to connect to the database, and then connects the requesting
applications to the appropriate database tables.
To create a database for the Profiles feature, you must install the IBM Tivoli Directory Integrator, and
then configure and populate the database.
Be sure you have installed all the required software, including a database server, before you begin this
procedure.
To install and configure Tivoli Directory Integrator, complete the following steps:
1. Install IBM Tivoli Directory Integrator 6.1.0 on the same system that you are using to host the
database for the Profiles feature.
When prompted for the Solution directory location, select Do not specify. Use the current working
directory at startup time.
Note: Move the contents of this directory to the system on which you installed theTivoli Directory
Integrator using a file transfer mechanism, such as FTP.
4. Install the tdisol file, by doing one of the following:
v Linux:
Extract the tdisol.tar file into the directory you just created, and then, in the TDI directory, execute
the following commands to ensure that the script files in it are all executable:
– chmod +x *.sh
– chmod +x netstore
v Windows:
Extract the supplied tdisol.zip file into the directory you just created.
This creates a Tivoli Directory Integrator solution directory called TDI in the subdirectory you
created.
5. Make the database libraries available to the Tivoli Directory Integrator by doing one of the following:
v If you are using DB2, copy the db2jcc_license_cu.jar file from the java subdirectory of the directory
to which you installed the database and paste it into the jvm/jre/lib/ext subdirectory of the
directory in which you installed Tivoli Directory Integrator.
For example, if you installed Tivoli Directory Integrator on a Linux system at /opt/IBM/TDI/V6.1,
the path would be /opt/IBM/TDI/V6.1/jvm/jre/lib/ext.
v If you are using Oracle, copy the ojdbc14.jar file from the jdbc/lib subdirectory of the directory to
which you installed the database and paste it into the lib subdirectory of the TDI source directory
that was created when you extracted the contents of the tdisol file.
6. Increase the runtime memory by adding -Xms256M and -Xmx1024M as arguments to the Java
invocation command in the following file stored in the Tivoli Directory Integrator installation
directory:
v Linux: ibmdisrv
After you add the memory arguments, the Java invocation should start like this:
"$JRE_PATH/java" -Xms256M -Xmx1024M
v Windows: ibmdisrv.bat
After you add the memory arguments, the Java invocation should start like this:
"D:\IBM\TDI\V6.1\jvm\jre\bin\java" -Xms256M -Xmx1024M
7. Linux only: Ensure that there is a localhost entry to the /etc/hosts file. For example:
127.0.0.1 localhost
8. From the TDI directory, open the tdienv file in a text editor to make sure that the path for the Tivoli
Directory Integrator installation directory is specified correctly in the TDIPATH variable. If the path is
not correct, edit the TDIPATH environment variable.
v Linux: tdienv.sh
The default value is:
export TDIPATH=/opt/IBM/TDI/V6.1
v Windows: tdienv.bat
The default value is:
Mapping fields
Populate the properties database repository with data from the enterprise LDAP directory by mapping
the content of the fields in one with fields in the other.
You can find the product documentation for the Tivoli Directory Integrator at the following Web address:
http://publib.boulder.ibm.com/infocenter/tivihelp/v2r1/topic/com.ibm.IBMDI.doc_6.1/welcome.htm
Consider using LDAP viewer software to help you map the fields.
The properties in the map_dbrepos_from_source.properties file have the default values defined in the
table below. Many of them are null. You must determine which LDAP fields to map to your database
fields and edit this file to specify values that apply to your configuration. Any values you omit or set to
null will not be populated in the database.
Table 3. Default values for properties in the map_dbrepos_from_source.properties file
Property Default value
PROF_ALTERNATE_LAST_NAME null
PROF_BLOG_URL null
PROF_BUILDING_IDENTIFIER null
PROF_CALENDAR_URL null
PROF_COURTESY_TITLE null
PROF_DEPARTMENT_NUMBER null
PROF_DESCRIPTION null
PROF_DISPLAY_NAME cn
PROF_EMPLOYEE_NUMBER employeenumber
PROF_EMPLOYEE_TYPE employeetype
PROF_EXPERIENCE null
PROF_FAX_TELEPHONE_NUMBER facsimiletelephonenumber
PROF_FREEBUSY_URL null
PROF_FLOOR null
PROF_GROUPWARE_EMAIL null
PROF_GUID See Note.
PROF_IP_TELEPHONE_NUMBER null
PROF_ISO_COUNTRY_CODE c
PROF_IS_MANAGER null
PROF_JOB_RESPONSIBILITIES null
PROF_MAIL mail
PROF_MANAGER_UID $manager_uid (This represents a lookup of the UID of
the manager using DN in manager field)
PROF_MOBILE mobile
PROF_NATIVE_FIRST_NAME null
PROF_NATIVE_LAST_NAME null
PROF_ORGANIZATION_IDENTIFIER ou
Note: The PROF_GUID identifies the global unique ID of a user. This is a complex values that never
changes. The mapping of the PROF_GUID property must be handled differently depending on the LDAP
server you are using:
v IBM Directory Server
PROF_GUID=ibm-entryUuid
v Active Directory
PROF_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 PROF_GUID, which is stored as a string
in the Profiles database.
Note: If you edited the wimconfig.xml file to use a custom global unique ID, be sure to specify that
custom ID here.
Note: The PROF_UID property, not to be confused with the PROF_GUID property, defines the unique ID
of a user. The PROF_UID is a critical field in the Profiles database. The value in it is used to link together
entries for a given person across multiple tables. The value you map to PROF_UID must meet the
following requirements:
v It must be present in every entry which is to be added to the database.
v It must be unique.
v It must be 36 characters or fewer in length.
In Microsoft Active Directory, although there often is a UID field available, this is not always the best
choice for mapping to PROF_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.
Note: PROF_IS_MANAGER property must have a Y or N value in the database. Y identifies the person
as a manager.
Edit the validate_dbrepos_fields.properties file to include validation information to be used during the
mapping process to validate field values before they are added to profiles repository fields.
You can find the product documentation for the Tivoli Directory Integrator at the following Web address:
http://publib.boulder.ibm.com/infocenter/tivihelp/v2r1/topic/com.ibm.IBMDI.doc_6.1/welcome.htm
See the topic Mapping fields for information about mapping fields from the enterprise LDAP directory to
the local Profiles database repository.
To create and populate the local database repository, complete the following steps:
1. DB2 only: Use a text editor to modify the file paths of table spaces in the file system which are
specified in the peopledb.db2 DDL file that is stored in the TDI directory.
For example, you could add a peopledb subdirectory under the db2inst1 user’s home directory to
store the PEOPLEDB information. The resulting content of the peopledb.db2 file might look as
follows:
CREATE LARGE TABLESPACE USERSPACE4K IN DATABASE PARTITION GROUP
IBMDEFAULTGROUP
PAGESIZE 4096 MANAGED BY DATABASE
USING (FILE ’/home/db2inst1/peopledb/peopletabspace4k’ 19200)
AUTORESIZE YES
INCREASESIZE 20 M
MAXSIZE NONE
EXTENTSIZE 32
Or you can specify a relative path to create the file in a data area in a subdirectory of the directory
to which the db2 instance is installed. For example, to specify a relative path, use the syntax: FILE
’peopletabspace4k’
2. Create the PEOPLEDB database and tables by doing one of the following:
v If you are using DB2, do the following:
– Linux:
a. Be sure that you are logged in as a DB2 instance user. db2inst1 is typically the default name
for the first instance user.
b. Change to the DB2 sqllib/bnd directory under the DB2 instance directory.
c. Type the following command into the command line processor:
db2 -tvf <path_to_tdi_directory>/peopledb.db2
where <path_to_tdi_directory> is the path to the TDI directory where the peopledb.db2 file is
located.
– Windows:
a. Change to the DB2 sqllib\bnd directory. For example, C:\Program Files\IBM\SQLLIB\bnd
Note: It is critical that you change to the directory specified in this step. If you do not, the
database bindings will fail, causing the Profiles application to have problems accessing the
database information.
b. Open the command line processor using the db2cmd command, and then type the following
command:
db2 -tvf <path_to_tdi_directory>\peopledb.db2
where <path_to_tdi_directory> is the path to the TDI directory where the peopledb.db2 file is
located.
v If you are using Oracle, from the TDI solution directory and using the same user ID you used to
install the Oracle database, run the following commands:
– Linux:
./createOracleDb.sh <password>
export ORACLE_SID=PEOPLEDB
./createOracleSchema.sh <password>
– Windows:
createOracleDb.bat <password>
set oracle_sid=PEOPLEDB
createOracleSchema.bat <password>
The SQL statements used for defining the tables, indexes, and triggers for Oracle are stored in the
peopledb.oracle.sql file.
3. DB2 only: Create the explain tables for DB2 by locating the EXPLAIN.DDL file which is provided
with DB2 and is typically stored in the misc subdirectory of the DB2 installation directory. Type the
following commands to run it:
db2 connect to PEOPLEDB
db2 -tvf <path_to_explain_ddl_file>
Note: Make sure that the values do not exceed the maximum length of their destination database
fields or errors will be logged and the entire record will be omitted from the database when it is
populated.
7. Optional: You must perform either this step or Step 10. If you are setting the PROF_IS_MANAGER
field using a 1:1 mapping, be sure you specified how to set the field in the
map_dbrepos_from_source.properties file.
Note: If your source LDAP system uses a value other than Y or N to indicate whether the person is
a manager, write a Javascript function to map the value into a Y or N, and then provide a reference
to that function here.
Note: If you are setting the PROF_IS_MANAGER field based on PROF_MANAGER_UID references
in other employees’ records, perform Step 10 instead of this step.
8. Required: Run the following script to create a file containing the distinguished names (DNs) to be
processed from the source LDAP directory.
v Linux: collect_dns.sh
v Windows: collect_dns.bat
The file created is named collect.dns by default. After the script runs, it creates a log file called
ibmdi.log in the /logs subdirectory of the TDI directory. Check this file to find out how many
entries were populated and whether there were any errors encountered during the process.
9. Required: Populate the database repository from the source LDAP directory by running the
following script:
v Linux: populate_from_dn_file.sh
v Windows: populate_from_dn_file.bat
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 left off. Check the
PopulateDBFromDNFile.log file in the logs subdirectory to find out which distinguished name was
last successfully processed. (The ibmdi.log file also keeps track of the tasks that you run.) Edit the
DNS file generated in the previous step, which is named collect.dns by default, to remove all entries
up to and including the last successfully processed entry. Start the task again. This can be repeated
as many times as necessary until all of the distinguished names are processed.
10. Optional: You must perform either this step or Step 7. If you are setting the PROF_IS_MANAGER
field based on PROF_MANAGER_UID references in other employees’ records, run the following
script:
v Linux: mark_managers.sh
v Windows: mark_managers.bat
The acceptable values for the PROF_IS_MANAGER field are Y or N. Y indicated that the person is a
manager. Manager identification is not done 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 may not
complete in a single pass for large organizations.
You must perform either this Step or Step 7.
11. Run the following script file to populate the Country table from the isocc.csv file:
v Linux: fill_country.sh
v Windows: fill_country.bat
12. Optional: Create any of the following tables that are relevant for your organization, and then
populate the local database repository with that information:
Department codes
If your organization uses department codes, create a table that contains one line per entry. In
each entry, include a department code, followed by a separator (such as a semicolon), and
This topic defines the Tivoli Directory Integrator properties associated with the LDAP directory. Most, but
not all of the properties in the profiles_tdi.properties file map to configuration parameters used in Tivoli
Directory Integrator.
or
oracle.jdbc.pool.
OracleConnectionPool
DataSource
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
value uses the syntax for a DB2
database. If you are using an Oracle
database, use the following syntax:
jdbc:oracle:thin:
@<host_name>:1521:
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.
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.
Be sure you have installed all the prerequisite software and that the system or systems you are installing
the features onto meet the system requirements. Also, be sure you have completed the preinstallation
tasks.
Note: Change the name of the response file to identify the feature you are installing or the response
file will get overwritten the next time you use it during an installation. For example, you could edit
the response file name using these options depending on the feature you are installing:
v Activities – InstallResponseA.txt
v Blogs – InstallResponseB.txt
v Communities – InstallResponseC.txt
v Dogear – InstallResponseD.txt
v Profiles – InstallResponseP.txt
7. Select one feature to install from the following options:
v Activities
v Blogs
Note: If the location of the server you want to use is not displayed, click the Cancel button to cancel
out of the installation, and then complete the following steps:
a. Open a command prompt on the system on which you installed WebSphere Application Server.
b. Change to the directory which contains the Lotus Connections install executable file or shell
script, and then type the following command:
v Linux:
./install.sh -W installedWasLocation.undetectedWas=
/<file_path_to_AppServer_directory>
v Windows:
install -W installedWasLocation.undetectedWas=
<file_path_to_AppServer_directory>
where <file_path_to_AppServer_directory> is the file path to the AppServer directory of the
WebSphere Application Server you want to use. For example:
v Linux:
/opt/IBM/WebSphere/AppServer
v Windows:
C:\Progra~\IBM\WebSphere\AppServer
Note: Use Progra~ to represent the Program Files directory name; the install command does
not recognize file path parameters that contain spaces.
Note: If you are installing multiple features onto a single system, you can either install all the
features within a single profile, or create a separate profile for each feature. See Chapter 4,
“Preinstallation tasks,” on page 21 for information about how to create profiles.
10. Optional: A screen asking you to specify a server process is displayed only if your profile has
more than one server process associated with it. Select the application server you want to use to
host the feature, and then click Next.
Note: If you are installing multiple features onto a single machine and within a single profile, you
must install each feature to a separate server process. See Chapter 4, “Preinstallation tasks,” on page
21 for information about how to create server processes.
11. Type the WebSphere Application Server Administrative user ID and password, and then click Next.
12. Confirm the server hostname. For example: appserver.enterprise.acme.com. Click Next.
13. Select the database product you used to create the feature databases:
v DB2 Universal Database™
v Oracle Enterprise Edition
Click Next.
14. Provide Java Database Connectivity (JDBC) connector information for the database.
Table 9. Java Database Connectivity (JDBC) connector information
Field Name Description
Host name Host name of the database server.
Port The port number for the database connection. By default,
the port number for a DB2 database is 50000 and the
port number for an Oracle database is 1521.
Database name Specify the name of the database for the feature you are
installing from the following list of options:
v DB2:
– Activities: OPNACT
– Blogs: BLOGS
– Communities: SNCOMM
– Dogear: DOGEAR
– Profiles: PEOPLEDB
v Oracle:
– For Profiles, type PEOPLEDB.
– For all other features:
- If you are using an existing Oracle database and
adding the feature tables to it, type the name of
that database.
- If you ran the script provided with Lotus
Connections to create a new database, type
LSCONN.
Click Next. You have now completed the Lotus Connections common installation procedures.
15. Refer to the related section in this Installation Guide for the steps to complete the installation of one
of the following Lotus Connections features:
v Activities
v Blogs
v Communities
v Dogear
v Profiles
Related reference
Chapter 3, “Hardware and software requirements,” on page 15
Note: Do not deselect the Enable HTTP server check box. Doing so could cause the features to be
inaccessible from the navigation bar.
7. Review the Summary screen to make sure the values you entered on previous screens are correct. If
you want to make a change, click Back to edit a value. If the values are correct, on the installation
summary screen, click Install to begin the installation.
8. Click Finish.
9. Optional: If you indicated that you would like to use a Domino database as the content store, you
must create the database before starting Activities. See Creating a Domino database content store.
10. Start the WebSphere Application Server instance to which you installed the feature, such as server1,
by typing the following commands:
Note: If you are migrating data from a pilot to production installation, skip this step and the next
step. You will not start the servers until after the migration is complete.
v Linux:
cd opt/IBM/WebSphere/AppServer/profiles/<profile_name>/bin
startServer.sh <server_instance>
v Windows:
cd C:\IBM\WebSphere\AppServer\profiles\<profile_name>\bin
startServer.bat <server_instance>
Note: If the server fails to start, start it again by repeating the above commands. If it continues to
fail, look at the error log to see if there is a problem with your set up. The error log file is stored in
the following directory:
v Linux:
opt/IBM/WebSphere/AppServer/profiles/<profile_name>/logs/
<server_instance>/SystemOut.log
v Windows:
C:\IBM\WebSphere\AppServer\profiles\<profile_name>\logs\
<server_instance>\SystemOut.log
11. Open a Web browser and access the feature directly from the WebSphere Application Server by
going to the Web address you specified for the Activities feature.
For example:
http://appserver.enterprise.acme.com:<port_number>/activities
Much of the information you specify during the installation is stored in XML-based configuration files
associated with the product. For information about making changes to those values, see the
Administering Lotus Connections section of the Lotus Connections information center. For example, if
you change HTTP servers, you can use a wsadmin command to change the service location settings
defined in the configuration files for the feature.
Related tasks
Chapter 7, “Mapping the features to the IBM HTTP Server,” on page 99
After you install the features, map them to the IBM HTTP Server. This task updates the plugin-cfg.xml
file on the IBM HTTP Server, which is the configuration file that defines how the IBM HTTP Server
should access the features when they are requested from a Web browser.
Related reference
“Hardware requirements” on page 15
The following hardware is required for the systems that host IBM Lotus Connections services.
To use a Domino database as the content store, you must create a database and specify the ID that can
access the database on behalf of Activities. When you indicate that you want to use a Domino database
as the content store for Activities during the installation process, the Activities server uses HTTP to
communicate with the Domino server.
Note: To enable Domino to process HTTP requests from the Activities server, the HTTP task must be
running on the Domino server that is hosting the content store database.
2. During the installation of Activities, indicate that you want to use a Domino database as the content
store and provide the names of the server and database you decided on in the previous step.
3. After installing Activities and before starting Activities for the first time, you must create the content
store database. Copy the ActivitiesObjectStore.ntf template file to the designated Domino server
running the HTTP task that will host the content store. The content store template is located in the
following directory:
v Linux:
opt/IBM/WebSphere/LotusConnections/activities/activities/activities/templates
v Windows:
C:\IBM\WebSphere\LotusConnections\activities\activities\activities\templates
4. Create a new Notes® database on the server using the content store template.
5. In the access control list for the database, add the name of the user identity that will authenticate with
the Domino server on behalf of the Activities server. Add this user as a Person Editor who has Delete
documents privileges for the database. These access privileges allow the user to save, retrieve, and
delete documents in the activities database on behalf of Activities members.
6. For security purposes, create a dedicated user ID to access the Activities database. Also, consider
enforcing HTTP authentication and preventing anonymous access to the server by configuring settings
in the server’s Web Site document.
You can configure Activities to encrypt all network traffic between the browser and the server.
Configuring Activities for encrypted traffic is optional and is only recommended if you are working with
sensitive data.
Activities does not automatically redirect API calls to transmit the data over a secure channel. You can
force the data to be secured by editing the httpd.conf file to define rewrite rules for the IBM HTTP Server.
Be sure you have mapped the feature to the IBM HTTP Server before you perform this task.
Note: This procedure assumes that you have completed the steps to configure the Secure Socket Layer
protocol on the IBM HTTP Server described in the topic, Configuring the IBM HTTP Server for SSL.
To secure the Activities public API methods, complete the following steps:
1. With a text editor, open the httpd.conf file from the /opt/IBM/HTTPServer/conf directory, and then
edit it as follows:
a. Uncomment the following lines if they are commented out:
LoadModule rewrite_module modules/mod_rewrite.so
LoadModule headers_module modules/mod_headers.so
b. Locate the following comment:
# Redirect allows you to tell clients about documents which used to exist in
# your server’s namespace, but do not anymore. This allows you to tell the
# clients where to look for the relocated document.
where <server.name> is the hostname of the server that hosts the Activities feature.
c. Look for the SSL virtual host reference. Below SSLEnable and inside the <VirtualHost> block, add
the following:
RewriteEngine on
#RewriteLog "logs/rewrite.log"
#RewriteLogLevel 9
where <server.name> is the hostname of the server that hosts the Activities feature.
d. Make sure the non-SSL ServerName property is set to your server name and port.
For example:
ServerName <server.name>.com:80
Save and close the file.
2. Restart the IBM HTTP Server.
3. From the WebSphere Application Server Integrated Solutions Console, select Environment → Virtual
Hosts → default_host → Host Aliases, click New, and then add the following values to the fields:
v Hostname – *
v Port – 443
v
Click OK, Save, and then Restart.
The following excerpt is from a httpd.conf file that forces authentication attempts and API calls in Blogs
and Dogear and forces API calls in Activities to be sent over a secure channel:
#LoadModule mime_magic_module modules/mod_mime_magic.so
LoadModule proxy_module modules/mod_proxy.so
LoadModule proxy_connect_module modules/mod_proxy_connect.so
LoadModule proxy_http_module modules/mod_proxy_http.so
#LoadModule proxy_ftp_module modules/mod_proxy_ftp.so
LoadModule rewrite_module modules/mod_rewrite.so
LoadModule setenvif_module modules/mod_setenvif.so
#LoadModule speling_module modules/mod_speling.so
...
<IfModule !mod_afpa_cache.c>
Listen 0.0.0.0:80
<VirtualHost *:443>
</IfModule>
SSLDisable
KeyFile "c:/IBM/HTTPServer/bin/key.kdb"
SSLStashFile "c:/IBM/HTTPServer/bin/key.sth
...
# Redirect allows you to tell clients about documents which used to exist in
# your server’s namespace, but do not anymore. This allows you to tell the
# clients where to look for the relocated document.
RewriteEngine On
#RewriteLog "logs/rewrite.log"
#RewriteLogLevel 9
# when doing form based authentication, ensure user/pwd is sent over https
RewriteCond %{SERVER_PORT} !^443$
RewriteRule ^/dogear/auth(.*) https://example.acme.com/dogear/auth$1
[noescape,L,R]
# when doing form based authentication, ensure user/pwd is sent over https
RewriteCond %{SERVER_PORT} !^443$
RewriteRule ^/blogs/roller-ui/login.do https://example.acme.com/blogs/
roller-ui/login.do [noescape,L,R]
Note: Do not deselect the Enable HTTP server check box. Doing so could cause the features to be
inaccessible from the navigation bar.
4. Review the Summary screen to make sure the values you entered on previous screens are correct. If
you want to make a change, click Back to edit a value. If the values are correct, on the installation
summary screen, click Install to begin the installation.
5. Click Finish.
6. Start the WebSphere Application Server instance in which you installed the feature by typing the
following commands:
Note: If you are migrating data from a pilot to production installation, skip this step and the next
step. You will not start the servers until after the migration is complete.
v Linux:
cd opt/IBM/WebSphere/AppServer/profiles/<profile_name>/bin
startServer.sh <server_instance>
v Windows:
cd C:\IBM\WebSphere\AppServer\profiles\<profile_name>\bin
startServer.bat <server_instance>
Note: If the server fails to start, start it again by repeating the above commands. If it continues to fail,
look at the error log to see if there is a problem with your set up. The error log file is stored in the
following directory:
v Linux:
opt/IBM/WebSphere/AppServer/profiles/<profile_name>/logs/
<server_instance>/SystemOut.log
v Windows:
C:\IBM\WebSphere\AppServer\profiles\<profile_name>\logs\
<server_instance>\SystemOut.log
where the <port_number> is the port number on the WebSphere Application Server that the feature is
available from. This is usually:
v 9080 – Standard port number for the default server process, server1. This is probably the server
process that you installed the feature on if you are installing each feature to its own profile.
v 9081-9085 – These are the port numbers that are usually assigned to features that are installed into
a single profile. The first server process you create is assigned the port 9081, the next 9082, and
each subsequent feature is assigned a port number incremented by one.
The serverindex.xml file stored in the node directory contains port assignment information.
If you see the Welcome to Blogs page, the installation was successful. If you do not, go to the
Troubleshooting section.
Do not log into Blogs yet. You must map Blogs to the IBM HTTP Server, and then edit the
configuration file for the IBM HTTP Server to protect your user name and password during login. See
Mapping the features to the IBM HTTP Server
8. Optional: If you plan to install additional features on the same system and want to be able to refer to
the log file generated by the installer, copy the lcinstalllog.txt file from the following directory:
v Linux:
/tmp/lcinstalllog.txt
v Windows:
c:\Documents and Settings\<user_name>\Local Settings\temp\lcinstalllog.txt
into this directory:
v Linux:
/opt/IBM/WebSphere/LotusConnections/Blogs/lcinstalllog.txt
v Windows:
c:\Program Files\IBM\WebSphere\AppServer\LotusConnections\Blogs\
lcinstalllog.txt
The lcinstalllog.txt log file stored in the temporary directory is overwritten by subsequent feature
installations.
Related tasks
Chapter 7, “Mapping the features to the IBM HTTP Server,” on page 99
After you install the features, map them to the IBM HTTP Server. This task updates the plugin-cfg.xml
file on the IBM HTTP Server, which is the configuration file that defines how the IBM HTTP Server
should access the features when they are requested from a Web browser.
Related reference
“Hardware requirements” on page 15
The following hardware is required for the systems that host IBM Lotus Connections services.
Be sure you have mapped the feature to the IBM HTTP Server before you perform this task.
Note: This step assumes that you have completed the step to configure SSL on the IBM HTTP Server
described in the topic, Configuring the IBM HTTP Server for SSL.
RewriteEngine on
where <host_name> is the name of the server you have set up.
2. Save and close the file.
3. Restart the IBM HTTP Server.
The following excerpt is from a httpd.conf file that forces authentication attempts and API calls in Blogs
and Dogear and forces API calls in Activities to be sent over a secure channel:
#LoadModule mime_magic_module modules/mod_mime_magic.so
LoadModule proxy_module modules/mod_proxy.so
LoadModule proxy_connect_module modules/mod_proxy_connect.so
LoadModule proxy_http_module modules/mod_proxy_http.so
#LoadModule proxy_ftp_module modules/mod_proxy_ftp.so
LoadModule rewrite_module modules/mod_rewrite.so
LoadModule setenvif_module modules/mod_setenvif.so
#LoadModule speling_module modules/mod_speling.so
...
<IfModule !mod_afpa_cache.c>
Listen 0.0.0.0:80
</IfModule>
SSLDisable
KeyFile "c:/IBM/HTTPServer/bin/key.kdb"
SSLStashFile "c:/IBM/HTTPServer/bin/key.sth
...
# Redirect allows you to tell clients about documents which used to exist in
# your server’s namespace, but do not anymore. This allows you to tell the
# clients where to look for the relocated document.
RewriteEngine On
#RewriteLog "logs/rewrite.log"
#RewriteLogLevel 9
# when doing form based authentication, ensure user/pwd is sent over https
RewriteCond %{SERVER_PORT} !^443$
RewriteRule ^/dogear/auth(.*) https://example.acme.com/dogear/auth$1
[noescape,L,R]
# when doing form based authentication, ensure user/pwd is sent over https
RewriteCond %{SERVER_PORT} !^443$
RewriteRule ^/blogs/roller-ui/login.do https://example.acme.com/blogs/
roller-ui/login.do [noescape,L,R]
Configuring Blogs
You must configure the Blogs feature before you and others can use it.
After you have successfully installed the Blogs feature and given yourself administrative access to the
Blogs feature using the WebSphere Application Server, follow these steps to configure it for use:
1. Open a Web browser and go to the Blogs Web address that you specified for the Blogs feature.
2. From the Welcome to Blogs page, click the New Blogs Creation Page link, and then log in using the
credentials of the Blog site administrator.
Note: You must be a user with administrative level access to the Blog site to be able to create a page.
3. Fill out a the new blog form to create the Blog site’s home page. Include the following information:
v Name – Type a name for the Blogs home page. For example: home.
v Description – Type a description of the Blogs home page.
v Handle – Type a value to use as the keyword for the home page. For example, home.
Note: Remember the value you specify here; you will need this information later.
v Theme – Choose homepage.
Note: This value must be changed from its default of blogs to homepage or any blogs that users
subsequently create will not be visible on the Blogs site.
4. Click Create Blog.
5. In the Actions section of the Edit My Blog tab, click Server administration to open the site
configuration settings document, and then type the value you specified for the handle into the
Handle of blog to serve as frontpage blog field; this is the value you entered in the Handle field in
Step 3.
You can optionally provide values for the following site settings:
v Site name – Type a name for the blog site which will be displayed on the home page of the blog
site.
v Short name – Type a short name for the blog which will be displayed in the blog site banner.
v Site Description – Type a description which will be displayed below the site name on the home
page and will be provided as the feed description.
For information about other configuration options, see the Administration Guide.
6. Click Save.
7. If you are installing the Blog site with the default configuration, Blogs is ready to be used.
The Blogs site is now running with a default configuration. For details on other configuration options,
and how to implement them, refer to the Administration Guide.
Note: Do not deselect the Enable HTTP server check box. Doing so could cause the features to be
inaccessible from the navigation bar.
4. Review the Summary screen to make sure the values you entered on previous screens are correct. If
you want to make a change, click Back to edit a value. If the values are correct, on the installation
summary screen, click Install to begin the installation.
5. Click Finish.
6. Start the WebSphere Application Server instance to which you installed the feature, such as server1,
by typing the following commands:
Note: If you are migrating data from a pilot to production installation, skip this step and the next
step. You will not start the servers until after the migration is complete.
v Linux:
cd opt/IBM/WebSphere/AppServer/profiles/<profile_name>/bin
startServer.sh <server_instance>
v Windows:
cd C:\IBM\WebSphere\AppServer\profiles\<profile_name>\bin
startServer.bat <server_instance>
Note: If the server fails to start, start it again by repeating the above commands. If it continues to fail,
look at the error log to see if there is a problem with your set up. The error log file is stored in the
following directory:
v Linux:
opt/IBM/WebSphere/AppServer/profiles/<profile_name>/logs/
<server_instance>/SystemOut.log
v Windows:
where <port_number> is the port number on the WebSphere Application Server that the feature is
available from. This is usually:
v 9080 – Standard port number for the default server process, server1. This is probably the server
process that you installed the feature on if you are installing each feature to its own profile.
v 9081-9085 – These are the port numbers that are usually assigned to features that are installed into
a single profile. The first server process you create is assigned the port 9081, the next 9082, and
each subsequent feature is assigned a port number incremented by one.
The serverindex.xml file stored in the node directory contains port assignment information.
See Mapping the features to the IBM HTTP Server for information about setting up a server that sits in
front of the WebSphere Application Server and directs requests (which are not required to specify port
numbers) to the appropriate features. If the Communities login screen is displayed, you have
successfully installed the Communities feature. If it is not, see the Troubleshooting section of this
document.
8. Optional: If you plan to install additional features on the same system and want to be able to refer to
the log file generated by the installer, copy the lcinstalllog.txt file from the following directory:
v Linux:
/tmp/lcinstalllog.txt
v Windows:
c:\Documents and Settings\<user_name>\Local Settings\temp\lcinstalllog.txt
into this directory:
v Linux:
/opt/IBM/WebSphere/LotusConnections/Communities/lcinstalllog.txt
v Windows:
c:\Program Files\IBM\WebSphere\AppServer\LotusConnections\Communities\
lcinstalllog.txt
The lcinstalllog.txt log file stored in the temporary directory is overwritten by subsequent feature
installations.
Much of the information you specify during the installation is stored in XML-based configuration files
associated with the product. For information about making changes to those values, see the
Administering Lotus Connections section of the Lotus Connections information center. For example, if
you change HTTP servers, you can use a wsadmin command to change the service location settings
defined in the configuration files for the feature.
Related tasks
Chapter 7, “Mapping the features to the IBM HTTP Server,” on page 99
After you install the features, map them to the IBM HTTP Server. This task updates the plugin-cfg.xml
file on the IBM HTTP Server, which is the configuration file that defines how the IBM HTTP Server
should access the features when they are requested from a Web browser.
Related reference
“Hardware requirements” on page 15
The following hardware is required for the systems that host IBM Lotus Connections services.
Note: In the following procedures, change all references to ″servername.com″ to the external facing
server name in your deployment.
1. In the Index file directory field, specify the file path to a local directory in which to store the index
files used by Dogear to perform full-text searches of bookmark titles and descriptions.
Alternatively, click Browse to navigate to a directory.
Do not share index file directories between different Dogear servers. Make sure the directories you
specify are large enough to hold the content. See the Hardware Requirements topic for details about
disk space requirements for the features.
Click Next.
2. In the Favicons file location field, type the file path to a local directory in which to store favorite
icons. Favorite icons are images associated with a bookmark that are displayed with the bookmark to
help identify its source.
Alternatively, click Browse to navigate to a directory.
Make sure the directories you specify are large enough to hold the content. See the Hardware
Requirements topic for details about disk space requirements for the features.
Click Next.
3. When asked to enter the fully qualified domain name for the feature, in the HTTP URL field, type the
Web address that users will type into a Web browser location bar to access the feature after it is
installed. If you are using an HTTP server, do not specify a port number and remove the default port
number provided by the installer. Select the Enable SSL server check box, and then type the Web
address users will type into a Web browser location bar to access the feature over SSL into the HTTPS
URL field. Click Next.
Note: Do not deselect the Enable HTTP server check box. Doing so could cause the features to be
inaccessible from the navigation bar.
4. Review the Summary screen to make sure the values you entered on previous screens are correct. If
you want to make a change, click Back to edit a value. If the values are correct, on the installation
summary screen, click Install to begin the installation.
5. Click Finish.
6. Open a Web browser and access the feature directly from the WebSphere Application Server by going
to the Web address you specified for the Dogear feature.
For example:
http://appserver.enterprise.acme.com:<port_number>/dogear
where the <port_number> is the port number on the WebSphere Application Server that the feature is
available from. This is usually:
v 9080 – Standard port number for the default server process, server1. This is probably the server
process that you installed the feature on if you are installing each feature to its own profile.
v 9081-9085 – These are the port numbers that are usually assigned to features that are installed into
a single profile. The first server process you create is assigned the port 9081, the next 9082, and
each subsequent feature is assigned a new port number in increments of one.
The serverindex.xml file stored in the node directory contains port assignment information.
7. If the Dogear login screen displays, the installation was successful. If it does not, see the
Troubleshooting section. Do not log into Dogear. You must map the feature to the IBM HTTP Server
and then edit the IBM HTTP Server configuration to protect your login credentials before you log in.
See Mapping the features to the IBM HTTP Server.
8. Optional: If you plan to install additional features on the same system and want to be able to refer to
the log file generated by the installer, copy the lcinstalllog.txt file from the following directory:
76 IBM Lotus Lotus Connections 1.0.1 Installation Guide
v Linux:
/tmp/lcinstalllog.txt
v Windows:
c:\Documents and Settings\<user_name>\Local Settings\temp\lcinstalllog.txt
into this directory:
v Linux:
/opt/IBM/WebSphere/LotusConnections/Dogear/lcinstalllog.txt
v Windows:
c:\Program Files\IBM\WebSphere\AppServer\LotusConnections\Dogear\
lcinstalllog.txt
The lcinstalllog.txt log file stored in the temporary directory is overwritten by subsequent feature
installations.
9. Specify a set of IP-ranges for your deployment so that Dogear can detect which Web addresses are
intranet sites versus Internet sites, and mark them accordingly. In the intranet IP Range table, add the
intranet IP ranges for your company. See the Administering Lotus Connections section of the information
center for details on how to specify IP ranges.
Related tasks
Chapter 7, “Mapping the features to the IBM HTTP Server,” on page 99
After you install the features, map them to the IBM HTTP Server. This task updates the plugin-cfg.xml
file on the IBM HTTP Server, which is the configuration file that defines how the IBM HTTP Server
should access the features when they are requested from a Web browser.
Related reference
“Hardware requirements” on page 15
The following hardware is required for the systems that host IBM Lotus Connections services.
Be sure you have mapped the feature to the IBM HTTP Server before you perform this task.
Note: This procedure assumes that you have completed the step to configure SSL on the IBM HTTP
Server described in the topic, Configuring the IBM HTTP Server for SSL.
# when doing form based authentication, ensure user/pwd is sent over https
RewriteCond %{SERVER_PORT} !^443$
RewriteRule ^/dogear/auth(.*) https://servername.com/dogear/auth$1 [noescape,L,R]
The following excerpt is from a httpd.conf file that forces authentication attempts and API calls in Blogs
and Dogear and forces API calls in Activities to be sent over a secure channel:
#LoadModule mime_magic_module modules/mod_mime_magic.so
LoadModule proxy_module modules/mod_proxy.so
LoadModule proxy_connect_module modules/mod_proxy_connect.so
LoadModule proxy_http_module modules/mod_proxy_http.so
#LoadModule proxy_ftp_module modules/mod_proxy_ftp.so
LoadModule rewrite_module modules/mod_rewrite.so
LoadModule setenvif_module modules/mod_setenvif.so
#LoadModule speling_module modules/mod_speling.so
...
<IfModule !mod_afpa_cache.c>
Listen 0.0.0.0:80
<VirtualHost *:443>
SSLEnable
SSLProxyEngine on
</IfModule>
SSLDisable
KeyFile "c:/IBM/HTTPServer/bin/key.kdb"
SSLStashFile "c:/IBM/HTTPServer/bin/key.sth
...
# Redirect allows you to tell clients about documents which used to exist in
# your server’s namespace, but do not anymore. This allows you to tell the
# clients where to look for the relocated document.
RewriteEngine On
#RewriteLog "logs/rewrite.log"
#RewriteLogLevel 9
# when doing form based authentication, ensure user/pwd is sent over https
RewriteCond %{SERVER_PORT} !^443$
RewriteRule ^/dogear/auth(.*) https://example.acme.com/dogear/auth$1
[noescape,L,R]
# when doing form based authentication, ensure user/pwd is sent over https
RewriteCond %{SERVER_PORT} !^443$
RewriteRule ^/blogs/roller-ui/login.do https://example.acme.com/blogs/
roller-ui/login.do [noescape,L,R]
Note: If you are upgrading from a previous version of Dogear, complete the procedure, Updating the
httpd.conf file when upgrading Dogear, in addition to this procedure.
Note: Do not deselect the Enable HTTP server check box. Doing so could cause the features to be
inaccessible from the navigation bar.
3. Review the Summary screen to make sure the values you entered on previous screens are correct. If
you want to make a change, click Back to edit a value. If the values are correct, on the installation
summary screen, click Install to begin the installation.
4. Click Finish.
5. Optional: Determine whether you want to display organizational chart information in the Profile
pages, and then edit the following file to make the required changes. Alternatively, you can use
wsadmin commands to edit the values in these files later. See the Lotus Connections information
center for more details.
v Linux:
/opt/IBM/WebSphere/AppServer/profiles/<profile_name>/config/
cells/<cell_name>/nodes/<node_name>/LotusConnections-config/
profiles-config.xml
v Windows:
C:\IBM\WebSphere\AppServer\profiles\<profile_name>\config\
cells\<cell_name>\nodes\<node_name>\LotusConnections-config\
profiles-config.xml
v To display organizational chart information in profile pages, make the following changes to the
profiles-config.xml file:
– In the <fullReportsToChainCache> tag, type the UID of the CEO or whoever is at the top of
the reporting chain as the value of the ceouid attribute.
– In the size attribute of the <miniReportsToChainCache> tag, type the number of employees
included in the Profiles database.
v If you do not want organization chart information to be displayed in the profile pages, change the
setting for the <organizationalStructureEnabled> tag to false.
Note: Implementing report-to information increases the demand on the server. If you implement this,
be sure to increase the size of the initial and maximum heap settings of the Java Virtual Machine in
WebSphere Application Server before running Profiles. Go to the WebSphere Application Server
information center at the following Web site for more information: http://publib.boulder.ibm.com/
infocenter/wasinfo/v6r1/index.jsp?topic=/com.ibm.websphere.nd.doc/info/ae/ae/
urun_rconfproc_jvm.html
6. Start the WebSphere Application Server on which you installed the feature by executing the following
commands:
Note: If the server fails to start, start it again by repeating the above commands. If it continues to fail,
look at the error log to see if there is a problem with your set up. The error log file is stored in the
following directory:
v Linux:
opt/IBM/WebSphere/AppServer/profiles/<profile_name>/logs/<server_name>/
SystemOut.log.
v Windows:
C:\IBM\WebSphere\AppServer\profiles\<profile_name>\logs\<server_name\
SystemOut.log.
7. Open a Web browser and access the feature directly from the WebSphere Application Server by going
to the Web address you specified for the Profiles feature.
For example:
http://appserver.enterprise.acme.com:<port_number>/profiles
where the <port_number> is the port number on the WebSphere Application Server that the feature is
available from. This is usually:
v 9080 – Standard port number for the default server process, server1. This is probably the server
process that you installed the feature on if you are installing each feature to its own profile.
v 9081-9085 – These are the port numbers that are usually assigned to features that are installed into
a single profile. The first server process you create is assigned the port 9081, the next 9082, and
each subsequent feature is assigned a port number incremented by one.
The serverindex.xml file stored in the node directory contains port assignment information. See
Mapping the features to the IBM HTTP Server for information about setting up a server that sits in front
of the WebSphere Application Server and directs requests (which are not required to specify port
numbers) to the appropriate features. If the Profiles login screen displays, you have successfully
installed the Profiles feature. If it does not, see the Troubleshooting section.
8. Optional: If you plan to install additional features on the same system and want to be able to refer to
the log file generated by the installer, copy the lcinstalllog.txt file from the following directory:
v Linux:
/tmp/lcinstalllog.txt
v Windows:
c:\Documents and Settings\<user_name>\Local Settings\temp\lcinstalllog.txt
into this directory:
v Linux:
/opt/IBM/WebSphere/LotusConnections/Profiles/lcinstalllog.txt
v Windows:
c:\Program Files\IBM\WebSphere\AppServer\LotusConnections\Profiles\
lcinstalllog.txt
The lcinstalllog.txt log file stored in the temporary directory is overwritten by subsequent feature
installations.
When you enable presence awareness in Profiles, a person’s online status is indicated by a set of icons
and an associated status message. Presence awareness tells you whether the person is available to chat,
busy in a meeting, or away from their computer.
To bring the Sametime presence awareness capability into Profiles, you must do one of the following:
v Configure single sign-on between the Domino Sametime server and the WebSphere Application Server
hosting Profiles – If users explicitly log into Profiles or access Profiles after logging into another
WebSphere Application Server-based feature hosted in the same single sign-on domain, presence
awareness appears in Profiles.
v Configure the anonymous login capability in Sametime – Users do not have to log in before they can
see presence awareness in Profiles.
You must have the following software enabled to be able to add presence awareness to Profiles:
v Domino 7.0.1 server or later configured with Sametime 7.5 or later services and configured to use one
of the LDAP directories supported by Lotus Connections. In addition, the Directory Assistance feature
of the Domino server must be enabled. Lotus Connections does not support Lotus Domino as an LDAP
directory; using the Directory Assistance feature of Lotus Domino enables you to include the
directories being used by the Lotus Connections services, in directory operations.
v The Profiles feature must be deployed on a WebSphere Application Server instance that is configured
to use the same directory or directories that Domino is configured to use and that contains records for
the Lotus Connections users. In addition to being able to use the Directory Assistance feature in
Domino, the support in WebSphere for Federated Repositories may also be used. One or more
directories must be shared between the Domino and WebSphere servers and that set of users may take
advantage of the Sametime integration in Profiles. If the Domino deployment is configured to encrypt
traffic between the server and the LDAP directory or directories in use, the WebSphere Application
Server deployment must be configured to do the same.
v The WebSphere Application Server, Domino, and Sametime deployments must all exist in the same
domain because their integration depends on the single sign-on facility provided by the LTPA tokens.
Note: The LTPA facility in Domino does not support the newer LTPA v2 specification.
b. Select Authentication mechanisms and expiration, and in the Cross-cell single sign-on section,
type a password and the location to which you want the LTPA key to be exported.
Note: This key must be available to the Domino server so that it may decrypt any LTPA tokens
forwarded to it by the Connections Profiles service.
c. Open the Domino Administrator client and access the Server document for the Domino server.
Select Create Web → SSO Configuration. Select Keys, and then select Import WebSphere LTPA
Keys.
d. Type the following values into the specified fields:
v Configuration Name – LtpaToken
v Organization – Optional. You can type the organization name.
v DNS Domain – Type the DNS Domain associated with your Domino and WebSphere
Application Server deployments. For example:
.acme.example.com
Note: This is necessary to reconcile the different ways in which WebSphere Application Server
and Domino format names.
v Domino Server Names – Type the name of your Domino server.
v LDAP Realm and LTPA Version – These fields are populated when you import the LTPA key.
Ensure that the realm name matches the domain name used on WebSphere Application Server.
For example, if the port identified in the realm is 389, then this means WebSphere Application
Server was configured to not encrypt traffic between itself and the directory. Configure Domino
in the same way to ensure a matching realm name.
Save the Web SSO Configuration document.
e. Return to the Server document. Select the Internet Protocols tab, and then select the Domino Web
Engine tab. For Session authentication, select Multiple Servers (SSO), and then for Web SSO
Configuration, verify that the name of the newly created LtpaToken is listed there. If it is not, add
it.
f. Restart the Domino Server and look for a message indicating the Web SSO Configuration was
successfully applied.
g. You can test whether single sign-on is configured correctly by accessing a WebSphere Application
Server-based application that is protected. After authenticating successfully, you can then try to
access a Domino application that has also been protected and does not allow anonymous access. If
the server challenges you to authenticate, single sign-on is not configured correctly between the
Domino server and WebSphere Application Server. If it does not challenge you, it is.
2. For web pages that have STLinks integrated in them to function on Mozilla-based browsers, STLinks
resources must be available on the Web server that is fronting the WebSphere Application Server
which hosts Profiles. Also, the STLinks applet that makes Sametime functionality available to
browser-based applications must be signed. To enable STLinks access for Mozilla-based browsers and
sign the applet, complete the following steps:
a. Find the stlinks.jar file, which contains the ST Links resources, on the Domino server in the
following directory:
<Domino data directory>\domino\html\sametime\stlinks
execfile("<WAS_HOME>/profiles/<profile_name>/bin/connectionsConfig.py")
LCConfigService.checkOutConfig("/wsadminoutput", "<cell_name>")
LCConfigService.updateConfig("sametimeLinks.href",
"http://example.acme.com/sametime/stlinks")
LCConfigService.updateConfig("sametimeLinks.enabled","true")
LCConfigService.updateConfig("sametimeLinks.ssl.href",
"https://example.acme.com/sametime/stlinks")
LCConfigService.updateConfig("sametimeLinks.ssl.enabled","true")
LCConfigService.showConfig()
LCConfigService.checkInConfig()
quit
See the Administration section of the Lotus Connections information center for information on using
wsadmin commands to edit feature settings.
4. Restart the Profiles application on the WebSphere Application Server to apply your changes and
enable presence awareness.
For example, if you installed version 1.0 of all the Lotus Connections features, except Blogs, to a system,
then updated the four installed features to version 1.0.1, and now would like to add Blogs to the system
for the first time, you must edit the Vital Product Data registry file named vpd.properties. The
vpd.properties file identifies product version numbers, but does not get updated to reflect the version
number change to features updated using the update installer. The installer for Lotus Connections 1.0.1
will not install a 1.0.1 version of a feature to a system that is hosting features that the vpd.properties file
identifies as having a version number earlier than 1.0.1. Therefore, before you can run the 1.0.1 installer
to add the Blogs feature, you must edit the vpd.properties file to change the version numbers of the
previously updated features from 1.0 to 1.0.1.
1. Before you edit the vpd.properties file, make a backup copy of it. A vpd.properties file is stored in the
root directory of the system hosting the WebSphere Application Server instance associated with a
Lotus Connections installation:
For example:
v Linux:
/root/vpd.properties
v Windows:
<root>\vpd.properties
to this:
LotusConnections|1|0|0|1|1.0.1.0|1=Lotus Connections|
Wrapper Product| |IBM| | |/opt/IBM/WebSphere/LotusConnections|
0|0|1|LotusConnections|1|0|0|1|1.0.1.0|1|0
|false|"uninstall" "uninstall.jar" "uninstall.dat"
""|true|3|LotusConnections|1|0|0|1|1.0.1.0|1
v Windows:
Change the following value:
LotusConnections|1|0|0|0| |1=Lotus Connections|
Wrapper Product| |IBM| | |C:\IBM\WebSphere\LotusConnections|
0|0|1|LotusConnections|1|0|0|0| |1|0
|false|"uninstall" "uninstall.jar" "uninstall.dat"
""|true|3|LotusConnections|1|0|0|0| |1
to this:
LotusConnections|1|0|0|1|1.0.1.0|1=Lotus Connections|
Wrapper Product| |IBM| | |C:\IBM\WebSphere\LotusConnections|
0|0|1|LotusConnections|1|0|0|1|1.0.1.0|1|0
|false|"uninstall" "uninstall.jar" "uninstall.dat"
""|true|3|LotusConnections|1|0|0|1|1.0.1.0|1
3. Save and close the vpd.properties file.
Related tasks
“Lotus Connections version 1.0.1” on page 114
Use the update installer to update Lotus Connections version 1.0 to Lotus Connections version 1.0.1.
When you set up a stand-alone deployment of Lotus Connections, after you have installed the features
you want to implement, do one of the following:
v Link the features together – Edit the configuration file in each profile to include information about the
features installed on different profiles. Follow the instructions in the following topic:“Linking features”
v Create a single-node cluster – Install a deployment manager and create a cluster that contains a single
node. This enables you to centrally administer features installed on different profiles. It also make it
easier to upgrade to a multiple node cluster in the future, if your enterprise expands and the need for
a cluster arises. Complete Steps 1-8 in the following topic:“Creating a cluster” on page 92
Linking features
After you have installed the Lotus Connections features that you want to use, configure the features to
work together. Doing so enables features to share information, and allows you to easily navigate among
them.
For example, during the installation of the features, you are asked to provide server host name
information. The installer uses the information you provide to populate the <sloc:serviceReference
serviceName="<feature_name>"/> element in the LotusConnections-config.xml file on the server. If, on
another server, you install a second feature on a separate profile, a second LotusConnections-config.xml
file is created and populated with information that pertains to the second feature. Because the features
are not federated into a single cell, they run independently and cannot interact with one another. The
navigation bar in each feature lists only the current feature, and users cannot navigate from one feature to
another.
Windows:
C:\IBM\WebSphere\AppServer\profiles\<profile_name>\config\cells\
<cell_name>\LotusConnections-config\LotusConnections-config.xml
Linux:
/opt/IBM/WebSphere/AppServer/profiles/<profile_name>/config/cells/
<cell_name>/LotusConnections-config/LotusConnections-config.xml
where <profile_name> is the name of the WebSphere Application Server profile and <cell_name> is the
WebSphere Application Server cell in which you installed the feature.
First link two features together, test that each feature recognizes the other one, and then link additional
features one at a time.
Note: On some Web browsers, you might need to clear the browser cache to see this effect.
7. Repeat these steps for each feature you have installed, one at a time.
8. If you are enabling the Profiles feature, to reference it, you must edit both the profiles and personTag
sloc:serviceReference elements.
Note: Values for the ssl_href and ssl_enabled attributes only need to be specified for features that you
are configuring to run over SSL.
<config
id="LotusConnections"
xmlns="http://www.ibm.com/LotusConnections-config"
xmlns:tns="http://www.ibm.com/LotusConnections-config"
xmlns:sloc="http://www.ibm.com/service-location"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.ibm.com/LotusConnections-config
LotusConnections-config.xsd">
<sloc:serviceReference serviceName="personTag"
href="http://<full_host_dns_name>/ibm_semanticTagServlet"
enabled="true"
ssl_href="https://<full_host_dns_name>/ibm_semanticTagServlet"
ssl_enabled="true"/>
//Note: If the service for which you are editing this version of the
//configuration file is set up to use SSL, this ssl_enabled attribute
//must be set to true or users may see security warning messages when
//they access pages using Microsoft Internet Explorer.
<sloc:serviceReference serviceName="sametimeLinks"
href="admin_replace"
enabled="false"
ssl_href="admin_replace"
ssl_enabled="false">
<anonymousLogin enabled="false" />
</sloc:serviceReference>
<sloc:serviceReference serviceName="profiles"
href="http://<full_host_dns_name>/profiles"
enabled="true"
ssl_href="https://<full_host_dns_name>/profiles"
ssl_enabled="true"
feed_href="admin_replace"
feed_enabled="false"
ssl_feed_href="admin_replace"
ssl_feed_enabled="false"
provider_use_feed_enabled="false"/>
<sloc:serviceReference serviceName="communities"
href="http://<full host dns name and port (if applicable),
such as appserver.enterprise.acme.com>:80/communities"
enabled="true"
ssl_href="https://<full host dns name and port (if applicable),
such as appserver.enterprise.acme.com>:443/communities"
ssl_enabled="true" />
<sloc:serviceReference serviceName="blogs"
href="http://<full host dns name and port (if applicable),
such as appserver.enterprise.acme.com>/blogs"
enabled="true" />
<sloc:serviceReference serviceName="dogear"
href="http://<full host dns name, such as
appserver.enterprise.acme.com>/dogear"
enabled="true" />
ssl_href="https://<full host dns name, such as
appserver.enterprise.acme.com>/dogear"
ssl_enabled="true" />
<sloc:serviceReference serviceName="activities"
href="http://<full host dns name, such as
appserver.enterprise.acme.com>/activities"
enabled="true" />
<style enabled="false">
<header url="admin_replace" />
<css url="admin_replace" />
When you install Communities in a stand-alone deployment of Lotus Connections, the installer sets up
Java 2 security for the feature automatically. Java 2 security provides a policy-based access control
mechanism that increases overall system integrity by checking for permissions before allowing access to
certain protected system resources. When you install Communities on a node and federate it into a Lotus
Connections cell, you must enable Java 2 security on the deployment manager as well. If you do not, the
Java 2 security settings on the node will be overwritten during clustering. Without Java 2 security
enabled, users can log into all Communities, including those to which they are not members.
You must review and meet the software and hardware requirements for each system you plan to
configure in the deployment before you can begin the network deployment installation. Also, be sure to
complete the preinstallation tasks for a network deployment.
Note: If you decide to create or upgrade a configuration that has one profile with five server
processes, you must install all five features before you add any of them to the cluster. Lotus
Connections does not support running the installer on a managed node. A managed node is an
application server that has been federated into a Deployment Manager cell.
2. Install WebSphere Application Server Network Deployment on a separate system from the one to
which you installed Lotus Connections. See the WebSphere Application Server information center at
the following external Web site for more information: http://publib.boulder.ibm.com/infocenter/
wasinfo/v6r1/index.jsp?topic=/com.ibm.websphere.nd.doc/info/ae/ae/welcclusters.html
3. Create a Deployment Manager profile, and then enable Global Security.
4. Set up federated repositories on the WebSphere Application Server hosting the Deployment Manager.
See “Setting up federated repositories” on page 25.
5. Communities only: If you plan to install the Communities feature as part of the cluster, enable Java
2 security on the system that hosts the Deployment Manager. See “Preinstallation tasks for a network
deployment” on page 91 for more details.
Note: Java 2 security will be enabled on all the nodes federated into this cell.
6. Edit the security settings for the system that is already hosting Lotus Connections to have the same
security settings as the Deployment Manager profile of the cell you are planning to federate into.
7. Configure the security settings for each additional system to which you will install Lotus
Connections to have the same security settings as the Deployment Manager profile of the cell you
are planning to federate into.
8. Add the first node to the cluster. See “Installing the first node” on page 93.
9. If you have set up a node that has Blogs enabled, you must create a snapshot directory for the
feature. See “Creating a snapshot directory for Blogs” on page 95
10. To add subsequent nodes to this feature cluster, install another instance of the same Lotus
Connections feature on a separate system. See “Installing a Lotus Connections feature” on page 56.
Alternatively, consider running a silent installation, which enables you to reuse the values you
provided during the previous installation.
11. Add another node to the cluster. See “Installing a subsequent node” on page 96.
12. You can add additional nodes by installing another instance of Lotus Connections, and then
repeating the previous step and replacing any references to the node or the server hosting the Lotus
Connections features with the appropriate information.
Related tasks
Note: When the cluster starts, it first starts the application server. If this does not occur, start the
application server by selecting Servers → Application servers, and then selecting the check box
next to the Web server for the feature, such as server1. Click Start.
8. You have set up the primary node of the cluster. Access Lotus Connections to make sure the node is
functioning. Go to the following Web address, and make sure you can log in successfully.
http://firsthostname.domainname:9080/<feature_name>
Note: 9080 is the HTTP port number for the server you have added a cluster member.
9. Copy PY files from one directory to another on the Deployment Manager system. Copy the files from
the following directory:
<WebSphere_Application_Server>\AppServer\profiles\<Deployment_Manager_profile>\
config\bin_lc_admin
to the following directory on the same system:
<WebSphere_Application_Server>/AppServer/profiles/<Deployment_Manager_profile>/
bin
You must have added Blogs to the primary node of the cluster before you can perform this procedure.
To create a snapshot directory for Blogs in a cluster, complete the following steps:
1. Designate a shared directory as a snapshot directory that Blogs can use to copy search indexes. See
the Hardware Requirements topic for details about disk space requirements for the features.
2. Start the Blogs feature by opening a Web browser, and then going to the Web address you specified
for the Blogs feature. For example:
http://<http_server_name>/blogs
3. In the Actions section of the Edit your Blog tab, click Administration → Server Administration to
open the Administration page.
4. In the Search snapshot directory field, type the file path of the shared directory that you designated
in Step 1.
All subsequent nodes of the Blogs feature that you add will use this shared directory as the snapshot
directory automatically.
Note: Make sure there are no extra spaces at the end of these property values in the properties file.
The installation scripts use these values to build directory paths.
4. Run the following commands to add the node:
v Windows:
cd c:\IBM\WebSphere\LotusConnections\ConfigEngine
v Linux:
cd opt/IBM/WebSphere/LotusConnections/ConfigEngine
Then, enter the following command (without carriage returns):
Note: When the cluster starts, it first starts the application servers. If this does not occur, start the
application servers by selecting Servers → Application servers, and then selecting the check box
next to the Web server for the first node, such as server1 and the check box next to the Web server
for the subsequent node, such as server2. Click Start.
7. You have set up a Lotus Connections cluster with two nodes. Access Lotus Connections to make sure
the node is functioning. Go to the following Web addresses, and make sure you can log in
successfully.
http://firsthostname.domainname:<port_number>/<feature_name>
http://secondhostname.domainname:<port_number>/<feature_name>
where the port number for the first node is likely 9080 and the second is likely 9081.
Network deployment: Define one or more Web servers for the nodes in the cluster.
Stand-alone deployment: Do not complete this procedure. Define a Web server for each profile included
in your deployment by completing the steps described in Defining the IBM HTTP Server for a profile
instead.
Note: 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:
Chapter 6. Setting up a network deployment 97
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/topic/com.ibm.websphere.base.doc/info/aes/
ae/twsv_plugin.html
To define the IBM HTTP Server for a node, complete the following steps:
1. Make sure the IBM HTTP Server is installed and running.
2. From the WebSphere Application Server Integrated Solutions Console for the Network Deployment
Manager, select System administration → Nodes → Add Node.
3. Select Unmanaged node, and then click Next.
4. Specify the properties of the node by providing values in the following fields:
v Name – Name of the node.
v Host Name – Host name of the IBM HTTP Server.
v Platform Type – Operating system on the system that hosts the IBM HTTP Server.
Click OK.
5. Select Servers → Web servers, and then click New.
6. Provide values for the following fields:
Select node
Choose the node you just created.
Type Choose the IBM HTTP Server.
Host Name
Type the fully qualified DNS host name. For example: enterprise.acme.com.
Platform
Choose the operating system.
7. Click Next.
8. Select the default Web server template listed, and then click Next.
9. On the Enter the properties for the new Web server page, check the paths and make adjustments if
necessary, and then enter the IBM Administration Server user name and password. Confirm the
password, and then click Next.
10. Confirm the new Web server, click Finish, and then click Save.
Complete the procedures to create a Web server for each profile or node that you want to map before you
begin this task.
Any features that are configured behind the IBM HTTP Server must be mapped to it. If you do not install
the HTTP server, users must include the correct port number in the Web address that they type into the
Web browser to access the feature. The Blogs and Dogear features require that you install the IBM HTTP
Server and Web server plug-in because they use the HTTP server to force login credentials to be
submitted over a secure channel. When you use the IBM HTTP Server, it monitors all traffic sent over
HTTP. By mapping all the features to the IBM HTTP Server, you tell it which ports to use to access each
feature and it can redirect requests to the appropriate features.
Each Lotus Connections feature is made up of one or more modules. You must map each module to the
IBM HTTP Server. The following steps describe how to map all of the modules for all of the features. If
you are not installing all of the features, perform the steps that pertain only to those features you are
installing.
To map the features to the IBM HTTP Server, complete the following steps:
1. Make sure the IBM HTTP Server you plan to map the feature to is installed and running.
2. Do one of the following steps:
v If you have set up a network deployment, open the WebSphere Application Server Integrated
Solutions Console on the system to which you installed the Deployment Manager, and then
complete the steps below.
v If you are mapping multiple features that you installed into separate server processes in a single
profile, open the WebSphere Application Server Integrated Solutions Console of the system on
which you installed the single profile, and then complete the steps below on that same system.
v If you are mapping features that you installed to individual profiles, you must open the
WebSphere Application Server Integrated Solutions Console associated with each profile and
perform the steps described per feature below on the associated consoles. After completing this
procedure, perform the steps described in Mapping multiple profiles to a single IBM HTTP Server.
3. Select Applications → Enterprise Applications.
4. Do one of the following steps:
Note: This step instructs you to select webserver1. Be sure that you have defined this Web server
before you attempt to complete these steps. See Defining the IBM HTTP Server.
v Activities:
– Select Activities → Manage Modules.
– In the Clusters and Servers box, select both of the following servers:
Note: Use the Ctrl key to select more than one server at a time.
- <server_name>
where <server_name> is the name of the profile on which you installed the feature.
- webserver1
– Select the Activities Web UI and Connections Navigation check boxes, and then click Apply.
Note: Use the Ctrl key to select more than one server at a time.
- <server_name>
where <server_name> is the name of the profile on which you installed the feature.
- webserver1
– Select the Roller Weblogger and Connections Navigation check boxes, and then click Apply.
– Review the Server details to make sure both servers are now listed there. Click OK, and then
click Save.
v Communities:
– Select Communities → Manage Modules.
– In the Clusters and Servers box, select both of the following servers:
Note: Use the Ctrl key to select more than one server at a time.
- <server_name>
where <server_name> is the name of the profile on which you installed the feature.
- webserver1
– Select the Communities Web UI and Connections Navigation check boxes, and then click
Apply.
– Review the Server details to make sure both servers are now listed there. Click OK, and then
click Save.
v Dogear:
– Select Dogear → Manage Modules.
– In the Clusters and Servers box, select both of the following servers:
Note: Use the Ctrl key to select more than one server at a time.
- <server_name>
where <server_name> is the name of the profile on which you installed the feature.
- webserver1
– Select the Dogear Application and Connections Navigation check boxes, and then click Apply.
– Review the Server details to make sure both servers are now listed there. Click OK, and then
click Save.
v Profiles:
– Select Profiles → Manage Modules.
– In the Clusters and Servers box, select both of the following servers:
Note: Use the Ctrl key to select more than one server at a time.
- <server_name>
where <server_name> is the name of the profile on which you installed the feature.
- webserver1
– Select the Profiles, Connections Navigation, and Semantic Tag Service check boxes, and then
click Apply.
Note: This step is only required if you are installing multiple features to a single WebSphere
Application Server profile.
a. From the WebSphere Application Server Integrated Solutions Console of the server which hosts
the profile, expand Environment, and then select Virtual Hosts.
b. Click default_host → Host Aliases, click New, and then add the following values to the fields:
v Host Name – <feature_name>
v Port – <port_number_for_feature>
Refer to the serverindex.xml file stored in the node directory to discover port assignments if you
did not make a note of them during the installation. For example, if you installed all five features
to a single profile, and Profiles was assigned the port number 9085, you would specify the
following values here:
v Host Name – profiles
v Port – 9085
c. Click OK, and then click Save.
d. Repeat these steps to add a virtual host for each feature in the profile.
6. From the WebSphere Application Server Integrated Solutions Console, select Servers → Web servers,
select the check box beside the Web server (webserver1), and then click Generate Plug-in.
7. Select the check box beside your web server again, and then click Propagate Plug-in.
Note: If you have trouble propagating the plug-in on Linux, restart the IBM HTTP Server using the
following commands:
./adminctl start
./apachectl -k stop
./apachectl -k start
8. Communities only: Select Environment → Update global Web Server plug-in configuration, and
then click OK to update the plug-in.
9. Stop, and then start the Web server.
10. Restart the feature servers by doing the following:
a. From the WebSphere Application Server Integrated Solutions Console, select Applications →
Enterprise Applications.
b. Select the check box beside each feature you want to restart.
c. Click Stop.
d. Select the check boxes again, and then click Start.
11. Log out of the WebSphere Application Server Integrated Solutions Console.
12. Test the mapping by opening a Web browser and trying to access each of the features by specifying
the following:
http://<hostname>/<feature_name>
where <hostname> is the host name of the Web server to which you mapped the feature and
<feature_name> is the name of the feature. Do not specify the port number.
Related tasks
“Creating a cluster” on page 92
Create a cluster to add redundancy to the deployment and achieve better performance.
Complete this procedure if you installed each Lotus Connections feature to a separate profile, but want to
use a single IBM HTTP Server with the product. Do not complete this procedure if you are planning to
add the multiple profiles to a node in a network deployment. In that case, you can define a Web server
for the node and map only the node to the IBM HTTP Server.
To map multiple profiles to a single IBM HTTP Server, complete the following steps:
1. Follow the steps in Mapping the features to the IBM HTTP Server to map only one of the profiles.
2. Copy the plugin-cfg.xml file, and then name the copy to associate the file with the profile you just
mapped, for example: plugin-cfg-Activities.xml.
3. Repeat Steps 1 and 2 for each profile.
4. Merge the multiple copies of the plugin-cfg.xml file into a single file, name it plugin-cfg.xml and
replace the file in the IBM HTTP Server directory with the edited version you just created.
To merge the files, capture the following values:
a. Add the <VirtualHost> elements from each feature profile configuration file into the
<VirtualHostGroup Name=″default_host″> element block in the merged file. For example, the
following set of virtual host values represent the set for a single feature profile. Your port numbers
will differ based on your configuration:
<VirtualHostGroup Name="default_host">
<VirtualHost Name="*:9084"/>
<VirtualHost Name="*:80"/>
<VirtualHost Name="*:9447"/>
<VirtualHost Name="*:5069"/>
<VirtualHost Name="*:5068"/>
<VirtualHost Name="*:443"/>
</VirtualHostGroup>
b. Copy the <ServerCluster> element from the configuration file for each feature profile into the
merged file. For example:
<ServerCluster
CloneSeparatorChange="false"
IgnoreAffinityRequests="true"
LoadBalance="Round Robin"
Name="server1_Node05_Cluster"
PostBufferSize="64"
PostSizeLimit="-1"
RemoveSpecialHeaders="true"
Example of a merged plugin-cfg.xml file for two nodes, one on which Activities has been installed and a
another on which Blogs has been installed.
<ServerCluster
CloneSeparatorChange="false"
IgnoreAffinityRequests="true"
LoadBalance="Round Robin"
<UriGroup
Name="default_host_server1_acme1Node01_Cluster_URIs">
<Uri
AffinityCookie="JSESSIONID"
AffinityURLIdentifier="jsessionid"
Name="/snoop/*"/>
<Uri
AffinityCookie="JSESSIONID"
AffinityURLIdentifier="jsessionid"
Name="/hello"/>
<Uri
AffinityCookie="JSESSIONID"
AffinityURLIdentifier="jsessionid"
Name="/hitcount"/>
<Uri
AffinityCookie="JSESSIONID"
AffinityURLIdentifier="jsessionid"
Name="*.jsp"/>
<Uri
AffinityCookie="JSESSIONID"
AffinityURLIdentifier="jsessionid"
Name="*.jsv"/>
<Uri
AffinityCookie="JSESSIONID"
AffinityURLIdentifier="jsessionid"
Name="*.jsw"/>
<Uri
AffinityCookie="JSESSIONID"
AffinityURLIdentifier="jsessionid"
Name="/j_security_check"/>
<Uri
AffinityCookie="JSESSIONID"
AffinityURLIdentifier="jsessionid"
Name="/ibm_security_logout"/>
<Uri
AffinityCookie="JSESSIONID"
AffinityURLIdentifier="jsessionid"
Name="/servlet/*"/>
<Uri
AffinityCookie="JSESSIONID"
AffinityURLIdentifier="jsessionid"
<Route
ServerCluster="server1_acme1Node01_Cluster"
UriGroup="default_host_server1_acme1Node01_Cluster_URIs"
VirtualHostGroup="default_host"/>
<Route
ServerCluster="server1_acme1Node02_Cluster"
<RequestMetrics
armEnabled="false"
loggingEnabled="false"
rmEnabled="false"
traceLevel="HOPS">
<filters enable="false" type="URI">
<filterValues enable="false" value="/snoop"/>
<filterValues enable="false" value="/hitcount"/>
</filters>
<filters enable="false" type="SOURCE_IP">
<filterValues enable="false" value="255.255.255.255"/>
<filterValues enable="false" value="254.254.254.254"/>
</filters>
<filters enable="false" type="JMS">
<filterValues enable="false" value="destination=aaa"/>
</filters>
<filters enable="false" type="WEB_SERVICES">
<filterValues enable="false" value="wsdlPort=aaa:op=bbb:nameSpace=ccc"/>
</filters>
</RequestMetrics>
</Config>
Update to Lotus Connections are delivered in fix packs. You can find the latest fixes and fix packs
available for download from the IBM Fix Central Web site:
http://www.ibm.com/eserver/support/fixes/
Click the About link from a feature’s home page to display a product page which specifies the feature
build number.
To use the Lotus Connections update installer, complete the following steps:
1. Download the download.updii.1010.multi.ia.zip file which contains the Lotus Connections Update
Installer application from the IBM Fix Central Web site. To do so, go to the following Web page:
http://www.ibm.com/eserver/support/fixes/
Select the product family Lotus, and product name Lotus Connections, and then search by the Fix ID
1.0.1.0-LC-Multi-IFLO23494.
Save the file to a temporary directory, and then extract its contents to add the following directories to
your temporary directory:
download.updii.1010.multi.ia/LO23494/lc101-pui
2. From the lc101-pui directory, find the LotusConnectionsUpdateInstaller.zip file, and then extract its
contents into the following directory:
v Linux:
/opt/IBM/WebSphere/LotusConnections/update
v Microsoft Windows:
C:\IBM\WebSphere\LotusConnections\update
Note: When running this command in a UNIX shell, be sure to use the syntax
.(space)./setupCmdLine.sh. If you do not precede the command with the period and space, the Java
environment will not be properly set for the active shell.
5. To run the update installer, enter the following command:
v Linux:
/opt/IBM/WebSphere/LotusConnections/update>
./updateLC.sh -<parameters>
v Microsoft Windows:
C:\IBM\WebSphere\LotusConnections\update>
updateLC.bat -<parameters>
where <parameters> are the parameters you pass to the update installer command to specify what
you want the command to do. See updateLC command for more details.
Related tasks
“Updating a network deployment” on page 117
In a network deployment, you must first plan the update, then perform the update, and finally
synchronize the changes between servers.
“Updating a stand-alone server” on page 115
Use the update installer to install a fix pack to update a stand-alone deployment of Lotus Connections
version 1.0 to version 1.0.1.
“Installing an interim fix” on page 124
An interim fix is a noncumulative fix that is tested by IBM and made available to all customers.
updateLC command
The updateLC command can install or uninstall interim or cumulative fixes or fix packs to Lotus
Connections and provide information about the update state of applied interim or cumulative fixes or fix
packs.
Purpose
This command:
v Installs fixes and fix packs.
v Uninstalls fixes and fix packs.
v Reports on the current state of applied fixes and fix packs.
updateLC.{sh|bat}
Parameters
-? Displays command usage information.
/?
Displays command usage information.
-configProperties <propertyFile>.properties
Specifies an externally supplied properties file containing Lotus Connections properties and values.
When specifying properties in a file, use the following conventions:
Examples
The following examples demonstrate how to perform common tasks. They assume the following:
v The Lotus Connections installation root is:
C:\IBM\WebSphere\LotusConnections
v The fix repository is:
C:\IBM\WebSphere\LotusConnections\update\fixes
v The fix pack repository is:
C:\IBM\WebSphere\LotusConnections\update\fixpacks
Note: The examples include carriage returns after each parameter to make the example easier to
understand. When using the command, do not add carriage returns after the parameters.
To bring down Lotus Connection for maintenance, complete the following steps:
1. Let your users know how long the product will be unavailable and when the maintenance work will
begin. You can send e-mail notifications to community members or inform users of the planned
outage by posting a message to an area of the product that is used to provide site status information.
2. Drop all connections from the applications to the database servers to ensure that there are no
processes still connected to the servers.
3. Perform one of the following steps:
v Stop the IBM HTTP Server – Only do this if no other applications are using the IBM HTTP Server.
v Create a rewrite rule in the configuration file for the IBM HTTP Server (httpd.conf ) that redirects
requests for Lotus Connections features to a maintenance page explaining that the product is
temporarily unavailable due to scheduled maintenance work.
4. Stop each server that is hosting a Lotus Connections feature to ensure that there are no remaining
open sessions. You can do this by either using the WebSphere Application Server Integrated Solutions
Console, or, if your configuration includes profiles that have multiple server processes and you cannot
access each feature using the WebSphere Application Server Integrated Solutions Console, use the
wsadmin client to stop them.
Related tasks
“Updating a network deployment” on page 118
Use the update installer to install a fix pack that updates Lotus Connections version 1.0 to version
1.0.1 in a network deployment.
“Updating a stand-alone server”
Use the update installer to install a fix pack to update a stand-alone deployment of Lotus Connections
version 1.0 to version 1.0.1.
Before you can begin this procedure, install the update installer. See Using the Lotus Connections update
installer for more details.
To update a stand-alone deployment of Lotus Connections version 1.0 to version 1.0.1, complete the
following steps:
1. The update installer does not currently support 24x7 updates; you must apply the updates at a time
when no one is logged into the product. See Bringing down Lotus Connections for maintenance work.
2. Make sure all systems are stopped, and then back up the system files. You can do this by archiving
the WebSphere Application Server root directory.
v Linux:
/opt/IBM/WebSphere/
v Microsoft Windows:
C:\IBM\WebSphere\
Note: When running this command in a UNIX shell, be sure to use the syntax
.(space)./setupCmdLine.sh. If you do not precede the command with the period and space, the
Java environment will not be properly set for the active shell.
7. Use the update installer to install the fix pack. To perform a basic installation, from a command
prompt, enter the following commands (without the carriage returns):
v Linux:
/opt/IBM/WebSphere/LotusConnections/update>
./updateLC.sh -installDir /opt/IBM/WebSphere/LotusConnections
-fixpack -install
-fixpackDir /opt/IBM/WebSphere/LotusConnections/update/fixpacks
-fixpackID LC101_Fixpack -wasPassword <AdminPassword>
v Microsoft Windows:
C:\IBM\WebSphere\LotusConnections\update>
updateLC.bat
-installDir C:\IBM\WebSphere\LotusConnections -fixpack -install
-fixpackDir C:\IBM\WebSphere\LotusConnections\update\fixpacks
-fixpackID LC101_Fixpack -wasPassword <AdminPassword>
where <AdminPassword> is the password associated with the WebSphere Application Server
administrative ID.
See updateLC command for information about additional command options.
8. After applying the updates, use the WebSphere Application Server Integrated Solutions Console or
the wsadmin client to start each server that hosts a Lotus Connections feature.
9. Check to make sure the updates were installed properly. Access each feature by opening a Web
browser and typing the Web address using the following syntax:
<was_server_host_name>:<port_number>/
<feature_name>
You can also check the logs. There is one log created for each feature installed. The files are named
LC101_Fixpack_<feature_name>_install.log and are stored in the following directory:
v Linux:
/opt/IBM/WebSphere/LotusConnections/version/log
v Windows:
C:\IBM\WebSphere\LotusConnections\version\log
10. Click the About link for the feature and look for the build information. It should display a build
number that begins with 1.0.1.
11. Start the IBM HTTP Server if you stopped it or if you added rewrite rules to the httpd.conf file for
the IBM HTTP Server, remove them so that users can once again access the features through the IBM
HTTP Server.
12. Access the features again, this time using their public Web addresses. Click the About links for each
feature to make sure the correct build number is displayed.
13. Validate the security settings for Lotus Connections. Changes you may have made to the settings
could be overwritten by the update. For example, the update enables the All Authenticated role by
default. If you previously disabled it, you must explicitly disable it again.
14. If you are using the Profiles feature, you must update the Tivoli Directory Integrator support files.
See Updating Profiles feature data.
Related tasks
“Lotus Connections version 1.0.1” on page 114
Use the update installer to update Lotus Connections version 1.0 to Lotus Connections version 1.0.1.
“Bringing down Lotus Connections for maintenance work” on page 115
Before you bring down Lotus Connections to apply feature updates, you must let your users know
about the planned maintenance work.
“Using the Lotus Connections update installer” on page 109
Use the update installer to install updates to Lotus Connections.
“Updating Profiles feature data” on page 122
When you install the Profiles feature as part of the Lotus Connections product, you must also install a
set of files that support the interaction between Profiles and the Tivoli Directory Integrator, which is a
product that initially populates the Profiles database repository from a source LDAP system, and
keeps the database up-to-date as LDAP changes are made. If you decide to update the Profiles feature,
you must also update the supporting files for Tivoli Directory Integrator.
Related reference
“updateLC command” on page 110
The updateLC command can install or uninstall interim or cumulative fixes or fix packs to Lotus
Connections and provide information about the update state of applied interim or cumulative fixes or
fix packs.
Before completing this procedure, you must download the update installer. See Using the Lotus
Connections update installer for more details.
You must install the update on the servers in the following order:
v Install the update on the WebSphere Application Server installation that represents the primary
member of a cluster.
v Use the Deployment Manager to synchronize the primary member with all the secondary members of
that cluster.
v Run the update on each secondary member system (that is not also a primary member). This step is
required because there are some files that need to be updated that the Deployment Manager cannot
edit; you must run the update directly on the secondary member servers to be sure that those files are
updated.
If the primary cluster members for the features are hosted on different systems, this process can become
confusing, so it is best to write down a diagram of your configuration and plan the order of operations.
Note: After updating the product, you will have run the update installer once and only once on each
WebSphere Application Server installation.
When you update Lotus Connections, you update the primary member of a cluster first. Before you
perform the update, determine which systems in your deployment host primary members and which
host secondary members. See Planning a network deployment update for more details.
To update a network deployment of Lotus Connections version 1.0 to version 1.0.1, complete the
following steps:
1. The update installer does not currently support 24x7 updates; you must apply the updates at a time
when no one is logged into the product. See Bringing down Lotus Connections for maintenance work.
2. Make sure all systems are stopped, and then back up the system files. You can do this by archiving
the WebSphere Application Server root directory.
v Linux:
/opt/IBM/WebSphere/
v Microsoft Windows:
C:\IBM\WebSphere\
3. Create the following directory if it does not already exist; you will use it to store the update fix pack.
v Linux:
/opt/IBM/WebSphere/LotusConnections/update/fixpacks
v Microsoft Windows:
C:\IBM\WebSphere\LotusConnections\update\fixpacks
4. Download the fix pack file named 1.0.1.0-LC-Multi-FP00001.zip from the IBM Fix Central Web site.
To do so, go to the following Web page:
http://www.ibm.com/eserver/support/fixes/
Select the product family Lotus, and product name Lotus Connections, and then search by the Fix
ID 1.0.1.0-LC-Multi-FP00001.
5. Save the file to a temporary directory, and then extract its contents to add the following directories
to the temporary directory:
FP00001/lc101-ptf
Copy the LC101_Fixpack.jar file from the lc101-ptf directory to the fixpacks directory.
6. Start each server that hosts a Lotus Connections feature using the WebSphere Application Server
Integrated Solutions Console for the Deployment Manager system.
7. Check the Deployment Manager to make sure that Automatic synchronization is selected for all
nodes. If it is not on, turn it on. See Synchronizing updated nodes.
8. Install the update on the WebSphere Application Server installation that represents the primary
member of the cluster by completing the following steps:
a. Refer to the list you compiled of primary and secondary cluster members, and then use the
Deployment Manager to turn off both automatic and startup synchronization for the secondary
nodes. See Synchronizing updated nodes for more details.
b. If you have not done so already, set up the Java environment for the update installer by opening
a command prompt, changing to the bin directory of the WebSphere Application Server that is
associated with Lotus Connections, and then entering the following command:
v Linux:
source setupCmdLine.sh
v Microsoft Windows:
setupCmdLine.bat
v UNIX:
.(space)./setupCmdLine.sh
Note: When running this command in a UNIX shell, be sure to use the syntax
.(space)./setupCmdLine.sh. If you do not precede the command with the period and space, the
Java environment will not be properly set for the active shell.
where the <port_number> is the port number on the WebSphere Application Server that the feature
is available from. Refer to the WebSphere Application Server configuration file, named
serverindex.xml, for the node to find port number assignments. The following Web address opens
the Activities feature directly from the WebSphere Application Server:
http://appserver.acme.com:9080/activities
You can also check the logs. There is one log created for each feature installed. The files are named
LC101_Fixpack_<feature_name>_install.log and are stored in the following directory:
You can enable the following types of synchronization from the Deployment Manager:
v Automatic synchronization – Updates occur on a schedule. This type of synchronization is on by
default in network deployments
v Startup synchronization – Updates occur each time the server is started.
To enable and disable synchronization when installing updates, complete the following steps:
1. Open the WebSphere Application Server Integrated Solutions Console for the Deployment Manager
system, and then click System Administration → Node agents.
2. Click the nodeagent link for the node for which you are enabling or disabling synchronization.
3. In the Additional Properties section, click File synchronization service.
4. Perform one of the following actions:
v To turn on synchronization, select the Automatic synchronization and Startup synchronization
check boxes.
v To turn off synchronization, deselect the Automatic synchronization and Startup synchronization
check boxes.
To perform a full synchronization, which copies an update applied to the primary cluster member
application to all secondary cluster members associated with it, complete these steps:
v Open the WebSphere Application Server Integrated Solutions Console for the Deployment Manager
system, and then click System Administration → Nodes.
v Select the check boxes for the secondary nodes, and then click the Full Resynchronize button.
Only perform this procedure if you installed a previous version of the Profiles feature.
Note: You must extract the contents to the parent directory because during the extraction a TDI
directory is created. The extracted TDI directory replaces the existing TDI directory on the system.
v Linux: tdisol.tar
v Microsoft Windows: tdisol.zip
b. Copy the files you saved to the savev1 directory back into the TDI directory.
c. Using a text editor, open the profiles_tdi.properties from the TDI directory, and add the following
properties to it:
v source_ldap_compute_function_for_givenName=
v source_ldap_compute_function_for_sn=
v sync_updates_show_summary_only=true
Save and close the file.
d. Linux only: Execute the following commands on the TDI directory:
chmod +x netstore
chmod +x *.sh
7. Some of the files that are commonly modified by users were updated in version 1.0.1. If you replaced
any of the updated versions of the following files with the files you saved to the savev1 directory,
make the following edits by opening the files with a text editor and changing the specified values:
v map_dbrepos_from_source.properties
The default setting for PROF_SECRETARY_UID has been changed from null to the following:
PROF_SECRETARY_UID=$secretary_uid
where $secretary_uid specifies to do a lookup of the UID using the DN value in the secretary field.
v validate_dbrepos_fields.properties
The default setting for PROF_MAIL has been changed from 64 to the following:
PROF_MAIL=(x != null) && (x.length() > 0) && (x.length() <= 64)
This new formula indicates that a value for this property is required.
Related tasks
“Updating a network deployment” on page 118
Use the update installer to install a fix pack that updates Lotus Connections version 1.0 to version
1.0.1 in a network deployment.
“Updating a stand-alone server” on page 115
Use the update installer to install a fix pack to update a stand-alone deployment of Lotus Connections
version 1.0 to version 1.0.1.
Uninstalling updates
You must uninstall fixes and fix packs in the reverse order from that used to install them. For example, if
you installed fix 1, fix 2, and fix 3 and want to remove fix 2, you must uninstall fix 3 before you can
uninstall fix 2.
If you are planning to uninstall a fix because you ran into a problem with the installation and want to
start over, you may not need to uninstall the fix. If you zipped up the system files before you began the
installation, you can instead revert back to the files you backed up, and start again.
You must have the Lotus Connections update installer installed before you can perform this procedure.
See Using the Lotus Connections update installer.
This topic describes the steps to install an ifix only; it does not include information about how to prepare
the production environment before applying the fix nor does it identify things to consider if you are
installing the fix to a network deployment of Lotus Connections. See the Lotus Connections version 1.0.1
section for more detailed information about the preinstallation and post-installation steps involved in
applying a fix to the product.
Note: If a fixes subdirectory does not exist in the update directory, create one.
v Linux:
/opt/IBM/WebSphere/LotusConnections/update/fixes
v Microsoft Windows:
C:\IBM\WebSphere\LotusConnections\update\fixes
7. Use the update installer to install the fix. To perform a basic installation, from a command prompt,
enter the following commands (without the carriage returns):
v Linux:
Note: If you do not know the APAR number of the fix, look in the readme.txt file that is downloaded
to the temporary directory with the fix.
See updateLC command for information about additional command options.
Related tasks
“Using the Lotus Connections update installer” on page 109
Use the update installer to install updates to Lotus Connections.
“Lotus Connections version 1.0.1” on page 114
Use the update installer to update Lotus Connections version 1.0 to Lotus Connections version 1.0.1.
Note: If you plan to reinstall Lotus Connections and you would like to retain some of the preference
settings you configured for the previous installation, delete all of the files and subdirectories in the
LotusConnections directory except the lastSessionDefaults.properties file, which is stored in this
directory.
7. Activities only: Delete the following items if no other nodes use them:
v All operating systems:
– If you do not want to keep the statistical data that was collected about the performance of the
Activities feature, delete the statistics directory that you created during the Activities
installation.
By default, the statistics directory is stored in the following subdirectory:
IBM/LotusConnections/Data/Activities/
<profile_name>_<server_name>/statistics
– If you are using a file system directory store and do not want to keep the data that users have
added to Activities during previous sessions of the Activities feature, delete the contentstore
directory that you created during the Activities installation.
By default, the contentstore directory is stored in the following subdirectory:
IBM/LotusConnections/Data/Activities/<profile_name>/
contentstore
v Linux:
– From /opt/IBM/WebSphere/AppServer/lib/ext, delete the files commons-codec-1.3-minus-mp.jar
and oatai.jar.
Note: If you edited the communities.policy file to include values for other applications that you
use or if a policy file already existed on the system when you installed Communities and you
added the communities policy file values to it, do not delete the policy file. Instead, remove any
Communities-specific values from the policy file and continue to reference it in the
java.security.auth.policy property.
a. From the WebSphere Application Server Integrated Solutions Console, select Application servers
→ <server_name>, and then under Server infrastructure, expand Java Process Management to
find Process Definition.
b. Select Process Definition → Java Virtual Machine → Custom Properties.
c. Select the check box next to java.security.auth.policy and then click Delete. Save your changes.
d. Stop and start WebSphere Application Server.
e. Delete the Communities.policy file from the following directory:
v Linux:
opt/IBM/WebSphere/AppServer/profiles/<profile_name>/
properties
v Windows:
where <your_password> is the password associated with your SYSDBA account. LSCONN is the
name of the database if you created one from scratch; replace this with the name of your
database if you are using an existing database to store the Lotus Connections tables.
c. Type one of the following sets of commands to drop the associated feature database tables:
Note: Ignore the forced carriage returns; each line should end in a semicolon.
v Activities:
DROP USER OAUSER CASCADE;
DROP USER ACTIVITIES CASCADE;
DROP ROLE OAUSER_ROLE;
DROP TABLESPACE OAREGTABSPACE INCLUDING CONTENTS AND DATAFILES
CASCADE CONSTRAINTS;
DROP TABLESPACE OAINDEXTABSPACE INCLUDING CONTENTS AND DATAFILES
CASCADE CONSTRAINTS;
v Blogs:
DROP USER BLOGS CASCADE;
DROP TABLESPACE BLOGSREGTABSPACE INCLUDING CONTENTS AND DATAFILES
CASCADE CONSTRAINTS;
DROP TABLESPACE BLOGSINDEXTABSPACE INCLUDING CONTENTS AND
DATAFILES CASCADE CONSTRAINTS;
v Communities:
DROP USER SNCOMM CASCADE;
DROP TABLESPACE SNCOMMREGTABSPACE INCLUDING CONTENTS AND
DATAFILES CASCADE CONSTRAINTS;
DROP TABLESPACE SNCOMMINDEXTABSPACE INCLUDING CONTENTS AND
DATAFILES CASCADE CONSTRAINTS;
DROP ROLE SNCOMM_ROLE;
You must create a response file during a standard installation before you can use that file to perform a
silent installation.
InstallResponse.txt file
When you install a Lotus Connections feature, you can record your selections in a response file. After the
initial installation, you can perform similar installations by starting the installer from the command line
and passing the response file in as an argument. The installer uses the values in the response file rather
than requiring you to interact with it.
During the installation, the path and name of the default file are displayed:
C:\DOCUME~1\db2admin\LOCALS~1\Temp\1\InstallResponse.txt
The Installing a Lotus Connections feature topic instructs you to edit the default name of the response file to
identify which feature installation instructions it contains. If you do not change the file name, several
common properties are overwritten if you install a subsequent feature to the same machine.
Whether or not you rename it, the response file collects a specific set of property values. Those values are
described in the following tables.
Related tasks
“Creating a cluster” on page 92
Create a cluster to add redundancy to the deployment and achieve better performance.
GSK_ERROR
If you see a 500 error when using HTTPS over the IBM HTTP Server to get to an application, HTTPS
might not be configured correctly with the WebSphere Application Server plug-in. If this error occurs,
check both your IBM HTTP Server and WebSphere Application Server logs to see if there is a
GSK_ERROR. If the logs do not contain errors, examine the plug-in logs located in the following
directory:
C:\ibm\HTTPServer\Plugins\logs\webserver1\http_plugin.log
The following error is generated if the WebSphere Application Server SSL certificate is not trusted by the
WebSphere Application Server plug-in configured for the IBM HTTP Server:
ERROR: lib_stream: openStream: Failed in r_gsk_secure_soc_init:
GSK_ERROR_BAD_CERT(gsk rc = 414)
To fix this error, follow the instructions in the topic, Configuring the IBM HTTP Server for SSL.
A faulty JDBC driver or data source can prevent you from accessing a Lotus Connection feature. Here’s
how to test the connections and correct problems.
If you encounter a HTTP 500 - Internal Server Error when attempting to access a Lotus Connections
feature for the first time, make sure that you are using the Web address. If the Web address is correct, test
the validity of your database connection, by performing the following steps from the WebSphere
Application Server Integrated Solutions Console:
v Verify the database connections by selecting Resources → JDBC → JDBC Providers →
<feature_name>JDBC → Data Source.
v Select a Lotus Connections data source, and then click Test Connection.
v If the connections fails, use one of the following approaches to locate and resolve the problem:
– Data source problems – Select the data source and review the database server values to ensure they
are correct. Check the port number, server name, and database name. If you discover an error,
change the value, click OK and Save, and then retest the database connection.
– JDBC driver path problems – Check to ensure the path assigned to a feature’s JDBC driver is correct.
Select Environment → WebSphereVariables, and then review the path for the JDBC driver variable
to make sure it is correct. The driver path is named using the syntax:
<FEATURE>_JDBC_DRIVER_HOME. Note that on Linux this path is case-sensitive. If the path is
incorrect, change it, and then click OK and Save.
– JAAS credential problems – Check the JAAS J2C authentication settings by selecting Resources →
JDBC → JDBC Providers → DogearJDBC → datasource → <Feature_name> → JAAS-J2C authentication
data. Select <Feature_name> JAASAauth, and then view the user ID and password credentials you
entered during installation to verify that they are correct. If they are not correct, make any required
changes.
where:
v Feature prefix – Identifies the application that wrote the message. The following prefixes are used to
identify Lotus Connections features and components:
Table 16. Error message prefixes
Lotus Connections feature or component Prefix
Activities CLFRA
Note: The Quartz Scheduler, a component of Activities
does not use the Activities prefix, but its messages do
include the string org.quartz.
Blogs Blogs messages do not use a prefix.
Communities CLFRM
Dogear CLFRL
Lotus Connections Configuration CLFRO
Lotus Connections Installer EJPIC
Lotus Connections Multi-Service Portlet CLFNF
Profiles CLFRN
Waltz (A common directory service for the Lotus CLFRK
Connections features)
v Error code – A 4-digit code assigned to the error message to identify it. Code numbers make it easier to
search for information about the message. See Error messages to see a list of the error codes and what
they mean.
v Message level code – Identifies the level of the message written to the log. The following levels are
supported:
Table 17. Message level codes
Message level code Message level
I INFO
E ERROR
A AUDIT
W WARN
For example:
CLFRA0299I
Error messages
Use the codes included in the error messages generated by IBM Lotus Connections to identify problems
and find their solutions.
IBM may not offer the products, services, or features discussed in this document in other countries.
Consult your local IBM representative for information on the products and services currently available in
your area. Any reference to an IBM product, program, or service is not intended to state or imply that
only that IBM product, program, or service may be used. Any functionally equivalent product, program,
or service that does not infringe any IBM intellectual property right may be used instead. However, it is
the user’s responsibility to evaluate and verify the operation of any non-IBM product, program, or
service.
IBM may have patents or pending patent applications covering subject matter described in this
document. The furnishing of this document does not grant you any license to these patents. You can send
license inquiries, in writing, to:
IBM Director of Licensing IBM Corporation North Castle Drive Armonk, NY 10504-1785 U.S.A.
For license inquiries regarding double-byte (DBCS) information, contact the IBM Intellectual Property
Department in your country or send inquiries, in writing, to:IBM World Trade Asia Corporation Licensing
2-31 Roppongi 3-chome, Minato-ku Tokyo 106-0032, Japan
The following paragraph does not apply to the United Kingdom or any other country where such
provisions are inconsistent with local law: INTERNATIONAL BUSINESS MACHINES CORPORATION
PROVIDES THIS PUBLICATION ″AS IS″ WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR
IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
NON-INFRINGEMENT, MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Some
states do not allow disclaimer of express or implied warranties in certain transactions, therefore, this
statement may not apply to you.
This information could include technical inaccuracies or typographical errors. Changes are periodically
made to the information herein; these changes will be incorporated in new editions of the publication.
IBM may make improvements and/or changes in the product(s) and/or the program(s) described in this
publication at any time without notice.
Any references in this information to non-IBM Web sites are provided for convenience only and do not in
any manner serve as an endorsement of those Web sites. The materials at those Web sites are not part of
the materials for this IBM product and use of those Web sites is at your own risk.
IBM may use or distribute any of the information you supply in any way it believes appropriate without
incurring any obligation to you.
Licensees of this program who wish to have information about it for the purpose of enabling: (i) the
exchange of information between independently created programs and other programs (including this
one) and (ii) the mutual use of the information which has been exchanged, should contact:
Lotus Software
IBM Software Group
One Rogers Street
Cambridge, MA 02142 USA
Such information may be available, subject to appropriate terms and conditions, including in some cases,
payment of a fee.
Any performance data contained herein was determined in a controlled environment. Therefore, the
results obtained in other operating environments may vary significantly. Some measurements may have
been made on development-level systems and there is no guarantee that these measurements will be the
same on generally available systems. Furthermore, some measurements may have been estimated through
extrapolation. Actual results may vary. Users of this document should verify the applicable data for their
specific environment.
Information concerning non-IBM products was obtained from the suppliers of those products, their
published announcements or other publicly available sources. IBM has not tested those products and
cannot confirm the accuracy of performance, compatibility or any other claims related to non-IBM
products. Questions on the capabilities of non-IBM products should be addressed to the suppliers of
those products.
All statements regarding IBM’s future direction or intent are subject to change or withdrawal without
notice, and represent goals and objectives only.
This information contains examples of data and reports used in daily business operations. To illustrate
them as completely as possible, the examples include the names of individuals, companies, brands, and
products. All of these names are fictitious and any similarity to the names and addresses used by an
actual business enterprise is entirely coincidental.
COPYRIGHT LICENSE:
This information contains sample application programs in source language, which illustrate programming
techniques on various operating platforms. You may copy, modify, and distribute these sample programs
in any form without payment to IBM, for the purposes of developing, using, marketing or distributing
application programs conforming to the application programming interface for the operating platform for
which the sample programs are written. These examples have not been thoroughly tested under all
conditions. IBM, therefore, cannot guarantee or imply reliability, serviceability, or function of these
programs.
Trademarks
The following terms are trademarks of International Business Machines Corporation in the United States,
other countries, or both:
400
Cloudscape
DB2
DB2 Universal Database
Domino
IBM
iSeries
Lotus
Lotus Notes
Notes
Sametime
the IBM logo
Tivoli
WebSphere
z/OS
Adobe, Acrobat, Portable Document Format (PDF), PostScript, and all Adobe-based trademarks are either
registered trademarks or trademarks of Adobe Systems Incorporated in the United States, other countries,
or both.
Intel, Intel logo, Intel Inside, Intel Inside logo, Intel Centrino, Intel Centrino logo, Celeron, Intel Xeon,
Intel SpeedStep, Itanium, and Pentium are trademarks or registered trademarks of Intel Corporation or its
subsidiaries in the United States and other countries.
ITIL is a registered trademark, and a registered community trademark of the Office of Government
Commerce, and is registered in the U.S. Patent and Trademark Office
Microsoft, Windows, Windows NT, and the Windows logo are trademarks of Microsoft Corporation in the
United States, other countries, or both.
Java and all Java-based trademarks are trademarks of Sun Microsystems, Inc. in the United States, other
countries, or both.
Linux is a registered trademark of Linus Torvalds in the United States, other countries, or both.
UNIX is a registered trademark of The Open Group in the United States and other countries.
Other company, product, or service names may be trademarks or service marks of others.
Notices 199