Running The Population Wizard

The first thing we’re going to want to do once the Connections applications successfully install is test them by logging in as a regular user.  To do that the user must have a profile in the PEOPLEDB or Connections will throw an error and the easiest way to ensure that exists is to run the Population Wizard.

The Population Wizard is a simple tool that asks a series of questions such as where is your LDAP directory, where are your DB2 databases, and where is TDI and uses those answers to run a one off script using TDI to import all users into Connections, creating them a profile along the way.  It’s designed to work in only one direction (you can pull information from LDAP to databases only, not the other way around).

For a test environment or a very small manually-maintained environment you could run the PopulationWizard to update the databases whenever you want but for production it’s not really workable.  However, this is just to ensure we have some data in place that we can use for testing.  We will work with the custom TDI scripts later to fine tune what we want.

To run the population wizard look in the “Wizards” directory from the ConnectionsWizards download.  The file will be called (or populationWizard.bat).



The JDBC drive path must contain the drivers for your database platform.  If you aren’t running TDI on the same server as your databases you will need to copy the drivers from the database server to the TDI server to reference them here.

The User ID is the account granted full rights to the PEOPLEDB database.  This can often be a custom account and not (as in this case) the instance owner.


Here we tell the wizard where our LDAP server is and how to connect to it.  If you are using a secure port such as 636 make sure you check the box for “Use SSL communication”


These are the bind credentials to login and query LDAP.  They aren’t stored anywhere in this activity or used for any purpose other than running this one-off wizard so any credentials would do.


This shows the sample mapping of LDAP attributes to database fields. For example “mail” in LDAP will map to the field “Office Email”.  On this screen we can choose what attributes to map where and even if we want to map attributes at all.  Anything we don’t map won’t be populated with data and will appear as empty in Connections.

Once the populationWizard completes it should report that it imported your users.  To do this it wrote instructions to properties files and ran script files stored in the location:

/Wizards/TDIPopulation/linux/TDI –

The files it wrote our instructions to are:

The script files it ran were:

The activity is recorded in /Wizards/TDIPopulation/linux/TDI/Logs.

We’ll come back to this later when we start customising our syncing activity.

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.

Setting Up An LDAP Repository

Before we do anything else we now need to make sure our users can login.

WebSphere only has an internal file repository that will only contain the “wasadmin” entry we created when installing.  The users and groups we want to be able to use Connections aren’t in that File Repository, they are in a LDAP directory (or directories) somewhere.  We need to tell WebSphere’s deployment manager where to find and authenticate those users.

First we need to consider where our directory is going to be and if there will be one or multiple directories (if all users aren’t held in one place).  For instance, if all my users login to Active Directory I might use that, or I might use Domino which itself could be running Directory Assistance.

When deciding on LDAP directory configuration:

  1. As few directories as possible should be referenced
  2. Every user should have a unique key in the directory
  3. If you use multiple directories each user should appear only once with their unique key. If my key is my email,, then there should only be one entry with that name across all the directories we reference.
  4. The directory should be a trusted source with strong password validation

In this case we’re going to choose a single Domino LDAP server but we could have just as easily chosen Active Directory or many other LDAP directory sources.

Adding external directories in WebSphere is known as adding Federated Repositories. Before modifying or adding any federated repository I like to take a backup of the Deployment Manager.  Very often if the LDAP configuration is wrong you can end up locking yourself out of WebSphere entirely and you will need to restore from that backup.

To backup go to the /bin directory under /profiles/Dmgr01 and run:

./ <locationofzipfile> -nostop


To add or modify a Federated Repository we go to Global Security in the ISC and choose “Configure” next to the “Available realm definitions – Federated repositories”:


We are going to add an LDAP repository:


Here we enter the details of the LDAP directory source we’re going to use.  In this case I have a Domino server running LDAP on hostname and secure port 636.  Note how the “Require SSL Communications” checkbox is enabled, you must select this if you are connecting to LDAP securely.

Choosing the right Directory type from the drop down list ensures that the LDAP query syntax is correctly formed for the directory you are accessing. Selecting “IBM Lotus Domino” when pointing to an Active Directory server will prevent the directory from working.

I do not recommend using bind credentials to login to your LDAP directory unless you are also using a secure SSL protocol to connect. If you are connecting using 389 or another non-encrypted port I would suggest an anonymous bind.

The field “Federated repository properties for login” will determine what values can be used to login.  These are all LDAP attributes that map to fields in the source directories. If possible in a Connections environment we want to have “uid” listed first.  UID maps to the value ‘shortname’ in Domino LDAP, ‘mail’ maps to the internet mail address and ‘cn’ maps to my fullname.  With the values set here as uid,mail,cn I will be able to login using variations of my name including:

Gabriella Davis
Gabriella Davis/Turtle

Finally the value for failover server can be used to point to other identical directories. Although many customers use a separate load balancer to handle LDAP failover, WebSphere actually responds faster to multiple LDAP failover servers entered here rather than waiting for a load balancer to return a new host.

WebSphere will attempt to validate all the information on this screen including hostname, bind credentials and port when we save. The next step is to define the Unique Distinguished Name for entries in this repository. Whatever we choose here, it must be unique across all directories.skitch.6

For this directory I could use the value O=Turtle and that will restrict valid users to just those with a hierarchical name containing the Turtle organisation e.g Gabriella Davis/Turtle.  In a Domino directory, unique for LDAP sources, not all entries are hierarchical (groups names for instance are flat) so with this configuration WebSphere won’t recognise any Domino groups.  One option to workaround that is to use the value “root” for the Unique distinguished name which will tell WebSphere to recognise all organisations and even flat names or groups.


We also need to make sure the Group definitions are correct for the directory type we are using.  For Domino the attribute use for defining a group is called “dominoGroup” not the default “groupofNames” and the member attribute is called “member”.

Once the repository is configured we log out of the ISC and restart the deployment manager, then we log back in and go to Users and Groups – Manage Users / Manage Groups to confirm that all our LDAP users and groups are found and displayed.

If I can’t log back in after a restart I can rollback to the earlier backed up instance of the deployment manager and start over.


Now that the Federated Repository is set up the next thing we want to do is add additional accounts that can administer the ISC, including a LDAP account which will become the Connections Administrator.  Here we are using an account called “connadmin” that I created in the Domino directory.  Once the account is added we can test that it works by logging out of the ISC and attempting to login as “connadmin”.