Scenario 4: Upgrading Connections 2.5 from a Standalone, Single Server to a Single Node Cluster of Connections 3.0  

1.  Overview

Deployment scenario 4 demonstrates how to upgrade Lotus Connections 2.5 from a standalone single server, using the supported system requirements, to a single node cluster of Lotus Connections 3.0.  This example assumes the deployment is installed on Microsoft Windows 2003 on VMware using an ITDS LDAP directory, and a DB2 Database Server. For general deployment instructions and system requirements, refer to the Lotus Connections Wiki and system requirements as follows:

http://www-10.lotus.com/ldd/lcwiki.nsf/xpViewCategories.xsp?lookupName=Lotus%20Connections%203%20documentation
https://www.ibm.com/support/docview.wss?uid=swg27019882

2.  Scenario environment

The scenario described in this article is that of a customer migrating a single server deployment of Lotus Connections 2.5 to Lotus Connections 3.0 in a network deployment with one node.

The following describes the environment in more detail prior to migration:

· Operating System: Microsoft Windows Server 2003 Enterprise Edition, Service Pack 2 is installed on all machines.
· Database Server: DB2 9.7 Enterprise server Edition is used as the backend database to Connections. In this scenario, a single database instance is hosting all eight databases required for Lotus Connections to run.
· User Directory: The LDAP server being used is a IBM Tivoli Directory Server (TDS)
· Application Server: WebSphere Application Server 6.1.0.23
· Plug-ins supported: All plug-ins are supported in this environment.
· Secure Sockets Layer (SSL): SSL is only enabled for authenticating users in this configuration.

After the migration to Lotus Connections 3.0, all of the infrastructure components are the same with the exception of Websphere and TDI Servers.

· Application Server: WebSphere Application Server 7.0.0.11
· Tivoli Directory Integrator (TDI)

3.  Migration Strategies

There are different strategies for migrating to Lotus® Connections 3.0 and you need to choose one that suits your topology, resources, and schedules.  The migration strategy that you choose depends on the size of your deployment, the downtime that you can tolerate, and your hardware environment.  The following two strategies are the most common choices.  We are giving these as examples to help you build your migration strategy:

3.1 Minimum down-time strategy:

This strategy involves the least amount of down time for your end users.  This strategy requires additional hardware.

The following steps are a high-level overview:

1.  Install the supporting software (including WebSphere® Application Server 7.0.0.11) on new hardware.

2.  Stop Lotus Connections 2.5.

3.  Complete the following steps simultaneously:

   a. Update your databases to release 3.0.

   b. Install Lotus Connections 3.0 and migrate Lotus Connections 2.5 configuration settings and content stores to release 3.0.

   c. Apply any customizations, configuration and company-specific branding.

4.  Update the URLs to point to the new deployment.

3.2 Hardware efficiency strategy:

With this strategy, you are reusing your existing hardware. Because it involves extra steps in uninstalling your WebSphere Application Server and Lotus Connections 2.5 stack, it does add to the downtime you will experience.

Important: The steps outlined in this document will use the hardware efficiency strategy.
The following steps are a high-level overview:

1.  Stop Lotus Connections 2.5.

2.  Back up Lotus Connections 2.5.

3.  Export Lotus Connections 2.5 data and configurations.

4.  Uninstall Lotus Connections 2.5.

5.  Uninstall WebSphere Application Server 6.1.0.23.

6.  Update your databases to release 3..0

7.  Install WebSphere Application Server 7.0.0.11.

8.  Install Lotus Connections 3.0.

   a. Migrate Lotus Connections 2.5 configuration settings and content stores to release 3.0.

   b. Apply any customizations and company-specific branding.       

9.  Start your new Lotus Connections 3.0 deployment.

Important note:  With Lotus Connections 3.0, all deployments will use the Network Deployment Model (Deployment Manager/DMGR) of WebSphere.  Make sure you have sufficient resources on your existing hardware to run both WebSphere Application Server node and deployment manager on the same machine.  In larger deployment you may want to separate and run the deployment manager on its own dedicated hardware.

4.  Preparing for the upgrade

As with any upgrade, upgrading to Lotus Connections 3.0 requires preparation work.  The following section describes the steps we took to prepare our environment and users for the Lotus Connections upgrade. 

Before you begin:
Best Practice #1: It is always good to go through a practice upgrade on a test environment before trying it in production.
Best Practice #2: Before you begin the upgrade ensure that your systems meet the requirements for Lotus Connections 3.0. For more information, see the Lotus Connections system requirements tech note:

Lotus Software Knowledge Base Document # 7019882 here:    
http://www-01.ibm.com/support/docview.wss?uid=swg27019882

4.1 Prepare to stop Lotus Connections 2.5

Inform users of the planned outage and let them know when the maintenance work will begin and how long it will 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. Perform one of the following steps during the planned outage – these are the two options of informing users of the outage:

1.  Stop the IBM HTTP Server – only do this if no other applications are using the IBM HTTP Server.
2.  Keep the webserver running but prevent user-access to the deployment during the migration or upgrade. To accomplish this, set up a maintenance page and create rewrite rules in the httpd.conf configuration file for the IBM HTTP Server to redirect requests for Lotus Connections. Create an HTML document (.htm file) notifying users of the server maintenance window. The maintenance page can inform users that Lotus Connections is temporarily unavailable because of scheduled maintenance work.

a. Update your httpd.conf file to include these ErrorDocument statements:
   ErrorDocument 401 /upgrading.htm
   ErrorDocument 403 /upgrading.htm
b.  Add the following element to your httpd.conf file to block all non-authorized IP addresses from reaching the server and to send the user to the upgrading.htm page:

{code}

Order Deny,Allow
Deny from all
Allow from
Allow from
{code}

Note: You must have an Allow element for every instance of WebSphere® Application Server in your deployment.

Important: When the migration or update is complete, remove the Location and ErrorDocument stanzas from the httpd.conf file.

4.2 Back up your current deployment

Before upgrading to Lotus Connections 3.0, it is very important to have a full backup of your Lotus Connections 2.5 Deployment.  Each company usually has its own backup methodology.  In this section we will outline the best practice for taking a backup.

1.  Stop the IBM WebSphere® Application Server instances that are hosting Lotus Connections.
2.  Create a backup copy of the databases using native database tools. If the update fails, use this backup to restore the databases. As Lotus Connections supports multiple database servers, such as SQL, Oracle, DB2, we will not outline the exact steps.  In most deployments, the database administer can help your Lotus Connections administrator accomplish backup of the databases.
3.  Create a backup copy of the WebSphere Application Server profile directory:

a. For example in our deployment we created a backup of the following directory.
C:\IBM\WebSphere\AppServer\profiles\AppSrv01
b. Create a back-up copy of the Lotus Connections installation directory:
C:\IBM\WebSphere\LotusConnections
Note: If Lotus Connections applications are deployed on separate profiles, archive each profile.
c. Create a back-up copy of the profileRegistry.xml file, located under C:\IBM\WebSphere\AppServer\properties

4. Back up any customized configuration files.
The update or migration process changes several configuration files, including files that you might have customized. Customized files can include header and footer HTML files, CSS and JSP files, themes. Make a backup of any customizations, so that they can be reapplied to the LC 3.0 version.

Important: If you are using Lotus Connections Connectors, such as Lotus Quickr® or Confluence, you will have to reinstall them after migration. Similarly, if you defined a server whitelist for publishing file attachments from Activities to Lotus Quickr, back it up before migration. You will need to re-define it manually after the migration is complete.

4.3 Migrate Lotus Connections 2.5 to release 3.0 (export data)

To export data from your 2.5 deployment, complete the following steps:

Procedure
1. Copy the Lotus Connections 3.0 lotus_connections_root /migration directory from the install media to the Lotus Connections 2.5 installation directory.

Ensure that you copy the migration directory to the same directory level as the ConfigEngine directory in your existing Lotus Connections data directory.

2. Open a command prompt, change to the migration directory and run the following command:

Note: The migration process can take a long time to complete, depending on the number and size of files in your content store directories. If the directories contain more than 1 GB of data, use the -DhandleData=false parameter to bypass the export. When you are prompted to select the content store directories during install of LC 3.0, re-use the 2.5 content store directories.
             migration.bat lc-export
Notes:
• The lc-export command exports the following data:
➢ Content in the data directories for each application
➢ Configuration and properties files in the LotusConnections-config directory. You can find this directory in the following location:
• C:\IBM\WebSphere\AppServer\profiles\AppSrv01\config\cells\ServerNode01Cell\ LotusConnections-config
• The migration tool collects data from all applications even when they are in different WebSphere Application Server profiles. The location of each application is recorded in the ConfigEngine directory in the lotus_connections_root directory. After extracting the 2.5 data, the tool uses the same method to determine where the 3.0 applications are located and imports the data accordingly.
• C:\IBM\WebSphere\LotusConnections\ConfigEngine
•  The exported data is stored in the migration directory. Check the log file to validate the export. The log is stored in the system user's home directory, and uses the following naming format:lc-migration-yyyyMMdd_HHmm_ss.log
For example:
➢ C:\Documents and Settings\Administrator\lc-migration-20100922_1534_26.log

3. Back up the migration directory to a location outside of your 2.5 deployment.

4.4 Uninstall Lotus Connections and WebSphere Application Server 6.1.0.23

4.4.1. Uninstall Lotus Connections

Note: If you are installing version 3.0 on a different system from version 2.5, you do not need to uninstall version 2.5.

Use the Lotus Connections 2.5 uninstall wizard.

To uninstall Lotus Connections, complete the following steps:

1. Log into the Application Server as the system administrator.

2. Open a command prompt and change to the lotus_connections_root/uninstall directory.

3. Run the uninstallation wizard:               

                * Windows: uninstall.bat



4. Select a language to use for the installation procedure and click Next.

5. On the Welcome page of the Uninstallation Wizard, click Next.



6. Select the Stand-alone deployment option and click Next.



7. Select all the features and click Next.



8. Review the summary panel. If you want to make any changes, click Back to edit the values that you entered. Click Next to begin the uninstallation process.



9. When the features have been uninstalled, click Finish to close the uninstallation wizard.

10. To remove all Lotus Connections application files, delete the lotus_connections_root directory. (Ensure that the backup was created prior to performing this step.)

What to do next:

Clean your systems by removing files that remain after uninstalling. For more information, see the uninstalling Lotus Connections topic in the Product Documentation.

4.4.2  Uninstall WebSphere Application Server 6.1.0.23

Since we are installing Lotus Connections 3.0 onto WebSphere Application Server 7.0, we need to first uninstall our previous version of WebSphere Application Server 6.1.0.23.

1. Log on as a user who belongs to the Administrators group or as the user who installed the product.

2. Stop each running application server with the stopServer command:
       stopServer.bat server1

If a server is running and security is enabled, use the following command:
      stopServer.bat server1 -user user_ID -password password

If you have multiple servers, you can use the serverStatus command to find running application servers. Issue the following command from the profile_root /bin directory to determine which servers, if any, are running:
     serverStatus.bat -all

3. Issue the uninstall command:

      app_server_root\uninstall\uninstall.exe

The uninstaller wizard begins and displays the Welcome panel.

You can also issue the uninstall command with a silent parameter to use the wizard without the graphical user interface.

Issue the following command to start the uninstaller wizard in silent mode, without the graphical user interface, and to remove all profiles:
          app_server_root\uninstall\uninstall -silent (default behavior)

          app_server_root\uninstall\uninstall -silent -OPT removeProfilesOnUninstall="true"

4. If you are using the wizard, click Next to begin uninstalling the product.

The uninstall wizard displays a confirmation panel that lists a summary of the components that you are uninstalling.

a. Click Next to continue uninstalling the product.

b. After uninstalling the application server profile, the uninstaller program deletes the core product files.

c.  Click Finish to close the wizard after the wizard removes the product.

5.  Review the log file:

      app_server_root /logs/uninstall/log.txt

The log file records file system or other unusual errors. Look for the INSTCONFSUCCESS indicator of success in the log:

{code}

      (date_time),

      Uninstall, com.ibm.ws.install.ni.ismp.actions.

      SetExitCodeAction, msg1,

      CWUPI0000I: EXITCODE=0

      (date_time),

      Uninstall, com.ibm.ws.install.ni.ismp.actions.

      ISMPLogSuccessMessageAction, msg1,

      INSTCONFSUCCESS{code}

6. If any product files remain, delete manually before reinstalling.

The uninstaller program leaves some log files, including the app_server_root /logs/uninstall/log.txt file.

Manually uninstall the product to remove all artifacts of the product so that you can reinstall into the same installation root directory. If you do not plan to reinstall, you do not need to manually uninstall.

Reinstalling the product into a new directory when files remain from a previous installation can create a coexistence scenario. However, you can delete all files and registry entries to completely remove a WebSphere Application Server product. A clean system lets you reinstall the product into the original directory without coexistence.

Default directories are shown in the following planning table (Table 1. ):

Default Location	Actual Location
app_server_root	C:\Program Files\IBM\WebSphere\AppServer
profile_root	C:\Program Files\IBM\WebSphere\AppServer\profiles
plugins_root	C:\Program Files\IBM\WebSphere\Plugins

7. Delete product registry entries for the WebSphere Application Server product that you are uninstalling.

Edit the Windows system registry by invoking the regedit.exe command from a command prompt.

Handle the Registry with care
Note: You can easily make a mistake while using the registry editor to view and edit registry contents. The editor does not warn you of editing errors, which can be extremely dangerous. A corrupt registry can disrupt your system to the point where your only option is to reinstall the Windows operating system.

a. Press Ctrl-F to search for all instances of WebSphere to determine whether you should delete each entry. You might not be able to remove all of the entries related to WebSphere Application Server, which is not a problem.

b. Expand and select keys related to WebSphere Application Server products. See Operating system registry keys for a list of Windows registry keys to search for and delete.

c.  Click Edit > Delete from the menu bar for each related key.

d.  Click Yes when asked to confirm deletion of the key.

e. Click Registry > Exit from the menu bar when you are finished.

f. Delete the installation root directory for the product that you are uninstalling.

g. Locate all of the profile directories and delete the directories if they were located outside of the app_server_root directory and were not deleted in the previous step.

h. Open a Windows Explorer window and browse to the C:\Documents and Settings\All Start Menu\Programs\IBM WebSphere directory.

Note: If you are running Windows 2008, then browse to the C:\Users\\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\WebSphere directory.

If you have one installation of a WebSphere Application Server product, delete the following folder: Application Server Network Deployment v6.x

i. Edit the vpd.properties file.

The file is located in the installation directory of the operating system, such as the C:\WINNT directory or the C:\windows directory.

Do not delete or rename the vpd.properties file because the InstallShield MultiPlatform (ISMP) program uses it for other products that it installs. If the WebSphere Application Server product that you are uninstalling is the only product with entries in the vpd.properties file, you can delete this file.

j. Use the installRegistryUtils command to examine the installation locations for all installed WebSphere Application Server products and remove the desired products from the install registry.

k. Restart your machine if a prompt displays that directs you to restart.

This procedure results in having a clean system. You can reinstall into the same directories now. A clean system has no trace of a previously deleted installation.

5.  Upgrade/migration steps

5.1 Upgrade your Lotus Connections 2.5 databases to release 3.0

For more information, see the Updating databases topic.
There are a couple of options for upgrading your database from Lotus Connections 2.5 to the Lotus Connections 3.0 schema.

1. In place upgrade either manually or using the wizard.
2. Side by side upgrade, which can only be done manually.

To simplify the process, we have chosen to upgrade in place using the Wizard.

Note: You must perform the database upgrade with a user who has full administrator privileges.

1. First step is to ensure you are using the appropriate JRE. If you have moved the database upgrade scripts, you will need to point your PATH variable to the JRE provided with the LC 3.0 Wizards; the relative path might be \IBM\Lotus_Connections\Wizards.

Note: Currently we only support running the upgrade using the Java Runtime Environment (JRE) provided with upgrade scripts.

2. Stop the WebSphere Application Server.

3. Log in to the database server as Administrator, for DB2  it appears similar to the following:

Run the database wizard:

Select the database type:


Select the features you want to upgrade as follows:



Enter your the database server information, host name, port number, admin name and password:


A confirmation screen is displayed with the components you selected:


When the database upgrade has completed, review the Post Configuration Task Summary panel for any errors and, click View Log to open the log files directory if necessary. Click Finish to exit the wizard.

5.2 Install WebSphere Application Server 7.0.0.11

5.2.1 Install WebSphere 7.0

This step involves setting up a DMGR server, 1 managed node (in this case I installed everything on 1 system, so installed a cell).  Then you need install and apply fix pack 11 to WebSphere Application Server.

5.2.2 Install WebSphere Application Server Cell

1.

2.

3.

4.

5.

6. I did not select any optional features as shown:

7. I changed the install location to C:\IBM\WebSphere\AppServer as follows:

8. Because I’m installing everything on a single server, I chose Cell:

9.

10.

11.

12.

13.

14.

5.2.3  Install WebSphere Update Installer

I am installing WebSphere update installer version 7.0.0.11-WS-UPDI-WinIA32.

1.

2.

3.

4. I changed the install directory to C:\IBM\WebSphere\UpdateInstaller:

5.

6. I went ahead and clicked Finish.
 

5.2.4 Install WebSphere Application Server 7.0 fix pack 11 – 7.0.0.11

Download fix pack 11 from the following technote:  http://www.ibm.com/support/docview.wss?uid=swg24026852

You need the AppServer fix pack, for Win 2003 32 bit, like this:

32-bit x86 AMD/Intel AppServer06/18/2010US English646832763

1. Copy 7.0.0-WS-WAS-WinX32-FP00000011.pak to C:\IBM\WebSphere\UpdateInstaller\maintenance.

2. Run C:\IBM\WebSphere\UpdateInstaller\update.bat.

3.

4.

5.

6.

7.

8.

9.

5.2.5 Perform the same steps for the Deployment Manager and nodes to install the WebSphere Application Server SDK FP11 as well.

http://www.ibm.com/support/docview.wss?rs=180&uid=swg24026858

5.3 Configure Federated Repositories

In this process, we will start WebSphere Application Server and enable security.

5.3.1 Start the DMGR, nodeagent and node1’s server1

1. Start the DMGR by running: C:\IBM\WebSphere\AppServer\profiles\Dmgr01\bin>startManager.bat

2. Start the nodeagent by running: C:\IBM\WebSphere\AppServer\profiles\AppSrv01\bin>startServer.bat nodeagent

3. Start server1 by running: C:\IBM\WebSphere\AppServer\profiles\AppSrv01\bin>startServer.bat server1

5.3.2 Enable security with an LDAP Directory

1. Open a browser to the dmgr Integrated Solutions Console: (http://valletta.swg.usma.ibm.com:9060/ibm/console), add a user ID (the name is not important) and click Log in.

2. Open Security – Global Security.

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

4. On the Federated Repositories page, enter an administrative user ID (for example, localadmin) in the Primary administrative user name field. You can leave the other default settings, such as Realm name, unchanged.
Note: The administrative user ID must be unique, and must not exist in the LDAP repository to be federated.

5. From the Server user identity area, select automatically generated server identity as the server user identity.

6. Click Apply.

7. Type the password for the administrative user in the Password and Confirm password fields. Click OK.

8. Click Save to save this setting.

9. Click Add Base entry to Realm.

10. On the Repository reference page, click Add Repository.

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

12. Specify the LDAP directory that you are using in the Directory type field.

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

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

15. Specify the login attribute or attributes that you want to use for authentication in the Login properties field. Separate multiple attributes with a semicolon. For example: uid;mail.

16. Click Apply.

17. Click Save.

18. Set the base entry fields, and click OK.

19. Click Save.

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

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

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

23. Set the objectClass to the group objectClass for you directory, and add the search base for groups, Click Apply.

24. Click Save to save this setting.

25. You can do the same for PersonAccount, in my ldap, we use inetOrgPerson, so I did not change anything.

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

27. Complete the following steps for group membership:

a. Click the Group attribute definition link in the Additional Properties area.

b. Click the Member attributes link.

c. Click New to create a group attribute definition.

d. Enter group membership values in the Name of member attribute and Object class fields.  Click OK.

e. Click Save to save this setting.

28. Set the new repository as the current repository:

a. Click Global Security in the navigation links at the top of the page.

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

c. Click Apply.

29. Enable login security on WebSphere Application Server:

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

b. Click Apply.

c. Click Save to save this configuration.

30. Log out of the WebSphere Application Server Integrated Solutions Console and restart WebSphere Application Server. If you are performing this task on the Deployment Manager console, restart that console.
a. Run C:\IBM\WebSphere\AppServer\profiles\Dmgr01\bin>stopManager.bat

b. Then C:\IBM\WebSphere\AppServer\profiles\Dmgr01\bin>startManager.bat

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

a. From the WebSphere Application Server Integrated Solutions Console, select Users and Groups > Manage Users.

b. 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.

32. Once the DMGR is finding users correctly from LDAP, restart node1 to pick up the changes by running


a. C:\IBM\WebSphere\AppServer\profiles\AppSrv01\bin>stopNode.bat

b. C:\IBM\WebSphere\AppServer\profiles\AppSrv01\bin>stopServer.bat server1

c. C:\IBM\WebSphere\AppServer\profiles\AppSrv01\bin>startNode.bat

d. C:\IBM\WebSphere\AppServer\profiles\AppSrv01\bin>startServer.bat server1

5.3.3 Set the JVM heap size

1. Open the Integrated Solution Console on the DMGR and synchronize the node. To do so, open a browser to @nowiki@3and log in as localadmin : password.

2. Go to Servers > Server Types > WebSphere application servers and click on the connections cluster server.

3. On the right-hand side, scroll down to Server Infrastructure, open Java and Process Management and click Process definition.

4. Click Java Virtual Machine.

5. Set
Initial heap size: 256
Maximum heap size: 1536

6. Click OK and Save.

5.4 Install Tivoli Directory Integrator 7.0

Before starting the TDI installation and configuration you will want to make sure that the TDI version for LC 2.5 uninstalled.  To uninstall TDI 6.1.1, go your Windows Start menu and click “Uninstall IBM Tivoli Directory Integrator V6.1.1 and follow the menus in the uninstall wizard.


Important: Please make sure you take a backup of any custom TDI configurations, or scripts.  You will need to merge your custom TDI properties files with the 3.0 .properties file.  DO NOT REUSE THE 2.5 CONFIGURATION FILES!
5.4.1 Install Tivoli Directory Integrator (TDI) 7.0 Steps

1.

2.

3.

4.

5.

6.

7.

8.

9.

10.

11.

12.

13.

5.4.2 Configure TDI

1. Copy the db2jcc.jar and db2jcc_license_cu.jar files from the java subdirectory of the directory where you installed DB2 (C:\IBM\SQLLIB\java) .
Paste the files into the jvm/jre/lib/ext subdirectory of Tivoli Directory Integrator. (C:\IBM\TDI\V7.0\jvm\jre\lib\ext)

2. Increase the runtime memory for TDI:

a. Edit C:\IBM\TDI\V7.0\ ibmdisrv.bat

b. At the bottom of the file look for
{code}
"%TDI_JAVA_PROGRAM%" -classpath "%TDI_HOME_DIR%\IDILoader.jar" %ENV_VARIABLES% com.ibm.di.loader.IDILoader com.ibm.di.server.RS %*
{code}
change this to:
{code}
"%TDI_JAVA_PROGRAM%" -Xms256M -Xmx1024M -classpath "%TDI_HOME_DIR%\IDILoader.jar" %ENV_VARIABLES% com.ibm.di.loader.IDILoader com.ibm.di.server.RS %*
{code}

5.4.3 Apply fix pack 5 to TDI

1. After downloading fix pack 5 for TDI 7.0 unzip the download to a location on the hard drive. This creates a folder called 7.0.0-TIV-TDI-FP0005 with and exe file (TDI-7.0-FP0005.zip).

2. Run the following command, pointing to TDI-7.0-FP0005.zip: C:\IBM\TDI\V7.0\bin>applyUpdates.bat -update C:\downloads\TDIv7.0\7.0.0-TIV-TDI-FP0005\TDI-7.0-FP0005.zip

3. Run the following command to ensure the fix pack has been applied:
{code}

C:\IBM\TDI\V7.0\bin>applyUpdates.bat –queryreg

Information from .registry file in: C:\IBM\TDI\V7.0
Edition: General Purpose
Level: 7.0.0.5
{code}

4. License: Full
{code}
Fixes Applied
=-=-=-=-=-=-=
TDI-7.0-FP0005(7.0.0.0)

Components Installed
=-=-=-=-=-=-=-=-=-=
BASE
SERVER
   -TDI-7.0-FP0005
CE
   -TDI-7.0-FP0005
JAVADOCS
EXAMPLES
   -TDI-7.0-FP0005
EMBEDDED WEB PLATFORM
AMC
   Deferred: false
{code}

6. Install Lotus Connections 3.0

For this you will install IBM Rational Install Manager 1.3.3 on the DMGR, then use it to install Lotus Connections.  The Connections install wizard will complete these steps for you.

Stop the node and nodeagent by running:

C:\IBM\WebSphere\AppServer\profiles\AppSrv01\bin>stopServer.bat server1 -username localadmin -password password

C:\IBM\WebSphere\AppServer\profiles\AppSrv01\bin>stopServer.bat nodeagent -username localadmin -password password

1. Start the DMGR if not running: C:\IBM\WebSphere\AppServer\profiles\Dmgr01\bin>startManager.bat

2. Run Lotus_Connections\LC_Install_IM\launchpad.exe. Then click Install Lotus Connections 3.0, and click Launch the Lotus Connections 3.0 install wizard.

3. Select the packages to install.  Choose the default and then click Next.

4. Accept the license agreement.  Click Next.

4.   Choose shared resources directory path, and verify the Installation Manager Directory. Click Next.

5. Specify the path where you would like to install Lotus Connections.

6. Select the features you would like to install.  Click Next.

7. Specify your WebSphere Application Server's Deployment Manager profile, host name, credentials and SOAP port. Click Next.

8. Select the Deployment topology.  Click Next.

9. Specify your database server information.  Click Next.

10. Validate Content Store.

11.  Click OK if Validation is successful.

12. Click Next after successful validation.

13. Choose to enable notifications at this time, or just click Next.

14. Confirm your selections.  Click Back if changes need to be made; otherwise, click Install.

15. After installation is completed successfully, click Finish.

16. After completion, choose to Exit  and click OK. 
 

6.2 Import Data from 2.5 (data dir) – lc import
1.Rename the lotus_connections_root/migration directory on the Deployment Manager node in your 3.0 deployment, and then copy the migration directory that you backed up from your 2.5 deployment to the lotus_connections_root directory in your 3.0 deployment.
2. Import your 2.5 data:
Open a command prompt, change to the migration directory on the Deployment Manager node in your 3.0 deployment, and run the following command:
      Note: If you used the -DhandleData=false parameter during the data export, use that parameter when you run the import command.
          * Windows:
              migration.bat lc-import -DDMUserid= -DDMPassword=           * where is the administrative user ID for WebSphere Application Server Deployment Manager and 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:
C:\Documents and Settings\Administrator\Local Settings\Temp\lc-migration-20101215_1534_26.log
 3. If your deployment uses multiple nodes, perform a full synchronization of all nodes.
6.3 Bring up Lotus Connections 3.0 and confirm your deployment

1. Restart DMGR by running:

a. C:\IBM\WebSphere\AppServer\profiles\Dmgr01\bin>stopManager.bat -username localadmin -password password

b. C:\IBM\WebSphere\AppServer\profiles\Dmgr01\bin>startManager.bat

2. Start the node agent by running:

a. C:\IBM\WebSphere\AppServer\profiles\AppSrv01\bin>startNode.bat

Start Lotus Connections

1. Open the Integrated Solution Console on the DMGR and synchronize the node:

a. Open a browser to http://valletta.swg.usma.ibm.com:9060/ibm/console and log in as localadmin : password.

b. Go to System administration > Nodes.

c. Select the node, and click Full Resynchronize.

2. Start Lotus Connections:

a. Wait for the node to completely synchronize.

b. In the Integrated Solution Console, go to Servers > Server Types > WebSphere application servers.

c. Select the cluster, and click Start.

d. After you get the successfully started message, you are ready to test Connections:

3. Log in to Lotus Connections 3.0 using the WebSphere Application Server port URL’s.  Example: http://servername.domain.com:9081/profiles

7. IBM HTTP configuration

The following section needs to be taken from 5.4 from here:
http://dwlhub.swg.usma.ibm.com/ldd/lotusdraftwiki.nsf/dx/Scenario_1__Installing_Lotus_Connections_3.0_Small_Deployment#Configuring+the+HTTP+Server

8. Perform post-migration tasks

After migrating to IBM® Lotus® Connections 3.0, you need to perform further tasks to ensure that your new deployment is complete. 
1.  Re-apply any proxy configurations.  This is only necessary if in LC 2.5, you performed additional configuration for the AJAX proxy or Reverse proxy.   As we did not for our deployment, we will only include a link to the info center for reference:
http://publib.boulder.ibm.com/infocenter/ltscnnct/v3r0/index.jsp?topic=/com.ibm.connections.25.help/t_admin_config_ajax_proxy.html
and
http://publib.boulder.ibm.com/infocenter/ltscnnct/v2r0/index.jsp?topic=/com.ibm.connections.25.help/t_install_deploy_caching_proxy.html

2.  If you changed the hostname on your install:
Open the httpd.conf file in a text editor. The file is located in the ibm_http_server_root/conf directory.
Uncomment the following line:
LoadModule rewrite_module modules/mod_rewrite.so
Add the following statements:
Note: This example redirects all requests to the pre-migration URL of https://blog25.example.com/weblogs/* to the post-migration URL of https://blog30.example.com/newblogs/*. Substitute your own URLs as appropriate.
RewriteEngine on
RewriteRule /weblogs/(.*) https://blog30.example.com/newblogs/$1 [R,L]
Listen 0.0.0.0:443
RewriteEngine on
RewriteRule /weblogs/(.*) https://blog30.example.com/newblogs/$1 [R,L]
ServerName blog30.example.com
SSLEnable
SSLDisable

3.  Delete your pre-migration search indexes and generate new indexes.
Please note that new indexes will get automatically created and will run on a default schedule as long as the content of the folder referenced in the WebSphere Environment Variable: SEARCH_INDEX_DIR have been deleted.
4.   Remove the Location and ErrorDocument stanzas if you added them to the httpd.conf file before migrating.
5.  If you used Lotus Connections Connectors in release 2.5, such as Lotus Quickr® and Confluence, re-install them.
6.  If you defined a server whitelist in release 2.5 for publishing file attachments from Activities to Lotus Quickr, re-define it after migration.
7.  Update any configuration settings that you customized in 2.5. 
8.  Examine the LotusConnections-config.xml file to see what values were migrated for the following directory service attributes:
communities_directory_service_extension_href
profiles_directory_service_extension_href
These attributes are no longer included in the configuration file in release 3.0 by default.

9. Configuring Administrative Users for Blogs and Homepage:

https://idoc2.swg.usma.ibm.com/connections/index.jsp?topic=/com.ibm.lotus.connections.doc_2.5.1/t_create_admin.html

10.  Mandatory: With the version 3.0 release, enhancements were introduced to enable user data changes to be pushed automatically from the Profiles database to the databases of the other applications. After migrating to 3.0, the application databases may not be fully in sync with each other or the corporate user directory. To level set the data stores, run a set of wsadmin commands to synchronize the user data between the member tables for the Lotus Connections applications and your corporate directory.

The following steps describe this procedure:

1. Synchronize all of the application member table databases, except News repository, Profiles, and Search, with the corporate directory by running the syncAllMembersByExtId() administrative command for each application.

a. Open a command prompt and then do the following:

Change to the following directory of the system on which you installed the deployment manager:

\profiles\\bin

Attention: 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 a Lotus Connections component will not work properly.

b. Enter the following command to start the wsadmin client:

§ AIX® / Linux:

§ ./wsadmin.sh -lang jython -user -password

  -port

§ Microsoft Windows:

§ wsadmin -lang jython -user -password

  -port

c. where:

§ is the user name of the WebSphere® Application Server administrator.

§ is the password of the WebSphere Application Server administrator.

§ is the SOAP port for the WebSphere Application Server. The default value of the SOAP port is 8879. If you are using the default port value, you do not need to specify this parameter. If you are not using the default and you do not know the port number, you can look up its value in the WebSphere Application Server Integrated Solution Console. To look up the SOAP port number, do one of the following:

i. Open the WebSphere Application Server Integrated Solution Console for the deployment manager, and then select System Administration > Deployment Manager.

ii. In the Additional properties section expand Ports, and then look for the SOAP_CONNECTOR_ADDRESS port entry to find the port number.

For example:

§ AIX / Linux:

./wsadmin.sh -lang jython -username jsmith -password myp@assword -port 8879

§ Microsoft Windows:

wsadmin -lang jython -username jsmith -password myp@assword -port 8879

d. Use following command to access the application configuration files:

execfile("")

where is one of the following:

§ Activities: activitiesAdmin.py

§ Blogs: blogsAdmin.py

§ Bookmarks: dogearAdmin.py

§ Communities: communitiesAdmin.py

§ Files: filesAdmin.py

§ Forums: forumsAdmin.py

§ Home Page: homepageAdmin.py

§ Wikis: wikisAdmin.py

The News repository, Profiles, and Search do not need to be synchronized at this time.

e. Enter the following command to synchronize user data:

MemberService.syncAllMembersByExtId({"updateOnEmailLoginMatch":"false"})

For example:

CommunitiesMemberService.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 database 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 is not found in the directory, then the code uses the email address and login names contained in the application database tables to continue to search for the user in the corporate directory. When a login name or email address for this user is found in the corporate directory, the command does not update the application database automatically. Instead, it writes a log entry to the UIcSyncCmd.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 database. 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]

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:

o 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:

MemberService.syncMemberByExtId(externalId)

where externalId is the external ID specified for that user in the log. For example:

CommunitiesMemberService.syncMemberByExtId("25374cc6-82a511df-80b6c81b-5330ca0eZZZ")

o Note: The following commands are not implemented in the Beta 2 build. Therefore, you cannot perform this task in the Beta 2 timeframe.

If you determine that the user identified in the log file 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 corporate directory:

MemberService.inactivateMemberbyEmail(email)

where email is the email address of the user specified in the log. For example:

ForumsMemberService.inactivateMemberByEmail("jsmith@example.com")

MemberService.inactivateMemberbyExtId(externalId)

where externalId is the unique ID representing the user as specified in the log. For example:

ForumsMemberService.inactivateMemberByExtId("25374cc6-82a511df-80b6c81b-5330ca0eZZZ")

2. Repeat the previous steps for each application to synchronize each application's member table against the corporate directory.

3. Make sure the Profiles member database table is synchronized with the corporate directory by looking at the USER_STATE_LAIDX table in the PEOPLEDB database. Make sure it is populated and that each member has a user status of 0, indicating that they are active. If this is not the case, run the following command to update the Profiles member database tables:

ProfilesService.rebuildLookAsideIndexes()

Note: 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("true") commands for each installed application. The frequency with which you need to run these commands is dependent 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("true") command needs to be run in an interval shorter than the dormancy time for email and login reuse. See Managing user for more information.