Creating an LTPA Token – Without WAS Network Deployment Server

Recently I was installing an HCL Sametime 11 environment from scratch. I always tend to implement a single LTPA Token across the Domino, Sametime and/or Connections environment. It is also a very good idea to use only the LTPA Token version 2, as it is more secure, but this also means that the LTPA Token has to be created by a WebSphere server.

Usually this is not a problem, because most of my customers have HCL Connections or an older version of Sametime already deployed, which means that they are also using WebSphere Application Server Network Deployment.

But this customer only had Domino, and a new installation of the WAS Network Deployment Server, solely to create a new LTPA Token and scrap it afterwards would take me too much time.

My friend Herwig W. Schauer gave me tip that the same could be done with WebSphere Liberty server, which is a lot faster.

Just download the latest version of WebSphere Application Liberty Server, which is free, from the IBM Website, I used the ZIP Install Package for Windows OS.

Just extract the downloaded package to the directory of your choice and open the “server.xml” file, which can be found under “<was_liberty_package>\wlp\usr\servers\defaultServer”, in text editor. At the line number 17, inside the “<ltpa>” tag, edit the “keyFileName” and “keysPassword” parameter, as shown in the screenshot below:

Afterwards, just start the WAS Liberty by executing the “server.bat” script.

<was_liberty_package>\wlp\bin>server.bat start

Just as in the screenshot below:

As soon as you get the server fired up, a new LTPA token will be generated in “<was_liberty_package>\wlp\usr\servers\defaultServer” directory, with the name and password you specified in the “server.xml” file.

That’s it, you can take the newly generated LTPA token and import it to Domino.

Advertisement

We Have Lost The “wasadmin” Account Password!

If you have lost the “wasadmin” account password or any other local WebSphere account, there is a rather simple way to recover it.

Just connect to the server where WebSphere Deployment Manager is running, via RDP or SSH, depending on the OS of the server, and open the “security.xml” file located under “<WebSphere_Installation_Directory>/AppServer/profiles/<Deployment_Manager_Profile>/config/cells/<Cell_Name>” for example “/opt/IBM/WebSphere/AppServer/profiles/ic-dmgr01/config/cells/ic-cell01”.

After that just search for the account name, for which you would like get the password, in the same line you should find the attribute “password”:

Then just copy the value of the “password” attribute, now we need to decode the xor encoded password. For that I am usually using the following Website: https://strelitzia.net/wasXORdecoder/wasXORdecoder.html

Just paste the encoded text and click the “decode” button, after that you should have the password.

DB2 HADR Configuration for STSC Database

At this point you should already have a Sametime System Console and two DB2 Servers installed. One of the DB2 Servers will be used as a DB2 Primary Instance and the other one as the Secondary. I strongly encourage you to read the official IBM documentation before implementing the following configuration.

In the environment where I have done this I had the following components installed:

  • IBM DB2 10.1 (without any Fix Packs)
  • WebSphere Network Deployment 8.5.5.0
  • Sametime System Console 9 Hot Fix 1
  • Sametime Community Server 9 Hot Fix 1

I also used the IBM Data Studio. You can install the newest version on your client, just make sure that you connect to the “STSC” database as a user which has the instance owner role.

The steps to configure HADR for STSC database are as following:

  1. Stop Sametime System Console.
  2. Back up all Databases which are running on your DB2 Server including STSC Database.
  3. You should also have a backup of the whole server where DB2 is running or a configuration backup.
  4. Log in as “db2admin” or another User which has the instance owner role.
  5. The first thing which we need to do is to configure logging due to the fact that DB2 HADR relies on it to keep the secondary database in sync with primary.

  1. Manually create a folder in the file system where you would like to store the logging data.

  1. Select “Archive” and then browse to the location of the folder you created.

  1. You can keep the default values.

  1. I have kept the default value for the destination of active logs.

  1. The wizard creates a DB backup before applying the configuration changes, here you can select where you want to store the Backup.

Note: You can copy all commands and create a script of them to run it in another environment.

Commands:

CONNECT TO STSC;

QUIESCE DATABASE IMMEDIATE FORCE CONNECTIONS;

UNQUIESCE DATABASE;

CONNECT RESET;

CONNECT TO STSC;

UPDATE DATABASE CONFIGURATION USING logarchmeth1 “DISK:C:\db2archlog_stsc” newlogpath “C:\STSC\DB2\NODE0000\SQL00002\LOGSTREAM0000” logprimary 13 logsecond 12 logfilsiz 1024 LOGINDEXBUILD OFF ;

CONNECT RESET;

DEACTIVATE DATABASE STSC;

BACKUP DATABASE STSC TO “C:\STSC\Backup” EXCLUDE LOGS WITHOUT PROMPTING;

  1. At the end select “Run”.

After the process is finished you may get a warning which states that you need to deactivate and activate the database in order for changes to take effect.

You can do this by issuing the following commands in DB2 CMD.

  1. Configure HADR

Now we can actually configure HADR.

  1. Connect to the STSC database.

We can now use “Online Backup” because we have configured archive logging, that is why it is quite handy to have archive logging configured even if you don´t want to configure HADR.

After going any further you should check the port numbers which are used by other databases. You need to make sure that you do not define ports for the new STSC database HADR configuration which are already used by other HADR configurations on the DB2 instance.

  1. Open db2 admin cmd.
  2. Connect to the specific database by issuing “db2 connect to <database_name>”.
  3. Then enter the “db2 get db cfg” command.

Note: Make sure you do not use the same ports as defined in the output.

Note: Mostly I use “Synchronous” HADR synchronization mode due to the fact that all my servers are in the same LAN. Depending on your network configuration you can choose which one works best for you.

  1. In the “Client Reroute Options” enter the Hostname of the secondary server as well as the port number on which the secondary database should be accessible by the Sametime System Console in a case of a failover.

2. Create a connection to the standby instance.

3. Create a new Connections Profile to the standby server and select the most recent backup of the STSC database.

4. Select a directory on the standby system where the backup file will be copied. If the specific folder does not exist, create it manually, otherwise you will get an error. J

5. Select a port for the HADR service on the standby system.

6. You will need to specify the “Client Reroute Options” again, this time you will need the to specify the primary server.

7. After you are happy with the configuration, click run.

Note: you can ignore the following warnings.

These Commands were shown in the Data Studio as a result from our configuration:

RESTORE DATABASE STSC FROM “C:\STSC\Backup” TAKEN AT 20150827095005 INTO STSC REPLACE HISTORY FILE WITHOUT PROMPTING;

–Primary Database Configuration Commands;

— Configure database for client reroute – <Primary_Host>(DB2) – STSC;

UPDATE ALTERNATE SERVER FOR DATABASE STSC USING HOSTNAME <Secondary_Host> PORT 50000;

— Update HADR configuration parameters on database – <Primary_Host>(DB2) – STSC;

UPDATE DB CFG FOR STSC USING HADR_LOCAL_HOST <Primary_Host>;

UPDATE DB CFG FOR STSC USING HADR_LOCAL_SVC 56001;

UPDATE DB CFG FOR STSC USING HADR_REMOTE_HOST <Secondary_Host>;

UPDATE DB CFG FOR STSC USING HADR_REMOTE_SVC 56002;

UPDATE DB CFG FOR STSC USING HADR_REMOTE_INST DB2;

UPDATE DB CFG FOR STSC USING HADR_TIMEOUT 120;

UPDATE DB CFG FOR STSC USING HADR_TARGET_LIST <Secondary_Host>:56002;

UPDATE DB CFG FOR STSC USING HADR_SYNCMODE SYNC;

UPDATE DB CFG FOR STSC USING HADR_PEER_WINDOW 0;

UPDATE DB CFG FOR STSC USING HADR_SPOOL_LIMIT 0;

UPDATE DB CFG FOR STSC USING HADR_REPLAY_DELAY 0;

UPDATE DB CFG FOR STSC USING BLOCKNONLOGGED NO;

STOP HADR ON DATABASE STSC;

–Standby Database Configuration Commands for <Secondary_Host>-DB2;

— Configure database for client reroute – <Secondary_Host>(DB2) – STSC;

UPDATE ALTERNATE SERVER FOR DATABASE STSC USING HOSTNAME <Primary_Host> PORT 50000;

— Update HADR configuration parameters on database – <Secondary_Host>(DB2) – STSC;

UPDATE DB CFG FOR STSC USING HADR_LOCAL_HOST <Secondary_Host>;

UPDATE DB CFG FOR STSC USING HADR_LOCAL_SVC 56002;

UPDATE DB CFG FOR STSC USING HADR_REMOTE_HOST <Primary_Host>;

UPDATE DB CFG FOR STSC USING HADR_REMOTE_SVC 56001;

UPDATE DB CFG FOR STSC USING HADR_REMOTE_INST DB2;

UPDATE DB CFG FOR STSC USING HADR_TIMEOUT 120;

UPDATE DB CFG FOR STSC USING HADR_TARGET_LIST <Primary_Host>:56001;

UPDATE DB CFG FOR STSC USING HADR_SYNCMODE SYNC;

UPDATE DB CFG FOR STSC USING HADR_PEER_WINDOW 0;

UPDATE DB CFG FOR STSC USING HADR_SPOOL_LIMIT 0;

UPDATE DB CFG FOR STSC USING HADR_REPLAY_DELAY 0;

UPDATE DB CFG FOR STSC USING BLOCKNONLOGGED NO;

— Start HADR on standby database – <Secondary_Host>(DB2) – STSC;

DEACTIVATE DATABASE STSC;

START HADR ON DATABASE STSC AS STANDBY;

— Start HADR on primary database – <Primary_Host>(DB2) – STSC;

START HADR ON DATABASE STSC AS PRIMARY;

7. Post Configuration and Verification

Verify that the HADR is working.

Primary server:

Standby server:

Check if you can connect to the database.

You can restart the system just to make sure that everything is ok after the restart.

Primary:

Stand by:

Primary:

Standby:

8. Test a Failover

Standby:

Primary:

9. WebSphere & SSC Configuration

Alternate Server Name: <Secondary_Host>

Alternate Port Name: 50000

Do this for every DB2 Datasource/Database configured as HADR.

Restart the Application Server. à In our Case, the SSC.

  1. Check and verify

Start the application, SSC.

Primary:

Our Application Server has the IP of 192.168.13.29

Failover to Standby and check if the Application can connect to the Standby Server.

If you get an error message, which refers to db2 database, in SSC just refresh or click on the same menu once again.

Some useful information regarding DB2 HADR: https://www.ibm.com/developerworks/community/wikis/home?lang=en#!/wiki/DB2HADR/page/HADR+commands

We have our DB2 Servers running in the Configuration described above for quite some time and we didn’t have any issues with it.

IBM Connections 5 to 5.5 In-Place Migration

I have done this, so far, only in my Test Environment, and there may be some additional steps you will have to do in your Production environment to make everything work correctly. So I strongly advise you to go through the official IBM Documentation regarding the Migration before you start the Process in your production environment.

In my test environment all Applications, including DB2 Server, run on one Windows 2008 R2 Machine. My starting point was the following:

  • IBM Installation Manager 1.8.3
  • IBM DB2 10.1
  • IBM WebSphere 8.5.5 FP4
  • IBM Connections 5.0 CR3
  • TDI 7.1.1.3

From there I want to go to:

  • IBM Installation Manager 1.8.4
  • IBM DB2 10.5
  • IBM WebSphere 8.5.5 FP6
  • IBM Connections 5.5 (Including IC 5.5 Day1 iFix)
  • TDI 7.1.1.3

I already had TDI 7.1.1.3 running, so there was no need to update the TDI, at least from the System Requirements point of view.

Download Time

For the upgrade I needed the following packages:

IBM Installation Manager 1.8.4

WebSphere Application Server Full Profile 8.5.5 FP6

8.5.5-WS-WAS-FP0000006-part1.zip & 8.5.5-WS-WAS-FP0000006-part2.zip

WebSphere Application Server Supplements 8.5.5 FP6

8.5.5-WS-WASSupplements-FP0000006-part1.zip & 8.5.5-WS-WASSupplements-FP0000006-part2.zip

WebSphere Customization Toolbox 8.5.5 FP6

8.5.5-WS-WCT-FP0000006-part1.zip & 8.5.5-WS-WCT-FP0000006-part2.zip

DB2 10.5

CIW3YML: IBM DB2 Server V10.5 for Windows on AMD64 and Intel EM64T systems x64) Multilingual

IBM Connections 5.5

CN808ML: IBM Connections V5.5 for Windows Multilingual
CN80DML: IBM Connections V5.5 Wizard for Windows Multilingual

Update the Installation Manager to the 1.8.4 Version

Create a backup of the whole environment before proceeding with the Upgrade.

  1. Extract the Installation Files.
  2. Run the “Install.exe” as Administrator
  3. Accept the license Agreement and Continue until the software is updated.

The Process is straightforward, there are no options which need to be changed.

DB2 update to 10.5

On this DB2 Server I only have Connections Databases running, in a more complex environment I suggest going through the IBM Documentation regarding DB2 Update.

During the Update, if possible, always use the “db2admin” User or similar User created when the DB2 Server was first installed.

Verify that your databases are ready for Upgrade

https://www-01.ibm.com/support/knowledgecenter/SSEPGG_10.5.0/com.ibm.db2.luw.qb.upgrade.doc/doc/t0007187.html?lang=en

Note: DB2 Server needs to be running.

  1. Start the db2 command line.
  2. Run the following command for all your databases

“db2ckupgrade sample -l db2ckupgrade.log -u adminuser -p password”



Make sure that all databases can be upgraded.

Update the DB2 Instance

  1. Stop all Applications involved.
  2. Log in as a instance Owner
  3. Backup all databases
  4. Start the DB2 Command Line Processor as Admin.
  5. Deactivate all databases:
    1. Check if there are any active databases left with “db2 list active databases”.
    2. Deactivate with “db2 deactivate database <database_alias>”
  6. Stop the db2 Server
    1. “db2stop” command
  7. Extract the Installation Files
  8. Start the “setup.exe” as administrator.
  9. Select “Install a Product” and “Work with Existing”, you need to choose the right version. We are using DB2 Workgroup Server edition.


11. Select the DB2 Copy.


12. Ignore the warning, and click “OK”.

13. After that an another DB2 Setup Wizard should start.


14. Click Next

15. Accept the license agreement

16. Choose the Installation Type.

17. In most cases it will be typical.

  • Use “Custom” if you are using some of the advanced Features that are not found under “typical” installation type.

18. Click “Next”



19. Enter the Administration Account and Password, instance Owner.


20. Check the settings and click “OK”.


21. Review the settings and click “OK”.

22. Finish the setup.


23. Restart the Windows Server.
24. Download and extract the db2 license files.
25. Start the DB2 Console.
26. Enter “db2licm -l”


At this point the DB2 Server  is not registered.

27. Navigate to the correct license file.

28. Enter “db2licm –a <license_file>”.


29. Check if the Product is now licensed with “db2licm -l”.


30. Start the DB2 Server.

At this point I ran into an error where “gsk8iccs_64.dll” was missing:

Error Code in DB2 Log File:

2015-12-21-14.54.09.139000+060 I4156F1113           LEVEL: Error

PID     : 2628                 TID : 2696           PROC : db2syscs.exe

INSTANCE: DB2                  NODE : 000

HOSTNAME: SRV079

EDUID   : 2696                 EDUNAME: db2sysc 0

FUNCTION: DB2 Common, Cryptography, cryptDynamicLoadGSKitCrypto, probe:998

MESSAGE : ECF=0x90000076=-1879048074=ECF_LIB_CANNOT_LOAD

Cannot load the specified library

DATA #1 : unsigned integer, 4 bytes

70

DATA #2 : String, 39 bytes

C:\IBM\SQLLIB\bin\icc64\gsk8iccs_64.dll

CALLSTCK:

[0] 0x000007FEFA24614D pdOSSeLoggingCallback + 0xFD

[1] 0x000007FEF99A2B7A ossLog + 0x15A

[2] 0x000007FEF99A2A79 ossLog + 0x59

[3] 0x000007FEEF5B5985 cryptDynamicLoadGSKitCrypto + 0x745

[4] 0x000007FEEF5B49F0 cryptContextRealInit + 0x140

[5] 0x000007FEEF5B4625 cryptContextInit + 0x115

[6] 0x000007FEEE4C456E sqloRunInstance + 0x1CE

[7] 0x000000013F6027EB 0x000000013F6027EB + 0x0

[8] 0x000000013F6019A4 0x000000013F6019A4 + 0x0

[9] 0x00000000778B5A4D BaseThreadInitThunk + 0xD

[10] 0x0000000077C0B831 RtlUserThreadStart + 0x21

The solution for this was to install IBM Data Server Client

  1. Start the DB2 “setup.exe” as Administrator.
  2. Select the following option:


3. Choose the Typical installation and click next until you have reached the end of the wizard.

4. After that, the db2 Instance should start automatically.

Upgrade DB2 Databases

https://www-01.ibm.com/support/knowledgecenter/SSEPGG_10.5.0/com.ibm.db2.luw.qb.upgrade.doc/doc/t0007193.html?lang=en

  1. Issue the “db2 list database directory” command to list all catalogued databases.
  2. Issue the following Command for every database:

db2 UPGRADE DATABASE <database alias> USER username USING password


Update the Schema of DB2 Databases to IBM Connections 5.5 Version

http://www-01.ibm.com/support/knowledgecenter/SSYGQH_5.5.0/admin/migrate/t_update_databases-wizard.html?lang=en

Download the latest Version of Connections Wizards.

http://www-01.ibm.com/support/docview.wss?uid=swg21972646

  1. Stop Connections and all other Applications using the DB2 Databases.
  2. Backup the Databases
  3. Log on as Administrator, DB2 Instance owner, SYSAdmin Authority.
  4. Open the DB2 Administrator Command Window


5. Change the Location and enter the following command “dbWizard.bat”.

6. After that a “Database Wizard” should pop up. Click “Next”.


7. Select “update” database Task and click next.


  • Check the details about the DB2 Instance and click “Next”.

8.Select the databases you want to update and click “Next”.

9. Review the summary and then click “update”.

10.Click “Execute”.

11.This can take a while, make sure there are no errors when the wizard is finished updating all databases.

Create the Push Notifications Database

  1. Stop Connections and all other Applications using the DB2 Databases.
  2. Log on as Administrator, DB2 Instance owner, SYSAdmin Authority.
  3. Open the DB2 Administrator Command Window

4.Change the Location and enter the following command “dbWizard.bat”.

5. After that a “Database Wizard” should pop up. Click “Next”.

6.Select “Create” Database Task.

7. Select “Push Notification” Database, at this point all other possibilities should be greyed out.

8.Select “Create” and then “Execute”.

9.Make sure there are no errors.

Uninstall the previous Version of Connections

http://www-01.ibm.com/support/knowledgecenter/SSYGQH_5.5.0/admin/migrate/t_uninstall_pre-migration.dita?lang=en

  1. Backup your whole Connections Environment before proceeding.
  2. Start your Deployment Manager.
  3. Stop all other Instance of WAS, including Node Agents.
  4. Start IBM Installation Manager

  1. Select “Uninstall”.

5. Select the “IBM Connections” Installation Package and then click “Next”.

6. Enter the Administrator password, click “Validate” and then proceed after the validation was successful.

7. On the next Screen select “Uninstall”.

8. Grab some café and take a break, this could take some time… In my Environment (4 CPUs, 12 GB of RAM) the Uninstallation Process took about 50 Minutes.

9. Restart the Deployment Manager and Start all Nodes.

10. Synchronize the nodes.

11. Delete/rename/move the following files:

  • Connections Installation Files
    • Make sure you do not delete the local and shared Content Store before migrating them and other files like “TDISOL” directory if it is located here, move these files if they are located in Connections Installation Root Folder.
    • All of the Contents in Connections Root Folder.
    • Example: “C:\IBM\Connections”.
  • IBM Connections Configuration files
    • This directory is usually removed by the installation process, but make sure it is deleted before proceeding.
    • Whole “LotusConnections-config” Directory, “DMGR_Profile\config\cells\cell_name\LotusConnections-config”.
    • Example: “C:\IBM\WebSphere\AppServer\profiles\ic-mgr01-d\config\cells\ic-cell-d\ LotusConnections-config”
  • Registry.xml File, if it is not removed already by the uninstallation process.
  • All “.py”, Python type files from the “Bin” Directory of Deployment Manager
    • C:\IBM\WebSphere\AppServer\profiles\DMGR\bin

Preparing for IBM Connections 5.5 Installation

Install WebSphere Application Server 8.5.5 FP6

  1. Download the Required Software (WAS Full Profile, WAS Supplements, Customization Toolbox)

    http://www-01.ibm.com/support/docview.wss?uid=swg24040035

  2. Extract and prepare the packages (some Installation Packages come in a few parts which need to be put together in one Folder), most of the time you will only need to copy the folder “native” from the second part into the first part.

3. Stop all instances of WAS Server.

4. Start the Installation Manager as Administrator.

5. Add the repositories needed.

6. Install the IBM WebSphere Application Server Update.

7. Click Update

8. Select “IBM WebSphere Application Server V8.5”

9. Accept the Defaults and Update.

10.  Using the same process update the Customization Toolbox.

11. Using the same process  update the IBM HTTP Server.

12. Using the same process update the “Web Server Plug-ins for IBM WebSphere Application Server V8.5”.

Install Connections 5.5

http://www-01.ibm.com/support/knowledgecenter/SSYGQH_5.5.0/admin/install/t_install_cluster-N.dita?lang=en

  1. Start the WAS Deployment Manager.
  2. Import start the Installation Manager as Administrator.
  3. Add Connections repository to the Installation Manager.

4. Start the Installation process.

5. Change the Installation Directory, take something other than “Program Files(x86)”.

6. Select the Features you want to be installed.

7. Fill in WAS Configuration Information.

8. Choose the Deployment Type you wish to use.

9. Insert the Database Server Configuration Information and then Click validate.

10. Select the WebServer and then click “Next”.

11. Choose whether to Configure Cognos now.

12. Select the Content Store

You can reuse the old Content Stores, you do not have to create new ones.

http://www-01.ibm.com/support/knowledgecenter/SSYGQH_5.5.0/admin/migrate/c_content-store_migration.dita?lang=en

13 . Delete Search related data from the Content Stores before you proceed.

http://www-01.ibm.com/support/knowledgecenter/SSYGQH_5.5.0/admin/migrate/t_reuse_content-store.html?lang=en

  • local_content_store/news/search/index
  • local_content_store/profiles/cache
  • local_content_store/search/backup
  • local_content_store/search/index
  • shared_content_store/news/search/indexReplication
  • shared_content_store/search/dictionary
  • shared_content_store/search/stellent/dcs/oiexport/exporter

I am using local repositories because this is a test server (I will also have to copy them later on, because the Installation directory has to be empty before the installation). In a Production Enviroment you should use a Shared Content Store which is stored on a Share, which is preferably Highly Available.

14. Enter Notifications Configuration.

15. In the next step you can Map LDAP Users to Administrative and Global Moderator roles.

16. Review the Configuration and then click install.

17. After the Installation is complete, log in to the ISC and fully synchronize all Nodes.

18. System Administration à Nodes à Full Resynchronize

The initial Synchronization can take more than 30 Minutes.

19. Verify that all Applications are distributed, by opening SystemOut.log of the node agents.

Note: “ADMA7021I: Distribution of application <application> completed successfully” Indicates that the Distribution is completed.

  1. Restart the Deployment Manager and Node Agents.
  2. Copy the Content Store if you didn´t do it before.

http://www-01.ibm.com/support/knowledgecenter/SSYGQH_5.5.0/admin/migrate/t_copy_content-store.html?lang=en

3. Look into the article above for the data you need to copy from the content store.

Note: You should copy the customization directory after you have tested and made sure that the deployment works without them.

4. Delete the old Log files and Caches dmgr + nodeagent

  • Log path
  • Temp path
  • Ws temp path

5. Start all Clusters

6. Generate and Propagate the Plug-In on HTTP Server.

Update the Connections Port and URL settings (optional)

  1. Stop all Connections Clusters and the Node Agent.
  2. Run CMD as Administrator
  3. Navigate to the “bin” directory of the DMGR.
    1. Example: “C:\IBM\WebSphere\AppServer\profiles\DMGR\bin”
  4. Check out the Connections configuration

You can do that with the following commands:

  • wsadmin -lang jython -username wasadmin -password passw0rd
  • execfile(“connectionsConfig.py”)
  • LCConfigService.checkOutConfig(“<Check out Destination>”,”<cell name>”)

You can display the cell name with the following command:

  • print AdminControl.getCell()

5. Navigate to the folder where you have checked out the configuration files previously.

6. Open the “LotusConnections-config.xml” file and modify the URL and Port for each Application.

In My case I just want to change the URL.

There are many ways how to accomplish this, I prefer using Notepad ++ or UltraEdit.

https://milanmatejic.wordpress.com/2015/08/19/deleting-port-numbers-from-lotusconnections-config-xml-file/

7.After you are done editing, save the file and check it in again.

  • With the following command: “LCConfigService.checkInConfig()”

8. After that synchronize all nodes.

Note: You can do this while you are in the same cmd Window with the following command.

“synchAllNodes()”

9. Restart all Connections Clusters.

Clear all Scheduled Tasks

http://www-01.ibm.com/support/knowledgecenter/SSYGQH_4.5.0/admin/admin/t_admin_common_clear_scheduler_after_ltpa_change.html?lang=en

  1. Start all Connections Clusters and the Node Agent.
  2. Run CMD as Administrator
  3. Navigate to the “bin” directory of the DMGR.
  4. Enter the following commands:
  • wsadmin -lang jython -username wasadmin -password passw0rd”
  • execfile(“connectionsConfig.py”)
  • Scheduler.listAllTasks() à This should return a rather longer list.
  • Scheduler.clearAllTasks()
  • Scheduler.listAllTasks() à The list should be now empty.

5. Restart the Connections Clusters to force the Scheduled tasks to be recreated.

Install the day1 iFix

http://www-01.ibm.com/support/knowledgecenter/SSYGQH_5.5.0/admin/migrate/t_install_interim-fix.dita?lang=en

Download: http://www-01.ibm.com/support/docview.wss?uid=swg21972646

You will need to download the new iFix and the update Installer as well.

  1. Stop all Connections Application Clusters.
  2. Make sure that “WAS_HOME” variable is set.
    1. You can do this by runing “setupCmdLine.bat” which is located in the “bin” directory of Deployment Manager.
  3. Copy the newly downloaded Update Installer into the Connections Root directory.
  4. Run “updateWizard.bat”, as Administrator, from the “UpdateInstaller” directory.

Note: You have to run both commands in the same “cmd”.

5. Select the directory of downloaded iFix in the Update Wizard which should have popped-up until now.

6. Select the iFix and click “Next”.

7. Enter the WAS Administrator User ID and continue.

8. Finish the installation process.

Installation took about 30 Minutes in our Environment.

9. Stop the DMGR.

10. Remove the temporary Directories of DMGR and Node Agent.

11. Start the DMGR including Node Agents.

12. Resynchronize all Nodes.

13. Start all Connections Clusters.

 

Java Export Policies Change

After trying to log in into Connections I saw the following errors in the Log file:

[12/23/15 15:20:21:251 CET] 000000f8 HttpMethodDir I org.apache.commons.httpclient.HttpMethodDirector executeWithRetry I/O exception (javax.net.ssl.SSLKeyException) caught when processing request: RSA premaster secret error

[12/23/15 15:20:21:251 CET] 000000f8 HttpMethodDir I org.apache.commons.httpclient.HttpMethodDirector executeWithRetry Retrying request

This meant that I simply needed to change the Java Export policies.

You can download the files needed from:

https://www-01.ibm.com/marketing/iwm/iwm/web/reg/pick.do?source=jcesdk&lang=en_US.

You can check the version with the “java –version” command. You should do that in order to determine which version of java policy files you need.

java -version

In this case I would download and use “Files for older versions of the SDK”, from the URL mentioned above.

IBM Unrestricted SDK JCE policy files

You can just overwrite the original files located under:

  • c:\IBM\HTTPServer\java\jre\lib\security
  • c:\IBM\WebSphere\AppServer\java\jre\lib\security

 

SSO Check

  1. Open ISC.
  2. Navigate to “Securityà Global Security à Single sign-on (SSO)”.

3. Check if the Domain name is right.

I had an issue that the Domain Name had changed after the installation. If that is the case you will only be able to log-in to Profiles Application.

Errors in System.out log connected to this problem:

000001f2 DSXSearchEngi E com.ibm.connections.directory.services.engine.DSXSearchEngine search CLFRK0004E: Directory Service Extension(DSX) received a HTTP response from URL ‘https://social-d.bat-groupware.at/profiles/dsx/instance.do?login=WBTSTT&#8217; expected XML, received unexpected content-type ‘text/html;charset=UTF-8’!

[12/28/15 13:39:07:056 CET] 000001f2 DSXSearchEngi E com.ibm.connections.directory.services.engine.DSXSearchEngine search X-LConn-Auth=false

[12/28/15 13:39:07:056 CET] 000001f2 DSXSearchEngi E com.ibm.connections.directory.services.engine.DSXSearchEngine search /profiles/login returned:

AbstractHomep E CLFRQ0415E: An error occurred while executing the action. See nested exception for more details.

com.ibm.lconn.homepage.web.WebException: CLFRQ0341E: Could not retrieve details for the user with login ID: WBTSTT due to an exception. The exception occurred when retrieving the details via Profiles Directory Service Extension: [Ljava.lang.Object;@f6273db5

[12/28/15 12:55:51:113 CET] 0000017e AbstractDirec W EJPVJ9246E: Unable to query the directory service by field j2eePrincipal for WBTSTT. [UserImpl@f5ff182c id=00000000-0000-0000-0000-000000000000 directoryId=00000000-0000-0000-0000-000000000000]

At this point you should be able to login into Connections. J

Configure the new TDI Wizard for IBM Connections 5.5

  1. Run “IBM_Connections_5.5_Wiz_win.exe” to extract the new TDI Wizard.
  2. Copy the newly extracted files on the Machine where TDI is installed, preferably in the “IBM” Software installation folder.
  3. Run the “populationWizard.bat” as Administrator.
  4. Select the Location of TDI Installation Directory.

5. Choose the correct database type.

6. Enter the Connection details of the DB2 Database, then click next.

Note: From this point on you may need an LDAP Search Browser.

7. Enter the LDAP server connection details.

8. Enter the LDAP authentication properties.

9.Enter the LDAP User search base and the LDAP search filter

Note: You can copy the settings from the old TDI Wizard, they are all saved in “profiles_tdi.properties” file, which is located in the directory of the old TDI wizard.

  • You will need the value of “source_ldap_search_base” and “source_ldap_search_filter” attributes for this step, just search for them in the file mentioned above.

10. On the next screen you can configure the Profiles database mappings.

  • Here you can use the “map_dbrepos_from_source.properties” file, in the old TDI Wizard directory, as reference.

11. Select the Optional database tasks if you need them and then click “Next”.

12. Review the Settings and then click “Configure”.

13. Make sure there are no errors after the Wizard finishes.

14. Now you can create a scheduled task, which will make sure the TDI Wizard runs at defined Interval, or simple change the existing one by editing the location of “sync_all_dns.bat” file, pointing to the file in the new Wizard directory.

Post Migration Tasks

http://www-01.ibm.com/support/knowledgecenter/SSYGQH_5.5.0/admin/migrate/t_post-migration_tasks.dita?lang=en

  • Didn´t had to recreate the search index, because I deleted it from the content store and local data before installing the Search application. You can check if the Search index is recreated by navigating to local Search index directory: “connections_root\data\local\search\index”. There a current “INDEX.READY” and “CRAWLING_VERSION.” Files should exist.

If that is the case, than most likely the Search is functioning correctly.

You can verify that the Search works correctly by using the following URLs (you need to use an Administrative Account):

https://<connections server URL>/search/serverStatus

https:// <connections server URL>/search/serverStats

Synchronize files that are shared with Communities

  1. Initialize the “wsadmin” command prompt.
  2. Enter “execfile(“filesAdmin.py”)”
  3. After that enter “FilesDataIntegrityService.syncAllCommunityShares()“.

After the task is completed you will see the following line in the Log File:

000001b1 SyncCommunity I EJPVJ9366I: The task Synchronize all Community shares has finished at December 28, 2015 2:55:38 PM CET.

This should be it, now you should be able to log in into Connections and the peopleDB will synchronize with your LDAP directory.

Different WAS node Versions in a single cell

In the course of Connections CR Updates I also tend to update all WebSphere Components to the latest supported version. Currently for Connections 5 CR2 & CR3 the latest supported Application Server is WebSphere 8.5.5.4.

Quite recently we needed to update a Connections environment from 5 CR1 to 5 CR2. This Environment consists of four nodes, on two of them we have Connections applications running in a cluster, the other two are used for IBM Docs applications, also clustered. One of the nodes where Connections Software is running is also a Deployment Manager.

The initial plan was to update WebSphere Nodes, to 8.5.5.4, only on which Connections is running. We wanted to update remaining nodes later on, in the course of IBM Docs Update. This was a very bad idea, after the Update, the two IBM Docs nodes, running the older version of WebSphere, started getting out of sync, causing Docs applications to stop working.

Manual Synchronization, using “syncNode.bat” file, seemed to resolve the problem for a short period, but only after we updated the IBM Docs Nodes to the 8.5.5.4 version we managed to solve the synchronization issue.

So beware of running different node versions of WAS in a single cell.