Changing subdomain in Connections,CCM and Docs

I’ve just completed a process where a customer needed to change their subdomain due to an organisational name change. This site has a pretty large install.  CCM, Docs and also leveraged Windows Desktop SSO via SPNEGO.

The change was connections.OLD.sub.dom.au to connections.NEW.sub.dom.au

There is some documentation out there on how to change host names, but I wanted to compile a list for this specific task. So here you go.


SSL CSR created, new key created and imported into new KDB. Make available on IBM HTTP Server.

DNS change implemented, and points to existing IBM HTTP Server. Keep old record in place as well. Also ensure that the new record is resolvable on all Connections hosts.

Change the SSL Certificate over in IHS. (Change the following)

Keyfile D:\IBM\HTTPServer\NEWkey.kdb
SSLStashFile D:\IBM\HTTPServer\NEWkey.sth

CellDefaultTrustStore as it shared a common root with the previous Certificate.

Connections changes

Change the LotusConnectection-config.xml file. Check out with wsadmin, change the references to OLD and replace with NEW. Check-in. Process here

While in wsadmin, change the Notifications file to reflect new mail domain. Change the Administration user that notifications come from. Check-in. Process here

Change and update Blogs

To update the URL’s inside blogs, there is an AdminTask. while still in wsadmin, execute the following.

BlogsAdminService.fixBrokenUrls(https://connections.old.sub.dom.au, https://connections.new.sub.dom.au)


Change LTPA to reflect new Domain.

In the ISC, select Global Security > Single sign-on

Update the Domain name field to reflect the new sub domain. i.e from .old.sub.com.au to .new.sub.dom.au


Re-sync all nodes, stop and restart the entire environment (DMGR and NODES).

Docs Changes

Docs is pretty straight forward.

The property files for Docs all need to be changed. They are found in: <WAS_HOME>/profiles/<DMGR>/config/cells/{cellname}/IBMDocs-config/

Change all instances of OLD url to NEW in the concord-config.json file, and the viewer-config.json file. Just to be safe, verify no instances of OLD url exist in the other .json files in the directory. If there are, change them.

Re-sync all nodes, stop and restart the entire environment (DMGR and NODES).

CCM Changes

For CCM, we only had to update the Activity stream widget. Follow this process


Update Scheduled tasks

Jump back into wsadmin, and run the following. Following is from the knowledge centre.


Note: If Scheduler.clearAllTasks() does not clear tasks successfully, run clearScheduler.sql manually for each of the applications. 
For example:

db2 -v -td@ -f activities\db2\clearScheduler.sql
db2 -v -td@ -f homepage\db2\clearScheduler.sql 
The SQL scripts are in the following locations:

AIX or Linux: connections_root/connections.sql directory.


Update Search

I planned on updating search, but I didn’t get any errors after the change while using the search. Just to be safe,  I kicked off a new once off index task after the changes were completed.




…..and finally, a bit of a catch all

IBM HTTP Server rewrite – redirect OLD url to NEW

Add the following to handle any URLS that still come in using the old name. Replace your new server names below.

#Added to support redirect from OLD to NEW
<VirtualHost *:80>
    ServerName connections.OLD.sub.dom.au
    RewriteEngine On
    RewriteRule ^/$    /homepage     [PT] 
    RewriteRule ^/(.*) http://connections.NEW.sub.dom.au/$1 [R,L]
RewriteEngine off

<VirtualHost *:443>
    ServerName connections.OLD.sub.dom.au
    RewriteEngine on
    RewriteRule ^/$    https://connections.NEW.sub.dom.au/homepage [PT]      RewriteRule ^/(.*) https://connections.NEW.sub.dom.au/$1 [R,L]    
RewriteEngine off

<VirtualHost *:80>
    ServerName connections.NEW.sub.dom.au
    RewriteEngine On
    RewriteRule ^/$     /homepage     [PT]
RewriteEngine Off

<VirtualHost *:443>
    ServerName connections.NEW.sub.dom.au
    RewriteEngine On
    RewriteRule ^/$     /homepage     [PT]
RewriteEngine Off





RSA Premaster Secret Error in Connections 5

I’m doing an install for a customer at the moment, and it’s a large install. All on RHEL, integrated with Portal, and hosted in SoftLayer. Very Cool. I love playing with this stuff!

So the Connections install was running along great, until it was time to bring up the Connections Apps and test login. The way we usually configure Connections these days is to setup WAS primary administration user to exist in the LDAP directory, and use the default file based admin as a backup. We also then use this same user as the Connections administrator. We ensure that this user also has a profile. This just seems to make the installation (especially of companion products/extensions) easier..

I go to log into Connections the first time with the Admin user.. I get the “Unable to process your request page”. Damn.

Start troubleshooting. Eventually find the stanza that I think is logging for the error. This was in the Homepage Server System.Out. (Large Connections Install)..

 [14/01/16 19:30:20:532 EST] 00000120 HttpMethodDir I org.apache.commons.httpclient.HttpMethodDirector executeWithRetry Retrying request
 [14/01/16 19:30:20:535 EST] 00000120 HttpMethodDir I org.apache.commons.httpclient.HttpMethodDirector executeWithRetry I/O exception (javax.net.ssl.SSLKeyException) caught when processing request: RSA premaster secret error
 [14/01/16 19:30:20:536 EST] 00000120 HttpMethodDir I org.apache.commons.httpclient.HttpMethodDirector executeWithRetry Retrying request
 [14/01/16 19:30:20:539 EST] 00000120 UserInfoInter E com.ibm.lconn.homepage.web.interceptor.UserInfoInterceptor cacheUserInfo CLFRQ0341E: Could not retrieve details for the user with login ID: ConnectionsAdmin@domain.blah.au due to an exception. The exception occurred when retrieving the details via Profiles Directory Service Extension: [Ljava.lang.Object;@5c0f8907

More digging revealed that this error was due to…….the SSL Key.

What was occurring is this. I’d setup the IBM HTTP Server to use the key provided by the customer. I’d imported this into the CellDefaultTrustStore, as required. It was 4096 bits wide, which Java security in the WAS stack had an issue with. Some secret squirrel stuff about the governments wanting to control Encryption or something. So when the Homepage app was hitting the URL for profiles and verifying I am who I say I am, it caused the SSL error.

How did I fix it?

Copy and replace the Java policy files with the unrestricted policy files, then restart the Connections servers.

cd /opt/IBM/WebSphere/AppServer/java/demo/jce/policy-files/unrestricted/
[root@connwas2 unrestricted]# cp *.jar /opt/IBM/WebSphere/AppServer/java/jre/lib/security/
cp: overwrite `/opt/IBM/WebSphere/AppServer/java/jre/lib/security/local_policy.jar'? yes
cp: overwrite `/opt/IBM/WebSphere/AppServer/java/jre/lib/security/US_export_policy.jar'? yes

That’s it. Restart servers and enjoy.

Thanks to Mikkel Heisterberg,  you pointed me in the right direction with this Blog. Cheers!



Quick Tip – Name your console..

The guys I work with are full of good tips.

I’d always wondered how to do this, as I thought it was some sort of Developer jiggery-pokery.

Most environments I work in have a Development environment, and a Production environment.

Quite often, I get lost. Am I in Prod or Dev? Especially with cryptic server names.

Quick way to fix this is to Name your Consoles.

  • Logon to your ISC.
  • Expand System Administration > Task Management
  • Select Console Identity.
  • Type in the Console name..ie Prod
  • And hey presto…You know where you are..

You’re welcome.

Error when reparenting a sub-community.

Reparenting a sub-community is a feature added in Connections 4.5 CR3.

This feature allows you to move a sub-community to a Parent level, but also allows you to move the sub community to a different parent. (Think of the sub community as the child).

To move a sub-community, you use wsadmin, and the CommunitiesService.moveSubcommunityToCommunity(“CommunityUNID”) command.

Here is the IBM Link to the this utility.

I ran into an issue when trying to move the Community.

Firing up wsadmin as our usual Admin user,  I got the below error.


 The System.Out

000009a TangoServiceI W com.ibm.tango.internal.service.TangoServiceImpl getMemberProfileWithUpdates CLFRM0110W: Undetermined memberProfile, in which its name: waslocaladmin, email: null, member uuid: 2f333cc26-b4d5-437d-b970-c9c1b3c076aa, and logins: [waslocaladmin], closely matches to directory service object of an user, whose name: waslocaladmin, email: null, and logins: [waslocaladmin].


000009a TangoServiceI E com.ibm.tango.internal.service.TangoServiceImpl updateCommunity CLFRM0039E: internal error
com.ibm.tango.exception.MemberDuplicateLoginIdException: [waslocaladmin]
at com.ibm.tango.internal.service.TangoServiceImpl.getMemberProfileWithUpdates(TangoServiceImpl.java:3187)

 This was interesting, as the user waslocaladmin user was the Admin user for Connections, but wasn’t listed as an Admin userroles in the Application.

Additionally, waslocaladmin user was in the file based repository.


Switching to our support login, which has Administration access to the Communities application, I was able to run the reparenting command successfully.

This was done by running the wsadmin command as the support user.


Further Troubleshooting revealed that this issue is more than likely the waslocaladmin id not being synced with the Community member database table.

This environment was upgraded, so in theory this could be correct. The migration method was a side-by-side install, so the waslocaladmin user would be different.

Synchronise a single member’s directory ID in the Communities member database table

  1. Open a command prompt and navigate to C:\IBM\WebSphere\AppServer\profiles\Dmgr01\bin
  2. Run wsadmin -lang jython -user waslocaladmin -password password -port 8879

From the wsadmin prompt run:
wsadmin>execfile(“communitiesAdmin.py”) (enter)

Errors have stopped, so fingers crossed!

Updating Connections 5 WAS to

Connections 5 runs on WebSphere Application Server 8.5.x.

We recently deployed on the release, but as part of keeping the WAS stack as up to date as possible, I updated to the recent release We were experiencing an error that is resolved in the update.

Details on this fix are located here

Just to save time, if you are going to do the same, uninstall fix IFP119108, or you’ll get the error below when you go to update using IIM.


Hope this saves time for someone out there.

EDIT…It appears that IBM have decided not to support Connections on this version of WAS.

So if you need to update to resolve an issue in the WAS stack, beware…