In this blog we’re going to look at installing a new version of Connections 5.5 then updating it with the latest fixes.
Setting Up The Repository
We start installing Connections by configuring a new repository in Installation Manager. Having extracted the Connections installer the repository.config will be found in the IBM Connections directory.
We opted to deselect the existing repositories that we used to install WebSphere. We may need them later so deselecting is a better option than removing them entirely. If however you do delete the installers from your file system you should remove them from the list of repositories as well
What Are We Installing?
The only product we can install is IBM Connections Version 126.96.36.199. Don’t worry about the fixes and updates at this point, we are just doing a base install initially.
Since we have never installed Connections on this machine Installation Manager will create a new package group to track the software. The previous package group is used for WebSphere products only.
The next page has a list of features that can be installed as part of Connections. By default all are selected and I would always install all for a standard Connections build. If you scroll down this list there are “Optional Components” such as Connections Content Manager which are not selected by default. This would require additional licensing.
The next few screens take us through the Connections install and validate we have everything else in place. You need to have installed and configured WebSphere as well as DB2 (or SQL/Oracle), created the databases and preferably populated them before you can install Connections.
Connecting To The Deployment Manager
On the first screen the installer needs to validate that WebSphere is in place and that it can login The account listed here as “Administrator User ID” will by default be given access to all the Connections applications as they install. You can’t click “next” on this screen until you click “Validate” and that changes to “Validated“. To achieve that the installer will try to login to the deployment manager using the credentials you show.
Make sure the deployment manager is running or the installer will not be able to login.
You may receive a warning at this point that application security is not enabled and that will prevent the installer from validating. If that happens, leave the installer on this screen and log back into the ISC on https://hostname:9043/ibm/console.
Go to Security – Global Security and choose “Enable application security”. By default the box is unchecked. It needs to be checked as shown below and the configuration saved, then restart Deployment manager and go back to your Installer screen to try validating again.
If you receive a warning about missing SSO configuration when you try to enable application security simply click on “Single Sign-on (SSO)” under “Web and SIP security” on the right and enter the domain you are using for this environment as shown below.
So.. back to our installer screen and we have the nice “Validated” button at the bottom so we can now click “Next”
Where Do The Applications Go?
The topology page is where we choose how to deploy the Connections applications onto which servers. IBM tries to help you here by asking what size deployment you want
You should only ever choose a “Small” deployment where every application is on a single WAS server instance for a test or development environment. Bear in mind the server will be slow to start as every application will be on it. Also finding debug information in the logs may be harder since each log file will contain all content for all applications.
The most common option is “Medium” where the applications are spread across multiple server clusters. Each server has its own allocation of memory and runs only the applications assigned to it. In addition if we wanted to grow the environment by adding a cluster instance, we could choose to do so for only the most under demand servers/applications. IBM provide a suggestion for which applications should be assigned to which servers but it’s only a suggestion – you know your business and your requirements best. Bear in mind it’s a good idea to spread the applications that will be under heavy load across different servers.
The “Large” deployment creates one server per application which could mean 20 or more server instances. This would only be done for extremely large Enterprise deployments and will need to be planned carefully across multiple nodes.
For Connections101 we have chosen a “Medium” topology so IBM offers to create four individual server clusters to put the applications on. Since our environment currently has only one node , all those instances will be created in that node. This is an opportunity to move applications around between servers and even rename servers if we want.
You should already have a design in mind before you get to this point of the install. If not stop now and think about how you want the applications deployed across how many servers.
Verifying The Databases
Our third page is where we tell the installer where the database server and databases are. The installer will take the settings you provide here and attempt to access each database using those settings and credentials. If you created a LCUSER account to use when running the DBWizard you would use those credentials here. In the past on Linux there have been issues with case sensitivity for the account name so make sure if the account you create is ‘lcuser” you enter “lcuser” in lower case for the credentials.
See the earlier blog on the DBWizard for how to create the lcuser account
Defining The HTTP Server
On the fourth page we can choose to tell the installer about the IBM HTTP Server we created earlier. This is a good idea and will save you work post install as the installer will ensure all the mappings for the applications to use IHS as a front end are in place including in the LotusConnections-Config.xml. If you haven’t already created an IHS instance then you can choose “Do Later”.
Since we have already created the IHS node in our earlier blog and called it webserver1 all we have to do is choose “Do now” and the installer will select our server automatically.
Cognos. Leave it for now 🙂
We would always recommend installing Cognos later. The steps involved are fairly complex and take us away from the base Connections application install. Once Connections is installed and updated (and backed up / snapshotted), we can come back and install Cognos.
Choosing not to install Cognos does not prevent the installer for installing the Metrics application which gathers activity for Cognos and other 3rd party tools to use so you will not lose data if Cognos isn’t immediately deployed.
Where Is The Data Going To Go?
On the content store page the installer needs to be told where to create and store data. There are two content stores that need to be defined and both are used by every server.
- a shared network content store. The location of which must be accessible by every server regardless of platform. Each server must use the identical path to find the content store so the path we choose to enter here has to be visible and accessible to each server. If you have a mixed Windows and Linux environment or choose to put your content store on a Linux share, ensure that there is a single path that can reach that store from every server.
- a local network content store. The data in the local store is only used by the server on that machine and should be unique to each machine, however the path to the local store should be identical for each server. We can workaround this post-install by modifying environment variables later on but for now we should plan for the path to the local store to be consistent.
The validation check on this page only verifies that the paths and directories exist to the installer. It doesn’t verify that all servers can see them or even that they are writable as well as readable locations. That’s something you need to confirm yourself
Mail Notifications And Replies
On the next tab we can configure the mail notifications. This is something that is fairly straightforward to do post-install so if you haven’t considered how you want notifications to work you can stop and do that now. If you think you might want to change things in the future then come back to it later.
We chose to have notifications (emails) to users as well as granting users the ability to reply to mail. Since WebSphere has no mailboxes of its own the reply to messages must be delivered to an IMAP accessible mailbox on a server.
When defining how to find a mail server to send mail we have two choices We can use WebSphere’s own built in mail session to have SMTP mail sent to a specific server or we can rely on MX records in DNS to route mail for onward delivery. These options can also be easily changed post install.
Always use a dedicated account for sending and collecting mail and if possible use secure SMTP so the credentials cannot be intercepted en route. The reason I prefer to use a dedicated account is to ensure the account is only used by Connections. It’s far too easy for a shared account to be renamed, deleted or even have its password changed without anyone thinking to tell the Connections admin!
This is a new and much welcome feature in 5.5. Here the installer gives us the option of adding users from our LDAP directory who will automatically be assigned administrative rights to each application (rather than just the connadmin account i’m using for the install). Similarly we can add individual users as moderators and those will be granted the correct rights to provide moderation across applications.
One of the first things we used to do post install is go into each of the 20 or so applications and manually add additional administrative users and moderators so telling the installer now to do it for us saves a lot of time. However, what I really want to do is add groups not individuals. That way I could have a LDAP group called “ConnectionsAdmins” and have that added here.
If you are going to want to use groups rather than users for security it’s best to leave these options empty as this point and go back post install to manually add the groups.
We can now complete the install. This could take anywhere from 20 minutes to 2 hours depending on the complexity of your environment, disk and network speed.
The lovely green tick is what we hope to see. If the install fails, open the install log and read it carefully. In my experience the install can often fail for three reasons
1. The person running the install doesn’t have the authority to write to the WebSphere servers or the file system
2. You run out of disk space on a partition during the install
3. There are old files hanging around from an earlier failed installed that need to be removed
Checking Everything Installed
Once the install says it completed successfully, we login to the ISC and verify all the applications are listed under “Enterprise Applications”
We also check all the servers we asked to be created on the topology page of the installer do now exist.
So that’s the install. However before you go any further you are going to want to install any and all patches that have come out since the base 5.5 version of Connections was released.
Even if you think you have all the most recent fixes, now is the time to go to Fix Central and check there are no new updates for Connections 5.5
If you find new updates you should download them to your file system. The very first thing we need to do is extract the updater file 188.8.131.52-IC-Multi-UPDI-20151224.zip and find the .zip or .tar file within that. That compressed file will itself extract into a directory called updateInstaller.
The updateInstaller must be extracted under the Connections install directory which in our environment is /opt/IBM/Connections. Once extracted it looks like the screenshot below.
Any other fixes (jar files) that you download from fix central should be copied to the “fixes” directory here.
To run the update wizard for Connections, which applies all the fixes we run updateWizard.sh / bat but first we need to do two things
- Run setupcmdline from the Dmgr bin directory so /opt/IBM/WebSphere/AppServer/profiles/Dmgr01/bin/setupCmdLine.sh
- Set the WAS_HOME variable (as shown above)
Now we can run updateWizard
The Update Wizard can both install and remove updates. That’s useful to us because there may be some cases when we may want to easily remove an update once it has been applied.
In this case we’re going to Install updates. The updater lets us choose where the fixes are located so in theory we could put them anywhere and not just in the “fixes” directory under “/Connections/updateInstaller” however it’s safest to put them there and work from that directory.
The installer finds any fixes that were in that directory and asks us which ones to deploy showing the application affected (if it’s just a single application) and the release date of the fix.
In this case, because we went to apply all fixes at once, the upgrade wizard warns us that some of the fixes are already obsolete so we can go back to the previous screen and deselect those.
The update wizard gives us a final warning that we need to backup our customisation directory. At this point we are on a new install and have no customisations so we can go ahead and say we have made no changes.
If you have made changes, even if you don’t think the update you’re applying should affect those changes, make sure you manually back them up.
Finally it will run and apply all the updates. During this process it will remove applications, add new applications, change configuration settings, clear out temporary data etc. In fact it could be completing a lot more work than happens during an install – this could take a long time.
If you are concerned about the progress of the updater it will be creating log files in the Connections install directory under the version / log location e.g /opt/IBM/Connections/version/log. You can monitor this directory to see each update as it happens and reassure yourself things are progressing.
If you have problems with Connections after an upgrade IBM will want to see those log files so do not delete them.
Finally the updater will finish and confirm what it managed to successfully complete.
Confirming What Version Is Installed
If you’re a control freak like me you might now like to confirm the version of Connections you’re on by running the updateSilent command from the file system. It can be found in the updateInstaller directory where we ran the wizard from and the syntax is
updateSilent -fix -installDir as shown in the screenshot below
and we’re done. Now go make yourself a coffee and relax before we go onto the next step !