Creating The Databases For Connections

Before we can install the Connections applications we must create the databases they will use.  The database server can be DB2, SQL or Oracle but the licensing for DB2 is part of your Connections licensing whereas SQL and Oracle would need to be separately licensed.  I tend to use whatever server the customer feels most comfortable supporting, if they are a big SQL or Oracle house I’ll use that.  For our purposes, and if the customer has no preference I like to use DB2.  One note about high availability, the license for DB2 includes the rights to use active/passive HADR for DB2  which means creating two servers which sync with each other but with only one active at a time. To make the active server passive and make the passive server active requires a manual switchover and will entail some amount of downtime.  For additional license cost DB2 offer a full HADR active/active solution but I won’t be discussing that on this blog.

We already installed DB2 so now we just need to run the DBWizard to create the databases.  It’s important to use the db2inst1 account we created during install as “owner” of the DB2 instance (on Windows it’s probably called db2admin) to create the databases. This ensures that the db2inst1 has the right security access to the databases and that later, when the Connections applications attempt to write to the databases, everything works.

Now I can login as db2inst1.  Don’t use “su” as that can throw errors, always login to the server as the db2inst1 (or in Windows db2admin) account.

Setting The Environment

The first thing we should do is make sure the instance of DB2 can run all the Connections databases.  Run the command

db2 update dbm cfg using numdb 20 to allow up to 20 databases to run in this single instance.  That’s a high number but in a reasonably small environment (less than 1000 concurrent users say) it’s fine. 

We also need to set the DB2 instance to use unicode before Connections installs, we can do that whilst we’re here by typing

db2set db2codepage=1208

Then stop and start DB2 to make both the above changes take effect


Creating The Databases

IBM released Day 1 fixes for the DBWizards and you need to find and use these not the ones that shipped with 5.5.  They are on fixcentral and their filenames are


Using my root account I extract the tar file to a directory like this

mkdir /home2/db2inst1/DBWizard
cd /home/db2inst1/DBWizard
tar -xvf /opt/Software/ chown -R db2inst1 * (this recursively makes the file owner of all files in that directory db2inst1)


Launch the ./ from the terminal session.  This has a graphical interface so if you don’t have one configured you will need to create a response file and run ./db2Wizard -silent -nameofresponsefile insteaad



The same dbWizard is used to create, update and delete databases, it can also just generate the SQL commands to enable you to manually do these activities yourself.  Depending on the complexity of the enviornment and / or if the Wizard starts throwing errors, I often take the SQL commands and manually run them myself so I can monitor and adjust them if necessary.


The second screen asks for (and defaults to) the location of my DB2 install as well as the account that owns that DB instance.  I am running the Wizard using that account to ensure there are no security issues with permissions on the newly created databases.


I have chosen not to create either the Cognos or the Connections Content Manager databases at this time beacuse I will not yet be installing those features.  When I come to install them later I will re-run this Wizard (or the latest version of this Wizard) and create them then.


The final screen shows all the commands that the Wizard is about to run to create each of the databases. These commands point to .sql files that were extracted into the DBWizard directory and hold instructions on how to build each database for each application.  I can save those commands to a file and keep them for reference or use them manually later.

If you want to look at what they are doing, the sql files and routines are under the connections.sql directory in the extracted Wizard location.


The wizard will now run through creating every database and logging the activity to the /home/db2inst1/lcwizard/log/dbWizard directory with one log file for each sql routine.  I like to review the log file activity as it progresses in case there are any issues – the entire process can take anywhere from 30 minutues to 2hrs depending on the speed of your disk.


Once the Wizard has finished, try to connect to one of the newly created databases from a terminal window to confirm the database is there and db2inst1 has the right access to it.


For example to connect to the Activities database I use
db2 connect to opnact

Next step: configuring LDAP and populating the profiles database

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.


The WebSphere Integrated Solutions Console

Once WebSphere is installed I want to do two things, login to the admin interface and backup the environment so I have a “start point”

WebSphere’s admin interface is called the Integrated Solutions Console and is the same regardless of what product you are working with.

To login to the ISC

:9060 which is the non secure port will redirect to 9043


Login here using the credentials created during the original WebSphere install, these credentials are created and stored in the WebSphere default repository during install (and will always be your “backdoor” into the server).


Once logged in I know that WebSphere is correctly installed and running and I can logout and move onto my next task and come back to here later.


At this point, and before I start further configuration I like to take a backup of the WebSphere environment.  This is simple to do using the backupconfig command.

From the Dmgr profile location
/opt/IBM/WebSphere/AppServer/profiles/Dmgr01/bin type
./ /opt/Backups/ -nostop

The location and filename of the backup can be anything.

The -nostop option tells WebSphere not to stop its services before it does a backup.  By default it will stop the Dmgr to avoid anyone making any updates whilst it is backing up but since I know I am the only one working on here I’m happy to take a “live” backup instead.



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

A WebSphere Primer..

Before you start installing WebSphere you should really understand some core concepts behind its architecture and options. This is going to make it easier to decide where and how to build servers.

Connections uses WebSphere 8.5.5 Network Deployment.  When you go to install your Connections applications you’re going to need at least one instance of WAS to install onto, however a single WAS install may be running multiple independent servers each running different applications. Our Connections environment could therefore be a single host machine with multiple WebSphere servers or multiple host machines each with single WebSphere servers.

Every WAS server must be installed into what is called a Node  and similarly each Node must exist inside what is called a Cell. For Connections101 I am building two “nodes” on two physical hosts with each running multiple WAS instances hosting different applications.

Each Cell has one process called a Deployment Manager whose job it is to manage the configuration settings and changes for all servers in its cell.

Each server then also has another parent process called the Node Agent. Its job is to talk to the Deployment Manager and receive the latest sync information (XML files) for the server it is managing. It’s also responsible for starting and stopping the server.  You cannot start any WAS server unless its corresponding node agent is also running.  You can’t stop any WAS server unless its corresponding node agent is also running.

Here’s an example diagram of how the architecture for Connections101 might be designed. In this design I have built a deployment manager and two separate nodes which are full clusters of each other.


In WebSphere terms only individual servers need to be clustered, not entire nodes so I could easily just cluster the busiest components in my environment such as Cluster2 which contains search , homepage and profiles.  This is why it’s important to think about WebSphere design as well as the locations of the applications and which ones you may want to cluster, before starting the install.

The Deployment Manager directory holds XML files for every server.  It copies those files into the individual server directories when you Sync the servers.   You do all your configuration by logging into the administrative interface for the deployment manager (the Integrated Solutiions Console) and from there any changes push out to the managed servers.

Based on this there are important things to bear in mind

  1. Each server will have only one node agent
  2. Each node agent can manage multiple servers
  3. So from this we know that every single WAS cell will have, at minimum, one deployment manager, one node agent and the application server itself.
  4. Changes made to server configuration on the deployment manager will need to sync down to the nodes before the server itself will pick them up
  5. Syncing basically results in copies of the XML files for a server being sent from the Deployment Manager’s directory to the Server’s directory
  6. This means there will be at least 2 copies of every configuration file for a server, one owned by the Deployment Manager and one by the Server
  7. If you try and change a server setting in the Deployment Manager without syncing, the server won’t take the change
  8. If you try and change a server setting directly on the server without updating the Deployment Manager, it will be overwritten
  9. If you install the deployment manager and server on the same machine, it still has to sync to push out changes.  From a file system perspective, there are multiple copies of the same files.  If the servers are on different boxes the files will be too,  WAS is designed to work as if all servers are physically different and isolated from each other regardless of hardware infrastructure.  Sometimes you will be asked to locate a certain file, and you may find more than one.  It’s important to learn the locations of files and their purposes (i.e are you looking at the deployment manager’s copy of the file, or the servers’).  We will get to file locations in a later post.
  10. There are a lot of restarting servers required when working with WebSphere since server changes don’t just happen on the fly, they require a sync and a server restart to take effect as the XML files can be read as the server starts up.

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.