Home


Overview - IBM Connections v4

 

+

Search Tips   |   Advanced Search


  1. Overview
  2. What's new in IBM Connections 4?
  3. Supported languages
  4. Administrators: Deploying a preview guide to your users
  5. Accessibility
  6. Plan
  7. Install
  8. Update and migrating


Overview

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


What's new in IBM Connections 4?

IBM Connections:

Activities:

Blogs:

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

Bookmarks:

The following features are new for Bookmarks:

Communities:

Files:

Forums:

Home page:

Profiles:

Wikis:


What's new in installing?


What's new in administering?

IBM Connections:

Activities:

Blogs:

Bookmarks:

Communities:

Files:

Forums:

Home page:

News:

Profiles: register the applications in the news-config.xml file.

Search:

IBM Connections 4 includes new and enhanced APIs for Search.

Wikis:


What's new in customizing?

If you customized the IBM Connections user interface in a previous release of the product, note that there is no migration path provided for importing your changes into IBM Connections 4. Before upgrading to IBM Connections 4, review and make a note of your existing customizations so that you can verify them post-migration and rework if necessary.


What's new in security?


What's new in mobile?


What's new in developing?

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


What's new in troubleshooting and support?


Supported languages

The IBM Connections user interface is available in multiple languages.


Related tasks

  • Enable users to set a language preference

  • Common configuration properties


    Administrators: Deploying a preview guide to your users

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

    • Overview of several new applications
    • Important changes from the previous release
    • Familiar applications that remain the same
    • Links to product tours, reference cards, and product documentation
    • A few key productivity tips

    You can download the preview guide from the IBM Connections wiki

    There are two files available to you:

    • An Adobe PDF file, ready for emailing, printing, or distributing to your organization.

    • An IBM Symphony. ODT file that can be customized for your organization; for example, you can add contact information for your Help Desk.

      This file includes instructions in blue text for customizing information. Remember to remove these instructions before rolling out the file to your organization.

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


    Accessibility

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

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

    The major accessibility features in this product enable users to do the following tasks:

    • Use assistive technologies, such as screen-reader software and digital speech synthesizer, to hear what is displayed on the screen. Consult the product documentation of the assistive technology for details about using those technologies with this product.

    • Operate specific or equivalent features using only the keyboard.

    • Customize display attributes such as color, contrast, and font size.

    • Magnify what is displayed on the screen.

    The accessibility of IBM Connections is optimized when using a Microsoft Windows XP client, Microsoft Windows Server 2003 or later, FireFox 3.6 or later, and JAWS 12 or later.

    In addition, the documentation was modified to include the following features to aid accessibility:

    • All documentation is available in HTML formats to give the maximum opportunity for users to apply screen-reader software technology.

    • All images in the documentation are provided with alternative text so that users with vision impairments can understand the contents of the images.


    IBM Connections user interface

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

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

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


    Plan

    1. Install, configure, secure, and administer IBM WebSphere Application Server (WAS).

    2. Install IBM Tivoli Directory Server, Microsoft Active Directory, Sun Java. System Directory Server, or IBM Lotus Domino LDAP directory, and then configure WAS to use that LDAP directory with federated repositories.

    3. Create, manage, and drop IBM DB2®, Oracle, or Microsoft SQL Server DBs.

    4. Install IBM HTTP Server, and then configure it to interact with IBM WAS over HTTP and HTTPS.


    Directory path conventions

    Directory variable values

    Directory variable Description Default installation root
    app_server_root IBM WAS installation directory AIX: /usr/IBM/WebSphere/AppServer
    Linux: /opt/IBM/WebSphere/AppServer
    Windows: C:\IBM\WebSphere\AppServer
    profile_root WAS installation directory AIX: /usr/IBM/WebSphere/AppServer/profiles/profile_name
    Linux: /opt/IBM/WebSphere/AppServer/profiles/profile_name
    Windows: C:\IBM\WebSphere\AppServer\profiles\profile_name
    ibm_http_server_root IBM HTTP Server installation directory AIX: /usr/IBM/HTTPServer
    Linux: /opt/IBM/HTTPServer
    Windows: C:\IBM\HTTPServer
    connections_root IBM Connections installation directory AIX or Linux: /opt/IBM/Connections
    Windows: C:\IBM\Connections
    local_data_directory_root Local content stores AIX or Linux: /opt/IBM/Connections/data/local
    Windows: C:\IBM\Connections\data\local
    shared_data_directory_root Shared content stores AIX or Linux: /opt/IBM/Connections/data/shared
    Windows: C:\IBM\Connections\data\shared\
    IM_root IBM Installation Manager installation directory AIX: /opt/IBM/InstallationManager
    Linux: /var/IBM/InstallationManager
    Windows: C:\\IBM\Installation Manager
    shared_resources_root Shared resources directory AIX or Linux: /opt/IBM/SSPShared
    Windows: C:\IBM\SSPShared
    db2_root DB2 DB installation directory AIX or Linux: /usr/IBM/db2/version Linux:
    /opt/ibm/db2/version
    Windows: C:\IBM\SQLLIB\version
    oracle_root Oracle DB installation directory AIX or Linux: /home/oracle/oracle/product/version/db_1
    Windows: C:\oracle\product\version\db_1
    sql_server_root Microsoft SQL Server DB installation directory Windows: C:\Microsoft SQL Server
    Cognos_BI_install_path IBM Cognos BI Server installation directory AIX or Linux: /opt/IBM/Cognos64
    Windows: C:\IBM\Cognos64

    You specify the installation directory in the cognos-setup.properties file during installation.

    Cognos_Transformer_install_path Cognos Transformer installation directory AIX or Linux: /opt/IBM/Cognos
    Windows: C:\IBM\Cognos

    You can specify the installation directory in the cognos-setup.properties file during installation.


    Deployment options

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

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

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

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

    When you are installing IBM Connections, you have three deployment options:

    Small deployment

    Install all IBM Connections applications on a single node in a single cluster. This option is the simplest deployment but has limited flexibility and does not allow individual applications to be scaled up. All the applications run within a single Java Virtual Machine (JVM).

    The diagram depicts a topology with up to 8 servers. If you install the servers on shared systems, you do not need to deploy 8 separate systems.

    Medium deployment

    Install a subset of applications in separate clusters. IBM Connections provides three predefined cluster names shared among all of its applications. For example, Profiles application loads may be higher, and require their own cluster, while other applications could be installed in a different cluster.

    Large deployment

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

    In a multi-node cluster, configure network share directories as shared content stores.

    • For NFS, use NFS v4 because NFS v3 lacks advanced locking capability.

    • For Microsoft SMB, use the UNC file-naming convention...

        \\machine-name\share-name

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

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

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

    For added security when you are planning to run 3rd party OpenSocial gadgets, such as those from iGoogle, configure locked domains. Locked domains are required to isolate these gadgets from access to your intranet and SSO information. The basic configuration of locked domains is as follows:

    • A second top-level domain that is not in your SSO domain.

      For example, if you organization's SSO domain is example.com, you will require a distinct top level domain, such as example-modules.com.

    • A wild card SSL certificate for this domain name.

    No additional server instances are required for the basic configuration.


    IBM Connections system requirements

    Detailed system requirements for IBM Connections web page.


    IBM Connections support statement

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

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


    Worksheet for installing IBM Connections

    Record your installation and configuration data.


    Recording installation data

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


    LDAP server details

    LDAP server details

    LDAP data type Example Details
    LDAP server type and version Lotus Domino 8.5  
    Primary host domino_ldap.example.com  
    Port 389  
    Bind distinguished name cn=lcadmin,ou=People,dc=example,dc=com  
    Bind password    
    Certificate mapping    
    Certificate filter    
    Login attribute mail or uid  


    WAS details

    WAS details

    WAS item Example Details
    WAS version V7.0 fix pack 21  
    Installation location C:\IBM\WebSphere\AppServer  
    Update installer location C:\IBM\WebSphere\UpdateInstaller  
    Administrator ID wsadmin  
    Administrator password    
    WAS URL http://was.example.com:9060/ibm/console  
    WAS secure URL https://was.example.com:9043/ibm/console  
    WAS host    
    HTTP transport port    
    HTTPS transport port    
    SOAP connector port    
    Run application server as a service? (True/False)    


    Database details

    Database server details

    Database item Example Details
    Database type and version Oracle Database 10g Enterprise Edition Release 2 10.2.0.4  
    Database instance or service name    
    Database server host DB.example.com  
    Port DB2=50000
    Oracle=1433
    MS SQL Server=1523
     
    JDBC driver fully qualified file path C:\IBM\SQLLIB  
    Database client name and version MS SQL Server Management Studio Express® v9.0.2  
    Database client UID db2admin  
    Database client user password    
    DB2 administrators group (Windows only) DB2ADMNS  
    DB2 users group (Windows only) DB2USERS  
    Activities DB server host    
    Activities DB server port    
    Activities DB name. OPNACT  
    Activities DB application UID    
    Activities DB application user password    
    Blogs DB server host    
    Blogs DB server port    
    Blogs DB name. BLOGS  
    Blogs DB application UID    
    Blogs DB application user password    
    Cognos DB server host    
    Cognos DB server port    
    Cognos DB name. COGNOS  
    Cognos DB application UID    
    Cognos DB application user password    
    Communities DB server host    
    Communities DB server port    
    Communities DB name SNCOMM.  
    Communities DB application UID    
    Communities DB application user password    
    Dogear DB server host    
    Dogear DB server port    
    Dogear DB name. DOGEAR.  
    Dogear DB application UID    
    Dogear DB application user password    
    Files DB server host    
    Files DB server port    
    Files DB name. FILES.  
    Files DB application UID    
    Files DB application user password    
    Forums DB server host    
    Forums DB server port    
    Forums DB name. FORUM.  
    Forums DB application UID    
    Forums DB application user password    
    Home page DB server host    
    Home page DB server port    
    Home page DB name. HOMEPAGE.  
    Home page DB application UID    
    Home page DB application user password    
    Metrics DB server host    
    Metrics DB server port    
    Metrics DB name. METRICS.  
    Metrics DB application UID    
    Metrics DB application user password    
    Mobile DB server host    
    Mobile DB server port    
    Mobile DB name. MOBILE.  
    Mobile DB application UID    
    Mobile DB application user password    
    Profiles DB server host    
    Profiles DB server port    
    Profiles DB name. PEOPLEDB.  
    Profiles DB application UID    
    Profiles DB application user password    
    Wikis DB server host    
    Wikis DB server port    
    Wikis DB name. WIKIS  
    Wikis DB application UID    
    Wikis DB application user password    


    Tivoli Directory Integrator details

    Tivoli Directory Integrator details

    Tivoli Directory Integrator item Example Details
    Tivoli Directory Integrator installation location C:\IBM\TDI\  
    Tivoli Directory Integrator version. 7.1 fix pack 2.  
    Solutions Directory path C:\IBM\TDISOL\TDI  


    LDAP-Profiles mapping details

    This table is derived from the map_dbrepos_from_source.properties file.

    LDAP-Profiles mapping details

    Profiles DB attribute LDAP attribute (example) Profiles DB column
    alternateLastname null PROF_ALTERNATE_LAST_NAME
    bldgId null PROF_BUILDING_IDENTIFIER
    blogUrl null PROF_BLOG_URL
    calendarUrl null PROF_CALENDAR_URL
    countryCode c PROF_ISO_COUNTRY_CODE
    courtesyTitle null PROF_COURTESY_TITLE
    deptNumber null PROF_DEPARTMENT_NUMBER
    description description PROF_DESCRIPTION
    displayName cn PROF_DISPLAY_NAME
    distinguishedName $dn PROF_SOURCE_UID
    email mail PROF_MAIL
    employeeNumber employeenumber PROF_EMPLOYEE_NUMBER
    employeeTypeCode employeetype PROF_EMPLOYEE_TYPE
    experience null PROF_EXPERIENCE
    faxNumber facsimiletelephonenumber PROF_FAX_TELEPHONE_NUMBER
    floor null PROF_FLOOR
    freeBusyUrl null PROF_FREEBUSY_URL
    givenName givenName PROF_GIVEN_NAME
    givenNames givenName  
    groupwareEmail null PROF_GROUPWARE_EMAIL
    guid (Javascript function: {func_map_from_GUID}) PROF_GUID
    ipTelephoneNumber null PROF_IP_TELEPHONE_NUMBER
    isManager null PROF_IS_MANAGER
    jobResp null PROF_JOBRESPONSIBILITIES
    loginId employeenumber PROF_LOGIN and PROF_LOGIN_LOWER
    logins mail PROF_LOGIN
    managerUid $manager_uid

    This attribute represents a lookup of the UID of a manager using DN in the manager field.

    PROF_MANAGER_UID
    mobileNumber mobile PROF_MOBILE
    nativeFirstName null PROF_NATIVE_FIRST_NAME
    nativeLastName null PROF_NATIVE_LAST_NAME
    officeName physicaldeliveryofficename PROF_PHYSICAL_DELIVERY_OFFICE
    orgId ou PROF_ORGANIZATION_IDENTIFIER
    pagerId null PROF_PAGER_ID
    pagerNumber null PROF_PAGER
    pagerServiceProvider null PROF_PAGER_SERVICE_PROVIDER
    pagerType null PROF_PAGER_TYPE
    preferredFirstName null PROF_PREFERRED_FIRST_NAME
    preferredLanguage preferredlanguage PROF_PREFERRED_LANGUAGE
    preferredLastName null PROF_PROF_PREFERRED_LAST_NAME
    profileType null PROF_TYPE
    secretaryUid $secretaryUid

    This attribute represents a lookup of the UID of a secretary using DN in the secretary field.

    PROF_SECRETARY_UID
    shift null PROF_SHIFT
    surname sn PROF_SURNAME
    surnames sn PROF_SURNAME
    telephoneNumber telephonenumber PROF_TELEPHONE_NUMBER
    timezone null PROF_TIMEZONE
    title null PROF_TITLE
    uid (Javascript function - {func_map_to_db_UID}) PROF_UID
    workLocationCode postallocation PROF_WORK_LOCATION


    IBM Connections details

    IBM Connections details

    IBM Connections item Example Details
    IBM Connections installation location C:\IBM\Connections  
    Response file directory path. C:\IBM\Connections\InstallResponse.txt  
    DNS host connections.example.com  
    Choose: DNS MX Records or Java Mail Session?    
    DNS MX Records only: Local mail domain example.com  
    Java Mail Session only: DNS server name or SMTP relay host dns.example.com; relayhost.example.com  
    Domain name for Reply-to email address    
    Suffix or prefix for Reply-to email address    
    Server that receives Reply-to emails    
    User name and password for that server    
    URL and ports for admin and user access You can look up the URLs for each application in the text files that the installation wizard generates under connections_root  
    Activities server name    
    Activities cluster member name    
    Activities URL http://www.example.com:9080/activities  
    Activities secure URL https://www.example.com:9446/activities  
    Activities statistics files directory path    
    Activities content files directory path    
    Blogs server name    
    Blogs cluster member name    
    Blogs URL http://www.example.com:9080/blogs  
    Blogs secure URL https://www.example.com:9446/blogs  
    Blogs upload files directory path    
    Bookmarks server name    
    Bookmarks cluster member name    
    Bookmarks URL http://www.example.com:9080/dogear  
    Bookmarks secure URL https://www.example.com:9446/dogear  
    Bookmarks favicon files directory path    
    Communities server name    
    Communities cluster member name    
    Communities URL http://www.example.com:9080/communities  
    Communities secure URL https://www.example.com:9446/communities  
    Communities statistics files directory path    
    Communities discussion forum content directory path    
    Files server name    
    Files cluster member name    
    Files URL http://www.example.com:9080/files  
    Files secure URL https://www.example.com:9446/files  
    Files content store directory path    
    Forums server name    
    Forums cluster member name    
    Forums URL http://www.example.com:9080/forums  
    Forums secure URL https://www.example.com:9446/forums  
    Forums content store directory path    
    Home page server name    
    Home page cluster member name    
    Home page URL http://www.example.com:9080/homepage  
    Home page secure URL https://www.example.com:9446/homepage  
    Home page content store directory path    
    Metrics server name    
    Metrics cluster member name    
    Moderation server name    
    Moderation cluster member name    
    Moderation URL http://www.example.com:9080/moderation  
    Moderation secure URL https://www.example.com:9446/moderation  
    Profiles server name    
    Profiles cluster member name    
    Profiles URL http://www.example.com:9080/profiles  
    Profiles secure URL https://www.example.com:9446/profiles  
    Profiles statistics files directory path    
    Profiles cache directory path    
    Search server name    
    Search cluster member name    
    Search dictionary directory path    
    Search index directory path    
    Wikis server name    
    Wikis cluster member name    
    Wikis URL http://www.example.com:9080/wikis  
    Wikis secure URL https://www.example.com:9446/wikis  
    Wikis content directory path    


    IBM HTTP Server

    IBM HTTP Server details

    IBM HTTP Server item Example Details
    IBM HTTP Server installation location C:\IBM\HTTPServer\  
    IBM HTTP Server version V7.0 fix pack 21.  
    IBM HTTP Server httpd.conf file directory path C:\IBM\HTTPServer\conf\  
    web server definition name webserver1
    web server plugin-cfg.xml file directory path C:\IBM\HTTPServer\Plugins\config\webserver1\  
    IBM HTTP Server host    
    IBM HTTP Server fully qualified host    
    IBM HTTP Server IP address    
    IBM HTTP Server communication port 80  
    IBM HTTP Server administration port 8008  
    Run IBM HTTP Server as a service? (Y/N)    
    Run IBM HTTP administration as a service? (Y/N)    
    IBM HTTP Server administrator ID    
    IBM HTTP Server administrator password    


    Cognos BI Server and Transformer

    Cognos BI Server and Transformer details

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


    IBM Connections release notes

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


    Contents

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

    The IBM Connections 4 announcement is available at www.ibm.com/common/ssi/index.wss.

    • Detailed product description, including a description of new function
    • Product-positioning statement
    • Packaging and ordering details
    • International compatibility information

    IBM Connections system requirements


    Install IBM Connections 4

    For step-by-step installation instructions, refer to the Installing section of the product documentation.

    Once mandatory tasks are completed, go to fix central to obtain the latest iFixes and apply them using " Update IBM Connections 4.0" to ensure the deployment will have the latest set of Software Fixes.


    Known problems

    Known problems are documented in the form of individual technotes in the Support Portal

    As problems are discovered and resolved, the IBM Support team updates the knowledge base. By searching the knowledge base, you can quickly find workarounds or solutions to problems.

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


    Install


    New for IBM Connections 4.0 install

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

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

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

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

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


    Migrate to this release

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

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

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

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


    The installation process

    1. Review software and hardware requirements.

    2. Install required software:

      • WebSphere Application Server
      • LDAP directory
      • Database server
      • Tivoli Directory Integrator
      • IBM Cognos (optional)

    3. Determine SMTP and DNS details of the mail infrastructure.

    4. Prepare the LDAP directory

    5. Create application DBs

    6. Install IBM Connections

    7. Complete post-installation tasks


    Accessibility applications for installing IBM Connections

    Use the wizards

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

    • IBM Connections installation
    • Database creation
    • Profiles population
    • Connector installation
    • Update installation


    Pre-installation tasks

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


    Prepare to configure the LDAP directory

    1. Install a supported LDAP directory.

    2. Set the Size Limit parameter in the LDAP configuration to match the number of users in the directory.

      This allows the Profiles population wizard to return the correct number of records.

      For example, if the directory has 100,000 users, set this parameter to 100000.

      If you cannot set the Size Limit parameter, you could run the wizard multiple times. Alternatively, you could write a JavaScript function to split the original LDAP search filter, then run...

        collect_dns_iterate.bat
        populate_from_dns_files.bat

    3. Turkish locales have some limitations. See the Base entry comparison for Turkish locale.

    4. Identify LDAP attributes to use for the following roles.

      If no corresponding attribute exists, create one. You can use an attribute for multiple purposes. For example, you can use the mail attribute to perform the login and messaging tasks.

      Display name The cn LDAP attribute is used to display a person's name in the product user interface.
      Log in Attribute or attributes to log in to IBM Connections. For example: uid. The login name must be unique in the LDAP directory.
      Messaging Optional. Attribute to use to define the email address of a person. The email address must be unique in the LDAP directory. If a person does not have an email address and does not have an LDAP attribute that represents the email address, that person cannot receive notifications.
      Global unique identifier Attribute to use as the unique identifier of each person and group in the organization. Must be unique across the organization.

    5. Collect LDAP directory information

      Directory Type Directory service from the available vendors and versions.
      Primary host
      Port
      Bind distinguished name
      Bind password
      Certificate mapping
      Certificate filter, if applicable.
      LDAP entity types or classes LDAP object classes. For example, select the LDAP inetOrgPerson object class for the Person Account entity, or the LDAP groupOfUniqueNames object class for the Group entity.
      Search base Distinguished name (DN) of the LDAP subtree as the search scope. For example, select o=ibm.com to allow all directory objects underneath this subtree node to be searched. For example:

        Group, OrgContainer, PersonAccount, or inetOrgPerson


    Create the Cognos administrator account

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

    The Cognos administrator account must reside in the same LDAP directory used by IBM Connections.

    If you will use an existing LDAP account, take note of the user name and password.

    For example, if your organization already has a Cognos deployment, you might choose to use the same administrator account with Connections.

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


    Install IBM WAS

    WAS Network Deployment is bundled with the IBM Connections install image.

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


    WAS options

    • IBM Connections deployment
    • Deployment Manager and one node on the same system
    • Deployment Manager and nodes on separate systems

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


    Install and configure WAS

    1. Install WAS Network Deployment.

      Enable security when the installation wizard requests it. The administrative user ID that you create must be unique and must not exist in the LDAP repository that you plan to federate.

    2. Apply the available fix packs.

    3. Configure WAS to communicate with the LDAP directory.

      • Perform this step on the Deployment Manager Integrated Solutions Console.
      • Configure the LDAP for Cognos separately.

    4. Configure Application Security.

    5. For each node to add to the cell:

      ...where...

      • DM_host is the host of the Deployment Manager
      • DM_SoapPort is the SOAP port of the Deployment Manager
      • AdminUserId is the UID for the Deployment Manager
      • AdminPwd is the password for the Deployment Manager

      Synchronize all the nodes.

      You can also add nodes after you have deployed IBM Connections.


    Set up federated repositories

    Use federated repositories with IBM WAS to manage and secure user and group identities. You can configure the user directory for IBM Connections to be populated with users from more than one LDAP directory.

    For IBM Tivoli Directory Server, for group entities, choose one of the following object classes...

    • groupOfNames
    • groupOfUniqueNames

    WAS uses groupOfNames by default. In most cases, delete the default mapping and create a new mapping for group entities using the LDAP groupOfUniqueNames object class.

    For groupOfUniqueNames object class for group entities, for the group member attribute, use uniqueMember

    For groupOfNames object class group entities, for the group member attribute, use member

    Configure the LDAP for Cognos separately.


    Set up federated repositories in WAS

    1. Prepare to configure the LDAP directory.

    2. Start WAS and log in to the Integrated Solutions Console on the Deployment Manager:

        http://dmgr_host:9060/ibm/console

    3. Click...

        Security | Global Security | Available realm definitions | Federated Repositories | Configure | Add Base entry to Realm | Add Repository

    4. On the New page, set repository identifier, for example MyRepo.

    5. Set the LDAP directory

      • IBM Tivoli Directory Server 6.1, 6.2, 6.3
      • z/OS Integrated Security Services LDAP Server
      • IBM Lotus Domino 8.0 or later, 8.5 or later
      • Novell Directory Services eDirectory 8.8
      • Sun Java System Directory Server 7
      • Microsoft Active Directory 2008
      • Microsoft Active Directory Application Mode
      • Active Directory Lightweight Directory Services (AD LDS)

    6. Set the host of the primary LDAP directory server.

    7. If the directory does not allow LDAP attributes to be searched anonymously, provide values for...

      • Bind distinguished name
      • Bind password fields

      For example, Domino LDAP directory does not allow anonymous access.

    8. Set the login attribute or attributes to use for authentication in the Login properties field. Separate multiple attributes with a semicolon. For example:

        uid;mail

      If you are using Active Directory, and you use an email address as the login, specify mail as the value for this property.

      If you use the samAccountName attribute as the login, specify uid as the value for this property.

    9. Click Apply and then click Save.

    10. On the Repository reference page, set...

      • LDAP attribute type
      • Value pairs for the base element in the realm and the LDAP repository.

      Types include...

        DN of a base entry that uniquely identifies this set of entries in the realm

        Identifies entries in the realm. For example, on a Domino LDAP server:

          cn=john doe, o=example

        DN of a base entry in this repository

        Identifies entries in the LDAP directory. For example...

          cn=john doe, o=example

        The search base entry is the top node of a subtree which consists of many possible entries beneath. For example, the search base entry could be o=example and one of the entries underneath this search base could be...

          cn=john doe, o=example

        If you have defined flat groups in the Domino directory, do not enter a value in this field. Flat groups are group names such as SalesGroup, as opposed to:

          cn=SalesGroup,ou=Groups

        If you configure a search base in this Step, you will not be able to access the groups.

    11. Click Apply and then click Save.

    12. Click OK to return the Federated Repositories page.

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

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

    15. Click the Group entity type and modify the object classes mapping.

      You can also edit the Search bases and Search filters fields, if necessary. Enter LDAP parameters that are suitable for the LDAP directory.

      You can accept the default object classes value for Group. However, if you are using Domino, change the value to dominoGroup.

    16. Click Apply and then click Save.

    17. Click the PersonAccount entity type and modify the default object classes mapping.

      You can also edit the Search bases and Search filters fields, if necessary. Enter LDAP parameters that are suitable for the LDAP directory. Click Apply, and then click Save to save this setting.

      If you are using a Domino LDAP, replace the default mapping with dominoPerson and dominoGroup object classes for person account and group entities.

    18. In the navigation links at the beginning of the page, click the name of the repository modified to return to the Repository page.

    19. Optional: If your applications rely on group membership from LDAP:

      1. Click the Group attribute definition link in the Additional Properties area, and then click the Member attributes link.

      2. Click New to create a group attribute definition.

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

      4. Click Apply and then click Save.

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

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

      If you do not configure the group membership attribute, the group member attribute is used when you search group membership. To enable searches of nested group membership, configure the group membership attribute.

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

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

    21. Set the new repository as the current respository:

      1. Click Global Security in the navigation links at the beginning of the page.

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

    22. Enable login security on WAS:

      1. Select the Administrative Security and Application Security check boxes. For better performance, clear the Java 2 security check box.

      2. Click Apply and then click Save.

      The administrative user name and password are now required because you set up security on WAS.

    23. Create an administrator for WAS:

      1. Click Users and Groups > Administrative user roles and then click Add.

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

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

      4. Click OK and then click Save.

      5. Log out of the DM.

      6. Restart the DM and the nodes.

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

      Ensure that this UID does not have spaces in the name.

    24. Set a primary administrative user:

      1. Click...

          Security | Global Security | Available realm definitions | Federated Repositories | Configure

      2. Enter the user name mapped in the previous step in the Primary administrative user name box.

      3. Click Apply and then click Save.

    25. Log out of the DM and restart WAS.

    26. When WAS is running again, log in to the Integrated Solutions Console using the primary administrative user name and password.

    27. Optional: Test the new configuration by adding some LDAP users to the WAS with administrative roles.

    28. Optional: If you are using SSL for LDAP, add a signer certificate to your trust store :

      1. From the WAS Integrated Solutions Console, select...

          SSL Certificate and key management | Key Stores and certificates | CellDefaultTrustStore | Signer Certificates | Retrieve from port

      2. Set the DNS name of the LDAP directory in the Host field.

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

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

      5. Click Apply and then click Save.

    29. Optional: If you plan to enable single sign-on (SSO) for IBM Connections, prepare the WAS environment :

      1. From the WAS Integrated Solutions Console, select Security > Global security > web and SIP security > Single sign-on (SSO).

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

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

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

      5. Click Apply and then click Save.

    30. Optional: Verify that users in the LDAP directory have been successfully added to the repository:

      1. From the WAS Integrated Solutions Console, select Users and Groups > Manage Users.

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


    Results

    You have configured WAS to use a federated repository.


    Choose login values

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

    The following scenarios are supported:

    Single LDAP attribute with a single value

    For example:

      uid=jsmith

    Multiple LDAP attributes, each with a single value

    To specify multiple attributes, separate them with a semicolon when you enter them in the Login properties field (while adding the repository to IBM WAS).

    For example, where uid=jsmith and mail=jsmith@example.com, you would enter: uid; mail.

    Single LDAP attribute with multiple values

    For example, mail is the login attribute and it accepts two different email addresses: an intranet address and an extranet address. For example:

      mail=jsmith@myCompany.com
      mail=jsmith@example.com

    Multiple LDAP attributes, each with multiple values

    For example:

      uid=jsmith
      uid=john_smith
      mail=jsmith@example.com
      mail=john_smith@example.com
      mail=jsmith@MyCompany.com

    Multiple LDAP directories

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


    Multi-valued attributes

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

    If, for example, you mapped the following attributes for a user called Sample User, all three values for the user are populated in the PROFILE_LOGIN table in the Profiles DB:

    • mail=suser@example.com
    • mail=sample_user@example.com
    • mail=user_sample@example.com

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

    • uid=suser
    • uid=sampleuser
    • uid=user_sample

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


    Custom attributes

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

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

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

    The value for the loginID attribute is stored in the Prof_Login column of the Employee table in the Profiles DB.


    Use Profiles or LDAP as the repository

    The default login attributes defined in the profiles-config.xml file are uid, email, or loginID

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


    Set the global ID attribute for users and groups

    Unique identifier of each person and group in the organization. Must be unique across the organization.

    By default, WAS reserves the following attributes as unique identifiers for the following LDAP directory servers:

      IBM Tivoli Directory Server ibm-entryUUID
      Microsoft Active Directory objectGUID

      For AD, the samAccountName attribute has a 20-character limit; other IDs used by IBM Connections have a 256-character limit.

      IBM Domino Enterprise Server dominoUNID

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

        <config:externalIdAttributes name="dominoUNID"/>

      Sun Java System Directory Server nsuniqueid
      eNovell Directory Server GUID
      Custom ID If your organization already uses a unique identifier for each user and group, you can configure IBM Connections to use that identifier.

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

      AIX

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

      Linux

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

      Microsoft Windows

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

    IBM recommends that you do not allow the GUID of a user to change. If you change the GUID, the user will not have access to their data unless you re-synchronize the LDAP and Profiles DB with the new GUID. When you change the GUID and run the sync_all_dns batch file, the user's GUID is changed only in the Profiles DB, and not in the DBs for other IBM Connections applications. Similarly, if you delete users and re-add them to the LDAP, the GUID value that the LDAP generates is now different than the value that is stored in the other application DBs.

    To resolve this discrepancy, use the SWAP command.

    To allow deletes and adds, or migration across various LDAP servers (for example, from staging to production), use an LDAP attribute that is fixed across various directories or when entries are recreated.


    Specify a custom ID attribute for users or groups

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


    This is an optional task.

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

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

    The wimconfig.xml file governs a single ID attribute for all supported objects such as users, groups, and organizations in WAS. You can use LotusConnections-config.xml to override the ID attribute in the wimconfig.xml file.

    For example, you could use the wimconfig.xml file to specify the ibm-entryUUID attribute as the ID Key attribute for users and groups in all applications running on WAS, and then modify LotusConnections-config.xml to specify the employeeID as the ID Key attribute for IBM Connections applications.

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

    A custom ID must meet the following requirements:

    • The ID must be static and unique. It must not be reassigned across users and groups in the directory.

    • The ID must not exceed 256 characters in length. To achieve faster search results, use a fixed-length attribute for the ID.

      If you are planning to install the Files or Wikis application, the ID cannot exceed 252 characters in length.

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

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

    1. From the VMM_HOME/model directory, open the wimxmlextension.xml file. If no file with this name exists, create one.

      VMM_HOME is the directory where the Virtual Member Manager files are located. This location is set to either the wim.home system property or the user.install.root/config/cells/local.cell/wim directory.

    2. Add the definitions of the new property types and the entity types to which they apply. Ensure that the XML is well-formed and conforms to the schema defined in wimschema.xsd.

      • To select a single ID attribute for both users and groups, use the following sample XML, which defines a new property type called enterpriseID and adds this property type to the PersonAccount and Group entity types:

        <?xml version="1.0" encoding="UTF-8"?>
        <sdo:datagraph xmlns:sdo="commonj.sdo" 
        xmlns:wim="http://www.example.com/websphere/wim">
        <wim:schema>
        <wim:propertySchema 
        nsURI="http://www.example.com/websphere/wim" 
        dataType="STRING" multiValued="false" 
        propertyName="enterpriseID">
        <wim:applicableEntityTypeNames>PersonAccount
        </wim:applicableEntityTypeNames>
        </wim:propertySchema>
        <wim:propertySchema 
        nsURI="http://www.example.com/websphere/wim" 
        dataType="STRING" multiValued="false" 
        propertyName="enterpriseID">
        <wim:applicableEntityTypeNames>Group
        </wim:applicableEntityTypeNames>
        </wim:propertySchema>
        </wim:schema>
        </sdo:datagraph> 

      • To use two different ID attributes, one for users and a different one for groups, use the following sample XML, which defines a property type called customUserID and adds it to the PersonAccount entity type, and also defines a property type called customGroupID and adds it to the Group entity type:

        <?xml version="1.0" encoding="UTF-8"?>
        <sdo:datagraph xmlns:sdo="commonj.sdo" 
        xmlns:wim="http://www.example.com/websphere/wim">
        <wim:schema>
        <wim:propertySchema 
        nsURI="http://www.example.com/websphere/wim" 
        dataType="STRING" multiValued="false" 
        propertyName="customUserID">
        <wim:applicableEntityTypeNames>PersonAccount
        </wim:applicableEntityTypeNames>
        </wim:propertySchema>
        <wim:propertySchema 
        nsURI="http://www.example.com/websphere/wim" 
        dataType="STRING" multiValued="false" 
        propertyName="customGroupID">
        <wim:applicableEntityTypeNames>Group
        </wim:applicableEntityTypeNames>
        </wim:propertySchema>
        </wim:schema>
        </sdo:datagraph> 

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

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

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

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

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

    4. Find and edit the <config:attributeConfiguration> element, adding one of the following texts:

      • To use a single ID attribute for both users and groups, using a string called enterpriseid, add the following text:

        <config:attributeConfiguration>
        	<config:externalIdAttributes 
        name="enterpriseID" syntax="String"/>
        </config:attributeConfiguration>  

      • To use two different ID attributes, one for users and the other for groups, add the following text:

        <config:attributeConfiguration>
        	<config:attributes name="userPassword" 
        propertyName="password"/>
        	<config:attributes name="customUserID" 
        propertyName="customUserID"/>
        	<config:attributes name="customGroupID" 
        propertyName="customGroupID"/>
        	<config:propertiesNotSupported 
        name="homeAddress"/>
        	<config:propertiesNotSupported 
        name="businessAddress"/>
        </config:attributeConfiguration> 

    5. Save and close the wimconfig.xml file.


    What to do next

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

    When you map fields in the Profiles DB, ensure that you add the custom ID attribute to the PROF_GUID field in the EMPLOYEE table.


    Create DBs

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

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

    • Cognos

    • Metrics

    • Mobile

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

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

    Consult your DB documentation for detailed information about preparing your DBs.

    You must have already created and started a DB instance before you can create DBs.

    Complete the procedures that are appropriate for your deployment:


    Create multiple DB instances

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

    This is an optional procedure. If you need to have only one DB instance (in Oracle terminology, one DB), you can skip this task.

    (Windows only) Complete the following steps for each instance that you plan to create:

    1. Create a new user and add it to the Administrators group.

      If you are using DB2, add the new user to the DB2ADMNS group as well.

    2. Remove the user account from the Users group.

    3. In the Local Security Policy utility, add these rights to the new user:

      • Act as part of the operating system

      • Adjust memory quotas|Increase quotas for a process

      • Create a token object

      • Debug programs

      • Lock pages in memory

      • Log on as a service

      • Replace a process level token

    The new account uses the local system as the domain.

    A DB environment with multiple instances provides several benefits:

    • the ability to use different instances for development and production.

    • restricted access to sensitive information.

    • an optimized configuration for each instance.

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

    Multiple instances require additional system resources.

    To create multiple instances of a DB:

    Choose your DB type:

    • DB2

      For each instance to create, log in as the instance owner before creating the instance.

      > Use the DB2 Command Line Processor to enter commands.

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

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

        1. Create a group for DB2:

            mkgroup db2iadm1

        2. Create a user for DB2:

          mkuser groups=db2iadm1 db2instN

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

        3. Create DB2 instances:

          Login with root user and go to /opt/IBM/db2/V9.5/instance.

          ./db2icrt -u db2instN db2instN

          ...where db2instN is the name of a user and also the name of an instance. Repeat this step to create enough instances to match the number of DBs.

        4. Set the port of the instance:

          Edit the/etc/services file and add the following line:

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

        5. Set the communication protocols for the instance:

          db2 update DB manager configuration using svcename db2c_instance_name
          db2set DB2COMM=tcpip
          db2stop
          db2start
          Repeat this step for each instance.

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

      • Linux:

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

        1. Create groups for DB2:

          groupadd -g 999 db2iadm1 
          groupadd -g 998 db2fadm1 
          groupadd -g 997 dasadm1 

        2. Create users for DB2 in the db2iadm1 group:

          useradd -u 1100 -g db2iadm1 -m -d /home/db2instN db2instN -p db2instX

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

        3. Create the db2fenc1 user for DB2 in the db2fadm1 group:

          useradd -u 1101 -g db2fadm1 -m -d /home/db2fenc1 db2fenc1 -p db2instX

        4. Create the dasusr1 user for DB2 in the dasadm1 group:

          useradd -u 1102 -g dasadm1 -m -d /home/dasadm1 dasusr1 -p db2instX

        5. Create new DB2 instances:

          Login with root user and go to /opt/ibm/db2/V9.5/instance.

          ./db2icrt -u db2fenc1 db2instN

          Create enough instances to match the number of DBs.

        6. Set the port of the instance:

          Edit the /etc/services file and add the following line:

          db2c_<instance_name> <instance_port>/tcp

          ...where instance_name is the name of the instance and instance_port is the port of that instance. Repeat this step for each instance.

        7. Log in as the DB instance and set the communication protocols for the instance:

          su - db2instN
          db2 update DB manager configuration using svcename 
           db2c_instance_name
          db2set DB2COMM=tcpip
          db2stop
          db2start
          Repeat this step for each instance.

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

      • Microsoft Windows:

        1. Create an instance:

            db2icrt instance_name -s ese -u db2_admin_user

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

        2. Set the port of the instance:

          Edit the C:\WINDOWS\system32\drivers\etc\services file and add the following line:

          db2c_instance_name instance_port/tcp

        3. Set the current instance parameter:

          set DB2INSTANCE=instance_name

        4. Set the communication protocols for the instance:

          db2 update DB manager configuration using svcename 
           db2c_instance_name
          db2set DB2COMM=npipe,tcpip
          db2stop
          db2start

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

    • Oracle:

      Each DB is a DB instance.

      Use the Oracle Database Configuration Assistant (DBCA) to create Oracle a new DB:

      1. Open the DBCA tool:

        • AIX or Linux:

            $ sudo su - oracleuser
            $ export [[ORACLE_HOME]]=...
            $ export PATH=$PATH:$ORACLE_HOME/bin
            $ export DISPLAY=hostname:displaynumber.screennumber

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

            localhost:0.0

        • $ dbca &

    • Windows:

      1. Click Start

      2. Select Oracle > Oracle_home_name > Configuration and Migration Tools > Database Configuration Assistant.

        where Oracle_home_name is the Oracle home on your system. For example:

          OraDB10g_Home1

  • On the Operations page, accept the default option to Create a DB and click Next.

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

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

  • On the Management Options page, accept the default option to Configure the DB with Enterprise Manager and click Next.

  • On the Database Credentials page, enter the DB password and click Next.

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

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

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

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

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

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

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

  • SQL Server

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

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

    3. Ensure that Named Pipes is enabled in the SQL Server Network Configuration for all instances.

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

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

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


    What to do next

    When you create multiple DB instances, you must install the DBs on each instance. If you are using the DB wizard to install the DBs, you must prepare and run the DB wizard once for each instance and if you are using the scripts to install the DBs, you must run the scripts once for each instance.


    Register the DB2 product license key

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

    Only perform this procedure if you are using the version of DB2 that was included with IBM Connections. If you installed IBM Connections and DB2 from the product DVD, the license key was already provided.

    If you used DB2 with an earlier version of IBM Connections, your installation of DB2 is already registered and you can skip this task.

    Install DB2 before beginning this task but do not create any application DBs until after you have completed this task. To register the DB2 product license key, complete the following steps:

    1. Navigate to the IBM Passport Advantage® web site and log in.

      If you installed IBM Connections and DB2 from the product DVD, the license key was already provided. You can skip Steps 1-3 and begin at Step 4.

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

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

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

    5. Open a command prompt, change to the directory where the license file is stored, and run the following command:

      On the DVD image, the license is stored in the DB2.License directory.

        db2licm -a path_to_lic_file/db2ese_o.lic

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

    6. Verify the license is registered by running the following command:

        db2licm -l

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

    7. Restart DB2.


    What to do next

    Create your IBM Connections application DBs.


    Create a dedicated DB2 user

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

    To create a dedicated DB2 DB user named lcuser, complete the following steps:

    Choose your operating system:

    • AIX or Linux:

      • Log into the DB2 server as the root user, and then type the following command to create a new user:

        useradd -u 1004 -g db2iadm1 -m -d /db2home/lcuser lcuser -p password

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

    • Windows

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

      2. From the Computer Management console, select...

      3. Right-click Users and select New User.

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

      5. Click Close.

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

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

      8. Type DB2USERS in the Enter the object names to select field, and click OK. Click OK again to save your changes.

        If the DB2USERS group is not found, extended security for DB2 on Windows might not be enabled.


    Configure the DB2 DBs for unicode

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

    Configure the DB2 DBs for unicode ensures that DB2 tools like export and import do not corrupt unicode data.

    You must perform the following steps on each DB2 instance in the deployment:

    1. Stop any WebSphere server connected to the DB2 DB you are configuring.

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

    3. Open the DB2 command window.

    4. Run the following commands:

      db2set DB2CODEPAGE=1208
      db2stop force
      db2start

    5. Run the following commands to check the new configuration:

      db2set
      This should return DB2CODEPAGE=1208. If not, it is not configured correctly and you should try Step 4 again.


    Create DBs with the DB wizard

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


    Prepare the DB wizard

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

    Ensure that you have given the necessary permissions to the UIDs that need to log in to the DB system and access the IBM Connections Wizards directory.

    If you are planning to create multiple DB instances, prepare and run the DB wizard once for each instance.

    (DB2 only) Create a dedicated IBM DB2 DB user named lcuser.

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

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

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

      gtar -xvf Lotus_Connections_wizard_aix.tar

    This command creates a directory named after the wizard.

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

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

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

    To prepare the DB wizard, complete the following steps:

    1. Log in to your DB server as the root user or system administrator.

    2. (AIX and Linux only) Grant display authority to all userss under the root user or system administrator:

      xhost + // Grant display authority to other users

      If granting display authority to all users is a security concern for you, change the command to grant display authority to a specific user or users.

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

    3. (AIX and Linux only) Ensure that the current user is qualified or else switch to a qualified user by running the following commands:

      • DB2

          su - db2inst1
          export DISPLAY=localhost:0.0
          xclock
          Ctrl + C

      • Oracle

        Before running the DB wizard, create an Oracle DB instance.

        su - oracle
        export DISPLAY=localhost:0.0
        xclock
        Press Ctrl + C

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

    4. Start the DB instance:

      Run the DB commands under the user account that has administrative access to the DB.

      • AIX or Linux:

        • DB2

          db2start

        • Oracle (login as oracle or use the su oracle command to change to oracle)

          export ORACLE_SID=orcl // Set the current Oracle DB

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

          cd $ORACLE_HOME/bin

          ./sqlplus "/ as sysdba"

          startup // Start the current Oracle DB

      • Microsoft Windows:

        Windows registers most DB instances as a service. You can start or stop a DB service manually if necessary.

        • DB2

          1. Log in to the Control Center.

          2. In Object View, right-click the DB instance.

          3. In the menu, click Start to start the DB manager.

        • Oracle

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

          2. Right-click the Oracle service.

          3. From the menu, click Start to start the DB service.

        • SQL Server

          1. Open SQL Server Management Studio.

          2. Connect the DB instance.

          3. Start the DB instance from the studio.

    5. Copy the Wizards directory in the IBM Connections installation media to the system that hosts the DB server.

      If you have more instances, exit from the current instance and repeat this step for each instance.

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

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


    Use the DB wizard

    Use the DB wizard to create DBs for the IBM Connections applications that you plan to install.

    Before using the wizard for the first time, complete the steps described in the Preparing the DB wizard topic.

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

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

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

    (DB2 only) If you use only one DB instance and if that instance includes other DBs besides IBM Connections, configure the numdb parameter to match the total number of DBs on the instance.

    If you migrated from IBM Connections 3.0.1, the numdb parameter was set to 12, the maximum number of IBM Connections 4.0 DBs. If the instance has additional DBs, increase the value of the numdb parameter to match the total number of DBs on the instance.

    To change the parameter:

      db2 UPDATE DBM CFG USING NUMDB nn

    where nn is a number of DBs.

    DB2 uses a user account called lcuser. If you are creating a DB2 DB with SQL scripts, manually create the lcuser account on your operating system and then run the appGrants.sql script to grant the appropriate privileges to the lcuser account. When you use the DB wizard, this script runs automatically.

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

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

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

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

    Some of these packages have dependencies on other packages. The AIX package installer alerts you to any additional packages that might be required. Use the IBM Connections DB wizard to create, update, and remove DBs.

    You can review the scripts that the wizard executes by looking in the connections.sql directory in the installation media. On DB2, the commands are shown in the log that the wizard creates. On Oracle and SQL Server, the log shows the results of the commands.

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

    1. (DB2 on Windows 2008 64-bit.) On Windows 2008, you must perform DB2 administration tasks with full administrator privileges.

      1. Logged in as the instance owner, open a command prompt and change to the DB2 bin directory. For example: C:\IBM\SQLLIB\BIN.

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

    2. From the IBM Connections Wizards directory, open the following file to launch the wizard:

      • AIX: ./dbWizard.sh
      • Linux: ./dbWizard.sh
      • Microsoft Windows: dbWizard.bat

    3. Click Next to continue.

    4. Select the option to Create a DB and click Next.

    5. Enter the details of the DB you wish to create and then click Next:

      1. Select a DB type.

      2. Select the location of the DB.

        For an Oracle DB on Windows 2008 64-bit, enter the value of the ORACLE_HOME registry key.

        For example, the key for Oracle 11g on Windows 2008 64-bit is HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE\Key_OraDb11g_home1 and the value is C:\app\Administrator\product\11.2.0\dbhome_1.

      3. Specify a DB instance.

        The DB instance that you specify must already exist on your system.

    6. Select an application and click Next.

      If you are creating DBs in this task, only applications that have not already been installed to a DB instance are available. If you are updating DBs, you can only choose applications that are already installed.

      The News and Search DBs are contained in the Home page DB.

      The Metrics application has some additional requirements:

      • If you select the Metrics application, you must also select the IBM Cognos application.

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

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

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

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

    7. (Oracle and SQL Server DBs only) Enter the password for the DBs and then click Next. Choose one of the following options:

      • Use the same password for all applications. Enter the password in the Password and Confirm password fields.

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

    8. (SQL Server only) Set the location of the DB file and then click Next.

      • Use the same DB file location for all applications. Enter the location of the DB or click Browse to choose a location.

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

    9. Review the Pre Configuration Task Summary to ensure that the values you entered on previous pages in the wizard are correct. If you want to make a change, click Back to edit the value. Click Create to begin creating DBs.

      Click Show detailed DB commands to preview each SQL command before it is executed by the wizard. If you choose to save the commands, you must have write-access to the folder you choose to save them in.

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


    What to do next

    (DB2 for Linux on System z only.) To improve DB performance, enable the NO FILE SYSTEM CACHING option.


    Use the DB wizard in silent mode

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

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

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

    (DB2 only) If you use only one DB instance and if that instance includes other DBs besides IBM Connections, configure the numdb parameter to match the total number of DBs on the instance.

    If you migrated from IBM Connections 3.0.1, the numdb parameter was set to 12, the maximum number of IBM Connections 4.0 DBs. If the instance has additional DBs, increase the value of the numdb parameter to match the total number of DBs on the instance.

    To change the parameter:

      db2 UPDATE DBM CFG USING NUMDB nn

    where nn is a number of DBs.

    (Oracle only) Ensure that the Statement cache size for the data sources on WAS is no larger than 50. A higher value could lead to Out Of Memory errors on the application server instance. To create DBs in silent mode, complete the following steps:

    1. (DB2 on Windows 2008 64-bit.) On Windows 2008, you must perform DB2 administration tasks with full administrator privileges.

      1. Logged in as the instance owner, open a command prompt and change to the DB2 bin directory. For example: C:\IBM\SQLLIB\BIN.

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

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

    3. Launch the wizard:

      • AIX: ./dbWizard.sh -silent response_file
      • Linux: ./dbWizard.sh -silent response_file
      • Microsoft Windows: dbWizard.bat -silent response_file

      where response_file is the file path to the response file.

      If the path to the response_file contains a space, this parameter must be enclosed in double quotation marks (").


    What to do next

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


    The DB wizard response file

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

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

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

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

    Typical properties of the response.properties file

    Property Value Description
    dbtype db2 | oracle | sqlserver The DB system to use. Choose from IBM DB2, Oracle, or Microsoft SQL Server.
    dbInstance DB_instance_name The instance name of the DB that you want to use. For example:

    • DB2 (DB2 on Windows)

    • db2inst1 (DB2 on AIX or Linux)

    • orcl (Oracle)

    • \\ (SQL Server)

      The first '\' is an escape character.

    dbHome DB_location File path to the DB.

    If you encounter an Invalid DB instance error, the file path to the DB might be incorrect.

    If the dbHome value is, for example, /home/oracle/oracle/product/10.2.0/db_1/, then you must remove the final / character. This limitation applies only on Oracle DBs.

    On Windows, you need to add an escape character '\'.

    For example, activities.filepath=C\:\\SQLSERVER.

    action create | delete | upgrade The action performed by the wizard. The options are create, delete, or upgrade.
    dbVersion DB2: 9 | Oracle: 10 or 11| SQL Server 2005:9 SQL Server 2008: 10 The major version number of the DB type.

    For example, if you use SQL Server 2005, enter 9. If you use SQL Server 2008, enter 10.

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

    If you are creating Oracle or SQL Server DBs, add the additional properties described in the following table:

    Additional properties for Oracle or SQL Server DBs

    Property Value Description
    <application>.password Password for application DBs Password for the applications.

    The passwords will be removed from the response file after the wizard has finished processing.

    <application>.filepath File path to the directory where DB files are stored (SQL Server only) File path to the DB file location.

    On Windows, add an escape character '\'.

    For example, activities.filepath=C\:\\SQLSERVER.

    If you are upgrading DBs and a JDBC connection is needed, add the additional properties described in the following table:

    Additional properties for upgrading DBs with JDBC

    Property Recommended value Description
    port

    • DB2 default is 50000

    • Oracle default is 1521

    • SQL Server default is 1433
    Database server port for starting JDBC
    administrator

    • DB2 default on Windows is db2admin

    • DB2 default on AIX and Linux is db2inst1

    • Oracle default is system

    • SQL Server default is sa
    Database administrator account for starting JDBC
    adminPassword   Database administrator password for starting JDBC
    storyLifetimeInDays   The Home page upgrade requires this parameter. It should be the same as the value in the news-config.xml file.
    profiles.db.name profiles.db.hostname profiles.db.port profiles.db.admin profiles.db.adminPassword   The Home page migration process copies data from the Profiles DB. For this reason, you must update the Home page DB before updating the Profiles DB. The migration process supports the use of different instances to host the Home page and Profiles DBs.
    jdbcLibPath   (SQL Server only) JDBC library path for starting JDBC.

    On Windows, add an escape character '\'.

    For example, jdbcLibPath=C\:\\sqljdbc4.jar


    Create DBs with SQL scripts

    Create IBM Connections DBs using the SQL scripts that are provided on the installation media. Use the SQL scripts to create DBs for IBM Connections takes longer than using the wizard, and does not validate the DBs, but might be necessary in some circumstances.


    Create IBM DB2 DBs manually

    Create IBM DB2 DBs with SQL scripts instead of using the IBM Connections DB wizard.

    Use this procedure if you do not want to use the DB wizard to create your DBs.

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

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

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

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

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

    (AIX only) Configure the AIX system that hosts the DB2 DBs to use the enhanced journaled file system (JFS2), which supports file sizes larger than 2 GB. To enable large files in the JFS system, complete the following steps:

    1. In the SMIT tool, select...

        System Storage Management>File System>Add/Change/Show/Delete File Systems

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

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

    You must perform this task for each IBM Connections application that you are installing.

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

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

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

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

    To create the application DBs, complete the following steps:

    1. Optional: (Only required if the DB server and IBM Connections are installed on different systems.) Copy the IBM Connections SQL scripts to the DB2 DB system. Authorize a UID that can create the DBs.

    2. Log in to the DB2 DB system with the UID of the owner of the DB instance. The UID must have privileges to create a DB, a tablespace, tables, and indexes.

      If you created multiple DB instances, specify the UID for the first instance.

      The default administrative ID for Microsoft Windows is db2admin.

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

      db2start

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

      db2 -tvf createDb.sql

    5. For Home page, run the following script:

      db2 -tvf initData.sql

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

      db2 -td@ -vf createDb.sql

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

    7. Run the following command to grant access privileges to the lcuser account for the Home page and Profiles DBs:

      db2 -tvf <application_subdirectory>/appGrants.sql

    8. Run the following command to grant access privileges to the lcuser account for the Activities, Communities, Blogs, Bookmarks, Files, Forums, Mobile, and Wikis DBs:

      db2 -td@ -vf application_subdirectory/appGrants.sql

    9. Run the following commands to generate statistics for the Home page DB:

      db2 -tvf application_subdirectory/reorg.sql

      db2 -tvf application_subdirectory/updateStats.sql

    10. Run the following commands to create Calendar tables in the Communities DB:

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

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

    11. To use the Metrics application, run the following commands to create the Metrics and Cognos DBs:

      db2 -td@ -vf metrics/createDb.sql

      db2 -td@ -vf metrics/appGrants.sql

      db2 -td@ -vf cognos/createDb.sql

      db2 -td@ -vf cognos/appGrants.sql

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

    12. Close the DB2 command line processor.

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


    What to do next

    (DB2 for Linux on System z only.) To improve DB performance, enable the NO FILE SYSTEM CACHING option.


    Create Oracle DBs manually

    Create Oracle DBs with SQL scripts instead of using the IBM Connections DB wizard.

    Follow this procedure if you do not want to use the DB wizard to create your DBs.

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

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

    You must specify the Unicode AL32UTF8 character set.

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

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

    sql> spool on

    sql> spool output_file

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

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

    To manually create the application DB tables:

    1. Log in with the same UID that you used to install the Oracle DB system.

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

    3. Set the ORACLE_SID.

      If you created multiple DBs, specify the DB on which to install the tables by providing the SID for that DB.

    4. Run SQL Plus by entering the following command:

      sqlplus /NOLOG

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

      connect as sysdba

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

    6. Enter the Oracle UID and password.

    7. For each application, change to that application's SQL scripts directory and enter the following command to create the application's DB tables:

        @application_subdirectory/createDb.sql password

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

      Begin the command with the @ symbol.

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

      • Activities: OAUSER
      • Blogs: BLOGSUSER
      • Bookmarks: DOGEARUSER
      • Cognos: COGNOS
      • Communities: SNCOMMUSER
      • Files: FILESUSER
      • Forums: DFUSER
      • Home page: HOMEPAGEUSER
      • Metrics: METRICSUSER
      • Mobile: MOBILEUSER
      • Profiles: PROFUSER
      • Wikis: WIKISUSER

      Each of these default UIDs has a narrower set of privileges than an administrative UID.

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

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

    8. Optional: (Communities only.) Run the following commands:

      @application_subdirectory/calendar-createDb.sql

      @application_subdirectory/calendar-appGrants.sql

    9. Optional: (Dogear only.) Run the following command:

      @application_subdirectory/createHistogramStatsJob.sql

      • This script creates a job to collect histogram statistics.

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

    10. (Home page only.) Run the following command:

      @application_subdirectory/initData.sql

    11. Run the following command to grant access privileges for each application:

      @application_subdirectory/appGrants.sql

    12. Close the SQL Plus window.


    Create SQL Server DBs manually

    Create Microsoft SQL Server DBs with SQL scripts instead of using the IBM Connections DB wizard.

    Follow this procedure if you do not want to use the DB wizard to create your DBs.

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

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

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

    If you installed SQL Server with a default instance, you do not need to supply details of the sql_server_instance_name.

    For example, in a default instance

    • The name of the server is ServerA.

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

    • Use only the server name.

    Alternatively, in an instancename example:

    • ServerB is the name of the server

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

    • Use the ServerB\Connections naming format.

    Finally, where the A-Record is specified as an Alias for SQL Server:

    • ServerC is the name of the server

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

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

    • Use the name of the new A-Record.

      For example, use A-Record-Name\sqlserver_server_instance_name>

    This task describes how to use SQL scripts to create SQL Server DBs for IBM Connections applications.

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

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

    To capture the output of each command to a log file, append the following parameter to each command:

    >> \file_path\db_application.log

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

    For example:

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

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

    1. Configure SQL Server account mode and Windows Authentication mode:

      1. Create a SQL Server Account such as lcuser.

      2. Apply sysadmin permissions.

    2. Configure Local Account Mode:

      1. Create a local account, such as lcuser, on the system that is hosting SQL Server.

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

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

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

    3. Create a directory on the SQL Server system where you can store the application DBs.

      Later on, you need to specify these directories as parameters of the file path flag for the sqlcmd command.

    4. Create a SQL Server UID with system DB administrator privileges that you can use to manage the DB tables or use an existing ID that has administrative privileges, such as sa.

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

    5. Perform the following steps once per application to create each DB:

      1. Open a command prompt and change to the directory to which you copied the DB creation scripts for the application.

      2. Enter the following command to create the application DB table:

        If your DB server has multiple SQL Server instances, add the following parameter as the first parameter in each command:

        -S sqlserver_server_name\sqlserver_server_instance_name

        sqlcmd -U admin_user -P admin_password -i "createDb.sql" -v filepath="path_to_db" password="password_for_application_user" where

        • admin_user and admin_password are the credentials for the UID that you created in a previous step or an existing ID with administrative privileges.

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

        • password_for_application_user is the password for each application DB.

        • The DB UIDs are named as follows:

          • Activities: OAUSER

          • Blogs: BLOGSUSER

          • Bookmarks: DOGEARUSER

          • Cognos:COGNOSUSER

          • Communities: SNCOMMUSER

          • Files: FILESUSER

          • Forums: DFUSER

          • Home page: HOMEPAGEUSER

          • Metrics: METRICSUSER

          • Mobile: MOBILEUSER

          • Profiles: PROFUSER

          • Wikis: WIKISUSER
          Set the password to be associated with this UID.

        When you run the installation wizard, you are asked to provide a UID for the JDBC provider. Set the UID created by the DB creation script and the password that you defined in this step.

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

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

        Example for SQL Server Account Mode:

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

        Example for Local Account Mode:

        sqlcmd -S sql_server_name\sql_server_instance_name -U servername \local_account -P local_account_password -i "createDb.sql" -v filepath="sql_server_data_path" password="password_for_application_user"

        ...where

        • sql_server_account andsql_server_account_password are the credentials for SQL Server. These credentials do not apply for Windows Local Account or Windows Domain Account.

        • servername \local_account are the credentials for the UID.

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

    6. (Home page only) Perform the following steps for the Home page application:

      1. Open a command prompt and change to the directory to which you copied the DB creation scripts for this application.

      2. Enter the following command to create the application DB table:

        sqlcmd -U admin_user -P admin_password -i initData.sql

    7. Optional: (Communities only) Run the following commands:

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

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

    8. Perform the following steps to grant access privileges for the applications:

      1. Open a command prompt and change to the directory to which you copied the DB creation scripts for each application.

      2. Enter the following command:

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


    What to do next

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


    Enable NO FILE SYSTEM CACHING for DB2 on System z

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

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

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

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

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

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

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

    To enable the NO FILE SYSTEM CACHING option:

    1. Log in to the DB2 DB system with the UID of the owner of the DB instance. The UID must have privileges to create a DB, a table space, tables, and indexes.

      If you created multiple DB instances, specify the UID for the first instance.

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

      CONNECT TO OPNACT

      ALTER TABLESPACE OAREGTABSPACE NO FILE SYSTEM CACHING

      CONNECT RESET

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

      CONNECT TO SNCOMM

      ALTER TABLESPACE SNCOMMREGTABSPACE NO FILE SYSTEM CACHING

      ALTER TABLESPACE DFREGTABSPACE NO FILE SYSTEM CACHING

      CONNECT RESET

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

      CONNECT TO FORUM

      ALTER TABLESPACE DFREGTABSPACE NO FILE SYSTEM CACHING

      CONNECT RESET

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

      CONNECT TO PEOPLEDB

      ALTER TABLESPACE USERSPACE4K NO FILE SYSTEM CACHING

      ALTER TABLESPACE TEMPSPACE4K NO FILE SYSTEM CACHING

      ALTER TABLESPACE USERSPACE32K NO FILE SYSTEM CACHING

      ALTER TABLESPACE TEMPSPACE32K NO FILE SYSTEM CACHING

      CONNECT RESET

    6. Close the DB2 command line processor.


    Populate the Profiles DB

    Populate the Profiles DB with data from the LDAP directory.

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

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

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

    • Prepopulate Profiles photos.

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

    • Ensure that Tivoli Directory Integrator is correctly configured.

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

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


    Related

  • Developing custom Tivoli Directory Integrator assembly lines for Profiles

  • Tivoli Directory Integrator commands


    Configure Tivoli Directory Integrator

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

    Install all the required software, including a DB server and LDAP directory, and that you have created the Profiles DB.

    The internal name of the Profiles DB is PEOPLEDB.

    Use Tivoli Directory Integrator to populate the Profiles DB repository from an LDAP directory.

    You can manually run various Profiles tasks by using the appropriate scripts in the TDI Solution directory.

    To configure Tivoli Directory Integrator:

    1. Install Tivoli Directory Integrator, if it is not already installed.

      When prompted for the location of the Solution directory, select Do not specify. Use the current working directory at startup time.

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

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

    2. Make the DB libraries available to Tivoli Directory Integrator by doing one of the following:

      • DB2: Copy the db2jcc.jar and db2jcc_license_cu.jar files from the java subdirectory of the directory where you installed DB2. Paste the files into a temporary location. The wizard will eventually paste the drivers into the jvm/jre/lib/ext subdirectory of Tivoli Directory Integrator.

        For example, if you installed Tivoli Directory Integrator on a Linux system in /opt/IBM/TDI/V7.1, the path would be /opt/IBM/TDI/V7.1/jvm/jre/lib/ext.

      • Oracle: Copy the ojdbc6.jar file from the jdbc/lib subdirectory of the directory where you installed Oracle. Paste the files into a temporary location. The wizard will eventually paste the drivers into the jvm/jre/lib/ext subdirectory of Tivoli Directory Integrator.

        For example, if you installed Tivoli Directory Integrator on a Linux system in /opt/IBM/TDI/V7.1, the path would be /opt/IBM/TDI/V7.1/jvm/jre/lib/ext.

      • SQL Server:

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

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

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

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

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

    3. Edit the ibmdisrv file to increase runtime memory and disable the JIT compiler. To increase the runtime memory, add the two -Xms256M -Xmx1024M space-separated arguments to the Java invocation command; to disable the JIT compiler, add the -Xnojit argument. The ibmdisrv file is stored in the TDI directory.

      • AIX or Linux: ibmdisrv

        After you add the new arguments, the Java invocation command is similar to the following text:

        "$TDI_JAVA_PROGRAM" -Xms256M 
                            -Xmx1024M $TDI_MIXEDMODE_FLAG 
                            -Xnojit 
                            -cp "$TDI_HOME_DIR/IDILoader.jar" "$LOG_4J" com.ibm.di.loader.ServerLauncher "$@" &

      • Windows: ibmdisrv.bat

        After you add the new arguments, the Java invocation command is similar to the following text:

        "%TDI_JAVA_PROGRAM%" -Xms256M -Xmx1024M -Xnojit -classpath "%TDI_HOME_DIR%\IDILoader.jar" 
        %ENV_VARIABLES% com.ibm.di.loader.IDILoader com.ibm.di.server.RS %*"  

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

      127.0.0.1    localhost


    Related tasks

  • Delete or inactivate users in the Profiles DB


    Introduction to IBM Tivoli Directory Integrator

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


    AssemblyLines

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

    How data is organized can differ greatly from system to system.

    For example, DBs usually store information in records with a fixed number of fields. Directories usually work with variable objects called entries, and other systems use messages or key-value pairs.


    Connectors

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

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


    work Entries

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

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


    Attribute mapping

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


    Add source data to the Profiles DB

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

    The Profiles population wizard provides an interface to make it easier for you to populate the Profiles DB with information from the LDAP directory. Alternatively, if you do not want to use the wizard, you can populate the DB manually by manually updating the profiles_tdi.properties file in the TDI directory.

    Although LDAP is the default source, and the only source supported by the Profiles population wizard, other sources are available if you are manually populating the Profiles DB.

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


    Procedure

    To populate the Profiles DB with information from the LDAP server, do one of the following:

    • Run the Profiles population wizard on the server where Tivoli Directory Integrator is installed.

    • Populate the Profiles DB manually by updating the property values relevant to your configuration in the profiles_tdi.properties file.


    Related

  • Add supplemental content to Profiles


    Use the Profiles population wizard

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

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

    Ensure that you have created a Profiles DB, and installed and configured Tivoli Directory Integrator and an LDAP directory.

    Run the population wizard on the system where Tivoli Directory Integrator is installed.

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

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

    You can run the population wizard before, during, or after installing IBM Connections. To populate the Profiles DB, complete the following steps:

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

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

      xhost + // Grant display authority to other users

      If granting display authority to all users is a security concern for you, change the command to grant display authority to a specific user or users.

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

    3. Copy the Wizards directory from the IBM Connections installation media to the system

      ...where Tivoli Directory Integrator is installed.

      Microsoft Windows: If you are installing from disk or ISO, change the permissions for the Wizards folder from Read Only to Write or the population wizard will fail.

    4. Run the following script from the Wizards directory:

      • AIX: ./populationWizard.sh

      • Linux: ./populationWizard.sh

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

      • Microsoft Windows: populationWizard.bat

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

    6. Select Default settings or, if you are resuming an earlier session, click Last successful default settings and click Next.

      This page is shown only if you have already used the wizard to populate the Profiles DB.

    7. Enter the location of Tivoli Directory Integrator and then click Next.

      This page is shown only if the wizard cannot automatically detect your Tivoli Directory Integrator directory.

    8. Select a DB type and click Next.

    9. Enter the following information about the DB, and then click Next:

      Host name

      The name of the system that hosts the DB.

      Port

      The communications port for connecting to the DB. Add a new port or choose one of the following default ports:

      DB2

      50000

      Oracle

      1521

      SQL Server

      1433

      Database name

      The default name of the DB is PEOPLEDB.

      There is no default name for the Oracle DB, Instead, enter the name of the DB instance.

      JDBC driver library path

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

      DB2

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

      Oracle

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

      SQL Server

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

      User ID

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

      Password

      Enter your password.

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

      LDAP server name

      The host or IP address of the LDAP server.

      LDAP server port

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

      Use SSL communication

      Select the check box to enable SSL.

    11. (Optional) Create an empty truststore file where you can store trusted LDAP server certificates. (Complete this step if you want to use SSL. If you already have a truststore file that contains the LDAP server certificates, you can skip this step.) The Profiles population wizard downloads the LDAP server certificates from the LDAP directory for you.

      1. Start the iKeyman utility by running the following file:

        • AIX or Linux:TDI_Install_directory/jvm/jre/bin/./ikeyman
        • Windows: TDI_Install_directory\jvm\jre\bin\ikeyman.exe

        where TDI_Install_directory is the directory

        ...where Tivoli Directory Integrator is installed.

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

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

      3. Select JKS or PKCS12 as the key DB type.

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

      5. Enter a password in the Password Prompt dialog box and then confirm the password. Click OK.

        You need this password when you use the Profiles population wizard.

      6. Exit the iKeyman utility.

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

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

      Truststore file

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

      Keystore password

      Password to access the keystore.

      Keystore type

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

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

      Ensure that the global.properties file in Tivoli Directory Integrator (TDI) is configured with the file trust store name, password and type you just created.

      See: Tivoli Directory Administrator's Guide for Client SSL Configuration of TDI Components. The Understand IBM Tivoli Directory Integrator for IBM Connections white paper is also helpful.

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

    13. Enter the authentication details for the Bind distinguished name (DN) and Bind password, and then click Next.

      The Profiles population wizard does not support anonymous binding for LDAP. If you wish to populate the Profiles DB using anonymous binding, you must populate the DB manually.

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

    15. Map LDAP attributes or JS Functions to the Profiles DB fields.

      For each user in the LDAP, Tivoli Directory Integrator will create a row in the DB, mapping each LDAP attribute or JavaScript function to the corresponding column in the DB. The wizard automatically validates each mapping. If you need to change the default mapping, select the required LDAP attributes or JavaScript functions and create or modify the field.

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

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

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

      Countries

      Add country data to each profile.

      Departments

      Add department data to each profile.

      Organizations

      Add organization data to each profile.

      Employee types

      Add employee-type data to each profile.

      Work locations

      Add location data to each profile.

      Select Yes if you want to mark the profiles of each manager.

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

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

      Countries task
      isocc_sample.csv
      Departments task
      deptinfo_sample.csv
      Organizations task
      orginfo_sample.csv
      Employee types task
      emptype_sample.csv
      Work locations task
      workloc_sample.csv

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

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


    Results

    The Profiles population wizard has populated the Profiles DB with data from the LDAP directory.


    Use the Profiles population wizard in silent mode

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

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

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

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

    You can also modify the mappings files manually.

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

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

      gtar -xvf Lotus_Connections_wizard_aix.tar

      This command creates a directory named after the wizard.

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

    1. Log in to your DB server as the root user or system administrator.

    2. (AIX and Linux only) Grant display authority to all userss under the root user or system administrator:

      xhost + // Grant display authority to other users

      If granting display authority to all users is a security concern for you, change the command to grant display authority to a specific user or users.

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

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

    4. Open a command prompt, change to the TDIPopulation directory, and enter the following commands to launch the wizard in silent mode:

      • AIX/Linux:

        populationWizard.sh -silent response_file 
                          [ -mappingFile mapping_file] 
                          [ -dbPassword db_password] 
                          [ -ldapPassword ldap_password] 
                          [ -sslPassword ssl_password] 
                          [ -help | -? | /help | /? | -usage] 
        

      • Windows:

        populationWizard.bat -silent response_file 
                           [ -mappingFile mapping_file] 
                           [ -dbPassword db_password] 
                           [ -ldapPassword ldap_password] 
                           [ -sslPassword ssl_password] 
                           [ -help | -? | /help | /? | -usage] 
        

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

      If you do not specify a mapping file, the default mapping file for the LDAP directory type is used. These mapping files are located in the Wizards/TDIPopulation directory,

      ...where you can edit the file for the LDAP directory type. For more information about editing the mapping file, see the Mapping fields manually topic. The following table lists the mappings files for applicable LDAP directory types:

      Options to specify a supported LDAP directory

      Directory type Map file
      IBM Lotus Domino defaultMapping_domino.properties
      IBM Tivoli Directory Server defaultMapping_tivoli.properties
      Microsoft Active Directory Application Mode defaultMapping_adam.properties
      Microsoft Windows Server 2003 Active Directory defaultMapping_ad.properties
      Novell Directory Services defaultMapping_nds.properties
      Sun ONE defaultMapping_sun.properties

      The parameters for running the population wizard in silent mode are described in the following table:

      Command parameters

      Parameter Value Description
      responseFile (required) full path to the tdisettings.properties response file After running the population wizard successfully, the tdisettings.properties response file is stored in the Wizards\TDIPopulation directory in the IBM Connections set-up directory.
      mappingFile (optional) full path to the mappings.properties file The mappings.properties file is stored in the Wizards\TDIPopulation directory in the IBM Connections set-up directory. If you do not use specify a different file with the -mappingFile parameter, the wizard uses this file to map properties to the LDAP directory.
      dbPassword (optional) Database password Overwrites the DB password in the response file. If you do not specify the DB password here, you must specify it in the response file.
      ldapPassword (optional) LDAP password Overwrites the LDAP password in the response file. If you do not specify the LDAP password here, you must specify it in the response file.
      sslPassword (optional) SSL key store password Overwrites the SSL key store password in the response file. If you do not specify the SSL password here, you must specify it in the response file.


    Results

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


    The tdisettings.properties file

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

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

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

    Common properties of the tdisettings.properties file

    Property Description Value
    db.hostname Host name of the DB server.  
    db.jdbcdriver Location of the JDBC driver. Example: C\:\\IBM\\SQLLIB\\java

    The extra "\" symbol is an escape character.

    db.name Name of the Profiles DB. Default: PEOPLEDB
    db.password Password for connecting to the DB. The property is required if you do not specify -dbPassword as a command parameter.

    • DB2 default: 50000

    • Oracle default: 1521

    • SQL Server default: 1433
    db.port Database server port for invoking JDBC.

    • DB2 default: 50000

    • Oracle default: 1521

    • SQL Server default: 1433
    db.type DB2, Oracle, or SQL Server. db2 | oracle | sqlserver
    db.user Name of the DB user, such as lcuser. Example: lcuser
    ldap.dn.base LDAP distinguished name search base. Example: dc=example, dc=com
    ldap.enable.ssl Boolean value that determines if SSL is enabled. If the value of this property is yes, you must also provide values for the ssl.keystore, ssl.password, and ssl.type properties.

    yes | no

    ldap.filter Filter for the LDAP. Example: (&(uid=*)(objectclass=inetOrgPerson))
    ldap.hostname Host name of the LDAP server.  
    ldap.password Password for connecting to the LDAP directory. Default: 389 or 663 (SSL)
    ldap.port Communications port of the LDAP server. Default: 389 or 663 (SSL)
    ldap.user DN of the LDAP administrative user.  
    ssl.keyStore File path to the keystore. Required only if the ldap.enable.ssl property is set to yes.  
    ssl.password SSL password. Required only if the ldap.enable.ssl property is set to yes.  
    ssl.type SSL standard. Required only if the ldap.enable.ssl property is set to yes. JKS | PKCS12
    task.list Tasks that the Profiles population wizard can perform. You can choose from the following options: LDAP_OPTIONAL_TASK_MARK_MANAGER, LDAP_OPTIONAL_TASK_FILL_COUNTRIES, LDAP_OPTIONAL_TASK_FILL_DEPARTMENT, LDAP_OPTIONAL_TASK_FILL_ORGANIZATION, LDAP_OPTIONAL_TASK_FILL_EMPLOYEE, and LDAP_OPTIONAL_TASK_FILL_WORK_LOCATION

    To execute multiple tasks, separate the tasks with the comma symbol.

    Example: LDAP_OPTIONAL_TASK_MARK _MANAGER,LDAP_OPTIONAL _TASK_FILL_COUNTRIES
    task.country.csv File path to the isocc.csv file. Required if you specify LDAP_OPTIONAL_TASK_FILL_COUNTRIES in the task.list property. Example: C\:\\build\\isocc.csv

    The extra "\" symbol is an escape character.

    task.department.csv File path to the deptinfo.csv file. Required if you specify LDAP_OPTIONAL_TASK_FILL_DEPARTMENT in the task.list property. Example: C\:\\build\\deptinfo.csv

    The extra "\" symbol is an escape character.

    task.empoyeetype.csv File path to the emptype.csv file. Required if you specify LDAP_OPTIONAL_TASK_FILL_EMPLOYEE in the task.list property. Example: C\:\\build\\emptype.csv

    The extra "\" symbol is an escape character.

    task.organization.csv File path to the orginfo.csv file. Required if you specify LDAP_OPTIONAL_TASK_FILL_ORGANIZATION in the task.list property. Example: C\:\\build\\orginfo.csv

    The extra "\" symbol is an escape character.

    task.worklocation.csv File path to the workloc.csv file. Required if you specify LDAP_OPTIONAL_TASK_FILL_ORGANIZATION in the task.list property. Example: C\:\\build\\workloc.csv

    The extra "\" symbol is an escape character.

    TDI.dir Installation location of Tivoli Directory Integrator. Example: C\:\\IBM\\TDI\\V7.1

    The extra "\" symbol is an escape character.

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


    Manually populating the Profiles DB

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

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

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

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

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

    The internal name of the Profiles DB is PEOPLEDB.

    After installing the Profiles DB and defining mapping and validation to populate the Profiles DB:

    1. Update the profiles_tdi.properties file to specify values for the following properties.

      To locate this file, extract the tdisol.tar|zip file from the tdisol directory in your IBM Connections installation media. After extraction, the file is located in the tdisol.tar|zip/tdisol/TDI directory.

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

      source_ldap_url

      Universal resource locator of the LDAP directory. Enables programs to access the LDAP directory. Use the following syntax to specify the value:

       source_ldap_url=ldap://myldap.enterprise.example.com:389 

      source_ldap_user_login

      If you cannot use Anonymous search, a user login name is required . Use the following syntax to specify the value:

      source_ldap_user_login=uid=wpsbind,cn=users,l=Bedford Falls,
      st=New York,c=US,ou=Enterprise,o=Sales Division,dc=example,dc=com

      source_ldap_user_password

      If you cannot use anonymous search, a user password is required, along with user login name. Use the following syntax to specify the value:

      {protect}-source_ldap_user_password=wpsbind  

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

      source_ldap_search_base

      A portion of the LDAP DN that must be part of all entries processed. This base usually contains the expected organization (o) value, such as source_ldap_search_base=o=ibm.com. Use the following syntax to specify the value:

      source_ldap_search_base=l=Bedford Falls,st=New York,c=US,
      ou=Enterprise,o=Sales Division,dc=example,dc=com   

      source_ldap_search_filter

      A search filter to further refine the entries used. A typical value might be source_ldap_search_filter=cn=*. Use the following syntax to specify the value:

      source_ldap_search_filter=(&(uid=*)(objectclass=inetOrgPerson))   

      source_ldap_use_ssl

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

      dbrepos_jdbc_driver

      JDBC driver used to access the Profiles DB repository. The default value of the properties file references the DB2 DB provided with Profiles as follows:

      dbrepos_jdbc_driver=com.ibm.db2.jcc.DB2Driver
      If you are using DB2, you do not need to modify this value. If you are using an Oracle DB, change the value to reference an Oracle DB. The following values are examples:

      dbrepos_jdbc_driver=oracle.jdbc.driver.OracleDriver

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

      com.microsoft.sqlserver.jdbc.SQLServerDriver

      dbrepos_jdbc_url

      Universal resource locator of the DB that you created. This value specifies the peopledb DB, and must include the port. For example:

      • DB2:

         jdbc:db2://localhost:50000/peopledb

      • Oracle:

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

      • SQL Server:

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

      dbrepos_username

      The user name used to authenticate to the DB that you created. Use the following syntax to specify the value:

      dbrepos_username=<db_admin_id>   

      dbrepos_password

      The password used to authenticate to the DB that you created. Use the following syntax to specify the value:

      {protect}-dbrepos_password=act1vities   

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

    2. Complete the steps in the Mapping fields manually task. You must complete the mapping task before continuing.

    3. Run the ./collect_dns.sh or collect_dns.bat script to create a file containing the distinguished names (DNs) to be processed from the source LDAP directory.

      Before starting the script, ensure that you have completed the steps in the Mapping fields manually task.

      If the script does not run, you might need to enable its Executable attribute by running the chmod command first. The Executable attribute of a script can become disabled after the script is copied from a read-only medium such as DVD.

      The new file is named collect.dns by default but you can rename it if necessary. If you change the file name, update the source_ldap_collect_dns_file parameter in the profiles_tdi.properties file.

      After the script runs, it creates a log file called ibmdi.log in the tdisol.tar|zip/tdisol/TDI directory. Examine this file to find out whether any errors occurred during the process.

    4. Populate the DB repository from the source LDAP directory by running the ./populate_from_dn_file.sh or populate_from_dn_file.bat script.

      Depending on how many records you are processing, this step could take many hours.

      For example, 5,000 records might take a few minutes, while half a million records could take over 12 hours. Tivoli Database Integrator prints a message to the screen after every 1,000 iterations to inform you of its progress.

      If a failure occurs during processing, such as loss of the network connection to the LDAP directory server, start processing the names from where it was interrupted. Examine the PopulateDBFromDNFile.log file in the logs subdirectory to find out which distinguished name was last successfully processed. The ibmdi.log file also tracks the tasks that you run. Edit the collect.dns file to remove all entries up to and including the last successfully processed entry. Start the task again. You can repeat this step as many times as necessary until all the distinguished names are processed.

    5. Optional: If you are setting the PROF_IS_MANAGER field based on PROF_MANAGER_UID references in other employee records, run the ./mark_managers.sh or mark_managers.bat script.

      Manager identification is not performed as part of the previous record population step because it must run across all the records and it is possible that the initial record population step does not complete in a single pass for large organizations.

      If the manager designation was not part of the source records for your data set, you can run this task to analyze all the records after population. This task will take each user record and see if it is referenced as the manager for any other users. If yes, the user will be marked as a manager. If not, the user will be marked as not a manager. If you need to use this process to set this profile attribute, you will also need to run it periodically to perform updates. For more information, see Synchronizing user data between Profiles and the LDAP directory.

    6. Optional: Run additional and optional scripts to populate additional fields.

      For example, run the ./fill_country.sh or fill_country.bat script to populate the Country table from the isocc.csv file.

  • Customize the Profiles data model


    Tivoli Directory Integrator solution properties for Profiles

    IBM Connections maps LDAP, DB, and other properties with Tivoli Directory Integrator configuration parameters.

    The properties described in this topic are found in the supplied profiles_tdi.properties file.

    The TDI parameter column in the tables contains the name of the parameter in the LDAP connector. See the Tivoli Directory Integrator product documentation for more information.

    You can find additional information about LDAP properties at ibm.com® and other sites.

    All file paths specified are relative to the TDI solution directory.

    The following properties are associated in an LDAP directory that will be used as the source for the data. If you wish to use a source other than LDAP, see Manually populating the Profiles DB.

    LDAP Properties

    Property TDI parameter Definition
    source_ldap_url LDAP URL hostname and LDAP URL Port

    Required.

    The LDAP web address used to access the source LDAP system. The port is required and is typically 389 for non-SSL connections.

    Express this value in the form of ldap://host:port. For example: ldap://myservername.com:389.

    If using the population wizard, this property is configured using the LDAP server name and LDAP server port on the LDAP server connection page.

    The LDAP query constructed from the source URL, search base, and search filter are stored in a source url property, which can be used to segment the Profiles DB user set during synchronization. Using different values for this property, which may be equivalent (for example referencing the LDAP server by IP address or DNS name) is not advised.

    The default value is ldap://localhost:389.

    source_ldap_use_ssl LDAP URL Use SSL connection

    Required if you are using SSL to authenticate.

    Set to either true or false.

    Set to true if you are using SSL (for example if you are using port 636 in the LDAP URL).

    The default value is false.

    If using the population wizard, this property is configured with the Use SSL communication checkbox on the LDAP server connection page.

    source_ldap_user_login Login user name

    Login user name used for authentication. You can leave this blank if no authentication is required.

    If using the population wizard, this property is configured in the Bind distinguished name (DN) field on the LDAP authentication properties page.

    source_ldap_user_password Login password

    Login password used for authentication. Leave this blank if no authentication is required. The value will be encrypted in the file the next time it is loaded.

    If using the population wizard, this property is configured in the Bind password field on the LDAP authentication properties page.

    source_ldap_search_base or source_ldap_user_search_base Search Base

    The search base (the location from where the search begins) of the iterating directory. The search begins at this point in the ldap directory structure and searches all records underneath. This should be a distinguished name.

    Most directories require a search base, and as such it must be a valid distinguished name. Some directory services allow you to specify a blank string which defaults to whatever the server is configured to do.

    A default value is not specified.

    If using the population wizard, this property is configured in the LDAP user search base field on the LDAP page.

    source_ldap_search_filter or source_ldap_user_search_filter Search Filter

    Search filter used when iterating the directory.

    This determines which objects are included or excluded in the search. If using the search base and the specified search filter properties do not allow you to adequately construct your search set, use the source_ldap_required_dn_regex property.

    Search filters are used by those directories to select entries from which data is retrieved from a search operation. Care should be taken when specifying search filters as they can affect performance of the directory being searched. The directory server schema being queried can impact performance.

    A default value is not specified.

    If using the population wizard, this is the LDAP user search filter field on the LDAP authentication properties page.

    source_ldap_sort_page_size Page size

    If specified, the LDAP Connector tries to use paged mode search. Paged mode causes the directory server to return a specific number of entries (called pages) instead of all entries in one chunk. Not all directory servers support this option. The default value is 0, which indicates that paged mode is disabled.

    The default value is 0.

    This parameter is not configurable when using the population wizard.

         
    source_ldap_authentication_method Authentication Method

    Options include the following:

    Anonymous

    This method provides minimal security.

    Simple

    This method uses a login user name and password to authenticate. It is treated as anonymous if no user name and password are provided.

    CRAM-MD5

    Challenge/Response Authentication Mechanism using Message Digest 5. This method provides reasonable security against various attacks, including replay.

    SASL

    Simple Authentication and Security Layer. This method adds authentication support to connection-based protocols. Specify parameters for this type of authentication using the Extra Provider Parameters option.

    This parameter is not configurable when using the population wizard.

    source_ldap_collect_dns_file  

    Name of the file used to collect distinguished names (DNs) by the collect_dns.bat/sh process from the source, and then used during population by the populate_from_dn_file.bat/sh processes to look up entries to add to the DB repository.

    This file can also be constructed by hand to populate an explicit set of users.

    The default value is collect.dns.

    This parameter is not configurable when using the population wizard.

    source_ldap_escape_dns  

    Indicates that special characters have not been escaped properly and identifies them so the processor can find those characters and escape them. Special characters are:

    • , (comma)

    • = (equals)

    • + (plus)

    • < (less than)

    • > (greater than)

    • # (number sign)

    • ; (semicolon)

    • \ (backslash)

    • " (quotation mark)

    The backslash is used to escape special characters. A plus sign is represented by \+ and a backslash is represented by \\.

    if your distinguished names contains these special characters and you receive errors when running the collect_dns/populate_from_dn_file process, set this property to true so that the characters are escaped.

    The default value is false.

    This parameter is not configurable when using the population wizard.

    source_ldap_required_dn_regex  

    Allows a regular expression to be used to limit the distinguished names (DNs) which are processed by providing a regular expression which must be matched. If the regular expression is not matched, that particular record is skipped. Although the search filter property gives some flexibility, in case this is not sufficient, you can use a more powerful regular expression.

    A default value is not specified.

    This parameter is not configurable when using the population wizard.

    source_ldap_sort_attribute Sort Attribute

    Specifies server-side sorting. This parameter instructs the LDAP server to sort entries matching the search base on the specified field name. Server-side sorting is an LDAP extension. The iterating directory must be able to support this sorting extension.

    A default value is not specified.

    This parameter is not configurable when using the population wizard.

    source_ldap_iterate_with_filter  

    This property should be used if the size of the data to be retrieved from LDAP exceeds the search limit from the LDAP.

    For example, if your search parameters would return 250K records but the LDAP only allows 100K to be returned at a time, this parameter must be used.

    If the data is too large, an LDAP size limit exceeded error message is generated. To configure this mechanism, see the Populating a large user set topic.

    When set to true, this specifies that the default iteration assembly line use the collect_ldap_dns_generator.js file to iterate over a set of LDAP search bases and filters. The cconfig setting replaces the sync_all_dns_forLarge and collect_dns_iterate scripts used in earlier releases.

    This parameter is not configurable when using the population wizard.

    The default value is false.

    source_ldap_binary_attributes Binary Attributes

    By default, this property is set internally to GUID, objectGUID, objectSid, sourceObjectGUID. Any additional values specified in the property are appended to the list.

    This parameter is not configurable when using the population wizard.

    The default value is GUID.

    source_ldap_time_limit_seconds Time Limit

    Specifies the maximum number of seconds that can be used when searching for entries; 0 = no limit.

    This parameter is not configurable when using the population wizard.

    The default value is 0.

    source_ldap_map_functions_file  

    Specifies the location of any referenced function mappings.

    When using the population wizard, the functions shown in the mapping dialog are read from and written to this file.

    The default value is profiles_functions.js.

    source_ldap_logfile  

    In addition to the standard logs/ibmdi.log file, output from the populate_from_dn_file.bat or populate_from_dn_file.sh task is written to this file.

    This parameter is not configurable when using the population wizard.

    The default value is logs/PopulateDBFromSource.log.

    source_ldap_compute_function_for_givenName  

    Connections allows Javascript functions for setting values of common LDAP fields such as cn, sn, givenName to execute before Connections performs its mapping.

    For example, sn and/or givenName can be parsed from cn (common name).

    This parameter is not configurable when using the population wizard.

    A default value is not specified.

    source_ldap_compute_function_for_sn  

    Connections allows Javascript functions for setting values of common LDAP fields such as cn, sn, givenName to execute before Connections performs its mapping.

    For example, sn and/or givenName can be parsed from cn (common name).

    This parameter is not configurable when using the population wizard.

    A default value is not specified.

    source_ldap_collect_updates_file  

    This property is no longer used.

    source_ldap_manager_lookup_field  

    This property is no longer used.

    source_ldap_secretary_lookup_field  

    This property is no longer used.

    Many properties in the TDI LDAP connector are not mapped to Profiles TDI properties. To configure properties other than those listed here, consider using an alternate source repository and creating your own specialized configuration. Use the LDAP iterator and connectors provided with the TDI solution directory as a starting point, see Using a custom source repository connector for more information.

    The following properties are associated with the Profiles DB repository.

    The following properties must be set in the profiles_tdi.properties file, even if developing your own assembly lines using the connectors provided in the Profiles TDI solution directory. These properties are not configured in the Connector panels, but rather in the profiles_tdi.properties file.

    Profiles Database Properties

    Property TDI parameter Definition
    dbrepos_jdbc_driver JDBC Driver

    Required.

    The JDBC driver implementation class name used to access the Profiles DB repository.

    For DB2, the default is com.ibm.db2.jcc.DB2Driver. For example:

    dbrepos_jdbc_driver=com.ibm.db2.jcc.DB2Driver

    For Oracle, the default is oracle.jdbc.driver.OracleDriver. For example:

    dbrepos_jdbc_driver=oracle.jdbc.driver.OracleDriver

    If you are using a Microsoft SQL Server DB, change the value to reference a SQL Server driver, for example:

    dbrepos_jdbc_driver=com.microsoft.sqlserver.jdbc.SQLServerDriver

    This corresponds to the JDBC driver path in the population wizard. If not using the wizard, this library must be present in the CLASSPATH of Tivoli Directory Integrator, or Tivoli Directory Integrator cannot load the library when initializing the Connector and cannot communicate with the Relational Database (RDBMS).

    To install a JDBC driver library so that Tivoli Directory Integrator can use it, copy it into the TDI_install_dir/jars directory, or a subdirectory such as TDI_install_dir/jars/local.

    dbrepos_jdbc_url JDBC URL

    Required.

    JDBC web address used to access the Profiles DB repository.

    You must modify the hostname portion and port to reference your server information.

    You can find this information by accessing the WAS Administration Console (http://yourhost:9060), and then selecting Resources > JDBC > Data sources > profiles.

    The default syntax is for DB2, unless using the wizard, but the default uses a local host. If the DB2 is not on the same system as the TDI solution directory, update the URL with the host.

    If you are using an Oracle DB, use the following syntax:

    dbrepos_jdbc_url=jdbc:oracle:thin:@<host_name>:1521:orcl

    If you are using a SQL Server DB, use the following syntax:

    dbrepos_jdbc_url=jdbc:sqlserver://<host_name>:1433;DBName=PEOPLEDB
    dbrepos_username User name

    Required.

    User name under which the DB tables, which are part of the Profiles DB repository, are accessed.

    dbrepos_password Password

    Required.

    Password associated with the username under which the DB tables, which are part of the Profiles DB repository, are accessed.

    dbrepos_mark_manger_if_referenced  

    This property is no longer used.

    The following properties are associated with the task that monitors the Profiles employee draft table for changes and transmits them through a DSML v2 connector.

    Change Monitoring Properties

    Property TDI parameter Definition
    monitor_changes_dsml_server_authentication  

    Type of authentication used by the DSML server update requests. Options include the following:

    HTTP basic authentication

    A method designed to allow a web browser, or other client program, to provide credentials, in the form of a user name and password, when making a request.

    Anonymous

    This method provides minimal security.
    monitor_changes_dsml_server_url   Required if you are transmitting user changes back to the source repository.

    Web address of the DSML server to which the DSML update requests should be sent.

    monitor_changes_dsml_server_username   Required if you are transmitting user changes back to the source repository.

    User name used for authentication to the DSML server.

    monitor_changes_dsml_server_password   Required if you are transmitting user changes back to the source repository.

    Password used for authentication to DSML server that the DSML update requests should be sent to.

    monitor_changes_map_functions_file  

    Path to the file containing mapping functions for mapping from a changed DB field to a source. for example LDAP field. This is only needed if changes made to the source based on DB repository field changes are not mapped one-to-one. You can use the same file you use to map from source to DB repository fields, assuming the functions are named appropriately.

    monitor_changes_sleep_interval  

    Polling interval, in seconds, between checks for additional changes when no changes exist.

    The following properties are associated with the Tivoli Directory Integrator processing that reads a Tivoli Directory Server change log and subsequently updates the DB repository with those changes.

    Tivoli Directory Server Change Log Properties

    Property TDI parameter Definition
    ad_changelog_ldap_url  

    LDAP web address used to access the LDAP system that was updated. For example:

    ldap://host:port
    ad_changelog_ldap_user_login  

    Login user name to use to authenticate with an LDAP system that has been updated. You can leave this blank if no authentication is needed.

    ad_changelog_ldap_user_password  

    Login user name to use to authenticate with an LDAP that has been updated. You can leave this blank if no authentication is needed. The value will be encrypted in the file the next time it is loaded.

    ad_changelog_ldap_search_base    
    ad_changelog_ldap_use_ssl  

    Defines whether or not to use SSL in authenticating with an LDAP system that was updated. The options are true and false.

    ad_changelog_timeout    
    ad_changelog_sleep_interval  

    Polling interval, in seconds, between checks for additional changes when no changes exist.

    ad_changelog_use_notifications  

    Indicates whether to use changelog notifications rather than polling. If true, the tds_changelog_sleep_interval is not applicable since polling is not used. The options are true and false.

    ad_changelog_ldap_page_size    
    ad_changelog_start_at  

    Change number in the Active Directory changelog to start at. Typically this is an integer, while the special value EOD means start at the end of the changelog.

    ad_changelog_ldap_required_dn_regex.    
    tds_changelog_ldap_authentication_method Authentication Method

    Authentication method used to connect to LDAP to read records. Options include the following:

    Anonymous

    This method provides minimal security.

    Simple

    This method uses a login user name and password to authenticate. It is treated as anonymous if no user name and password are provided.

    CRAM-MD5

    Challenge/Response Authentication Mechanism using Message Digest 5. This method provides reasonable security against various attacks, including replay.

    SASL

    Simple Authentication and Security Layer. This method adds authentication support to connection-based protocols. Specify parameters for this type of authentication using the Extra Provider Parameters option.
    tds_changelog_ldap_changelog_base ChangelogBase

    Changelog base to use when iterating through the changes. This is typically cn=changelog.

    tds_changelog_ldap_time_limit_seconds Time Limit

    Search for entries must take no more than this number of seconds; 0 = no limit.

    tds_changelog_ldap_url LDAP URL

    LDAP web address used to access the LDAP system that was updated. For example:

    ldap://host:port
    tds_changelog_ldap_use_ssl Use SSL

    Defines whether or not to use SSL in authenticating with an LDAP system that was updated. The options are true and false.

    tds_changelog_ldap_user_login Login user name

    Login user name to use to authenticate with an LDAP system that has been updated. You can leave this blank if no authentication is needed.

    tds_changelog_ldap_user_password Login password

    Login user name to use to authenticate with an LDAP that has been updated. You can leave this blank if no authentication is needed. The value will be encrypted in the file the next time it is loaded.

    tds_changelog_sleep_interval  

    Polling interval, in seconds, between checks for additional changes when no changes exist.

    tds_changelog_start_at_changenumber  

    Change number in the Tivoli Directory Server changelog to start at. Typically this is an integer, while the special EOD value means start at the end of the changelog.

    tds_changelog_use_notifications  

    Indicates whether to use changelog notifications rather than polling. If true, the tds_changelog_sleep_interval is not applicable since polling is not used. The options are true and false.

    The following properties are available in the profiles_tdi.properties file and are associated with Tivoli Directory Integrator debug activities.

    The debug properties enable TDI debugging for an entire assembly. In addition, enabling debug_update_profile which enables debugging for the commands that use the Profiles Connector, also enables Java debugging for the following packages.

    • log4j.logger.com.ibm.lconn.profiles.api.tdi=ALL

    • log4j.logger.com.ibm.lconn.profiles.internal.service=ALL

    • log4j.logger.java.sql=ALL

    The following properties are not configurable when using the population wizard.

    Tivoli Directory Integrator Debug and Trace Properties

    Property TDI parameter Definition
    sync_all_dns   For information about sync_all_dns, see Understanding how the sync_all_dns process works.
    debug_managers  

    Flag that instructs TDI to log additional debug information for the following command(s).

    The options are true and false.

    To enable, set as debug_managers=true.

    This property maps as follows:

    debug_managers
        mark_managers

    The default setting is false.

    debug_photos  

    Flag that instructs TDI to log additional debug information for the following command(s).

    The options are true and false.

    This property maps as follows:

    debug_photos
        load_photos_from_files
        dump_photos_to_files

    The default setting is false.

    debug_pronounce  

    Flag that instructs TDI to log additional debug information for the following command(s).

    The options are true and false.

    This property applies to the following command(s):

    debug_pronounce
        load_pronounce_from_files, 
        dump_pronounce_to_files

    The default setting is false.

    debug_fill_codes  

    Flag that instructs TDI to log additional debug information for the following command(s).

    The options are true and false.

    This property applies to the following command(s):

    debug_fill_codes
        fill_country
        fill_department
        fill_emp_type
        fill_organization
        fill_worklok

    The default setting is false.

    debug_draft  

    Flag that instructs TDI to log additional debug information for the following command(s).

    The options are true and false.

    This property applies to the following command(s):

    debug_draft
        process_draft_updates
        reset_draft_iiterator_state
        set_draft_iterator_count

    The default setting is false.

    debug_update_profile  

    Flag that instructs TDI to log additional debug information for the following command(s).

    The options are true and false.

    This property applies to the following command(s):

    debug_update_profile
        populate_from_dn_file
        delete_or_inactivate_employees
        populate_from_xml_file
        process_ad_changes
        process_tds_changes

    The default setting is false.

    debug_collect  

    Flag that instructs TDI to log additional debug information for the following command(s).

    The options are true and false.

    This property applies to the following command(s):

    debug_collect
        collect_dns

    The default setting is false.

    debug_special  

    Flag that instructs TDI to log additional debug information for the following command(s).

    The options are true and false.

    This property applies to the following command(s):

    debug_special
        unused at present

    The default setting is false.

    trace_profile_tdi_javascript  

    Enables generation of an internal Javascript trace file.

    Options are OFF, FATAL, ERROR, WARN, INFO, DEBUG, TRACE, ALL ( values are not case-sensitive).

    The default setting is OFF.


    Batch files for processing Profiles data

    IBM Connections provides several batch files that automate the collection and processing of LDAP data for the Profiles DB.


    Batch file functions

    The name of each batch file ends with the .sh suffix for the IBM AIX and Linux operating systems and with the .bat suffix for the Microsoft Windows operating system.

    The following list describes each batch file and its functions. You can search for more information about these files in the help topics.

    clearLock

    Delete the lock file that is generated by the sync_all_dns batch file.

    collect_dns

    Create a file called collect.dns that contains the distinguished names from the LDAP directory. This batch file is used in the first step of the process to populate the Profiles DB.

    delete_or_inactivate_employees

    Deactivate employee records in the Profiles DB. The records are not removed from the Profiles DB but are set to an inactive state and the employee login and mail address values are removed.

    These changes are propagated to the member and login tables in the DBs of installed applications. The records to be deactivated are defined in the delete_or_inactivate_employees.in file. To remove users from only the Profiles DB, change the value of the sync_delete_or_inactivate property in the profiles_tdi.properties file to delete.

    You must manually create the delete_or_inactivate_employees.in file. Use the following format for adding entries:

    $dn:cn=Any User3,cn=Users,l=WestfordFVT,st=Massachusetts,c=US,ou=Lotus,o=Software Group,dc=ibm,dc=com uid:Any User3

    dump_photos_to_files

    Copy all the photos from the PHOTO table in the Profiles DB to a folder on the local system called dump_photos. This batch file also creates a local file called collect_photos.in that contains the UID and URL of each photo.

    dump_pronounce_to_files

    Copy all the pronunciation files from the PRONUNCIATION table in the Profiles DB to a folder on the local system called dump_pronounce. the local files. This batch file also creates a local file called collect_pronounce.in that contains the UID and URL of each pronunciation file.

    fill_country

    Populate the COUNTRY table in the Profiles DB from the isocc.csv file.

    fill_department

    Populate the DEPARTMENT table in the Profiles DB from the deptinfo.csv file.

    fill_emp_type

    Populate the EMP_TYPE table in the Profiles DB from the emptype.csv file.

    fill_organization

    Populate the ORGANIZATION table in the Profiles DB from the orginfo.csv file.

    fill_workloc

    Populate the WORKLOC table in the Profiles DB from the workloc.csv file.

    load_photos_from_files

    Load all the photos from the dump_photos folder on the local system to the PHOTO table in the Profiles DB. This batch file reads the collect_photos.in file and the dump_photos folder that you created with the dump_photos_to_files batch file. This batch file loads photos only for people who are already recorded in the DB.

    load_pronounce_from_files

    Load all the pronunciation files from the dump_pronounce folder on the local system to the PRONUNCIATION table in the Profiles DB. This batch file reads the collect_pronounce.in file and the dump_pronounce folder that you created with the dump_pronounce_to_files batch file. This batch file loads pronunciation files only for people who are already recorded in the DB.

    mark_managers

    Set the PROF_IS_MANAGER field in the Profiles DB, based on the value of the PROF_MANAGER_UID field in the employee records.

    populate_from_dn_file

    Populate the Profiles DB from the source LDAP directory. This batch file reads the collect.dns data file that you created with the collect_dns batch file. The batch file also updates existing employee records in the Profiles DB.

    process_ad_changes

    Synchronize LDAP directory changes with the Profiles DB when the LDAP directory type is Microsoft Active Directory. This batch file is stored in the solution-dir/Samples directory. For more information, go to the Active Directory Change Detection Connector topic in the Tivoli Directory Integrator information center. For information about permissions, go to the How to poll for object attribute changes topic on the Microsoft Support website.
    The sync_all_dns script is recommended when you want to synchronize changes in the LDAP directory with the Profiles DB.

    process_draft_updates

    Synchronize changes from the Profiles DB back to the LDAP directory.

    process_tds_changes

    Synchronize LDAP directory changes with the Profiles DB when the LDAP directory type is IBM Tivoli Directory Server. This batch file is stored in the solution-dir/Samples directory.

    The sync_all_dns script is recommended when you want to synchronize changes in the LDAP directory with the Profiles DB.

    sync_all_dns

    Update the Profiles DB to capture changes to the LDAP directory. This synchronization process includes updates to employee records and additions and deletions of records.

    tdienv

    Set the correct environment for IBM Tivoli Directory Integrator. This batch file sets the path to the Tivoli Directory Integrator program, the Tivoli Directory Integrator host, and the Tivoli Directory Integrator port. If you installed Tivoli Directory Integrator to a custom location, modify the path to that location before using this batch file.


    Populate a large user set

    Populate the Profiles DB from an LDAP directory with a large user population.

    In very large organizations, the number of users in the LDAP directory exceeds the capacity of the Tivoli Directory Integrator assembly lines for Profiles. To overcome this restriction, you can populate the DB by using manual TDI assembly lines. You cannot use the Profiles population wizard.

    For related information and details, see Tivoli Directory Integrator help.


    Limits with large user sets

    The LDAP administrator can change the LDAP size limit. The capacity of the standard assembly lines provided with IBM Connections is 100,000 users. In some cases, you can modify the maximum number of entries returned from the LDAP or adjust the source_ldap_page_size parameter in the profiles_tdi.properties file.

    For example, set the parameter to the maximum number of records the LDAP repository will return, using the following sample statement:

    source_ldap_page_size=1000 
    If you receive the following, adjust the source_ldap_page_size parameter in the profiles_tdi.properties file.

    LDAP: error code 4 - Sizelimit Exceeded

    If neither of these alternatives is successful, use a special set of assembly lines to populate your Profiles DB from the LDAP directory.


    Alternative population process

    If you have a very large set of data, set the source_ldap_iterate_with_filter property in the profiles_tdi.properties file to true. This uses the collect_ldap_dns_generator.js file to retrieve search criteria for a batch of records. The batch is always smaller than the limit of the LDAP retrieval.

    The collect_ldap_dns_generator.js file constructs a search filter with a portion of UIDs but does not modify the search base. It is data-specific so you need to modify it for your own deployment. Modify suppliesSearchBase() or suppliesSearchBase(), depending on which filter is used in the LDAP retrieval.

    If one of the filters is changed to return true (in the supplied file, suppliesSearchBase returns true), the corresponding function, either getNextSearchBase() or getNextSearchFilter(), is called in iterations. Each time the function is called it returns a string with the next search base or filter to use. When it reaches the end of the batch, it returns null.

    In the sample file, the UID is examined over a range of its first characters.

    The process first uses some special characters and then examines the first two characters of the UID string, or example aa*, ab*, and so on. After it reaches zz* it returns null and the collect_dns assembly line stops processing. You can then run populate_from_dn_file.


    Map fields manually

    To populate the Profiles DB with data from the enterprise LDAP directory, map the content of the fields in the DB to the fields in the LDAP directory.

    Edit the map_dbrepos_from_source.properties file to map fields between the Profiles DB and the LDAP directory. Open the profiles_functions.js file to see the options for the different mapping functions. You can add your own functions if necessary.

    When you run the Profiles population wizard in interactive mode, it generates two property files in the Wizards\TDIPopulation directory: a tdisetting.properties file and a mappings.properties file. The properties in mappings.properties are very similar to those in map_dbrepos_from_source.properties.

    The internal name of the Profiles DB is PEOPLEDB.

    To map fields:

    1. On the system hosting your Tivoli Directory Integrator installation, create a subdirectory in which to store the Tivoli Directory Integrator solution directory. Make sure that the file path does not contain spaces. Do not, for example, create the subdirectory in the Program Files directory in Microsoft Windows.

    2. Copy the tdisol compressed file from the TDISOL directory of the IBM Connections installation media to the system

      ...where you installed Tivoli Directory Integrator.

    3. Use appropriate tools, extract the tdisol file to the directory that you created in Step 1. This process creates a Tivoli Directory Integrator Solution directory called TDI.

    4. From the TDI solution directory, open the tdienv.bat or tdienv.sh file in a text editor. Ensure that the path to the Tivoli Directory Integrator installation directory is specified correctly in the TDIPATH variable. If the path is not correct, edit the TDIPATH environment variable.

      • AIX or Linux:

        The default value for TDIPATH is:

        export TDIPATH=/opt/IBM/TDI/V7.1 

      • Windows:

        The default value for TDIPATH is:

        SET TDIPATH=C:\IBM\TDI\V7.1
      Other scripts in the solution directory use this Tivoli Directory Integrator path or tdienv.bat or tdienv.sh file to find Tivoli Directory Integrator files.

    5. Edit the properties files to define the mapping between the LDAP directory and the Profiles DB. Consider using LDAP viewer software to help you map the fields. To define the mappings that are used when populating the Profiles DB from the enterprise directory:

      1. From the TDI directory, open the map_dbrepos_from_source.properties file in a text editor.

      2. Add or modify the field values. Any values that you omit or set to null are not populated in the DB. You can modify the values in one of the following ways:

        1:1 mapping

        If one field in the Profiles DB matches one field in the enterprise directory, type the name of the field in the Profiles DB and set it equal to the associated source DB LDAP property. For example:

        bldgId=buildingname

        Complex mapping

        If there is a more complex relationship between the fields in the Profiles DB and enterprise directory, such as the content of the property in the enterprise LDAP directory must be split into multiple fields in the Profiles DB, use a JavaScript function to define the relationship. Define the function in the profiles_functions.js file and wrap the name of the JavaScript function in braces {}. Begin function names with func_ so that you can more easily identify them. For example:

        bldgId={func_map_to_db_bldgId}

        See Example complex mapping of Profiles data for an example of complex mapping.

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

    6. Open the tdi-profile-config.xml file. After the IBM Tivoli Directory Integrator Solution files are extracted, the file is located in the following directory:

      TDI/conf/LotusConnections-config

    7. Modify the file to configure the extension attribute, specifying the property's name and mapping from the source. Use the following parameters:

      Custom extension attribute parameters

      Parameter Description
      extensionId The ID of the extension attribute.

      This parameter is required.

      sourceKey The name of the attribute from the source.

      This parameter is required.

      For example, to add a simple attribute called spokenLangs, the configuration would look like the following extract from the tdi-profiles-config.xml file:

      <simpleAttribute extensionId="spokenLangs"
          sourceKey="spokenLang"/>

      The formatting between the tdi-profile-config.xml and the profiles-config.xml files is compatible, so you can copy and paste configuration information between the files. For the extension to be displayed in the user interface, the modifications must be made in profiles-config.xml.

      To leverage the custom attribute in the Profiles user interface or REST API, configure the application per the instructions in the Customize Profiles section. For a detailed example that uses custom attributes, see Creating a simple profile data model and template customization.

    8. Save your changes to the tdi-profile-config.xml file.

    9. Optional: Write a JavaScript function that combines different attributes from the LDAP directory to map a customized extension attribute for the Profiles DB:

      1. Add the extension attribute function definition in the map_dbrepos_from_source.properties file, using the following format:

        extattr.spokenLangs={func_map_to_langs}

        The extensionAttribute name must match the specified extensionId in the tdi-profiles-config.xml extension attribute definition.

      2. Add a new func_map_to_db_extensionAttribute JavaScript function in the TDISolution\TDI\profiles_functions.js file. Write logic for the function that specifies the new extension attribute mapping.

      3. Repeat these steps for each JavaScript function.


    What to do next

    The properties in the map_dbrepos_from_source.properties file have the default values defined in the following table. Many of them are null. You must determine which LDAP properties to map to your DB fields and edit this file to specify values that apply to your configuration. Any values that you omit or set to null are not populated in the DB.

    Default values for properties in the map_dbrepos_from_source.properties file

    TDI property Default LDAP attribute mapping
    alternateLastname null
    bldgId null
    blogUrl null
    calendarUrl null
    countryCode c
    courtesyTitle null
    deptNumber null
    description null
    displayName cn

    Required.

    distinguishedName $dn

    Required.

    email mail
    employeeNumber employeenumber
    employeeTypeCode employeetype
    experience null
    faxNumber facsimiletelephonenumber
    floor null
    freeBusyUrl null
    givenName givenName
    givenNames gn
    groupwareEmail null
    guid Required
    ipTelephoneNumber null
    isManager null
    jobResp null
    loginId
    logins null
    managerUid $manager_uid

    This property represents a lookup of the UID of the manager using the DN in the manager field.

    mobileNumber mobile
    nativeFirstName null
    nativeLastName null
    officeName physicaldeliveryofficename
    orgId ou
    pagerId null
    pagerNumber null
    pagerServiceProvider null
    pagerType null
    preferredFirstName null
    preferredLanguage preferredlanguage
    preferredLastName null
    secretaryUid null
    shift null
    surname sn

    You must provide this field because the Search application expects to find it in the Profiles DB.

    Required.

    surnames sn
    telephoneNumber telephonenumber
    timezone null
    title null
    uid Required.
    workLocationCode postallocation

    Map the guid, uid, and loginId: The guid property identifies the global unique ID of a user. This property's value is created by the LDAP directory and is unique, complex, and never changes. It is essential in that it maps each user's IBM Connections data to their User ID when using the Profiles DB as the user repository. The mapping of the guid property must be handled differently depending on the type of LDAP directory that you are using:

    • Microsoft Active Directory

      guid={function_map_from_objectGUID} You must use a JavaScript function to define the value for Active Directory because objectGUID is stored in Active Directory as a binary value, but is mapped to guid, which is stored as a string in the Profiles DB. Also, the samAccountName property used by Active Directory has a 20 character limit, as opposed to the 256 character limit of the other IDs used by IBM Connections.

    • IBM Lotus Domino

      guid={function_map_from_dominoUNID}

    • IBM Directory Server

      guid=ibm-entryUuid

    • Sun Java System Directory Server

      guid=nsUniqueID

    • Novell eDirectory

      guid={function_map_from_GUID}

    If you edited the wimconfig.xml file to use a custom global unique ID, be sure to specify that custom ID here. The uid property, not to be confused with the guid property, defines the unique ID of a user. This property differs from a guid in that it is the organization-specific permanent identifier for a user . often a login ID or some value based on the user's employee code. The uid is a critical field in the Profiles DB. By default, this property links a given person's user record back to LDAP data. The value you map to uid must meet the following requirements:

    • It must be present in every entry that is to be added to the DB.

    • It must be unique.

    • In a multi-LDAP environment, it must be unique across LDAP directories.

    • It must be 256 characters or fewer in length.
    In Active Directory, although there often is a UID field available, this field is not always the best choice for mapping to uid because it is not guaranteed to be present for all entries. A better choice is sAMAccountName because it usually does exist for all entries. Other values are acceptable also, as long as they meet the requirements.

    > If you are mapping the uid from an LDAP field, specify the name of the field. However, if you need to parse it from the distinguished name and it is in the DN in the form of uid=value, use the following mapping function:

    {func_map_to_db_UID}

    Use the isManager and managerUid properties to set up the organizational structure of the organization. The isManager field determines whether the current person is a manager or not. You must assign a Y (Yes) or N (No) value to this property for each entry. Y identifies the person as a manager. The managerUid identifies the UID of the current person's manager. By default, managerUid is mapped to $manager_uid, which represents a lookup of the UID of the manager (using the DN contained in the LDAP manager field). If a user's manager information is not contained in the $manager_uid field, you should adjust the mapping accordingly. These two properties work together to identify manager/employee relationships and create a report-to chain out of individual user entries.

    If users intend to log into Profiles using a single-valued user name other than the value specified in the uid or email properties, you must map that user name value to the loginId property. To do so, complete the following step:

    • Set the loginId property in the map_dbrepos_from_source.propeties file equal to the LDAP property to use as the login ID.

      For example, if you want to use employeeNumber as the login property, edit the property value as follows:

      loginId=employeeNumber

    If you have more than one additional login ID (such as with a long and short form UID) and you want to allow users to login with either of their login IDs, you can populate multiple additional login IDs by using one of the following settings:

    logins=multiValuedLdapAttribute

    or

    logins={function_to_get_multiple_ldap_values}

    For more information, see the Tivoli Directory Integrator product documentation.

    Add profile types:

    IBM Connections supports the ability to classify a profile using a profile type. The profile type allows the application to provide the set of properties that are intended for a given profile object. For more information, see Profile-types.


    Example complex mapping of Profiles data

    This example illustrates a sample complex mapping using Javascript functions to define mapping between the LDAP directory and the Profiles DB.

    When manually mapping Profiles fields you can perform 1:1 or complex mapping as described in the Mapping fields manually topic.

    In this example, the mapping pertains to the surnames list. The primary CRUD functions (create, retrieve, update and delete) are illustrated context. The example is intended for illustrative purposes only.

    The map_dbrepos_from_source.properties mapping file contains the following statement:

    surname=sn
    surnames={func_surNames_basic}

    This means there is an LDAP field named sn which contains a list of surnames. The first property (surname=sn) causes the first entry in the list to be stored in the surname field or row in the Profiles user table. If the second property were also assigned to sn, this would cause the list to be placed in the Profiles SURNAME table. However, the following function has been specified.

    function func_surNames_basic(fieldName) 
    {
        var fieldName str = fieldName.toString();   // be cautious, make sure it is a string.
        var result = work.getAttribute("sn");       // get the list
    
        if(result == null) 
        {
            result = "no sn work element";          // return bogus value. See the function
                                                    // func_compute_givenName() in profiles_functions.js
                                                    // for a more realistic approach.
        }
        else
        {
            result = result.clone();
            var len = result.size();
            for (var i = 0; i <len; i++) 
            {
                var val = result.getValue(i);
                if (!(val instanceof java.lang.String)) 
                {
                    val = java.lang.String.valueOf(val);
                    val = val + " Esq                    // append .Esq.
                    result.setValue(i, val);             // update value
                }
            }
        }
        result.setValue(len, fieldNamestr);
        return result;
    }
    

    In the first line the fieldName value is the name of the property, in this example the surnames property. This makes it possible to use the same function for a number of items.

    In the third line the sn list is a variable named result. The argument of the getAttribute() must be the value of a property, in this example the sn property value.

    A test for sn not being available occurs at the fourth line in the result = "no sn work element" statement.

    Given that the list is available, we clone it to avoid changing the entry list. We next iterate through the list testing to verify that each value is a string. This is a best practice even though in this case it may seem unnecessary. The line containing .result.getValue(i);. gets the next item in the list; this represents the R element of CRUD. The result.setValue(i, val); line shows how to modify a value; this represents the U element of CRUD. After the iteration we add the fieldname to the list in the result.setValue(len, fieldNamestr); statement; this represents the C element of CRUD. The example uses the same setValue method for both the create and update functions.

    Further, let.s suppose we don.t want any more than five names in the surnames list. Add the following entry after the for (var i = 0; i <len; i++) { demonstrate how the delete function works.

    if (i > 4)
    {
    result.removeValue(i);
    len--; i--;
    continue;
    }


    Attribute mapping for Profiles

    When the Profiles directory service is enabled, IBM Connections relies on the Profiles DB to provide user data such as user name, ID, and email.

    The internal name of the Profiles DB is PEOPLEDB.

    The following table shows the mapping relationships between Profiles, the Profiles directory service, Virtual Member Manager, and LDAP.

    Attribute mapping table

    Profiles DB column Profiles Directory Service Virtual Member Manager LDAP
    PROF_GUID ID uniqueId UUID/GUID/UNID (defined in RFC4122)
    PROF_DISPLAY_NAME Name cn/displayName cn/displayName
    PROF_MAIL Mail mail/ibm-primaryEmail mail/ibm-primaryEmail
    PROF_SOURCE_UID DN uniqueName DN
    PROF_UID UID UID UID or samAccountName (in MS AD/ADAM only)
    PROF_LOGIN LOGIN Login attributes other than UID and mail LDAP login attributes other than UID and mail

    The following table shows the population functions that are used in TDI scripts to populate ID into PROF_GUID.

    Population functions for populating ID into PROF_GUID

    LDAP implementations LDAP attribute type names LDAP syntax TDI scripts with functions
    IBM Lotus Domino Server dominoUNID Directory String (in Byte String Format)

    {function_map_from_dominoUNID}

    Novell eDirectory Server GUID Octet String (in Binary Format)

    {function_map_from_GUID}

    Microsoft AD/ADAM Server/Service objectGUID Octet String (in Binary Format)

    {function_map_from_objectGUID}

    Microsoft AD/ADAM Server/Service objectSID Octet String (in Binary Format)

    {function_map_from_objectSID}

    IBM Tivoli Directory Server ibm-entryUUID Directory String (in Canonical Format) n/a
    Sun Java Directory Server nsuniqueid Directory String (in Canonical Format) n/a


    Configure the Manager designation in user profiles

    When you map manager data in the Profiles DB, you can mark manager profiles and also create report-to chains.

    Each profile contains a manager_uid field which stores the uid value of that person's manager. This information is used to build the Reports To display widget in the Profiles user interface. For information about the manager_uid field, see Mapping fields manually.

    Additionally, the isManager field (which equates to the Mark manager mapping task in the Profiles population wizard) is used to mark the user profile as being a manager. This information is used to build the People Managed display widget in the Profiles user interface. A Y or N attribute is assigned to an employee to indicate whether the employee is listed as a manager of other employees.

    You can set the isManager field as described in the Mapping fields manually topic (using either 1:1 mapping or function mapping) or by running the Mark manager task (using the population wizard or by running the mark_manager.bat or mark_manager.sh script). For more information about these options see Using the Profiles population wizard and Manually populating the Profiles DB.

    If you are setting the ismanager field using a 1:1 mapping, ensure specified how to set the field in the map_dbrepos_from_source.properties file. For example, if the LDAP has an ismanager field that is set to a value of Y or N, your map_dbrepos_from_source.properties file could specify the following property:

    PROF_IS_MANAGER=ismanager

    If the manager information is supplied directly from the source, the Mark manager task is not necessary.

    The Mark manager task will iterate through the profiles, and see if that particular profile is referenced as the manager for any other profiles. If yes, it will mark that profile as a manager. If that profile is not referenced as anyone else's manager, it will be marked as not a manager.

    For information about configuring the display of the Reports To and People Managed widgets for your organization, see Enabling the display of organizational structure information.


    Supplemental user data for Profiles

    You can supplement user profiles data using a mapping table, the profiles_tdi.properties file, and CSV files.


    Map user data

    You can map additional user data to supplemental tables within the Profiles DB and then display that data in a user's profile.

    When the LDAP directory provides a code or abbreviation for a particular setting, the supplemental table can provide extra data. For example, an employeeType of P in the LDAP directory might correspond to Permanent. If the employee-type table is populated with data such as p;permanent, this extra data can be displayed in the profile.

    The profiles_tdi.properties file stores the settings that determine how the files are formatted.

    These properties are supplied in the profiles_tdi.properties file. The file path specified is relative to the TDI solution directory.

    The mapping task for Profiles maps your user data to the following entities:

    Fill countries

    Add country data to each profile.

    Fill departments

    Add department data to each profile.

    Fill organization

    Add organization data to each profile.

    Fill employee types

    Add employee-type data to each profile.

    Fill work locations

    Add location data to each profile.


    CSV files

    A CSV (comma separated value) file is required as input for each of these tasks.

    The following properties pertain to the CVS files used by these tasks:

    country_table_csv_separator=;
    country_table_csv_file=isocc.csv
    
    department_table_csv_separator=;
    department_table_csv_file=deptinfo.csv
    
    emp_type_table_csv_separator=;
    emp_type_table_csv_file=emptype.csv
    
    organization_table_csv_separator=;
    organization_table_csv_file=orginfo.csv
    
    workloc_table_csv_separator=;
    workloc_table_csv_file=workloc.csv

    The separator character separates the different tokens in each line. The second property is the name of the file, relative to the solution directory.

    The first token is the code. The next attributes are read in order for each additional field. No other fields are required.

    The data that can be populated in these tables is usually provided as two values per line: code;description. For the workloc code, the values can be code;addr1;addr2;city;state;zip. For example: WSF;FIVE TECHNOLOGY PARK DR;;WESTFORD;MA;01886-3141.

    Fields that you do not require in your mapping can be omitted from the file; this example uses only one addr field.

    The default file name for each codes is shown in the following list:

    countryCode

    isocc.csv

    deptNumber

    deptinfo.csv

    orgId

    orginfo.csv

    employeeTypeCode

    emptype.csv

    workLocationCode

    workloc.csv


    Sample CSV file

    This sample shows some lines from the isocc.csv file, which can be used to fill countries data:

    ad;Andorra, Principality of
    ae;United Arab Emirates
    af;Afghanistan, Islamic State of
    ag;Antigua and Barbuda
    ai;Anguilla
    al;Albania
    am;Armenia
    an;Netherlands Antilles
    ao;Angola
    aq;Antarctica
    ar;Argentina

    You can find more sample CSV files in the wizard_files_directory/TDIPopulation/TDISOL/aix|lin|win/samples directory,

    ...where the wizard_files_directory is the location of the various Wizard files that you downloaded or received on disk, and aix|lin|win is the AIX, Linux, or Microsoft Windows version of the directory.


    Install Cognos Business Intelligence

    IBM Cognos Business Intelligence collects, manages, and displays statistical information for the Metrics application in IBM Connections. Installing Cognos Business Intelligence involves installing IBM WAS Network Deployment, plus a DB client, in addition to the Cognos components.

    This documentation assumes you are deploying Cognos Business Intelligence before you install IBM Connections. If you choose to deploy Cognos later, you can ignore any Cognos-related validation errors during the Connections installation process and then return to this section later for instructions on deploying the Cognos components. Even if you are not deploying Cognos now, you can create the raw Metrics DB and install the Metrics application so that Connections can immediately begin capturing event data for later use.

    IBM Connections requires a customized version of Cognos Business Intelligence, which is installed using the provided script. You cannot use previously deployed Cognos Business Intelligence components with the Metrics application. For best performance, use a separate computer for the customized version of Cognos Business Intelligence.

    To install the Cognos Business Intelligence and its supporting software, complete these tasks:


    Install required patches on the Cognos BI Server system

    Before installing IBM Cognos Business Intelligence and its related software, prepare the server environment by applying required patches to the operating system and other third-party components.

    Any required patches must be installed before you attempt to deploy the Cognos server.

    1. Review IBM technote 7022463, Cognos BI 10.1.1 Software Environments - Required Patches.

      Open Motif libraries are still required (as mentioned in the technote) for headless Linux systems.

    2. Install the patches specified for your server environment.

    3. Restart the server to make sure all patches take effect.


    Install WAS for Cognos Business Intelligence

    Install IBM WAS Network Deployment on the computer that will host IBM Cognos Business Intelligence, so that the server can be managed by the Deployment Manager used with IBM Connections.

    The WebSphere node hosting the Cognos BI server will be federated to the same dedicated Deployment Manager as your IBM Connections deployment. Do not use a WebSphere node that has already been federated to a different Deployment Manager.

    1. Install WAS Network Deployment as described in the WAS Version 7.0 information center.

      This server should be installed using the Application server profile; you will federate it to the Deployment Manager in a later task.

      If you will use a server where the appropriate version of WAS Network Deployment is already deployed, you do not have to install it again; just create a new Application server profile for Cognos Business Intelligence as follows:

      IBM AIX, Linux

      manageprofiles.sh -create -templatepath  WAS_install_root/profileTemplates/default -adminUserName was_admin_name -adminPassword was_admin_password

      Microsoft Windows

      manageprofiles.bat -create -templatepath  WAS_install_root\profileTemplates\default -adminUserName was_admin_name -adminPassword was_admin_password

      You can verify that the installation was successful by reviewing the WAS log stored in: Cognos_WAS_node_profile/logs/Cognos_server_name/SystemOut.log; for example on Windows:

      C:\IBM\WebSphere\AppServer\profiles\CognosNode01\logs\cognos_server\SystemOut.log

    2. On the newly installed server, set the system clock to match the time (and time zone) on the Deployment Manager.s computer.

      The node.s clock must be synced to within 1 minute of the Deployment Manager.s clock to ensure that federation does not fail in a later task.


    Install Cognos Business Intelligence components

    Install IBM Cognos Business Intelligence on the computer where you previously installed IBM WAS Network Deployment and the DB client. The Cognos product consists of two components (Cognos BI Server and Cognos Transformer); you must install both components as part of this deployment.

    The following conditions must be satisfied to ensure that the Cognos Business Intelligence components installs correctly:

    • The Cognos Content Store DB must have been created on the DB server, and that DB server must be running (see Create DBs

    • The Deployment Manager must be running.

    • The DB client must have been installed on the current server, but does not have to be running.

    • The current server must reside within the same domain as the IBM Connections servers so you can enable SSO (Single Sign-On) as required for generating reports.

    • The user running the Cognos installation script must have permissions to use the DB client.

    Install Cognos Business Intelligence requires two Cognos packages (BI Server and Transformer) in addition to the scripts provided in the IBM Connections kit.

    The installation packages for Cognos Business Intelligence components are available in the IBM Connections kit as separate downloads.

    Package names for Cognos components to be installed for use with IBM Connections.

    Operating System Cognos BI Server package name Cognos Transformer package name
    IBM AIX IBM Cognos Business Intelligence Server 64-bit 10.1.1 AIX Multilingual IBM Cognos Business Intelligence Transformer 10.1.1 AIX Multilingual
    Linux IBM Cognos Business Intelligence Server 64-bit 10.1.1 Linux x86 Multilingual IBM Cognos Business Intelligence Transformer 10.1.1 Linux x86 Multilingual
    Microsoft Windows IBM Cognos Business Intelligence Server 64-bit 10.1.1 Windows Multilingual IBM Cognos Business Intelligence Transformer 10.1.1 Windows Multilingual
    zLinux (System z) IBM Cognos Business Intelligence Server 64-bit 10.1.1 Linux on System z Multilingual (CI5W5ML IBM Cognos Business Intelligence Transformer 10.1.1 Linux on System z Multilingual (CI2QHML)

    1. Create a shared network folder where Cognos Transformer can publish metrics data (in the form of PowerCubes) for reports to access.

      The shared network folder is used when you cluster multiple Cognos servers; you can use any name you want for the folder. Record this location so you can assign it to the cognos.cube.path property when you set up the cognos-setup.properties file in step 6.

    2. Prepare the Cognos BI Server package:

      1. Download the Cognos BI Server package to a temporary location on the server.

      2. Create a directory to contain the expanded package; for example:

        • AIX or Linux: /opt/biserver_10.1.1

        • Windows: C:\biserver_10.1.1

      3. Expand the package into the new directory.

    3. Prepare the Cognos Transformer package:

      1. Download the Cognos Transformer package to a temporary location on the server.

      2. Create a directory to contain the expanded package; for example:

        • AIX or Linux: /opt/transformer_10.1.1

        • Windows: C:\transformer_10.1.1

        Due to potential file name conflicts, the Transformer package cannot share a directory with the BI Server package. Extracting the packages to the same location will overwrite libraries and result in a non-functioning server.

      3. Expand the package into the new directory.

    4. Prepare the Cognos server setup package:

      CognosConfig.zip or CognosConfig.tar can be found in the /Cognos folder within the Connections product media.

      1. Download the CognosConfig package to a temporary location on the server.

      2. Create a directory to contain the expanded package; for example:

        • AIX or Linux: /opt/CognosSetup

        • Windows: C:\CognosSetup

      3. Expand the package into the new directory.

    5. Set up the JDBC driver:

      1. Locate the type 4 JDBC driver provided by your DB server product.

      2. Copy the JDBC driver to the following location: /CognosSetup/BI-Customization/JDBC

    6. Prepare the cognos-setup.properties file by filling in a value for each property.

      The cognos-setup.properties file is located in the CognosSetup directory where you expanded the Cognos server setup package in step 4. This file provides values that are used during installation; each property setting in the file is accompanied by a description.

      Notes® on the settings in this file:

      • The shared network folder is represented by the cognos.cube.path property; set this property to the name you used for the shared network folder that you created in step 1.

      • The Cognos administrator account specified for the cognos.admin.username setting must represent a valid LDAP user . this is not the WebSphere administrator. You should have already set up a user in the LDAP for this purpose; for information see Create the Cognos administrator.

      • (Oracle DB) When you installed the Oracle DB client, you should have written down the DB settings hat you will use in the cognos-setup.properties file; refer to those settings now.

      • Any passwords stored in this file will be removed after the script finishes running; if you need to run the script again you will need to insert the passwords before the next run. If you prefer, you can omit the passwords from the properties file and supply them on the command line when you run the script, as shown in step 9.

    7. (RedHat Linux 6 64-bit systems) Run the following command to preload libraries needed for the setup scripts used in the next step:

      export LD_PRELOAD=/usr/lib64/libfreebl3.so

    8. (SuSE 11 zLinux systems) Create a symbolic link to the libXm.so.3 package:

      The openmotif22-libs-32bit-2.2.4-138.18.1 kit includes libXm.so.4, while the Cognos installer program issetup script links with libXm.so.3 and encounters an error if it is not available. Prevent this error by creating a symbolic link to libXm.so.3 with the following command:

      ln -s /usr/lib/libXm.so.4 /usr/lib/libXm.so.3

    9. (Microsoft SQL Server) If you are using Microsoft SQL Server as your DB management system, configure it to support remote connections before running the cognos-setup.bat|sh script, or the DB validation will fail. For information on enabling remote connections in SQL Server, see the Microsoft site.

    10. Run the cognos-setup.sh script to install the Cognos BI Server and Transformer components.

      Any of the properties specified in the cognos-setup.properties file can be passed in as parameters when you run this script. In particular, you might want to supply passwords using this method rather than adding them into the properties file because they will be deleted from the file after it runs. For any properties you supply at run time, use the following syntax:

      cognos-setup.sh -property_name1=property_value1 -property_name2=property_value2

      For example, the properties file contains settings for four passwords. You can pass all of them in at run time by including them on the command line as shown:

      cognos-setup.sh -was.local.admin.password=WASadmin_pwd -cognos.admin.password=CognosAdmin_pwd -cognos.db.password=CognosContentStore_pwd -metrics.db.password=Metrics_DB_pwd

      Output from this operation is stored in the /CognosSetup/cognos-setup.log.

      If you encounter an error when running the cognos-setup.bat|sh script, correct the error and run the script again before proceeding to the next step. For example, if you provided an incorrect password in the cognos-setup.properties file, modify the password and then run the cognos-setup.sh script again. Remember that if you added passwords to the properties file, they were deleted after the previous run, and must be provided again. If you encounter other problems, see Troubleshoot Cognos Business Intelligence components for possible solutions.

    11. Now run the cognos-configure.sh script to configure the Cognos server and set up DB connections.

      Any of the properties specified in this script can be passed in as parameters when you run this script, using the syntax shown in the previous step.

      Output from this operation is stored in the /CognosSetup/cognos-configure.log.

      If you encounter an error when running the cognos-configure.sh script, correct the error and run the script again before proceeding to the next step. For example, if you provided an incorrect password in the cognos-setup.properties file, modify the password and then run the cognos-setup.sh script again. Remember that if you added passwords to the properties file, they were deleted after the previous run, and must be provided again. If you encounter other problems, see Troubleshoot Cognos Business Intelligence components for possible solutions.

    12. Leave the Cognos server stopped for now; you will start the server after federating it to the Deployment Manager in the next task.

      In the future, whenever you want to stop the Cognos server, you must stop the WAS hosting it; wait at least 1 full minute to ensure that all of the Cognos processes (AIX or Linux: cgsServer.sh and CAM_LPSvr processes;

      Windows: cgsLauncher.exe and CAM_LPSvr processes) have completely stopped before you attempt to start the server again.


    Results

    The Cognos BI Server and Transformer components are installed into the directories specified in the cognos-setup.properties file; for example:

    • Cognos BI Server: cognos.biserver.install.path

      • AIX or Linux: /opt/IBM/Cognos64

      • Windows: C:\Program Files\IBM\Cognos

    • Cognos Transformer: cognos.transformer.install.path

      • AIX or Linux: /opt/IBM/Cognos

      • Windows: C:\Program Files (x86)\IBM\Cognos

    During the installation, you might see the following message: ERROR: The system cannot find the file specified. If this message is followed by "success" messages" similar to those shown here, then the installation was successful and you can ignore the error message.

    <date><time> : daily refresh success
    <date><time> : rebuild <year><month> success

    You can verify that the components were installed successfully by reviewing the installation logs at the following locations:

    • Cognos BI Server installation log: Cognos_BI_install_path/logs/cogserver.log

      • AIX or Linux: /opt/IBM/Cognos64/logs/cogserver.log

      • Windows: C:\Program Files\IBM\Cognos\logs\cogserver.log

    • Cognos Transformer installation log: Cognos_Transformer_install_path/logs/cogserver.log:

      • AIX or Linux: /opt/IBM/Cognos/logs/cogserver.log

      • Windows: C:\Program Files (x86)\IBM\Cognos\logs\cogserver.log


    Install the DB client for Cognos Transformer

    Install a DB client on the computer where you will host IBM Cognos Business Intelligence. The Cognos Transformer component requires the use of a DB client to ensure proper access to the DB server for PowerCube generation and reporting.


    Install the DB2 DB client for Cognos Transformer

    Install the IBM DB2 DB client on the computer

    ...where you will host IBM Cognos Business Intelligence.

    Before you install the DB client, the DB server must be installed and running, and you must have created the Metrics DB and the Cognos Content Store DB.

    1. Install the DB client on the server where you will deploy Cognos Business Intelligence, using the instructions provided with your DB product.

      For instructions on installing the IBM DB2 client, see the Installation methods for IBM data server clients in the DB2 information center.

    2. (DB2 on Linux only) Ensure that the DB2 client library is properly sourced:

      1. In the DB2 client installation directory, open the /etc/ld.so.conf file for editing.

      2. Add the following library /opt/ibm/db2/V9.7/lib32 to the file.

      3. Save and close the file.

      4. Run the ldconfig command to regenerate dynamic link libraries (DLLs).

    3. Create a connection between the client and the DB.

      First, connect the client to the node (the DB2 server) where the DB is hosted by completing the following steps.

      1. Log on to the client computer as a user with at least DB2 SYSADM authority.

        You cannot catalog a node as a root authority.

      2. Change to the home directory of instance.

        The substeps below refer to this directory as INSTHOME.

      3. (AIX or Linux) Set up the instance environment by running the startup script:

        bash, Bourne, or Korn shell

        . INSTHOME/sqllib/db2profile

        C shell

        source INSTHOME/sqllib/db2cshrc

        ...where INSTHOME indicates the home directory of the instance.

      4. Open the DB2 command line processor:

        AIX or Linux

        db2

        Windows

        db2cmd

        ...where INSTHOME indicates the home directory of the instance.

      5. Catalog the DB2 server by entering the following commands in the command line processor:

        db2 => catalog tcpip node Node_name remote Host_name|IP_address
               server Service_name|DB2_Instance_Port
        
        db2 => terminate
        Where:

        • Node_name indicates a local nickname (for example, the short host) that you can set for the DB2 server.

        • Host_name|IP_address indicates the host or IP address of the server instance where the DB resides (both IPv4 and IPv6 addresses are accepted).

        • Service_name|DB2_Instance_Port indicates the service name or DB2 instance port used for the connection (typically port 50000 for DB2).

        For example, connect to the server called "db2node" with the IP address "2001:DB8:0:0:0:0:0:0" on port 50000 as follows:

        db2 =>  catalog tcpip node db2node remote 2001:DB8:0:0:0:0:0:0 server 50000 
        DB20000I  The CATALOG TCPIP NODE command completed successfully.
        DB21056W  Directory changes may not be effective until the directory cache is refreshed.
        
        db2 =>  terminate 
        DB20000I  The TERMINATE command completed successfully.

      Now connect the client to the DB2 DB itself .

      For DB2, configure the client to use Metrics as both the Database name and the Database alias.

      1. Run the following commands in the DB2 command line processor:

        db2 => catalog DB Database_name as Database_alias at node Node_name
        
        db2 => connect to Metrics user Metrics_db_user
        
        db2 => terminate
        Where the DB2 server is the node you just connected to, and the DB information matches the values specified in the cognos-setup.properties file that is used during installation:

        • Database_name indicates the name of the Metrics DB (the metrics.db.name setting; the default value is METRICS).

        • Database_alias indicates the alias for the Metrics DB (the metrics.db.local setting; the default value is METRICS).

        • Node_name is the same local nickname that you used to connect to the DB2 server earlier in this step.

        • Metrics_db_user indicates the user name that will be used to access the DB (the metrics.db.user setting; the default value is LCUSER).

        For example, catalog the METRICS DB on the server "db2node" as the user "LCUSER" and then test the connection with the following commands:

        db2 =>  catalog DB METRICS as METRICS at node db2node 
        DB20000I  The CATALOG DATABASE command completed successfully.
        DB21056W  Directory changes may not be effective until the directory cache is refreshed.
        
        db2 =>  connect to METRICS user LCUSER 
        Database Connection Information     
        Database server = DB2 9.7.0     
        SQL authorization ID = LCUSER     
        Local DB alias = METRICS
        
        db2 =>  terminate 
        DB20000I  The TERMINATE command completed successfully.

      2. When you have successfully cataloged the DB, close the DB2 command line processor with the following command:

        db2 =>  quit 

      For more information on connecting the DB2 client to the DB2 server and DB (including optional arguments), see Configure client-to-server connections using the command line processor in the DB2 information center.


    Install the Oracle DB client for Cognos Transformer

    Install the Oracle DB client on the computer where you will host IBM Cognos Business Intelligence.

    Before you install the DB client, the DB server must be installed and running, and you must have created the Metrics DB and the Cognos Content Store DB.

    For troubleshooting information on configuring the Oracle DB client for use with Cognos, see the IBM technote, Resolve Oracle connection errors.

    1. Install the standard 32-bit DB client on the server

      ...where you will deploy Cognos Business Intelligence; for information see Install Oracle Database Client.

      Be sure to install the standard 32-bit client rather than the Instant Client, which is not supported by Cognos. If you installed the 64-bit client, you must uninstall it before installing the 32-bit client.

    2. Copy the following files to the Cognos_Transformer_install_path/bin directory:

      • Oracle_client_install_path/lib/libclntsh.so.11.1

      • Oracle_client_install_path/lib/libnnz11.so

      If you are using a different version of the Oracle client, you should find similar files (named for the version) in the same location, and can use those files instead.

    3. (AIX or Linux) If you are not logged in as root, change the permissions on the two files using chmod 755.

    4. Restart the server:

      1. Stop the IBM WAS that hosts the Cognos server.

      2. Wait at least 1 full minute to ensure that all Cognos processes have stopped:

        • AIX or Linux: cgsServer.sh and CAM_LPSvr processes

        • Windows: cgsLauncher.exe and CAM_LPSvr processes

      3. Start WAS.

      4. Start the Cognos server.

      If possible restart the server and then start Cognos service. If you cannot restart the server, just restarting the Cognos service should do.

    5. Define the ORACLE_HOME, TNS_ADMIN, and LD_LIBRARY_PATH locations:

      ORACLE_HOME=/u01/app/oracle/product/11.2.0/client_1
      LD_LIBRARY_PATH=Cognos_Transformer_install_path/bin; ORACLE_HOME/lib
      TNS_ADMIN=ORACLE_HOME/network/admin

    6. Edit the Oracle_client_install_path/network/admin/tnsnames.ora file and add the following TNS settings into the file:

      The TNS setting on the Oracle client should look like the example that follows:

      METRICS =
        (DESCRIPTION =
          (ADDRESS_LIST =
            (ADDRESS = (PROTOCOL = TCP)(HOST = Oracle_DB_server_host_name)(PORT = Port))
          )
          (CONNECT_DATA =
            (SERVICE_NAME = Database_service_name)
          )
        )

      ...where:

      • Oracle_DB_server_host_name is the host of the server hosting the Oracle DB server; for example: oradb.example.com.

      • Port is port on which the Oracle DB server is listening; typically port 1521.

      • Database_service_name is the DB service name; for example orcl.

    7. Write down the following settings so you can enter them into the cognos-setup.properties file in a later task:

      Use the same values for the Oracle_DB_server_host_name, the Port, and the Database_instance_name that you used in the Oracle tnsnames.ora file.

      cognos.db.type=oracle
      cognos.db.host=Oracle_DB_server_host_name:Port
      cognos.db.name=Database_instance_name
      cognos.db.user=cognos           //created by installer
      cognos.db.password=pass
      
      metrics.db.type=oracle
      metrics.db.host=Oracle_Database_Server:1521
      metrics.db.name=orcl
      
      metrics.db.local.name=METRICS   //local TNS name
      metrics.db.user=metricsuser     //created by installer
      metrics.db.password=pass

    8. Verify the client can connect to the Metrics DB.

      If the Oracle client encounters errors connection to the Metrics DB, refer to the IBM technote, Resolve Oracle connection errors.


    Federate the Cognos server to the Deployment Manager

    The computer hosting the IBM Cognos Business Intelligence server must be federated to the same dedicated Deployment Manager used by IBM Connections.

    Before attempting to federate the Cognos node to the Deployment Manager, make sure that:

    • The Deployment Manager is running.

    • The Cognos server is stopped (if you started it after installation, stop it now by stopping the IBM WAS hosting it).

    • The system clock on the Cognos server is set to within 1 minute of the time (and time zone) of the system clock on the Deployment Manager.

    • The Deployment Manager and the Cognos server are either both registered in the DNS or are referenced in each other.s etc/hosts file.

    This task involves working on the newly installed Cognos Business Intelligence server to add the node to the Deployment Manager, and then working on the Deployment Manager to create virtual ports for the new node.

    1. On the Deployment Manager, disable Java 2 security:

      1. Log into the Integrated Solutions Console as the WebSphere administrator.

      2. Click Security > Global Security

      3. Look under "Java 2 security" and clear the selection for Use Java 2 security to restrict application access to local resources.

      4. Click Apply.

      5. Click OK.

    2. Use the computer hosting the Cognos components to federate the new node to the Deployment Manager:

      1. On the computer hosting the Cognos components, open a command window and navigate to the/bin directory in the WAS installation root; for example:

        • IBM AIX, Linux: /opt/IBM/WebSphere/AppServer/bin

        • Microsoft Windows:: C:\Program Files\IBM\WebSphere\AppServer\bin

      2. Run the addNode command to federate the node to the Deployment Manager as follows:

        addNode.bat|sh DM_host_name DM_port -profileName Cognos_profile_name -includeapps -username DM_admin_user_name -password DM_admin_password

        where:

        • DM_host_name is the fully qualified host of the Deployment Manager.

        • DM_port is the SOAP_CONNECTOR port that the Deployment Manager is listening on; the default port is 8879.

          You can determine the port by checking the SOAP_CONNECTOR_ADDRESS value in the following file on the computer hosting the Deployment Manager::

          WAS_install_root/profiles/DM_Name/properties/portdef.props; for example on Windows:

          C:\IBM\WebSphere\AppServer\profiles\Dmgr01\properties\portdef.props

        • Cognos_profile_name is the profile name where Cognos Business Intelligence is installed (in case multiple profiles are installed on the same server).
          Tip: If you only installed one WebSphere profile on the server, you can omit this parameter.

          If you are not sure of the Deployment Manager.s profile name, you can determine it by looking at the directory name

          ...where it was installed; for example on Linux:

          /opt/IBM/WebSphere/AppServer/profiles/Cognos_profile_name

        • DM_admin_user_name is the user name of the WebSphere administrator on the Deployment Manager, and DM_admin_password is the associated password.

        Make sure you specify -includeapps as shown in the example.

        For example:

        addNode.bat lc40.example.com 8879 -profileName AppSrv01 -includeapps -username wasadmin -password my_WASadmin_pwd

      3. Now start the node agent by running the startNode command (from within the same directory); for example:

        • AIX or Linux: startNode.sh

        • Windows: startNode.bat

    3. Move back to the Deployment Manager and create virtual ports for the new node:

      1. Log into the Integrated Solutions Console as the WebSphere administrator.

      2. In the navigation tree, click Servers > Server Types > WebSphere Application servers > Cognos_server_name > Ports.

      3. Note the values for the following ports, for use in the next step:

        • WC_defaulthost

        • WC_defaulthost_secure

      4. Back in the navigation tree, click Environment > Virtual Hosts > default_host > Host Aliases.

      5. Click the New button in the ports table and add a port representing WC_defaulthost; then click OK:

        • Host name: *

        • Port: use the value of the WC_defaulthost port that you noted earlier.

      6. Click the New button again and add a port representing WC_defaulthost_secure; then click OK:

        • Host name: *

        • Port: use the value of the WC_defaulthost_secure port that you noted earlier.

      7. Save the changes to the master configuration by clicking the Save link in the "Messages" box at the top of the page.

    4. Synchronize the new node to the Deployment Manager:

      1. On the navigation tree, click System Administration > Nodes.

      2. In the nodes table, click the checkbox that precedes the new node (the Cognos server).

      3. Click the Synchronize button in the table and wait for the operation to finish before proceeding to the next step.

        Synchronization might take several minutes to complete; be sure to allow sufficient time before restarting the Cognos server in the next task.

    5. Restart the Cognos server:

      1. Stop the IBM WAS that hosts the Cognos server.

      2. Wait at least 1 full minute to ensure that all Cognos processes have stopped:

        • AIX or Linux: cgsServer.sh and CAM_LPSvr processes

        • Windows: cgsLauncher.exe and CAM_LPSvr processes

      3. Start WAS.

      4. Start the Cognos server.


    Validate the Cognos BI server installation

    Verify the IBM Cognos Business Information server is correctly installed by viewing its content manager and dispatcher pages.

    Make sure the Cognos server is running.

    For configuration tips and information on troubleshooting the Cognos Business Intelligence installation, see Troubleshoot Cognos Business Intelligence.

    1. From any browser, navigate to the Cognos server.s content manager at the following address:

      http://Host_Name:Port/Context_Root/servlet

      where:

      • Host_Name is the fully qualified host of the Cognos server; for example, host.example.com.

        This value is specified in the was.fqdn.hostname property in the cognos-setup.properties file used for installing the server.

      • Port is the port that the Cognos server is listening on.

      • Context_Root is the context root to which you installed the Cognos server; for example, cognos.

        This value is specified in the cognos.context_root property in the cognos-setup.properties file using for installing the server (the default value was set to cognos).

      For example:

      http://cognosserver.example.com:9083/cognos/servlet

      The IBM Cognos Content Manager displays the following information: build number, server start time, current time, and current server state. The state should be running; if it is not, see Troubleshoot Cognos Business Intelligence components for possible problems and suggested solutions.

    2. Next, verify the dispatcher:

      1. In the browser, navigate to the dispatcher.s address:

        • If you have not yet federated the node to the Deployment Manager, use the following URL:

          http://Host_Name:Port/Context_Root/servlet/dispatch/ext

        • If you have already federated the node to the Deployment Manager, use the following URL:

          http://Host_Name:Port/Context_Root/servlet/dispatch

          Images and icons may not display properly for this URL, but it is sufficient to validate that the IBMConnectionsMetrics folder and subfolders exist.

        where the Host_Name, Port, and Context_Root values are the same as those used in step 1. For example:

        http://cognosserver.example.com:9083/cognos/servlet/dispatch

        The dispatcher displays tabs listing public and private folders.

      2. In the dispatcher, click the Public tab; in the list of public folders click the IBMConnectionsMetrics folder and verify that it contains three subfolders (Metrics, MetricsCubeDS, and MetricsDBQuery).


    What to do next

    If you deployed Cognos Business Intelligence as a prerequisite step to installing IBM Connections, continue the next section, Install IBM Connections. You will complete the Cognos configuration tasks after you install the Connections applications.

    If you originally installed IBM Connections without first deploying Cognos Business Intelligence and are now deploying the Cognos server, skip the Connections installation topics (which you have already completed) and instead go directly to Configure Cognos Business Intelligence.


    Install IBM Connections

    Select the IBM Connections applications and install them in a clustered deployment.

    An IBM Connections deployment consists of the following components:

    • WAS nodes:

      • One node with IBM WAS Network Deployment Manager (DM) installed.

      • One or more WAS nodes that can be federated into the DM cell. These nodes are hosts for cluster members.

    • A system with a DB server installed.

    • An LDAP server.

    • A system with IBM HTTP Server installed.

    Before beginning the installation, you must understand the prerequisites for IBM Connections 4.0. For more information, see the Before installing topic and ensure that you meet all the conditions that are prescribed for your deployment environment.


    Before installing

    Verify that all necessary prerequisite conditions are complete before installing IBM Connections.


    Prerequisites

    • Check the Release notes for late-breaking issues.

    • If you previously installed IBM Installation Manager, update it to V1.4.4 or higher. For more information, go to the IBM Installation Manager updates webpage.

      Use the same user account to install IBM Installation Manager and IBM Connections.

    • IBM Installation Manager presents three options for the type of deployment that you can install. For more information about these options, see the Deployment options topic.

    • The IBM Connections installation process supports the creation of new server instances and clusters. Do not use existing clusters to deploy IBM Connections.

    • You can install IBM Connections with either root or non-root accounts on AIX and Linux, or administrator or non-administrator accounts on Microsoft Windows. For more information, see the Installing as a non-root user topic.

    • Complete the Pre-installation tasks.

      If you are migrating from IBM Connections 3.0.1, you need to complete only the following tasks:

        Prepare to configure the LDAP directory.

      • Install IBM WAS if you are installing on the same host as 3.0.1.

      • Set up federated repositories

      • Do not complete the Pre-installation tasks for creating DBs or populating the Profiles DB. The migration process handles those tasks separately.

    • Install IBM WAS Network Deployment (Application Server option) on each node. IBM Connections is installed on the system where WAS Deployment Manager is installed. For more information, see the Installing IBM WAS topic.

    • Back up the profile_root/Dmgr01 directory.

    • Configure WAS to communicate with the LDAP directory. For more information, see the Set up federated repositories topic.

    • Prepare directories to use as content stores. You need to provide shared content stores on network share devices and local content stores on each node. Both shared and local content stores must be accessible using the same path from all nodes and from the Deployment Manager.

    • Set the system clocks on the Deployment Manager and the nodes to within 1 minute of each other. If these system clocks are further than 1 minute apart, you might experience synchronization errors.

    • Copy the JDBC files for your DB type to the Deployment Manager (DM) and then from the DM to each node. Place the copied files in the same location on each node as their locations on the DM. If, for example, you copied the db2jcc.jar file from the C:\IBM\SQLLIB directory on the DM, place the copy in the C:\IBM\SQLLIB directory on each node.

      JDBC files

      Database type JDBC files
      DB2

      db2jcc.jar

      db2jcc_license_cu.jar

      Oracle

      ojdbc6.jar

      Ensure that you are using the latest version of the ojdbc6.jar file.

      SQL Server

      sqljdbc4.jar

    • If you are going to use a trusted SSL certificate, ensure that is available before you begin the installation.

    • If you do not plan to deploy IBM Cognos Business Intelligence now to support metrics, you can still install the Metrics application along with the other IBM Connections applications. This enables Connections to begin collecting event data immediately and store it in the Metrics DB for use when Cognos is available to provide reports.

    • (Microsoft Windows) You must use an administrator account to install IBM Connections on Windows. If you are installing on Windows Server 2008, you must use a local administrator account. If you use a domain administrator account, the installation might fail.

    • (Linux only) If you receive an error message after attempting to start IBM Installation Manager, you might need to install additional 32-bit libraries. For more information about required Linux libraries, see the Linux libraries topic. For more information about IBM Installation Manager errors, go to the Unable to install Installation Manager on RHEL 6.0/6.1 (64-bit) webpage.

    • (AIX and Linux) Ensure that the directory paths that you enter contain no spaces.

    • (AIX and Linux) Ensure that the Open File Descriptor limit is 8192. For information about setting the file limit, go to the Installation error messages topic and search for error code CLFRP0042E.

    • (AIX only) IBM Installation Manager requires additional libraries for the AIX operating system. For more information, go to the Required filesets on AIX for Installation Manager webpage.

    • (AIX only) If IBM Installation Manager hangs while being installed on your system, you might need to update your version of the software. For more information, read the IBM Installation Manager hangs on 64-bit AIX systems technote.

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

      After installing the GNU-compatible compression program, change to the directory where you downloaded the IBM Connections tar file. Enter the following command to extract the files from the file:

      gtar -xvf Lotus_Connections_wizard_aix.tar

      This command creates a directory named after IBM Installation Manager.

    Tips:

    • Establish naming conventions for nodes, servers, clusters, and web servers.

    • Use a worksheet to record the UIDs, passwords, server names, and other information required during and after installation. For more information, see the Worksheet for installing IBM Connections topic.

    • Install and configuring IBM Connections is a complex process; not only should you read the instructions but you must also pay attention to the Before you begin prerequisites in each topic.


    Linux libraries

    The complete list of Linux libraries required for deploying IBM Connections 4.0.


    Linux

    Install the following Linux packages and libraries:

    Ensure that the GTK library is available on your system. Even when you are installing on a 64-bit system, you still need the 32-bit version of the GTK library.

    compat-libstdc++-33.x86_64

    libcanberra-gtk2.i686

    PackageKit-gtk-module

    gtk2.i686

    compat-libstdc++-33.i686

    compat-libstdc++-296

    compat-libstdc++

    libXtst.i686


    Cognos

    If you plan to install Cognos, you also need the libraries listed in the Cognos BI 10.1.1 Software Environments - Required Patches technote.

    Both 32-bit and 64-bit versions are required.


    Install as a non-root user

    Grant permissions to a non-root user to install IBM Connections.

    Ensure that you complete all the prerequisite tasks that are relevant for your environment. For more information, see the Before installing topic. This task applies to the AIX and Linux operating systems only.

    By default, only root users have the necessary permissions to install an IBM Connections deployment. On the AIX and Linux operating systems, you can permit non-root users to install the product by changing their permissions to access certain data directories. On the Windows operating system, the user must be a member of the administrator group.

    The non-root user must be the same user who installed IBM WAS.

    To grant the necessary permissions to a non-root user:

    1. Unless it already exists, create the non-root user account to use to install IBM Connections.

    2. If it does not already exist, create a home directory for the user.

    3. Edit the install.ini file:

      1. Open the install.ini file for editing from the following location:

        • AIX: IBM_Connections_set-up directory/IM/aix/install.ini

        • Linux: IBM_Connections_set-up directory/IM/linux/install.ini

        • Linux on System z: IBM_Connections_set-up directory/IM/zlinux/install.ini

      2. In the second line of the file, change admin to nonadmin.

      3. Save and close the file.

    4. Open a command prompt and grant the appropriate permissions to the user by entering the commands shown in the following table:

      • AIX or Linux:

        Use either the chmod or chown commands, depending on your security environment. Use the chown commands to grant permissions to a user and group but ensure that the group includes the user account that installed WAS.

        Non-root user permissions

        Directory Permissions chmod command chown command
        app_server_root RWX chgrp -R non-root_user_group app_server_root chmod -R g+wrx app_server_root

        where non-root_user_group is a user group that contains the non-root user account.

        chown -R non-root_ID:group app_server_root

        where non-root_ID is the non-root user account and group is the user group that contains this account.

        IBM_ Connections set-up directory

        RWX chgrp -R non-root_user_group IBM_Connections_set-up_directory chmod -R g+wrx IBM_Connections_set-up_directory chown -R non-root_ID:group IBM_connections_set-up_directory
        connections_root RWX chgrp -R non-root_user_group connections_root chmod -R g+wrx connections_root chown -R non-root_ID:group connections_root
        IM_root RWX chgrp -R non-root_user_group IM_root chmod -R g+wrx IM_root chown -R non-root_ID:group IM_root
        shared_resources_root RWX chgrp -R non-root_user_group shared_resources_root chmod -R g+wrx shared_resources_root chown -R non-root_ID:group shared_resources_root

        var/ibm/InstallationManager

        RWX chmod -R ugo+rwx /var/ibm/InstallationManager

        Grant permissions to this folder only if the root user installed IBM Installation Manager.

        chown -R non-root_ID:group /var/ibm/InstallationManager

    5. Install IBM Connections using either the wizard, the console, or a silent installation method.


    Example

    Grant permissions to a non-root user who wants to install an IBM Connections deployment on Linux.

    Assumptions:

    • The app_server_root directory is /opt/IBM/Websphere/Appserver.

    • The IBM_Connections_set-up_directory directory is /opt/ConnectionsSetup.

    • The connections_root, IM_root, and shared_resources_root directories are subdirectories of the /opt/ConnectionsInstallation directory.

    • The non-root user account is a member of the ConnectionsInstallers group.

    Procedure:

    1. Create a non-root user account called ConnectionsInstaller.

    2. Create a home directory for the new user account.

    3. Add the new user account to the ConnectionsInstallers group.

    4. Open a command prompt and enter the following commands:

      1. chgrp -R ConnectionsInstallers /opt/IBM/Websphere/Appserver chmod -R g+wrx /opt/IBM/Websphere/Appserver chown -R ConnectionInstaller:ConnectionsInstallers /opt/IBM/Websphere/Appserver

      2. chgrp -R ConnectionsInstallers /opt/ConnectionsSetup chmod -R g+wrx /opt/ConnectionsSetup chown -R ConnectionInstaller:ConnectionsInstallers /opt/IBM/Websphere/Appserver

      3. chgrp -R ConnectionsInstallers /opt/ConnectionsInstallation chmod -R g+wrx /opt/ConnectionsInstallation chown -R ConnectionInstaller:ConnectionsInstallers /opt/IBM/Websphere/Appserver


    Install IBM Connections 4.0

    Install IBM Connections.


    Ensure that you complete all the prerequisite tasks that are relevant for your environment. For more information, see the Before installing topic.

    To install IBM Connections, run the IBM Installation Manager wizard on the system where the Deployment Manager is installed.

    If an error occurs during installation, IBM Installation Manager cancels the installation and rolls back the installation files. Installation errors are usually caused by environment problems such as insufficient disk space, privilege issues, or corruption of a WebSphere profile. If your installation is canceled, complete the following steps:

    1. Identify and resolve the error that caused the cancellation. After canceling the installation, IBM Installation Manager displays an error message with an error code. You can look up the error code in the Installation error messages topic or check the log files.

    2. Restore the Deployment Manager profile from your backup.

    3. Delete the connections_root directory.

    4. Start this task again.

    To install IBM Connections, complete the following steps:

    1. On each node, stop any running instances of WAS and WebSphere node agents.

    2. Start WAS Network Deployment Manager.

    3. Copy the installation files to the system hosting the Deployment Manager.

      Ensure that the directory path that you enter contains no spaces.

    4. From the Connections setup directory, run the file to start the IBM Connections launchpad:

      • AIX or Linux: Connections set-up/launchpad.sh

      • Windows: Connections set-up\launchpad.exe

      The launchpad needs a web browser to run. If your system does not have a web browser, take one of the following actions:

      • Install a web browser.

      • Install IBM Connections in silent mode. For more information, see the Installing silently topic.

      • Start IBM Installation Manager manually:

        1. Open a command prompt.

        2. Change to the Connections_install/IM/OS directory, where OS is your operating system.

        3. Enter ./install.sh -input response.xml.

    5. Click Install IBM Connections 4.0 and then click Launch the IBM Connections 4.0 install wizard.

      Click the links to Documentation, Pre-installation tasks, or Post-installation tasks to view the product documentation.

    6. In the Select packages to install window, select the packages to install and click Next to continue.

      Accept the default setting for Show all versions.

      If you are using an earlier version of IBM Installation Manager than 1.4.4, the 1.4.4 package is selected in this window.

      Click Check for Other Versions and Extensions to search for updates to IBM Installation Manager.

    7. Review and accept the license agreement by clicking I accept the terms in the license agreements. Click Next.

    8. Set the location of shared directories for IBM Installation Manager.

      1. Set the location of the Shared Resources Directory.

      2. Set the location of the Installation Manager Directory. This option appears only if you have not previously installed IBM Installation Manager.

      3. Click Next.

    9. The Shared Resources directory stores resources that can be shared by multiple packages. If you used IBM Installation Manager before, the wizard automatically enters this value.

    10. The Installation Manager directory stores resources that are unique to the packages that you are installing.

    11. Choose to Use the existing package group or Create a new package group.

      If you are using the wizard for the first time, the Use the existing package group option is not available.

    12. Set the location of the installation directory for IBM Connections. You can accept the default directory location, enter a new directory name, or click Browse to select an existing directory. Click Next.

    13. Confirm the applications to install and click Next. You can select from the following options:

      • The wizard always installs the Home page, News, and Search applications.

      • To use media gallery widgets in the Communities application, you must install the Files application. Media gallery widgets store photo and video files in the Files DB.

      • Even if you are not configuring Cognos yet, install Metrics now so that your application data is captured from the moment that IBM Connections is deployed. Metrics captures your deployment data whereas Cognos is used for viewing data reports. If you install Metrics at a later stage, you will not have any data reports for the period before you installed Metrics.

      Option Description
      IBM Connections 4.0 Install all IBM Connections applications.

      Activities Collaborate with colleagues.

      Blogs Write personal perspectives about projects.

      Communities Interact with people on shared projects.

      Bookmarks Bookmark important websites.

      Files Share files among users.

      Forums Discuss projects and exchange information.

      Metrics Identify and analyze usage and trends.

      Mobile Access IBM Connections from mobile devices.

      Moderation Forum and community owners can moderate the content of forums.

      Profiles Find people in the organization.

      Wikis Create content for your website.

    14. Enter the details of your WAS environment:

      1. Select the WAS installation location that contains the Deployment Manager.

        Note the default path to the WAS installation:

        • AIX: /usr/IBM/WebSphere/AppServer

        • Linux: /opt/IBM/WebSphere/AppServer

        • Windows: C:\Program Files\IBM\WebSphere\AppServer

      2. Enter the properties of the WAS Deployment Manager (DM):

        Deployment Manager profile

        Name of the DM to use for IBM Connections. The wizard automatically detects any available DMs.

        Host name

        Name of the host DM server.

        Administrator ID

        The administrative ID of the DM.
        This ID is set to the connectionsAdmin J2C authentication alias, which is mapped to the following J2EE roles: dsx-admin, widget-admin, and search-admin. It is also used by the service integration bus. To use security management software such as Tivoli Access Manager or SiteMinder, the ID that you specify here must exist in the LDAP directory. For more information, see the Switching to unique administrator IDs for system level communication topic.

        Administrator Password

        The password for the administrative ID of the DM.

        SOAP port

        The SOAP port of the DM. The wizard automatically detects this value.

      3. Click Validate to verify the DM information that you entered and that application security is enabled on WAS. If the verification fails, IBM Installation Manager displays an error message.

        (AIX and Linux) The validation process checks the number of open files that are supported by your system. If the value for this parameter, known as the Open File Descriptor limit, is too low, a file open error, memory allocation failure, or connection establishment error could occur. If one of these errors occurs, exit the installation wizard and increase the open file limit before restarting the wizard. To set the file limit, go to the Installation error messages topic and search for error code CLFRP0042E. The recommended value for IBM Connections is 8192. For more information about the Open File Descriptor limit, see the documentation for your operating system.

      4. When the verification test is successful, click Next.

      The wizard creates a dmInfo.properties file under WAS to record details of the cell, node, and server.

    15. Configure your topology. For more information about each option, see the Deployment options topic.

      If you return to this page from a later page in the installation wizard, your settings are still present but not visible. If you want to change any settings, you must enter all of the information again. If you do not want to change your initial settings, click Next.

      • Small deployment:

        1. Select the Small deployment topology.

        2. Enter a Cluster name for the topology.

        3. Select a Node.

        4. Click Next.

      • Medium deployment:

        1. Select the Medium deployment topology.

        2. Select the default value or enter a Cluster name for each application or for groups of applications.

          For example, use Cluster1 for Activities, Communities, and Forums.

          IBM Installation Manager creates servers and clusters when required.

        3. Select a Node for each cluster. Accept the predefined node or select a different node.
          These nodes host application server instances that serve IBM Connections applications. You can assign multiple nodes to a cluster, where each node is a server member of that cluster.

        4. Enter a Server member name for the selected node. Choose the default or enter a custom name.

          If you enter a custom server member name, the name must be unique across all nodes in your deployment.

        5. Click Next.

      • Large deployment:

        1. Select the Large deployment topology.

        2. Enter a Cluster name for each application.

          IBM Installation Manager creates servers and clusters when required.

        3. Select a Node for each cluster. Accept the predefined node or select a different node.
          These nodes host application server instances that serve IBM Connections applications. You can assign multiple nodes to a cluster, where each node is a server member of that cluster.

        4. Enter a Server member name for the selected node. Choose the default or enter a custom name.

          If you enter a custom server member name, the name must be unique across all nodes in your deployment.

        5. Click Next.

    16. Enter the DB information:

      If you return to this page from a later page in the installation wizard, your settings are still present but not visible. If you want to change any settings, you must enter all of the information again. If you do not want to change your initial settings, click Next.

      1. Specify whether the installed applications use the same DB server or instance: Select Yes or No.

        If allowed by your DB configuration, you can select multiple DB instances as well as different DB servers.

      2. Select a Database type from one of the following options:

        • IBM DB2 Universal Database.
        • Oracle Enterprise Edition
        • Microsoft SQL Server Enterprise Edition

      3. Enter the Database server host. For example: appserver.enterprise.example.com

        If your installed applications use different DB servers, enter the DB host for each application.

      4. Enter the Port number of the DB server. The default values are: 50000 for DB2, 1521 for Oracle, and 1433 for SQL Server.

        If your installed applications use different DB servers or instances, enter the port for each DB server or instance.

      5. Enter the JDBC driver location. For example:

        • AIX: /usr/IBM/WebSphere/AppServer/lib
        • Linux:

          /opt/IBM/WebSphere/AppServer/lib

        • Windows:

          C:\IBM\WebSphere\Appserver\lib

      6. Ensure that the following JDBC driver libraries are present in the JDBC directory:

        DB2

        db2jcc.jar and db2jcc_license_cu.jar

        Ensure that your user account has the necessary permissions to access the DB2 JDBC files.

        Oracle

        ojdbc6.jar

        SQL Server

        Download the SQL Server JDBC 2 driver from the Microsoft website to a local directory and enter that directory name in the JDBC driver library field.

        The directory must not contain the sqljdbc.jar file, only the sqljdbc4.jar file. Even though the data source is configured to use the sqljdbc4.jar file, an exception occurs if both files are present in the same directory.

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

      7. Enter the User ID and Password for each DB. If each DB uses the same user credentials, select the Use the same password for all applications check box and then enter the UID and password for the first DB in the list.

        If your DB type is Oracle, connect to the DB with the UID that you used when you created the application DB.

      8. Click Validate to verify your DB settings. If the validation fails, check your DB settings. When the validation succeeds, click Next.

        IBM Installation Manager tests your DB connection with the DB values that you supplied. You can change the DB configuration later in the WAS Integrated Solutions Console.

    17. Specify your Cognos configuration details as explained in the table, and then click Validate to verify your connection.

      • The IBM Cognos configuration panel appears only if you chose to install the Metrics application earlier in this task.

      • Ensure that Cognos Business Intelligence Server is running because the wizard pings the server during the validation process.

      • If you do not want to deploy Cognos now, enter dummy values for UID and password, click Load node info, and then click Validate. Ignore the error message that appears. To continue installing IBM Connections, click Next. For information about deploying Cognos, see the Installing Cognos Business Intelligence topic. For information about resolving Cognos validation problems, see the Troubleshooting Cognos validation problems topic.

      Option Description
      Administrator UID Set the user name of the administrator account that you selected for Cognos Business Intelligence. This user must be included in the LDAP directory used with Connections.

      Administrator password Set the password for the Cognos administrator.

      Name Click the Load node info button to retrieve the list of available nodes and profiles, then click the arrow and select the WebSphere profile that hosts the Cognos BI server. The profile you select here must match the profile you specified as the was.profile.name in the cognos-setup.properties file.

      Host name

      This is a non-editable field that is populated when you select a profile in the Name field. Seeing the associated host for each profile/node can help you choose the correct node where the Cognos BI Server is running.

      Server name There might be multiple servers installed on the same computer as the Cognos BI server; click the arrow and select the instance that represents the Cognos server. Must match what you specified as the cognos.was.server.name in the cognos-setup.properties file.
      Tip: A default value of cognos_server was assigned in the properties file, so unless you changed that value, use it now.

      Port Set the number of the port that the Cognos BI Server is listening on; this defaults to port 9080 but might have been changed. You can determine the port by checking the WC_defaulthost value in the following file: WAS_install_root/config/cells/Cell_Name/nodes/Node_Name/serverindex.xml; for example on Windows:

      C:\IBM\WebSphere\AppServer\profiles\AppSvr01\config\cells\lc40Cell01\nodes\lc40CellManager01\serverindex.xml

      Web context root The context root determines which requests will be delegated to the Cognos application for processing (any request beginning with this string will be handled by Cognos). Must match the cognos.contextroot specified in the cognos-setup.properties file.
      Tip: A default value of cognos was assigned in the properties file, so unless you changed that value, use it now.

      If you deployed Cognos Business Intelligence and the validation fails at this point, you can click Next and continue installing IBM Connections. After the installation is complete, you can correct the validation issue as explained in the topic, Troubleshooting Cognos validation problems.

    18. Set the locations of the content stores. All nodes in a cluster must have read-write access to shared content. Both shared and local content stores must be accessible using the same path from all nodes and from the DM. Each content store is represented by a corresponding WebSphere variable that is further defined as shared or local. Local content is node-specific.

      If you are migrating from IBM Connections 3.0.1, you can reuse your existing content stores in 4.0. For more information, see the Content store migration topic.

      1. Enter the location of the Shared content store. The shared content store usually resides in a shared repository that grants read-write access to the DM and all the nodes. Use one of the following methods to create a shared data directory:

        • Network-based file shares (for example: NFS, SMB/Samba, and so on)

        • Storage area network drives (SAN)

        • If you are using a shared-file system on Microsoft Windows, specify the file location using the Universal Naming Convention (UNC) format. For example: \\server_name\share_name.
          (Windows only) If you use Remote Desktop Connection to map shared folder drives, ensure that you use the same session to start the node agents. Otherwise, the shared drives might be invisible to the nodes.

      2. Enter the location of the Local content store.

      3. Click Validate to verify that the account that you are using to install IBM Connections has write access to the content store.

      4. Click Next.

    19. Select a Notification solution. Notifications are email messages to users about new information and events in your IBM Connections deployment.

      • Enable Notification only.

        Use notifications but without the ReplyTo capability.

      • Enable Notification and ReplyTo.

        Use notifications and the ReplyTo capability. To use ReplyTo, your mail server must be able to receive all the replies and funnel these replies into a single inbox. IBM Connection connects to the mail server using the IMAP protocol.

      • None.

        Do not use a notification solution in your IBM Connections deployment. You can configure notifications after installation.

    20. Select and specify a mail server solution and then click Next.

      • WebSphere Java Mail Session: Use a single mail server for all notifications. Select this option if you can access an SMTP server directly using the host.

        Complete the following fields to identify the mail server to use for sending email:

        Host name of SMTP messaging server

        Enter the host or IP address of the preferred SMTP mail server.

        This SMTP server requires authentication

        Select the check box to force authentication when mail is sent from this server.

        User ID

        If the SMTP server requires authentication, enter the UID.

        Password

        If the SMTP server requires authentication, enter the user password.

        Encrypt outgoing mail traffic to the SMTP messaging server using SSL

        Select this check box if you want to encrypt outgoing mail to the SMTP server.

        Port

        Accept the default port of 25, or enter port 465 if you are using SSL.

      • DNS MX Records: Use information from DNS to determine which mail servers to use. Select this option if you use a Domain Name System (DNS) server to access the SMTP messaging server.

        Messaging domain name

        Enter the name or IP address of the messaging domain.

        Choose a specific DNS server

        Select this check box if you want to specify a unique SMTP server.

        DNS server for the messaging servers query

        Enter the host or IP address of the DNS server.

        DNS port used for the messaging servers query

        Enter the port that is used for sending queries using the messaging server.

        This SMTP server requires authentication

        Select the check box to force authentication when notification mail is sent from this server.

        User ID

        If SMTP authentication is required, enter the administrator user ID for the SMTP server.

        Password

        If SMTP authentication is required, enter the password for the administrator user of the SMTP server.

        Encrypt outgoing mail traffic to the SMTP messaging server using SSL

        Select the check box if you want to use the Secure Sockets Layer (SSL) when connecting to the SMTP server.

        Port

        Set the port to use for the SMTP server connection. The default port for the SMTP protocol is 25. The default port number for SMTP over SSL is 465.

      • If you click Do not enable Notification, IBM Installation Manager skips the rest of this step. You can configure notification later.

    21. If you selected the Notification and ReplyTo option, configure the ReplyTo email settings. IBM Connections uses a unique ReplyTo address to identify both the person who replied to a notification and the event or item that triggered the notification.

      1. Enter a domain name. For example: mail.example.com.

        This domain name is used to build the ReplyTo address. The address consists of the suffix or prefix, a unique key, and the domain name.

      2. The reply email address is given a unique ID by the system. You can customize the address by adding a prefix or suffix, using a maximum of 28 characters. This extra information is useful if the domain name is already in use for other purposes. Select one of the following options:

        None

        Use the ID generated by the system.

        Prefix

        Enter a prefix in the Example field.

        Suffix

        Enter a suffix in the Example field.

        As you select an option, the wizard creates an example of the address, combining your selection with the ID generated by the system.

        For example:

        • unique_id@domain

        • prefix_unique_id@domain

        • unique_id_suffix@domain -

      3. Specify the details of the mail file to which ReplyTo emails are sent:

        Server

        The domain where your mail server is located. For example: replyTo.mail.example.com.

        User ID

        The user account for the mail server. The UID and password are credentials that IBM Connections will use to poll the inbox on the mail server to retrieve the replies and process the content. IBM Connections connects to the mail server using IMAP.

        Password

        Password for the user account. The UID and password are credentials that IBM Connections will use to poll the inbox on the mail server to retrieve the replies and process the content. IBM Connections connects to the mail server using IMAP.

      4. Click Next.
      You can modify the ReplyTo settings after installation. To edit the domain name and prefix or suffix, edit the news-config.xml file. For more information, see the Post-migration step for status updates topic. To edit the server and authentication details, log in to the WAS Integrated Solutions Console and navigate to the Mail Sessions page, where you can edit the configuration.

    22. Review the information that you have entered. To revise your selections, click Back. To finalize the installation, click Next.

    23. Review the result of the installation. Click Finish to exit the installation wizard.

    24. Restart the Deployment Manager:

      • AIX or Linux: Open a command prompt and change to the profile_root/Dmgr01/bin directory. Enter the ./stopManager.sh command and then enter the ./startManager.sh command.

      • Windows: Stop and restart the Deployment Manager service.

    25. Start all the federated nodes and enter the startNode command. Repeat these steps for each node:

      1. Log in to a node.

      2. From a command line, change to the profile_root/bin directory.

      3. Enter the startNode command for your operating system:

        • AIX or Linux: ./startNode.sh

        • Windows: startNode.bat

    26. Log in to the Integrated Solutions Console on the DM to perform a full synchronization of all nodes.

      1. Go to System administration > Nodes.

      2. Select the nodes and click Full Resynchronize.

      Wait until the DM copies all the application EAR files to the installedApps directory on each of the nodes. This process can take up to 30 minutes.

      To verify that the DM has distributed the application EAR files to the nodes, check the SystemOut.log file of each node agent. The default path to the SystemOut.log file on a node is profile_root/logs/nodeagent.

      Look for a message such as the following example: ADMA7021I: Distribution of application application_name completed successfully. where application_name is the name of an IBM Connections application.

    27. Restart the Deployment Manager.

    28. Start all your IBM Connections clusters:

      1. Log in to the Integrated Solutions Console on the DM

      2. Go to Servers > Clusters > WebSphere Application server clusters.

      3. Select the IBM Connections clusters and click Start.

      If you installed a cluster with multiple Search nodes, create the initial index. For more information about creating the Search index, see the Creating the initial Search index topic.

        If you are installing a non-English language deployment, enable Search dictionaries. For more information, see the Enabling Search dictionaries topic.

      1. The index is ready when the INDEX.READY and CRAWLING_VERSION files are present in the index directory.

      If some applications do not start, the file-copying process might not have completed. Wait a few minutes and start the applications.


    Results

    The installation wizard has installed IBM Connections in a network deployment.

    To confirm that the installation was successful, open the log files in connections_root/logs. Each IBM Connections application installed has a log file, using the following naming format: application_nameInstall.log, where application_name is the name of an IBM Connections application. Search for the words error or exception to check whether any errors or exceptions occurred during installation.

    To view the log file for system events that occurred during the installation, open the date_time.xml file, where date_time represents the date and time of the installation. The file is located by default in the following directory:

    • AIX or Linux (root user): /var/ibm/InstallationManager/logs

    • AIX or Linux (non-root user): /home/user/var/ibm/Installation Manager/logs where user is the non-root user name

    • Windows Server 2008 64-bit: C:\ProgramData\IBM\Installation Manager\logs


    What to do next

    Complete the post-installation tasks that are relevant to your installation. For more information, see the Post-installation tasks topic.

    Access network shares:

    If you installed WAS on Microsoft Windows and configured it to run as a service, ensure that you can access network shares. For more information, see the Accessing Windows network shares topic.


    Install in console mode

    Install IBM Connections in console mode. This method is convenient if you cannot or do not want to use the graphical mode.

    Ensure that you complete all the prerequisite tasks that are relevant for your environment. For more information, see the Before installing topic. Use console mode to complete the installation process in a non-graphical environment. This mode is useful when you have to install IBM Connections on a system that does not have a video card.

    In steps where you enter custom information, such as server details, you can type P at any time to return to the previous input choice in that step. However, you cannot type P to return to a previous step.

    To install IBM Connections, you need to use IBM Installation Manager, which manages the installation process.

    To install IBM Connections in console mode, complete the following steps:

    1. On each node, stop any running instances of WAS and WebSphere node agents.

    2. Start WAS Network Deployment Manager.

    3. Copy the installation files to the system hosting the Deployment Manager.

      Ensure that the directory path that you enter contains no spaces.

    4. Start IBM Installation Manager in console mode:

      Run IBM Installation Manager on the system where the Deployment Manager is installed.

      • If Installation Manager is already installed, open a command prompt and change to the IBM Installation Manager installation directory. Then run the following command:

        • AIX or Linux: /opt/IBM/InstallationManager/eclipse/tools/imcl -c

        • Windows: \Program Files\IBM\Installation Manager\eclipse\tools\imcl.exe -c

      • To install both IBM Installation Manager and IBM Connections, open a command prompt and change to the IBM Installation Manager installation directory. Then run the following command:

        • AIX: Lotus_Connections_Install/IM/aix/install.console.sh

        • Linux: Lotus_Connections_Install/IM/linux/install.console.sh

        • Windows: Lotus_Connections_Install\IM\windows\install.console.bat

        The batch script calls a response file which contains information about the repositories for both IBM Installation Manager and IBM Connections.

      • To use another language for the installation process, open a command prompt, change to the IBM Installation Manager installation directory, and run the following command:

        • AIX: Lotus_Connections_Install/IM/aix/tools/imcl -c -nl language_code

        • Linux: Lotus_Connections_Install/IM/linux/tools/imcl -c -nl language_code

        • Windows: \Program Lotus_Connections_Install\IM\windows\tools\imcl.exe -c -nl language_code

        where language_code is the two-letter code for a language, such as fr for French.

    5. In the console window, specify the IBM Connections repository:

      If you chose the option to run the install.console.bat|sh file in Step 4, you can skip this step.

      1. Type P to edit preferences.

      2. Type 1 to specify repositories.

      3. Type D to add a repository.

      4. Set the repository path for IBM Connections 4.0, for example: Lotus_Connections/repository.xml.

      5. Type A to save the repository information.

      6. Type C to return to the console window.

    6. In the Select packages to install step, type 1 to select the package and then type N to proceed.

    7. Review the license agreement by typing the appropriate number to view license information. To accept the license agreement, type A. Type N to proceed.

    8. Set the location of the shared resources directory for IBM Installation Manager.

      1. Enter the location of the Shared Resources Directory.

      2. Type N to proceed.

      The Shared Resources directory stores resources that can be shared by multiple packages. If you used IBM Installation Manager before, the wizard automatically enters this value.

      Ensure that the directory path that you enter contains no spaces.

    9. Set the location of the IBM Installation Manager installation directory.

      1. Enter the location of the Installation Manager Directory.

      2. Type N to proceed.

      This option is available only if you have not previously installed IBM Installation Manager.

      The Installation Manager directory stores resources that are unique to the packages that you are installing.

      Ensure that the directory path that you enter contains no spaces.

    10. Set the locations of the package group for IBM Installation Manager and the installation directory for IBM Connections:

      1. The wizard automatically detects the IBM Connections package group. Type M to change the default location where the package group will be installed.

      2. Type N to proceed.

      3. To accept the default location for the IBM Connections installation directory, type N. To specify a new directory name, type M and enter the new directory name and path.

      4. Type N to proceed.

    11. Select the applications to install and then type N to proceed. You can select from the following options:

      • The wizard always installs the Home page, News, and Search applications.

      • If you clear the selections of the Home page, News, or Search applications, the wizard will exit.

      • To use media gallery widgets in the Communities application, you must install the Files application. Media gallery widgets store photo and video files in the Files DB.

      • Even if you are not configuring Cognos yet, install Metrics now so that your application data is captured from the moment that IBM Connections is deployed. Metrics captures your deployment data whereas Cognos is used for viewing data reports. If you install Metrics at a later stage, you will not have any data reports for the period before you installed Metrics.

      Option Description
      IBM Connections 4.0 Install all IBM Connections applications.

      Activities Collaborate with colleagues.

      Blogs Write personal perspectives about projects.

      Communities Interact with people on shared projects.

      Bookmarks Bookmark important websites.

      Files Share files among users.

      Forums Discuss projects and exchange information.

      Metrics Identify and analyze usage and trends.

      Mobile Access IBM Connections from mobile devices.

      Moderation Forum and community owners can moderate the content of forums.

      Profiles Find people in the organization.

      Wikis Create content for your website.

    12. Enter the details of your WAS environment:

      1. Select the WAS installation location that contains the Deployment Manager.

        Note the default path to the WAS installation:

        • AIX: /usr/IBM/WebSphere/AppServer

        • Linux: /opt/IBM/WebSphere/AppServer

        • Windows: C:\Program Files\IBM\WebSphere\AppServer

      2. Enter the properties of the WAS Deployment Manager (DM):

        Deployment Manager profile

        Name of the DM to use for IBM Connections. The wizard automatically detects any available DMs.

        Host name

        Name of the host DM server.

        Administrator ID

        The administrative ID of the DM.
        This ID is set to the connectionsAdmin J2C authentication alias, which is mapped to the following J2EE roles: dsx-admin, widget-admin, and search-admin. It is also used by the service integration bus. To use security management software such as Tivoli Access Manager or SiteMinder, the ID that you specify here must exist in the LDAP directory. For more information, see the Switching to unique administrator IDs for system level communication topic.

        Administrator Password

        The password for the administrative ID of the DM.

        SOAP port

        The SOAP port of the DM. The wizard automatically detects this value.

      3. Press Enter to verify the DM information that you entered. The verification process also checks that application security is enabled on WAS. If the verification fails, IBM Installation Manager displays an error message.

        (AIX and Linux) The validation process checks the number of open files that are supported by your system. If the value for this parameter, known as the Open File Descriptor limit, is too low, a file open error, memory allocation failure, or connection establishment error could occur. If one of these errors occurs, exit the installation wizard and increase the open file limit before restarting the wizard. To set the file limit, go to the Installation error messages topic and search for error code CLFRP0042E. The recommended value for IBM Connections is 8192. For more information about the Open File Descriptor limit, see the documentation for your operating system.

      4. If the verification check is successful, type N to proceed. If verification fails, press B to re-enter the required information.

      The wizard creates a dmInfo.properties file under WAS to record details of the cell, node, and server.

    13. Configure your topology. For more information about each option, see the Deployment options topic.

      • Small deployment:

        1. Type 1 to select the Small deployment topology.

        2. Enter a Cluster name for the topology.

        3. Select a Node.

        4. Enter a Server member name for the node.

        5. Type N to proceed.

      • Medium deployment:

        1. Type 2 to select the Medium deployment topology.

        2. Select the default value or enter a Cluster name for each application or for groups of applications.

          For example, use Cluster1 for Activities, Communities, and Forums.

          IBM Installation Manager creates servers and clusters when required.

        3. Select a Node for each cluster. Accept the predefined node or select a different node.
          These nodes host application server instances that serve IBM Connections applications. You can assign multiple nodes to a cluster, where each node is a server member of that cluster.

        4. Enter a Server member name for the selected node. Choose the default or enter a custom name.

          If you enter a custom server member name, the name must be unique across all nodes in your deployment.

        5. The topology specified is displayed. To re-specify any details, type the number that corresponds to the application; for example, type 1 for Activities.

        6. Type N to proceed.

      • Large deployment:

        1. Type 3 to select the Large deployment topology.

        2. Enter a Cluster name for each application.

          IBM Installation Manager creates servers and clusters when required.

        3. Select a Node for each cluster. Accept the predefined node or select a different node.
          These nodes host application server instances that serve IBM Connections applications. You can assign multiple nodes to a cluster, where each node is a server member of that cluster.

        4. Enter a Server member name for the selected node. Choose the default or enter a custom name.

          If you enter a custom server member name, the name must be unique across all nodes in your deployment.

        5. The topology specified is displayed. To re-specify any details, type the number that corresponds to the application; for example, type 1 for Activities.

        6. Type N to proceed.

    14. Enter the DB information:

      1. Specify whether the installed applications use the same DB server or instance: Type 1 to specify that the applications use same DB server or instance; type 2 to specify that they use different DB servers or instances.

        If allowed by your DB configuration, you can select multiple DB instances as well as different DB servers.

      2. Select a Database type from one of the following options:

        • IBM DB2 Universal Database
        • Oracle Enterprise Edition
        • Microsoft SQL Server Enterprise Edition

      3. Enter the Database server host. For example: appserver.enterprise.example.com

        If your installed applications use different DB servers, enter the DB host for each application.

      4. Enter the Port number of the DB server. The default values are: 50000 for DB2, 1521 for Oracle, and 1433 for SQL Server.

        If your installed applications use different DB servers or instances, enter the port for each DB server or instance.

      5. Enter the JDBC driver location. For example:

        • AIX: /usr/IBM/WebSphere/AppServer/lib
        • Linux:

          /opt/IBM/WebSphere/AppServer/lib

        • Windows:

          C:\IBM\WebSphere\Appserver\lib

      6. Ensure that the following JDBC driver libraries are present in the JDBC directory:

        DB2

        db2jcc.jar and db2jcc_license_cu.jar

        Ensure that your user account has the necessary permissions to access the DB2 JDBC files.

        Oracle

        ojdbc6.jar

        SQL Server

        Download the SQL Server JDBC 2 driver from the Microsoft website to a local directory and enter that directory name in the JDBC driver library field.

        The directory must not contain the sqljdbc.jar file, only the sqljdbc4.jar file. Even though the data source is configured to use the sqljdbc4.jar file, an exception occurs if both files are present in the same directory.

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

      7. Enter the User ID and Password for each DB. If each DB uses the same user credentials, confirm the Use the same password for all applications question and then enter the UID and password for the first DB in the list.

        If your DB type is Oracle, connect to the DB with the UID that you used when you created the application DB.

      8. If you need to make changes, type the number that corresponds to the application to change. Alternatively, type R to reset all the DB specifications to their default values.

      9. Press Enter to verify your DB settings. If the validation fails, check your DB settings. When the validation succeeds, click Next.

        IBM Installation Manager tests your DB connection with the DB values that you supplied. You can change the DB configuration later in the WAS Integrated Solutions Console.

      10. If the verification check is successful, type N to proceed. If verification fails, press B to re-enter the required information.

    15. Specify your Cognos configuration.

      The IBM Cognos configuration panel appears only if you chose to install the Metrics application earlier in this task.

      If you do not want to configure Cognos now, enter dummy values for UID and password, and select any values from the list of nodes and servers. Then press Enter and ignore the validation error message that appears. To continue installing IBM Connections, type N. For information about configuring Cognos after installation, see the Installing Cognos Business Intelligence topic. For information about resolving Cognos validation problems, see the Troubleshooting Cognos validation problems topic.

      1. Enter the LDAP UID for the Cognos administrator.

      2. Enter the password for the Cognos administrator.

      3. Select the node where the Cognos BI Server is installed.

      4. Enter the port of the Cognos server.

      5. Enter the web context root.

      6. Press Enter to validate the configuration.

      7. Type N to proceed.

    16. Set the locations of the content stores. Shared content must be read/write accessible by all nodes in a cluster. Both shared and local content stores must be accessible using the same path from all nodes and the DM. Local content is node-specific. Each content store is represented by a corresponding WebSphere variable that is further defined as shared or local.

      If you are migrating from IBM Connections 3.0.1, you can reuse your existing content stores in 4.0. For more information, see the Content store migration topic.

      1. Enter the location of the Shared content store. The shared content store usually resides in a shared repository that grants read-write access to the DM and all the nodes. Use one of the following methods to create a shared data directory:

        • Network-based file shares (for example: NFS, SMB/Samba, and so on)

        • Storage area network drives (SAN)

        • If you are using a shared-file system on Microsoft Windows, specify the file location using the Universal Naming Convention (UNC) format. For example: \\server_name\share_name.
          (Windows only) If you use Remote Desktop Connection to map shared folder drives, ensure that you use the same session to start the node agents. Otherwise, the shared drives might be invisible to the nodes.

      2. Enter the location of the Local content store.

      3. Press Enter to verify that the account that you are using to install IBM Connections has write access to the content store.

      4. Click Next.

    17. Select a Notification solution. Notifications are email messages to users about new information and events in your IBM Connections deployment.

      • Enable Notification only.

        Use notifications but without the ReplyTo capability.

      • Enable Notification and ReplyTo.

        Use notifications and the ReplyTo capability. To use ReplyTo, your mail server must be able to receive all the replies and funnel these replies into a single inbox. IBM Connection connects to the mail server using the IMAP protocol.

      • None.

        Do not use a notification solution in your IBM Connections deployment. You can configure notifications after installation.

    18. If you chose a mail notification option, select and specify a mail server solution.

      • WebSphere Java Mail Session: Use a single mail server for all notifications. Select this option if you can access an SMTP server directly using the host.

        Identify the mail server to use for sending email:

        Host name of SMTP messaging server

        Enter the host or IP address of the preferred SMTP mail server.

        This SMTP server requires authentication

        Enter Y to force authentication when mail is sent from this server.

        User ID

        If the SMTP server requires authentication, enter the UID.

        Password

        If the SMTP server requires authentication, enter the user password.

        Encrypt outgoing mail traffic to the SMTP messaging server using SSL

        If you want to encrypt outgoing mail to the SMTP server, press Y.

        Port

        Press Enter to accept the default port of 25, or enter 465 if you are using SSL.

      • DNS MX Records: Use information from DNS to determine which mail servers to use. Select this option if you use a Domain Name System (DNS) server to access the SMTP messaging server.

        Messaging domain name

        Enter the name or IP address of the messaging domain.

        Choose a specific DNS server

        To specify a unique SMTP server, press Y.

        DNS server for the messaging servers query

        Enter the host or IP address of the DNS server.

        DNS port used for the messaging servers query

        Enter the port that is used for sending queries using the messaging server.

        This SMTP server requires authentication

        Enter Y to force authentication when mail is sent from this server.

        User ID

        If SMTP authentication is required, enter the administrator user ID for the SMTP server.

        Password

        If SMTP authentication is required, enter the password for the administrator user of the SMTP server.

        Encrypt outgoing mail traffic to the SMTP messaging server using SSL

        If you want to encrypt outgoing mail to the SMTP server, press Y.

        Port

        Press Enter to accept the default port of 25, or enter 465 if you are using SSL.

      • If you specify Do not enable Notification, IBM Installation Manager skips the rest of this step. You can configure notification later.

    19. If you selected the Notification and ReplyTo option, configure the ReplyTo email settings. IBM Connections uses a unique ReplyTo address to identify both the person who replied to a notification and the event or item that triggered the notification.

      1. Enter a domain name. For example: mail.example.com.

        This domain name is used to build the ReplyTo address. The address consists of the suffix or prefix, a unique key, and the domain name.

      2. The reply email address is given a unique ID by the system. You can customize the address by adding a prefix or suffix, using a maximum of 28 characters. This extra information is useful if the domain name is already in use for other purposes. Select one of the following options:

        None

        Use the ID generated by the system.

        Prefix

        Enter a prefix in the Example field.

        Suffix

        Enter a suffix in the Example field.

        As you select an option, the wizard creates an example of the address, combining your selection with the ID generated by the system.

        For example:

        • unique_id@domain

        • prefix_unique_id@domain

        • unique_id_suffix@domain -

      3. Specify the details of the mail file to which ReplyTo emails are sent:

        Server

        The domain where your mail server is located. For example: replyTo.mail.example.com.

        User ID

        The user account for the mail server. The UID and password are credentials that IBM Connections will use to poll the inbox on the mail server to retrieve the replies and process the content. IBM Connections connects to the mail server using IMAP.

        Password

        Password for the user account. The UID and password are credentials that IBM Connections will use to poll the inbox on the mail server to retrieve the replies and process the content. IBM Connections connects to the mail server using IMAP.

      4. Click Next.

      You can modify the ReplyTo settings after installation. To edit the domain name and prefix or suffix, edit the news-config.xml file. For more information, see the Post-migration step for status updates topic. To edit the server and authentication details, log in to the WAS Integrated Solutions Console and navigate to the Mail Sessions page, where you can edit the configuration.

    20. Review the information that you entered. To revise your selections, press B. To continue installing, press N.

    21. To install the product, press I. To generate a response file, press G.

    22. Review the result of the installation. Press F to exit the installation wizard.

    23. Restart the Deployment Manager:

      • AIX or Linux: Open a command prompt and change to the profile_root/Dmgr01/bin directory. Enter the ./stopManager.sh command and then enter the ./startManager.sh command.

      • Windows: Stop and restart the Deployment Manager service.

    24. Start all the federated nodes and enter the startNode command. Repeat these steps for each node:

      1. Log in to a node.

      2. From a command line, change to the profile_root/bin directory.

      3. Enter the startNode command for your operating system:

        • AIX or Linux: ./startNode.sh

        • Windows: startNode.bat

    25. Log in to the Integrated Solutions Console on the DM to perform a full synchronization of all nodes.

      1. Go to System administration > Nodes.

      2. Select the nodes and click Full Resynchronize.

      Wait until the DM copies all the application EAR files to the installedApps directory on each of the nodes. This process can take up to 30 minutes.

      To verify that the DM has distributed the application EAR files to the nodes, check the SystemOut.log file of each node agent. The default path to the SystemOut.log file on a node is profile_root/logs/nodeagent.

      Look for a message such as the following example: ADMA7021I: Distribution of application application_name completed successfully. where application_name is the name of an IBM Connections application.

    26. Restart the Deployment Manager.

    27. Start all your IBM Connections clusters:

      1. Log in to the Integrated Solutions Console on the DM

      2. Go to Servers > Clusters > WebSphere Application server clusters.

      3. Select the IBM Connections clusters and click Start.

      If you installed a cluster with multiple Search nodes, create the initial index. For more information about creating the Search index, see the Creating the initial Search index topic.

      1. If you are installing a non-English language deployment, enable Search dictionaries. For more information, see the Enabling Search dictionaries topic.

      2. The index is ready when the INDEX.READY and CRAWLING_VERSION files are present in the index directory.

      If some applications do not start, the file-copying process might not have completed. Wait a few minutes and start the applications.


    Results

    The installation wizard has installed IBM Connections in a network deployment.

    To confirm that the installation was successful, open the log files in connections_root/logs. Each IBM Connections application installed has a log file, using the following naming format: application_nameInstall.log, where application_name is the name of an IBM Connections application. Search for the words error or exception to check whether any errors or exceptions occurred during installation.

    To view the log file for system events that occurred during the installation, open the date_time.xml file, where date_time represents the date and time of the installation. The file is located by default in the following directory:

    • AIX or Linux (root user): /var/ibm/InstallationManager/logs

    • AIX or Linux (non-root user): /home/user/var/ibm/Installation Manager/logs where user is the non-root user name

    • Windows Server 2008 64-bit: C:\ProgramData\IBM\Installation Manager\logs


    What to do next

    Complete the post-installation tasks that are relevant to your installation. For more information, see the Post-installation tasks topic.

    Access network shares:

    If you installed WAS on Microsoft Windows and configured it to run as a service, ensure that you can access network shares. For more information, see the Accessing Windows network shares topic.


    Install silently

    Silent installation is a tool for installing the same IBM Connections profile on multiple computers without using the IBM Installation Manager. This simplifies the installation process in enterprises that need multiple, identical instances of IBM Connections.

    Silent installation uses installation parameters in a response file to install identical IBM Connections profiles on different computers. To specify silent installation parameters you can edit the default response file provided with IBM Connections, or create a new file.

    In addition to silently installing IBM Connections, you can use the silent installation process to modify, update, or uninstall IBM Connections.


    Install IBM Connections in silent mode (with an existing IBM Installation Manager)

    Use a silent installation to perform an identical installation of IBM Connections on multiple systems.

    Ensure that you complete all the prerequisite tasks that are relevant for your environment. For more information, see the Before installing topic.

    Ensure that IBM Installation Manager is installed on your system. To prevent errors caused by using the wrong version of IBM Installation Manager, remove the following line from the default response file:

    <offering id='com.ibm.cic.agent' version='1.4.4000.20110525_1254' profile='IBM Installation Manager' features='agent_core,agent_jre' installFixes='none'/>

    To create a customized version of the default response file, run the installation wizard in interactive mode. For more information, see the Creating a response file topic.

    Use a response file for your intended deployment, install IBM Connections on multiple systems without needing to interact with the installation wizard.

    To perform a silent installation:

    1. cd IM_root/eclipse/tools

    2. Enter the following command:

      • AIX or Linux: ./imcl -input response_file -log log_file -acceptLicense

      • Windows: imcl.exe -input response_file -log log_file -acceptLicense

        The IM_root/eclipse directory contains a similar file called IBMIM.exe but that file is not suitable for silent installation.

      where response_file is the full path and name of the response file and log_file is the full path and name of the log file. The default name of the response file is LC.rsp. By default, the response file is in the following directory:

      • AIX or Linux: connections_root.

      • Microsoft Windows:: connections_root.

      Examples:

      • AIX or Linux: ./imcl -input /opt/IBM_Connections_Install/IBMConnections/LC.rsp -log /mylog/silent_install_log.xml -acceptLicense

      • Windows: imcl.exe -input E:\IBM_Connections_Install\IBMConnections\LC.rsp -log \mylog\silent_install_log.xml -acceptLicense


    Results

    IBM Installation Manager writes the result of the installation command to the log file specified with the -log parameter.

    To check the complete details of the installation, open each of the log files in connections_root/logs. Each IBM Connections application installed has a log file, using the following naming format: applicationInstallog.txt, where application is the name of an IBM Connections application.

    If the installation is successful, the log files are empty. For example:

    <?xml version="1.0" encoding="UTF-8"?>
    <result>
    </result>
    The log file contains an error element if the operation was not completed successfully. A successful installation adds a value of 0 to the log file. An unsuccessful installation adds a positive integer to the log file.
    The log file for IBM Installation Manager records the values that you entered when you ran IBM Installation Manager in interactive mode. To review the log file for IBM Installation Manager, open the date_time.xml file, where date_time represents the date and time of the installation. The file by default is in the following directory:

    • AIX or Linux (root user): /var/ibm/InstallationManager/logs

    • AIX or Linux (non-root user): user_home/var/ibm/InstallationManager/logs

    • Windows (administrator): C:\ProgramData\IBM\Installation Manager\logs

    • Windows (non-administrator): C:\user\Application Data\IBM\Installation Manager\logs


    What to do next

    Complete any applicable post-installation tasks. For more information, see the Post-installation tasks topic.


    Install IBM Connections and IBM Installation Manager in silent mode

    Use a silent installation to perform an identical installation of IBM Connections and IBM Installation Manager on multiple systems.

    This task assumes that IBM Installation Manager is not installed on your system.

    Ensure that you complete all the prerequisite tasks that are relevant for your environment. For more information, see the Before installing topic.

    However, do not complete the prerequisite tasks that relate to IBM Installation Manager.

    Edit the default response file to suit your environment. For more information, see the Using the default response file topic.

    Use a response file for your intended deployment, install IBM Connections on multiple systems without needing to interact with the installation wizard.

    To perform a silent installation:

    1. Open a command prompt and go to the location of the silent installation file. The file is stored in the IBM_Connections_set-up/IBM_Connections_install/IM/OS directory,

      ...where IBM_Connections_set-up is the directory or media where the IBM Connections installation files are located and OS represents your operating system

      To change the paths to the response file and log file, edit the lc_install.ini file. The file is located in the IBM_Connections_set-up/IBM_Connections_install/IM/OS directory.

    2. Run the silent installation script:

      • AIX or Linux (root user): ./installc -input response_file -log log_file -acceptLicense

      • AIX or Linux (non-root user): ./userinstc -input response_file -log log_file -acceptLicense

      • Windows (administrator): installc.exe -input response_file -log log_file -acceptLicense

      • Windows (non-administrator): userinstc.exe -input response_file -log log_file -acceptLicense

      where response_file is the full path and name of the response file and log_file is the full path and name of the log file. The default name of the file is LC.rsp.

      By default, the response file is stored in the IBM_Connections_set-up/IBM_Connections_install/IBMConnecgtions directory on the installation media.


    Results

    IBM Installation Manager writes the result of the installation command to the log file specified with the -log parameter.

    To check the complete details of the installation, open each of the log files in connections_root/logs. Each IBM Connections application installed has a log file, using the following naming format: applicationInstallog.txt, where application is the name of an IBM Connections application.

    If the installation is successful, the log files are empty. For example:

    <?xml version="1.0" encoding="UTF-8"?>
    <result>
    </result>
    The log file contains an error element if the operation was not completed successfully. A successful installation adds a value of 0 to the log file. An unsuccessful installation adds a positive integer to the log file.

    The log file for IBM Installation Manager records the values that you entered when you ran IBM Installation Manager in interactive mode. To review the log file for IBM Installation Manager, open the date_time.xml file, where date_time represents the date and time of the installation. The file by default is in the following directory:

    • AIX or Linux (root user): /var/ibm/InstallationManager/logs

    • AIX or Linux (non-root user): user_home/var/ibm/InstallationManager/logs

    • Windows (administrator): C:\ProgramData\IBM\Installation Manager\logs

    • Windows (non-administrator): C:\user\Application Data\IBM\Installation Manager\logs


    What to do next

    Complete any applicable post-installation tasks. For more information, see the Post-installation tasks topic.


    The default response file

    Response files provide input parameters for silent installations of IBM Connections.

    The default response file for AIX and Linux is called LC.rsp and is located in the IBM Connections set-up directory or installation media. You can edit this file and use it as input for a silent installation.

    IBM does not provide a default response file on Windows because it is more convenient if you to generate the file yourself. For information about generating a response file, see the Creating a response file topic.

    Instead of generating a new response file, you can edit the default response file that is provided with the product. However, if you edit the default response file, you need to add encrypted passwords to the file. For more information, see the Creating encrypted passwords for a response file topic.


    Use the default response file

    Use the default response file to specify silent installation parameters for your environment.

    Encrypt your administrator passwords. For more information about encrypting passwords, see the Creating encrypted passwords for a response file topic.

    Silent installation uses the parameters in a response file to install the same IBM Connections profile on multiple computers.

    If you are silently installing IBM Connections as a non-root user in an AIX or Linux environment, you must specify that parameter in the silent-install.ini file.

    1. Navigate to the connections_root directory and open the LC.rsp response file.

    2. Specify your installation parameters. For more information, see the Default response file topic.

    3. Add the encrypted passwords to the relevant elements of the response file. The following example shows the elements for the Activities passwords:

      <data key='user.activities.adminuser.password' value='encrypted_password'/>

      <data key='user.activities.dbUserPassword value='encrypted_password'/>

      where encrypted_password is the password after you encrypted it.

    4. Change the default WAS administrator name from wasadmin if your administrator name is different.

    5. Save your changes.

    6. If you are performing the silent installation as a non-root user on AIX or Linux systems:

      1. Open the silent-install.ini file for editing from the following location:

        • AIX: IBM_Connections_set-up/IBM_Connections_install/IM/aix/silent-install.ini

        • Linux: IBM_Connections_set-up/IBM_Connections_install/IM/linux/silent-install.ini

        • Linux on System z: IBM_Connections_set-up/IBM_Connections_install_s390/IM/zlinux/silent-install.ini

        where IBM_Connections_set-up is the IBM Connections set-up directory or installation media.

      2. In the second line of the file, change admin to nonadmin.

      3. Save and close the file.


    Create a response file

    Use a response file to install, modify, update, or uninstall IBM Connections without user interaction.

    You can create a response file by using IBM Installation Manager or by editing the file that is provided with the product. For more information about editing the file, see the Default response file topic.

    Ensure that IBM Installation Manager is installed. For more information, see the Installing IBM Connections 4.0 topic.

    To ensure that the response file captures the details of your SSL certificates, start IBM WAS.

    The default location of a response file that you generate is the connections_root/silentResponseFile directory. To specify a different location, edit the generate_install_responsefile.bat|sh file or generate_other_responsefile.bat|sh file, depending on the task to carry out.

    Instead of creating your own response file, you can edit the file that is provided with the product. The file is in the IBM_Connections_set-up/IBM_Connections_install/IBMConnections directory. However, this default file is applicable only for installation. The response files for modifying, updating, rolling back, and uninstalling the product are based on the response file for installation. Before you create a response file for any of those procedures, you must first run the silent installation procedure.

    For more information about creating response files with IBM Installation Manager, go to the Recording a response file with Installation Manager webpage.

    This task describes the procedure to generate a response file for the following procedures:

    • Install IBM Connections

    • Modify an existing installation by adding or removing IBM Connections applications

    • Update an existing installation by installing a fix pack

    • Roll back an update

    • Uninstall IBM Connections

    For each procedure, run a simulated instance of the IBM Installation Manager and record your input to a response file. Later, you can run a silent command that uses this response file as an input parameter.

    Default response files on AIX or Linux:

    Install

    LC.rsp

    Modify - Add

    LC_modify_add.rsp

    Modify - Remove

    LC_modify_remove.rsp

    Update

    LC_update.rsp

    Roll back

    LC_rollback.rsp

    Uninstall

    LC_uninstall.rsp

    To create a response file, complete the following steps:

    1. Open a command prompt and go to the IM_root/eclipse directory.

    2. Ensure that the IBM_Connections_set-up/IBM_Connections_install/IM/OS/skip directory allows write access, where IBM_Connections_set-up is the directory or media where the IBM Connections installation files are located, and OS represents your operating system.

    3. Run the command to record a response file. This command uses the -skipInstall agentDataLocation argument, which records the installation commands without installing IBM Connections. Substitute your own file name and path for the response file. Verify the file paths that you enter exist because IBM Installation Manager does not create directories for the response file.

      • AIX and Linux: ./IBMIM -record /response_files/install_product.xml -skipInstall agentDataLocation

      • Microsoft Windows:: IBMIM.exe -record responseFile -skipInstall agentDataLocation

      where agentDataLocation is the file path to the skip directory, which stores IBM Installation Manager data files.

      • The -log option is not available when recording a response file.

      • Use quotation marks around file paths that contain spaces.

      • You can use the same agentDataLocation parameter in the next recording session to update, modify, roll back or uninstall IBM Connections. However, if you want to record a new installation, you must specify a new agentDataLocation parameter.

    4. Enter the required information in the IBM Installation Manager.

      • To install a new deployment, open Files > Preferences, and enter the path to the IBM Connections repository; for example: C:\build\\IBM_Connections_Install\IBMConnections. Click Install and enter the required information as if you were installing the product. For more information, see the Installing IBM Connections 4.0 topic.

      • To modify an existing installation, click Modify and enter the required information.

        • To add applications, select the applications to add in the Application Selection pane.

          Ensure that all the currently installed applications are also selected.

        • To remove applications, clear the check boxes of the applications to remove in the Application Selection pane.

        For more information, see the Modifying the installation in interactive mode topic.

      • To update an existing installation, click Update and enter the required information.

      • To roll back an update, click Rollback and enter the required information

      • To uninstall IBM Connections, click Uninstall and enter the required information. For more information, see the Uninstalling a deployment topic.

    5. Confirm that the new response file is present.


    What to do next

    Use the response file to silently install, modify, update, roll back, or uninstall IBM Connections.

    If you are running IBM Installation Manager as a non-administrator and plan to use the response file to install the product on another user's system, change the file paths in your response file from absolute paths to relative paths.


    Create encrypted passwords for a response file

    Add encrypted passwords to your edited version of the default response file.

    You can create a response file using IBM Installation Manager or by editing the file that is provided with the product. For more information about editing the file, see the Default response file topic.

    When you edit the default response file to suit your own environment, create encrypted passwords and add them to the file. Create encrypted passwords for both WebSphere Application Sever and your DBs.

    To create encrypted passwords for a response file, complete the following steps:

    1. Open a command prompt and change to the IBM_Connections_setup/IBM_Connections_Install/IM/OS/tools where OS is your operating system.

    2. Run the following command:

      • AIX or Linux: ./imutilsc encryptString Password -silent -noSplash

      • Windows: imutilsc.exe encryptString Password -silent -noSplash

        where Password is your password.

    3. Add the encrypted password to the relevant line in the response file. You usually need to enter passwords for both the WAS administrator and the DB user. For example:

      <data key='user.activities.adminuser.password' value='encrypted_password'/>

      <data key='user.activities.dbUserPassword value='encrypted_password'/>

      where encrypted_password is the value generated by the command.

      You might also need to change the default WAS administrator name from wasadmin, if different from your administrator name.

    4. Repeat these steps for each unique password.


    What to do next

    Use the response file to silently install, modify, update, roll back, or uninstall IBM Connections.


    Directory paths for IBM Installation Manager

    IBM Installation Manager uses default directory paths for its installation files.


    Purpose

    This topic describes the default directory paths for IBM Installation Manager.


    IBM Installation Manager

    Each instance of Installation Manager must have its own installation directory and agent data directory.

    The directories where IBM Installation Manager is installed are determined by the type of user account that you used to install the product.

    Any changes that you make to an installation of IBM Installation Manager installed with a root user or non-administrator account do not affect an installation of IBM Installation Manager installed with a non-root user or non-administrator account. The reverse is also true.

    The following table indicates the location of the relevant directories.

    Default installation directories for IBM Installation Manager

    Directory Root/Administrator Non-root/non-administrator
    Default installation directory

    AIX or Linux: /opt/IBM/InstallationManager/eclipse
    Windows: C:\IBM\Installation Manager\eclipse

    AIX or Linux: /<user/IBM/InstallationManager/eclipse

    Windows XP Professional, Windows Server 2003: C:\<user>\IBM\Installation Manager\eclipse

    Windows Vista, Windows Server 2008, Windows 7: C:\Users\<user>\IBM\Installation Manager\eclipse

    Eclipse log file

    AIX or Linux: /var/ibm/InstallationManager/pluginState/.metadata

    Windows Server 2008: C:\ProgramData\IBM\Installation Manager\pluginState\.metadata

    AIX or Linux: /<user/var/ibm/InstallationManager/pluginState/.metadata

    Windows Server 2008: C:\Users\<user\IBM\Installation ManagerInstaller\pluginState\.metadata

    Default agent data location.

    For more information about agent data, go to the Agent data location page in the IBM Installation Manager information center.

    AIX or Linux: /var/ibm/InstallationManager

    Windows Server 2008: C:\ProgramData\IBM\Installation Manager

    AIX or Linux: /<user>/var/ibm/InstallationManager

    Windows Server 2008: C:\Users\<user>\AppData\Roaming\IBM\Installation Manager

    To find the location of IBM Installation Manager:

    • AIX or Linux:

      1. Open the /etc/.ibm/registry/InstallationManager.dat file.

      2. Examine the location entry.

        For example, location=/var/ibm/InstallationManager.

    • Windows:

      1. Open the Windows Registry.

      2. Search for the following registry key: HKLM\SOFTWARE\Wow6432Node\IBM\Installation Manager\location.

      3. Open the key and examine its value.


    Modify the installation in interactive mode

    Modify your deployment of IBM Connections by adding or removing applications. Use the Modify function of the IBM Installation Manager to add or remove IBM Connections applications.

    To modify your installation:

    1. Open a command prompt and change to the IM_root directory.

    2. Run the following command:

      • AIX or Linux: ./launcher

      • Windows: launcher.exe

    3. From the IBM Installation Manager menu, click File > Preferences.

    4. Click Repositories.

    5. In the Repositories area, select the repositories that you want to modify.

    6. Click OK to save your selections.

    7. Click Modify.

    8. Select IBM Connections and click Next.

    9. In the Application Selection page, choose the applications you want to add or remove and then click Next.

      • Add applications: Select the check boxes of any applications that are not already installed and to add to your deployment.

      • Remove applications: Clear the check boxes of any installed applications to remove from your deployment.

      All installed applications are selected by default.

      The Home page, News, and Search applications are required and cannot be removed.

    10. Enter the administrative ID and password of the Deployment Manager.

      This ID is set to the connectionsAdmin J2C authentication alias, which is mapped to the following J2EE roles: dsx-admin, widget-admin, and search-admin. It is also used by the service integration bus. To use security management software such as Tivoli Access Manager or SiteMinder, the ID that you specify here must exist in the LDAP directory. For more information, see the Switching to unique administrator IDs for system level communication topic.

    11. Configure your topology:

      The panel described in this step appears only if you selected new applications to install.

      If you select an existing cluster on which to deploy applications, the nodes in that cluster are fixed and cannot be modified.

      • Small deployment:

        1. Select the Small deployment topology.

        2. Enter a Cluster name for the topology.

        3. Select a Node.

        4. Click Next.

      • Medium deployment:

        1. Select the Medium deployment topology.

        2. Select the default value or enter a Cluster name for each application or for groups of applications.

          For example, use Cluster1 for Activities, Communities, and Forums.

          IBM Installation Manager creates servers and clusters when required.

        3. Select a Node for each cluster. Accept the predefined node or select a different node.
          These nodes host application server instances that serve IBM Connections applications. You can assign multiple nodes to a cluster, where each node is a server member of that cluster.

        4. Enter a Server member name for the selected node. Choose the default or enter a custom name.

          If you enter a custom server member name, the name must be unique across all nodes in your deployment.

        5. Click Next.

      • Large deployment:

        1. Select the Large deployment topology.

        2. Enter a Cluster name for each application.

          IBM Installation Manager creates servers and clusters when required.

        3. Select a Node for each cluster. Accept the predefined node or select a different node.
          These nodes host application server instances that serve IBM Connections applications. You can assign multiple nodes to a cluster, where each node is a server member of that cluster.

        4. Enter a Server member name for the selected node. Choose the default or enter a custom name.

          If you enter a custom server member name, the name must be unique across all nodes in your deployment.

        5. Click Next.

    12. Enter the DB information.

      The panel described in this step appears only if you selected new applications to install and if the new applications require DB configuration.

      1. Specify whether the installed applications use the same DB server or instance: Select Yes or No.

        If allowed by your DB configuration, you can select multiple DB instances as well as different DB servers.

      2. Select a Database type from one of the following options:

        • IBM DB2 Universal Database
        • Oracle Enterprise Edition
        • Microsoft SQL Server Enterprise Edition

      3. Enter the Database server host. For example: appserver.enterprise.example.com

        If your installed applications use different DB servers, enter the DB host for each application.

      4. Enter the Port number of the DB server. The default values are: 50000 for DB2, 1521 for Oracle, and 1433 for SQL Server.

        If your installed applications use different DB servers or instances, enter the port for each DB server or instance.

      5. Enter the JDBC driver location. For example:

        • AIX: /usr/IBM/WebSphere/AppServer/lib
        • Linux:

          /opt/IBM/WebSphere/AppServer/lib

        • Windows:

          C:\IBM\WebSphere\Appserver\lib

      6. Ensure that the following JDBC driver libraries are present in the JDBC directory:

        DB2

        db2jcc.jar and db2jcc_license_cu.jar

        Ensure that your user account has the necessary permissions to access the DB2 JDBC files.

        Oracle

        ojdbc6.jar

        SQL Server

        Download the SQL Server JDBC 2 driver from the Microsoft website to a local directory and enter that directory name in the JDBC driver library field.

        The directory must not contain the sqljdbc.jar file, only the sqljdbc4.jar file. Even though the data source is configured to use the sqljdbc4.jar file, an exception occurs if both files are present in the same directory.

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

      7. Enter the User ID and Password for each DB. If each DB uses the same user credentials, select the Use the same password for all applications check box and then enter the UID and password for the first DB in the list.

        If your DB type is Oracle, connect to the DB with the UID that you used when you created the application DB.

      8. Click Validate to verify your DB settings. If the validation fails, check your DB settings. When the validation succeeds, click Next.

        IBM Installation Manager tests your DB connection with the DB values that you supplied. You can change the DB configuration later in the WAS Integrated Solutions Console.

    13. In the summary panel, confirm your selection and click Modify.

    14. When the modification process is complete, restart the Deployment Manager and all the nodes.

      Wait until the DM copies all the application EAR files to the installedApps directory on each of the nodes. This process can take up to 30 minutes.

      To verify that the DM has distributed the application EAR files to the nodes, check the SystemOut.log file of each node agent. The default path to the SystemOut.log file on a node is profile_root/logs/nodeagent.

      Look for a message such as the following example: ADMA7021I: Distribution of application application_name completed successfully. where application_name is the name of an IBM Connections application.

      To confirm that the installation was successful, open the log files in connections_root/logs. Each IBM Connections application installed has a log file, using the following naming format: application_nameInstall.log, where application_name is the name of an IBM Connections application. Search for the words error or exception to check whether any errors or exceptions occurred during installation.


    Modify the installation in silent mode

    Modify your deployment of IBM Connections by adding or removing applications in silent mode. With the help of a response file, use the Modify function of the IBM Installation Manager to add or remove IBM Connections applications.

    To modify your installation in silent mode, complete one of the following tasks:


    Add applications in silent mode

    Add applications to your deployment of IBM Connections without using the installation wizard.

    Create a response file for this task by running a simulated modification. For more information, see the Creating a response file topic.

    Instead of generating a new response file, you can edit the default response file that is provided with the product. However, if you edit the default response file, you need to add encrypted passwords to the file. For more information, see the Creating encrypted passwords for a response file topic.

    A silent modification uses a response file to automate the addition of applications to your deployment.

    To perform a silent modification:

    1. cd IM_root/eclipse/tools

    2. Enter the following command:

      • AIX or Linux: ./imcl -input response_file -log log_file -acceptLicense

      • Windows: imcl.exe -input response_file -log log_file -acceptLicense

        The IM_root/eclipse directory contains a similar file called IBMIM.exe but that file is not suitable for silent installation.

      where response_file is the full path and name of the response file and log_file is the full path and name of the log file. The default name of the response file is LC.rsp. By default, the response file is in the following directory:

      • AIX or Linux: connections_root.

      • Microsoft Windows:: connections_root.

      Examples:

      • AIX or Linux: ./imcl -input /opt/IBM_Connections_Install/IBMConnections/LC.rsp -log /mylog/silent_install_log.xml -acceptLicense

      • Windows: imcl.exe -input E:\IBM_Connections_Install\IBMConnections\LC.rsp -log \mylog\silent_install_log.xml -acceptLicense


    Results

    IBM Installation Manager writes the result of the installation command to the log file specified with the -log parameter.

    To check the complete details of the installation, open each of the log files in connections_root/logs. Each IBM Connections application installed has a log file, using the following naming format: applicationInstallog.txt, where application is the name of an IBM Connections application.

    If the installation is successful, the log files are empty. For example:

    <?xml version="1.0" encoding="UTF-8"?>
    <result>
    </result>
    The log file contains an error element if the operation was not completed successfully. A successful installation adds a value of 0 to the log file. An unsuccessful installation adds a positive integer to the log file.

    The log file for IBM Installation Manager records the values that you entered when you ran IBM Installation Manager in interactive mode. To review the log file for IBM Installation Manager, open the date_time.xml file, where date_time represents the date and time of the installation. The file by default is in the following directory:

    • AIX or Linux (root user): /var/ibm/InstallationManager/logs

    • AIX or Linux (non-root user): user_home/var/ibm/InstallationManager/logs

    • Windows (administrator): C:\ProgramData\IBM\Installation Manager\logs

    • Windows (non-administrator): C:\user\Application Data\IBM\Installation Manager\logs


    Remove applications in silent mode

    Silently remove applications from your deployment of IBM Connections.

    Create a response file for this task by running a simulated modification. For more information, see the Creating a response file topic.

    Instead of generating a new response file, you can edit the default response file that is provided with the product. However, if you edit the default response file, you need to add encrypted passwords to the file. For more information, see the Creating encrypted passwords for a response file topic.

    A silent modification uses a response file to automate the removal of applications from your deployment.

    To perform a silent modification:

    1. cd IM_root/eclipse/tools

    2. Enter the following command:

      • AIX or Linux: ./imcl -input response_file -log log_file -acceptLicense

      • Windows: imcl.exe -input response_file -log log_file -acceptLicense

        The IM_root/eclipse directory contains a similar file called IBMIM.exe but that file is not suitable for silent installation.

      where response_file is the full path and name of the response file and log_file is the full path and name of the log file. The default name of the response file is LC.rsp. By default, the response file is in the following directory:

      • AIX or Linux: connections_root.

      • Microsoft Windows:: connections_root.

      Examples:

      • AIX or Linux: ./imcl -input /opt/IBM_Connections_Install/IBMConnections/LC.rsp -log /mylog/silent_install_log.xml -acceptLicense

      • Windows: imcl.exe -input E:\IBM_Connections_Install\IBMConnections\LC.rsp -log \mylog\silent_install_log.xml -acceptLicense


    Results

    IBM Installation Manager writes the result of the installation command to the log file specified with the -log parameter.

    To check the complete details of the installation, open each of the log files in connections_root/logs. Each IBM Connections application installed has a log file, using the following naming format: applicationInstallog.txt, where application is the name of an IBM Connections application.

    If the installation is successful, the log files are empty. For example:

    <?xml version="1.0" encoding="UTF-8"?>
    <result>
    </result>
    The log file contains an error element if the operation was not completed successfully. A successful installation adds a value of 0 to the log file. An unsuccessful installation adds a positive integer to the log file.

    The log file for IBM Installation Manager records the values that you entered when you ran IBM Installation Manager in interactive mode. To review the log file for IBM Installation Manager, open the date_time.xml file, where date_time represents the date and time of the installation. The file by default is in the following directory:

    • AIX or Linux (root user): /var/ibm/InstallationManager/logs

    • AIX or Linux (non-root user): user_home/var/ibm/InstallationManager/logs

    • Windows (administrator): C:\ProgramData\IBM\Installation Manager\logs

    • Windows (non-administrator): C:\user\Application Data\IBM\Installation Manager\logs


    Modify the installation in console mode

    Use console mode, modify your deployment of IBM Connections by adding or removing applications. Use IBM Installation Manager in console mode to add or remove IBM Connections applications. This method is convenient if you cannot or do not want to use the interactive mode.

    To modify your installation:

    1. On each node, stop any running instances of WAS and WebSphere node agents.

    2. Start WAS Network Deployment Manager.

    3. Open a command prompt and change to the IM_root/tools

    4. Start IBM Installation Manager in console mode:

      • AIX or Linux: ./imcl -c

      • Windows: imcl.exe -c

    5. Type 1 to begin modifying the deployment.

    6. In the Select packages to install step, type 1 to select the package and then type N to proceed.

    7. Select the applications to add or remove and then type N.

      • Add applications: Set the numbers corresponding to applications that are not already installed and to add to your deployment.

      • Remove applications: Set the numbers corresponding to installed applications to remove from your deployment. The Home page, News, and Search applications are required and can't be removed.

      All installed applications are selected by default.

    8. Enter the administrative ID and password of the Deployment Manager.

      This ID is set to the connectionsAdmin J2C authentication alias, which is mapped to the following J2EE roles: dsx-admin, widget-admin, and search-admin. It is also used by the service integration bus. To use security management software such as Tivoli Access Manager or SiteMinder, the ID that you specify here must exist in the LDAP directory. For more information, see the Switching to unique administrator IDs for system level communication topic.

    9. Configure your topology. For more information about each option, see the Deployment options topic.

      • Small deployment:

        1. Type 1 to select the Small deployment topology.

        2. Enter a Cluster name for the topology.

        3. Select a Node.

        4. Enter a Server member name for the node.

        5. Type N to proceed.

      • Medium deployment:

        1. Type 2 to select the Medium deployment topology.

        2. Select the default value or enter a Cluster name for each application or for groups of applications.

          For example, use Cluster1 for Activities, Communities, and Forums.

          IBM Installation Manager creates servers and clusters when required.

        3. Select a Node for each cluster. Accept the predefined node or select a different node.
          These nodes host application server instances that serve IBM Connections applications. You can assign multiple nodes to a cluster, where each node is a server member of that cluster.

        4. Enter a Server member name for the selected node. Choose the default or enter a custom name.

          If you enter a custom server member name, the name must be unique across all nodes in your deployment.

        5. The topology specified is displayed. To re-specify any details, type the number that corresponds to the application; for example, type 1 for Activities.

        6. Type N to proceed.

      • Large deployment:

        1. Type 3 to select the Large deployment topology.

        2. Enter a Cluster name for each application.

          IBM Installation Manager creates servers and clusters when required.

        3. Select a Node for each cluster. Accept the predefined node or select a different node.
          These nodes host application server instances that serve IBM Connections applications. You can assign multiple nodes to a cluster, where each node is a server member of that cluster.

        4. Enter a Server member name for the selected node. Choose the default or enter a custom name.

          If you enter a custom server member name, the name must be unique across all nodes in your deployment.

        5. The topology specified is displayed. To re-specify any details, type the number that corresponds to the application; for example, type 1 for Activities.

        6. Type N to proceed.

    10. Enter the DB information:

      1. Specify whether the installed applications use the same DB server or instance: Type 1 to specify that the applications use same DB server or instance; type 2 to specify that they use different DB servers or instances.

        If allowed by your DB configuration, you can select multiple DB instances as well as different DB servers.

      2. Select a Database type from one of the following options:

        • IBM DB2 Universal Database
        • Oracle Enterprise Edition
        • Microsoft SQL Server Enterprise Edition

      3. Enter the Database server host. For example: appserver.enterprise.example.com

        If your installed applications use different DB servers, enter the DB host for each application.

      4. Enter the Port number of the DB server. The default values are: 50000 for DB2, 1521 for Oracle, and 1433 for SQL Server.

        If your installed applications use different DB servers or instances, enter the port for each DB server or instance.

      5. Enter the JDBC driver location. For example:

        • AIX: /usr/IBM/WebSphere/AppServer/lib

        • Linux:

          /opt/IBM/WebSphere/AppServer/lib

        • Windows:

          C:\IBM\WebSphere\Appserver\lib

      6. Ensure that the following JDBC driver libraries are present in the JDBC directory:

        DB2

        db2jcc.jar and db2jcc_license_cu.jar

        Ensure that your user account has the necessary permissions to access the DB2 JDBC files.

        Oracle

        ojdbc6.jar

        SQL Server

        Download the SQL Server JDBC 2 driver from the Microsoft website to a local directory and enter that directory name in the JDBC driver library field.

        The directory must not contain the sqljdbc.jar file, only the sqljdbc4.jar file. Even though the data source is configured to use the sqljdbc4.jar file, an exception occurs if both files are present in the same directory.

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

      7. Enter the User ID and Password for each DB. If each DB uses the same user credentials, confirm the Use the same password for all applications question and then enter the UID and password for the first DB in the list.

        If your DB type is Oracle, connect to the DB with the UID that you used when you created the application DB.

      8. If you need to make changes, type the number that corresponds to the application to change. Alternatively, type R to reset all the DB specifications to their default values.

      9. Press Enter to verify your DB settings. If the validation fails, check your DB settings. When the validation succeeds, click Next.

        IBM Installation Manager tests your DB connection with the DB values that you supplied. You can change the DB configuration later in the WAS Integrated Solutions Console.

      10. If the verification check is successful, type N to proceed. If verification fails, press B to re-enter the required information.

    11. Review the information that you have entered. To revise your selections, press B. To finish modifying, press M.

    12. Review the result of the installation. Press F to exit the installation wizard.

    13. Restart the Deployment Manager:

      • AIX or Linux: Open a command prompt and change to the profile_root/Dmgr01/bin directory. Enter the ./stopManager.sh command and then enter the ./startManager.sh command.

      • Windows: Stop and restart the Deployment Manager service.

    14. Start all the federated nodes and enter the startNode command. Repeat these steps for each node:

      1. Log in to a node.

      2. From a command line, change to the profile_root/bin directory.

      3. Enter the startNode command for your operating system:

        • AIX or Linux: ./startNode.sh

        • Windows: startNode.bat

    15. Log in to the Integrated Solutions Console on the DM to perform a full synchronization of all nodes.

      1. Go to System administration > Nodes.

      2. Select the nodes and click Full Resynchronize.

      Wait until the DM copies all the application EAR files to the installedApps directory on each of the nodes. This process can take up to 30 minutes.

      To verify that the DM has distributed the application EAR files to the nodes, check the SystemOut.log file of each node agent. The default path to the SystemOut.log file on a node is profile_root/logs/nodeagent.

      Look for a message such as the following example: ADMA7021I: Distribution of application application_name completed successfully. where application_name is the name of an IBM Connections application.

    16. Start all your IBM Connections clusters:

      1. Log in to the Integrated Solutions Console on the DM

      2. Go to Servers > Clusters > WebSphere Application server clusters.

      3. Select the IBM Connections clusters and click Start.

      If you installed a cluster with multiple Search nodes, create the initial index. For more information about creating the Search index, see the Creating the initial Search index topic.

      1. If you are installing a non-English language deployment, enable Search dictionaries.

      2. The index is ready when the INDEX.READY and CRAWLING_VERSION files are present in the index directory.

      If some applications do not start, the file-copying process might not have completed. Wait a few minutes and start the applications.


    Post-installation tasks

    After installation, you need to perform further tasks to ensure an efficient deployment.

    After running the wizards to install applications and create DBs, check which of the following additional tasks you need to complete.


    Tasks to be completed

    After you complete the mandatory post-installation tasks, update the deployment with the latest fixes.

    Mandatory post-installation tasks


    Review the JVM heap size

    Review the size of the Java Virtual Machine heap and adjust it, if necessary, to avoid out-of-memory errors or to suit your hardware capabilities.

    If you selected the Small or Medium deployment option when you installed IBM Connections, IBM Installation Manager set the Maximum Heap Size of the Java Virtual Machine (JVM) on each application server. This setting is designed to avoid out-of-memory errors.

    Review the heap size on each server to ensure that you are allocating enough memory for IBM Connections but also to ensure that you are not allocating more memory than the physical capabilities of the systems where the JVMs are deployed.

    Whether you installed a Small, Medium, or Large deployment of IBM Connections, you should review the JVM heap sizes in your deployment and make adjustments, if necessary.

    To review the JVM heap size:

    1. Log into the WAS Integrated Solutions Console and select Servers > Server Type > WebSphere application servers.

    2. Click server,

      ...where server is the name of an IBM Connections server. You might have several servers in your deployment, so you might need to repeat these steps for each server.

    3. In the Server Infrastructure area, click Java and Process Management and then click Process Definition > Java Virtual Machine.

    4. Review the Maximum heap size. IBM Installation Manager sets the following default values:

      • Small deployment:

        Maximum Heap Size

        2506 MB

      • Medium deployment:

        Maximum Heap Size

        2506 MB

      • Large deployment:

        Each application in a Large deployment, except News and Search, has a default Heap size of 256 MB. The News and Search applications have a default Heap size of 784 MB.

      Ensure that you are not allocating more memory than the physical capacity of the system where the JVM is installed.

    5. Adjust the current values of the heap size up or down to suit the needs of your deployment and your hardware capabilities.

    6. Click OK and then click Save.

    7. Repeat these steps for any additional servers in your deployment.


    Configure IBM HTTP Server

    Configure IBM HTTP Server to manage web requests to IBM Connections.

    When you have successfully installed IBM Connections to run on WAS, you can configure IBM HTTP Server to handle web traffic by completing the following tasks:


    Define IBM HTTP Server

    Define IBM HTTP Server to manage web connections.

    Install web server plug-ins for IBM HTTP Server, if they are not already installed. For more information, go to the Install web server plug-ins web site.

    IBM Connections uses a web server as the entry point for all the applications.

    This procedure describes how to create a web server using the Integrated Solutions Console. There are other ways to create the web server. See the IBM WAS information center for more information.

    To define IBM HTTP Server:

    1. Start the IBM HTTP Administration Server:

      • AIX / Linux

          cd IHS_HOME/bin
          ./adminctl start

      • Windows:

        1. Open the Services window in the Windows Control Panel.

        2. Verify the IBM HTTP Administration Server service is started. If this service is not running, start it

    2. Log in to the WAS Integrated Solutions Console on the Deployment Manager and select...

        System administration > Nodes > Add Node

    3. Select Unmanaged node and click Next.

    4. Set the properties of the node...

      Name

      Enter the name of the node.

      Host Name

      Enter the fully qualified DNS host for IBM HTTP Server. For example: webserver.example.com.

      Platform

      Select the operating system type that hosts your IBM HTTP Server.
      Click OK and then click Save.

    5. Select Servers > Server Types > Web servers and click New.

    6. Provide values for the following fields:

      Select node

      Select the node specified in Step 4.

      Server name

      Enter the name of the your web server. The default value is webserver1.

      Type

      Select IBM HTTP Server.

    7. Click Next.

    8. Select the default web server template and 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 user name and password specified when you installed IBM HTTP Server. Confirm the password and click Next.

    10. Confirm to create the new web server.

    11. Click Finish and then click Save.

    12. Synchronize all the nodes.

    13. Select Servers > Server Types > Web servers and click the link to your webserver.

    14. Click Generate Plug-in.

    15. Select the check box for your webserver.

    16. Click Propagate Plug-in.

    17. Select Servers > Server Types > Web servers and click the link to your webserver.

    18. Click Plug-in properties and then click Copy to Web Server key store directory.

      If the plugin-key.kdb file is on a different system from the IBM HTTP Server system, copy it manually from the WAS system to the IBM HTTP Server system.

    19. Restart IBM HTTP Server.


    What to do next

    Complete the steps in the Configuring IBM HTTP Server for SSL topic.

    Configure IBM HTTP Server to handle file downloads from the Files and Wikis applications. For information on this configuration, see the Configuring Files and Wikis downloads topic.


    Configure IBM HTTP Server for SSL

    Configure IBM HTTP Server to use the SSL protocol.

    To support SSL, create a self-signed certificate and then configure IBM HTTP Server for SSL traffic. If you use this certificate in production, users might receiver warning messages from their browsers. In a typical production deployment, you would use a certificate from a trusted certificate authority.

    To configure IBM HTTP Server for SSL:

    1. Create a key file.

      1. Start the iKeyman user interface.

      2. Click Key Database File in the main user interface, then click New.

        Select CMS for the Key DB type. IBM HTTP Server does not support DB types other than CMS.

      3. Enter a name for the new key file.

        For example, hostname-key.kdb. Click OK.

      4. Enter your password in the Password Prompt dialog box, and confirm the password. Select Stash the password to a file and then click OK. The new key DB should display in the iKeyman utility with default signer certificates. Ensure that there is a functional, non-expiring signer certificate for each of your personal certificates.

    2. Create a self-signed certificate:

      1. Start the iKeyman user interface.

      2. Click Key Database File and then click Open.

      3. Enter your key file name in the Open dialog box and click OK.

      4. In the Password Prompt dialog box, enter your password and click OK.

      5. Click Personal Certificates in the Key Database content frame, and then click New Self-Signed.

      6. Enter the required information about the key file, your webserver, and organization in the dialog box.

      7. Click OK.

      Save the new self-signed certificate with a unique file name; do not overwrite the default Plugin-key.kdb file because that file might be accessed by other applications.

    3. Stop IBM HTTP Server.

    4. Log in to the WAS Integrated Solutions Console for the Deployment Manager and select Servers > Server types > Web servers.

    5. From the list of web servers, click the web server that you defined for this profile.

    6. On the Configuration page for this web server, click Edit for the Configuration file name field. This action opens the httpd.conf configuration file on the Deployment Manager.

    7. Add the following text to the end of the configuration file:

      LoadModule ibm_ssl_module modules/mod_ibm_ssl.so

      <IfModule mod_ibm_ssl.c>

      Listen 0.0.0.0:443

      <VirtualHost *:443>

      ServerName server_name

      #DocumentRoot C:\IBM\HTTPServer\htdocs

      SSLEnable

      </VirtualHost>

      </IfModule>

      SSLDisable

      Keyfile "path_to_key_file"

      SSLStashFile "path_to_stash_file"

      where

      • server_name is the host of the IBM HTTP Server.

      • path_to_key_file is the path to the key file that you created with the iKeyman utility.

      • path_to_stash_file is the path to the associated stash file.
      For example:

      • AIX:

        • Keyfile: /usr/IBM/keyfiles/key_file.kdb
        • SSLStashFile: /usr/IBM/keyfiles/key_file.sth

      • Linux:

        • Keyfile: /opt/IBM/keyfiles/key_file.kdb
        • SSLStashFile: /opt/IBM/keyfiles/key_file.sth

      • Microsoft Windows::

        • Keyfile: C:\IBM\keyfiles\key_file.kdb
        • SSLStashFile: C:\IBM\keyfiles\key_file.sth

      ...where key_file is the name that you have given to your key file and stash file.

    8. Click Apply and then click OK.

    9. Restart IBM HTTP Server to apply the changes.

    10. Test the new configuration: Open a web browser and ensure that you can successfully reach https://server_name. You might be prompted to accept the self-signed certificate on your browser.


    Results

    IBM Connections users can access applications through the SSL protocol.

    If you receive an error message about failing to load a GSK library (libgsk7ssl.so), install the libgsk7ssl.so GSK library. For more information, go to the following Support page: Failure attempting to load GSK library when using SSL with IBM HTTP Server.


    What to do next

    For more information about securing web communications, go to the IBM WAS Information Center or read the IBM WAS V7.0 Security Handbook.

    For more information about the key store and setting up the IBM HTTP Server, see the Securing communications topic in the WAS Information Center. The key file can be shared between two webservers, thus providing failover capability.


    Map applications to IBM HTTP Server

    Map IBM Connections applications to IBM HTTP Server.

    Complete this task if you installed and configured IBM HTTP Server before installing IBM Connections.

    If you plan to configure a reverse proxy, see the Configuring a reverse caching proxy topic.

    If you installed and configured IBM HTTP Server after installing IBM Connections, your IBM Connections applications are automatically mapped to the web server. However, if you installed and configured IBM HTTP Server before installing IBM Connections, manually map the applications.

    To map your IBM Connections applications to IBM HTTP Server and regenerate the plugin:

    1. Open the WAS Integrated Solutions Console on the system where you installed the Deployment Manager.

    2. Select Applications > Application Types > WebSphere enterprise applications.

    3. Map an IBM Connections application to IBM HTTP Server:

      This step instructs you to select webserver1. Ensure defined this web server before you attempt to complete these steps.

      1. Select application > Manage Modules,

        ...where application is an IBM Connections application.

      2. In the Clusters and Servers box, select the cluster and server on which you installed the application. If necessary, use the Ctrl key to select both targets.

      3. Select the check boxes for all the modules and click Apply.

      4. Review the Server details and ensure that both servers are listed there. Click OK and then click Save.

      5. Repeat this step for each IBM Connections application.

    4. From the WAS Integrated Solutions Console, select Servers > Server Types > Web servers and then click the web server (webserver1).

    5. Click Generate Plug-in.

    6. Click your web server again and then click Propagate Plug-in.

      If you have trouble propagating the plug-in on Linux, restart IBM HTTP Server s:

       ./adminctl start
       ./apachectl -k stop
       ./apachectl -k start

    7. Stop and restart the web server.

    8. Synchronize the nodes.

    9. Restart all IBM Connection clusters.

    10. Restart the Deployment Manager.


    What to do next

    To verify that the mappings are correct, complete the steps in the Verifying application mappings topic.

    Test the mappings: open a web browser and try to access each of the applications by specifying the web address using the following syntax:

    http://hostname/application_name

    where hostname is the host of the web server to which you mapped the application and application_name is the name of the application. Do not specify the port.


    Verify application mappings

    Verify that IBM Connections applications are mapped to your webserver.

    If you installed and configured IBM HTTP Server after installing IBM Connections, your IBM Connections applications are automatically mapped to the web server. However, if you installed and configured IBM HTTP Server before installing IBM Connections, manually map the applications. To verify whether the mappings exist, complete the following steps:

    1. From the WAS Integrated Solutions Console, select Servers > Server Types > Web servers and then click the web server (webserver1).

    2. Click Generate Plug-in.

    3. Click your web server again and then click Propagate Plug-in.

      If you have trouble propagating the plug-in on Linux, restart IBM HTTP Server s:

       ./adminctl start
       ./apachectl -k stop
       ./apachectl -k start

    4. Wait until a confirmation message is displayed; for example:

      PLGC0062I: The plug-in configuration file is propagated from /opt/IBM/WebSphere/AppServer/profiles/Dmgr01/config/cells/servernameCell01/nodes/webserver1/servers/webserver1/plugin-cfg.xml to /opt/IBM/HTTPServer/Plugins/config/webserver1/plugin-cfg.xml.

      The message identifies where the plugin-cfg.xml file is on the system that hosts IBM HTTP Server. In this example, the file path is: /opt/IBM/HTTPServer/Plugins/config/webserver1/plugin-cfg.xml.

    5. Log on to the system that hosts IBM HTTP Server and open the plugin-cfg.xml file.

    6. Verify the URIs for the installed IBM Connections applications are present. For example:

      <UriGroup Name="default_host_Cluster1_URIs">      
      <Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid" Name="/activities/*"/>      
      <Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid" Name="/activities/quickrpicker/*"/>      
      <Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid" Name="/communities/*"/>      
      <Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid" Name="/communities/calendar/*"/>      
      <Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid" Name="/communities/recomm/*"/>      
      <Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid" Name="/forums/*"/>      
      <Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid" Name="/metrics/service/*"/>      
      <Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid" Name="/metrics/*"/>      
      <Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid" Name="/profiles/*"/>      
      <Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid" Name="/profiles/seedlist/*"/>   
      </UriGroup>

      If the IBM Connections URIs are not present, complete the steps in the Mapping applications to IBM HTTP Server topic.


    Add certificates to the WebSphere trust store

    Import a self-signed IBM HTTP Server certificate into the default trust store of IBM WAS.

    Before you complete this procedure, ensure that IBM HTTP Server is configured to support SSL.

    This topic describes the procedure to configure certificates in a deployment with one webserver.

    To establish trusted server to server communication for IBM Connections, import signer certificates from IBM HTTP Server into the WAS default trust store.

    There are different types of certificates that you can use. This procedure describes how to import a self-signed certificate. You can also import a certificate that you purchased from a third-party Certificate Authority. To help decide a key file strategy for your environment, go the IBM HTTP Server information center.

    To import a public certificate from IBM HTTP Server to the default trust store in IBM WAS, complete the following steps:

    1. Log into the IBM WAS Integrated Solutions Console and select Security > SSL Certificate and key management > Key stores and certificates.

    2. Click CellDefaultTrustStore.

    3. Click Signer Certificates.

    4. Click Retrieve from port.

    5. Enter the Host name, SSL Port, and Alias of the webserver.

    6. Click Retrieve Signer Information and then click OK. The root certificate is added to the list of signer certificates.


    Results

    If your configuration changes aren't successful, ensure that you have applied the instructions to configure a default personal certificate.


    What to do next

    Verify that users can create a private community and add other widgets, such as Activities, Blogs, Dogear, and so on, to it. Ensure that there are no errors when these widgets are added. If problems are reported, consult the Communities SystemOut.log file.

    The proxy-config.tpl file allows a proxy to work with self-signed certificates. This is true for an out-of-the-box deployment but for improved security you should set the value of the unsigned_ssl_certificate_support property to false when your deployment is ready for production.

    Ensure that you are ready to renew your certificate before it expires. WAS provides a utility for monitoring certificates.


    Add certificates to IBM HTTP Server

    Add signer certificates to an IBM HTTP Server plug-in.

    Before you complete this procedure, ensure that IBM HTTP Server is configured to support SSL.

    To establish trusted communication between IBM HTTP Server and a web browser, import signer certificates from WAS.

    There are different types of certificates that you can use. This procedure describes how to import the self-signed certificate that is shipped with WAS. You can also import a certificate that you purchased from a third-party Certificate Authority, or create a new self-signed certificate. To import a public WAS certificate into the IBM HTTP Server plug-in:

    1. Copy the plugin-key.kdb file from the ibm_http_server_root/Plugins/config/webserver1 directory to the app_server_root/profiles/AppSrv01/config/cells/cell_name/nodes/node_name/servers/webserver_name directory.

      where cell_name, node_name, and webserver_name are the names of your WAS cell, the name of the node that you are configuring, and your web server.

    2. Log into the IBM WAS Integrated Solutions Console and select Security > SSL Certificate and key management > Key stores and certificates.

    3. Click CellDefaultTrustStore.

    4. Click Personal Certificates.

    5. Select the check box beside the default certificate and click Extract.

    6. Enter a fully-qualified Certificate file name. If you do not specify a directory path, the certificate is stored in the app_server_root/profiles/profile_name/etc directory, where profile_name is the name of the current WAS profile.

    7. Click OK to extract the file.

    8. In the IBM WAS Integrated Solutions Console, select Servers > Server Types > Web servers.

    9. Click webserver_name, where webserver_name is the name of your IBM HTTP Server web server.

    10. Click Plug-in properties and then click Manage keys and certificates.

    11. Under Additional Properties, click Signer certificatesand then click Add.

    12. Enter the certificate Alias and its fully-qualified File nameand then click OK.

    13. Click Save to import the file.

    14. In the IBM WAS Integrated Solutions Console, select Servers > Server Types > Web servers > webserver_name > Plug-in properties.

    15. Click Copy to web server key store directory to synchronize the KDB file with IBM HTTP Server.

    16. To apply the changes, restart IBM HTTP Server.


    Results

    If your configuration changes are not successful, ensure that you have applied the instructions to configure a default personal certificate.


    What to do next

    The proxy-config.tpl file allows the proxy to work with self-signed certificates. For improved security, set the value of the unsigned_ssl_certificate_support property to false when your deployment is ready for production.


    Determine which files to compress

    If you are not compressing content with the IBM WAS Edge components or a similar device, configure the IBM HTTP Server to compress certain types of content to improve browser performance. 

    This is an optional configuration. You do not need to perform this procedure if you are compressing content elsewhere in your network. Compression requires a significant amount of CPU; you must monitor resource availability if you choose to use this option. The directives discussed here do not compress images, but do compress JavaScript.

    To specify which types of files to compress:

    1. Use a text editor, open the httpd.conf file. The file is stored in the following directory by default:

      • AIX: /usr/IBM/HTTPServer/conf

      • Linux: /opt/IBM/HTTPServer/conf

      • Microsoft Windows:: C:\IBM\HTTPServer\conf

    2. Find the following entry in the configuration file:

      LoadModule deflate_module modules/mod_deflate.so

      If this entry is not present, add it.

    3. Add the following statements to compress multiple content types used by IBM Connections:

      #Only the specified MIME types will be compressed.
      
      AddOutputFilterByType DEFLATE application/atom+xml
      AddOutputFilterByType DEFLATE application/atomcat+xml
      AddOutputFilterByType DEFLATE application/javascript
      AddOutputFilterByType DEFLATE application/json
      AddOutputFilterByType DEFLATE application/octet-stream
      AddOutputFilterByType DEFLATE application/x-javascript
      AddOutputFilterByType DEFLATE application/xhtml+xml
      AddOutputFilterByType DEFLATE application/xml
      AddOutputFilterByType DEFLATE text/css
      AddOutputFilterByType DEFLATE text/html
      AddOutputFilterByType DEFLATE text/javascript
      AddOutputFilterByType DEFLATE text/plain
      AddOutputFilterByType DEFLATE text/xml
      AddOutputFilterByType DEFLATE text/xsl

    4. Add the following statement to specifically indicate that image files and binaries must not be compressed to prevent web browser hangs:

      # Ensures that images and executable binaries are not compressed
      SetEnvIfNoCase Request_URI \\.(?:gif|jpe?g|png|exe)$ no-gzip dont-vary

    5. Add the following statement to ensure that proxy servers do not modify the User Agent header needed by the previous statements:

      # Ensure that proxies do not deliver the wrong content
      Header append Vary User-Agent env=!dont-vary
      If the following line is commented out, remove the commenting from it:

      LoadModule headers_module modules/mod_headers.so
      

    6. Save and close the configuration file.

    7. Restart IBM HTTP Server.


    Update web addresses in IBM HTTP Server

    Update the web addresses that IBM HTTP Server uses to access IBM Connections applications.

    If you installed and configured IBM HTTP Server after installing IBM Connections, your IBM Connections applications are automatically mapped to the web server. However, if you installed and configured IBM HTTP Server before installing IBM Connections, manually map the applications.

    Before continuing with this task, map the application modules to IBM HTTP Server.

    If you are using the Files or Wikis applications, configure IBM HTTP Server to handle file downloads from those applications.

    If you choose to let the WAS redirect servlet manage file downloading, configure the server to transfer data synchronously instead of asynchronously. This configuration helps avoid errors caused by using too much memory. See the Excessive native memory use in IBM WAS technote for instructions.

    If you do not install a web server such as IBM HTTP Server, users must include the correct port in the web address that they use to access the application. When you use a webserver, users can access the applications without using port numbers.

    By default, the web address that you enter to access IBM Connections applications includes the port number for each application. To avoid using ports, update the web addresses by editing LotusConnections-config.xml. IBM HTTP Server can then redirect requests to the appropriate port for each application.

    To update the web addresses to your IBM Connections applications, complete the following steps:

    1. Stop WAS.

    2. Check out LotusConnections-config.xml. The file is stored by default in the following directory:

      • AIX: /usr/IBM/WebSphere/AppServer/profiles/profile_name/config/cells/cell_name/LotusConnections-config
      • Linux: /opt/IBM/WebSphere/AppServer/profiles/profile_name/config/cells/cell_name/LotusConnections-config
      • Windows: C:\IBM\WebSphere\AppServer\profiles\profile_name\config\cells\cell_name\LotusConnections-config

    3. For each application, update the web addresses specified in the href and ssl_href properties:

      <sloc:href>
      <sloc:hrefPathPrefix>/application</sloc:hrefPathPrefix>
      <sloc:static
      href="http://webserver:port"
      ssl_href="https://webserver:port">
      <sloc:interService 
      href="https://webserver:port">
      </sloc:href>

      where

      • webserver is the domain name of IBM HTTP Server, such as webserver.example.com.

      • port is the default port of the application. Remove the port when you specify a webserver.

      • application is the name of an IBM Connections application.

      Each href attribute in LotusConnections-config.xml is case-sensitive and must specify a fully-qualified domain name.

      For example, to update the web address for Communities, add the following specifications to the file:

      <sloc:href> 
      <sloc:hrefPathPrefix>/communities</sloc:hrefPathPrefix> 
      <sloc:static href="http://webserver.example.com" 
      ssl_href="https://webserver.example.com"> 
      <sloc:interService  href="https://webserver.example.com"> 
      </sloc:href>
      

      To use a reverse proxy, the web addresses defined in this file must be updated to match the appropriate proxy server URLs. Go to the IBM Connections wiki for more information about deployment scenarios, including how to configure a reverse proxy.

    4. Save and check in LotusConnections-config.xml.

    5. Synchronize the nodes.

    6. Log on to each application to ensure that the web addresses in the navigation bar are correct.


    Results

    You can access each application without needing to specify a port.


    Configure the Home page administrator

    Create an administrator for Home page so that you can make changes to the application such as adding and removing widgets.

    IBM Connections administrators must be dedicated users. Their only purpose should be application administration.

    Only a Home page administrator can add, remove, enable, or disable widgets on the Home page.

    You can also create global administrators for any of the applications, for the purpose of managing content.

    To configure administrative access to the Home page application, complete the following steps:

    1. Log in to the WAS Integrated Solutions Console on the Deployment Manager.

    2. Select Applications > Application Types > WebSphere enterprise applications.

    3. Click the link to the Home page application.

    4. Click the Security role to user/group mapping link.

    5. Select the check box beside the admin role and then click Map Users.

    6. In the Search String box, type the name of the person whom you would like to set as an administrator, and then click Search. If the user name exists in the LDAP directory, it is found and displayed in the Available box.

    7. Select the name from the Available box and then move it into the Selected column by clicking the right arrow button.

    8. Repeat Steps 4 and 5 to add more users to the administrative role.

    9. Click OK.

    10. From the Enterprise Applications > <application> > Security role to user/group mapping page, click OK and then click Save.

    11. Synchronize and restart all your WAS instances.


    Enable Search dictionaries

    During installation, only the English language dictionary is enabled by default. When your organization spans multiple geographies and multiple languages, you need to enable the relevant language dictionaries for your deployment to ensure that Search returns optimum results for your users.

    For non-English deployments, enabling multilingual support for Search is a mandatory post-installation step that needs to be performed before you start your IBM Connections Search server for the first time. Without multiple dictionary support, for languages other than English, Search only returns results where there is an exact match between the search term and content term. Enabling multiple dictionaries ensures better quality search results when your user base is multilingual.

    For information about how to enable multilingual support, see Configuring dictionaries for Search.


    Related

  • Configure dictionaries for Search


    Create the initial Search index

    When you install IBM Connections, Search indexing is automatically configured. To create the initial Search index, all you need to do is wait for one of the default indexing tasks to run.

    When you are installing a non-English language deployment, you must enable the relevant language dictionaries for your deployment before creating the initial Search index. Without multiple dictionary support, for languages other than English, Search only returns results

    ...where there is an exact match between the search term and the content term. Enabling multiple dictionaries ensures better quality search results when your user base is multilingual. Initial index creation occurs when any scheduled indexing task fires and an index does not yet exist. As part of the initial index creation process, the index is automatically rolled out to the secondary nodes in your deployment. Each node running the Search application must have the Search index stored locally on the node's file system. Because there are multiple indexes in a clustered environment, they must all be kept in synchronization with each other.

    The Search index directory is defined by the IBM WAS variable SEARCH_INDEX_DIR. You can change the location of the index by editing this variable.

    After the initial index has been built and optimized, the contents of the index directory are copied to a staging folder. When the newly-built index is successfully posted, JMS messages are broadcast so that each node automatically downloads the index from the staging folder and loads it. The index management tables are populated at the same time. For Search to function properly, the initial index must have completed successfully and it must be deployed to all nodes.

    Do not stop your deployment until the index has been copied to all nodes. If the server is stopped during this process, the index will not be successfully rolled out to all nodes. In this event, you need to manually copy the index from the staging location to the other nodes.

    You can change the location of the Search index staging folder by editing the WAS variable, SEARCH_INDEX_SHARED_COPY_LOCATION.


    Related

  • Configure dictionaries for Search

  • Recreating the Search index
  • Create a background index
  • Change the location of the Search index

  • Search default scheduled tasks


    Copy Search conversion tools to local nodes

    To enable full indexing of data, copy the Search conversion tools to local nodes.

    Perform this task only on nodes in the Search cluster. If you added a node to an existing cluster, as described in the Add a node to a cluster topic, complete this task only if the new node is a member of the Search cluster. References to nodes in the steps of this task apply only to nodes in the Search cluster.

    Steps 1-3 and 6-7 are required for all supported operating systems. However, if your deployment has only one node, skip steps 1-3. Steps 4-5 are required only if you are using the AIX or Linux operating system.

    The Search conversion tools index Files and Wiki attachments. The tools work best when they are available locally on each node. However, when IBM Connections was installed, the conversion tools were deployed on a network share. Therefore, copy the tools to each node in the Search cluster.

    To copy Search conversion tools to local nodes, complete the following steps:

    1. Identify the nodes in the Search cluster.

      1. Log in to the Integrated Solutions Console and click Servers > Clusters > WebSphere application server clusters.

      2. Click cluster_name, where cluster_name is the name of the Search cluster.

      3. In the Additional Properties area, expand Cluster members and then click Details.

      4. In the table of cluster members, make a note of the nodes that host the cluster members.

    2. Copy the shared_data_directory_root/search/stellent directory from the shared content folder to a local directory on each node. Use exactly the same path on each node. The following path is an example only and might be different on your operating system:

      • AIX or Linux: /opt/IBM/Connections/data/local/search/stellent

      • Windows: C:\IBM\Connections\data\local\search\stellent

      The new directory contains the exporter executable file.

    3. On the Deployment Manager, update the FILE_CONTENT_CONVERSION Websphere variable to point to the exporter file in the local directory on each node.

      For example: /opt/IBM/Connections/data/local/search/stellent/dcs/oiexport/exporter

      The exporter file must be in the same file path on all nodes.

    4. (AIX and Linux only) Back up the setupCmdLine.sh file on each node. This file is in the app_server_root/AppServer/bin directory.

    5. (AIX and Linux only) Add the following text to the end of the setupCmdLine.sh file on each node:

      1. export PATH=$PATH:SearchBinariesHome/dcs/oiexport

        where SearchBinariesHome is the path to the directory specified in Step 2.

      2. Choose the option for your operating system:

        • AIX: export LIBPATH=$LIBPATH:SearchBinariesHome/dcs/oiexport

        • Linux: export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:SearchBinariesHome/dcs/oiexport

    6. Restart all node agents.

    7. Restart WAS on each node.


    Access Windows network shares

    Configure a user account to access network shares in an IBM Connections deployment on the Microsoft Windows operating system

    This task applies only to deployments of IBM Connections environments where the data is located on network file shares, and where you have installed WAS on Microsoft Windows and configured it to run as a service. When WAS runs as a Windows service, it uses the local system account to log in with null credentials. When WAS tries to access an IBM Connections network share using Universal Naming Convention (UNC) mapping, the access request fails because the content share is accessible only to valid UIDs.

    When using a Windows service to start WAS, you must use UNC mapping; you cannot use drive letters to reference network shares.

    To resolve this problem, configure the WAS service login attribute to log in with a user account that is authorized to access the content share.

    To configure the WAS service:

    1. Click Start > Control Panel and select Administrative Tools > Services.

    2. Open the service for the first node in the list of WAS services.

    3. Click the Log On tab and select This account.

    4. Enter a user account name or click Browse to search for a user account.

    5. Enter the account password, and then confirm the password.

    6. Click OK to save your changes and click OK again to return to the Services window.

    7. Stop and restart the service.

    8. Repeat steps 3-7 for each node.


    What to do next

    Your corporate password policy might require that you change this login attribute periodically. If so, remember to update this service configuration. Otherwise, your access to network shares might fail.


    Configure Moderation

    Configure moderation so that moderators can review content for blogs, forums, and community files from a central interface.

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

    • Blog entries and comments. These can be in stand-alone blogs or community blogs.

    • Forum posts and replies. These can be in stand-alone forums or community forums.

    • Files and comments within a community.

    To enable moderation, follow these steps:

    1. Install the Moderation application as part of the Connections installation or migration.

    2. Assign users to the role of global moderator so they can moderate content from a central interface.

    3. Configure moderation in the contentreview-config.xml file if you want to enable moderation features such as owner moderation or assign content reviewers for flagged content.


    Designating global moderators

    Assign users to the role of global-moderator so they can moderate content for blogs, forums, and community files from a central interface.

    In order for a user to moderate content, they must be assigned the global-moderator role for the Moderation application and for the applications you want moderated, which can be Blogs, Forums, Files, and Communities.

    To map users to a global moderator role, complete the following steps:

    1. Map a user to a global-moderator role:

      1. Expand Applications > Application Types, and then select WebSphere enterprise applications. Find and click the link to the application to configure.

      2. Click Security role to user/group mapping.

      3. Select the check box for the global-moderator role, and then click Map users.

      4. In the Search String box, type the name of the user to assign to the role, and then click Search. If the user exists in the directory, it is displayed in the Available list.

      5. Select the user or group name from the Available box, and then move it into the Selected column by clicking the right arrow button.

      6. Click OK.

      7. Click OK, and then click Save to save the changes.

    2. Synchronize and restart all your WAS instances.


    Configure J2C Aliases for the moderation proxy service

    Configure J2C Aliases so that community owners can moderate their community Blogs, Forums, and Files applications.

    Moderation actions are performed by a moderation API. Community owners cannot access that API, so IBM Connections handles their moderation requests through a proxy service. The proxy service uses J2C Aliases to pass the requests. Proxy service alias users must be in the global-moderator roles of the appropriate applications, and they must be able to log in to IBM Connections.

    By default the proxy service uses the connectionsAdmin J2C Alias provided during installation. That user is mapped to the global-moderator roles for Blogs, Forums, Files, Moderation, and Communities by the installation program, and can log in to IBM Connections. However, you can create different moderation aliases for each of the different supported applications. You can create the following aliases:

    • For Blogs create an alias called moderationBlogsAlias.

    • For Files create an alias called moderationFilesAlias.

    • For Forums create an alias called moderationForumAlias.

    The different applications recognize these specific aliases. You can map any users to these aliases, but all users must be in the global-moderator roles of the appropriate application, and they must be able to log into IBM Connections. For example, the moderationBlogsAlias user must be in the global-moderator role for Blogs. See Roles.

    The proxy service logs its actions, so if the users (other than the connectionAdmin user) are only used for this purpose, it will make reading the log more clear.

    To create moderation aliases and then map them to a global moderator role:

    1. Create a moderation alias:

      1. From the IBM WAS Integrated Solutions Console, expand Security, and then click Global security.

      2. In the Authentication area, expand Java Authentication and Authorization Service, and click J2C authentication data.

      3. Click New.

      4. Name the alias, for example moderationFilesAlias.

      5. Set the name and password of a user for the alias.

      6. Click OK.

    2. Map an alias user to a global-moderator role:

      1. Expand Applications > Application Types, and then select WebSphere enterprise applications. Find and click the link to the application to configure.

      2. Click Security role to user/group mapping.

      3. Select the check box for the global-moderator role, and then click Map users.

      4. In the Search String box, type the name of the user to assign to the role, and then click Search. If the user exists in the directory, it is displayed in the Available list.

      5. Select the user or group name from the Available box, and then move it into the Selected column by clicking the right arrow button.

      6. Click OK.

      7. Click OK, and then click Save to save the changes.

    3. Synchronize and restart all your WAS instances.


    Synchronize files shared with communities

    After upgrading, you must synchronize files that have been shared with communities. After upgrading the IBM Connections applications and DBs, but before any users have access, you must synchronize files shared with communities.

    To run the command FilesDataIntegrityService.syncAllCommunityShares() follow the steps detailed in the topic Run Files administrative commands.


    Related tasks

  • Run Files administrative commands


    Configure Cognos Business Intelligence

    Configure your IBM Cognos Business Intelligence environment to work with IBM Connections.

    After you have installed Cognos Business Intelligence, configure the environment by completing the following tasks:


    Apply fix packs to update the Cognos server

    Apply available fix packs to the Cognos Business Intelligence server to provide important product corrections. These fixes must be applied after Cognos Business Intelligence has been installed.

    Install Cognos Business Intelligence and federate the server to the IBM Connections Deployment Manager as explained in Install Cognos Business Intelligence in the Pre-installation section of this documentation.

    For additional information on updating Cognos Business Intelligence with fix packs, see Install Fix Packs in the Cognos information center.

    Download the latest fix pack and apply it to the Cognos server. At a minimum, you will need to apply the fix pack listed below, but you should check with IBM Fix Central in case additional fix packs were made available after this documentation was published. Fix packs are cumulative; when you install the latest fix pack, it includes updates from all previous fix packs.

    1. Stop IBM WAS and verify that all Cognos services have stopped before proceeding to the next step.

      After stopping the server, wait at least 1 full minute to ensure that all Cognos processes have stopped:

      • IBM AIX or Linux: cgsServer.sh and CAM_LPSvr processes

      • Microsoft Windows:: cgsLauncher.exe and CAM_LPSvr processes

    2. Download fix packs for Cognos Business Intelligence 10.1.1 from IBM Fix Central.

      Fix packs required for a new deployment of IBM Cognos for IBM Connections

      Operating system Fix pack
      AIX 10.1.1-BA-CBI-AIX64-FP001
      Linux 10.1.1-BA-CBI-Linuxi38664-FP001
      Windows 10.1.1-BA-CBI-Win64-FP001
      zLinux 10.1.1-BA-CBI-zLinux64-FP001

      1. Review the fix pack prerequisites and make sure your deployment satisfies all requirements.

      2. Download the appropriate compressed tar file for your operating system using the links in the "Download Package" section.

        Some browsers might change a downloaded file.s type from .tar.gz to a file type not recognized by the operating system. To correct this, change the file type back to .tar.gz after the download is complete. Using Download Director will prevent inadvertent renaming of files at download.

    3. Expand the downloaded fix pack.

      AIX or Linux

      1. Open command prompt or terminal window.

      2. Change to the directory where you have downloaded the fix pack.

      3. Run the following command to expand the package using either GNU Zip (gzip) or GNU Tar (tar):

        gunzip fix_pack_file_name.tar.gz | tar xvf . 

      Windows

      1. Open a command prompt.

      2. Change to the directory where you have downloaded the fix pack.

      3. Expand the package using your file compress and decompress utility (if you are using WinZip, select the option "Use folder names" to retain the package.s folder structure).

    4. Apply the fix pack:

      AIX or Linux:

      1. Change to the directory where you expanded the fix pack.

      2. Now change to the following subdirectory:

        • AIX: /aix64h

        • Linux: /linuxi38664h

        • zLinux: /zlinux64h

      3. Run the following command: ./issetup

        If you do not use XWindow, run an unattended installation as explained in Set Up an Unattended Installation Using a File From an Installation on Another Computer in the Cognos information center.

      4. Follow the instructions in the installation wizard, install the fix pack in the same location as your existing IBM Cognos components.

        This installation location is the path specified for the cognos.biserver.install.path property in the cognos-setup.properties file.

      Windows:

        cd FIX_DIR/win64h
        ./issetup.exe

    5. Follow the instructions in the installation wizard, install the fix pack in the same location as your existing IBM Cognos components.

      This installation location is the path specified for the cognos.biserver.install.path property in the cognos-setup.properties file.

  • Generate a new Cognos BI Server EAR file with the fix pack:

    1. Locate the cognos-setup-update.sh script in the directory where you expanded the CognosConfig.zip or CognosConfig.tar when you installed Cognos Business Intelligence components as part of the pre-install task.

    2. Edit the cognos-setup.properties file and verify that it contains the appropriate values for each property.

      All passwords were removed from this file the last time it was used, so you must either add the passwords again, or pass them in from the command line when you run the cognos-setup-update.sh script.

    3. Run the cognos-setup-update.sh script.

  • Apply the new EAR file to the Cognos server by running an update in the WebSphere Integrated Solutions Console:

    1. On the server where Cognos BI Server is installed, start WAS.

    2. Log in to the Integrated Solutions Console as the WebSphere administrator.

    3. Click Servers > Enterprise Applications.

    4. In the list of applications, select the Cognos where you generated the new EAR file, and click the Update button in the table.

    5. Browse to the newly built EAR file residing in the Cognos_BI_Server_install_path directory, and click Next.

    6. Complete the remaining screens by accepting the default values and clicking Next.

    7. Click Finish to complete the update.

  • If necessary, enable anonymous access to the Cognos server:

    If you disabled anonymous access to the Cognos server, you must enable it now because the script that updates the configuration requires that anonymous access be enabled. There are two ways to enable anonymous access. You can run the Cognos Configuration tool or, if your Cognos server runs on AIX or Linux and does not provide a graphical user interface, you can enable anonymous access manually.

    It is not necessary to disable anonymous access again when you complete this task because you will do that when you configure LDAP authentication in the next task.

    Enable anonymous access with the Cognos Configuration tool:

    1. Navigate to the /bin directory of the Cognos BI Server installation directory:

      For example:

      • AIX or Linux: /opt/IBM/Cognos64/bin/

      • Windows: C:\Program Files\IBM\Cognos\bin

    2. Start the Cognos Configuration tool:

      • AIX or Linux: ./cogconfig.sh

      • Windows: cogconfig.bat

    3. Expand Local Configuration > Security > Authentication > Cognos and set Allow anonymous access? to True.

    4. Exit the Cognos Configuration tool, making sure to select No at the following prompt: The service 'IBM Cognos' is not running on the local computer. Before you can use it your computer must start the service. Do you want to start this service before exiting?

    5. Restart IBM WAS.

    Enable anonymous access manually:

    1. Navigate to the /configuration directory within the Cognos BI Server installation directory:

      For example:

      • AIX or Linux: /opt/IBM/Cognos64/bin/

      • Windows: C:\Program Files\IBM\Cognos\bin

    2. Open the working copy of the cogstartup.xml file for editing.

    3. Within the <crn:instance name="Cognos" class="Cognos"> section, change the allowAnon parameter:

      From:

      <crn:parameter name="allowAnon">
      <crn:value xsi:type="xsd:boolean"> false </crn:value>
      </crn:parameter>

      To:

      <crn:parameter name="allowAnon">
      <crn:value xsi:type="xsd:boolean"> true </crn:value>
      </crn:parameter>

    4. Save and close the file.

    5. Restart WAS.

  • Run the cognos-configure.sh script to configure the Cognos server and set up DB connections, just as you did when you originally deployed the Cognos server.

    Output from this operation is stored in the /CognosSetup/cognos-configure.log file.

    If you encounter an error when running the cognos-configure.sh script, correct the error and run the script again before proceeding to the next task.


    Configure support for LDAP authentication for Cognos Business Intelligence

    Configure the IBM Cognos Business Intelligence server to support the use of an LDAP directory for user authentication.

    Configure Cognos Business Intelligence to use the same LDAP directory that IBM Connections uses for authentication. Configuring LDAP authentication involves disabling anonymous access and restricting access to the namespace. Be sure to use the namespace specified by the cognos.namespace property in the cognos-setup.properties file; by default, that namespace is called IBMConnections.

    For general information on LDAP authentication in Cognos, see the Cognos information center.

    If you will be configuring LDAP authentication over SSL, see the IBM technote Configure LDAPS (LDAP via SSL) for CRN/Cognos 8 (also applicable to later versions of the product).

    Set the values for the LDAP properties as shown in this example, which configures Cognos for IBM Directory Server. For detailed instructions, see Configure LDAP support in the Cognos information center.

    1. Start the Cognos Configuration tool.

      The Cognos Configuration tool provides a graphical user interface for defining LDAP properties. If your IBM AIX or Linux server does not support a graphical user interface, see the topic Configure LDAP settings manually for instructions on configuring these LDAP authentication settings manually.

    2. Navigate to the /bin directory of the Cognos BI Server installation directory.

      For example:

      • IBM AIX or Linux: /opt/IBM/Cognos64/bin/

      • Microsoft Windows::C:\IBM\Cognos\bin

    3. Start the Cognos Configuration tool:

      • AIX or Linux: ./cogconfig.sh

      • Windows:cogconfig.bat

    4. Expand Local Configuration > Security > Authentication > IBMConnections and set the values shown here for the following properties:

      IBMConnections is the namespace, specified in the cognos.namespace property of the cognos-setup.properties file used for deploying the Cognos server.

      These settings are for IBM Directory Server; you might need different settings for another LDAP directory.

      • User lookup: (uid=${userID})

      • Use external identity? True

      • External identify mapping: (uid=${environment("REMOTE_USER")})

    5. Expand Local Configuration > Security > Authentication > Cognos and set Allow anonymous access? to False.

    6. Exit the Cognos Configuration tool, making sure to select No at the following prompt: The service 'IBM Cognos' is not running on the local computer. Before you can use it your computer must start the service. Do you want to start this service before exiting?

    7. Restart the Cognos server:

      1. Stop the IBM WAS that hosts the Cognos server.

      2. Wait at least 1 full minute to ensure that all Cognos processes have stopped:

        • AIX or Linux: cgsServer.sh and CAM_LPSvr processes

        • Windows: cgsLauncher.exe and CAM_LPSvr processes

      3. Start WAS.

      4. Start the Cognos server.


    What to do next

    After you have configured LDAP authentication for Cognos Business Intelligence, add users to the IBMConnectionsMetricsAdmin within the Cognos deployment as described in Configure the IBMConnectionsMetricsAdmin role on Cognos.


    Configure LDAP settings manually

    If your IBM Cognos Business Intelligence server runs on IBM AIX or Linux and does not provide a graphical user interface, you can configure LDAP authentication settings manually.

    You can configure the use of the LDAP directory by adding a component to the Cognos server.s cogstartup.xml file and then customizing it for your deployment.

    For general information on LDAP authentication in Cognos, see the Cognos information center.

    If you will be configuring LDAP authentication over SSL, see the IBM technote Configure LDAPS (LDAP via SSL) for CRN/Cognos 8 (also applicable to later versions of the product).

    1. On the computer where you installed Cognos Business Intelligence, navigate to the /configuration directory within the installation location of the BI Server component (specified by the cognos.biserver.install.path property in the cognos-setup.properties file); for example:

      • IBM AIX or Linux: /opt/IBM/Cognos64/configuration

      • Microsoft Windows:: C:\IBM\Cognos\configuration

    2. Make a backup copy of the cogstartup.xml file.

    3. Open the working copy of the cogstartup.xml file for editing.

    4. Now open the Authentication sample file for your locale, stored in the /samples subdirectory.

      The file name includes the locale code; for example, open the Authentication_en.xmlfile if you are using English.

    5. Within the Authentication_language_code.xml file, locate and copy the section of code for the LDAP directory product.

      Look for the (Begin of)LDAP template and (End of)LDAP template comments that enclose the section, and be sure to copy everything between them (the entire crn_instance).

      <!--
      ===============================================
      (Begin of) LDAP template
      -->
       <crn:instance name="LDAP Name" class="LDAP"...>
      
      ...
      
      </crn:instance> 
      <!--
      (End of) LDAP template
      ===============================================
      -->

    6. Paste the copied code into the cogstartup.xml file.

      You can insert the new code before the closing </crn:instances> line at the end of the file.

             </crn:instances>     </crn:value>
        </crn:parameter>
      </crn:parameters>

    7. Update the new code by making the following changes:

      The settings shown in substeps a, b, and c are for IBM Directory Server; you might need different settings for another LDAP directory.

      1. Change the userLookup parameter:

        From:

        <crn:parameter name="userLookup">
        <crn:value xsi:type="xsd:string"> ${userID} </crn:value>
        </crn:parameter>

        To:

        <crn:parameter name="userLookup">
        <crn:value xsi:type="xsd:string"> (uid=${userID}) </crn:value>
        </crn:parameter>

      2. Change the useExternalIdentity parameter:

        From:

        <crn:parameter name="useExternalIdentity">
        <crn:value xsi:type="xsd:boolean"> false </crn:value>
        </crn:parameter>

        To:

        <crn:parameter name="useExternalIdentity">
        <crn:value xsi:type="xsd:boolean"> true </crn:value>
        </crn:parameter>

      3. Change the externalIdentityMapping parameter:

        From:

        <crn:parameter name="externalIdentityMapping">
        <crn:value xsi:type="xsd:string"> ${environment("REMOTE_USER")} </crn:value>
        </crn:parameter>

        To:

        <crn:parameter name="externalIdentityMapping">
        <crn:value xsi:type="xsd:string"> (uid=${environment("REMOTE_USER")}) </crn:value>
        </crn:parameter>

      4. Within the <crn:instance name="Cognos" class="Cognos"> section, change the allowAnon parameter:

        From:

        <crn:parameter name="allowAnon">
        <crn:value xsi:type="xsd:boolean"> true </crn:value>
        </crn:parameter>

        To:

        <crn:parameter name="allowAnon">
        <crn:value xsi:type="xsd:boolean"> false </crn:value>
        </crn:parameter>

    8. Save and close the file.

    9. Validate the modified file: ./cogconfig.sh -config

    10. Restart the Cognos server:

      1. Stop the IBM WAS that hosts the Cognos server.

      2. Wait at least 1 full minute to ensure that all Cognos processes have stopped:

        • AIX or Linux: cgsServer.sh and CAM_LPSvr processes

        • Windows: cgsLauncher.exe and CAM_LPSvr processes

      3. Start WAS.

      4. Start the Cognos server.


    What to do next

    After you have configured LDAP authentication for Cognos Business Intelligence, add users to the IBMConnectionsMetricsAdmin within the Cognos deployment as described in Configure the IBMConnectionsMetricsAdmin role on Cognos.


    Grant access to global metrics

    Configure the metrics-report-run security role to grant users the authority to view and interact with global metrics.

    Other than administrators, only the users assigned to the metrics-report-run role can access global metrics. Whenever a user with this authorization level views the global metrics, the report information is updated automatically.

    Configure the metrics-report-run security role in IBM WAS.

    1. On the Deployment Manager, log in to the Integrated Solutions Console as the WebSphere administrator.

    2. In the navigation tree, click Enterprise Applications > Metrics > Security role to user/group mapping.

    3. In the roles table, click the check box next to the metrics-report-run role.

    4. Click the Map Groups button in the table.

    5. Add one or more user groups to the metrics-report-run role, giving those users the ability to view and interact with global metrics reports.

      For best results, limit access to a small set of users whose jobs require them to view the most recent metrics. Granting this level of access to a large number of users slow performance, as update requests are processed in sequence.

    6. Click OK.

    7. Save the change to the master configuration by clicking the Save link in the "Messages" box.

    8. Synchronize all nodes in the cell to the Deployment Manager, and then restart the node agents:

      1. On the navigation tree, click System Administration > Nodes.

      2. Click the Full Resynchronize button in the table.

      3. Return to the navigation tree and click System Administration > Node agents.

      4. In the nodes table, click the box in front of each node.

      5. Click the Restart button in the table.


    Grant access to community metrics

    Configure the community-metrics-run security role to grant users the authority to view community metrics using static reports.

    Other than administrators and community owners, only the users assigned to the community-metrics-run role can access community metrics. Users with this level of access see static reports, which can be refreshed by clicking the Update button in the Metrics user interface. You can map this role to everyone, or to subset of the user population. For example, you can gradually provide the community metrics feature to the user population by mapping this role to small group first, and then adding more users to the role over time.

    Configure the community-metrics-run security role in IBM WAS.

    1. On the Deployment Manager, log in to the Integrated Solutions Console as the WebSphere administrator.

    2. In the navigation tree, click Enterprise Applications > Metrics > Security role to user/group mapping.

    3. In the roles table, click the check box next to the community-metrics-run role.

    4. Click the Map Groups button in the table.

    5. Add one or more user groups to the community-metrics-run role, giving those users the ability to view community metrics as static reports.

    6. Click OK.

    7. Save the change to the master configuration by clicking the Save link in the "Messages" box.

    8. Synchronize all nodes in the cell to the Deployment Manager, and then restart the node agents:

      1. On the navigation tree, click System Administration > Nodes.

      2. Click the Full Resynchronize button in the table.

      3. Return to the navigation tree and click System Administration > Node agents.

      4. In the nodes table, click the box in front of each node.

      5. Click the Restart button in the table.


    Configure the IBMConnectionsMetricsAdmin role on Cognos

    Configure the IBMConnectionsMetricsAdmin in Cognos Business Intelligence to ensure that the Metrics administrator has access to features and reports.

    After you have configured LDAP authentication for Cognos Business Intelligence, configure the IBMConnectionsMetricsAdmin so that specified LDAP users can access Cognos features. In particular, you will want to add the following users to this role:

    • The user assigned to the Cognos administrator account

      The Cognos administrator is the primary person responsible for configuring Cognos features and reports.

    • All users who have been assigned to the admin role for Connections

      Anyone tasked with administering the Connections deployment should have access to Cognos features to ensure they can manage the full deployment as needed.

    • All users who have been assigned to the metrics-report-run role

      Users who have been authorized to run global metrics reports require access to Cognos before they can work with the reports.

    1. Use a browser to navigate to the Cognos deployment with the following address: http://Host_Name:Port/Context_Root/servlet/dispatch/ext

      where:

      • Host_Name is the fully qualified host of the Cognos server; for example, host.example.com. This value is specified in the was.fqdn.hostname property in the cognos-setup.properties file used for installing the server.

      • Port is the port that the Cognos server is listening on.

      • Context_Root is the context root to which you installed the Cognos server; for example, cognos.

    2. Log in to Cognos using an IBM Connections administrator account.

    3. On the Cognos dashboard, click Log On.

    4. On the next page, click Launch and then select IBM Cognos Administration.

    5. Select the Security tab.

    6. On the Directory page, select Cognos from the list and then select the IBMConnectionsMetricsAdmin role.

    7. Add users to the IBMConnectionsMetricsAdmin role:

      1. With the IBMConnectionsMetricsAdmin role selected, click the Set properties icon.

      2. In the properties window, click the Members tab, and then click Add.

      3. In the Add window, click Show users in the list.

      4. Select all users who require administrator access to Cognos Business Intelligence, click Add to add them to the role.

        Remember to add at least the following users:

        • The Cognos administrator

        • All Connections administrators

        • All users assigned to the metrics-report-run role

      5. Click OK to save the change.

      6. Save the change to the master configuration by clicking Save in the "Messages" box.

    8. Back in the users list, select the System Administrators role and limit access to the role by removing Everyone from the members list:

      1. With the System Administrators role selected, click the Set properties icon.

      2. In the properties window, click the Members tab.

      3. In the Members window, select Everyone, and then click Remove to delete it from the list of members.

      4. Click OK to save the change.

      5. Save the change to the master configuration by clicking Save in the "Messages" box.


    Configure PowerCube refresh schedules

    By default, IBM Cognos Transformer refreshes each PowerCube with incremental updates once each day, and replaces the cube.s data for the current month once a week. These jobs are scheduled by default but you might need to modify the schedules to avoid conflicts with other activities.

    When scheduling the refresh jobs, keep the following issues in mind:

    • These jobs should run at times when the Cognos system usage is relatively low, to minimize the impact on normal usage. You should adjust these times based on your system's usage pattern.

    • The weekly refresh should run only once every week; since it will take longer to complete, you should schedule it for the time when system usage is lowest (for example, on the weekend).

    • The daily refresh should run early in the morning (for example, just after midnight), so users can see the latest metrics for the previous day.

    On the computer hosting Cognos Transformer, schedule the PowerCube updates, making sure the schedules for the daily and weekly jobs do not collide:

    • AIX or Linux:

      Edit the cron jobs in the system crontab.

    • Windows:

      Edit the MetricsCubeDailyRefresh job to ensure it does not collide with the weekly refresh. You can modify the job.s properties in the Task Scheduler Library; for more information see the next topic.


    Configure the job scheduler for Cognos Transformer on Windows

    Rather than store administrative credentials in a script, you can add them to the job properties of the IBM Cognos Transformer to enable scheduled tasks on Microsoft Windows.

    Finish configuring the job scheduler to run the Transformer periodically by adding the Windows Administrator credentials to the MetricsCubeDailyRefresh scheduler job.

    1. Click Start > Control Panel > Administrative Tools and click Task Scheduler.

    2. In the navigation tree, click Task Scheduler Library.

    3. In the list of scheduled tasks, click MetricsCubeDailyRefresh to view its properties.

    4. In the MetricsCubeDailyRefresh Properties window, open the General tab and click the Change User or Group button.

    5. In the Select user or group dialog box, type administrator in the Enter the object name to select field, and then click the Check Names button.

      The Task Scheduler compiles a list accounts with administrative access on this Windows server.

    6. When the Task Scheduler dialog box prompts to Enter the user account information to run this task, select the Windows Administrator user name that will be associated with the MetricsCubeDailyRefresh task, and type the password associated with that account; then click OK.

      The selected administrator account now has the authority to run the MetricsCubeDailyRefresh task.

    7. Click OK to save the change and close the MetricsCubeDailyRefresh Properties window.

    8. Close the Task Scheduler.


    Configure Cognos Business Intelligence to use IBM HTTP Server

    IBM Cognos Business Intelligence uses the same IBM HTTP Server as IBM Connections, but configure Cognos Business Intelligence to work with that server.

    After you have configured IBM HTTP Server as described in the section Configure IBM HTTP Server, complete these tasks to configure the Cognos BI Server and the Cognos Transformer components to use HTTP:


    Configure Cognos BI Server to use HTTP

    Configure the Cognos BI Server to use the IBM HTTP Server that operates with the IBM Connections deployment.

    Use the Cognos Configuration tool to specify settings that enable Cognos BI Server to operate with IBM HTTP Server.

    The Cognos Configuration tool provides a graphical user interface. If your IBM AIX or Linux server does not support a graphical user interface, see the topic Configure HTTP manually for Cognos BI Server for instructions on configuring these settings manually.

    1. Navigate to the /bin directory of the Cognos BI Server installation directory.

      For example:

      • IBM AIX, Linux: /opt/IBM/Cognos64/bin/

      • Microsoft Windows::C:\IBM\Cognos\bin

    2. Start the Cognos Configuration tool:

      • AIX, Linux: ./cogconfig.sh

      • Windows:cogconfig.bat

    3. Expand Local Configuration > Environment and edit the URLs for the following properties by removing any reference to ports 908x and replacing them with port 80:

      The URLs must be updated to point to the HTTP server's host and port. The port must be included even if it's the standard port 80.

      • Gateway Sets

        In this section, change only the "Dispatch URIs for gateway" attribute.

      • Other URI Sets

    4. Save your changes.

    5. Exit the Cognos Configuration tool, making sure to select No at the following prompt: The service 'IBM Cognos' is not running on the local computer. Before you can use it your computer must start the service. Do you want to start this service before exiting?

    6. Restart the Cognos server:

      1. Stop the IBM WAS that hosts the Cognos server.

      2. Wait at least 1 full minute to ensure that all Cognos processes have stopped:

        • AIX or Linux: cgsServer.sh and CAM_LPSvr processes

        • Windows: cgsLauncher.exe and CAM_LPSvr processes

      3. Start WAS.

      4. Start the Cognos server.


    Configure HTTP manually for Cognos BI Server

    If your IBM Cognos Business Intelligence server runs on IBM AIX or Linux and does not provide a graphical user interface, you can configure HTTP settings manually.

    You can configure HTTP by adding a component to the Cognos BI Server.s cogstartup.xml file and then customizing it for your deployment.

    For more information, see the Cognos information center.

    1. On the computer where you installed Cognos Business Intelligence, navigate to the /configuration directory within the installation location of the BI Server component (specified by the cognos.biserver.install.path property in the cognos-setup.properties file); for example:

      • AIX or Linux: /opt/IBM/Cognos64/configuration

      • Microsoft Windows:: C:\IBM\Cognos\configuration

    2. Make a backup copy of the cogstartup.xml file.

    3. Open the working copy of the cogstartup.xml file for editing.

    4. In the file, locate the following parameters and update their URI port references from 90xx to port 80:

      In this file, the URLs must be updated to point to the HTTP server's host and port. The port must be included even if it's the standard port 80.

      <crn:parameter name=

      • gateway

      • gatewayDispatcherURIList

      • sdk

      • contentManagers

      After your changes, those parameters should look like the ones that follow:

       <crn:parameter name=" gateway ">
       	   <crn:value xsi:type="xsd:anyURI">http://cognos.example.com: 80 /ibmcognos/cgi-bin/cognos.cgi</crn:value>
       </crn:parameter>
      	
      	 <crn:parameter name=" gatewayDispatcherURIList " opaque="true">
         		<crn:value xsi:type="cfg:sortedArray">
            		<crn:item xsi:type="xsd:anyURI" order="0">http://cognos.example.com: 80 /cognos/servlet/dispatch/ext</crn:item>
        		 </crn:value>
       </crn:parameter>
      	
      	 <crn:parameter name=" sdk ">
           <crn:value xsi:type="xsd:anyURI">http://cognos.example.com: 80 /cognos/servlet/dispatch</crn:value>
       </crn:parameter>
      
      <crn:parameter name=" contentManagers ">	
      	    <crn:value xsi:type="cfg:array">
      	        <crn:item xsi:type="xsd:anyURI">http://cognos.example.com: 80 /cognos/servlet</crn:item>
        	 </crn:value>
      <crn:parameter>

    5. Save and close the file.

    6. Validate the modified file:

      1. Set JAVA_HOME to the WAS_install_path/java directory.

      2. Run the configuration script:

        • AIX or Linux: ./cogconfig.sh -config

        • Windows: cogconfig.bat -config

      3. Check the Cognos_BI_Server_install_path/logs/cogconfig_response.csv file for a success message.

    7. Restart the Cognos server:

      1. Stop the IBM WAS that hosts the Cognos server.

      2. Wait at least 1 full minute to ensure that all Cognos processes have stopped:

        • AIX or Linux: cgsServer.sh and CAM_LPSvr processes

        • Windows: cgsLauncher.exe and CAM_LPSvr processes

      3. Start WAS.

      4. Start the Cognos server.


    Configure Cognos Transformer to use HTTP

    Configure the Cognos Transformer to use the IBM HTTP Server that operates with the IBM Connections deployment.

    Use the Cognos Configuration tool to specify settings that enable Cognos Transformer to operate with IBM HTTP Server.

    The Cognos Configuration tool provides a graphical user interface. If your IBM AIX or Linux server does not support a graphical user interface, see the topic Configure HTTP manually for Cognos Transformer for instructions on configuring these settings manually.

    1. Navigate to the /bin directory of the Cognos Transformer installation directory.

      For example:

      • AIX, Linux: /opt/IBM/Cognos/bin/

      • Windows:C:\Program Files (x86)\IBM\Cognos\bin

    2. Start the Cognos Configuration tool:

      • AIX, Linux: ./cogconfig.sh

      • Windows:cogconfig.bat

    3. Expand Local Configuration > Environment and edit the URLs for the following properties by removing any reference to ports 908x and replacing them with port 80:

      The URLs must be updated to point to the HTTP server's host and port. The port must be included even if it's the standard port 80.

      • Gateway Sets

      • Other URI Sets

    4. Save your changes.

    5. Exit the Cognos Configuration tool.

      You do not need to restart the Transformer component.


    Configure HTTP manually for Cognos Transformer

    If your IBM Cognos Business Intelligence server runs on IBM AIX or Linux and does not provide a graphical user interface, you can configure HTTP settings manually.

    You can configure HTTP by adding a component to the Cognos Transformer.s cogstartup.xml file and then customizing it for your deployment.

    For more information, see the Cognos information center.

    1. On the computer where you installed Cognos Business Intelligence, navigate to the /configuration directory within the installation location of the Transformer component (specified by the cognos.transformer.install.path property in the cognos-setup.properties file); for example:

      • IBM AIX or Linux: /opt/IBM/Cognos/configuration

      • Microsoft Windows: C:\Program Files (x86)\IBM\Cognos\configuration

    2. Make a backup copy of the cogstartup.xml file.

    3. Open the working copy of the cogstartup.xml file for editing.

    4. In the file, locate the following parameters and update their URI port references from 90xx to port 80: I

      In this file, the URLs must be updated to point to the HTTP server's host and port. The port must be included even if it's the standard port 80.

      <crn:parameter name=

      • gateway

      • gatewayDispatcherURIList

      After your changes, those parameters should look like the ones that follow:

       <crn:parameter name=" gateway ">
       	   <crn:value xsi:type="xsd:anyURI">http://cognos.example.com: 80 /ibmcognos/cgi-bin/cognos.cgi</crn:value>
       </crn:parameter>
      	
      	 <crn:parameter name=" gatewayDispatcherURIList " opaque="true">
         		<crn:value xsi:type="cfg:sortedArray">
            		<crn:item xsi:type="xsd:anyURI" order="0">http://cognos.example.com: 80 /cognos/servlet/dispatch/ext</crn:item>
        		 </crn:value>
       </crn:parameter>

    5. Save and close the file.

    6. Validate the modified file:: ./cogconfig.sh -config

      1. Set the path as shown for your operating system:

        • AIX: LIBPATH=Cognos_BI_Server_install_path/bin64

        • Linux: LD_LIBRARY_PATH=Cognos_BI_Server_install_path/bin64

        • Windows: PATH=Cognos_BI_Server_install_path/bin64;%PATH%

      2. Set JAVA_HOME to the WAS_install_path/java directory.

      3. Run the configuration script:

        • AIX or Linux: ./cogconfig.sh -config

        • Windows: cogconfig.bat -config

      4. Check the Cognos_Transformer_install_path/logs/cogconfig_response.csv file for a success message.

      You do not need to restart the Transformer component.


    Optional post-installation tasks

    Complete the post-installation tasks that are relevant to your deployment.


    Related tasks

  • Define valid administrator email addresses
  • Manage content moderation and flagged content
  • Change application URLs


    Add a node to a cluster

    Add a node to an existing cluster.

    You must already have a cluster with at least one member.

    Ensure installed IBM WAS Network Deployment (Application Server option) on the new node.

    If you are adding a node to a Search cluster, do not use these instructions. Instead, use the instructions in the Add an additional Search node to a cluster topic.

    Although the IBM Cognos Business Intelligence server is managed by the same Deployment Manager as IBM Connections, you cannot add that node to the Connections cluster.

    To add a node to a cluster:

    1. Add a node to the DM cell:

      1. Log on to the new node.

      2. Open a command prompt and change to the bin directory of the local WAS profile:

        app_server_root/profiles/profile_name/bin

        where profile_name is the name of the applicable WAS profile on this node.

      3. Run the addNode command to add this node to the DM cell: .

        addnode [dmgr_host] [dmgr_port] [-username uid] [-password pwd] [-localusername localuid] [-localpassword localpwd]

        where

        • dmgr_host is the host of the Deployment Manager

        • dmgr_port is the SOAP port of the deployment manager (the default is 8879)

        • uid and pwd are the DM administrator user name and password

        • localuid and localpwd are the user name and password for the WAS administrator of the node

      4. Open the addNode.log file and confirm that the node was successfully added to the DM cell. The file is stored in the following location:

        app_server_root/profiles/profile_name/log/addNode.log

    2. Copy the relevant JDBC files from the DM node to this node, placing them in the same location as the JDBC files on the DM. If, for example, you copied the db2jcc.jar file from the C:\IBM\SQLLIB directory on the DM, you must copy the same file to the C:\IBM\SQLLIB directory on this node. See the following table to determine which files to copy. See the following table to determine which files to copy:

      JDBC files

      Database type JDBC files
      DB2

      db2jcc.jar

      db2jcc_license_cu.jar sql

      Oracle

      ojdbc6.jar

      SQL Server

      sqljdbc4.jar

    3. Ensure that the shared folders that are used for the application content stores in the cluster are accessible from the new node: from the new node, try to access the shared directories.

    4. Add additional members to an existing IBM Connections cluster:

      1. Log on to the Deployment Manager Integration Solutions Console.

      2. Click Servers > Clusters > cluster_name > Cluster members > New. Set the following information about the new cluster member:

        Member name

        The name of the server instance that is created for the cluster. The DM creates a server instance with this name.

        Each member name in the same cluster must be unique. The Integration Solutions Console prevents you from reusing the same member name in a cluster.

        Select node

        The node where the server instance is located.

        Click Add Member to add this member to the cluster member list.

      3. Click Next to go to the summary page where you can examine detailed information about this cluster member. Click Finish to complete this step or click Previous to modify the settings.

      4. Click Save to save the configuration.

      5. Click Server > Servers > Clusters > cluster_name > Cluster members. In the member list, click the new member that you added in the previous step.

      6. On the detailed configuration page, click Ports to expand the port information of the member. Make a note of the WC_defaulthost and WC_defaulthost_secure ports.

        For example, the WC_defaulthost port is typically 9084, while the WC_defaulthost_secure port is typically 9447.

      7. Click Environment > Virtual Hosts > default_host > Host Aliases > New. Enter the following information for the host alias for the WC_defaulthost port:

        Host name

        The IP address or DNS host of the node where the new member is located.

        Port:

        The port for WC_defaulthost.

        For example, 9084.

        Click OK to complete the virtual host configuration.

      8. Click Save to save the configuration.

      9. Repeat the previous two substeps to add the host alias for the WC_defaulthost_secure port.

      10. Click System administration > Nodes.

      11. In the node list page, select all the nodes where the target cluster members are located and then click Synchronize.


    What to do next

    Configure IBM HTTP Server to connect to this node.

    Repeat this task for each new node to add to a cluster.

    (AIX or Linux only) If you installed the Search application on the new node, configure the path variables to point to that application. For more information, see the Copying Search conversion tools to local nodes topic.

    If you experience interoperability failure, you might be running two servers on the same host with the same name. This problem can cause the Search and News applications to fail. For more information, go to the NameNotFoundException from JNDI lookup operation web page.


    Configure a reverse caching proxy

    Configure a reverse proxy that directs all traffic to your IBM Connections deployment to a single server.

    This is an optional configuration. IBM recommends for optimal performance, especially if users are accessing IBM Connections from a wide area network (WAN).

    Install IBM WebSphere Edge Components which is supplied with WAS Network Deployment.

    You must also have completed the basic configuration of WebSphere Edge Components, set up a target backend server, and created an administrator account.

    The IBM WAS Edge components provide a caching proxy that you can use to optimize your deployment. Edge components are provided with the WAS Network Deployment software.

    A reverse proxy configuration intercepts browser requests, forwards them to the appropriate content host, caches the returned data, and delivers that data to the browser. The proxy delivers requests for the same content directly from the cache, which is much quicker than retrieving it again from the content host. Information can be cached depending on when it will expire, how large the cache should be, and when the information should be updated.

    This topic describes how to configure the Edge components to optimize the performance of IBM Connections.

    1. Open the ibmproxy.conf configuration file for the Edge components in a text editor. The file is stored in the following directory:

      • AIX or Linux: /etc/

      • Microsoft Windows:: C:\IBM\edge\cp\etc\

    2. Make the following edits to the file:

      1. In the SendRevProxyName Directive section, add or enable the following rule:

        SendRevProxyName yes

      2. In the PureProxy Directive section, add or enable the following rule:

        PureProxy off

      3. In the SSL Directives section, add or enable the following rules:

        SSLEnable On

        SSLCaching On

      4. In the Keyring Directive section, add or enable the following rules:

        KeyRing C:\ProxyKey\proxykey.kdb

        KeyRingStash C:\ProxyKey\proxykey.sth

      5. In the Mapping Rules section, add the following reverse pass rules:

        ReversePass http://httpserver/* http://proxyserver/*

        ReversePass https://httpserver/* https://proxyserver/*

        where httpserver is the host of the HTTP server. The HTTP server is usually IBM HTTP Server, but could be a load balancer or another proxy, depending on your deployment. proxyserver is the host of the proxy server.

        You can specify * in the URL (to indicate that all URLs for the server can be passed) only if IBM Connections is the only application installed on the server. Alternatively, you can use a more specific URL such as http://httpserver/connections/*. You can use more than one ReversePass rule if you need to specify different servers for each component.

      6. Also in the Mapping Rules section, add the following proxy rules:

        Proxy /* http://<httpserver>/* :80

        Proxy /* https://<httpserver>/* :443

      7. Set the CacheTimeMargin rule to zero seconds. When a document's expiry date is set to .soon. and soon is defined by the CacheTimeMargin rule, setting this rule to zero disables the calculation and forces all documents to be cached, regardless of their expiry date. This setting is required for Blogs caching to function properly; it does not negatively affect the other applications.

        CacheTimeMargin 0 seconds

      8. Prevent the validation of a cache object from sending multiple requests for the same resource to the backend server by setting the KeepExpired rule to on. An expired or stale copy of the resource will be returned for the brief time that the resource is being updated on the proxy.

        KeepExpired On

      9. In the Method Directives section, add the following methods:

        Enable CONNECT

        Enable PUT

        Enable DELETE

      10. Add the following rule to the CacheQueries Directives section:

          CacheQueries PUBLIC

      11. Configure the proxy to allow large file uploads by editing and uncommenting the LimitRequestBody directive:

          LimitRequestBody n M

        where n is the maximum file size in MB. For example: LimitRequestBody 50 M allows a file size of up to 50 MB.

    3. Save and close the ibmproxy.conf file.

    4. Update the dynamicHosts attribute in LotusConnections-config.xml to reflect the URL of the proxy server:

      <dynamicHosts enabled="true">         
          <host href="http://proxy.example.com" 
          ssl_href="https://proxy.example.com"/>     
      </dynamicHosts>
      
      

      The dynamic hosts settings does not affect interservice URLs. Therefore, even when the proxy server is enabled, IBM Connections still routes internal communication between the applications through their own interservice URLs. You can force this internal traffic to be routed over the proxy server by updating the interservice URLs to use the proxy server.

      Each href attribute in LotusConnections-config.xml is case-sensitive and must specify a fully-qualified domain name.

    5. Optional: Using iKeyman, extract certificates from IBM Connections and add them to the proxy server key DB:

      1. Open the IBM Connections kdb file and extract the certificates.

      2. Open the kdb file on the proxy server and add the certificates that you extracted from IBM Connections.

      For more information about iKeyman, go to the Import and exporting keys topic in the IBM HTTP Server information center.

    6. Restart the Edge server.


    Enable locked domains

    Assuming that you have completed the server setup previously described, to enable locked domains in IBM Connections, specify an additional atrribute in the LotusConnections-config.xml to ensure that only ConnectionsOpensocial application is mapped to the locked domain host.

    For added security, only the ConnectionsCommon.ear should be mapped to the locked host. Although no SSO tokens will be flowing from the host, this extra precaution limits exposure of your Connections infrastructure to potentially malicious gadgets.

    1. Add the new attribute to LotusConnections-config.xml :

      1. Start the wsadmin tool.

      2. Access the Connections configuration file:

        execfile("<$WAS_HOME>/profiles/<DMGR>/config/bin_lc_admin/ connectionsConfig.py")
        If you are prompted to specify which server to connect to, enter 1. This information is not used by the wsadmin client when you are making configuration changes.

      3. Check out the Connections configuration files :

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

        ...where:

        • working_directory is the temporary working directory where the configuration XML and XSD files are copied to. The files are kept in this working directory while you change them.

        • cell_name is the name of the WAS cell hosting the Connections application. This argument is case sensitive. If you do not know the cell name, you can determine it by entering the following command in the wsadmin command processor: print AdminControl.getCell(), for example:

          LCConfigService.checkOutConfig("/temp","foo01Cell01")

      4. From the temporary directory where you checked out the Connections configuration files to, open LotusConnections-config.xml in a text editor.

      5. Add this attribute to LotusConnections-config.xml.

        <sloc:serviceReference bootstrapHost="{locked.host.name}" 
                               bootstrapPort="2809" 
                               clusterName="" 
                               enabled="true" 
                               serviceName="opensocialLocked" 
                               ssl_enabled="true">
        
                <sloc:href>
        
                    <sloc:hrefPathPrefix>/connections/opensocial</sloc:hrefPathPrefix>
        
                    <sloc:static href="http://{locked.host.name.authority/http}" 
                                 ssl_href="https://{locked.host.name.authority/https}"/>
        
                    <sloc:interService href="https://{locked.host.name.authority/https}"/>
                </sloc:href>
        
            </sloc:serviceReference>
        

      6. Save LotusConnections-config.xml.

      7. Check in the changed configuration property files : LCConfigService.checkInConfig()

      8. After making updates, enter the following command to deploy the changes: synchAllNodes()

    2. Restart your Connections server.

    For example, this configuration could look like the following sample:

    <sloc:serviceReference bootstrapHost="hern120w.dyn.webahead.renovations.com" 
                           bootstrapPort="2809" 
                           clusterName="" 
                           enabled="true" 
                           serviceName="opensocialLocked" 
                           ssl_enabled="true">
            <sloc:href>
                <sloc:hrefPathPrefix>/connections/opensocial</sloc:hrefPathPrefix>
                <sloc:static href="http://hern120w.locked.com:9080" ssl_href="https://hernw120.locked.com:9443"/>
                <sloc:interService href="https://hern120w.dyn.webahead.renovations.com:9443"/>
            </sloc:href>
        </sloc:serviceReference>


    Separate Common and Widget Container applications from the News cluster

    Run the ConfigEngine script to configure IBM® Connections to separate critical user interface components to a new cluster. Doing so provides high availability and failover capability for the Connections Web user interface features.

    Install all of the applications you need, and make sure all your applications works correctly after installing. Understand these applications to better evaluate whether or not you want to separate them out to a dedicated cluster in your particular environment:

    • The Common application is responsible for serving up static content, including images, css, and javascript to all IBM Connections applications. Additionally as an OSGi container, it is the component that enables Social Mail.

    • The WidgetContainer application provides the ability to render gadgets, proxies requests to remote services, and handles REST requests. With the requirement to proxy requests, it has the potential to be very resource intensive.

    • After installation, if the cluster fails, not all Web user interface elements will render.
    To separate the Common and WidgetContainer application or both from the cluster where the News repository is located (referred to as the News cluster in this procedure):

    1. Add new nodes if needed as described in Installing IBM WAS.

    2. Stop all clusters in the IBM Connections deployment.

    3. On the deployment manager, open a command prompt, and then change to the following directory on the WebSphere® Application Server hosting the IBM Connections server:

      • On AIX® or Linux:

        connections_root/ConfigEngine

      • On Microsoft Windows::

        connections_root\ConfigEngine

    4. Enter the following command, if needed, to run the script that removes the Common application from the News cluster. In addition, the script removes the associated dynacache objects:

      • On AIX or Linux:.

        ./ConfigEngine.sh remove-common-ear 
                          -DWasUserid=<was_admin_username> 
                          -DWasPassword=<was_admin_password> > /tmp/remove-common-ear.log 2>&1

      • On Microsoft Windows::

        ConfigEngine.bat remove-common-ear 
                         -DWasUserid=<was_admin_username> 
                         -DWasPassword=<was_admin_password> > C:\remove-common-ear.log 2>&1

      For example, on the Microsoft Windows operating system, you would enter the following command:

      ConfigEngine.bat remove-common-ear 
                       -DWasUserid=wasadmin 
                       -DWasPassword=yourpassword > C:\remove-common-ear.log 2>&1

    5. Check for a success message in the log file.

    6. Enter the following command, if needed, to run the script that removes the WidgetContainer application from the News cluster. In addition, the script removes the associated dynacache objects:

      • AIX or Linux:

        ./ConfigEngine.sh remove-widgetcontainer-ear 
                          -DWasUserid=<was_admin_username> 
                          -DWasPassword=<was_admin_password> > /tmp/remove-widgetcontainer-ear.log 2>&1 

      • Microsoft Windows::

        ConfigEngine.bat remove-widgetcontainer-ear 
                         -DWasUserid=<was_admin_username> 
                         -DWasPassword=<was_admin_password> > C:\remove-widgetcontainer-ear.log 2>&1

      For example, on the Microsoft Windows operating system, you would enter the following command:

      ConfigEngine.bat remove-widgetcontainer-ear 
                       -DWasUserid=wasadmin 
                       -DWasPassword=yourpassword > C:\remove-widgetcontainer-ear.log 2>&1

    7. Check for a success message in the log file.

    8. Change to the ./properties directory to open and edit the wkplc_comp.properties file according to the following settings for separating out Common or WidgetContainer or both:

      Property values for commonear

      Property Name Description
      commonear.ClusterName Desired cluster name for Common.
      commonear.FirstNodeName Name of first node of the cluster.
      commonear.SecondaryNodesNames Comma-delimited list of secondary node names.
      commonear.<FirstNodeName>.ServerName Name of the server on the first node, note that the <FirstNodeName> needs to be an actual name.
      commonear.<SecondaryNodesNames1>.ServerName Name of the server on the secondary node 1, note that the <SecondaryNodesNames1> needs to be an actual name.
      ... ...
      commonear.<SecondaryNodesNamesN>.ServerName Name of the server on the secondary node n, note that the <SecondaryNodesNamesN> needs to be an actual name.

      Property values for the widgetcontainer

      Property Description
      widgetcontainer.ClusterName Desired cluster name for the WidgetContainer.
      widgetcontainer.FirstNodeName Name of first node of the cluster.
      widgetcontainer.SecondaryNodesNames Comma-delimited list of secondary node names.
      widgetcontainer.<FirstNodeName>.ServerName Name of the server on the first node, note that the <FirstNodeName> needs to be an actual name.
      widgetcontainer.<SecondaryNodesNames1>.ServerName Name of the server on the secondary node 1, note that the <SecondaryNodesNames1> needs to be an actual name.
      ... ...
      widgetcontainer.<SecondaryNodesNamesN>.ServerName Name of the server on the secondary node n, note that the <SecondaryNodesNamesN> needs to be an actual name.

      Ensure the server name(s) selected is/are not already in use.

    9. Enter the following command, if needed, to run the script that creates a new cluster and deploys the Common application onto it. In addition, the script will create associated dynacache objects, set the cluster as bus member of the ConnectionsBus, and update the cluster name in the LotusConnections-config.xml for the Common application's service entry:

      • AIX or Linux:

        ./ConfigEngine.sh install-common-ear -DWasUserid=<was_admin_username> -DWasPassword=<was_admin_password> > /tmp/install-common-ear.log 2>&1

      • Microsoft Windows::

        ConfigEngine.bat install-common-ear -DWasUserid=<was_admin_username> -DWasPassword=<was_admin_password> > C:\install-common-ear.log 2>&1

      For example, on the Microsoft Windows operating system, you would enter the following command:

      ConfigEngine.bat install-common-ear -DWasUserid=wasadmin -DWasPassword=yourpassword > C:\install-common-ear.log 2>&1

    10. Check for a success message in the log file.

    11. Enter the following command, if needed, to run the script that creates a new cluster and deploys the WidgetContainer application onto it. In addition, the script will create associated dynacache objects, set the cluster as bus member of the ConnectionsBus, and update the cluster name in the LotusConnections-config.xml for the WidgetContainer application's service entry:

      • AIX or Linux:

        ./ConfigEngine.sh install-widgetcontainer-ear -DWasUserid=<was_admin_username> -DWasPassword=<was_admin_password> > /tmp/install-widgetcontainer-ear.log 2>&1

      • Microsoft Windows::

        ConfigEngine.bat install-widgetcontainer-ear -DWasUserid=<was_admin_username> -DWasPassword=<was_admin_password> > C:\install-widgetcontainer-ear.log 2>&1

      For example, on the Microsoft Windows operating system, you would enter the following command:

      ConfigEngine.bat install-widgetcontainer-ear -DWasUserid=wasadmin -DWasPassword=yourpassword > C:\install-widgetcontainer-ear.log 2>&1

    12. Check for a success message in the log file.

    13. Configure IHS to refresh the application mapping according to the instructions contained in the topic Mapping applications to IBM HTTP Server.

      For the users who have not yet deployed IHS, the ports for the servers that host the Common (webresources ) and WidgetContainer (opensocial) applications (as specified in the <profile_root>/config/cells/<cell_name>/LotusConnections-config/LotusConnections-config.xml file) remain the old ports and need to be updated manually to the new ports.

      The new http port and secure http port can be found in <LC_HOME>/<new_server>.properties. For example, this entry in LotusConnections-config.xml is for Common:

      <sloc:serviceReference clusterName="CommonCluster" enabled="true" serviceName="webresources" ssl_enabled="true">
      <sloc:href>
      <sloc:hrefPathPrefix>/connections/resources</sloc:hrefPathPrefix>
      <sloc:static href="http://yourserver.renovations.com:9081" ssl_href="https://yourserver.renovations.com:9444"/>
      <sloc:interService href="https://yourserver.renovations.com:9444"/>
      </sloc:href>
      </sloc:serviceReference>

    14. Restart Connections.

    15. Restart IHS.


    Configure the custom ID attribute for users or groups

    Configure IBM Connections to use custom ID attributes to identify users and groups in the LDAP directory.

    • If you specified a single ID attribute for both users and groups, you don't need to complete this task. This task is required only if you specified a custom ID attribute for users or groups in the Specifying a custom ID for users or groups topic.

    • Ensure that you have completed the steps to specify different ID attributes for users and groups in the Specifying a custom ID for users or groups topic.

    You can change the default setting to use a custom ID to identify users and groups in the directory. To configure IBM Connections to use the custom ID attribute that you specified earlier:

    1. Add the new attribute to LotusConnections-config.xml. To do so:

      1. Start the wsadmin tool.

      2. Use the following command to access the IBM Connections configuration file:

        execfile("<$WAS_HOME>/profiles/<DMGR>/config/bin_lc_admin/ connectionsConfig.py")

        If you are prompted to specify which server to connect to, enter 1. This information is not used by the wsadmin client when you are making configuration changes.

      3. Check out the IBM Connections configuration files : LCConfigService.checkOutConfig("/working_directory", "cell_name")

        where

        • working_directory is the temporary working directory to which the configuration XML and XSD files are copied. The files are kept in this working directory while you change them.

        • cell_name is the name of the IBM WAS cell hosting the IBM Connections application. This argument is case sensitive. If you do not know the cell name, you can determine it by entering the following command in the wsadmin command processor:

          print AdminControl.getCell()

        For example:

        LCConfigService.checkOutConfig("/temp","foo01Cell01")

      4. From the temporary directory to which you checked out the IBM Connections configuration files, open LotusConnections-config.xml in a text editor.

      5. Add the new custom properties to LotusConnections-config.xml. For example:

        <sloc:serviceReference serviceName="directory"
        ...
        custom_user_id_attribute="customUserID"
        custom_group_id_attribute="customGroupID"/> 

      6. Save LotusConnections-config.xml.

      7. Check in the changed configuration property files using the following command:LCConfigService.checkInConfig()

      8. After making updates, enter the following command to deploy the changes: synchAllNodes()

    2. Stop and restart the WAS instance hosting IBM Connections.


    Configure Files and Wikis downloading

    You can make downloading files from the Files and Wikis applications much more efficient by configuring an IBM HTTP Server to handle most of the download instead of the WAS. It is strongly recommended that you configure production deployments this way.

    Install an IBM HTTP Server in your WAS environment. See the topic Configuring IBM HTTP Server for information.

    In network deployments, Files and Wikis data must be stored on a shared file system, as described in the topic Deployment options. All IBM HTTP Servers in the deployment must have read access to the files, and all WASs must have write access.

    If you choose not to configure the IBM HTTP Server to download files, configure the WAS to transfer data synchronously instead of asynchronously in order to avoid errors related to using too much memory. See the tech note Excessive native memory use in IBM WAS for instructions.

    In the default deployment with an IBM HTTP Server, file download requests are passed from the IBM HTTP Server to the WAS. The WAS accesses the binary files in a data directory on the file system and returns them to the IBM HTTP Server, which passes them to the browser.

    This is inefficient in deployments where large numbers of users are downloading files, partly because WAS has a limited thread pool that is tuned for short-lived transactions, and optimized for J2EE applications and not file downloads. In this environment it is possible that you would need to create a cluster to handle downloads, especially if you have slow transfer rates, for example caused by people in different geographies downloading 2MB at 2KB per second. This would cause problems, such as making it impractical to properly tune the thread pool.

    Configure the IBM HTTP Server to download the binary files instead makes downloading far more efficient, since IBM HTTP Server is designed specifically for serving files. This leaves WAS to perform tasks such as security checking and cache validation while leaving downloading to the IBM HTTP Server.

    To configure this environment, you install an add-on module to the IBM HTTP Server. As in typical deployments, download requests are passed from the IBM HTTP Server to the WAS. But instead of responding with the binary data, the WAS only adds a special header to its response. The add-on module recognizes the header and directs the IBM HTTP Server to download the binary data.

    This configuration requires making the Files and Wikis data directories available to the IBM HTTP Server using an alias. This creates a security concern, so configure the access control at the IBM HTTP Server level. After you configure security, access to the Files and Wikis data directories is denied unless a specific environment variable is set. Requests to the Files and Wikis applications on WAS are then configured to set the variable. In other words, only requests passing through WAS are able to access the data directory, with WAS acting as the authorizer.

    If you use the add-on module you must use an IBM HTTP Server address for the IBM Connections "inter-service" URL. See the topic Troubleshoot inter-server communication for information on setting an inter-service URL.

    Do the following tasks to configure IBM HTTP Server downloading:

    1. Install the IBM Connections Files or Wikis applications.

    2. On the server installed IBM Connections on, navigate to the connections_root/plugins/ihs/mod_ibm_local_redirect/platform directory to find the module file (mod_ibm_local_redirect.so) appropriate to your IBM HTTP Server operating system. These are the platform directories:

      • /aix_ppc32-ap20

      • /aix_ppc32-ap22

      • /linux390-ap20

      • /linux390-ap22

      • /linux_ia32-ap20

      • /linux_ia32-ap22

      • /win_ia32-ap20

      • /win_ia32-ap22

      For example, on Linux computers:

      /IBM/Connections/plugins/ihs/mod_ibm_local_redirect/linux_ia32-ap20/mod_ibm_local_redirect.so

      • You can use these whether you installed IBM HTTP Server from the 32-bit or 64-bit supplemental package on all supported platforms, as the IBM HTTP Server process is 32-bits in both cases and requires 32-bit modules. See this support document for more information on this topic. For IBM HTTP Server 6.1.x releases, use the ap20 versions; for version 7.x releases use the ap22 version.

    3. Copy the module to the appropriate directory location on your IBM HTTP Server. By default, modules are located in the ibm_http_server_root/modules directory.

    4. Open the IBM HTTP Server httpd.conf file (in the ibm_http_server_root/conf directory by default) and add the following statements to load the ibm_local_redirect_module, and the required mod_env environment variable module:

      • LoadModule ibm_local_redirect_module path_to_module/mod_ibm_local_redirect.so
        For example: LoadModule ibm_local_redirect_module modules/mod_ibm_local_redirect.so

      • LoadModule env_module path_to_mod_env/mod_env.so

        For example: LoadModule env_module modules/mod_env.so

      By default, the mod_env module is installed in the /modules directory. It might already be loaded, or it might be a commented-out line that you can remove comments from to load.

    5. Do one of the following, according to your IBM HTTP Server operating system:

      • Microsoft Windows:: Give the IBM HTTP Server user READ access to the data directory root. For optimal security, do not give the user WRITE access.

      • AIX and Linux: Give the IBM HTTP Server user READ and EXECUTE access to the data directory root.

      You can find the data_directory_root path in the files-config.xml or wikis-config.xml file, in the file.storage.rootDirectory attribute. This attribute will contain either the path itself, or a WAS variable whose value is the path. If it contains a variable, you can find the path by opening the WAS console, clicking Environment > WebSphere Variables, and finding the variable.

      For example, if the element's value is ${FILES_CONTENT_DIR}, find FILES_CONTENT_DIR in the console to find the path. See the topic Changing configuration property values for information on opening the files-config.xml or wikis-config.xml file.

    6. On all virtual hosts in the same domain as Files or Wikis, including both HTTP and HTTPS, do the following to expose the data directory root:

      1. Open the httpd.conf file.

      2. Add the following to create an alias for the data directory root:

        Alias /<alias> "data_directory_root"
        For example, if the Files data directory root is /opt/IBM/Connections/Data/Files (on Linux), the following line creates the alias files_content for that directory:

        Alias /files_content /opt/IBM/Connections/Data/Files

      • Do not use the application context root (/files or /wikis by default) as part of the alias, but you can use any other value. For example, use /files_content, but not /files/content. The application context root is the last part of the application URL, for example the application context root of a Files application with the URL www.my.enterprise.com/files is /files. You can see the value in the files.href.prefix property in LotusConnections-config.xml. See the topic Changing common configuration property values for information on opening the configuration file.

      • Include quotes around the file path on Windows computers, and always use forward slashes, for example: "C:/IBM/Connections/Data/Files"

      • The example assumes the HTTP server is on the same computer as IBM Connections. If the HTTP server is on a different computer (as is common), specify the data directory using the network share path appropriate to your environment. For example, use a UNC network share format such as: Alias /files_content "//<server>/<sharename>/Files"

    7. In the httpd.conf file, add these lines after the lines you added in Step 6, to make the alias more secure:

      <Directory "data_directory_root">
       Order Deny,Allow
       Deny from all
       Allow from env=REDIRECT_FILES or WIKIS_CONTENT
       </Directory>
      For example:

      <Directory "/opt/IBM/Connections/Data/Files">
       Order Deny,Allow
       Deny from all
       Allow from env=REDIRECT_FILES_CONTENT
       </Directory>

      • This secures the data by only allowing requests where REDIRECT_FILES_CONTENT or REDIRECT_WIKIS_CONTENT is specified. Use any environment variable you want, as long as it is not already in the IBM HTTP Server environment.

      • The example assumes the HTTP server is on the same computer as IBM Connections. If the HTTP server is on a different computer (as is common), specify the data directory using the network share path appropriate to your environment.

        For example, use a UNC network share format such as: <Directory "//<server>/<sharename>/Files">

    8. In the httpd.conf file, add these lines after the lines you added in Step 7, to enable the module for Files or Wikis:

      <Location application_context_root>
       IBMLocalRedirect On
       IBMLocalRedirectKeepHeaders X-LConn-Auth,Cache-Control,Content-Type,Content-Disposition,
      Last-Modified,ETag,Content-Language,Set-Cookie
       SetEnv FILES or WIKIS_CONTENT true
      </Location>
      For example:

      <Location /files>
       IBMLocalRedirect On
       IBMLocalRedirectKeepHeaders X-LConn-Auth,Cache-Control,Content-Type,Content-Disposition,
      Last-Modified,ETag,Content-Language,Set-Cookie
       SetEnv FILES_CONTENT true
      </Location>

      • The application_context_root value is the last part of the application URL, for example the application context root of a Files application with the URL www.my.enterprise.com/files is /files. This is /files or /wikis by default, but can be changed during post-installation steps. You can see the value in the files.href.prefix property in LotusConnections-config.xml. See the topic Changing common configuration property values for information on opening the configuration file.

      • Specify IBMLocalRedirectKeepHeaders instructs the plugin to keep the specified headers from the application server, instead of recomputing them. This is critical because the applications set such directives as the content-type and content-disposition that the IBM HTTP Server would not know about.

      • If your environment requires additional headers (for example for a proxy cache), you can add them to the comma-delimited IBMLocalRedirectKeepHeaders list to ensure that the module retains them during redirection.

      • Header names must be comma-delimited with no space before or after commas. Also, all header names must be on one line regardless of how many there are.

      • The SetEnv value sets the token that the data directory requires to be accessible. It must match the value after REDIRECT_ that you set in Allow from env= in Step 7.

        For example, if you set REDIRECT_FILES_CONTENT in Step 7, this value must be SetEnv FILES_CONTENT true.

      • You can think of this as a lock and key mechanism: only requests that go through the Files or Wikis applications get a key, and the applications ensure that only authorized users can unlock particular files.

    9. Do the following to test that the IBM HTTP Server is configured properly and securely:

      1. Restart the IBM HTTP Server. Make sure it loads properly and there are no log errors about loading modules or configuration. If there are problems, make sure the load module and configuration directives do not contain typos.

      2. Try to access the alias directory directly at http/https:host/alias and make sure you are denied permission. If you can access the directory, make sure that the Order Deny, Allow; Deny from All; Allow from env from Step 7 are all there.

      3. Access the application and download a file to make sure it functions. The module is not yet enabled.

    10. Check out the files-config.xml or wikis-config.xml file using the steps in the topic Changing configuration property values, and specify the following property attributes:

      <download>
      <modIBMLocalRedirect enabled="true" hrefPathPrefix="/alias" />
      </download>

      The alias must have a forward slash in front of it.

    11. Restart Files or Wikis.

    12. Download a file to make sure it works.

    13. Do the following to test whether the IBM HTTP Server is downloading the files:

      1. Open the httpd.conf file and add # characters to comment out the last line in the <Directory> element, for example:

        <Directory "data_directory_root">
         Order Deny,Allow
         Deny from all
         #Allow from env=REDIRECT_FILES or WIKIS_CONTENT
        </Directory>
        For example:

        <Directory "C:\IBM\Connections\Data\Files">
         Order Deny,Allow
         Deny from all
         #Allow from env=REDIRECT_FILES_CONTENT
        </Directory>

      2. Save the file.

      3. Try to download a file from Files or Wikis. You should be denied. Test over both HTTP and HTTPS protocols (if HTTPS is enabled).

      4. Open the httpd.conf file and remove the # characters from the last line specified in Step a.

      Check the standard IBM HTTP Server error and request logs for any problems.


    What to do next

    • If you get a permission denied error trying to download a file, IBM HTTP Server might not have access to the content. You can temporarily disable security on the directory, and ensure you can access it directly first, then re-enable security. Note that you can tell if WebSphere or IBM HTTP Server is encountering an issue by the error page displayed, and by the path. If IBM HTTP Server is having a problem with the module invoked, the path will include /<alias>.

    • If you get log errors about loading the module, make sure that it is only loaded once, that you have selected the correct binary, and that you are on a supported platform.

    • If it works for HTTP but not HTTPS (or vice versa), make sure that the configuration lines are in a global context or in each virtual host, depending on your setup.
  • Files configuration properties
  • Wikis configuration properties


    Uninstall IBM Connections

    Uninstall IBM Connections.


    Remove applications

    Remove selected applications from IBM Connections.

    If you no longer need to keep certain applications, you can remove them from your deployment. You cannot remove core applications such as Home page, News, and Search.

    To remove selected applications from IBM Connections, complete the following steps:

    1. Start the IBM WAS Deployment Manager.

    2. Stop all instances of WAS, including node agents, in your deployment.

    3. Open a command prompt and change to the IM_root/eclipse directory.

    4. Start the installation wizard by opening the following file:

      • AIX or Linux:

        ./launcher

      • Windows:

        launcher.exe

    5. Click Modify.

    6. Select IBM Connections and click Next.

    7. Clear the check boxes of the applications that you want to remove.

    8. Click Next.

    9. Enter the details of your WAS environment.

    10. Click Next.

    11. In the Summary page, verify that the details are correct.

    12. Click Modify to begin removing applications.

    13. When the process is complete, restart the Deployment Manager.

    14. Restart all instances of WAS, including node agents.

    15. Synchronize the nodes.

    16. To check the details of the procedure, open the log files in connections_root/logs. Each IBM Connections application that you uninstalled has a log file that uses the following naming format: application_nameUninstall.log, where application_name is the name of an IBM Connections application.


    Results

    You removed selected IBM Connections applications.


    Uninstall a deployment

    Uninstall a deployment of IBM Connections.


    About this task

    To uninstall IBM Connections, complete the following steps:

    1. Start the IBM WAS Deployment Manager.

    2. Stop all instances of WAS, including node agents, in your deployment.

    3. Open a command prompt and change to the IM_root/eclipse directory.

    4. Start the installation wizard by opening the following file:

      • AIX or Linux:

        ./launcher

      • Windows:

        launcher.exe

    5. Click Uninstall.

    6. Select the IBM Connections package group and click Next.

    7. Click Uninstall to begin uninstalling.

    8. When the process is complete, restart the Deployment Manager.

    9. Restart all instances of WAS, including node agents.

    10. Synchronize the nodes.

    11. To check the details of the procedure, open the log files in connections_root/logs. Each IBM Connections application that you uninstalled has a log file that uses the following naming format: application_nameUninstall.log, where application_name is the name of an IBM Connections application.

    12. Optional: If you plan to reinstall IBM Connections, remove the following files:

      Except where noted, remove these files from the system that hosts the Deployment Manager.

      Because some of these files might be used by other programs, it is possible that you are not allowed to remove all of the following files.

      1. IBM Connections installation files: connections_root

        If you did not install IBM Connections in the default directory, delete the directory where you installed the product.

      2. IBM Connections shared data: Delete the directories specified for shared data when you installed IBM Connections.

      3. IBM Connections local data: On each node, delete the directories specified for local data when you installed IBM Connections.

      4. IBM Connections configuration files: Delete the profile_root/config/cells/cell_name/LotusConnections-config directory, where cell_name is the name of your WAS cell.

      5. If it is present, delete the registry.xml file from the profile_root/config/cells/cell_name directory.

      6. Delete all .py files from the /opt/IBM/WebSphere/AppServer/profiles/profile_name/bin directory on the deployment manager server.

      Delete IBM Connections data files makes the original deployment unrecoverable. If you plan to reinstall IBM Connections and use your old data, do not delete the data files.

      You do not need to remove IBM Installation Manager files. These files might be associated with other IBM applications.


    Results

    You uninstalled IBM Connections.


    Uninstall in console mode

    Uninstall IBM Connections in console mode. This method is convenient if you cannot or do not want to use the graphical mode. Use console mode to uninstall the product in a non-graphical environment. This mode is useful when you have to uninstall IBM Connections on a system that does not have a video card.

    In steps where you enter custom information, such as server details, you can type P at any time to return to the previous input choice in that step. However, you cannot type P to return to a previous step.

    Uninstall IBM Connections uses IBM Installation Manager to manage the installation process.

    To uninstall IBM Connections in console mode:

    1. Start the IBM WAS Deployment Manager.

    2. Stop all instances of WAS, including node agents, in your deployment.

    3. Open a command prompt and change to the IM_root/eclipse/tools

    4. Start the installation wizard by opening the following file:

      • AIX or Linux: ./imcl -c

      • Windows: imcl.exe -c

    5. Type P.

    6. Select the IBM Connections package group and then type N to proceed.

    7. Select the applications to remove and then type N to proceed.

    8. Type U to start removing applications.

    9. To check the details of the procedure, open the log files in connections_root/logs. Each IBM Connections application that you uninstalled has a log file that uses the following naming format: application_nameUninstall.log, where application_name is the name of an IBM Connections application.

    10. Optional: If you plan to reinstall IBM Connections, remove the following files:

      Except where noted, remove these files from the system that hosts the Deployment Manager.

      Because some of these files might be used by other programs, it is possible that you are not allowed to remove all of the following files.

      1. IBM Connections installation files: connections_root

        If you did not install IBM Connections in the default directory, delete the directory where you installed the product.

      2. IBM Connections shared data: Delete the directories specified for shared data when you installed IBM Connections.

      3. IBM Connections local data: On each node, delete the directories specified for local data when you installed IBM Connections.

      4. IBM Connections configuration files: Delete the profile_root/config/cells/cell_name/LotusConnections-config directory, where cell_name is the name of your WAS cell.

      5. If it is present, delete the registry.xml file from the profile_root/config/cells/cell_name directory.

      6. Delete all .py files from the /opt/IBM/WebSphere/AppServer/profiles/profile_name/bin directory on the deployment manager server.

      Delete IBM Connections data files makes the original deployment unrecoverable. If you plan to reinstall IBM Connections and use your old data, do not delete the data files.

      You do not need to remove IBM Installation Manager files. These files might be associated with other IBM applications.


    Results

    You uninstalled IBM Connections.


    Uninstall: delete DBs with the DB wizard

    Use the DB wizard to delete DBs. To delete DBs with the DB wizard, complete the following steps:

    1. Log in as the DB administrator, using the account that you created when you installed the DB.

    2. From the IBM Connections wizards directory, run the following script file to launch the wizard:

      • AIX:

        ./dbWizard.sh 

      • Linux:

        ./dbWizard.sh

      • Microsoft Windows::

        dbWizard.bat 

    3. On the Welcome panel, click Launch Information Center to open the IBM Connections product documentation in a browser window. Click Next to continue.

    4. Select the option to delete a DB, and click Next.

    5. Specify the relevant DB information, and then click Next:

      1. Select a DB type.

      2. Select the location of the DB.

        For an Oracle DB on Windows 2008 64-bit, enter the value of the ORACLE_HOME registry key.

        For example, the key for Oracle 11g on Windows 2008 64-bit is HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE\Key_OraDb11g_home1 and the value is C:\app\Administrator\product\11.2.0\dbhome_1.

      3. Specify a DB instance.

        The DB instance that you specify must already exist on your system.

    6. Select the application DBs to delete and click Next.

      Application DBs that are not installed are greyed out.

    7. Review the Pre-Configuration Task Summary to ensure that the values you entered on previous panels are correct. If you want to make a change, click Back to edit the value. Click Delete to begin deleting DBs.

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


    Uninstall DBs in silent mode

    Remove DBs with the DB wizard in silent mode.

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

    To create a response file, run the wizard in standard mode and specify that you would like to create a response file. You can modify the existing response file or create your own, using a text editor. To remove DBs in silent mode, complete the following steps:

    1. (DB2 on Windows 2008 64-bit.) On Windows 2008, you must perform DB2 administration tasks with full administrator privileges.

      1. Logged in as the instance owner, open a command prompt and change to the DB2 bin directory. For example: C:\IBM\SQLLIB\BIN.

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

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

    3. Launch the wizard:

      • AIX: ./dbWizard.sh -silent response_file

      • Linux: ./dbWizard.sh -silent response_file

      • Microsoft Windows:: dbWizard.bat -silent response_file

      where response_file is the file path to the response file.

      If the path to the response_file contains a space, this parameter must be enclosed in double quotation marks (").


    What to do next

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


    Uninstall: Manually drop DBs

    After uninstalling an IBM Connections application, you can drop any related DBs by using the DB wizard or by following this manual procedure.

    • Ensure that all IBM Connections DB instances are running.

    • Disconnect any open applications from the DB.

    • If the DB server and IBM WAS are on different systems, copy the DB scripts to the system that hosts the DB server.
    If you prefer not to use the DB wizard, use this procedure to manually drop DB2, Oracle, or Microsoft SQL Server DBs.

    The Wizards directory is located in the IBM Connections set-up directory or installation media.

    Complete the following steps for your DB type:

    • DB2:

      1. Log in to the DB server with an authorized administrator account.

        The default administrator account is db2inst1 on AIX and Linux, and db2admin on Windows.

      2. Run the following command for Communities:

        db2 -td@ -vf calendar-dropDb.sql

      3. For Home page and Profiles, run the following command :

        db2 -tvf dropDb.sql

      4. Run the following command for all the other applications:

        db2 -td@ -vf dropDb.sql

        The SQL scripts are located in the following directory:

        • AIX or Linux: Wizard/connections.sql/application_subdirectory/db2

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

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

        • Microsoft Windows:: Wizards\connections.sql\application_subdirectory\db2

        where application_subdirectory is the directory for an IBM Connections application.

    • Oracle:

      1. Log in to the DB server with an authorized administrator account.

        The default administrator account is oracle.

      2. Set the ORACLE_SID.

      3. Run SQL Plus by typing the following command:

        sqlplus /NOLOG

      4. Set the following command to log in as an administrator with the sysdba role:

        connect as sysdba

      5. Run the following command for Communities:

        • AIX or Linux:@Wizards/connections.sql/communities/oracle/calendar-dropDb.sql

        • Windows:@Wizards\connections.sql\communities\oracle\calendar-dropDb.sql

      6. Run the following command for the other applications:

        • AIX or Linux:@Wizards/connections.sql/application_subdirectory/oracle/dropDb.sql

        • Windows:@Wizards\connections.sql\application_subdirectory\oracle\dropDb.sql

        where application_subdirectory is the directory for an IBM Connections application.

    • SQL Server:

      1. Open a command prompt.

      2. Run the following command for Communities:

        • sqlcmd -U <admin_user> -P admin_password -i Wizards\connections.sql\communities\sqlserver\calendar-dropDb.sql

        • If your SQL Server DB has multiple instances, add the following line as the first parameter of the command:

          -S sqlserver_server_name\sqlserver_server_instance_name

          where sqlserver_server_name is the name of the SQL Server DB, and sqlserver_server_instance_name is the name of each DB instance.

      3. Run the following command for the other applications:

        sqlcmd -U <admin_user> -P admin_password -i Wizards\connections.sql\application_subdirectory\sqlserver\dropDb.sql

        where application_subdirectory is the directory for an IBM Connections application.


    Reverting Common and WidgetContainer Applications for Uninstallation

    The IBM Connections Installation Manager program requires that you revert the Common and WidgetContainer applications the News cluster for uninstallation if you previously separated those applications to their own clusters.

    1. Stop all clusters in the Connections deployment.

    2. On the deployment manager, open a command prompt, and then change to the following directory on the WebSphere® Application Server hosting the IBM Connections server:

      • On AIX or Linux:

        /opt/IBM/Connections/ConfigEngine

      • On Microsoft Windows::

        C:\IBM\Connections\ConfigEngine

    3. Enter the following command to run the script that reverts the Common application to the News cluster:

      • On AIX or Linux:

        ./ConfigEngine.sh revert-common-ear -DWasUserid=<was_admin_username> -DWasPassword=<was_admin_password> > /tmp/revert-common-ear.log 2>&1

      • On Microsoft Windows::

        ConfigEngine.bat revert-common-ear -DWasUserid=<was_admin_username> -DWasPassword=<was_admin_password> > C:\revert-common-ear.log 2>&1

      For example, on the Microsoft Windows operating system, you would enter the following command:

      ConfigEngine.bat revert-common-ear -DWasUserid=wasadmin -DWasPassword=yourpassword > C:\revert-common-ear.log 2>&1

    4. Enter the following command to run the script that reverts the WidgetContainer application to the News cluster:

      • On AIX or Linux:

        ./ConfigEngine.sh revert-widgetcontainer-ear 
                          -DWasUserid=<was_admin_username> 
                          -DWasPassword=<was_admin_password> > /tmp/revert-widgetcontainer-ear.log 2>&1

      • On Windows:

        ConfigEngine.bat revert-shindig-ear 
                         -DWasUserid=<was_admin_username> 
                         -DWasPassword=<was_admin_password> > C:\revert-shindig-ear.log 2>&1

      For example, on the Microsoft Windows operating system, you would enter the following command:

      ConfigEngine.bat revert-widgetcontainer-ear 
                       -DWasUserid=wasadmin 
                       -DWasPassword=yourpassword > C:\revert-widgetcontainer-ear.log 2>&1 

    5. Proceed with uninstallation.


    Update and migrating

    Update or migrate IBM Connections to the latest point release.


    About migrating

    Migrate IBM Connections version 3.0.1 to version 4.0, using built-in wizards and scripts to move your data, configuration settings, and DBs.

    This topic applies to all releases of version 3.0.1.

    If you have any customized header, footer, theme, or CSS files, you might need to update those customizations manually.


    About updating

    Update IBM Connections 4.0 with the latest interim fixes or fix packs.

    After updating, you might need to reconfigure IBM HTTP Server.


    Prepare IBM Connections for maintenance

    When you migrate or update IBM Connections, inform your users about any planned outages.

    If you are migrating from version 3.0.1, ensure that your systems meet the requirements for IBM Connections 4.0. Add Location and ErrorDocument stanzas to the httpd.conf file before migrating. When your deployment is offline, users are directed to a maintenance page.

    To bring down the product in preparation for updating or migrating:

    1. Inform users of the planned outage with details of when the maintenance work begins and how long it is schedule to last. You can send email notifications to community members or post a message to an area of the product that is used to provide site status information.

    2. Perform one of the following steps:

      • Stop the IBM HTTP Server . ensure that no other applications are using the IBM HTTP Server.

      • Keep the webserver running but prevent user-access to the deployment during the migration or update. To accomplish this, set up a maintenance page and create a rewrite rule in the httpd.conf configuration file for the IBM HTTP Server to redirect requests for IBM Connections:

        1. Create an HTML document notifying users of the server maintenance window. The maintenance page can inform users that IBM Connections is temporarily unavailable because of scheduled maintenance work. Point to the maintenance page by using these ErrorDocument statements:

          ErrorDocument 401 /upgrading.htm

          ErrorDocument 403 /upgrading.htm

        2. Add the following element to the httpd.conf file to block all non-authorized IP addresses from reaching the server and to send the user to the upgrading.html page:

          <Location / >

          Order Deny,Allow

          Deny from all

          Allow from your.ip.address>

          Allow from ip.address.of.each.machine.in.deployment

          </Location>

          You must have an Allow element for every instance of WAS in your deployment.


    What to do next

    When the migration or update is complete, remove the Location and ErrorDocument stanzas from the httpd.conf file.


    Back up IBM Connections

    Before migrating or updating IBM Connections, back up your DBs and applications. Follow these steps to back up your IBM Connections deployment. You can use this back-up to restore your existing deployment if the update or migration fails. This procedure backs up your entire deployment; you cannot use it to back up individual applications within IBM Connections.

    1. Stop the IBM WAS instances that are hosting IBM Connections.

    2. Use native DB tools, back up the DBs. If the update or migration fails, use this backup to restore the DBs.

    3. Back up the WAS Deployment Manager profile directory: profile_root/Dmgr01. For example: D:\WebSphere\AppServer\profiles\dmgr.

    4. Back up your IBM Connections deployment.

      1. Create a back-up of the IBM Connections installation directory: connections_root.

      2. Create a back-up of the WAS profile directory: profile_root

        If IBM Connections applications are deployed on separate profiles, archive each profile.

      3. Create a back-up of the profileRegistry.xml file, located under app_server_root/properties.

      4. Back up the local and shared data directories:

    5. Back up the Shared Resources directory:

    6. Optional: Back up the IBM Installation Manager data directory:

      This step is necessary only if you are planning an in-place migration of IBM Connections; that is, where you use the same systems to host the new deployment.

      • AIX or Linux: /var/ibm/InstallationManager

      • AIX or Linux (non-root user): /home/user/var/ibm/Installation Manager

        where user is the account name of the non-root user.

      • Windows: C:\ProgramData\IBM\Installation Manager

    7. Back up any customized configuration files.


    Save your customizations

    Before updating or migrating IBM Connections, back up and make notes of your customizations.

    Only some of the customizations that you made to IBM Connections 3.0.1 application files and custom fields are preserved by the migration tool (the lc-export and lc-import commands). Ensure that you reapply your customizations after migration.


    Customized files and themes

    The update and migration processes change several configuration files, including files that you customized. Customized files can include header and footer HTML files, CSS and JSP files, themes, and several other files that are listed in this topic.

    You must manually migrate the files that are referenced in the Migrate manually column of the following table:

    Configuration files to migrate

    Customization Automatically migrated Migrate manually
    User interface (customized CSS, JSP, and HTML; labels and strings).

    Customized string files are preserved in the customization directory but you might need to rename some string files to match new Java and Dojo package names in IBM Connections 4.0.

    Custom CSS files are preserved in the customization directory but you must update them to match the new OneUI version in IBM Connections 4.0.

    Partially. Yes.
    Template configuration

    Manual post-migration steps may be required, see the Post-migration steps for profile types and profile policies topic .

    Partially. See the post-migration steps.
    Header and Footer

    The customized header and footer are preserved in the customization directory, which is not migrated. You must update your customized header and footer to match the new layout and functionality of IBM Connections 4.0.

    No. Yes.

    Email notification templates.

    Email notification templates have been translated from JSP to FreeMarker.

    Merge your existing customizations with the new Notification templates in the profile_root/Dmgr01/config/cells/cell_name/LotusConnections-config/notifications directory. If a global customization exists for all emails, then you only need to customize the shared resources. If JSP templates were customized in the 3.0.1 customization folders - you can remove them.

    No. Yes.
    Blog themes Partially. Yes.
    Community themes

    The default Communities themes are migrated automatically. However, must redefine any custom theme.

    Yes Redefine any custom themes.
    Business cards

    The Links and Actions attributes of business cards are migrated when the LotusConnections-config.xml and profiles-config.xml are migrated. Link definitions defined as attributes to each service in the LCC.xml file are migrated to the new LCC.xml file.

    The photo and contact information in business cards is migrated from the profiles-config.xml file in 3.0.1 to the new businessCardInfo.ftl FreeMarker Template Language file in 4.0. Other elements in the profiles-config.xml file are migrated to the new profiles-config.xml file.

    Manual steps may also be required to migrate profile customizations for business cards from 3.0.1 as described in the Post-migration steps for profile types and profile policies topic.

    Yes. Partially.
    Security role mappings.

    Redefine your security role mappings.

    No. Yes.
    service-location.xsd

    Customized extended service names are not migrated. Copy any customized XSD elements to the 4.0 service-location.xsd file.

    Partially. Yes.
    profiles-policy.xml

    Copy the 3.0.1 version of profiles-policy.xml file to the 4.0 deployment, overwriting the 4.0 version of the file.

    No. Yes.
    validation.xml

    Redefine customized Profile field validation settings.

    No Yes.
    JavaScript

    The file path and contents of JavaScript string customizations have changed and require manual migration.

    The ui-extensions framework is deprecated in 4.0 so manually migrate your 3.0.1 JavaScript customizations.

    No. Yes
    IBM Connections Connector for Lotus Quickr®.

    The IBM Connections Connector for Lotus Quickr was updated for IBM Connections 4.0. You must obtain the 4.0 version from the catalog.

    No. Reinstall the connector.
    Server whitelist for publishing file attachments from Activities to Lotus Quickr. No. Redefine the whitelist.


    Prepare to migrate the media gallery

    Before you migrate your media gallery from IBM Connections 3.0.1 to 4.0, you must prepare your terms and conditions agreement and any third-party video player that you use. These features were both optional, so you might not use them. If you created an optional terms and conditions agreement for the media gallery or used a custom video player in 3.0.1, then follow these instructions.

    1. Copy the string bundle files associated with terms and conditions agreement from the customization_dir/strings directory that you used in IBM Connections 3.0.1.

    2. If you were using a custom video player in IBM Connections 3.0.1, then backup the original enterprise application that you used. If you used the same naming conventions that were used as in the 3.0.1 documentation, then back up the CustomVideoPlayer enterprise application (ear).

      1. Select the ear in the WAS admin console.

      2. Click Export.

      3. Save the ear to the file system.

    3. If you were using a custom field renderer in IBM Connections 3.0.1, then backup the original enterprise application that you used. If you used the same naming conventions that were used in the Connections 3.0.1 documentation, then backup the CustomRenderers enterprise application (ear).

      1. Select the ear in the WAS administration console.

      2. b. Click Export.

      3. c. Save the ear to the file system.


    Migrate to IBM Connections 4.0

    Migrate a production installation of IBM Connections 3.0.1 to IBM Connections 4.0.

    Ensure that your environment meets the hardware and software requirements for IBM Connections 4.0.

    If you have a version of IBM Connections that is earlier than version 3.0.1, you must migrate it to version 3.0.1 before migrating to version 4.0.

    If you plan to install the new Metrics application, IBM recommends that you deploy IBM Cognos Business Intelligence before installing IBM Connections 4.0. However, you can defer deploying Cognos and still install Metrics. For more information, see the Install Cognos Business Intelligence and Configure Cognos Business Intelligence topics.

    If you are deploying version 4.0 on a different system than version 3.0.1, you do not need to uninstall IBM Connections 3.0.1.

    If possible, set up a test environment and simulate the migration process. Correct the cause of any errors that occur and then migrate your production environment.

    This topic applies to all releases of version 3.0.1.

    There are several procedures required to migrate your deployment. Your migration strategy determines which procedures you need to follow.

    A side-by-side migration strategy minimizes the downtime of your production environment but costs more in terms of hardware resources.

    An in-place strategy minimizes costs but causes more downtime. It is similar to the side-by-side strategy except that you do not need to deploy new hardware.

    Whatever strategy you decide to follow, complete the following steps:

    1. Update IBM WAS to the supported version. For more information, go to the Install maintenance packages, interim fixes, fix packs, and refresh packs in the WAS infocenter.

    2. Advise users about any possible outages. For more information, see the Preparing IBM Connections for maintenance topic.

    3. Back up your current deployment, including customized files and settings. For more information, see the Back up IBM Connections and Saving your customizations topics.

    4. Stop IBM Connections 3.0.1.

    5. Export IBM Connections 3.0.1 artifacts. For more information, see the Exporting application artifacts from IBM Connections 3.0.1 topic.

    6. Migrate your IBM Connections 3.0.1 data. For more information, see the Migrating data from IBM Connections 3.0.1 DBs topic.

      • Update your DBs to version 4.0. For more information, see the Updating 3.0.1 DBs topic.

    7. Optional: Uninstall IBM Connections 3.0.1. This is recommended if you are installing version 4.0 in-place. It is not necessary if you are installing version 4.0 on new hardware.

    8. Install IBM Connections 4.0. For more information, see the Installing IBM Connections 4.0 for migration topic.

      • Complete the relevant Pre-installation tasks. For more information, see the Pre-installation tasks topic.

        Some of the Pre-installation tasks describe how to create DBs or populate the Profiles DB. You do not need to complete those particular tasks because the migration process automatically completes them.

      • Migrate your content stores. For more information, see the Content store migration topic.

    9. Import IBM Connections 3.0.1 artifacts. For more information, see the Importing application artifacts to IBM Connections 4.0 topic.

    10. Perform any applicable post-migration tasks. For more information, see the Post-migration tasks topic.


    Export application artifacts from IBM Connections 3.0.1

    Export application artifacts, such as configuration data, from your 3.0.1 deployment. To export application data from your 3.0.1 deployment, complete the following steps:

    1. Perform a full synchronization of all the nodes in the cluster where IBM Connections 3.0.1 is deployed.

      The migration tool does not migrate custom fields in IBM Connections configuration files. Nor does it migrate the validation.xml file. This file is needed by the Struts validation framework and is accessed when IBM Connections starts. To ensure that your custom fields and files are usable after upgrading, see the Save your customizations and Post-migration tasks topics.

    2. Do one of the following:

      • If IBM Connections 4.0 is not installed:

        1. Rename the migration directory in your IBM Connections 3.0.1 deployment.

        2. Copy the migration_4.0.0.0_date_time.zip file from the IBM_Connections_Install/IBMConnections/native directory of the installation media, where date and time represent the date and time stamps of the file.

        3. Extract the file to the IBM Connections 3.0.1 installation directory and ensure that your archiving software preserves the directory structure of the compressed files. The decompressed archive should create a migration directory at the same directory level as the ConfigEngine directory.

      • If IBM Connections 4.0 is installed:

        1. Rename the migration directory in your IBM Connections 3.0.1 deployment.

        2. Copy the IBM Connections 4.0 connections_root/migration directory to the IBM Connections 3.0.1 connections_root directory on the system that hosts the Deployment Manager. Ensure that you copy the migration directory to the same directory level as the /ConfigEngine directory.

      (AIX and Linux only) Make sure that the user has all permissions for the migration directory.

    3. Open a command prompt on the version 3.0.1 system, change to the migration directory and run the following command:

      The migration tool does not migrate the content stores. For more information about migrating the content stores, see the Content store migration topic.

      • AIX or Linux:

        ./migration.sh lc-export

      • Windows:

        migration.bat lc-export

      > The lc-export command exports the following data:

      • Configuration files in the LotusConnections-config directory. You can find this directory in a the following location:

        • profile_root/config/cells/DM_cell_name/LotusConnections-config

      • Properties files in the connections_root directory

      The exported data is stored in the migration/work directory. Check the log file to validate the export. The log file is stored in the system user's home directory and uses the following naming format:

      lc-migration-yyyyMMdd_HHmm_ss.log

      For example:

      • AIX or Linux:

        /root/lc-migration-20101215_1534_26.log

      • Windows:

        C:\Administrator\lc-migration-20101215_1534_26.log

      > You can reuse the 3.0.1. content stores or copy them to your new content store. For more information, see the Content store migration topic.

    4. Back up the migration directory to a location outside your 3.0.1 deployment.


    What to do next

    Continue with the next task in the migration process.


    Migrate data from IBM Connections 3.0.1 DBs

    Learn how to migrate data from your IBM Connections 3.0.1 DBs.

    To migrate your data, you can choose from two different strategies:

    Side-by-side

    Create new 3.0.1 DBs on a separate system and transfer your existing 3.0.1 data to that system. Then update the new DBs to version 4.0. This strategy requires more time and resources than an in-place migration but means that you can test the update while you continue to use your 3.0.1 DBs. For more information, see the Migrating data side-by-side topic.

    In-place

    Instead of migrating your 3.0.1 data, update the DBs on the same system as the earlier version. This strategy saves time and hardware resources. For more information, see the Migrating data in-place topic.

    You can update DBs with the IBM Connections DB wizard or with the SQL scripts that are provided with the product.


    Migrate 3.0.1 data side-by-side

    Migrate your IBM Connections 3.0.1 data in a side-by-side procedure so that your 3.0.1 data remains intact.

    (DB2 only) If you use only one DB instance and if that instance includes other DBs besides IBM Connections, configure the numdb parameter to match the total number of DBs on the instance. For more information, go to the numdb webpage in the DB2 information center.

    > If you migrated from IBM Connections 3.0.1, the numdb parameter was set to 12, the maximum number of IBM Connections 4.0 DBs. If the instance has additional DBs, increase the value of the numdb parameter to match the total number of DBs on the instance.

    > To change the parameter:

    db2 UPDATE DBM CFG USING NUMDB nn

    where nn is a number of DBs.

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

    This topic applies to all releases of version 3.0.1. Transfer data from your IBM Connections 3.0.1 DBs, described here as the source DBs, to the new 3.0.1 DBs, described here as the target DBs. When the data transfer is complete and you validate the new DBs, you can update them to version 4.0.

    You can continue to use your 3.0.1 DBs until you are ready to move to IBM Connections 4.0.

    Although you can continue to use your 3.0.1 DBs until you are ready to move to IBM Connections 4.0, any data that you generate after the DB update is not migrated to the new environment.

    To update the DBs:

    1. Use the IBM Connections 3.0.1 DB wizard, create target 3.0.1 DBs on a separate system from your 3.0.1 source DBs. The new DBs host your data for migration to the 4.0 deployment.

      If the 3.0.1 DB wizard is not on the system that hosts the target DBs, copy it from the system hosting IBM Connections 3.0.1.

    2. (DB2 on Windows 2008 64-bit.) On Windows 2008, you must perform DB2 administration tasks with full administrator privileges.

      1. Logged in as the instance owner, open a command prompt and change to the DB2 bin directory. For example: C:\IBM\SQLLIB\BIN.

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

    3. Prepare the target 3.0.1 DBs to accept data from the source 3.0.1 DBs. Remove constraints from the target DBs by executing the following SQL scripts:

      Run these SQL scripts before transferring data to the target DB.

      Run each script from the same directory that you use to create the target DB.

      IBM Connections uses the following DB libraries which are already on the target DB server:

      • DB2

        • db2jcc.jar

        • db2jcc_license_cu.jar

        Oracle

        • ojdbc6.jar

      Repeat the following procedures for each application that you are migrating:

      • DB2:

        1. Log in as the instance owner. The default owner on AIX and Linux is db2inst1. On Windows, the default is db2admin.

        2. For each application, change to the directory where the relevant SQL file is stored.

        3. Enter the appropriate commands for each application, as shown in the following table.

        DB2 commands for removing constraints

        Application Directory DB2 commands
        Activities /connections.sql/activities/db2 db2 -tvf predbxfer301.sql
        Blogs /connections.sql/blogs/db2 db2 -td@ -vf predbxfer301.sql
        Bookmarks /connections.sql/dogear/db2

        db2 -td@ -vf predbxfer301.sql

        Communities /connections.sql/communities/db2 db2 -td@ -vf predbxfer301.sql
        Files /connections.sql/files/db2 db2 -td@ -vf predbxfer301.sql
        Forum /connections.sql/forum/db2 db2 -tvf predbxfer301.sql
        Home page /connections.sql/homepage/db2 db2 -tvf predbxfer301.sql
        Profiles /connections.sql/profiles/db2 db2 -tvf predbxfer301.sql
        Wikis /connections.sql/wikis/db2 db2 -td@ -vf predbxfer301.sql

      • Oracle:

        1. For each application, change to the directory containing the relevant SQL file.

        2. Enter the following commands:

          1. sqlplus /NOLOG

          2. conn system/password@SID

          3. @SQL_script.sql
          where

          • password is the password for the user system.

          • SID is the Oracle System Identifier for IBM Connections.

          • SQL_script refers to a SQL script from the following table.

        Oracle commands for removing constraints

        Application Directory Oracle commands
        Activities /connections.sql/activities/oracle

        @predbxfer301.sql

        Blogs /connections.sql/blogs/oracle @predbxfer301.sql
        Bookmarks /connections.sql/dogear/oracle @predbxfer301.sql
        Communities /connections.sql/communities/oracle

        @predbxfer301.sql

        Files /connections.sql/files/oracle @predbxfer301.sql
        Forum /connections.sql/forum/oracle @predbxfer301.sql
        Home page /connections.sql/homepage/oracle @predbxfer301.sql
        Profiles /connections.sql/profiles/oracle @predbxfer301.sql
        Wikis /connections.sql/wikis/oracle @predbxfer301.sql

      • SQL Server

        1. Log in as the DB administrator.

        2. For each application, change to the directory containing the relevant SQL file.

        3. Enter the commands shown in the following table:

          In these commands, password is the password for the SQL Server user sa.

          If your DB server has multiple SQL Server instances, add the following line as the first parameter to each command in the table: -S sqlserver_server_name\sqlserver_server_instance_name

        SQL Server commands for removing constraints

        Application Directory SQL Server commands
        Activities /connections.sql/activities/sqlserver sqlcmd -U sa -P password -i "predbxfer301.sql"
        Blogs /connections.sql/blogs/sqlserver sqlcmd -U sa -P password -i "predbxfer301.sql"
        Bookmarks /connections.sql/dogear/sqlserver sqlcmd -U sa -P password -i "predbxfer301.sql"
        Communities /connections.sql/communities/sqlserver

        sqlcmd -U sa -P password -i "predbxfer301.sql"

        Files /connections.sql/files/sqlserver sqlcmd -U sa -P password -i "predbxfer301.sql"
        Forum /connections.sql/forum/sqlserver sqlcmd -U sa -P password -i "predbxfer301.sql"
        Home page /connections.sql/homepage/sqlserver sqlcmd -U sa -P password -i "predbxfer301.sql"
        Profiles /connections.sql/profiles/sqlserver sqlcmd -U sa -P password -i "predbxfer301.sql"
        Wikis /connections.sql/wikis/sqlserver sqlcmd -U sa -P password -i "predbxfer301.sql"

    4. Use the IBM Connections DB transfer tool, transfer data to the target DBs:

      1. Create a directory called DBT_HOME on the target DB server. This directory temporarily stores transferred data.

      2. Copy the dbt.jar file from the connections_root\ConfigEngine\lib directory to the DBT_HOME directory on the target DB server.

        IBM Connections does not support GNU Java.

        Use the Java Runtime Environment (JRE) under the Wizards directory in the installation media. Update your PATH variable to point to this JRE, using the instructions for your operating system.

        For example, the relative path to the JRE on the Microsoft Windows operating system might be Wizards\jvm\win\jre. For the AIX or Linux operating systems, the relative path might be Wizards/jvm/aix/jre and Wizards/jvm/linux/jre.

      3. Create an XML configuration file under the DBT_HOME directory and add the following content:

        <dbTransfer xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
        <DB role="source" 
        driver="JDBC_driver" 
        url="JDBC_url" 
        userId="DB_admin
        schema="application_db_schema_name"
        dbType="dbType"/>
        <DB role="target"
        driver="JDBC_driver"
        url="JDBC_url"
        userId="DB_admin" 
        schema="application_db_schema_name" 
        dbType="dbType"/>
        </dbTransfer>

        where

        JDBC_driver is one of the following types:

        • DB2: com.ibm.db2.jcc.DB2Driver

        • Oracle: oracle.jdbc.driver.OracleDriver

        • SQL Server: com.microsoft.sqlserver.jdbc.SQLServerDriver

        JDBC_url is one of the following types:

        • DB2: jdbc:db2://host_IP:port/application_DB_name

          You can try to increase the speed of the migration process by adapting the URL as follows:

          DB2: jdbc:db2://host_IP:port/application_DB_name:streamBufferSize=2097152;progressiveStreaming=1;

        • Oracle: jdbc:oracle:thin:@host_IP:port:SID

        • SQL Server: jdbc:sqlserver://host_IP:port;DBName=application_DB_name

        where

        • host_IP is the IP address of the DB server.

        • port is the port of the server.

        • SID is the Oracle System Identifier for IBM Connections.

        • application_DB_name is one of the following values:

          • Activities: OPNACT

          • Blogs: BLOGS

          • Communities: SNCOMM

          • Dogear: DOGEAR

          • Files: FILES

          • Forum: FORUM

          • Home page: HOMEPAGE

          • Profiles: PEOPLEDB

          • Wikis: WIKIS

        DB_admin is the UID of the DB administrator.

        application_db_schema_name is one of the following values:

        • Activities: ACTIVITIES

        • Blogs: BLOGS

        • Communities: SNCOMM

        • Dogear: DOGEAR

        • Files: FILES

        • Forum: FORUM

        • Home page: HOMEPAGE

        • Profiles: EMPINST

        • Wikis: WIKIS

        dbType is one of the following values:

        • DB2: DB2

        • Oracle: oracle

        • SQL Server: sqlserver2005

      4. Prepare the JDBC driver of the target DBs:

        • DB2:

          • Use the JDBC driver on the target DB server.

        • Oracle:

          • Use the JDBC driver on the target DB server.

          • Ensure that the Oracle driver on your system has the same version number as your Oracle DB server. IBM Connections does not support the Oracle 10.2.0.1 JDBC driver.

        • SQL Server

          • Download the SQL Server 2005 JDBC 1.2 driver from the Microsoft website and follow the instructions to extract the driver files.

      5. To perform the data transfer, run the dbt.jar file:

        Remove the lines for the DB systems that are not in your deployment.

        • Linux:

          "JAVA_HOME/bin/java"

          -cp DBT_HOME/dbt.jar:

          DB2_HOME/java/db2jcc.jar:

          DB2_HOME/java/db2jcc_license_cu.jar:

          ORACLE_HOME/jdbc/lib/ojdbc6.jar:

          SQLSERVER_DRIVER_PATH:

          com.ibm.wps.config.db.transfer.CmdLineTransfer

          -logDir DBT_HOME/logs

          -xmlfile DBT_HOME/dbt_config_file_name

          -sourcepassword source_db_password

          -targetpassword target_db_password

          where

          • JAVA_HOME is the path to the Java JDK.

          • dbt_config_file_name is the name of the XML configuration file you created for the dbt.jar file

          • logs is the directory where log files are stored. Create the logs directory before running this file

          • DB2_HOME is the path to the DB2 installation directory.

          • ORACLE_HOME is the path to the Oracle installation directory.

          • SQLSERVER_DRIVER_PATH is the path to the sqljdbc4.jar JDBC driver.

        • Windows:

          "JAVA_HOME/bin/java"

          -cp DBT_HOME/dbt.jar;

          DB2_HOME/java/db2jcc.jar;

          DB2_HOME/java/db2jcc_license_cu.jar;

          ORACLE_HOME/jdbc/lib/ojdbc6.jar;

          SQLSERVER_DRIVER_PATH;

          com.ibm.wps.config.db.transfer.CmdLineTransfer

          -logDir DBT_HOME/logs

          -xmlfile DBT_HOME/dbt_config_file_name

          -sourcepassword source_db_password

          -targetpassword target_db_password

          where

          • JAVA_HOME is the path to the Java JDK.

          • dbt_config_file_name is the name of the XML configuration file you created for the dbt.jar file

          • logs is the directory where log files are stored. Create the logs directory before running this file

          • DB2_HOME is the path to the DB2 installation directory.

          • ORACLE_HOME is the path to the Oracle installation directory.

          • SQLSERVER_DRIVER_PATH is the path to the sqljdbc4.jar JDBC driver.

        When the transfer is complete, you can restart your 3.0.1 deployment to minimize service downtime.

        Data that is generated after restarting the 3.0.1 environment is not migrated.

    5. Reapply constraints to the target DBs:

      • DB2:

        1. Log in as the instance owner.

        2. For each application, change to the directory where the relevant SQL file is stored.

        3. Enter the appropriate commands for each application, as shown in the following table.

        DB2 commands for reapplying constraints

        Application Directory DB2 commands
        Activities /connections.sql/activities/db2

        db2 -tvf postdbxfer301.sql

        db2 -tvf clearScheduler.sql

        Blogs /connections.sql/blogs/db2 db2 -td@ -vf postdbxfer301.sql
        Bookmarks /connections.sql/dogear/db2 db2 -td@ -vf postdbxfer301.sql
        Communities /connections.sql/communities/db2

        db2 -td@ -vf postdbxfer301.sql

        db2 -td@ -vf clearScheduler.sql

        Files /connections.sql/files/db2 db2 -td@ -vf postdbxfer301.sql

        db2 -td@ -vf clearScheduler.sql

        Forum /connections.sql/forum/db2

        db2 -tvf postdbxfer301.sql

        db2 -td@ -vf clearScheduler.sql

        Home page /connections.sql/homepage/db2

        db2 -tvf postdbxfer301.sql

        db2 -tvf clearScheduler.sql

        Profiles /connections.sql/profiles/db2 db2 -tvf postdbxfer301.sql

        db2 -tvf clearScheduler.sql

        Wikis /connections.sql/wikis/db2 db2 -td@ -vf postdbxfer301.sql

        db2 -td@ -vf clearScheduler.sql

      • Oracle:

        1. For each application, change to the directory containing the relevant SQL file.

        2. Enter the following commands:

          1. sqlplus /NOLOG

          2. conn system/password@SID

          3. @SQL_script.sql
          where

          • password is the password for the user system.

          • SID is the Oracle System Identifier for IBM Connections.

          • SQL_script refers to a SQL script from the following table.

        Oracle commands for reapplying constraints

        Application Directory Oracle commands
        Activities /connections.sql/activities/oracle

        @postdbxfer301.sql

        @clearScheduler.sql

        Blogs /connections.sql/blogs/oracle @postdbxfer301.sql
        Bookmarks /connections.sql/dogear/oracle @postdbxfer301.sql
        Communities /connections.sql/communities/oracle

        @postdbxfer301.sql

        @clearScheduler.sql

        Files /connections.sql/files/oracle @postdbxfer301.sql

        @clearScheduler.sql

        Forum /connections.sql/forum/oracle

        @postdbxfer301.sql

        @clearScheduler.sql

        Home page /connections.sql/homepage/oracle

        @postdbxfer301.sql

        @clearScheduler.sql

        Profiles /connections.sql/profiles/oracle @postdbxfer301.sql

        @clearScheduler.sql

        Wikis /connections.sql/wikis/oracle @postdbxfer301.sql

        @clearScheduler.sql

      • SQL Server

        1. Log in as the DB administrator.

        2. For each application, change to the directory containing the relevant SQL file.

        3. Enter the commands shown in the following table:

          In these commands, password is the password for the SQL Server user sa.

          If your DB server has multiple SQL Server instances, add the following line as the first parameter to each command in the table: -S sqlserver_server_name\sqlserver_server_instance_name

        SQL Server commands for reapplying constraints

        Application Directory SQL Server commands
        Activities /connections.sql/activities/sqlserver

        sqlcmd -U sa -P password

        -i "postdbxfer301.sql"

        sqlcmd -U sa -P password -i "clearScheduler.sql"

        Blogs /connections.sql/blogs/sqlserver sqlcmd -U sa -P password -i "postdbxfer301.sql"
        Bookmarks /connections.sql/dogear/sqlserver sqlcmd -U sa -P password -i "postdbxfer301.sql"
        Communities /connections.sql/communities/sqlserver

        sqlcmd -U sa -P password -i "postdbxfer301.sql"

        sqlcmd -U sa -P password -i "clearScheduler.sql"

        Files /connections.sql/files/sqlserver sqlcmd -U sa -P password -i "postdbxfer301.sql"

        sqlcmd -U sa -P password -i "clearScheduler.sql"

        Forum /connections.sql/forum/sqlserver

        sqlcmd -U sa -P password -i "postdbxfer301.sql"

        sqlcmd -U sa -P password -i "clearScheduler.sql"

        Home page /connections.sql/homepage/sqlserver

        sqlcmd -U sa -P password -i "postdbxfer301.sql"

        sqlcmd -U sa -P password -i "clearScheduler.sql"

        Profiles /connections.sql/profiles/sqlserver sqlcmd -U sa -P password -i "postdbxfer301.sql"

        sqlcmd -U sa -P password -i "clearScheduler.sql"

        Wikis /connections.sql/wikis/sqlserver sqlcmd -U sa -P password -i "postdbxfer301.sql"

        sqlcmd -U sa -P password -i "clearScheduler.sql"

    6. (Profiles only.) Run the following commands to update the DB sequence for DB2 or Oracle target DBs:

      • DB2

        • Run the following commands on the 3.0.1 source DB:

            SELECT EMPINST.EMPINST.EXT_DRAFT_SEQ.NEXTVAL AS EXT_DRAFT_SEQ FROM DUAL;
            SELECT EMPINST.EMPINST.EMP_DRAFT_SEQ.NEXTVAL AS EMP_DRAFT_SEQ FROM DUAL;
            SELECT EMPINST.CHG_EMP_DRAFT_SEQ1.NEXTVAL AS CHG_EMP_DRAFT_SEQ1 FROM DUAL;
            SELECT EMPINST.CHG_EMP_DRAFT_SEQ2.NEXTVAL AS CHG_EMP_DRAFT_SEQ2 FROM DUAL;

          Run the following commands on the 3.0.1 target DB:

          DROP SEQUENCE EMPINST.EXT_DRAFT_SEQ;

          CREATE SEQUENCE EMPINST.EXT_DRAFT_SEQ START WITH query_result;

          DROP SEQUENCE EMPINST.EMP_DRAFT_SEQ;

          CREATE SEQUENCE EMPINST.EMP_DRAFT_SEQ START WITH query_result;

          DROP SEQUENCE EMPINST.CHG_EMP_DRAFT_SEQ1;

          CREATE SEQUENCE EMPINST.CHG_EMP_DRAFT_SEQ1 START WITH query_result;

          DROP SEQUENCE EMPINST.CHG_EMP_DRAFT_SEQ2;

          CREATE SEQUENCE EMPINST.CHG_EMP_DRAFT_SEQ2 START WITH query_result;

      • Oracle

        • Run the following commands on the 3.0.1 source DB:

            SELECT EMPINST.EMPINST.EXT_DRAFT_SEQ.NEXTVAL AS EXT_DRAFT_SEQ FROM DUAL;
            SELECT EMPINST.EMPINST.EMP_DRAFT_SEQ.NEXTVAL AS EMP_DRAFT_SEQ FROM DUAL;
            SELECT EMPINST.CHG_EMP_DRAFT_SEQ1.NEXTVAL AS CHG_EMP_DRAFT_SEQ1 FROM DUAL;
            SELECT EMPINST.CHG_EMP_DRAFT_SEQ2.NEXTVAL AS CHG_EMP_DRAFT_SEQ2 FROM DUAL;

          Run the following commands on the 3.0.1 target DB:

          DROP SEQUENCE EMPINST.EXT_DRAFT_SEQ;

          CREATE SEQUENCE EMPINST.EXT_DRAFT_SEQ START WITH query_result;

          DROP SEQUENCE EMPINST.EMP_DRAFT_SEQ;

          CREATE SEQUENCE EMPINST.EMP_DRAFT_SEQ START WITH query_result;

          DROP SEQUENCE EMPINST.CHG_EMP_DRAFT_SEQ1;

          CREATE SEQUENCE EMPINST.CHG_EMP_DRAFT_SEQ1 START WITH query_result;

          DROP SEQUENCE EMPINST.CHG_EMP_DRAFT_SEQ2;

          CREATE SEQUENCE EMPINST.CHG_EMP_DRAFT_SEQ2 START WITH query_result;

      where query_result is the result of the corresponding SELECT command that you ran on the 3.0.1 DB.


    What to do next

    Check that all the DBs are working correctly. If you find errors, resolve the problem and repeat this task.

    Update the new DBs to IBM Connections version 4.0. For more information, see the Updating 3.0.1 DBs topic.

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


    Migrate 3.0.1 data in-place

    Prepare to update your IBM Connections 3.0.1 DBs to version 4.0.

    The in-place strategy is a good option when you have limited system resources because it minimizes the system resources required. Instead of migrating your data, you simply update the IBM Connections 3.0.1 DBs. If you want to keep your 3.0.1 DBs, use the side-by-side data migration strategy instead.


    Update 3.0.1 DBs

    Update IBM Connections 3.0.1 DBs to version 4.0 in an existing DB environment.

    There are two methods for updating a DB: using the IBM Connections DB wizard or the SQL scripts provided with the product.

    Database wizard

    The wizard is a faster procedure and also validates the update. For more information, see the Updating 3.0.1 DBs with the wizard topic.

    SQL scripts

    Use the SQL scripts provided with the product, you can examine all the commands applied to your DB. For more information, see the Updating 3.0.1 DBs manually topic.

    Perform the tasks that apply to your deployment:


    Update 3.0.1 DBs with the wizard

    Update your IBM Connections 3.0.1 DBs by using the DB wizard.

    Before applying updates, back up your DBs. For more information, see the Back up IBM Connections topic.

    If you use different DB instances for the Home page and Profiles DB, run the wizard first on the instance that hosts the Home page DB.

    Find out the value of the storyLifetimeInDays parameter in the news-config.xml file. You must enter this value when you migrate the Home page DB. The default value is 30. News stories and notifications that are older than this value are purged from the Home page DB during migration. For more information, see the Accessing the News configuration file topic.

    IBM recommends that you update the Homepage DB manually. By using the manual method, you can back up the Home page DB after each step. This precaution is useful because updating the Home page DB, if it is very large, can take considerably more time than the other DBs. If you choose this option, update the Home page DB before updating any other DB. After updating the Home page DB, you can use the wizard to update the remaining DBs. For more information about manually updating DBs, see the Updating 3.0.1 DBs manually topic.

    (DB2 only) If you use only one DB instance and if that instance includes other DBs besides IBM Connections, configure the numdb parameter to match the total number of DBs on the instance. For more information, go to the numdb webpage in the DB2 information center.

    If you migrated from IBM Connections 3.0.1, the numdb parameter was set to 12, the maximum number of IBM Connections 4.0 DBs. If the instance has additional DBs, increase the value of the numdb parameter to match the total number of DBs on the instance.

    To change the parameter:

    db2 UPDATE DBM CFG USING NUMDB nn

    where nn is a number of DBs.

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

    (SQL Server only) Ensure that Named Pipes is enabled in the SQL Server Network Configuration for all instances. For more information, refer to your SQL Server documentation. Follow these steps to update your IBM Connections 3.0.1 DBs to IBM Connections 4.0 DBs.

    As an alternative to using the wizard, you can update the DBs manually. For more information, see the Updating 3.0.1 DBs manually topic.

    To update your DBs with the DB wizard, complete the following steps:

    1. Stop the IBM WAS instances that are hosting IBM Connections 3.0.1.

    2. Optional: If the DB servers and IBM Connections are on different systems, copy the 4.0 DB wizard to the system that hosts your IBM Connections DBs.

    3. Log in as the DB administrator.

    4. (DB2 on Windows 2008 64-bit.) On Windows 2008, you must perform DB2 administration tasks with full administrator privileges.

      1. Logged in as the instance owner, open a command prompt and change to the DB2 bin directory. For example: C:\IBM\SQLLIB\BIN.

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

    5. Change to the directory where the DB wizard is stored. The default location is the Wizards directory on the installation media.

      (AIX and Linux only) Ensure that the DB administrator has all permissions for the IBM Connections Wizards directory.

    6. Enter the following command and then click Next:

      • AIX or Linux: ./dbWizard.sh

      • Windows: dbWizard.bat

    7. Select the Upgrade task and click Next.

    8. Set the DB type, DB instance, and the installation location, and then click Next. The wizard detects the current DB version.

    9. Select the DBs to update and click Next:

      • Activities: OPNACT

      • Blogs: BLOGS

      • Bookmarks: DOGEAR

      • Communities: SNCOMM

      • Files: FILES

      • Forum: FORUM

      • Home page: HOMEPAGE
        Enter the value of the storyLifetimeInDays parameter. Stories that are older than this value are purged from the DB during the migration process. Must match the value of the same parameter in the news-config.xml file.

      • Profiles: PEOPLEDB

      • Wikis: WIKIS

      The DB wizard disables the selection of any applications that were not released in IBM Connections 3.0.1. If any application DBs were created in an earlier release of IBM Connections than 3.0.1, update that DB by using the IBM Connections 3.0.1 DB wizard.

    10. (SQL Server only) Enter the location of the data files for the Home page application.

    11. (SQL Server only) Enter the password for the Home page DB user.

    12. (Oracle only) Enter the password for the Communities DB user.

    13. If you are updating the Activities, Blogs, Bookmarks, or Home page DB, provide the port, administrator ID, and administrator password for the DB.

      • (Oracle only) The DB wizard presents two options for password selection. If your Oracle environment does not use the same password for all schema UIDs, choosing either of these options leads to an error. To avoid this error, modify your schema UIDs to use the same password. When the migration process is complete, restore the original passwords.

    14. Enter the connection information for the Profiles DB user.

      • Enter the Oracle SID in the Database name field.

      • This information is used during the migration of the Home page DB to copy data from the Profile DB.

      • If you use different instances to host the Home page and Profiles DBs, this step is displayed only when you run the wizard on the instance that hosts the Home page DB.

    15. Review the Pre Configuration Task Summary to ensure that the values you entered are correct. If you want to change any values, click Back to edit the value. To continue, click Update.

      Click Show detailed DB commands to display the commands. To save the commands, ensure that the user who is running the DB wizard has write access to the destination folder. Click Execute to run the commands.

    16. After the update task finishes, review the Post Configuration Task Summary. Click Finish to exit the wizard.

    17. Run the DB wizard again to create DBs for Metrics, Cognos, and Mobile. For more information, see the Creating DB topic


    What to do next

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


    Update 3.0.1 DBs manually

    Manually update IBM Connections 3.0.1 DBs to version 4.0 in an existing IBM WAS and DB environment. Complete the task that is applicable to your deployment:


    Update 3.0.1 DB2 DBs manually

    Manually update IBM Connections 3.0.1 DBs to version 4.0 in an existing IBM WAS and DB2 DB environment.

    Before applying updates, back up your DBs. For more information, see the Back up IBM Connections topic.

    Install and configured all supporting software for version 4.0.

    Find out the value of the storyLifetimeInDays parameter in the news-config.xml file. You must enter this value when you migrate the Home page DB. The default value is 30. News stories and notifications that are older than this value are purged from the Home page DB during migration. For more information, see the Accessing the News configuration file topic.

    (DB2 only) If you use only one DB instance and if that instance includes other DBs besides IBM Connections, configure the numdb parameter to match the total number of DBs on the instance. For more information, go to the numdb webpage in the DB2 information center.

    If you migrated from IBM Connections 3.0.1, the numdb parameter was set to 12, the maximum number of IBM Connections 4.0 DBs. If the instance has additional DBs, increase the value of the numdb parameter to match the total number of DBs on the instance.

    To change the parameter:

    db2 UPDATE DBM CFG USING NUMDB nn

    where nn is a number of DBs.

    This topic describes how to manually update IBM Connections version 3.0.1 DBs to version 4.0. Use this procedure if you want an alternative to using the DB wizard to update your DBs.

    This topic applies to all releases of version 3.0.1.

    Use the Java Runtime Environment (JRE) under the Wizards directory in the installation media. Update your PATH variable to point to this JRE, using the instructions for your operating system.

    For example, the relative path to the JRE on the Microsoft Windows operating system might be Wizards\jvm\win\jre. For the AIX or Linux operating systems, the relative path might be Wizards/jvm/aix/jre and Wizards/jvm/linux/jre.

    IBM Connections does not support GNU Java.

    You need to use a DB administrator ID to run the Java migration utilities described in this task.

    After running each command, examine the output of the command for error messages. If you find errors, resolve them before continuing with the update process.

    To improve readability, some commands and file paths in this topic are displayed on separate lines. Ignore these formatting conventions when entering the commands.

    To update DBs manually:

    1. Log in to the WAS Integrated Solutions Console on your Deployment Manager.

    2. Go to Applications > Application types > WebSphere enterprise Applications.

    3. Stop all IBM Connections applications.

    4. (DB2 on Windows 2008 64-bit.) On Windows 2008, you must perform DB2 administration tasks with full administrator privileges.

      1. Logged in as the instance owner, open a command prompt and change to the DB2 bin directory. For example: C:\IBM\SQLLIB\BIN.

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

    5. Log in as the DB administrator.

    6. For each application, change to the directory where the SQL scripts are stored and then enter the commands for that application.

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

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

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

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

    7. Activities: Wizards/connections.sql/activities/db2

      1. db2 -td@ -vf upgrade-301-40.sql

      2. From a command prompt, change to the Wizards directory and enter the following text as a command on a single line:

        • AIX or Linux:

          jvm/OS/jre/bin/java -classpath

          jdbc_library_location/db2jcc.jar:

          jdbc_library_location/db2jcc_license_cu.jar:

          lib/commons-logging-1.0.4.jar:

          lib/lc.util.web-3.0.jar:

          lib/lc.dbmigration.default.jar:

          lib/log4j-1.2.11.jar:

          lib/oa.migrate.jar:

          com.ibm.openactivities.migrate.ActivitiesMigrationDriver

          -dburl jdbc:db2://dbHost:dbPort/OPNACT

          -dbuser dbUser -dbpassword dbPassword

          > java.out.log 2>&1

          where OS is the operating system on which the DB is hosted.

        • Windows:

          jvm\win\jre\bin\java -classpath

          jdbc_library_location\db2jcc.jar;

          jdbc_library_location\db2jcc_license_cu.jar;

          lib\commons-logging-1.0.4.jar;

          lib\lc.util.web-3.0.jar;

          lib\lc.dbmigration.default.jar;

          lib\log4j-1.2.11.jar;

          lib\oa.migrate.jar;

          com.ibm.openactivities.migrate.ActivitiesMigrationDriver

          -dburl jdbc:db2://dbHost:dbPort/OPNACT

          -dbuser dbUser -dbpassword dbPassword

          > java.out.log 2>&1

        where

        • jdbc_library_location is the location of your JDBC driver

        • dbHost is the name of the system hosting your DB

        • dbPort is the communications port of the DB

        • dbAlias is the reserved name of the DB, if applicable to your deployment

        • dbUser is the DB administrator ID

        • dbPassword is the administrator password

      3. db2 -td@ -vf appGrants.sql

    8. Blogs: Wizards/connections.sql/blogs/db2

      1. db2 -td@ -vf upgrade-301-40.sql

      2. From a command prompt, change to the Wizards directory and enter the following text as a command on a single line:

        • AIX or Linux:

          jvm/OS/jre/bin/java -classpath

          jdbc_library_location/db2jcc.jar:

          jdbc_library_location/db2jcc_license_cu.jar:

          lib/lc.dbmigration.default.jar:

          lib/blogs.migrate.jar:

          lib/commons-lang-2.4.jar:

          lib/commons-logging-1.0.4.jar

          com.ibm.lconn.blogs.migration.MigrationFrom301To40

          -dburl jdbc:db2://dbHost:dbPort/BLOGS

          -dbuser dbUser -dbpassword dbPassword

          > java.out.log 2>&1

          where OS is the operating system on which the DB is hosted.

        • Windows:

          jvm\win\jre\bin\java -classpath

          jdbc_library_location\db2jcc.jar;

          jdbc_library_location\db2jcc_license_cu.jar;

          lib\lc.dbmigration.default.jar;

          lib\blogs.migrate.jar;

          lib\commons-lang-2.4.jar;

          lib\commons-logging-1.0.4.jar

          com.ibm.lconn.blogs.migration.MigrationFrom301To40

          -dburl jdbc:db2://dbHost:dbPort/BLOGS

          -dbuser dbUser -dbpassword dbPassword

          > java.out.log 2>&1

        where

        • jdbc_library_location is the location of your JDBC driver

        • dbHost is the name of the system hosting your DB

        • dbPort is the communications port of the DB

        • dbAlias is the reserved name of the DB, if applicable to your deployment

        • dbUser is the DB administrator ID

        • dbPassword is the administrator password

      3. db2 -td@ -vf appGrants.sql

    9. Bookmarks: Wizards/connections.sql/dogear/db2

      1. db2 -td@ -vf upgrade-301-40.sql

      2. From a command prompt, change to the Wizards directory and enter the following text as a command on a single line:

        • AIX or Linux:

          jvm/OS/jre/bin/java -classpath

          jdbc_library_location/db2jcc.jar:

          jdbc_library_location/db2jcc_license_cu.jar:

          lib/lc.dbmigration.default.jar:

          lib/commons-lang-2.4.jar:

          lib/commons-logging-1.0.4.jar:

          lib/dogear.migrate.jar:

          com.ibm.lconn.dogear.migration.MigrationFrom301To40

          -dburl jdbc:db2://dbHost:dbPort/DOGEAR

          -dbuser dbUser -dbpassword dbPassword

          > java.out.log 2>&1

          where OS is the operating system on which the DB is hosted.

        • Windows:

          jvm\win\jre\bin\java -classpath

          jdbc_library_location\db2jcc.jar;

          jdbc_library_location\db2jcc_license_cu.jar;

          lib\lc.dbmigration.default.jar;

          lib\commons-lang-2.4.jar;

          lib\commons-logging-1.0.4.jar;

          lib\dogear.migrate.jar;

          com.ibm.lconn.dogear.migration.MigrationFrom301To40

          -dburl jdbc:db2://dbHost:dbPort/DOGEAR

          -dbuser dbUser -dbpassword dbPassword

          > java.out.log 2>&1

        where

        • jdbc_library_location is the location of your JDBC driver

        • dbHost is the name of the system hosting your DB

        • dbPort is the communications port of the DB

        • dbAlias is the reserved name of the DB, if applicable to your deployment

        • dbUser is the DB administrator ID

        • dbPassword is the administrator password

      3. db2 -td@ -vf appGrants.sql

    10. Communities: Wizards/connections.sql/communities/db2

      1. db2 -td@ -vf upgrade-301-40.sql

      2. db2 -td@ -vf appGrants.sql

      3. db2 -td@ -vf calendar-createDb.sql

      4. db2 -td@ -vf calendar-appGrants.sql

    11. Files: Wizards/connections.sql/files/db2

      1. db2 -td@ -vf upgrade-301-40.sql

      2. db2 -td@ -vf appGrants.sql

    12. Forum: Wizards/connections.sql/forum/db2

      1. db2 -td@ -vf upgrade-301-40.sql

      2. db2 -td@ -vf appGrants.sql

    13. Home page: Wizards/connections.sql/homepage/db2

      1. db2 -tvf upgrade-301-40.sql

      2. Optional: Back up the Home page DB, using your native DB tools. This precaution is recommended because the following migration step is complex and time-consuming. If any failures occur, use the backup to restore your Home page DB.

      3. From a command prompt, change to the Wizards directory and enter the following text as a single command:

        • AIX or Linux:

          jvm/OS/jre/bin/java -Xmx3072m -classpath

          jdbc_library_location/db2jcc.jar:

          jdbc_library_location/db2jcc_license_cu.jar:

          lib/news.core.data.jar:

          lib/news.common.jar:

          lib/news.core.service.jar:

          lib/news.cache.jar:

          lib/lc.dbmigration.default.jar:

          lib/lc.admin.userlifecycle.spi.jar:

          lib/lc.events.newsEjbConsumer.jar:

          lib/lc.events.internal.jar:

          lib/lc.appext.core.api-3.0.jar:

          lib/lc.appext.core.impl-3.0.jar:

          lib/lc.component.integration.news.jar:

          lib/lc.util.base-3.0.jar:

          lib/lc.config.svc-1.1.jar:

          lib/com.ibm.connections.directory.services.jar:

          lib/notify.client.jar:

          lib/lc.mtconfig.engine-1.0.jar:

          lib/lc.mtconfig.svc-1.0.jar:

          lib/icu4j-4_8_1.jar:

          lib/mybatis-2.3.5.jar:

          lib/spring.jar:

          lib/json4j.jar:

          lib/commons-logging-1.0.4.jar:

          lib/commons-dbcp-1.2.1.jar:

          lib/commons-collections-3.2.1.jar:

          lib/commons-pool-1.2.jar:

          lib/commons-lang-2.4.jar:

          lib/commons-configuration-1.5-plus-node-clone.jar:

          lib/jsoup-1.6.1.jar:

          lib/commons-lang3-3.1.jar:

          lib/news.migrate.jar:

          com.ibm.lconn.news.migration.next40.NewsMigrationFrom301To40

          -dburl jdbc:db2://dbHost:dbPort/HOMEPAGE

          -dbuser dbUser -dbpassword dbPassword

          -dburl_source jdbc:db2://Profiles_dbHost:Profiles_dbPort/PEOPLEDB

          -dbuser_source Profiles_dbUser -dbpassword_source Profiles_dbPassword

          -storyLifetimeInDays days

          > java.out.log 2>&1

          where OS is the operating system on which the DB is hosted.

        • Windows:

          jvm\win\jre\bin\java -Xmx3072m -classpath

          jdbc_library_location\db2jcc.jar;

          jdbc_library_location\db2jcc_license_cu.jar;

          lib\news.core.data.jar;

          lib\news.common.jar;

          lib\news.core.service.jar;

          lib\news.cache.jar;

          lib\lc.dbmigration.default.jar;

          lib\lc.admin.userlifecycle.spi.jar;

          lib\lc.events.newsEjbConsumer.jar;

          lib\lc.events.internal.jar;

          lib\lc.appext.core.api-3.0.jar;

          lib\lc.appext.core.impl-3.0.jar;

          lib\lc.component.integration.news.jar;

          lib\lc.util.base-3.0.jar;

          lib\lc.config.svc-1.1.jar;

          lib\com.ibm.connections.directory.services.jar;

          lib\notify.client.jar;

          lib\lc.mtconfig.engine-1.0.jar;

          lib\lc.mtconfig.svc-1.0.jar;

          lib\icu4j-4_8_1.jar;

          lib\mybatis-2.3.5.jar;

          lib\spring.jar;

          lib\json4j.jar;

          lib\commons-logging-1.0.4.jar;

          lib\commons-dbcp-1.2.1.jar;

          lib\commons-collections-3.2.1.jar;

          lib\commons-pool-1.2.jar;

          lib\commons-lang-2.4.jar;

          lib\commons-configuration-1.5-plus-node-clone.jar;

          lib\jsoup-1.6.1.jar;

          lib\commons-lang3-3.1.jar;

          lib\news.migrate.jar;

          com.ibm.lconn.news.migration.next40.NewsMigrationFrom301To40

          -dburl jdbc:db2://dbHost:dbPort/HOMEPAGE

          -dbuser dbUser -dbpassword dbPassword

          -dburl_source jdbc:db2://Profiles_dbHost:Profiles_dbPort/PEOPLEDB

          -dbuser_source Profiles_dbUser -dbpassword_source Profiles_dbPassword

          -storyLifetimeInDays days

          > java.out.log 2>&1

        where

        • jdbc_library_location is the location of your JDBC driver

        • dbHost is the name of the system hosting your DB

        • dbPort is the communications port of the DB

        • dbAlias is the reserved name of the DB, if applicable to your deployment

        • dbUser is the DB administrator ID

        • dbPassword is the administrator password

        where

        • Profiles_dbHost is the name of the system hosting your Profiles DB

        • Profiles_dbPort is the communications port of the Profiles DB

        • Profiles_dbUser is the UID for the Profiles DB

        • Profiles_dbPassword is the password for the Profiles UID

        • days is the number of days to preserve news stories. News stories and notifications that are older than this value are purged from the DB during the migration process.
        The Home page migration process copies data from the Profiles DB. For this reason, you must update the Home page DB before updating the Profiles DB.

      4. Back up the Home page DB again. This additional precaution is recommended because of the complexity of this step. If any failures occur, use the backup to restore your Homepage DB.

      5. db2 -tvf appGrants.sql

      6. db2 -tvf post-java-migration-301-40.sql

      7. db2 -tvf reorg.sql

      8. db2 -tvf updateStats.sql

    14. Metrics: To use the Metrics application, create DBs for Metrics and Cognos.

      1. Change to the Wizards/connections.sql/metrics/db2 directory and run the following commands.

      2. db2 -td@ -vf createDb.sql

      3. db2 -td@ -vf appGrants.sql

      4. Change to the Wizards/connections.sql/cognos/db2 directory and run the following commands.

      5. db2 -td@ -vf createDb.sql

      6. db2 -td@ -vf appGrants.sql

    15. Mobile: Wizards/connections.sql/mobile/db2

      1. db2 -td@ -vf createDb.sql

      2. db2 -td@ -vf appGrants.sql

    16. Profiles: Wizards/connections.sql/profiles/db2
      Ensure that you updated the Home page DB before attempting to update the Profiles DB. This is because the Home page migration process copies data from the Profiles DB.

      1. db2 -tvf upgrade-301-40.sql

      2. db2 -tvf appGrants.sql

    17. Wikis: Wizards/connections.sql/wikis/db2

      1. db2 -td@ -vf upgrade-301-40.sql

      2. db2 -td@ -vf appGrants.sql


    What to do next

    Check that all the DBs are working correctly.

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


    Update 3.0.1 Oracle DBs manually

    Manually update IBM Connections 3.0.1 DBs to version 4.0 in an existing IBM WAS and Oracle DB environment.

    Before applying updates, back up your DBs. For more information, see the Back up IBM Connections topic.

    Install and configured all supporting software for version 4.0.

    Find out the value of the storyLifetimeInDays parameter in the news-config.xml file. You must enter this value when you migrate the Home page DB. The default value is 30. News stories and notifications that are older than this value are purged from the Home page DB during migration. For more information, see the Accessing the News configuration file topic.

    (Oracle only) Ensure that the Statement cache size for the data sources on WAS is no larger than 50. A higher value could lead to Out Of Memory errors on the application server instance. (Oracle only) IBM Connections DBs use SMALLFILE tablespaces which have a size limitation of 222 blocks. When you use 8 KB blocks, this limit is approximately 32 GB. If you anticipate needing more space than this, add additional tablespace files to individual DBs. For detailed information, refer to your Oracle documentation.

    This topic describes how to manually update IBM Connections version 3.0.1 DBs to version 4.0. Use this procedure if you want an alternative to using the DB wizard to update your DBs.

    This topic applies to all releases of version 3.0.1.

    Use the Java Runtime Environment (JRE) under the Wizards directory in the installation media. Update your PATH variable to point to this JRE, using the instructions for your operating system.

    For example, the relative path to the JRE on the Microsoft Windows operating system might be Wizards\jvm\win\jre. For the AIX or Linux operating systems, the relative path might be Wizards/jvm/aix/jre and Wizards/jvm/linux/jre.

    IBM Connections does not support GNU Java.

    You need to use a DB administrator ID to run the Java migration utilities described in this task.

    After running each command, examine the output of the command for error messages. If you find errors, resolve them before continuing with the update process.

    To improve readability, some commands and file paths in this topic are displayed on separate lines. Ignore these formatting conventions when entering the commands.

    To update DBs manually:

    1. Log in to the WAS Integrated Solutions Console on your Deployment Manager.

    2. Go to Applications > Application types > WebSphere enterprise Applications.

    3. Stop all IBM Connections applications.

    4. Ensure that the Oracle driver on your system has the same version number as your Oracle DB server. IBM Connections does not support the Oracle 10.2.0.1 JDBC driver.

    5. Change to the directory containing the scripts.

    6. For each application, enter the following command and then run the appropriate scripts:

      sqlplus /as sysdba

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

      sql> spool on

      sql> spool output_file

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

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

      To manually create the application DB tables:

    7. Activities: Wizards/connections.sql/activities/oracle

      1. @upgrade-301-40.sql

      2. From a command prompt, change to the Wizards directory and enter the following text as a command on a single line:

        • AIX or Linux:

          jvm/OS/jre/bin/java -classpath

          jdbc_library_location/ojdbc6.jar:

          lib/commons-logging-1.0.4.jar:

          lib/lc.util.web-3.0.jar:

          lib/lc.dbmigration.default.jar:

          lib/log4j-1.2.11.jar:

          lib/oa.migrate.jar:

          com.ibm.openactivities.migrate.ActivitiesMigrationDriver

          -dburl jdbc:oracle:thin:@//dbHost:dbPort/ServiceName |

          -dburl jdbc:oracle:thin:@dbHost:dbPort:SID

          -dbuser dbUser -dbpassword dbPassword

          > java.out.log 2>&1

          where OS is the operating system on which the DB is hosted.

        • Windows:

          jvm\win\jre\bin\java -classpath

          jdbc_library_location\ojdbc6.jar;

          lib\commons-logging-1.0.4.jar;

          lib\lc.util.web-3.0.jar;

          lib\lc.dbmigration.default.jar;

          lib\log4j-1.2.11.jar;

          lib\oa.migrate.jar;

          com.ibm.openactivities.migrate.ActivitiesMigrationDriver

          -dburl jdbc:oracle:thin:@//dbHost:dbPort/ServiceName |

          -dburl jdbc:oracle:thin:@dbHost:dbPort:SID

          -dbuser dbUser -dbpassword dbPassword

          > java.out.log 2>&1

        where

        • jdbc_library_location is the location of your JDBC driver

        • dbHost is the name of the system hosting your DB

        • dbPort is the communications port for the DB

        • dbUser is the DB administrator ID

        • dbPassword is the administrator password

        Enter the appropriate dburl parameter depending on whether you are using SERVICE_NAME or SID.

      3. @appGrants.sql

    8. Blogs: Wizards/connections.sql/blogs/oracle

      1. @upgrade-301-40.sql

      2. From a command prompt, change to the Wizards directory and enter the following text as a single command:

        • AIX or Linux:

          jvm/OS/jre/bin/java -classpath

          jdbc_library_location/ojdbc6.jar:

          lib/lc.dbmigration.default.jar:

          lib/blogs.migrate.jar:

          lib/commons-lang-2.4.jar:

          lib/commons-logging-1.0.4.jar:

          com.ibm.lconn.blogs.migration.MigrationFrom301To40

          -dburl jdbc:oracle:thin:@//dbHost:dbPort/ServiceName |

          -dburl jdbc:oracle:thin:@dbHost:dbPort:SID

          -dbuser dbUser -dbpassword dbPassword

          > java.out.log 2>&1

          where OS is the operating system on which the DB is hosted.

        • Windows:

          jvm\win\jre\bin\java -classpath

          jdbc_library_location\ojdbc6.jar;

          lib\lc.dbmigration.default.jar;

          lib\blogs.migrate.jar;

          lib\commons-lang-2.4.jar;

          lib\commons-logging-1.0.4.jar;

          com.ibm.lconn.blogs.migration.MigrationFrom301To40

          -dburl jdbc:oracle:thin:@//dbHost:dbPort/ServiceName | -dburl jdbc:oracle:thin:@dbHost:dbPort:SID

          -dbuser dbUser -dbpassword dbPassword

          > java.out.log 2>&1

        where

        • jdbc_library_location is the location of your JDBC driver

        • dbHost is the name of the system hosting your DB

        • dbPort is the communications port for the DB

        • dbUser is the DB administrator ID

        • dbPassword is the administrator password

        Enter the appropriate dburl parameter depending on whether you are using SERVICE_NAME or SID.

      3. @appGrants.sql

    9. Bookmarks: Wizards/connections.sql/dogear/oracle

      1. @upgrade-301-40.sql

      2. From a command prompt, change to the Wizards directory and enter the following text as a single command:

        • AIX or Linux:

          jvm/OS/jre/bin/java -classpath

          jdbc_library_location/ojdbc6.jar:

          lib/lc.dbmigration.default.jar:

          lib/commons-lang-2.4.jar:

          lib/commons-logging-1.0.4.jar:

          lib/dogear.migrate.jar:

          com.ibm.lconn.dogear.migration.MigrationFrom301To40

          -dburl jdbc:oracle:thin:@//dbHost:dbPort/ServiceName |

          -dburl jdbc:oracle:thin:@dbHost:dbPort:SID

          -dbuser dbUser -dbpassword dbPassword

          > java.out.log 2>&1

          where OS is the operating system on which the DB is hosted.

        • Windows:

          jvm/win/jre/bin/java -classpath

          jdbc_library_location\ojdbc6.jar;

          lib\lc.dbmigration.default.jar;

          lib\commons-lang-2.4.jar;

          lib\commons-logging-1.0.4.jar;

          lib\dogear.migrate.jar;

          com.ibm.lconn.dogear.migration.MigrationFrom301To40

          -dburl jdbc:oracle:thin:@//dbHost:dbPort/ServiceName | -dburl jdbc:oracle:thin:@dbHost:dbPort:SID

          -dbuser dbUser -dbpassword dbPassword

          > java.out.log 2>&1

        where

        • jdbc_library_location is the location of your JDBC driver

        • dbHost is the name of the system hosting your DB

        • dbPort is the communications port for the DB

        • dbUser is the DB administrator ID

        • dbPassword is the administrator password

        Enter the appropriate dburl parameter depending on whether you are using SERVICE_NAME or SID.

      3. @appGrants.sql

    10. Communities: Wizards/connections.sql/communities/oracle

      1. @upgrade-301-40.sql

      2. @appGrants.sql

      3. @calendar-createDb.sql password

        where password is the password for the Communities DB.

      4. @calendar-appGrants.sql

    11. Files: Wizards/connections.sql/files/oracle

      1. @upgrade-301-40.sql

      2. @appGrants.sql

    12. Forum: Wizards/connections.sql/forum/oracle

      1. @upgrade-301-40.sql

      2. @appGrants.sql

    13. Home page: Wizards/connections.sql/homepage/oracle

      1. @upgrade-301-40.sql

      2. Optional: Back up the Home page DB, using your native DB tools. This precaution is recommended because the following migration step is complex and time-consuming. If any failures occur, use the backup to restore your Home page DB.

      3. From a command prompt, change to the Wizards directory and enter the following text as a single command:

        • AIX or Linux:

          jvm/OS/jre/bin/java -Xmx3072m -classpath

          jdbc_library_location/ojdbc6.jar:

          lib/news.core.data.jar:

          lib/news.common.jar:

          lib/news.core.service.jar:

          lib/news.cache.jar:

          lib/lc.dbmigration.default.jar:

          lib/lc.admin.userlifecycle.spi.jar:

          lib/lc.events.newsEjbConsumer.jar:

          lib/lc.events.internal.jar:

          lib/lc.appext.core.api-3.0.jar:

          lib/lc.appext.core.impl-3.0.jar:

          lib/lc.component.integration.news.jar:

          lib/lc.util.base-3.0.jar:

          lib/lc.config.svc-1.1.jar:

          lib/com.ibm.connections.directory.services.jar:

          lib/notify.client.jar:

          lib/lc.mtconfig.engine-1.0.jar:

          lib/lc.mtconfig.svc-1.0.jar:

          lib/icu4j-4_8_1.jar:

          lib/mybatis-2.3.5.jar:

          lib/spring.jar:

          lib/json4j.jar:

          lib/commons-logging-1.0.4.jar:

          lib/commons-dbcp-1.2.1.jar:

          lib/commons-collections-3.2.1.jar:

          lib/commons-pool-1.2.jar:

          lib/commons-lang-2.4.jar:

          lib/commons-configuration-1.5-plus-node-clone.jar:

          lib/jsoup-1.6.1.jar:

          lib/commons-lang3-3.1.jar:

          lib/news.migrate.jar:

          com.ibm.lconn.news.migration.next40.NewsMigrationFrom301To40

          -dburl jdbc:oracle:thin:@//dbHost:dbPort/ServiceName |

          -dburl jdbc:oracle:thin:@dbHost:dbPort:SID

          -dbuser dbUser -dbpassword dbPassword

          -dburl_source jdbc:oracle:thin@//Profiles_dbHost:Profiles_dbPort:Profiles_ServiceName |

          -dburl_source jdbc:oracle:thin@Profiles_dbHost:Profiles_dbPort:Profiles_SID

          -dbuser_source Profiles_dbUser -dbpassword_source Profiles_dbPassword

          -storyLifetimeInDays days

          > java.out.log 2>&1

          where OS is the operating system on which the DB is hosted.

        • Windows:

          jvm\win\jre\bin\java -Xmx3072m -classpath

          jdbc_library_location\ojdbc6.jar;

          lib\news.core.data.jar;

          lib\news.common.jar;

          lib\news.core.service.jar;

          lib\news.cache.jar;

          lib\lc.dbmigration.default.jar;

          lib\lc.admin.userlifecycle.spi.jar;

          lib\lc.events.newsEjbConsumer.jar;

          lib\lc.events.internal.jar;

          lib\lc.appext.core.api-3.0.jar;

          lib\lc.appext.core.impl-3.0.jar;

          lib\lc.component.integration.news.jar;

          lib\lc.util.base-3.0.jar;

          lib\lc.config.svc-1.1.jar;

          lib\com.ibm.connections.directory.services.jar;

          lib\notify.client.jar;

          lib\lc.mtconfig.engine-1.0.jar;

          lib\lc.mtconfig.svc-1.0.jar;

          lib\icu4j-4_8_1.jar;

          lib\mybatis-2.3.5.jar;

          lib\spring.jar;

          lib\json4j.jar;

          lib\commons-logging-1.0.4.jar;

          lib\commons-dbcp-1.2.1.jar;

          lib\commons-collections-3.2.1.jar;

          lib\commons-pool-1.2.jar;

          lib\commons-lang-2.4.jar;

          lib/commons-configuration-1.5-plus-node-clone.jar;

          lib\jsoup-1.6.1.jar;

          lib\commons-lang3-3.1.jar;

          lib\news.migrate.jar;

          com.ibm.lconn.news.migration.next40.NewsMigrationFrom301To40

          -dburl jdbc:oracle:thin:@//dbHost:dbPort/ServiceName |

          -dburl jdbc:oracle:thin:@dbHost:dbPort:SID

          -dbuser dbUser -dbpassword dbPassword

          -dburl_source jdbc:oracle:thin@//Profiles_dbHost:Profiles_dbPort/Profiles_ServiceName |

          -dburl_source jdbc:oracle:thin@Profiles_dbHost:Profiles_dbPort:Profiles_SID

          -dbuser_source Profiles_dbUser -dbpassword_source Profiles_dbPassword

          -storyLifetimeInDays days

          > java.out.log 2>&1

        where

        • jdbc_library_location is the location of your JDBC driver

        • dbHost is the name of the system hosting your DB

        • dbPort is the communications port for the DB

        • dbUser is the DB administrator ID

        • dbPassword is the administrator password

        Enter the appropriate dburl parameter depending on whether you are using SERVICE_NAME or SID.

        where

        • Profiles_dbHost is the name of the system hosting your Profiles DB

        • Profiles_dbPort is the communications port of the Profiles DB

        • Profiles_dbUser is the UID for the Profiles DB

        • days is the number of days to preserve news stories. News stories and notifications that are older than this value are purged from the DB during the migration process.

        The Home page migration process copies data from the Profiles DB. For this reason, you must update the Home page DB before updating the Profiles DB.

      4. Back up the Home page DB again. This additional precaution is recommended because of the complexity of this step. If any failures occur, use the backup to restore your Homepage DB.

      5. @appGrants.sql

      6. @post-java-migration-301-40.sql

    14. Metrics: To use the Metrics application, create DBs for Metrics and Cognos.

      1. Change to the Wizards/connections.sql/metrics/oracle directory and run the following commands.

      2. @createDb.sql password

        where password is the password for the Communities DB.

      3. @appGrants.sql

      4. Change to the Wizards/connections.sql/cognos/oracle directory and run the following commands.

      5. @createDb.sql password

        where password is the password for the Communities DB.

      6. @appGrants.sql

    15. Mobile: Wizards/connections.sql/mobile/oracle

      1. @createDb.sql password

      2. @appGrants.sql

    16. Profiles: Wizards/connections.sql/profiles/oracle

      Ensure that you updated the Home page DB before attempting to update the Profiles DB. This is because the Home page migration process copies data from the Profiles DB.

      1. @upgrade-301-40.sql

      2. @appGrants.sql

    17. Wikis: Wizards/connections.sql/wikis/oracle

      1. @upgrade-301-40.sql

      2. @appGrants.sql


    What to do next

    Check that all the DBs are working correctly.


    Update 3.0.1 SQL Server DBs manually

    Manually update IBM Connections 3.0.1 DBs to version 4.0 in an existing IBM WAS and Microsoft SQL Server DB environment.

    Before applying updates, back up your DBs. For more information, see the Back up IBM Connections topic.

    Find out the value of the storyLifetimeInDays parameter in the news-config.xml file. You must enter this value when you migrate the Home page DB. The default value is 30. News stories and notifications that are older than this value are purged from the Home page DB during migration. For more information, see the Accessing the News configuration file topic.

    Install and configured all supporting software for version 4.0.

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

    This topic describes how to manually update IBM Connections version 3.0.1 DBs to version 4.0. Use this procedure if you want an alternative to using the DB wizard to update your DBs.

    This topic applies to all releases of version 3.0.1.

    Use the Java Runtime Environment (JRE) under the Wizards directory in the installation media. Update your PATH variable to point to this JRE, using the instructions for your operating system.

    For example, the relative path to the JRE on the Microsoft Windows operating system might be Wizards\jvm\win\jre. For the AIX or Linux operating systems, the relative path might be Wizards/jvm/aix/jre and Wizards/jvm/linux/jre.

    IBM Connections does not support GNU Java.

    You need to use a DB administrator ID to run the Java migration utilities described in this task.

    After running each command, examine the output of the command for error messages. If you find errors, resolve them before continuing with the update process.

    To improve readability, some commands and file paths in this topic are displayed on separate lines. Ignore these formatting conventions when entering the commands.

    To update DBs manually:

    1. Log in to the WAS Integrated Solutions Console on your Deployment Manager.

    2. Go to Applications > Application types > WebSphere enterprise Applications.

    3. Stop all IBM Connections applications.

    4. Log in as the DB administrator and change to the directory containing the scripts. The relative path is shown in the step for each application.

    5. For each application, run the appropriate scripts by entering the commands shown in the following list. In these commands, dbPassword is the password for the SQL Server user named sa. If your DB server has multiple SQL Server instances installed, add the following text as the first parameter to each command:

      -S sqlserver_server_name\sqlserver_server_instance_name

      where

      • sqlserver_server_name is the name of your SQL Server DB server

      • sqlserver_server_instance_name is the name of your current instance

      To capture the output of each command to a log file, append the following parameter to each command:

      >> \file_path\db_application.log

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

      For example:

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

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

    6. Activities: Wizards\connections.sql\activities\sqlserver

      1. sqlcmd -U dbUser -P dbPassword -i upgrade-301-40.sql

        where

        • dbUser is the DB UID

        • dbPassword is the administrator password
        This script generates a message that states Change any part of an object name could break scripts and stored procedures. You can safely ignore the message.

      2. From a command prompt, change to the Wizards directory and enter the following text as a single command:

        jvm\win\jre\bin\java -classpath

        jdbc_library_location\sqljdbc4.jar;

        lib\lc.dbmigration.default.jar;

        lib\lc.util.web-3.0.jar;

        lib\log4j-1.2.11.jar;

        lib\oa.migrate.jar;

        lib\commons-logging-1.0.4.jar

        com.ibm.openactivities.migrate.ActivitiesMigrationDriver

        -dburl jdbc:sqlserver://dbHost:dbPort;DBName=OPNACT

        -dbuser dbUser -dbpassword dbPassword

        > java.out.log 2>&1

      3. sqlcmd -U dbUser -P dbPassword -i appGrants.sql

      where

      • jdbc_library_location is the location of your JDBC driver

      • dbHost is the name of the system hosting your DB

      • dbPort is the communications port of the DB

      • dbAlias is the reserved name of the DB, if applicable to your deployment

      • dbUser is the DB administrator ID

      • dbPassword is the administrator password

    7. Blogs: Wizards\connections.sql\blogs\sqlserver

      1. sqlcmd -U dbUser -P dbPassword -i upgrade-301-40.sql

      2. From a command prompt, change to the Wizards directory and enter the following text as a single command:

        jvm\win\jre\bin\java -classpath

        jdbc_library_location\sqljdbc4.jar;

        lib\lc.dbmigration.default.jar;

        lib\blogs.migrate.jar;

        lib\commons-lang-2.4.jar;

        lib\commons-logging-1.0.4.jar;

        com.ibm.lconn.blogs.migration.MigrationFrom301To40

        -dburl jdbc:sqlserver://dbHost:dbPort;DBName=BLOGS

        -dbuser dbUser -dbpassword dbPassword

        > java.out.log 2>&1

      3. sqlcmd -U dbUser -P dbPassword -i appGrants.sql

    8. Bookmarks: Wizards\connections.sql\dogear\sqlserver

      1. sqlcmd -U dbUser -P dbPassword -i upgrade-301-40.sql

      2. From a command prompt, change to the Wizards directory and enter the following text as a single command:

        jvm\win\jre\bin\java -classpath

        jdbc_library_location\sqljdbc4.jar;

        lib\lc.dbmigration.default.jar;

        lib\commons-lang-2.4.jar;

        lib\commons-logging-1.0.4.jar;

        lib\dogear.migrate.jar;

        com.ibm.lconn.dogear.migration.MigrationFrom301To40

        -dburl jdbc:sqlserver://dbHost:dbPort;DBName=DOGEAR

        -dbuser dbUser -dbpassword dbPassword

        > java.out.log 2>&1

      3. sqlcmd -U dbUser -P dbPassword -i appGrants.sql

    9. Communities: Wizards\connections.sql\communities\sqlserver

      1. sqlcmd -U dbUser -P dbPassword -i upgrade-301-40.sql

      2. sqlcmd -U dbUser -P dbPassword appGrants.sql

      3. sqlcmd -U dbUser -P dbPassword calendar-createDb.sql

      4. sqlcmd -U dbUser -P dbPassword calendar-appGrants.sql

    10. Files: Wizards\connections.sql\files\sqlserver

      1. sqlcmd -U dbUser -P dbPassword -i upgrade-301-40.sql

      2. sqlcmd -U dbUser -P dbPassword -i appGrants.sql

    11. Forum: Wizards\connections.sql\forum\sqlserver

      1. sqlcmd -U dbUser -P dbPassword -i upgrade-301-40.sql

      2. sqlcmd -U dbUser -P dbPassword -i appGrants.sql

    12. Home page: Wizards\connections.sql\homepage\sqlserver

      1. sqlcmd -U dbUser -P dbPassword -i upgrade-301-40.sql -v filepath=path_to_db password=Homepage_password

        where path_to_db is the full file path to the Home page DB and Homepage_password is the HOMEPAGEUSER password.

      2. Optional: Back up the Home page DB, using your native DB tools. This precaution is recommended because the following migration step is complex and time-consuming. If any failures occur, use the backup to restore your Home page DB.

      3. From a command prompt, change to the Wizards directory and enter the following text as a single command:

        jvm\win\jre\bin\java -Xmx3072m -classpath

        jdbc_library_location\sqljdbc4.jar;

        lib\news.core.data.jar;

        lib\news.common.jar;

        lib\news.core.service.jar;

        lib\news.cache.jar;

        lib\lc.dbmigration.default.jar;

        lib\lc.admin.userlifecycle.spi.jar;

        lib\lc.events.newsEjbConsumer.jar;

        lib\lc.events.internal.jar;

        lib\lc.appext.core.api-3.0.jar;

        lib\lc.appext.core.impl-3.0.jar;

        lib\lc.component.integration.news.jar;

        lib\lc.util.base-3.0.jar;

        lib\lc.config.svc-1.1.jar;

        lib\com.ibm.connections.directory.services.jar;

        lib\notify.client.jar;

        lib\lc.mtconfig.engine-1.0.jar;

        lib\lc.mtconfig.svc-1.0.jar;

        lib\icu4j-4_8_1.jar;

        lib\mybatis-2.3.5.jar;

        lib\spring.jar;

        lib\json4j.jar;

        lib\commons-logging-1.0.4.jar;

        lib\commons-dbcp-1.2.1.jar;

        lib\commons-collections-3.2.1.jar;

        lib\commons-pool-1.2.jar;

        lib\commons-lang-2.4.jar;

        lib\commons-configuration-1.5-plus-node-clone.jar;

        lib\jsoup-1.6.1.jar;

        lib\commons-lang3-3.1.jar;

        lib\news.migrate.jar;

        com.ibm.lconn.news.migration.next40.NewsMigrationFrom301To40

        -dburl jdbc:sqlserver://dbHost:dbPort;DBName=HOMEPAGE

        -dbuser dbUser -dbpassword dbPassword

        -dburl_source jdbc:sqlserver://Profiles_dbHost:Profiles_dbPort;DBName=PEOPLEDB

        -dbuser_source Profiles_dbUser -dbpassword_source Profiles_dbPassword

        -storyLifetimeInDays days

        > java.out.log 2>&1

        where

        • Profiles_dbHost is the name of the system hosting your Profiles DB.

        • Profiles_dbPort is the communications port of the Profiles DB.

        • Profiles_dbUser is the UID for the Profiles DB.

        • days is the number of days to preserve news stories. News stories and notifications that are older than this value are purged from the DB during the migration process.

        The Home page migration process copies data from the Profiles DB. For this reason, you must update the Home page DB before updating the Profiles DB.

      4. sqlcmd -U dbUser -P dbPassword -i appGrants.sql

      5. Back up the Home page DB again. This additional precaution is recommended because of the complexity of this step. If any failures occur, use the backup to restore your Homepage DB.

      6. sqlcmd -U dbUser -P dbPassword -i post-java-migration-301-40.sql

      7. sqlcmd -U dbUser -P dbPassword -i updateStats.sql

    13. Metrics: To use the Metrics application, create DBs for Metrics and Cognos.

      1. Change to the Wizards/connections.sql/metrics/sqlserver directory and run the following commands.

      2. sqlcmd -U dbUser -P dbPassword -i "createDb.sql" -v filepath="path_to_db" password="password_for_METRICSUSER"

        where

        • dbUser and dbPassword are the credentials for a UID with administrative privileges.

        • path_to_db is the directory in which the new DB is stored.

        • password_for_application_user is the password for the DB.

        • password_for_METRICSUSER is the password for the DB UID for Metrics.

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

      3. sqlcmd -U dbUser -P dbPassword appGrants.sql

      4. Change to the Wizards/connections.sql/cognos/sqlserver directory and run the following commands.

      5. sqlcmd -U dbUser -P dbPassword -i "createDb.sql" -v filepath="path_to_db" password="password_for_COGNOSUSER"

        where password_for_COGNOSUSER is the password for the DB UID for Cognos.

      6. sqlcmd -U dbUser -P dbPassword appGrants.sql

    14. Mobile: Wizards/connections.sql/mobile/sqlserver

      1. sqlcmd -U dbUser -P dbPassword -i "createDb.sql" -v filepath="path_to_db" password="password_for_MOBILEUSER"

        where password_for_MOBILEUSER is the password for the DB UID for Mobile.

      2. sqlcmd -U dbUser -P dbPassword appGrants.sql

    15. Profiles: Wizards\connections.sql\profiles\sqlserver

      Ensure that you updated the Home page DB before attempting to update the Profiles DB. This is because the Home page migration process copies data from the Profiles DB.

      1. sqlcmd -U dbUser -P dbPassword -i upgrade-301-40.sql

        This script generates a message that states Change any part of an object name could break scripts and stored procedures. You can safely ignore the message.

      2. sqlcmd -U dbUser -P dbPassword -i appGrants.sql

    16. Wikis: Wizards\connections.sql\wikis\sqlserver

      1. sqlcmd -U dbUser -P dbPassword -i upgrade-301-40.sql

      2. sqlcmd -U dbUser -P dbPassword -i appGrants.sql


    What to do next

    Check that all the DBs are working correctly.


    Restore DBs

    Restore your DBs if you need to roll back a failed update.

    Use the DB utilities provided by your DB vendor to roll back your DBs. For more information, refer to the vendor's product documentation.


    Uninstall a deployment before migration

    Uninstall a deployment of IBM Connections before migrating to a later version.

    If you are installing IBM Connections 4.0 side-by-side with your current deployment, you do not need to complete this task. For more information, see the Migrating to IBM Connections 4.0 topic.

    Back up your current deployment. For more information, see the Back up IBM Connections topic.

    To uninstall IBM Connections, complete the following steps:

    1. Start the IBM WAS Deployment Manager.

    2. Stop all instances of WAS, including node agents, in your deployment.

    3. Open a command prompt and change to the IM_root/eclipse directory.

    4. Start the installation wizard by opening the following file:

      • AIX or Linux:

        ./launcher

      • Windows:

        launcher.exe

    5. Click Uninstall.

    6. Select the IBM Connections package group and click Next.

    7. Click Uninstall to begin uninstalling.

    8. When the process is complete, restart the Deployment Manager.

    9. Restart all instances of WAS, including node agents.

    10. Synchronize the nodes.

    11. To check the details of the procedure, open the log files in connections_root/logs. Each IBM Connections application that you uninstalled has a log file that uses the following naming format: application_nameUninstall.log, where application_name is the name of an IBM Connections application.

    12. Optional: If you plan to reinstall IBM Connections, remove the following files:

      Except where noted, remove these files from the system that hosts the Deployment Manager.

      Because some of these files might be used by other programs, it is possible that you are not allowed to remove all of the following files.

      1. IBM Connections installation files: connections_root

        If you did not install IBM Connections in the default directory, delete the directory where you installed the product.

      2. IBM Connections shared data: Delete the directories specified for shared data when you installed IBM Connections.

      3. IBM Connections local data: On each node, delete the directories specified for local data when you installed IBM Connections.

      4. IBM Connections configuration files: Delete the profile_root/config/cells/cell_name/LotusConnections-config directory, where cell_name is the name of your WAS cell.

      5. If it is present, delete the registry.xml file from the profile_root/config/cells/cell_name directory.

      6. Delete all .py files from the /opt/IBM/WebSphere/AppServer/profiles/profile_name/bin directory on the deployment manager server.

      > Delete IBM Connections data files makes the original deployment unrecoverable. If you plan to reinstall IBM Connections and use your old data, do not delete the data files.

      > You do not need to remove IBM Installation Manager files. These files might be associated with other IBM applications.


    Results

    You uninstalled IBM Connections.


    Install IBM Connections 4.0 for migration

    Install IBM Connections.


    Ensure that you complete all the prerequisite tasks that are relevant for your environment. For more information, see the Before installing topic.

    To install IBM Connections, run the IBM Installation Manager wizard on the system where the Deployment Manager is installed.

    If an error occurs during installation, IBM Installation Manager cancels the installation and rolls back the installation files. Installation errors are usually caused by environment problems such as insufficient disk space, privilege issues, or corruption of a WebSphere profile. If your installation is canceled, complete the following steps:

    1. Identify and resolve the error that caused the cancellation. After canceling the installation, IBM Installation Manager displays an error message with an error code. You can look up the error code in the Installation error messages topic or check the log files.

    2. Restore the Deployment Manager profile from your backup.

    3. Delete the connections_root directory.

    4. Start this task again.

    To install IBM Connections, complete the following steps:

    1. On each node, stop any running instances of WAS and WebSphere node agents.

    2. Start WAS Network Deployment Manager.

    3. Copy the installation files to the system hosting the Deployment Manager.

      Ensure that the directory path that you enter contains no spaces.

    4. From the Connections setup directory, run the file to start the IBM Connections launchpad:

      • AIX or Linux: Connections set-up/launchpad.sh

      • Windows: Connections set-up\launchpad.exe

      The launchpad needs a web browser to run. If your system does not have a web browser, take one of the following actions:

      • Install a web browser.

      • Install IBM Connections in silent mode. For more information, see the Installing silently topic.

      • Start IBM Installation Manager manually:

        1. Open a command prompt.

        2. Change to the Connections_install/IM/OS directory, where OS is your operating system.

        3. Enter ./install.sh -input response.xml.

    5. Click Install IBM Connections 4.0 and then click Launch the IBM Connections 4.0 install wizard.

      Click the links to Documentation, Pre-installation tasks, or Post-installation tasks to view the product documentation.

    6. In the Select packages to install window, select the packages to install and click Next to continue.

      Accept the default setting for Show all versions.

      If you are using an earlier version of IBM Installation Manager than 1.4.4, the 1.4.4 package is selected in this window.

      Click Check for Other Versions and Extensions to search for updates to IBM Installation Manager.

    7. Review and accept the license agreement by clicking I accept the terms in the license agreements. Click Next.

    8. Set the location of shared directories for IBM Installation Manager.

      1. Set the location of the Shared Resources Directory.

      2. Set the location of the Installation Manager Directory. This option appears only if you have not previously installed IBM Installation Manager.

      3. Click Next.

      > The Shared Resources directory stores resources that can be shared by multiple packages. If you used IBM Installation Manager before, the wizard automatically enters this value.

      > The Installation Manager directory stores resources that are unique to the packages that you are installing.

    9. Choose to Use the existing package group or Create a new package group.

      If you are using the wizard for the first time, the Use the existing package group option is not available.

    10. Set the location of the installation directory for IBM Connections. You can accept the default directory location, enter a new directory name, or click Browse to select an existing directory. Click Next.

    11. Confirm the applications to install and click Next. You can select from the following options:

      • The wizard always installs the Home page, News, and Search applications.

      • To use media gallery widgets in the Communities application, you must install the Files application. Media gallery widgets store photo and video files in the Files DB.

      • Even if you are not configuring Cognos yet, install Metrics now so that your application data is captured from the moment that IBM Connections is deployed. Metrics captures your deployment data whereas Cognos is used for viewing data reports. If you install Metrics at a later stage, you will not have any data reports for the period before you installed Metrics.

      Option Description
      IBM Connections 4.0 Install all IBM Connections applications.

      Activities Collaborate with colleagues.

      Blogs Write personal perspectives about projects.

      Communities Interact with people on shared projects.

      Bookmarks Bookmark important websites.

      Files Share files among users.

      Forums Discuss projects and exchange information.

      Metrics Identify and analyze usage and trends.

      Mobile Access IBM Connections from mobile devices.

      Moderation Forum and community owners can moderate the content of forums.

      Profiles Find people in the organization.

      Wikis Create content for your website.

    12. Enter the details of your WAS environment:

      1. Select the WAS installation location that contains the Deployment Manager.

        Note the default path to the WAS installation:

        • AIX: /usr/IBM/WebSphere/AppServer

        • Linux: /opt/IBM/WebSphere/AppServer

        • Windows: C:\Program Files\IBM\WebSphere\AppServer

      2. Enter the properties of the WAS Deployment Manager (DM):

        Deployment Manager profile

        Name of the DM to use for IBM Connections. The wizard automatically detects any available DMs.

        Host name

        Name of the host DM server.

        Administrator ID

        The administrative ID of the DM.
        This ID is set to the connectionsAdmin J2C authentication alias, which is mapped to the following J2EE roles: dsx-admin, widget-admin, and search-admin. It is also used by the service integration bus. To use security management software such as Tivoli Access Manager or SiteMinder, the ID that you specify here must exist in the LDAP directory. For more information, see the Switching to unique administrator IDs for system level communication topic.

        Administrator Password

        The password for the administrative ID of the DM.

        SOAP port

        The SOAP port of the DM. The wizard automatically detects this value.

      3. Click Validate to verify the DM information that you entered and that application security is enabled on WAS. If the verification fails, IBM Installation Manager displays an error message.

        (AIX and Linux) The validation process checks the number of open files that are supported by your system. If the value for this parameter, known as the Open File Descriptor limit, is too low, a file open error, memory allocation failure, or connection establishment error could occur. If one of these errors occurs, exit the installation wizard and increase the open file limit before restarting the wizard. To set the file limit, go to the Installation error messages topic and search for error code CLFRP0042E. The recommended value for IBM Connections is 8192. For more information about the Open File Descriptor limit, see the documentation for your operating system.

      4. When the verification test is successful, click Next.

      The wizard creates a dmInfo.properties file under WAS to record details of the cell, node, and server.

    13. Configure your topology. For more information about each option, see the Deployment options topic.

      If you return to this page from a later page in the installation wizard, your settings are still present but not visible. If you want to change any settings, you must enter all of the information again. If you do not want to change your initial settings, click Next.

      • Small deployment:

        1. Select the Small deployment topology.

        2. Enter a Cluster name for the topology.

        3. Select a Node.

        4. Click Next.

      • Medium deployment:

        1. Select the Medium deployment topology.

        2. Select the default value or enter a Cluster name for each application or for groups of applications.

          For example, use Cluster1 for Activities, Communities, and Forums.

          IBM Installation Manager creates servers and clusters when required.

        3. Select a Node for each cluster. Accept the predefined node or select a different node.
          These nodes host application server instances that serve IBM Connections applications. You can assign multiple nodes to a cluster, where each node is a server member of that cluster.

        4. Enter a Server member name for the selected node. Choose the default or enter a custom name.

          If you enter a custom server member name, the name must be unique across all nodes in your deployment.

        5. Click Next.

      • Large deployment:

        1. Select the Large deployment topology.

        2. Enter a Cluster name for each application.

          IBM Installation Manager creates servers and clusters when required.

        3. Select a Node for each cluster. Accept the predefined node or select a different node.
          These nodes host application server instances that serve IBM Connections applications. You can assign multiple nodes to a cluster, where each node is a server member of that cluster.

        4. Enter a Server member name for the selected node. Choose the default or enter a custom name.

          If you enter a custom server member name, the name must be unique across all nodes in your deployment.

        5. Click Next.

    14. Enter the DB information:

      If you return to this page from a later page in the installation wizard, your settings are still present but not visible. If you want to change any settings, you must enter all of the information again. If you do not want to change your initial settings, click Next.

      1. Specify whether the installed applications use the same DB server or instance: Select Yes or No.

        If allowed by your DB configuration, you can select multiple DB instances as well as different DB servers.

      2. Select a Database type from one of the following options:

        • IBM DB2 Universal Database
        • Oracle Enterprise Edition
        • Microsoft SQL Server Enterprise Edition

      3. Enter the Database server host. For example: appserver.enterprise.example.com

        If your installed applications use different DB servers, enter the DB host for each application.

      4. Enter the Port number of the DB server. The default values are: 50000 for DB2, 1521 for Oracle, and 1433 for SQL Server.

        If your installed applications use different DB servers or instances, enter the port for each DB server or instance.

      5. Enter the JDBC driver location. For example:

        • AIX: /usr/IBM/WebSphere/AppServer/lib

        • Linux:

          /opt/IBM/WebSphere/AppServer/lib

        • Windows:

          C:\IBM\WebSphere\Appserver\lib

      6. Ensure that the following JDBC driver libraries are present in the JDBC directory:

        DB2

        db2jcc.jar and db2jcc_license_cu.jar

        Ensure that your user account has the necessary permissions to access the DB2 JDBC files.

        Oracle

        ojdbc6.jar

        SQL Server

        Download the SQL Server JDBC 2 driver from the Microsoft website to a local directory and enter that directory name in the JDBC driver library field.

        The directory must not contain the sqljdbc.jar file, only the sqljdbc4.jar file. Even though the data source is configured to use the sqljdbc4.jar file, an exception occurs if both files are present in the same directory.

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

      7. Enter the User ID and Password for each DB. If each DB uses the same user credentials, select the Use the same password for all applications check box and then enter the UID and password for the first DB in the list.

        If your DB type is Oracle, connect to the DB with the UID that you used when you created the application DB.

      8. Click Validate to verify your DB settings. If the validation fails, check your DB settings. When the validation succeeds, click Next.

        IBM Installation Manager tests your DB connection with the DB values that you supplied. You can change the DB configuration later in the WAS Integrated Solutions Console.

    15. Specify your Cognos configuration details as explained in the table, and then click Validate to verify your connection.

      • The IBM Cognos configuration panel appears only if you chose to install the Metrics application earlier in this task.

      • Ensure that Cognos Business Intelligence Server is running because the wizard pings the server during the validation process.

      • If you do not want to deploy Cognos now, enter dummy values for UID and password, click Load node info, and then click Validate. Ignore the error message that appears. To continue installing IBM Connections, click Next. For information about deploying Cognos, see the Installing Cognos Business Intelligence topic. For information about resolving Cognos validation problems, see the Troubleshooting Cognos validation problems topic.

      Option Description
      Administrator UID Set the user name of the administrator account that you selected for Cognos Business Intelligence. This user must be included in the LDAP directory used with Connections.

      Administrator password Set the password for the Cognos administrator.

      Name Click the Load node info button to retrieve the list of available nodes and profiles, then click the arrow and select the WebSphere profile that hosts the Cognos BI server. The profile you select here must match the profile you specified as the was.profile.name in the cognos-setup.properties file.

      Host name

      This is a non-editable field that is populated when you select a profile in the Name field. Seeing the associated host for each profile/node can help you choose the correct node where the Cognos BI Server is running.

      Server name There might be multiple servers installed on the same computer as the Cognos BI server; click the arrow and select the instance that represents the Cognos server. Must match what you specified as the cognos.was.server.name in the cognos-setup.properties file.
      Tip: A default value of cognos_server was assigned in the properties file, so unless you changed that value, use it now.

      Port Set the number of the port that the Cognos BI Server is listening on; this defaults to port 9080 but might have been changed. You can determine the port by checking the WC_defaulthost value in the following file: WAS_install_root/config/cells/Cell_Name/nodes/Node_Name/serverindex.xml; for example on

      Windows:

      C:\IBM\WebSphere\AppServer\profiles\AppSvr01\config\cells\lc40Cell01\nodes\lc40CellManager01\serverindex.xml

      Web context root The context root determines which requests will be delegated to the Cognos application for processing (any request beginning with this string will be handled by Cognos). Must match the cognos.contextroot specified in the cognos-setup.properties file.
      Tip: A default value of cognos was assigned in the properties file, so unless you changed that value, use it now.

      If you deployed Cognos Business Intelligence and the validation fails at this point, you can click Next and continue installing IBM Connections. After the installation is complete, you can correct the validation issue as explained in the topic, Troubleshooting Cognos validation problems.

    16. Set the locations of the content stores. All nodes in a cluster must have read-write access to shared content. Both shared and local content stores must be accessible using the same path from all nodes and from the DM. Each content store is represented by a corresponding WebSphere variable that is further defined as shared or local. Local content is node-specific.

      If you are migrating from IBM Connections 3.0.1, you can reuse your existing content stores in 4.0. For more information, see the Content store migration topic.

      1. Enter the location of the Shared content store. The shared content store usually resides in a shared repository that grants read-write access to the DM and all the nodes. Use one of the following methods to create a shared data directory:

        • Network-based file shares (for example: NFS, SMB/Samba, and so on)

        • Storage area network drives (SAN)

        • If you are using a shared-file system on Microsoft Windows, specify the file location using the Universal Naming Convention (UNC) format. For example: \\server_name\share_name.
          (Windows only) If you use Remote Desktop Connection to map shared folder drives, ensure that you use the same session to start the node agents. Otherwise, the shared drives might be invisible to the nodes.

      2. Enter the location of the Local content store.

      3. Click Validate to verify that the account that you are using to install IBM Connections has write access to the content store.

      4. Click Next.

    17. Select a Notification solution. Notifications are email messages to users about new information and events in your IBM Connections deployment.

      • Enable Notification only.

        Use notifications but without the ReplyTo capability.

      • Enable Notification and ReplyTo.

        Use notifications and the ReplyTo capability. To use ReplyTo, your mail server must be able to receive all the replies and funnel these replies into a single inbox. IBM Connection connects to the mail server using the IMAP protocol.

      • None.

        Do not use a notification solution in your IBM Connections deployment. You can configure notifications after installation.

    18. Select and specify a mail server solution and then click Next.

      • WebSphere Java Mail Session: Use a single mail server for all notifications. Select this option if you can access an SMTP server directly using the host.

        Complete the following fields to identify the mail server to use for sending email:

        Host name of SMTP messaging server

        Enter the host or IP address of the preferred SMTP mail server.

        This SMTP server requires authentication

        Select the check box to force authentication when mail is sent from this server.

        User ID

        If the SMTP server requires authentication, enter the UID.

        Password

        If the SMTP server requires authentication, enter the user password.

        Encrypt outgoing mail traffic to the SMTP messaging server using SSL

        Select this check box if you want to encrypt outgoing mail to the SMTP server.

        Port

        Accept the default port of 25, or enter port 465 if you are using SSL.

      • DNS MX Records: Use information from DNS to determine which mail servers to use. Select this option if you use a Domain Name System (DNS) server to access the SMTP messaging server.

        Messaging domain name

        Enter the name or IP address of the messaging domain.

        Choose a specific DNS server

        Select this check box if you want to specify a unique SMTP server.

        DNS server for the messaging servers query

        Enter the host or IP address of the DNS server.

        DNS port used for the messaging servers query

        Enter the port that is used for sending queries using the messaging server.

        This SMTP server requires authentication

        Select the check box to force authentication when notification mail is sent from this server.

        User ID

        If SMTP authentication is required, enter the administrator user ID for the SMTP server.

        Password

        If SMTP authentication is required, enter the password for the administrator user of the SMTP server.

        Encrypt outgoing mail traffic to the SMTP messaging server using SSL

        Select the check box if you want to use the Secure Sockets Layer (SSL) when connecting to the SMTP server.

        Port

        Set the port to use for the SMTP server connection. The default port for the SMTP protocol is 25. The default port number for SMTP over SSL is 465.

      • If you click Do not enable Notification, IBM Installation Manager skips the rest of this step. You can configure notification later.

    19. If you selected the Notification and ReplyTo option, configure the ReplyTo email settings. IBM Connections uses a unique ReplyTo address to identify both the person who replied to a notification and the event or item that triggered the notification.

      1. Enter a domain name. For example: mail.example.com.

        This domain name is used to build the ReplyTo address. The address consists of the suffix or prefix, a unique key, and the domain name.

      2. The reply email address is given a unique ID by the system. You can customize the address by adding a prefix or suffix, using a maximum of 28 characters. This extra information is useful if the domain name is already in use for other purposes. Select one of the following options:

        None

        Use the ID generated by the system.

        Prefix

        Enter a prefix in the Example field.

        Suffix

        Enter a suffix in the Example field.

        As you select an option, the wizard creates an example of the address, combining your selection with the ID generated by the system.

        For example:

        • unique_id@domain

        • prefix_unique_id@domain

        • unique_id_suffix@domain -

      3. Specify the details of the mail file to which ReplyTo emails are sent:

        Server

        The domain where your mail server is located. For example: replyTo.mail.example.com.

        User ID

        The user account for the mail server. The UID and password are credentials that IBM Connections will use to poll the inbox on the mail server to retrieve the replies and process the content. IBM Connections connects to the mail server using IMAP.

        Password

        Password for the user account. The UID and password are credentials that IBM Connections will use to poll the inbox on the mail server to retrieve the replies and process the content. IBM Connections connects to the mail server using IMAP.

      4. Click Next.
      You can modify the ReplyTo settings after installation. To edit the domain name and prefix or suffix, edit the news-config.xml file. For more information, see the Post-migration step for status updates topic. To edit the server and authentication details, log in to the WAS Integrated Solutions Console and navigate to the Mail Sessions page, where you can edit the configuration.

    20. Review the information that you have entered. To revise your selections, click Back. To finalize the installation, click Next.

    21. Review the result of the installation. Click Finish to exit the installation wizard.

    22. Restart the Deployment Manager:

      • AIX or Linux: Open a command prompt and change to the profile_root/Dmgr01/bin directory. Enter the ./stopManager.sh command and then enter the ./startManager.sh command.

      • Windows: Stop and restart the Deployment Manager service.

    23. Start all the federated nodes and enter the startNode command. Repeat these steps for each node:

      1. Log in to a node.

      2. From a command line, change to the profile_root/bin directory.

      3. Enter the startNode command for your operating system:

        • AIX or Linux: ./startNode.sh

        • Windows: startNode.bat

    24. Log in to the Integrated Solutions Console on the DM to perform a full synchronization of all nodes.

      1. Go to System administration > Nodes.

      2. Select the nodes and click Full Resynchronize.

      Wait until the DM copies all the application EAR files to the installedApps directory on each of the nodes. This process can take up to 30 minutes.

      To verify that the DM has distributed the application EAR files to the nodes, check the SystemOut.log file of each node agent. The default path to the SystemOut.log file on a node is profile_root/logs/nodeagent.

      Look for a message such as the following example: ADMA7021I: Distribution of application application_name completed successfully. where application_name is the name of an IBM Connections application.

    25. Restart the Deployment Manager.

    26. Start all your IBM Connections clusters:

      1. Log in to the Integrated Solutions Console on the DM

      2. Go to Servers > Clusters > WebSphere Application server clusters.

      3. Select the IBM Connections clusters and click Start.

      > If you installed a cluster with multiple Search nodes, create the initial index. For more information about creating the Search index, see the Creating the initial Search index topic.

      1. If you are installing a non-English language deployment, enable Search dictionaries. For more information, see the Enabling Search dictionaries topic.

      2. The index is ready when the INDEX.READY and CRAWLING_VERSION files are present in the index directory.

      If some applications do not start, the file-copying process might not have completed. Wait a few minutes and start the applications.


    Results

    The installation wizard has installed IBM Connections in a network deployment.

    To confirm that the installation was successful, open the log files in connections_root/logs. Each IBM Connections application installed has a log file, using the following naming format: application_nameInstall.log, where application_name is the name of an IBM Connections application. Search for the words error or exception to check whether any errors or exceptions occurred during installation.

    To view the log file for system events that occurred during the installation, open the date_time.xml file, where date_time represents the date and time of the installation. The file is located by default in the following directory:

    • AIX or Linux (root user): /var/ibm/InstallationManager/logs

    • AIX or Linux (non-root user): /home/user/var/ibm/Installation Manager/logs where user is the non-root user name

    • Windows Server 2008 64-bit: C:\ProgramData\IBM\Installation Manager\logs


    What to do next

    Complete the post-installation tasks that are relevant to your installation. For more information, see the Post-installation tasks topic.

    Access network shares:

    If you installed WAS on Microsoft Windows and configured it to run as a service, ensure that you can access network shares. For more information, see the Accessing Windows network shares topic.


    Before installing for 4.0 migration

    Verify that all necessary prerequisite conditions are complete before installing IBM Connections.


    Prerequisites

    • Check the Release notes for late-breaking issues.

    • If you previously installed IBM Installation Manager, update it to V1.4.4 or higher. For more information, go to the IBM Installation Manager updates webpage.

      Use the same user account to install IBM Installation Manager and IBM Connections.

    • IBM Installation Manager presents three options for the type of deployment that you can install. For more information about these options, see the Deployment options topic.

    • The IBM Connections installation process supports the creation of new server instances and clusters. Do not use existing clusters to deploy IBM Connections.

    • You can install IBM Connections with either root or non-root accounts on AIX and Linux, or administrator or non-administrator accounts on Microsoft Windows. For more information, see the Installing as a non-root user topic.

    • Complete the Pre-installation tasks.

      If you are migrating from IBM Connections 3.0.1, you need to complete only the following tasks:

        Prepare to configure the LDAP directory.

      • Install IBM WAS if you are installing on the same host as 3.0.1.

      • Set up federated repositories

      • Do not complete the Pre-installation tasks for creating DBs or populating the Profiles DB. The migration process handles those tasks separately.

    • Install IBM WAS Network Deployment (Application Server option) on each node. IBM Connections is installed on the system where WAS Deployment Manager is installed. For more information, see the Installing IBM WAS topic.

    • Back up the profile_root/Dmgr01 directory.

    • Configure WAS to communicate with the LDAP directory. For more information, see the Set up federated repositories topic.

    • Prepare directories to use as content stores. You need to provide shared content stores on network share devices and local content stores on each node. Both shared and local content stores must be accessible using the same path from all nodes and from the Deployment Manager.

    • Set the system clocks on the Deployment Manager and the nodes to within 1 minute of each other. If these system clocks are further than 1 minute apart, you might experience synchronization errors.

    • Copy the JDBC files for your DB type to the Deployment Manager (DM) and then from the DM to each node. Place the copied files in the same location on each node as their locations on the DM. If, for example, you copied the db2jcc.jar file from the C:\IBM\SQLLIB directory on the DM, place the copy in the C:\IBM\SQLLIB directory on each node. See the following table to determine which files to copy:

      JDBC files

      Database type JDBC files
      DB2

      db2jcc.jar

      db2jcc_license_cu.jar

      Oracle

      ojdbc6.jar

      Ensure that you are using the latest version of the ojdbc6.jar file.

      SQL Server

      sqljdbc4.jar

    • If you are going to use a trusted SSL certificate, ensure that is available before you begin the installation.

    • If you do not plan to deploy IBM Cognos Business Intelligence now to support metrics, you can still install the Metrics application along with the other IBM Connections applications. This enables Connections to begin collecting event data immediately and store it in the Metrics DB for use when Cognos is available to provide reports.

    • (Microsoft Windows) You must use an administrator account to install IBM Connections on Windows. If you are installing on Windows Server 2008, you must use a local administrator account. If you use a domain administrator account, the installation might fail.

    • (Linux only) If you receive an error message after attempting to start IBM Installation Manager, you might need to install additional 32-bit libraries. For more information about required Linux libraries, see the Linux libraries topic. For more information about IBM Installation Manager errors, go to the Unable to install Installation Manager on RHEL 6.0/6.1 (64-bit) webpage.

    • (AIX and Linux) Ensure that the directory paths that you enter contain no spaces.

    • (AIX and Linux) Ensure that the Open File Descriptor limit is 8192. For information about setting the file limit, go to the Installation error messages topic and search for error code CLFRP0042E.

    • (AIX only) IBM Installation Manager requires additional libraries for the AIX operating system. For more information, go to the Required filesets on AIX for Installation Manager webpage.

    • (AIX only) If IBM Installation Manager hangs while being installed on your system, you might need to update your version of the software. For more information, read the IBM Installation Manager hangs on 64-bit AIX systems technote.

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

      After installing the GNU-compatible compression program, change to the directory where you downloaded the IBM Connections tar file. Enter the following command to extract the files from the file:

      gtar -xvf Lotus_Connections_wizard_aix.tar

      This command creates a directory named after IBM Installation Manager.

    Tips:

    • Establish naming conventions for nodes, servers, clusters, and web servers.

    • Use a worksheet to record the UIDs, passwords, server names, and other information required during and after installation. For more information, see the Worksheet for installing IBM Connections topic.

    • Install and configuring IBM Connections is a complex process; not only should you read the instructions but you must also pay attention to the Before you begin prerequisites in each topic.


    Install Linux libraries

    The complete list of Linux libraries required for deploying IBM Connections 4.0.


    Linux

    Install the following Linux packages and libraries:

    Ensure that the GTK library is available on your system. Even when you are installing on a 64-bit system, you still need the 32-bit version of the GTK library.

    >ul>

  • compat-libstdc++-33.x86_64
  • libcanberra-gtk2.i686
  • PackageKit-gtk-module
  • gtk2.i686
  • compat-libstdc++-33.i686
  • compat-libstdc++-296
  • compat-libstdc++
  • libXtst.i686


    Cognos

    If you plan to install Cognos, you also need the libraries listed in the Cognos BI 10.1.1 Software Environments - Required Patches technote.

    Both 32-bit and 64-bit versions are required.


    Content store migration

    Migrate your 3.0.1 content stores to your IBM Connections 4.0 deployment.

    When creating content stores for IBM Connections 4.0, you can reuse the 3.0.1 content stores, using either of two methods: use the 3.0.1 directories in the 4.0 deployment or create new 4.0 directories and copy the 3.0.1 content to them.


    Reusing content stores

    Reuse your 3.0.1 content stores in your IBM Connections 4.0 deployment.

    While installing IBM Connections 4.0, you are prompted to specify the locations of the 4.0 content stores. Instead of creating new directories, you can specify the 3.0.1 content stores so that you can reuse that content in your 4.0 deployment.

    You must delete any Search-related data from your IBM Connections 3.0.1 content stores, such as indexes and statistics. The 4.0 installation generates new Search-related data.

    1. Delete the data in content stores that are related to the Search application.

    2. Use the following table as a guide to deleting data that is recreated in the IBM Connections 4.0 deployment:

      Content stores that must be deleted

      Content Store Location
      local_content_store/news/search/index
      local_content_store/profiles/cache
      local_content_store/search/backup
      local_content_store/search/index
      shared_content_store/activities/statistics
      shared_content_store/communities/statistics
      shared_content_store/messageStores
      shared_content_store/news/search/indexReplication
      shared_content_store/profiles/statistics
      shared_content_store/search/dictionary
      shared_content_store/search/stellent/dcs/oiexport/exporter

      where shared_content_store is a content store on a shared storage device on a network and local_content_store is content that is stored on your local system.


    Copy content stores

    Copy data from your IBM Connections 3.0.1 content stores to your 4.0 deployment.

    Ensure that you created new content stores while installing IBM Connections 4.0.

    You can reuse content stores from your IBM Connections 3.0.1 deployment by copying the data to the new content stores in your 4.0 deployment. You do not need to copy local content stores because those directories are recreated by the 4.0 deployment.

    This topic applies to all releases of version 3.0.1.

    To copy data from your IBM Connections 3.0.1 content stores, complete the following steps:

    1. Locate the content stores in your IBM Connections 3.0.1 deployment.

    2. Copy the 3.0.1 data to the corresponding content store in your IBM Connections 4.0 deployment.

    3. Use the following table as a guide to organizing the content stores:

      The table excludes content that is generated by the Search application, such as indexes and statistics.

      If you created additional content stores, copy those content stores as well as the default content stores in the table. For Activities, for example, the content stores that copy are defined in the objectStore element of the oa-config.xml file.

      Content Store Location:

      • shared_content_store/audit
      • shared_content_store/activities/content
      • shared_content_store/blogs/upload
      • shared_content_store/customization
      • shared_content_store/dogear/favorite
      • shared_content_store/files/upload
      • shared_content_store/forums/content
      • shared_content_store/wikis/upload


    Import application artifacts to IBM Connections 4.0

    Import application artifacts, including configuration data and properties files, into your new deployment.

    Ensure that you completed the steps in the Exporting application artifacts from IBM Connections 3.0.1 topic. To import application data into your IBM Connections 4.0 deployment, complete the following steps:

    1. Start the Deployment Manager in your IBM Connections 4.0 deployment.

    2. Copy the migration directory that you backed up from your 3.0.1 deployment to the connections_root directory in your 4.0 deployment.

    3. Import your 3.0.1 data. Open a command prompt, change to the migration directory on the Deployment Manager node in your 4.0 deployment, and run the following command:

      • AIX or Linux:

        ./migration.sh lc-import

        -DDMUserid=dm_admin

        -DDMPassword=dm_password

      • Windows:

        migration.bat lc-import

        -DDMUserid=dm_admin

        -DDMPassword=dm_password

      • where dm_admin is the administrative UID for WAS Deployment Manager and dm_password is the user password.

      Check the log file to validate the import. The log file is stored in the system user's home directory, and uses the following naming format:

      lc-migration-yyyyMMdd_HHmm_ss.log

      For example:

      • AIX or Linux:

        /root/lc-migration-20110215_1534_26.log

      • Windows:

        C:\Administrator\lc-migration-20110215_1534_26.log

      • Windows Server 2008:

        C:\Users\Administrator\lc-migration-20110215_1534_26.log

    4. If your deployment uses multiple nodes, synchronize the nodes.


    What to do next

    Compete the steps in the Post-migration tasks topic.

    If the migration fails, restore the Deployment Manager profile and complete the steps in this task again. If you customized your 3.0.1 environment, reapply your customizations to the relevant XML files.

    For more information, see the Rolling back a migration topic.

    If your existing deployment uses Quickr Connector and you want to continue using it, you must install and configure Quickr Connector after installing IBM Connections 4.0. The migration tool does not handle the Quickr Connector configuration files.


    Post-migration tasks

    After migrating to IBM Connections 4.0, you need to perform further tasks to ensure that your new deployment is complete.

    Complete any required post-installation tasks.

    Ensure that you backed up customized files from your IBM Connections 3.0.1 deployment. For more information, see the Saving your customizations topic.

    After updating or migrating IBM Connections, manually update any custom fields and customized files that could not be automatically updated or migrated.

    To finalize the migration process:

    1. Reapply the customizations that you used in version 3.0.1. For more information about migrating customizations, see the Saving your customizations topic.

      1. Migrate any JSP, CSS, and string customizations.

      2. Verify that your Blogs themes are present in 4.0. If not, manually update them. For more information, see the Customize a blog theme topic.

      3. Update your customized Community themes.

      4. Copy the 3.0.1 version of profiles-policy.xml file to the 4.0 deployment, overwriting the 4.0 version of the file. For more information, see the Post-migration steps for profile types and profile policies topic.

      5. Copy the customized XSD elements of the 3.0.1 service-location.xsd file to the 4.0 version of the file.

      6. Redefine customized Profiles fields in the validation.xml file.

      7. Migrate your 3.0.1 JavaScript customizations. For more information, see the Customize strings sourced in JavaScript and Extending JavaScript in IBM Connections topics.

    2. Reapply any proxy configurations, if necessary. For more information, see the Configuring the AJAX proxy and Configuring a reverse caching proxy topics.

    3. Delete your pre-migration search indexes and create new indexes. For more information, see the Deleting the Search index and Creating an initial or new Search index topics.

    4. Synchronize the member DB tables for each IBM Connections application with the data in the user directory. For more information, see the Synchronizing the application member tables and corporate directory topic.

      You must have a web server configured for IBM Connections before attempting to synchronize Profiles and the LDAP directory.

    5. Optional: If you used IBM Connections Connectors in version 3.0.1, such as Lotus Quickr, re-install them.

      You must obtain the 4.0 version of Connections Connector for Lotus Quickr from the catalog.

    6. Optional: If you defined a server whitelist in version 3.0.1 for publishing file attachments from Activities to Lotus Quickr, redefine it.

    7. If you changed the root URL of any IBM Connections application, and if the old and new URLs point to the same webserver, redirect requests to the new URL:

      1. Open the httpd.conf file in a text editor. The file is located in the ibm_http_server_root/conf directory.

      2. Uncomment the following line:

        LoadModule rewrite_module modules/mod_rewrite.so

      3. Add the following statements:

        • The lines referring to weblogs redirect all requests for the pre-migration URL of https://blog301.example.com/weblogs/* to the post-migration URL of https://blog40.example.com/newblogs/*. Substitute your own URLs as appropriate.

        • The lines referring to "bookmarklet" redirect the path of the bookmarklet feature to make it work in 4.0. Use the exact URLs shown.

        RewriteEngine on

        RewriteRule /weblogs/(.*) https://blog40.example.com/newblogs/$1 [R,L]

        RewriteCond %{REQUEST_URI} /(.*)/bookmarklet/(.*)

        RewriteCond %{REQUEST_URI} !^/connections/bookmarklet/(.*)

        RewriteRule ^/(.*)/bookmarklet/(.*) /connections/bookmarklet/$2 [noescape,L,R]

        Listen 0.0.0.0:443

        <VirtualHost *:443>

        RewriteEngine on

        RewriteRule /weblogs/(.*) https://blog40.example.com/newblogs/$1 [R,L]

        ServerName blog40.example.com

        SSLEnable

        RewriteCond %{REQUEST_URI} /(.*)/bookmarklet/(.*)

        RewriteCond %{REQUEST_URI} !^/connections/bookmarklet/(.*)

        RewriteRule ^/(.*)/bookmarklet/(.*) /connections/bookmarklet/$2 [noescape,L,R]

        </VirtualHost>

        SSLDisable

    8. Optional: Remove the Location and ErrorDocument stanzas if you added them to the httpd.conf file before migrating. For more information, see the Preparing IBM Connections for maintenance topic.


    What to do next

    After you complete the mandatory post-installation tasks, update the deployment with the latest fixes. For more information, see the Update IBM Connections 4.0 topic.


    Create the Search index after migrating or updating

    When you update or migrate IBM Connections from a previous release, you must recreate the Search index.

    When you follow the steps described in the following procedure, Search functionality is not available to your users.

    During the indexing update process, documents are first written to a cache table in the HOMEPAGE DB and then written to each index across the nodes. When a new index needs to be built, the DB cache is skipped, and the crawling and indexing process writes directly to the index directory on the node that is performing the indexing task.

    When the indexing task is finished, the Search application copies the index to all nodes that host the Search application. If some of those nodes were not running during indexing, you can copy the index manually. Before copying the index, verify that the INDEX.READY and CRAWLING_VERSION files are present in the index directory.

    1. To ensure that status updates and calendar events are included in the indexing task, restore the full set of default indexing tasks. Go to the Restoring the default scheduled tasks for Search topic and follow the instructions for running the SearchService.resetAllTasks() command.

    2. Stop all the nodes that are running the Search application. If there are existing search indexes on these nodes, delete them by performing the steps described in Deleting the index.

    3. Start all the Search nodes in the cluster.

    4. Recreate the index by completing one of the following steps:

      • Create a one-off task that indexes all the installed IBM Connections applications in your deployment. For more information, see Running one-off tasks.

      • Wait for the next scheduled indexing task to run.

      You can tell that the index is built on the indexing node when the INDEX.READY and CRAWLING_VERSION files are present in the index directory. The Search index directory is defined by the IBM WAS variable SEARCH_INDEX_DIR.

      After the index is built, the next phase is index roll-out. During this phase, the files in the index directory are automatically copied to the Search staging folder, which is defined by the WAS variable SEARCH_INDEX_SHARED_COPY_LOCATION. The files in the Search staging folder are then copied to each index folder on the remaining nodes.

      Do not stop your deployment until the index has been copied to all nodes. If the server is stopped during this process, the index will not be successfully rolled out to all nodes. In this event, you need to manually copy the index from the staging location to the other nodes.


    Synchronize the application member tables and corporate directory

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

    You can enable user data changes to be pushed automatically from the Profiles DB to the DBs of the other applications. As a result, if you install Profiles, keeping user data in sync will be easier. However, after migrating to the new release of IBM Connections, the application DBs may not be fully in sync with each other or with the corporate user directory. To level set the data stores, run a set of wsadmin commands that synchronize the user data between the member tables for the IBM Connections applications and your corporate directory.

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

      1. Open a command prompt and then do the following:

        Change to the following directory of the system on which you installed the deployment manager:

        WAS_HOME\profiles\DMGR\bin

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

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

        • AIX / Linux:

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

        • Microsoft Windows::

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

        where:

        • admin_user_id is the user name of the WAS administrator.

        • admin_password is the password of the WAS administrator.

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

          1. Open the WAS Integrated Solution Console for the deployment manager, and then select...

              System Administration > Deployment Manager

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

        For example:

        • AIX / Linux:

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

        • Microsoft Windows::

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

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

        execfile("application_py_file")

        ...where application_py_file is one of the following:

        • Activities: activitiesAdmin.py

        • Blogs: blogsAdmin.py

        • Bookmarks: dogearAdmin.py

        • Communities: communitiesAdmin.py

        • Files: filesAdmin.py

        • Forums: forumsAdmin.py

        • News: newsAdmin.py

        • Wikis: wikisAdmin.py
        The News repository, Profiles, and Search do not need to be synchronized at this time.

      4. Enter the following command to synchronize user data:

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

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

        • Activities

        • Blogs

        • Dogear (Bookmarks)

        • Communities

        • Files

        • Forums

        • News

          The Home page, News repository, and Search applications share the same DB, so running the synchronization command against News applies to all three areas.

        • Wikis

        For example:

        DogearMemberService.syncAllMembersByExtId({"updateOnEmailLoginMatch":"false"})
        For each user in the application's member table, this command first checks to see if the external ID of each member is present in the corporate directory. If it is, then the command gets the display name, email address, and login names from the corporate directory and updates the application DB tables with the values from the directory, if they are different. This is considered to be an update operation and these updates are not logged to the output file.

        If a match for the user's external ID in the application membership table is not found in the directory, then the code uses the email address and login names contained in the application DB tables to continue to search for the user in the corporate directory. When a login name or email address match for this user is found in the corporate directory, because of the input parameter "updateOnEmailLoginMatch": "false", the command does not update the application DB automatically. Instead, it writes a log entry to the application_nameULcSyncCmd.log file so that an administrator can later perform synchronization after confirming that the update should be made. Here is an example of the log entry that would be created in this situation:

        [2010-08-12 09:45:44] CLFWY0242W: The synchronize command found that active member Dan Retired [current 
        external id: 25374cc6-82a511df-80b6c81b-5330ca0eZZZ, application id 7980ff0f-7f41-4544-b1a7-9c4779aff287] 
        could not be matched via external id, but could be matched via login or email to external id 
        25374cc6-82a511df-80b6c81b-5330ca0e.  The member was not updated since this action was disabled by the command.

        If a match for the user's external ID is not found in the corporate directory, nor is a match found for the user's email address and login names, then the status of the user is changed to inactive in the application DB. The code writes a log entry for this action as well. Here is an example of that log entry type:

        [2010-08-12 09:45:42] CLFWY0261I: The synchronize command inactivated member Ann Retired [current 
        external id: 25374cc2-82a511df-80b6c81b-5330ca0e, application id 4fd0bb17-1495-4944-9e2a-b86971cab5c2]

        The location of the generated log file is dependent on your server configuration; either single server or cluster. In a single server environment, the log is generated in the server1 folder. In a server cluster, the log is generated in the application_cluster path, example .profiles/AppSrv01/logs/Cluster1_server1/.

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

    3. Do one of the following things:

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

        application_nameMemberService.syncMemberByExtId(externalId)

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

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

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

        application_nameMemberService.inactivateMemberbyEmail(email)

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

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

        application_nameMemberService.inactivateMemberbyExtId(externalId)

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

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

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

    5. Make sure the Profiles member DB table is synchronized with the corporate directory by looking at the prof_state column in the employee table in the PEOPLEDB DB. Make sure it is populated and that each member has a user status of 0, indicating that they are active.


    What to do next

    After performing this task, all of the component membership tables are consistent with the directory. If you have profiles installed, profiles will actively push user data changes including inactivations, or updates to the a person's email, login or external ID to the other components' membership tables. If you do not have Profiles installed, you must periodically run the syncAllMembersByExtId({"updateOnEmailLoginMatch":"true"}) commands for each installed application. The frequency with which you need to run these commands depends on the size of your deployment and how your company's directory is managed. The key determination is the time interval during which old emails and logins for inactive users are reserved before being assigned to new users. The syncAllMembersByExtId({"updateOnEmailLoginMatch":"true"}) command needs to be run in an interval shorter than the dormancy time for email and login reuse. See Managing users for more information.


    Post-migration steps for profile types and profile policies

    After migrating to this release, manually update profiles-types.xml to ensure that all profile types referenced in either profiles-policy.xml or widgets-config.xml file are present in the migrated deployment. You may also need to manually copy your customized com.profextattr.resources.properties file after migration. If you have modified profiles-policy.xml file, manually update it again with the same changes, or copy and replace profiles-policy.xml file in this release.

    In migrating to this release, there are significant changes to profiles configuration that should be validated. In prior releases, the layout of the profile and the underlying data model was defined in profiles-config.xml. In this release, the data model for profile-type definitions has been moved into a dedicated profiles-types.xml file and the rules for presentation of a profile have been moved into a set of FreeMarker template files.

    It is important to understand how the default migration for each file works in order to best validate the results for your environment:

    • profiles-types.xml

      This file now identifies the set of properties that are associated with each profile-record based on its associated profile-type.

      A profile-type is generated based on the previous data in profiles-config.xml using the following procedure. For each apiModel previously defined, a corresponding profile-type is generated with the associated properties. Each property is marked as readwrite if it was identified as an editable attribute and each property is marked as hidden if it was identified as a hidden attribute.

      For each profileLayout previously defined, a corresponding profile-type is generated or merged with the previously processed apiModel. A property is marked as readwrite if it was an editable attribute, and it is marked as richText if it was declared as a richText attribute for rendering.

      After migration, you must update profiles-types.xml to ensure that all profile types referenced in either profiles-policy.xml or widgets-config.xml file are present in the migrated deployment.

      For more information, see Profile-types.

    • User Interface Template files

      A set of template files now control the rendering of a profile record in the user interface.

      Each template file is generated based on previous layout definitions present in the prior release profiles-config.xml file. The profileDetails.ftl file and the profileEdit.ftl file are generated using the profileLayout definitions. The searchResults.ftl file is generated using the searchResultsLayout definitions. The businessCardInfo.ftl file is generated using the businessCardLayout definitions.

      If there were multiple profile-type layouts defined, the migrated file will preserve the profile presentation, and the generated files will have a set of if-elseif-else logic to handle each migrated profile-type. If there were common renderings across profile-type layout definitions, and you had many profile-type layout definitions for a particular layout, the migrated file may appear to contain redundant content. Where possible, leverage the features of the FreeMarker template language to simplify the result of each migrated file.

      For more information, see Customize display using templates.

    • LotusConnections-config.xml

      If your Profiles customization included custom strings, ensure that your custom resource bundle is properly registered in LotusConnections-config.xml.

      For more information, see Add custom strings for widgets and other scenarios.

    To summarize, profile types in the profiles-config.xml file are migrated. However, profile types in profiles-policy.xml and widgets-config.xml files are not migrated and require manual post-migration work.

    For example, the widgets-config.xml file may contain profile types temp and employee. These two types would not be present in the migrated profiles-config.xml file. You must manually make the same updates again or copy profiles-policy.xml from 3.0.1 environment to replace the copy in the 4.0 environment.

    To ensure that all defined profile types are present in the migrated deployment, manually add all profile types in your profiles-policy.xml and widgets-config.xml files to the end of profiles-types.xml after migration using the following format:

        <type>
            <parentId>default</parentId>
            <id>temp</id>
        </type>

    If you defined custom profile fields using extended attributes, the labels that display on the profile are typically defined in a file such as com.profextattr.resources.properties, which is referenced by the LCC.xml file. While the LCC.xml file is migrated, the referenced com.profextattr.resources.properties file is not. If your LCC.xml file contains references to com.profextattr.resources.properties, you must manually copy the file to the following folder structure in the new deployment:

    .../IBM/Connections/data/shared/customization/strings/com.profextattr.resources.properties


    Post-migration step for status updates

    If you changed the maximum length of status updates in your IBM Connections 3.0.1 deployment, update the 4.0.1 news-config.xml file to maintain this setting.


    Maximum length of status updates

    In IBM Connections 4.0, the property that specifies the maximum length of status updates has been moved from the profiles-config.xml file to the news-config.xml file. The default value of the property in IBM Connections 3.0.1 is 1000.

    If you edited the com.ibm.lconn.profiles.config.theboard.entry.MaxChars property in the profiles-config.xml file in IBM Connections 3.0.1 deployment, you must update the value of the microblogEntryMaxChar property in the news-config.xml file. For information about how to edit this property, see the Specifying the maximum size for microblogs topic.

    If you did not edit the default maximum length for status updates in IBM Connections 3, this post-migration step is not required.


    J2EE mapping for profile policies

    The J2EE mapping for Profiles policies for the board and status updates are now handled by the News application. If you mapped J2EE roles for these policies in 3.0.1, you must map the same users to the person role in the News application. For more information, see the Assigning people to J2EE roles topic.


    Post-migration steps for the media gallery terms and conditions

    After you migrated IBM Connections 3.0.1 to IBM Connections 4, perform the following tasks to update your terms and conditions agreement. You need to get the string bundle files that you copied in Preparing to migrate the media gallery.

    1. Create a jar file that declares an OSGI extension. To see an example, download this sample JAR file by right-clicking the following link: com.ibm.lconn.mediagallery.web.resources.examples_1.0.0.jar

    2. Place your string bundle properties files that you copied from IBM Connections 3.0.1 in the _properties folder of the OSGI bundle jar

    3. Update the file attribute with the name of the string bundle in the _properties folder if it is not tc.properties. Update the file attribute in the dojoResourceModule element in the plugin.xml file in the jar from step 1.

    4. Update the following items in the media gallery widget definition in widgets-config.xml.

      <item name="tc_bundle" value="my.custom.TermsConditions.messages" />
      <item name="tc_key" value="tc" />
      <item name="tc_checkbox" value="false" />

      ...where:

      • The tc_bundle value must be the name of the object that is set in the file, which is referenced by the bind attribute of the net.jazz.ajax.dojoModuleBinding in the OSGI bundle. In this case, the value is my.custom.TermsConditions.messages.

      • The value of tc_key is the key used in the properties file located in the _properties directory of the OSGI bundle jar, for example, com.ibm.lconn.mediagallery.web.resources.example.jar

      • The value attribute of the tc_checkbox item can be true or false. If true, users must check a box in the agreement before they can access the media gallery.
      See Using the widgets-config.xml file for Communities.

    5. Place the jar from step 1 on the IBM Connections server in the provision\webresources directory and then restart the common ear.

      The provision directory is typically CONNECTIONS_HOME/data/shared/provision.


    Additional post-migration steps for the media gallery

    After you migrated IBM Connections 3.0.1 to IBM Connections 4, perform the following tasks to update your custom video player and your custom field renderer.


    Update the media gallery custom video player

    You need the custom video player enterprise application from IBM Connections 3.0.1 that you backed up and saved in Preparing to migrate the media gallery.

    1. Create a jar file that declares an OSGI extension. To see an example, download this sample JAR file by right-clicking the following link: com.ibm.lconn.mediagallery.web.resources.examples_1.0.0.jar

      For additional information about creating an IBM Websphere Application Server OSGi extension, see the WAS:documentation about plugin.xml.

      1. Replace the contents of the playVideo method in the resources/VideoPlayer.js file in com.ibm.lconn.mediagallery.web.resources.examples_1.0.0.jar with the contents out of the CustomVideoPlayer.ear/CustomVideoPlayerWeb.war/custom-player.js file.

    2. In javascript, make sure that the following variable is set to the name of a constructor function (dojo class) that creates an object with a single member function:

      quickr.lw.config.media.videoPlayer
      For example:

       myCustomVideoPlayer_playVideo = function (node, store, item, width, height) {
      
      // Include dom code to render video player here
      
      }
      
      function myCustomVideoPlayer = function () {
      
      // Initialize member variables if necessary
      
      }
      
      myCustomVideoPlayer.prototype.playVideo = myCustomVideoPlayer_playVideo

    3. If your quickr.lw.config.media.videoPlayer variable had a value different from my.custom.VideoPlayer, then make the following updates in the com.ibm.lconn.mediagallery.web.resources.examples_1.0.0.jar file:

      1. In resources/VideoPlayer.js, change all references to my.custom.VideoPlayer to the value used in your CustomVideoPlayer.ear/CustomVideoPlayerWeb.war/custom-player.js file.

      2. In plugin.xml, change the bind attribute of the dojoModuleBinding element to the name of the class used in resources/VideoPlayer.js. Update the value attribute of the alias element if the package name of the class is different from my.custom to the package name of the class defined in resources/VideoPlayer.js.

    4. Finally, you would set the configuration variable to the name of your constructor:

      quickr.lw.config.media.VideoPlayer = "myCustomVideoPlayer";

    5. Place the jar on the IBM Connections server in the provision\webresources directory and then restart the common ear.

      The provision directory is typically CONNECTIONS_HOME/data/shared/provision.


    Update your custom field renderer

    After you migrating IBM Connections 3.0.1 to IBM Connections 4, perform the following tasks to update your custom field renderer. You need the custom field renderer enterprise application from IBM Connections 3.0.1 that you backed up and saved in Preparing to migrate the media gallery.

    1. Create a jar file that declares an OSGI extension. To see an example, download this sample JAR file by right-clicking the following link: : com.ibm.lconn.mediagallery.web.resources.examples_1.0.0.jar

      For additional information about creating an IBM Websphere Application Server OSGi extension, see the WAS documentation of the plugin.xml file.

      1. Copy your javascript classes out of CustomRenderers.ear\CustomRenderersWeb.war.

      2. Create javascript class files in the "resources" directory of the com.ibm.lconn.mediagallery.web.resources.examples_1.0.0.jar similar to the provided my.custom.renderer.SearchTermType.

    2. If your custom type class has a name different from my.custom.renderer.SearchTermType, then make the following updates in the com.ibm.lconn.mediagallery.web.resources.examples_1.0.0.jar file:

      1. In plugin.xml, change the bind attribute of the dojoModuleBinding element to the name of the class used in in your javascript class located in the "resources" directory of the jar.

      2. Update the value attribute of the alias element if the package name of the class is different from my.custom to the package name of your javascript class.

    3. Place the jar on the IBM Connections server in the provision\webresources directory and then restart the common ear.

      The provision directory is typically CONNECTIONS_HOME/data/shared/provision.


    Roll back a migration

    If a migration fails, you can roll back your environment to the previous one.

    Ensure that you have a back-up copy of your installation environment. Rolling back your IBM Connections environment ensures that you have a clean environment before attempting the migration again.

    To roll back your IBM Connections environment:

    1. Restore your DBs from the back-up that you made. Use your native DB tools.

    2. Restore your IBM Connections installation directory from the back-up.

    3. Restore your WAS profile directory and the profileRegistry.xml file from the back-up.

    4. Restore the WAS Deployment Manager profile directory: profile_root/Dmgr01. For example: D:\WebSphere\AppServer\profiles\dmgr.


    Update IBM Connections 4.0

    Update IBM Connections 4.0 with interim fixes or fix packs.

    Fixes are available for download from the IBM Fix Central web site.

    Updates include the following types of fixes:

    Interim fix

    A noncumulative fix that fixes a single issue.

    Cumulative Refresh (CR)

    Similar to an interim fix, a CR also updates the application EAR files.

    Fix pack

    A cumulative fix that contains multiple interim fixes and other identified updates.

    Use the update wizard to install interim fixes and CRs but use IBM Installation Manager to install fix packs. You must always update IBM Connections from the Deployment Manager and then synchronize nodes to propagate the update. Each fix pack and interim fix contains complete instructions for installation.

    The following topics describe how to update your IBM Connections environment.


    Download fixes

    Download fix packs and interim fixes from the IBM support web site.

    List all the fixes that you have already installed by completing the following steps:

    1. Open a command prompt and change to the connections_root/updateInstaller directory.

    2. Run the following command:

      updateSilent.sh -installDir lotus_connections_root -fix -applications application_name

      where application_name is one of the following IBM Connections applications:

      • activities

      • blogs

      • communities

      • dogear

      • files

      • forums

      • homepage

      • metrics

      • mobile

      • moderation

      • news

      • profiles

      • search

      • wikis
      Use a comma or semicolon to delimit multiple applications. If you do not provide this variable, all installed fixes will be listed.

      The IBM Connections update installer does not install fixes for IBM Cognos. For more information about updating Cognos, see your Cognos documentation.

    To download fixes, including interim fixes and fix packs, complete the following steps.

    1. Go to the Fix Central web site.

    2. Select Lotus from the product group menu, IBM Connections from the Product menu, your currently Installed version, your Platform, and then click Continue.

    3. Use one of the available search methods to identify the fix that you wish to install.
      Tip: Select Recommended to see a list of recommended fixes for your release.

    4. Follow the online instructions to download the fix to a temporary directory.

    5. Extract the contents of the fix file and then copy the extracted files to the following directory:

      • AIX or Linux: connections_root/update/fixes

      • Microsoft Windows:: connections_root\update\fixes

      If a fixes subdirectory does not already exist in the update directory, create it. You need to specify this directory when you install fixes.


    Set the WAS_HOME environment variable

    Set an environment variable that points to the WAS installation directory.

    Complete this task only if you are installing interim fixes. If you are installing fix packs, you do not need to complete this task. The update wizard is programmed to access the WAS installation by reading the WAS_HOME environment variable in the system path.

    To set the WAS_HOME environment variable, complete the following steps on the system that hosts the Deployment Manager:

    1. cd WebSphere/AppServer/bin directory.

    2. Execute the following script:

      • Linux:

        ./setupCmdLine.sh

      • Windows:

        setupCmdLine.bat

      This task is not applicable to deployments on the AIX operating system.


    Install fixes as a non-root user

    Grant permissions to a non-root user to install fixes.

    This task applies only to IBM Connections deployments on AIX or Linux. By default, only root users have the necessary permissions to install fixes for an IBM Connections deployment. You can permit non-root users to install fixes by changing their permissions to access certain data directories.

    To grant the necessary permissions to a non-root user:

    1. Create a non-root user.

    2. Create a home directory for the new non-root user.

    3. Open a command prompt and grant the appropriate permissions to the non-root user by running the commands shown in the following table:

      Non-root user permissions

      Directory Permissions Command
      app_server_root RWX chown -R non-root_user app_server_root
      connections_root RWX chown -R non-root_user connections_root
      data_directory_root RWX chown -R non-root_user data_directory_root
      path/tmp/efixes RWX chown -R non-root_user tmp/efixes

      where non-root_user is the account ID of the new non-root user and path is the path to the ptfs or efixes directory.

      The execute permission that you grant for the data_directory_root directory is intended specifically for the search/dcs/stellent directory.

      Verify the /tmp/efixes directory already exists before running the chown command.


    Results

    When you have granted the necessary permissions, the non-root user can install interim fixes and fix packs.

    If different non-root users intend to install fixes, you must first delete any files that might remain in the download directories since you installed earlier fixes.


    Example

    Grant permissions to a new non-root user who wants to install a fix pack for an IBM Connections deployment on Linux:

    1. Create a non-root user account called fix_installer.

    2. Create a home directory for the fix_installer user account.

    3. Open a command prompt and run the following commands:

      1. chown -R fix_installer /opt/IBM

        In this example, the opt/IBM directory contains both the app_server_root and connections_root directories.

      2. chown -R fix_installer /usr/IBM

        If the /usr/IBM directory does not exist, create it.

    4. Advise the new non-root user to log in and then download and install the latest fixes for IBM Connections.


    Install interim fixes

    Use the update wizard in interactive or silent mode to install interim fixes.


    Prerequisites

    Ensure that you have met the following prerequisites:

    • You have downloaded interim fixes, as described in the Downloading fixes topic.

    • The WAS_HOME environment variable has been set.

    • (AIX and Linux) Ensure that you have RWX permissions for the Deployment Manager profile directory that hosts IBM Connections applications.

    • You have backed up any customizations you have made. See Saving your customizations.

    There are two modes in which you can run the update wizard:

    Interactive mode

    Confirm each step of the process. This mode is useful when you use the wizard for the first time or if you are updating a single installation

    Silent mode

    Use a series of commands and parameters to launch and run the wizard. Silent mode is useful when you are updating multiple installations of IBM Connections


    Install interim fixes in interactive mode

    Install interim fixes with the update wizard in interactive mode.

    For information about prerequisites, see the Installing interim fixes topic. An interim fix is a noncumulative fix that resolves a single issue. This topic describes the steps to install an interim fix only; it does not include information about how to prepare the production environment before installing the fix.

    By using the update wizard, you can interact with each step in the procedure.

    You can install multiple fixes in this procedure.

    To install an interim fix in interactive mode:

    1. Stop all the clusters that host IBM Connection applications.

    2. Configure the command line:

      1. cd WebSphere/AppServer/bin directory.

      2. Run the following script:

        • AIX or Linux: .setupCmdLine.sh

        • Windows: setupCmdLine.bat

    3. Start the installation wizard from the updateInstaller directory in the connections_root directory and run the following script:

      • AIX/Linux: ./updateWizard.sh

      • Microsoft Windows::updateWizard.bat

    4. On the Welcome page, click Next to continue.

    5. Enter the location of the fixes in the Fix location field, or click Browse to navigate to the location of the fixes and then click Next. The update wizard scans the location for fixes.

    6. Select the check boxes of the fixes to install and then click Next.

    7. Confirm whether you backed up any customizations that you made to the IBM Connections interface. This input does not validate any such backup; it is just a reminder to consider backing up any customizations because updates to your deployment could overwrite your customizations.

    8. Enter the WAS Deployment Manager administrator ID and password for each application and then click Next.

    9. Review the information that you entered. To edit your input, click Back. To start the update, click Next. The installation process can take up to 10 minutes to complete.

    10. Review the result of the update. Click Finish to exit the wizard.

    11. Remove temporary WAS directories such as the app_server_root/profiles/AppSrv01/temp directory.

    12. Perform a full synchronization to push the update to all nodes.


    Results

    The log files that are created by the wizard are located under the connections_root/version/log directory.


    What to do next

    Your IBM Connections deployment was updated. To check the logs, go to the IM_root directory and open the applicationUpdate.log file, where application is the name of an IBM Connections application.


    Install interim fixes in silent mode

    Install interim fixes with the update wizard in silent mode.

    For information about prerequisites, see the Installing interim fixes topic. An interim fix is a noncumulative fix that resolves a single issue. This topic describes the steps to install an interim fix only; it does not include information about how to prepare the production environment before installing the fix. You can install multiple fixes at a time.

    For information about additional command options, see the updateSilent command topic.

    To install an interim fix in silent mode:

    1. Stop all the clusters that host IBM Connection applications.

    2. From the updateInstaller directory under the connections_root directory open a command prompt and enter the following commands (without the carriage returns):

      • AIX:

        chmod +x updateSilent.sh
        ./updateSilent.sh -fix -installDir connections_root
        -fixDir fix_file_location -install 
        -fixes APAR_number_of_fix 
        -wasUserId AdminUserID 
        -wasPassword AdminPasswordAdminPassword 
        -featureCustomizationBackedUp backup_status

      • Linux:

        chmod +x updateSilent.sh
        ./updateSilent.sh -fix -installDir connections_root
        -fixDir fix_file_location -install 
        -fixes APAR_number_of_fix 
        -wasUserId AdminUserID 
        -wasPassword AdminPasswordAdminPassword 
        -featureCustomizationBackedUp backup_status

      • Windows:

        updateSilent.bat -fix 
        -installDir connections_root
        -fixDir fix_file_location -install 
        -fixes APAR_number_of_fix 
        -wasUserId AdminUserID 
        -wasPassword AdminPasswordAdminPassword 
        -featureCustomizationBackedUp backup_status

      where

      • fix_file_location is the directory containing the downloaded fixes

      • APAR_number_of_fix is the APAR number of the fix (such as LO36338)

      • AdminUserId is the administrative user name for WAS Deployment Manager

      • AdminPwd is the password for that user

      • backup_status confirms whether you backed up any customizations that you made to the IBM Connections interface. The possible values are yes|no. This parameter does not validate any such backup; it is just a reminder to consider backing up any customizations because updates to your deployment could overwrite your customizations.

      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.

      For example:

      ./updateSilent.sh -installDir /opt/IBM/Connections -fix
      -fixDir /opt/IBM/Connections/update/fixes -install
      -fixes LO36338 LO34499 LO34327 LO35077 LO34966 
      -wasUserId wasadmin 
      -wasPassword wasadmin 
      -featureCustomizationBackedUp yes 

    3. Remove the content of temporary WAS directories such as the app_server_root/profiles/AppSrv01/temp directory.

    4. After installing the fixes, perform a full synchronization to push the updates to all nodes.


    Results

    The log files that are created by the wizard are located under the connections_root/version/log directory.


    updateSilent command

    Use the updateSilent command to run the update wizard in silent mode.


    Purpose

    The updateSilent command:

    • Installs fixes

    • Uninstalls fixes

    • Reports on the current state of applied fixes

    The updateSilent command was called the updateLC command in previous releases of IBM Connections.

    updateSilent.{sh}


    Parameters

    -?

    Displays command usage information.

    /?

    Displays command usage information.

    -configProperties <propertyFile>.properties

    Specifies an externally supplied properties file containing IBM Connections properties and values. When specifying properties in a file, use the following conventions:

    • Do not include trailing spaces after property values

    • Do not enclose values in quotation marks

    • When typing directory paths, use a forward slash (/) instead of a backward slash (\) regardless of the operating system

    -fix

    Identifies the update as an interim fix update.

    -fixDetails

    Instructs the command to display interim fix detail information.

    -fixDir <directory>

    Specifies the fully qualified directory to which you downloaded the interim fixes. The recommended directory is connections_root/update/fixes.

    -fixes <fix1> <fix2>

    Specifies a list of space-delimited interim fixes to install or uninstall.

    -fixJars <JAR_file1> <JAR_file2>

    Specifies a list of space-delimited interim fix JAR files to install or uninstall. Each JAR file has one or more interim fixes.

    -help

    Displays command usage information.

    /help

    Displays command usage information.

    -install

    Installs the update.

    -installDir <directory>

    Specifies the fully qualified installation root of the IBM Connections product. By default, this directory is connections_root.

    If you are applying an interim fix to applications in a cluster, apply the fix to the first node and then do a full synchronization to push the fix to the other nodes.

    -uninstall

    Uninstalls the identified fix.

    -uninstallAll

    Uninstalls all applied interim fixes.

    -usage

    Displays command usage information.

    -wasPassword <password>

    Required to install or uninstall. Identifies the succeeding text as a WAS Deployment Manager administrative user password.

    -wasUserId <AdminUserId>

    Required to install or uninstall. Specifies the UID of the WAS administrative user.

    -featureCustomizationBackedUp <backup_status>

    Confirms whether you backed up any customizations that you made to the IBM Connections interface. The possible values are yes|no. This parameter does not validate any such backup; it is just a reminder to consider backing up any customizations because updates to your deployment could overwrite your customizations.


    Syntax

    Use the specified syntax to perform the following common tasks:

    • To display command usage information:

      updateSilent -help | -? | /help | /? | -usage

    • To process a fix:

      updateSilent -installDir <connections_root>
      -fix
      -fixDir <connections_root/update/fixes> 
      -install | -uninstall | uninstallAll
      -fixes <space-delimited list of fixes>
      -fixJars <space-delimited list of JAR files>
      -wasUserId <AdminUserId> -wasPassword <AdminPwd>
      [-configProperties "property file name and path"]
      [-fixDetails]
      -featureCustomizationBackedUp yes

    • To display a list of applied fixes:

      updateSilent -fix 
      -installDir <connections_root>

    • To display a list of available fixes:

      updateSilent -fix 
      -installDir <connections_root>
      -fixDir <connections_root/update/fixes> 


    Examples

    The following examples demonstrate how to perform common tasks with the updateSilent command. They assume the following conditions:

    • The location of the update wizard is: C:\IBM\Connections\update

    • The IBM Connections installation root is: C:\IBM\Connections

    • The fix repository is: C:\IBM\Connections\updateInstaller\fixes

    The examples include carriage returns after each parameter to make the example easier to read. When using the command, do not add carriage returns after the parameters.

    To install a collection of interim fixes:

    	C:\IBM\Connections\updateInstaller 
    	updateSilent -fix 
    	-installDir "C:\IBM\Connections" 
    	-fixDir "C:\IBM\Connections\updateInstaller\fixes" 
    	-install -fixes Fix1 Fix2
    	-wasUserId wsadmin -wasPassword wspwd
    	-featureCustomizationBackedUp yes

    To install a collection of interim fixes and display interim fix details:

    	C:\IBM\Connections\updateInstaller 
    	updateSilent -fix 
    	-installDir "C:\IBM\Connections" 
    	-fixDir "C:\IBM\Connections\updateInstaller\fixes" 
    	-install -fixes Fix1 Fix2 -fixDetails
    	-wasUserId wsadmin -wasPassword wspwd
    	-featureCustomizationBackedUp yes

    To install a collection of interim fixes using a custom properties file:

    	C:\IBM\Connections\updateInstaller 
    	updateSilent -fix 
    	-installDir "C:\IBM\Connections" 
    	-fixDir "C:\IBM\Connections\updateInstaller\fixes" 
    	-install -fixes Fix1 Fix2
    	-wasUserId wsadmin -wasPassword wspwd
    	-configProperties .\myProp.properties
    	-featureCustomizationBackedUp yes

    To install interim fixes from a Java archive (JAR) file:

    	C:\IBM\Connections\updateInstaller 
    	updateSilent -fix 
    	-installDir "C:\IBM\Connections" 
    	-fixDir "C:\IBM\Connections\updateInstaller\fixes" 
    	-install -fixJar Fix1
    	-wasUserId wsadmin -wasPassword wspwd
    	-featureCustomizationBackedUp yes

    To uninstall a collection of interim fixes:

    	C:\IBM\Connections\updateInstaller 
    	updateSilent -fix 
    	-installDir "C:\IBM\Connections" 
    	-fixDir "C:\IBM\Connections\updateInstaller\fixes" 
    	-uninstall -fixes Fix1 Fix2
    	-wasUserId wsadmin -wasPassword wspwd
    	-featureCustomizationBackedUp yes

    To display a list of interim fixes:

    	C:\IBM\Connections\updateInstaller
    	updateSilent -fix
    	-installDir "C:\IBM\Connections" 

    To display a list of interim fixes available in the repository:

    	C:\IBM\Connections\updateInstaller
    	updateSilent -fix 
    	-installDir "C:\IBM\Connections" 
    	-fixDir "C:\IBM\Connections\updateInstaller\fixes"


    Install fix packs

    Install fix packs with the IBM Installation Manager.

    Fix packs contain multiple interim fixes for your IBM Connections installation.

    You must use IBM Installation Manager to install fix packs.


    Prerequisites

    Ensure that you have met the following prerequisites:

    • You backed up your files. For more information, see the Back up IBM Connections topic.

    • You downloaded the latest fix pack. See the Downloading fixes topic for more information.

    • You backed up any customizations that you made. See Saving your customizations.


    Install a fix pack in interactive mode

    Install a fix pack to update IBM Connections.

    Attention: Important information about the user account:

    • AIX and Linux: Use the same operating system user account to install this fix pack that was used to install IBM Connections 4.0. If that account is no longer available, recreate it with the same user name and password and use it to install the fix pack.

    • (AIX and Linux) If you installed IBM Connections 4.0 as a root user, you cannot install this fix pack as a non-root user.

    • Windows: Use an operating system user account that is in the same Administrators group as the account that was used to install IBM Connections 4.0.

    • Ensure that you have downloaded and extracted the latest fix pack. See the Downloading fixes topic for more information.

    • You must run IBM Installation Manager on the system where the Deployment Manager is installed.

    • If an error occurs during installation, IBM Installation Manager cancels the installation and rolls back the installation files. Installation errors are usually caused by environment problems such as insufficient disk space, privilege issues, or corruption of a WebSphere profile. If your installation is cancelled, complete the following steps:

      1. Identify and resolve the error that caused the cancellation. After cancelling the installation, IBM Installation Manager displays an error message with an error code. You can look up the error code in the Installation error messages topic or check the log files.

      2. Start this task again.

    To install the fix pack:

    1. Stop all clusters and node agents in your deployment but leave the Deployment Manager running.

    2. From the IM_root directory, run the file to start the IBM Installation Manager:

      • AIX or Linux: ./launcher

      • Windows: launcher.exe

        On Windows Server 2008, the launcher.exe file is in the IM_root\eclipse directory.

    3. From the IBM Installation Manager menu, click...

        File | Preferences | Repositories | Add Repository

    4. Enter the full path to the fix pack that you downloaded and then click OK.

      For example: C:\IBM\Connections\update\fixes\LC401_Fixpack\repository.config

      The IBM Installation Manager indicates if it can connect to the repository.

    5. Click OK to save the new repository.

    6. Click Update.

    7. The package group panel appears. Click Next to continue.

    8. Select the fix packs to install and click Next.

    9. Review and accept the license agreement by clicking I accept terms in the license agreements and then click Next.

    10. Ensure that all the applications are selected and click Next.

      All of the installed applications are selected by default. If you add any of the unselected applications, those applications will be installed. If you clear any of the selected applications, those applications will be uninstalled.

      If you have not previously installed the Metrics application, you cannot select it here. However, you can install it later by modifying the IBM Connections installation. For more information, see the Modify the installation in interactive mode topic.

    11. Enter the administrative ID and password of the Deployment Manager.

      This ID is set to the connectionsAdmin J2C authentication alias, which is mapped to the following J2EE roles: dsx-admin, widget-admin, and search-admin. It is also used by the service integration bus. To use security management software such as Tivoli Access Manager or SiteMinder, the ID that you specify here must exist in the LDAP directory. For more information, see the Switching to unique administrator IDs for system level communication topic.

    12. Configure your topology:

      The panel described in this step appears only if you selected new applications to install.

      If you select an existing cluster on which to deploy applications, the nodes in that cluster are fixed and cannot be modified.

      • Small deployment:

        1. Select the Small deployment topology.
        2. Enter a Cluster name for the topology.
        3. Select a Node.
        4. Click Next.

      • Medium deployment:

        1. Select the Medium deployment topology.

        2. Select the default value or enter a Cluster name for each application or for groups of applications.

          For example, use Cluster1 for Activities, Communities, and Forums.

          Installation Manager creates servers and clusters when required.

        3. Select a Node for each cluster. Accept the predefined node or select a different node.

          These nodes host application server instances that serve IBM Connections applications. You can assign multiple nodes to a cluster, where each node is a server member of that cluster.

        4. Enter a Server member name for the selected node. Choose the default or enter a custom name.

          If you enter a custom server member name, the name must be unique across all nodes in your deployment.

        5. Click Next.

      • Large deployment:

        1. Select the Large deployment topology.

        2. Enter a Cluster name for each application.

          IBM Installation Manager creates servers and clusters when required.

        3. Select a Node for each cluster. Accept the predefined node or select a different node.

          These nodes host application server instances that serve IBM Connections applications. You can assign multiple nodes to a cluster, where each node is a server member of that cluster.

        4. Enter a Server member name for the selected node. Choose the default or enter a custom name.

          If you enter a custom server member name, the name must be unique across all nodes in your deployment.

        5. Click Next.

    13. Enter the DB information.

      The panel described in this step appears only if you selected new applications to install and if the new applications require DB configuration.

      1. Specify whether the installed applications use the same DB server or instance: Select Yes or No.

        If allowed by your DB configuration, you can select multiple DB instances as well as different DB servers.

      2. Select a Database type from one of the following options:

        • IBM DB2 Universal Database
        • Oracle Enterprise Edition
        • Microsoft SQL ServerEnterprise Edition

      3. Enter the Database server host. For example: appserver.enterprise.example.com

        If your installed applications use different DB servers, enter the DB host for each application.

      4. Enter the Port number of the DB server. The default values are: 50000 for DB2, 1521 for Oracle, and 1433 for SQL Server.

        If your installed applications use different DB servers or instances, enter the port for each DB server or instance.

      5. Enter the JDBC driver location. For example:

        • AIX: /usr/IBM/WebSphere/AppServer/lib

        • Linux:

          /opt/IBM/WebSphere/AppServer/lib

        • Windows:

          C:\IBM\WebSphere\Appserver\lib

      6. Ensure that the following JDBC driver libraries are present in the JDBC directory:

        DB2

        db2jcc.jar and db2jcc_license_cu.jar

        Ensure that your user account has the necessary permissions to access the DB2 JDBC files.

        Oracle

        ojdbc6.jar

        SQL Server

        Download the SQL Server JDBC 2 driver from the Microsoft website to a local directory and enter that directory name in the JDBC driver library field.

        The directory must not contain the sqljdbc.jar file, only the sqljdbc4.jar file. Even though the data source is configured to use the sqljdbc4.jar file, an exception occurs if both files are present in the same directory.

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

      7. Enter the User ID and Password for each DB. If each DB uses the same user credentials, select the Use the same password for all applications check box and then enter the UID and password for the first DB in the list.

        If your DB type is Oracle, connect to the DB with the UID that you used when you created the application DB.

      8. Click Validate to verify your DB settings. If the validation fails, check your DB settings. When the validation succeeds, click Next.

        IBM Installation Manager tests your DB connection with the DB values that you supplied. You can change the DB configuration later in the WAS Integrated Solutions Console.

    14. Review the summary information. Click Back to change the information or click Update to install the selected fix packs.

    15. When the installation is complete, restart the clusters and node agents and synchronize the nodes.


    Results

    Your IBM Connections deployment has been updated. To check the logs, go to connections_root/logs and open the applicationUpdate.log file, where application is the name of an IBM Connections application. If you added new applications, check the applicationInstall.log file as well.


    Install a fix pack in silent mode

    Silently install a fix pack to update IBM Connections.

    Important information about the user account:

    • AIX and Linux: Use the same operating system user account to install this fix pack that was used to install IBM Connections 4.0. If that account is no longer available, recreate it with the same user name and password and use it to install the fix pack.

    • (AIX and Linux) If you installed IBM Connections 4.0 as a root user, you cannot install this fix pack as a non-root user.

    • Windows: Use an operating system user account that is in the same Administrators group as the account that was used to install IBM Connections 4.0.

    • Ensure that you have downloaded and extracted the latest fix pack. See the Downloading fixes topic for more information.

    • You must run IBM Installation Manager on the system where the Deployment Manager is installed.

    • Create a response file for this task by running a simulated modification.

      Instead of generating a new response file, you can edit the default response file that is provided with the product. However, if you edit the default response file, you need to add encrypted passwords to the file. For more information, see the Creating encrypted passwords for a response file topic.

    • If an error occurs during installation, IBM Installation Manager cancels the installation and rolls back the installation files. Installation errors are usually caused by environment problems such as insufficient disk space, privilege issues, or corruption of a WebSphere profile. If your installation is cancelled, complete the following steps:

      1. Identify and resolve the error that caused the cancellation. After cancelling the installation, IBM Installation Manager displays an error message with an error code. You can look up the error code in the Installation error messages topic or check the log files.

      2. Start this task again.

    A silent update uses a response file to automate the installation of a fix pack.

    To change the paths to the response file and log file, edit the generate_other_responsefile.sh file.

    To perform a silent update, complete the following steps:

    1. Stop all clusters and node agents in your deployment but leave the Deployment Manager running.

    2. Open a command prompt and change to the IM_root/eclipse directory.

    3. Run the following command:

      • AIX or Linux: ./IBMIM --launcher.ini silent-install.ini -input fixpack_root/LC_update.rsp -log ./update.log

      • Windows: IBMIMc.exe --launcher.ini silent-install.ini -input fixpack_root\LC_update.rsp -log .\update.log

        If you stored the response file in a location that is different from the default location, change the path in the command to point to the file.

    4. When the installation is complete, restart the clusters and node agents and synchronize the nodes.


    What to do next

    Check the update.log file for errors and repeat this task if necessary.


    Install a fix pack in console mode

    Use console mode to install a fix pack to update IBM Connections.

    Important information about the user account:

    • AIX and Linux: Use the same operating system user account to install this fix pack that was used to install IBM Connections 4.0. If that account is no longer available, recreate it with the same user name and password and use it to install the fix pack.

    • (AIX and Linux) If you installed IBM Connections 4.0 as a root user, you cannot install this fix pack as a non-root user.

    • Windows: Use an operating system user account that is in the same Administrators group as the account that was used to install IBM Connections 4.0.

    • Ensure that you have downloaded and extracted the latest fix pack. See the Downloading fixes topic for more information.

    • You must run IBM Installation Manager on the system where the Deployment Manager is installed.

    • If an error occurs during installation, IBM Installation Manager cancels the installation and rolls back the installation files. Installation errors are usually caused by environment problems such as insufficient disk space, privilege issues, or corruption of a WebSphere profile. If your installation is cancelled, complete the following steps:

      1. Identify and resolve the error that caused the cancellation. After cancelling the installation, IBM Installation Manager displays an error message with an error code. You can look up the error code in the Installation error messages topic or check the log files.

      2. Start this task again.

    To install a fix pack in console mode, complete the following steps:

    1. Stop all clusters and node agents in your deployment but leave the Deployment Manager running.

    2. Open a command prompt and change to the IM_root/eclipse/tools

    3. Start IBM Installation Manager:

      • AIX or Linux: ./imcl.sh -c

      • Windows: ./imcl.exe -c

    4. In the console window, specify the IBM Connections repository:

      1. Type P to edit preferences.

      2. Type 1 to specify repositories.

      3. Type D to add a repository.

      4. Set the full path to the fix pack that you downloaded. For example: C:\IBM\Connections\update\fixes\401_Fixpack.

      5. Type A to save the repository information.

      6. Type C to return to the console window.

      7. Type 1 to start the configuration.

      8. Type 2 to select Update and then type N to proceed.

      9. Select the fix pack to install and then type 'N' to proceed.

    5. Ensure that all the applications are selected and type N to proceed.

      All of the installed applications are selected by default. If you add any of the unselected applications, those applications will be installed. If you clear any of the selected applications, those applications will be uninstalled.

      If you have not previously installed the Metrics application, you cannot select it here. However, you can install it later by modifying the IBM Connections installation.

    6. Enter the administrative ID and password of the Deployment Manager.

      This ID is set to the connectionsAdmin J2C authentication alias, which is mapped to the following J2EE roles: dsx-admin, widget-admin, and search-admin. It is also used by the service integration bus. To use security management software such as Tivoli Access Manager or SiteMinder, the ID that you specify here must exist in the LDAP directory.

    7. Configure your topology.

      The panel described in this step appears only if you selected new applications to install.

      • Small deployment:

        1. Type 1 to select the Small deployment topology.

        2. Enter a Cluster name for the topology.

        3. Select a Node.

        4. Enter a Server member name for the node.

        5. Type N to proceed.

      • Medium deployment:

        1. Type 2 to select the Medium deployment topology.

        2. Select the default value or enter a Cluster name for each application or for groups of applications.

          For example, use Cluster1 for Activities, Communities, and Forums.

          Installation Manager creates servers and clusters when required.

        3. Select a Node for each cluster. Accept the predefined node or select a different node.

          These nodes host application server instances that serve IBM Connections applications. You can assign multiple nodes to a cluster, where each node is a server member of that cluster.

        4. Enter a Server member name for the selected node. Choose the default or enter a custom name.

          If you enter a custom server member name, the name must be unique across all nodes in your deployment.

        5. The topology specified is displayed. To re-specify any details, type the number that corresponds to the application; for example, type 1 for Activities.

        6. Type N to proceed.

      • Large deployment:

        1. Type 3 to select the Large deployment topology.

        2. Enter a Cluster name for each application.

          IBM Installation Manager creates servers and clusters when required.

        3. Select a Node for each cluster. Accept the predefined node or select a different node.

          These nodes host application server instances that serve IBM Connections applications. You can assign multiple nodes to a cluster, where each node is a server member of that cluster.

        4. Enter a Server member name for the selected node. Choose the default or enter a custom name.

          If you enter a custom server member name, the name must be unique across all nodes in your deployment.

        5. The topology specified is displayed. To re-specify any details, type the number that corresponds to the application; for example, type 1 for Activities.

        6. Type N to proceed.

    8. Enter the DB information.

      The panel described in this step appears only if you selected new applications to install and if the new applications require DB configuration.

      1. Specify whether the installed applications use the same DB server or instance: Type 1 to specify that the applications use same DB server or instance; type 2 to specify that they use different DB servers or instances.

        If allowed by your DB configuration, you can select multiple DB instances as well as different DB servers.

      2. Select a Database type from one of the following options:

        • IBM DB2 Universal Database
        • Oracle Enterprise Edition
        • Microsoft SQL Server Enterprise Edition

      3. Enter the Database server host. For example: appserver.enterprise.example.com

        If your installed applications use different DB servers, enter the DB host for each application.

      4. Enter the Port number of the DB server. The default values are: 50000 for DB2, 1521 for Oracle, and 1433 for SQL Server.

        If your installed applications use different DB servers or instances, enter the port for each DB server or instance.

      5. Enter the JDBC driver location. For example:

        • AIX: /usr/IBM/WebSphere/AppServer/lib

        • Linux:

          /opt/IBM/WebSphere/AppServer/lib

        • Windows:

          C:\IBM\WebSphere\Appserver\lib

      6. Ensure that the following JDBC driver libraries are present in the JDBC directory:

        DB2

        db2jcc.jar and db2jcc_license_cu.jar

        Ensure that your user account has the necessary permissions to access the DB2 JDBC files.

        Oracle

        ojdbc6.jar

        SQL Server

        Download the SQL Server JDBC 2 driver from the Microsoft website to a local directory and enter that directory name in the JDBC driver library field.

        The directory must not contain the sqljdbc.jar file, only the sqljdbc4.jar file. Even though the data source is configured to use the sqljdbc4.jar file, an exception occurs if both files are present in the same directory.

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

      7. Enter the User ID and Password for each DB. If each DB uses the same user credentials, confirm the Use the same password for all applications question and then enter the UID and password for the first DB in the list.

        If your DB type is Oracle, connect to the DB with the UID that you used when you created the application DB.

      8. If you need to make changes, type the number that corresponds to the application to change. Alternatively, type R to reset all the DB specifications to their default values.

      9. Press Enter to verify your DB settings. If the validation fails, check your DB settings. When the validation succeeds, click Next.

        IBM Installation Manager tests your DB connection with the DB values that you supplied. You can change the DB configuration later in the WAS Integrated Solutions Console.

      10. If the verification check is successful, type N to proceed. If verification fails, press B to re-enter the required information.

    9. Review the information that you entered. To revise your selections, press B. To install the update, press U.

    10. When the installation is complete, restart the clusters and node agents and synchronize the nodes.


    Results

    Your IBM Connections deployment has been updated. To check the logs, go to connections_root/logs and open the applicationUpdate.log file, where application is the name of an IBM Connections application. If you added new applications, check the applicationInstall.log file as well.


    Synchronize nodes

    Synchronize all the nodes in a cluster.

    Ensure that synchronization is enabled. After updating or changing your deployment, you usually need to synchronize those changes to the nodes in your deployment.

    To synchronize the nodes:

    1. Log in to the WAS Integrated Solutions Console for the Deployment Manager and click System Administration > Nodes.

    2. Select the check boxes for the nodes and click Full Resynchronize.

    3. Click Save.

    4. Restart WAS .


    Enable and disable synchronization

    Enable or disable the synchronization of nodes in a deployment of IBM Connections. You can enable the following types of synchronization from the Deployment Manager:

    • Automatic synchronization . Updates occur on a schedule. This type of synchronization is enabled by default in network deployments

    • Startup synchronization . Updates occur each time the server is started
    To enable or disable synchronization, complete the following steps:

    1. Open the WAS Integrated Solutions Console on the system that hosts the Deployment Manager and 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:

      • To turn on synchronization, select the Automatic synchronization and Startup synchronization check boxes.

      • To turn off synchronization, clear the Automatic synchronization and Startup synchronization check boxes.

    5. Click Save.

    6. Click System Administration > Node agents.

    7. Select the check box of the node for which you are enabling or disabling synchronization, and click Restart. If you are turning synchronization on or off for more than one node, perform this step for each node.

    8. Restart the Deployment Manager.


    What to do next

    To perform a full synchronization, see the Synchronizing nodes topic.


    Uninstall fixes

    If the installation of a fix pack or interim fix fails, you can restore your IBM Connections environment to its previous state.

    Use the update wizard to uninstall interim fixes. There are two modes in which you can run the wizard:

    Interactive mode

    You must confirm each step of the process

    Silent mode

    You use a series of commands and parameters to launch and run the wizard


    Uninstall interim fixes in interactive mode

    If the interim fix installed is not working, you can uninstall it using the update wizard in interactive mode.

    Ensure that you have met the following prerequisites:

    • You have restored your DBs

    • The WAS_HOME environment variable has been set for Linux and Windows

    To uninstall interim fixes with the update wizard in interactive mode:

    1. From the updateInstaller directory under the connections_root directory, run the following script:

      • AIX or Linux:

        ./updateWizard.sh

      • Microsoft Windows::

        updateWizard.bat

    2. On the Welcome panel, click Next to continue.

    3. Select the check boxes of the interim fixes that you wish to uninstall, and then click Next.

    4. Enter the WAS Deployment Manager administrator UID and password and click Next.

    5. Review the information that you have entered. To make changes, click Back. To start uninstalling, click Next.

    6. Review the result of the update. Click Finish to exit the wizard.


    Results

    At least two logs are created by the wizard under the connections_root/version/log directory:

    • Date_Time_ifix name_application name_install.log

    • Date_Time_ifix name_install.log


    Uninstall interim fixes in silent mode

    If the interim fix installed is not working, you can uninstall it using the update wizard in silent mode.

    Ensure that you verified the following prerequisites:

    • You restored your DBs

    • The WAS_HOME environment variable is set for Linux and Windows

    To uninstall an interim fix in silent mode, complete the following step:

    Open a command prompt and enter the following command:

    updateSilent.sh|exe -installDir fix_file_location -fix -uninstall -fixes fix1_id fix2_id -wasUserId AdminUserId -wasPassword AdminPwd -featureCustomizationBackedUp <yes|no>

    where:

    • fix_file_location is the directory containing the downloaded interim fix.

    • fix1_id and fix2_id are the label of the interim fixes to remove. Repeat this parameter as often as required.

    • AdminUserId is the UID for WAS Deployment Manager.

    • AdminPwd is the password for WAS Deployment Manager.

    • <yes|no> is the possible value of the featureCustomizationBackedUp parameter; this parameter indicates if you have backed up your customizations but does validate any such backup


    Results

    The log files that are created by the wizard are located under the connections_root/version/log directory.


    Roll back a fix pack in interactive mode

    If the fix pack installed is not working, you can uninstall it in interactive mode using IBM Installation Manager.

    Ensure that you have restored your DBs.

    You can also use a silent method to uninstall fix packs.

    To uninstall fix packs in interactive mode, complete the following steps:

    1. Stop all clusters in your deployment.

    2. From the IM_root directory, run the file to start IBM Installation Manager:

      • AIX or Linux: ./launcher

      • Windows 32-bit: launcher.exe

    3. Click Roll Back.

    4. Select the fix packs to uninstall and click Next. Ensure that IBM Connections is shown in the Package Group Name column and that the correct update version is shown under Installed Packages and Fixes. Click Next.

    5. Select the target check box and click Next.

    6. Enter the administrative ID and password of the Deployment Manager. Click Validate to verify the information that you entered and that application security is enabled on WAS. If the verification fails, IBM Installation Manager displays an error message.

    7. Review the summary information. Click Roll Back to uninstall the selected fix pack.

    8. Review the result of the update. Click Finish to exit the wizard.

    9. When the uninstallation is complete, synchronize all the nodes and restart all the clusters.


    Results

    To check the details of the uninstallation, open the log files in connections_root/logs. Each IBM Connections application that you uninstalled has a log file, using the following naming format: application_nameUninstall.log, where application_name is the name of an IBM Connections application. If you added new applications, check the application_nameInstall.log file as well. To check the details of updated applications, open the application_nameUpdate.log file.


    Roll back a fix pack in silent mode

    If the fix pack installed is not working, you can uninstall it in silent mode.

    Create a response file for this task by running a simulated rollback.

    Instead of generating a new response file, you can edit the default response file that is provided with the product. However, if you edit the default response file, you need to add encrypted passwords to the file. For more information, see the Creating encrypted passwords for a response file topic.

    A silent rollback uses a response file to automate the removal of a fix pack.

    To change the paths to the response file and log file, edit the lc_install.ini file.

    To perform a silent rollback:

    1. Stop all clusters and node agents in your deployment but leave the Deployment Manager running.

    2. Open a command prompt and change to the IBM Installation Manager directory. The default location is:

      • AIX or Linux: /opt/IBM/InstallationManager/eclipse

      • Windows: C:\Program Files\IBM\Installation Manager\eclipse

    3. Run the following command to start IBM Installation Manager:

      • AIX or Linux: ./IBMIM --launcher.ini silent-install.ini -input connections_root/silentResponseFile/rollback_file.rsp -log ./rollback.log

      • Windows: .\IBMIMc.exe --launcher.ini silent-install.ini -input connections_root\silentResponseFile\rollback_file.rsp -log .\rollback.log

      where rollback_file is the name of your response file. The default rollback response file is lc_rollback.rsp.

    4. When the installation is complete, restart the clusters and node agents and synchronize the nodes.


    Results

    Check the rollback.log file for errors and repeat this task if necessary.


    Roll back a fix pack in console mode

    Use console mode to uninstall a fix pack.

    If the fix pack installed is not working, you can roll back your deployment to the previous configuration.

    To uninstall a fix pack in console mode:

    1. Stop all clusters and node agents in your deployment but leave the Deployment Manager running.

    2. Open a command prompt and change to the IM_root/eclipse/tools

    3. Start IBM Installation Manager:

      • AIX or Linux: ./imcl.sh -c

      • Windows 32-bit: ./imcl.exe -c

    4. In the console window, type 4.

    5. Select the fix pack to roll back and then type 'N' to proceed.

    6. Review the information that you entered. To revise your selections, press B. To roll back the update, press R.

    7. When the rollback finishes, type F to exit IBM Installation Manager.


    Results

    To check the details of the uninstallation, open the log files in connections_root/logs. Each IBM Connections application that you uninstalled has a log file, using the following naming format: application_nameUninstall.log, where application_name is the name of an IBM Connections application. If you added new applications, check the application_nameInstall.log file as well. To check the details of updated applications, open the application_nameUpdate.log file.

    +

    Search Tips   |   Advanced Search

    +

    Search Tips   |   Advanced Search