Deploy Connections iFixes in a cluster without downtime

Following the documentation of IBM regarding deploying iFixes on a Connections
environment they state that all of your Connections JVM’s should be stopped
during the upgrade process.

“But I have a cluster why can’t this be done online?”,
” Yeah but the IBM documentation says so.”

There you have your challenge. Not much downtime is caused by deploying a single iFix
but there is some chance on data loss. This because running the update installer with online JVM’s will cause an automatic restart of the EAR when they are being upgraded/modified. A restart of an EAR in a clustered environment is most likely to occur simultaneously and can result in HTTP 500 errors for the end user.

Below the steps that work for me to perform an iFix deployment online. It is not a scenario supported by IBM but it can help in improving the process speed of deploying that little iFix that is so desperately needed by a set of end-users. Maybe giving you some ammunition to cut some corners at the CAB meeting.

In this made up example I need to deploy an iFix for Files ( LO66666 ).

Steps:

  • In order to prevent the updateInstaller of Connections from modifying the second node we need to shutdown the nodeagent for this node. Navigate to the WAS console. In the WAS console go to System Administration -> Node agents.
  • Select the node agent of the second node and press stop.
    Tail the SystemOut.log of the nodeagent to check if the nodeagent indeed is stopped.
  • Now logon to the IHS webserver.
  • Open httpd.conf on the webserver. Locate the plugin-cfg.xml line.
  • Open the plugin-cfg.xml, and save a copy of it with another name
    ( i.e. plugin-cfg-primary2ndnode.xml )

 

  • Within this file locate all the ServerCluster sections. For a medium Connections deployment you should find four sections.This example works with a cluster setup consisting of two nodes. One is marked as primary and one is marked as backup. We want to temporarily redirect all traffic primarily to the second node.To do so replace the server line in the BackupServers section with the one of the PrimaryServers section and vice versa.Note the customized CloneID’s. This helps you to verify on which JVM’s you are working. These CloneID’s are mentioned in the JSESSIONID cookie value. Later more about this.
  • Save the changes.
  • Now navigate back to the httpd.conf. Replace the WebSpherePluginConfig with a line pointing to the modified one.

  • Restart the IHS webserver to make this change effective.
  • Now check with a browser that your new Connections session is really being redirect to the correct node. Press F12 and drill down to a cookie information screen
    for one of the requested URL’s. The last part of the JSESSIONID should mention the CloneID’s of the second server.( The screenshot below shows a session to JVM’s on the primary server: infra_srv1 and apps_srv1. )
  • Now go ahead and run the updateInstaller on the DMGR.
    updateSilent.bat -fix -installDir D:\IBM\Connections -fixDir D:\IBM\Connections\updateInstaller\Fixes -install -fixes LO66666 -wasUserId wasadmin -wasPassword ******* -featureCustomizationBackedUp yes
  • Wait for the installer to finish. To make sure the primary node is fully in sync perform
    a full sync from the WAS console interface.
  • Now stop the AppsCluster_server1 ( hosting the Files application ) on the primary node. Now clear all AppsCluster_server1 temp files under
    app_server_root/profiles/AppSrv01/temp/AppsCluster_server1
    and start the AppsCluster_server1 JVM again.
  • Now back to the IHS webserver and switch back to the httpd.conf. Make the original
    plugin-cfg.xml active again and restart the IHS webserver.
    Verify if the traffic routed to the primary server again.
  • Now to also make this change effective for the secondary node start the nodeagent.
    Make sure that all changes are synced if not entirely sure just perform a full sync to
    this server from within the WAS console.
  • Now perform the same procedure as for the primary node. Stop the AppsCluster_server2 JVM, clean all temp files and start the JVM again.
  • And you’re done.

Sametime Community configure HTTP tunneling + push settings

Per default Sametime will listen on port 1533. As some network infrastructures will
not allow outgoing connections on this port, as an alternative you can specify to
use the HTTP port 80. This technique is called HTTP tunneling.

To configure your Domino/Sametime Community setup for this you can
follow the steps in the Blog item.

With your Notes client open the names.nsf on your Sametime Community server. Navigate to Configuration -> Servers -> “All server documents” and double click on the entry of the Sametime Community server

Within this document go to Ports ->Internet Ports -> Web.

ports 1

 

ports 2

 

 

 

 

 

 

 

Change the TPC/IP port number to something different then port 80. We will
go with port 8080.

Save the changes and restart the http task.

In the Domino console use the following commands to do this.

tell http quit

load http

Change the connection for the Sametime Community server in the SSC. Per default the SSC will make contact to the Sametime server through the Domino HTTP port.

As this changes you will need to change this connection setting in the SSC.

Navigate to the Community server.

ssc1

 

 

 

Click edit “Connection Properties”

ssc2

Change the HTTP port to the value you now configured as the HTTP port for Domino.
In our situation this is port 8080. Press Save.

ssc3

 

 

 

Now click on the “Deployment Identifier” link.

The configuration page of the Community server should open without any errors.

ssc4

 

 

 

 

Scroll down to the “HTTP Tunneled Client Connections” section on the Connectivity tab.

ssc5

 

 

 

 

 

Set the port to 80. Now press OK at the bottom of the page to save the changes.

Now switch back to the Domino console and restart the Sametime Community server.

res server

Now with “managed-settings.xml” and “managed-community-configs.xml” you can
push these setting to the clients. Pushing settings to Sametime clients with these files
is the preferred way to go. Working with Domino policies is far from predictable.

Follow these steps to configure the location from where to provide these two XML files.

Within the SSC menu on the left side go to “Manage policies”

policy1

 

 

 

 

policy 2
Click Edit for the “Sametime Instant Messaging Default Policy”.

policy 3

 

 

 

Find the “Sametime update site URL (IC):” entry.

We use the FQDN of the Sametime Community server + the update directory.

policy 4

 

 

On filesystem level on the Community server you should create this update
directory under /local/notesdata/domino/html/

When done press OK at the bottom of the page.

For initially setting the correct port you can configure the following settings in the
managed-settings.xml file.

<?xml version=”1.0″ encoding=”UTF-8″?>
<ManagedSettings>

>>SNIP<<

 

<settingGroup name=”com.ibm.collaboration.realtime.community”>
<setting name=”loginByToken” value=”true” isLocked=”false” overwriteUnlocked=”true”/>
<setting name=”loginAtStartup” value=”true” isLocked=”false” overwriteUnlocked=”true”/>
<setting name=”useCanonicalNamesOverride” value=”1″ isLocked=”false” overwriteUnlocked=”true”/>
<setting name=”name” value=”sametime.acmecorp.org” isLocked=”false” overwriteUnlocked=”true”/>
<setting name=”host” value=”sametime.acmecorp.org” isLocked=”false” overwriteUnlocked=”true”/>
<setting name=”port” value=”80″ isLocked=”false” overwriteUnlocked=”true”/>

</settingGroup>

 

>>SNIP<<

</ManagedSettings>

For updating existing server communities you can use the following section
in the managed-community-configs.xml file.

<?xml version=”1.0″ encoding=”utf-8″?>
<managed-communities>

>>SNIP<<

<managed-community id=”sametime.e-office.com” host=”sametime.acmecorp.org” port=”80″/>
<managed-community-action type=”update” managed-community-id=”sametime.acmecorp.org”/>

>>SNIP<<

</managed-communities>

A complete list of configurable options can be found here

The settings should work for the stand-alone Sametime Connect client
and the embedded version within IBM Notes.

Shutdown your Sametime Connect client and start it again.
The server community port should now be listed as 80.

55-CR1-homepage-db2.sql – 705 vs. 704

If you were one of the early birds deploying Connections 5.5 and you used the
Connections SQL files from the initial supplied Wizard tools then applying CR1 will fail.

The 55-CR1-homepage-db2 SQL script checks on DBSCHEMAVER 705. This is the version used within the Connections SQL files from the Day1Fix Wizard tools.
The “old” scripts use version 704 for the DBSCHEMAVER column.

UPDATE  HOMEPAGE.HOMEPAGE_SCHEMA SET DBSCHEMAVER = 706, RELEASEVER = '5.5.0.0 CR1'
WHERE   DBSCHEMAVER = 705@

Change the 55-CR1-homepage-db2 SQL script upfront befor applying or make the change after in the HOMEPAGE.HOMEPAGE_SCHEMA table.

.Wizards\connections.sql\homepage\db2\createDb.sql

--------------------------------------
-- INSERT THE SCHEMA VERSION
--------------------------------------
INSERT INTO HOMEPAGE.HOMEPAGE_SCHEMA (COMPKEY, DBSCHEMAVER, RELEASEVER) 
VALUES ('HOMEPAGE', 704, '5.5.0.0')@

.\Wizards_IC55day1fix\connections.sql\homepage\db2\createDb.sql

--------------------------------------
-- INSERT THE SCHEMA VERSION
--------------------------------------
INSERT INTO HOMEPAGE.HOMEPAGE_SCHEMA (COMPKEY, DBSCHEMAVER, RELEASEVER) 
VALUES ('HOMEPAGE', 705, '5.5.0.0')@

 

 

Customize the new Hikari theme in IBM Connections 5.5

With IBM Connections version 5.5 a new default theme was introduced, the
Hikari theme. In order to customize this new theme new directory paths are
required. You can find the source sprite files ( images ) and the CSS files of this
theme in the following location.

D:\IBM\WebSphere\AppServer\profiles\AppSrv01\installedApps\ACMECORPCell01\Common.ear\connections.web.resources.war\WEB-INF\eclipse\plugins

Now open the following JAR file. ( Running IC55 CR1 )

com.ibm.social.hikari.theme_1.0.0.20160515-0614.jar

Under \resources\sprite you can find the images used within this theme.

com.ibm.social.hikari.theme_1.0.0.20160515-0614.jar\resources\sprite
WinrarSpriteFolderHikariTheme

 

Place customized versions of these images under the CONNECTION_CUSTOMIZATION_PATH. Find the current customization path in the WAS console under Environment -> WebSphere variables.

For example, CONNECTIONS_CUSTOMIZATION_PATH  =
\\\\fs01.ACMECORP.net\\connections55\\customization

Additions and customization’s for the Hikari theme style-sheet needs to be placed under
the following path in a file with the name custom.css.

\\fs01.acmecorp.net\\connections55\customization\themes\HikariTheme

Custom sprites used by the Hikari theme need to be placed in the below mentioned directory. You can just create a copy of an existing sprite file and make adjustments to it, use other colors or create complete new icons.

\\fs01.acmecorp.net\connections55\customization\javascript\com\ibm\social\hikari\theme\sprite

This way you can easily re-style the images used for the Apps menu or the Mail & Calendar icons as used by Connections Mail.

HikariThemeCustomizedMailIcons

IC55 Hikari theme custom mail icons

HikariThemeCustomizedAppsIcons

IC55 Hikari theme custom Apps icons

 

 

 

The caching mechanism of Connections can be very persistent. When activating new
theme changes for Connections I always go for removing all the temp files of the
WAS IC nodes. So stopping all JVM’s, removing everything under AppSrv01/temp and
starting all JVM’s again. Then in the browser go for a CTRL + F5 to see the theme changes.

A strange phenomenon in the combination of Connections 5.5, Connections Mail 1.7 and Windows servers is that temp files are created in directory paths which are longer than the supported length of Windows. ( running Windows 2012R2 )

Whenever you try to remove the Common temp folder you will get this prompt.

WindowsConnectionsMailtempfiles

 

 

 

 

 
Whenever you try to browse to certain directories you will notice that the path
gets so long that you will not be able to open the underlying directories anymore.

For example:

D:\IBM\WebSphere\AppServer\profiles\AppSrv01\temp\NLDELCONN98Node01\InfraCluster_server1\Common\connections.web.resources.war\eclipse\workspace\.metadata\.plugins\com.ibm.servlets.amd.dojo.1.9.resources\__build-version__\domjs\dojo_trunk\131.20160119-0324

In order to delete these temp files you will need to make the full path length smaller.
So in case of the path as mentioned  above rename some of the directories to a
single character.

AppSrv01\temp\NLDELCONN98Node01\1\2\2\eclipse\

 

 

Working with IBM Connections Communities under a different URL

During side-by-side migrations or for backup/restore projects it sometimes is necessary
to access your Connections data under a different URL than the original one.

For side-by-side migration projects you may want to run a test migration and let
a subset of test users reach the new environment at a temporary URL. This way you don’t have explain anything about changing hosts files etc and testing access for mobile devices gives you no other challenges than using an alternative Connections URL.

Also testing purposes may demand you to have a set of data that resembles the production system. A thing that will help in troubleshooting data related production issues and gives you a try how to deal with a Connections data backup/restore routine.

The challenge with these projects is that there are components inside Connections which hold absolute URLs inside their configuration. The Community widget configuration is one of them. But you will also see this for Blog items which have images in them which are saved inside the Blogs component.

Also some issues could arise with embedded images inside Wiki pages. ( Okay so the Wikis embedded images thing is related to Connections 5.5. The following tech note was already released to address this issue. “Following migration to IBM Connections 5.5, images within wiki pages have disappeared and replaced with a small box.” )

As you notice it all is a bit trial and error which is mainly because no good
all-one backup / restore procedure exists yet. A lot of progress has been made to introduce trash cans in order to be able to restore deleted Files, Activities etc.
But doing a complete restore to a different environment, for example, get a presentably production like environment is a real challenge.

For now this Blog entry lists a way to fix the widget configurations of Communities so at least all functions within a Community are available and usable.

On creating, Communities don’t have absolute URLs in those widget configurations if
you stay to using “stock” Connections widgets. Add-on widgets like the Library and the “Featured Survey” widget always include an absolute URL inside their configuration.

The “Featured Survey” widget with a wrong URL configuration caused some Communities to get stuck in an infinite reloading loop.

Some other thing I saw going bork when accessing the Connections environment under a different URL was the Files widget. Saving settings for the Files widget will have the effect that absolute URLs  are included.

Below the error you will see when the the Files widget configuration uses absolute URLs.Files-widget-error

All Communities have a widget configuration saved as XML inside a BLOB column in the SNCOMM.LC_EXTENSIONS table. The name of the column is EXT_VALUE_EXTENDED.

widget-config-featuredsurvey widget-config-library

 

 

 

 

 

Once you access the Connections environment at the correct URL the thing to fix is to replace all old URLs with the new one within all XML configurations. A good database tool which you can use to open/edit and save BLOB fields is DbVisualizer. Running it in evaluation mode will give a way to edit BLOB fields. If you have a lot of these wrong widget configurations you be better off coding something with Java or SQL else you will be clicking yourselves senseless.

mustang-edit-blob

IBM Connections Plug-in for IBM Notes & Connections Cloud

Support for the Connections Cloud in the IBM Connections Plug-in for IBM Notes  seems on its way.

NotesPluginSmartCloud

 

 

 

 

 

https://greenhouse.lotus.com/blogs/We047f6e69323_42ff_8db6_8bd4fe32a841/entry/Make_the_Files_sidebar_widget_to_work_with_SmartCloud?lang=en_us

Re the “The Files sidebar plugin does not support IBM Connections Cloud” technote.