Installing Connections

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  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!


Role Mapping
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.

Applying Fixes
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 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 / bat but first we need to do two things

  1. Run setupcmdline from the Dmgr bin directory so /opt/IBM/WebSphere/AppServer/profiles/Dmgr01/bin/
  2. 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.  skitch.2

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 !


Installing TDI

Tivoli Directory Integrator is used to move data between our LDAP source (in this case Domino) and our DB2 (or SQL or Oracle) profiles database (PEOPLEDB).  IBM supply a range of Wizards and batch files to achieve this and they all depend on having TDI installed somewhere.

Once the TDI installer is extracted we run ./ in Linux (or launchpad.exe in Windows) to start installing TDI.

On linux this may fail because there is a script that validates if a supported browser version is installed.  The script is a bit old and only checks for Firefox numbers beginning 1x and 2x – we’re currently on Firefox 35 and growing. To workaround that validation modify the file in the launchpad directory as follows


The regedit syntax using [1-9][0-9] should cover any version Mozilla release for a couple of years 🙂

Now should run



I choose a custom install because we only need a limited set of features installed for our purposes.


In theory I only need the Server component – the CE (Configuration Editor) is for creating and managing AssemblyLines.  In a simple install we don’t use it but I like to install it regardless and it’s very likely we will use it to customise our directory sync activity.


The working directory should not be a static choice. Each time one of our TDI scripts runs, the parameters for that script will come from the directory it exists in.  By not setting a working directory we are able to run multiple scripts from different locations with different settings.

Once TDI 7.1.1 is installed we need to patch it to fixpack 5 before doing anything further. After downloading the fixpack ( and extracting it there will be a file called UpdateInstaller.jar in the extracted directory.

Copy the new UpdateInstaller.jar file to /opt/IBM/TDI/V7.1.1/maintenance

Copy the extracted fix to a convenient location – in this case I’m using the directory where I’m going to run the update from /opt/IBM/TDI/V7.1.1/bin


To apply the fixpack we run ./ -update <fixpackfilelocation>



Once the updates have been applied we can verify it ran successfully using:

./ -queryreg

which shows us both components installed and patch levels for each.

In our environment we are installing TDI on the same server where DB2 is installed but if we weren’t we would have to copy the DB2 library files over to the TDI server so the two can communicate.

Installing IHS

Connections uses IBM HTTP Server as a front end webserver, this is because WebSphere servers and their applications don’t listen on regular HTTP(S) ports 80/443 – each of the WebSphere servers I install will assign itself dedicated ports (see the earlier post on WebSphere installation).  If I install three WebSphere servers I will have three secure and three non secure ports that the applications may be listening on.  Blogs may be listening on a totally different port than Communities for instance.  As you can imagine that would make it very difficult to manage and route client requests.  By putting a webserver in front of the applications I can route all traffic through the standard HTTPS/443 port.

IBM HTTP Server is part of the WebSphere Supplemental installers.  I extracted those files and configured my Installation Manager (IM) repository to find them


IM now has references to two repositories, the WebSphere installers and the WAS Supplemental installers.


There are a lot of programs in the supplemental package but I want to find IBM HTTP Server so I use my filter at the top to help me find it.  Make sure the “show all versions” checkbox is ticked so earlier versions like fixpack 6 display.  I also want to find and install the Webserver Plugins for WebSphere as we’ll need these to integrate IHS with the installed Connections applications later.


Since I’ve chosen two products to install I need to set two directories to install into. The first directory is for the IHS server itself and this defaults to /opt/IBM/HTTPServer, you can change this if you want. I usually don’t unless there’s an issue wtih the /opt partition.


To verify and change the second directory for the web server plug-ins I have to click on that entry in the package group screen.  The plugins can be installed anywhere but I’ll need to remember where I put them for later !


On the next screen I can choose the features to install.  The installer will default to the correct architecture for the OS


The standard webserver port is 80 (this is for HTTP not HTTPS).


.. aaanndd IHS is installed.

I can’t run it yet and my work isn’t done.  I still have to

  1. configure the admin interface
  2. add the webserver to our ISC
  3. configure the http server
  4. create a SSL keyfile and enable SSL

I’m going to go ahead and complete steps 1 and 2 now and come back to steps 3 and 4 after I have Connections installed.

Configure The Admin Interface

To set up the admin interface I need to have an account in Linux I can use.

adduser ihsadmin

I need to set the admin password for IHS. From the directory /opt/IBM/HTTPServer/bin I type

./htpasswd -c /opt/IBM/HTTPServer/conf/admin.passwd ihsadmin

and I will be prompted to set the admin password for ihsadmin

The command to start the admin interface is ./adminctl start but that won’t work until I complete the admin.conf configuration in the /opt/IBM/HTTPServer/conf directory

vi admin.conf

search for @ symbols that you will need to replace with ports, for example



The default admin port is 8008.  To verify if I have the configuration file correct I type

/opt/IBM/HTTPServer/bin/adminctl configtest

To start the admin server I use

/opt/IBM/HTTPServer/bin/adminctl start

To verify it has started type netstat -tulvn |grep :8008 and I should see the server listening on that port.

Adding The WebServer To ISC

Log into the ISC at https:<hostname>:9043/ibm/console


Choose “Nodes” under “System administration”.  Currently I have two nodes for the Deployment Manager and the Application server profiles I already created on the previous post where I installed WebSphere. I want to “Add Node” to add a new node.


Since I’m not adding a WebSphere server but an IHS web server there’s going to be no way for WebSphere’s Deployment Manager to actually manage it so I need to add this as an “unmanaged node”.  Only WebSphere servers can be added as “managed nodes”


My unmanaged node properties are the

  • Name – which is only used within the ISC itself and never presented to the users so can be anything unique
  • Host Name – the host where the IHS is installed.  This hostname must be resolvable from the Dmgr.  In this case I installed the IHS on the same server as the Dmgr so they share a hostname
  • Platform


Once completed my new unmanaged node is shown in the list of nodes but as you can see the status column is empty because that column refers to WebSphere sync status and this node is not for a WebSphere server.


Now I’m ready to add my new IHS server on the new unmanaged node to ISC.  Go to Servers – Server Types – Web Servers and select “New” to create a new Webserver instance


Now I can choose the unmanaged node I just created and name the server (choose webserver1 as the name if you can since WebSphere often “assumes” that) and then choose the “Type” (IBM HTTP Server always)


On the next screen I need to tell WebSphere how to connect to the admin interface of IHS.  I just set that up using account ihsadmin and port 8008.  If the admin service isn’t started or the ihsadmin account isn’t set up correctly WebSphere won’t be able to “talk” to IHS at all..


Since I chose IBM HTTP Server on the earlier screen WebSphere knows there’s only one template I can use.


My install is now complete and my IHS web server is now part of my WebSphere cell.


Installing WebSphere

We can’t install Connections until both WebSphere and the DB2 (or Oracle or SQL) databases are in place so let’s start with WebSphere.  On previous posts we looked at installing Installation Manager (IM) and setting up a software repository to point to the WebSphere installers


My first check is to decide what version and fixpack I need and I do that by checking the System Requirements. These can change any time so I make a point to check them just before doing an install.   According to the current requirements Connections 5.5 needs a minimum of WebSphere Application Server Network Deployment 8.5.5 Fixpack 6. Since the requirement is a minimum I could install the most recent Fixpack 8 but for my purposes I’m sticking with Fixpack 6 today.


Even though at this point I’m not installing IHS I can see on the system requirements that it only supports 8.5.5 fixpack 6 of IHS.  This is something I need to remember later.


When  launching IM and clicking “Install” I am presented with serveral products with their latest versions and options.  I have to click the checkbox “Show All Versions” to choose an earlier fixpack such as Fixpack 6


There are now hundreds of products and versions to choose from so to make it easier I type “network deployment” in the search bar at the top to filter the product choices (and so I don’t accidentally choose the wrong one). I then select as the version I want to install. I haven’t downloaded, only 8.5.5 so I’m relying on IM to get the fixpack from the Passport Advantage site.


There are already several fixes available for but, having checked the System Requirements to ensure there are no specifics fixes I need, I let IM choose the recommended ones only.


I now identify two locations, The first is the location for the shared resources directory used by IM.  This is the location for IM to store the installers, fixes and rollback files, not the location of the WebSphere program itself.


Now I can tell IM where to install WebSphere.  The default “WebSphere” directory will always be /IBM/WebSphere/AppServer and I would only change this if I was installing multiple WebSphere versions on the same machine (unlikely).  On Linux this defaults to /opt/IBM/WebSphere/AppServer and on Windows I try to put it on a separate drive partition from the OS such as D:\IBM\WebSphere\AppServer.  This location is your “WebSphere program directory” that is referred to in documentation.


These are the standard features I install for Connections.  At this point the total install size should be about 2.5GB across both directories.


Our confirmation screen just before the install starts shows what products will be installed into which locations.  Read the target location details at the top of this screen to confirm you have entered them correctly.


Our WebSphere install is now complete (love that big green tick) but now I need to create profiles to set up the servers.  Selecting OK here will launch the profile management GUI tool but this can also be launched later off the GUI menu or you can create profiles by using the /opt/IBM/WebSphere/AppServer/bin/ command


Since this is the first server in my deployment I need to create a new cell which will include both a deployment manager and an application server.  I often like to create the deployment manager standalone on its own machine if I’m building a HA cluster but for our purposes in Connections101 I’m just locating both the deployment manager and my first application server together.  These are the first servers on “bogart” as shown below.  If I were creating an additional Application Sever on “marlowe” then I would be creating an Application Server profile only at this point.




Often during profile creation I would just choose the “Typical” option which is a far simpler series of choices with some default settings.  I’m choosing Advanced profile creation here to show you all the settings available to you.  The difference between “Typical” and “Advanced” is purely the ability to custom set options like ports, certificates and passwords – all of which can also be changed later after the profile already exists.


I always want to deploy the administrative console if I’m deploying a new cell because that’s how I’m going to manage all the servers.  If I add an existing Application server into an existing cell by federating it, its administrative console will be removed so it can be managed only by the deployment manager.

I often choose not to deploy the default applications for security reasons because it just gives me more things to have to lock down.  It can be useful for WAS troubleshooting but I rarely use it.


The first deployment manager on a node is usually put in a profile Dmgr01, similarly the first application server is put in the profile AppSrv01.  You can change both of these to something more meaningful if you want.  I never usually do. One thing to note in WebSphere world is to stay away from anything that could be a special character for path names or passwords.  As I mentioned on the previous post, all WAS configuration is stored in XML files and often encrypted so decrypting those special characters can fail and cause WebSphere itself to stop working.

Specific special characters to avoid for anything WebSphere related include


but I like to avoid anything that could be problematic including accented characters.  Longer passwords can be just as effective.


The hostname for the server is picked up from the server’s local settings or host file. You need to make sure it’s a fully qualified name and not just “bogart”.  It also needs to be fully resolvable with an IPV4 address from itself and any other server.  The default deployment manager and application node names will be “servername”CellManager01 and “servername”Node01.  This is important because the servers will be installed with these names and a lot of nested directories will use the names.  IBM recommend your server name is no longer than 8 characters for this reason (avoiding creating very very long filepaths) but if your servername is long you can change the node names here to something shorter..

The cell name and node names cannot be changed post install and will be used to reference the servers internally.  It will always be possible to add another resolvable fully qualified hostname like “” as an alias later but you can never fully remove these names.


When WebSphere is installed new SSL certificates are created using an IBM internal Certificate Authority and the servers’ hostnames and roles.  These certificates are usually replaced by me post install with valid SSL certificates from a public or internal provider.  If however you have a wildcard certificate for your organisation already you could add it during the install and avoid having to replace the internal IBM certificate later.  You would still need to add the trusted root though and I’m a control freak so I like to let IBM create its certificates then manually go in and replace them later.


The default certificates that are created (assuming you didn’t choose to replace them on the previous screen) will have keystore passwords of WebAS.  This is well known as IBM’s  default keystore password and for that reason WebSphere will see it as a security issue if you don’t change the password for keystores on a running server.

Again I prefer to let it install and then change it later but you can change it here during the install process.


There are three pages of ports that WebSphere will use for different services.  Unless there’s a specific reason you can’t use one of the default ports I suggest leaving these as they are (in a “Typical” install you never see these screens).  If you must change them I would suggest only incrementing them by “1” until you get to a port number you are happy with.


On Linux and Windows you are presented with the option to add the Deployment Manager to run as a service when the server starts.  You don’t get that option for either the nodeagent or any of the application servers which you will have to add manually after all the install work is complete.


Finally I get the option to create an IHS server definition.  I will need to do this at some point since we are going to put IHS in front of our Connections servers but I haven’t installed IHS yet and so I’m going to leave this for later.

That’s our WebSphere install complete.  It should take anywhere from 15 mins to an hour depending on your disk write speed.


Once installed, if you have a GUI, you will see IBM Websphere on the Application menu. From here you can find the profiles that were created as well as create new ones and start or stop individual servers.


The above screenshot shows me checking the install completed successfully.

First I do an “ls” to see there are both profiles there.  The system shows me Dmgr01 (the deployment manager profile) and AppSrv01 (the application server profile).  That’s good.

Now I navigate to /opt/IBM/WebSphere/AppServer/Dmgr01/bin and run ./ (note case sensitivity).  This should start the deployment manager from within its own profile.

Once it has started I want to check it’s listening and I know the deployment manager listens on port 9043 for the Integrated Solutions Console so I type

netstat -tulvn |grep :9043 to find if that service is listening.

We now have WebSphere installed.  If you are setting up multiple servers on different boxes you would now need to go and repeat the install but this time choosing to create only an Application Server profile on each of those boxes.  Remember to keep your WAS version on every server in your cell aligned at

Working With Installation Manager

Now we have Installation Manager (IM) installed it’s going to be our primary go to place for installing everything else so let’s have a look at how it works.


If you use a GUI you should see IBM Installation Manager added to the programs menu and you can run it from there, but you can also run it from the command line.  Navigate to the install directory /opt/IBM/Installation Manager/eclipse (beware case sensitivity) and run ./IBMIM.  I am using sudo to run it with the appropriate (root) rights because I’m not logged in as a root user.




The Installation Manager main menu gives us several options for working with software

Install:  adding new software such as WebSphere or Connections itself

Update: applying fixes and updates to already installed software

Modify:  changing the options for already installed software such as adding or removing features

Roll back: taking software back to an earlier release level for example rolling back WebSphere from an applied fix or IF

Uninstall: there’s no way back from this, uninstall the software and it’s gone completely


The file menu on the IM allows us to view what software , versions and locations exist.  We also use this menu to set up file repositories where IM can find installers.  We’ll look at that on our next blog entry “Installing WebSphere”.

As you can see, running our installs and updates through IM gives us much more flexibility and control over versions and upgrades.  Since IM maintains records of all installed software, location, patches and features it can’t be uninstalled whilst the owned software is still in place.  And by “can’t” I mean “won’t”.  If you try and uninstall IM it will simply refuse to uninstall itself until you have used its “uninstall” option to remove its owned software.

Installation Manager takes only a few minutes to install but think carefully about who installs it, who has rights to run it, and most importantly its install location

Setting Up Repositories

For IM to install software you must first tell it where to find the software you want to install.  Let’s take WebSphere as an example.

The WebSphere New Deployment installers come in 3 compressed files.  We extract all of those to the same directory using the syntax

unzip filename (eg -d {directoryname]

if you don’t use -d as a parameter the file will unzip into the directory you are currently running the command in.



Unzipped you should have 3 folders disk1, disk2 and disk3 and a repository.config file.  The repository.config is what IM looks for to determine how to install the software.


You want to add repositories for any software you plan to install by choosing File – Preferences from the IM menu and then “Add Repository”


Browse to the location of the extracted installers and find the repository.config file then select it.




One of the advantages of IM is that it can store previous versions of the software to enable you to rollback at any point, however the files needed for rollback need to stored on the file system and take up space.  You can go into this section of IM and choose to remove the saved rollback files at any point once you know you won’t need to rollback. If you do remove the files it should still be possible to rollback but you will need to be able to supply the original versions of the installers you want to rollback to.


When updating or installing software you can optionally be prompted for credentials to Passport Advantage in order for IM to find the files online.  This tells IM to find any updates available on Passport Advantage. It saves you the trouble of finding and downloading WAS fixes and patches but does require that the server has access to the internet.


Now when you go to Install or Update software IM will prompt you to login to Passport Advantage and optionally save the credentials so it won’t ask again.

Now we’re ready to install WebSphere.


Installing Installation Manager

Installation Manager (IM) is the IBM management tool that controls and manages the installation of IBM software. The big advantage of IM is that it creates its own library of what it installed and that enables you to easily rollback or update anything it manages.

Let’s start by installing IM – the compressed installers are different for each platform.  In Connections101 I will be installing both Linux and Windows components so I will eventually need both versions of IM (beginning agent.installer.”OS”) – extracted and shown below.

Installing IM 1

From the extracted directory run the file ./install on Linux , this will launch using a graphical interface so you will need to either have a GUI and browser installed or you will need to have set up X11 forwarding to your workstation.  There is a silent installer that you can run which won’t use the graphical interface and instead uses a response file to determine who to install. That uses file ./installc and instructions for that are here


Installing IM 2


Confirm you are installing the correct version of IM.  In our case, the newer the better.

Installing IM 3

This is the location of the Installation Manager files.  /opt/IBM/InstallationManager/eclipse by default on Linux C:\Program Files\Installation Manager\eclipse on Windows.  Change this to whatever location you want but make sure you will never run out of space on that location, or need to reassign it, as Installation Manager cannot be moved without first uninstalling all the software it manages (like Connections, WebSphere etc!).

Installing IM 4

The final screen before install confirms the location and details of the program.

Installing IM 5

On this screen you can see the “Target Location”, including the Package Group Name and the Installation Directory.  For each new piece of software IM installs it creates a new Package Group to manage it.  This is what is going to allow us to upgrade, rollback, patch and modify later one.

Installing IM 6

Having installed IM manager we can now use it to install other things.

Installing DB2

I am going to use DB2 as our Database server rather than SQL or Oracle because that’s part of our Connections entitlement.  If you have expertise and licensing for either Oracle or SQL and prefer those servers then I would go with them instead.  This DB2 install for our Connections101 server is very simple, a single instance and standard accounts. Depending on your requirements for HA and/or your number of users you may need to give that more thought.

I downloaded and use the DB2 (fixpack 5) universal installer.  You can install this without installing 10.5 first.  I extracted the compressed file v10.5fp5_ntx64_universal_fixpack then checked the OS meets the install requirements using the pre-requisite check

From the directory /DB2/univeral run ./prereqcheck


the pre requisite check is going to validate if all the correct OS libraries and settings are in place.  In my first check I was missing several necessary files including 32bit versions of some libraries that even the 64bit DB2 installer needs.

Installing Dependencies

Any libraries that are missing can be installed using yum – in this case I was missing gcc which I resolved with “yum install gcc”.  This is why I strongly recommend you don’t attempt a Linux install without a subscription in place to help you find and install all the libraries you need.

Each time I successfully installed a missing library I re-ran prereqcheck again.  In total it took less than 10 minutes to get all the libraries installed.

The final pre-requisite you may fail on is ensuring SELinux is disabled on the OS. By default it will be enabled and to disable it you can edit the file /etc/selinux/conf (in my RedHat deployment) using:

sudo vi /etc/selinux/config and setting SELINUX=disabled

Disable SELinux

Once all the pre-requisites are passed we can go ahead and install DB2 which we do by running ./db2setup from the “universal” directory the installer created (the same directory we ran db2prereqcheck from).

The default installer uses a GUI so you can either configure your SSH connection to use X11 forwarding or (I prefer) use either NoMachine or VNC.  X11 works well but can be very slow to redraw screens.

db2setup 1

I choose to “Install a Product” and in this case I’m installing the DB2 Workgroup Server Edition which is all that I need to host the Connections101 databases.

db2setup 2

I like to choose the custom install so I can minimise what features are added and ensure no unnecessary services are listening or available.  Having services I don’t need installed just exposes access via a route I may forget exists and so don’t secure properly.

db2setup 4

Here are the features I chose – I don’t for example install LDAP or SSH services with my DB2 server for Connections.

Bear in mind that although DB2 itself will install into /opt/ibm/db2/v10.5, the actual databases will install into the home directory of the instance owner – /home/db2inst1. If your Linux partition isn’t set up correctly to allow plenty of space in /home (which by default it often isn’t) you will hit space problems.

Similarly when installing on Windows look at the install screens carefully and note where it wants to use c:\programdata for storing DB2 information. Even if you choose to install the program files on an E drive you need to make sure you check all locations to avoid filling up your C drive by default.

db2setup 6

Now we need to set up users who will have administrative access to the DB2 services. In Windows the default user is a local account called db2admin.  In Linux it’s a local account called db2inst1.  At this point of the install neither account exists, the installer will both create them and grant them the access they need.

It’s important to note what you use on the next few screens for the account names and passwords.  You will need to switch to these accounts at various points to work with DB2

db2setup 8

DB2 can create multiple instances which run in isolation from each other with their own assigned memory and resources.  In larger environments this is useful for sharing the load of many databases across the resources of a large server.

I’m choosing to create a single DB2 instance and install all the databases into it.  In a large environment I would often have multiple instances to ensure I can manage resources effectively and that I can share the Connections databases across them.

db2setup 9

The local db2inst1 account which will be created during install is the account you use to perform all the DB2 maintenance work including creating the Connections databases using the DBWizard and running the update or maintenance scripts.  Post install you can also grant other users rights to do this work if you want.

db2setup 11

DB2 installs listening on port 5000, you can easily change this during the install if you need to.  Some people choose other ports to obfuscate security so that DB2 can’t easily be found on its known port.  If that’s all the security you have in place then you should worry 🙂

db2setup 12


db2setup 13

Once the install is complete you can verify it by checking you can login or switch (su)  to db2inst1 (which confirms the account is created) or , if Windows, that you can login to the server using local account db2admin.

You should also verify that the new server is listening on port 50000 or whatever you chose during install.  I like to do this after a clean restart of the OS to ensure the DB2 server does start automatically on OS launch.


netstat -tulvn | grep :50000

or on Windows

netstat -an | find /i “50000”

Finally we need to activate our DB2 install.  Download the activation file CN3Z2ML from Passport Advantage.  


Unzip the download and find the file db2ese_u.lic which should be in the top directory.

Login to the server as db2inst1 and run

db2licm -a <pathto db2ese_u.lic>

Verify the license has applied by typing db2licm -l