IBM Connections introduces social to the enterprise, allowing companies to be more proactive and efficient by providing a solid foundation on which to exchange ideas, build communities, promote the participation of employees, know the latest company updates, and more. The installation process for IBM Connections 3.0.1 can be quite complex because of the different scenarios available. Therefore, this article covers not only basic installation but also the architecture of the product and the final solution so as to provide the bigger picture of all the possible deployment options.
Installing IBM Connections requires a solid understanding of all of its underlying components and the way they work and communicate with each other.
As you can see in Figure 1, all the connections services and nodes are within one cell, which the Deployment Manager manages. Different server instances are deployed to different nodes that are configured to work together in clusters for features. This diagram shows three nodes. Typically, each node represents one machine. Node A and Node B each have two instances, and each server instance has two features. Node A and Node B are identical to each other in terms of applications and server instance separation. Cluster A logically groups server A from Node A and server C from Node B to act together. You can provide any name you like to your cluster.
Figure 1. The WebSphere architecture
You can use any of three deployment options when installing IBM Connections 3.0.1: small, medium, and large.
This option installs all applications in a single cluster on a single node and so is the simplest deployment (see Figure 2). However, it has limited flexibility and does not allow you to scale up individual applications. For each node within the cluster, all applications run within a single JVM.
Figure 2. Small deployment architecture: one node
Figure 3 shows one of the simplest deployments of IBM Connections, where each component is running on its own machine. This option does not provide any workload or disaster recovery, but it does provide simplicity to small organizations looking to run IBM Connections.
Figure 3. A simple small deployment of IBM Connections
This option installs a subset of applications in separate clusters (see Figure 4). IBM Connections 3.0.1 provides three predefined cluster names shared among all applications. This option is used to distribute applications according to usage expectations and allows you to maximize the use of available hardware and system resources to suit specific needs.
Figure 4. Medium deployment architecture
In Figure 5, a two-node cluster is used for IBM Connections, with two HTTP servers in front handling all requests coming from the edge server. This approach also shows you how you can use IBM Tivoli® Directory Integrator (TDI) to merge data coming from multiple sources into the Lightweight Directory Access Protocol (LDAP) server and IBM DB2® database.
Figure 5. A typical medium deployment of IBM Connections
This option installs each application in its own cluster, and IBM Connections 3.0.1 provides a predefined cluster name for each application (see Figure 6). This option provides the best performance in terms of scalability and availability options, but it also requires more system resources.
Figure 6. Large architecture, with multiple nodes and clusters
With a basic understanding of all the deployment options, you reach a decision point regarding all the additional servers and components that IBM Connections uses. Figure 7 shows a complex environment with multiple nodes, HTTP and proxy servers, and database clusters for each feature of IBM Connections (blogs, home pages, and more). Large organizations with strict service level agreements should consider deployments that include high availability and disaster recovery as well as sufficient resources to support the workload.
Figure 7. A large deployment of IBM Connections
Planning and installation
Installing IBM Connections requires the prior installation and configuration of several components. Before starting, make sure that all required software is available: The Resources section provides a detailed list of all components (and their product number) that you should download via either IBM Passport Advantage or IBM PartnerWorld.
When installing IBM WebSphere Application Server, you have several options,
as shown in Figure 8. IBM Connections 3.0.1 requires a
deployment manager, so you must choose Cell (deployment manager
and managed node). This option installs the Deployment
dmgr) and a managed node, with a default application
server profile called server1. IBM Connections does not use the
newly created server1, however; instead, the managed node will be
used as the destination for the new server.
Figure 8. WebSphere Application Server environments
If you are installing DB2, you must register the proper DB2 license to use
the product. When you buy IBM Connections, IBM provides a restricted
license that allows you to use DB2 for IBM Connections. You can download
this license (
db2ese_o.lic) from IBM PartnerWorld or IBM
Passport Advantage by looking for Product Number CZ381ML. See Resource for links to additional information on
DB2 license management.
After installing DB2, you must create a dedicated user named LCUSER and add it to the DB2users group. IBM Connections and WebSphere Application Server use this user to handle all connectivity with the DB2 databases.
In addition to the WebSphere Application Server environment, the following products must be installed:
- IBM Lotus Domino® 8.5.3 as the LDAP server
- WebSphere Application Server Network Deployment 22.214.171.124
- WebSphere Application Server 7.0 Fix Pack 19
- WebSphere Application Server 7.0 Plug-in Fix Pack 19
- IBM HTTP Server 126.96.36.199
- IBM HTTP Server 7.0 Fix Pack 19
- IBM DB2 Enterprise Server Edition V9.7 for Windows
- IBM Tivoli Directory Integrator V7.0 for Windows
- IBM Tivoli Directory Integrator V7.0 Fix Pack 5 for Windows
For more information on how to install and configure these products and other supported database and LDAP servers, see Resources.
Creating the IBM Connections databases
Before installing IBM Connections, you need to create the required databases and populate the Profiles database (PEOPLEDB). To do so, complete the following steps:
- Copy the IBM Connections Wizards (CZVQ9ML) to the DB2 server, and run
- On the Welcome page, click Next.
- Choose Create, and click Next.
- Select the database type (see Figure 9), the
location of the DB2 server installation, and the name of the DB2
instance to be used, and click Next.
Figure 9. Select the database type
- Select all the databases, and click Create.
- Review the task summary, and click Next.
- After all databases have been created, click Finish.
Populating the Profiles database
Now that all the databases have been created, you must populate PEOPLEDB with user information from the LDAP server. To do so, complete the following steps:
- From the IBM Connections Wizard folder, run
- On the Welcome screen, click Next.
- Enter the location of TDI (see Figure 10), and
Figure 10. Enter the location of TDI
- Select DB2 as the Profiles database type.
- Enter all the required information to establish a session with the
Profiles database, as shown in Figure 11.
Figure 11. Connect to the Profiles database
- Enter the hostname and port for the LDAP server, and click Next.
- Enter the bind credentials to access the LDAP server, and click Next.
- Enter the LDAP search filters based on your own LDAP server
configuration, and click Next.
Note: Using a tool like Softerra LDAP Browser might help in understanding your LDAP environment in case your organization does not have an LDAP administrator.
- Click Next.
- Review the configuration summary, and click Configure.
- Review the results, and click Finish to complete this wizard.
Configure the LDAP server with WebSphere
IBM Connections relies on WebSphere Application Server's security to handle the LDAP configuration and connectivity. This section show you how to configure WebSphere Application Server to connect to an existing LDAP server for search and authentication within IBM Connections.
To configure the LDAP server, complete the following steps:
- Access the Integrated Solutions Console (ISC), and click Security > Global Security.
- Select Federated Repositories, and click Configure.
- Click Add Repository.
- Enter the required information to connect to your LDAP server (see Figure 12), and click OK.
Figure 12. Set up a new repository
- Save the changes to the master configuration.
- Enter the distinguished name of the base entry that will identify this
set of entries (see Figure 13), and click
Figure 13. Provide the distinguished name for the base entry
- Click OK to save the changes.
- Enable application security (see Figure 14), and
click Apply to save the changes.
Figure 14. Enable application security
- Restart the Deployment Manager for the changes to take effect.
If you have never worked with the Deployment Manager before, the following are the commands to stop the Deployment Manager:
C:\Program Files\IBM\WebSphere\AppServer\profiles\Dmgr01\bin>stopServer dmgr -username wasadmin -password password
The following are the commnads to start the Deployment Manager:
C:\Program Files\IBM\WebSphere\AppServer\profiles\Dmgr01\bin>startServer dmgr
Installing IBM Connections
To install IBM Connections, complete the following steps:
- Access the IBM Connections installer (CZVP9ML) folder, and run
The IBM Connections installation process is controlled by the IBM Installation Manager, which must be installed first.
- Select both the IBM Installation Manager and IBM Connections, and click Next.
- Accept the terms in the license agreement, and click Next.
- Enter the location for the Shared Resources Directory and the Installation Manager Directory, and click Next.
- Enter the installation directory for IBM Connections, and click Next.
- Select all the features to install, and click Next.
- Select the location of WebSphere Application Server, and select the Deployment Manager profile.
- Enter the hostname of the machine on which you are performing the
installation and the credential information to connect to the
Deployment Manager (see Figure 15).
Doing so adds the new node to the Deployment Manager.
Figure 15. Deployment Manager settings
- Click Next.
- Select Small Deployment, and enter the cluster name
(see Figure 16). Click Next.
Figure 16. Choosing deploying options
- Copy the
db2jcc_license_cu.jarfiles from the DB2 server to the machine on which you are installing IBM Connections.
- Enter the required information for the connection to the DB2 databases
(see Figure 17).
Under JDBC driver location, select the location to which you copied the two
Figure 17. DB2 settings
- Enter the location for the shared and local content stores (see Figure 18).
Figure 18. Location of the shared and local content stores
- Enter the appropriate settings for your messaging environment.
You can choose not to enable notifications during the installation process and get back to it later.
- Click Next.
- Review the packages to be installed, and then click Install.
- After IBM Connections has been installed, click Finish to close the wizard.
Configure IBM HTTP Server
To configure IBM HTTP Server, complete the following steps:
- Log in to the WebSphere Application Server ISC on the Deployment Manager, and click System administration > Nodes > Add Node.
- Select Unmanaged node, and click Next.
- Enter the name and hostname for the new instance, and click OK to save the changes to the master configuration.
- Click Servers > Server Types > Web servers, and click New.
- Select the unmanaged node you created earlier, enter the server name, and select IBM HTTP Server as the type. Click Next.
- Select the default web server template, and click Next.
- Enter the information requested based on the IBM HTTP Server
installation (see Figure 19). Click
Figure 19. IBM HTTP Server settings
- Click Finish to save the changes to the master configuration.
- Click System Administration > Nodes, and synchronize the IBM Connections node.
- Click Servers > Server Types > Web servers, and generate and propagate the plug-in for the web server you just created.
- Click Servers > Server Types > webserver1 > Plug-in
properties, and click Copy to Web Server key
store directory (see Figure 20).
Note: If the
plugin-key.kdbfile is on a different system from the IBM HTTP Server system, copy it manually from the WebSphere Application Server system.
Figure 20. Copying the Web Server plug-in
- Restart IBM HTTP Server.
At this point, IBM Connections should be accessible. Note that IBM Connections uses HTTP Secure Sockets Layer (SSL) by default. For a pilot, you should be able to install the self-signed SSL certificate provided with the installation and avoid the security warnings. For additional information on the IBM HTTP Server and SSL configuration along with WebSphere Application Server and SSL certificates, see Resources.
Now that you have installed IBM Connections, you must configure your landing page for the Blogs feature and perform additional tasks, like assign an administrator for each feature for further administration. In addition, you must update web addresses. See Resources for links to information on these and other tasks.
Important considerations when deploying IBM Connections
Every software implementation must perform well enough and be as fast as possible for users to be able to enjoy the full experience. The following sections provide important topics that you must consider when deploying IBM Connections.
Java Virtual Machine
Although multiple components can run in a single JVM, doing so is not recommended for non-pilot deployments. It is easier to run each component in a separate JVM than to decide which component is to run on which JVM.
Running multiple nodes is required for failover but is not necessary for capacity, except in deployments with more than 100,000 users. If your system is 32 bit, remember that 32-bit JVMs can support a heap size of 1.5GB. Single-component benchmarks show that 1GB is usually sufficient to use all CPU resources and drive enough database load to saturate disks.
Also, for small and medium deployments, review the maximum heap size. IBM Installation Manager sets the values shown in Table 1 for such deployments.
Table 1. Default maximum heap size
|System||Maximum heap size|
Adjust the current values of the heap size up or down to suit the needs of your deployment and your hardware capabilities.
Multiple servers per node
The limit for running multiple WebSphere Application Server instances per node is based on system memory. Always make sure you have enough physical memory to run all JVMs at their maximum size, and avoid paging; 8GB of system memory will be usable, but 12GB or more is better.
It is optimal to run an instance per component rather than allocate all components into two or three instances. You cannot scale with all components in a single instance.
Running multiple database servers is not necessary, except in particularly large deployments. Database high availability and failover are supported if the process is transparent to Java Database Connectivity (JDBC), but you must beware of data replication lag time. If you use a 32-bit system, remember that the same rules for WebSphere Application Server instances are valid: You are limited to 2GB of memory per instance.
Shared file system
In IBM Connections 3.0.x, there is a requirement to have a shared file system that needs to be accessible to all WebSphere nodes. For a shared file system, make sure of the following:
- Linux®/UNIX®: You must have Network File System v4.
- Windows: Make sure that the bandwidth to the share is sufficient, and possibly consider a dedicated file server for deployments larger than 100,000 users.
IBM Connections 3.0.1 can run without a file repository, but searches, downloads, and updates with file content will fail. Consider a General Parallel File System, instead. Also, in medium or large deployments, configure the Windows services for IBM Connections to start as a valid network account, not as LocalSystemAccount. Doing so allows the multiple nodes involved in the IBM Connection deployment to access the shared file systems on the network.
An array provides fault tolerance from disk errors or failures and continues to operate as long as at least one drive in the mirrored set is functioning. With appropriate operating system support, there can be increased read performance and only a minimal write performance reduction.
In redundant array of independent disks (RAID) 2 (bit-level striping with dedicated Hamming-code parity), all disk spindle rotation is synchronized, and data is striped such that each sequential bit is on a different disk. Hamming-code parity is calculated across corresponding bits on disks and stored on one or more parity disks. Extremely high data transfer rates are possible. In RAID 3 (byte-level striping with dedicated parity), all disk spindle rotation is synchronized, and data is striped such that each sequential byte is on a different disk. Parity is calculated across corresponding bytes on disks and stored on a dedicated parity disk. Very high data transfer rates are possible.
IBM Connections 3.0.1 is database driven, and there can be significant disk activity on the database. IBM Connections 3.0.1 is also file driven: Activities, Wikis, Files, and Bookmarks all store data on the file system, and all components use disk-based full-text indexing. Consider a storage area network for deployments larger than 10,000 users or 100GB, with separate arrays and logical unit numbers for database and file store.
This article covered a significant portion of the installation process, plus additional considerations you need to be aware of when installing IBM Connections. After installing IBM Connections for the first time, you should have a considerable understanding of all components required and how they interact. As you continue working with IBM Connections, you will get to fully understand all the deployment options and how the tool can be installed and configured to achieve more complex requirements. Other articles in this series also cover the customization process of IBM Connections, including adding new fields to Profiles and applying the corporate look and feel.
- Check out the IBM Connections page.
- Find detailed system requirements for IBM Connections.
- Learn more about DB2 license management.
- Learn more about WebSphere Application Server Network Deployment 188.8.131.52.
- Read more about installing IBM HTTP Server 184.108.40.206.
- Be sure to read Updating web addresses in IBM HTTP Server for information about updating the web addresses that IBM HTTP Server uses to access IBM Connections applications.
- Read more about installing IBM DB2 Enterprise Server Edition V9.7 for Windows.
- Read more about installing IBM Tivoli Directory Integrator V7.0 for Windows.
- Find technical information at the IBM Connections product documentation page.
- Try IBM Connections on the Lotus Greenhouse.
- Learn more about configuring IBM HTTP Server for SSL.
- Check out the WebSphere Application Server V7.0 Security Guide.
- Learn how to assign an administrator to the Home Page and Blogs features.
- Learn more about configuring the Blogs home page.
Get products and technologies
- Download IBM Connections 3.0.1.
- Download and install WebSphere Application Server 7.0 Fix Pack 19.
- Download and install WebSphere Application Server 7.0 Plug-in Fix Pack 19.
- Download and install IBM HTTP Server 7.0 Fix Pack 19.
- Download and install IBM Tivoli Directory Integrator V7.0 Fix Pack 5.
- Participate in the IBM Connections forum.
- Subscribe to the IBM Social Software blog.
- Get involved in the My developerWorks community. Connect with other developerWorks users while exploring the developer-driven blogs, forums, groups, and wikis.
Dig deeper into IBM collaboration and social software on developerWorks
Get samples, articles, product docs, and community resources to help build, deploy, and manage your cloud apps.
Keep up with the best and latest technical info to help you tackle your development challenges.
Software development in the cloud. Register today to create a project.
Evaluate IBM software and solutions, and transform challenges into opportunities.