Domino 9.0.1 FP4 Crashes With HTTP On Linux and AIX

I discovered this on a customer site this weekend.  Their servers are running SLES Linux 64bit and already had Domino 9.0.1 FP2 on them.  I upgraded to  FP4 but only one of the clustered mail servers runs iNotes – that server kept crashing as soon as someone tried to access their mail.  The other server was stable and if I disabled HTTP the crashing server stayed up.

Turns out the IBM installer for FP4 on Linux and AIX is setting the ownership of the dojo folder incorrectly which causes the crash.  The dojo folder is under <notesdatadirectory>/domino/js and the ownership was set to invalid names.  From the js directory (which just has the dojo folder in it) I ran

chown notes:notes * -R

which told Linux to change the ownership of the dojo folder and everything beneath to the account / group used to run Domino.

There is a technote dated 28th August that i’ll post here but the fix on the technote is incorrect.  On their fix they say the permissions are wrong and need changing to 755 using chmod but that’s not true, they are already 755 in my installs but the actual ownership is wrong.  Maybe they’ll fix the technote but the background is here http://www-01.ibm.com/support/docview.wss?uid=swg21964549

IBM Connections Mobile – Issues On Android

This is one of those posts that scare me – I’m fairly sure someone else must have seen and blogged this but since I can’t find anything I am writing this up.

I recently did a Connections 5 install for a customer, it was a clean install on clean hardware.  We did migrate the data but not the artifacts (the lc-export function) because we wanted to have clean XML and configuration files. Once installed the mobile application worked perfectly on iOS but on Android there were no applications listed when you logged into the mobile application.  Since the configuration for mobile isn’t OS specific (or isn’t documented as being so) I assumed the mobile-config.xml was correct as it worked for iOS.  So the customer went ahead an opened a PMR, the response from IBM was

“Your Connections engineer missed a step in migrating the mobile application”

Well that’s strange because this wasn’t a migration and if I look at the migration documentation in the IBM Knowledge Centre there’s no mention of any tasks related to mobile-config.xml.  A follow up IBM email said we had a missing “NavigationGroups” section so I check the mobile-config.xml.  The section is there but with no real entries in the default version

<NavigationGroups>
<NavigationGroup name=”Favorites”>
<Expanded>false</Expanded>
<HideNavGroup>false</HideNavGroup>
</NavigationGroup>
<NavigationGroup name=”Updates”>
<Expanded>true</Expanded>
</NavigationGroup>
<NavigationGroup name=”Applications”>
<Expanded>true</Expanded>
</NavigationGroup>
</NavigationGroups>
<NavigationGroups>

The only document on the knowledge base that has the words “NavigationGroups” in it is the one that talks about extensibility of the Mobile app – here.  So OK, I take the example from there and attempt to modify my mobile-config.xml but on checking it back in using MobileConfigService.checkInConfig it returns an invalid XML error.  Looking at the IBM example it seems their XML structure is wrong.  If you are going to have an ApplicationList node entry then it MUST come after the Expanded and HideNavGroup entries.

The IBM suggested content is below – this fails

The ApplicationList node entry before the Expanded node entry is invalid XML structure

The ApplicationList node entry before the Expanded node entry is invalid XML structure

The final correct format I used is

<NavigationGroups>
<NavigationGroup name =”Favorites”>
<Expanded>false</Expanded>
<HideNavGroup>false</HideNavGroup>
<ApplicationsList>communities,wikis,activities</ApplicationsList>
</NavigationGroup>
<NavigationGroup name = “Updates”>
<Expanded>true</Expanded>
<HideNavGroup>true</HideNavGroup>
</NavigationGroup>
<NavigationGroup name = “Applications”>
<Expanded>true</Expanded>
<HideNavGroup>false</HideNavGroup>
<ApplicationsList>profiles,communities,files,wikis,activities,forums,blogs,bookmarks</ApplicationsList>
</NavigationGroup>
</NavigationGroups>

I am still awaiting more testing but it does seem from IBM’s response that the Android OS requires this section to be completed in a way that the iOS OS doesn’t.  It’s not part of the migration documentation though

Domino LDAP And A Failure To Authenticate

Bear with me and try not to shout at the screen “we all know that” – this blog is about the 10 hrs I lost yesterday troubleshooting a problem I distinctly remembering seeing before and realising, once I solved it, that last time it had also taken me hours and ended up being the same issue.  In my defence the last time I had this problem it was with Quickr so that’s a throwback and even if this blog isn’t news to you, it will hopefully be there for me in another 5 years…

I was using Domino as a LDAP source for Connections.  I don’t manage the Domino side of things for this customer so I had just asked them to add a secondary directory (in this case for External users) to Directory Assistance on their LDAP servers. I wanted the DA document set to be LDAP only rather than LDAP & Notes / Internet Authentication**. They did that and I tried to login from Connections to discover that I could login as a user in names.nsf but not as a user in the secondary directory. Time to look at the configuration.  Here’s what I did

1. Confirmed the DA document looked OK.  It actually wasn’t set to trust for credentials so I enabled that.
No luck.

2. Tried “sh xdir” to verify the directory was listed. It was, as Directory #4 out of 6.  Tried sh xdir reload to refresh Directory Assistance and then tried restarting the server
No luck but at least I knew DA was configured correctly

3. Turned on LDAPDebug=3 so I could see the debug information. At this point I could see the failing accounts (any in the secondary directory) were coming up with “authentication failure using internet password” in Domino and in the SystemOut.log of the WAS server that hosts the homepage application I saw references to PasswordFailedCheckException behind CWWIM4529E and SECJ0369E errors. Password failed? That made no sense at all.   One thing that was an issue was that the server I was working on was being probed every few seconds by a remote machine for availability on LDAP so with debug turned on the screen was filling up with thousands of lines of content making it difficult to see and track my own issues.  In retrospect if I’d asked for that to be disabled it would have saved me hours.

4. I then took a step back and installed Softerra’s LDAP Browser so I could test things outside of Connections.  I could bind using any credential in names.nsf but when trying to bind using a credential in the secondary directory I got “invalid credentials” and LDAP wouldn’t bind.

5. I then cut and paste a person document from the secondary directory to names.nsf to verify if the issue was the directory itself or the format of the person documents. I knew those documents worked fine on another server where they were in the names.nsf.  Turns out that if I moved them to names.nsf they worked fine.  I could bind with Softerra and I could login with Connections.

hmmm

6. I go back and check the ACLs of both names.nsf and the secondary directory.  I may even have bumped up default to something stupidly high *cough*Editor*cough* for 30 seconds to rule that out.
No luck

7. I paste the person document back into names.nsf again and bind with Softerra. This time I try and search for a name I know is in both the names.nsf and secondary directory (not the same name, just the same lastname).  Interestingly I get access denied / unauthorised – it finds the two entries but doesn’t let me see the content of them.  The fact that it found the entries meant that it could search LDAP but it can’t display them?  Surely that’s ACL issues.  So back I go to check the -default- rights on both directories and even test effective access for the specific account i’m using.  Nothing.

Then I see it.  As I try searching and searching and trying to catch errors on the server logs amongst the mass of LDAP debug information.. I see
searching directory names.nsf for sn=davis
searching directory directories\custnames.nsf for sn=davis
search directory directories\morenames.nsf for sn=davis unauthorised, skipping
search directory directories\externalnames.nsf for sn=davis
search directory directories\suppliers.nsf for sn=davis

Right there – in the middle. A directory I don’t care about, that has two dummy documents in it but happens to be part of Directory Assistance.  I go look at yes – -Default- is set to No Access. I change that to “Reader” and ta-da! suddenly I can both bind and login.  Then I remember I had this exact problem before at another customer with many directories that I didn’t set up or configure and it took me forever to find because I simply don’t touch what I’m not meant to be managing. In this case a directory that’s nothing to do with me and isn’t being used by my application on a server I don’t manage.

So what happened? It appears that Domino LDAP will search multiple directories but once it comes across one it can’t access with those bind credentials it doesn’t skip over it.. it stops.  The “skipping” isn’t strictly true.  So when the credentials were in directories one or two they worked. in directories four or five they failed because it stopped at directory three.

My lessons are
1. Remove as much extraneous activity as you can or you won’t be able to debug quickly enough
2. Always check everything (or in my case ask permission to check everything) even if it looks unrelated and especially if you didn’t set it up yourself 🙂

You’re welcome Gab of the future….

**Added on this morning.  Using LDAP only for authentication doesn’t work because a Directory Assistance document set to LDAP only doesn’t actually work for anything but LDAP searching. Not for authentication at all.  Foolish me for trying to be logical.  Here’s what the pop up help says – and they’re right. I tested it :-)]

DirectoryAssistance

The IBM Docs Dilemma

IBM Docs is a really nice add on to IBM Connections, what’s more it’s not particularly hard to install.  It does have one requirement, a big one, a show stopping one, a requirement that prevented my customer build from working for about four weeks until IBM and I came up with an agreement for how it could work.  Hopefully this will help you fast forward through that four weeks yourself ..

IBM Docs Infrastructure – The Simple Version

IBM Docs has four component WebSphere servers with applications stored on each

IBM Docs Servers

The servers also need access to three data shares; the standard Connections share, a new share for IBM Docs data and a new share for IBM Docs Viewer.  I created the two new shared on the Linux server that currently hosted the CIFS Connections share and installed Samba to enable a Windows server to access them.

I had one problem where it consistently failed during install if I didn’t use capital letters for the mapped drives.  It didn’t refuse to accept lower case letters, it just failed the install.  If your install fails make sure you aren’t using lower case letters.

Challenges

The key requirement for IBM Docs to actually work is that

1. The shares must use mapped drive letters and those drives letters must exist prior to the IBM Docs elements being started

2. The IBM recommendation for achieving this is to create a batch file on the IBM Docs OS (which must be partially if not wholly Windows) to do the drive mapping and have that load in Windows task scheduler on startup.

3. The WAS servers must then be run as services not using a system account but using a named Windows account that matches the one assigned to run the batch file in task scheduler

This solution had two problems, I hated it, and it didn’t work.

I hated this idea because my customer doesn’t run AD at all and their share was a samba share on a Linux box using CIFS.  That means there is no account that can be used to start the services that can also be used to map the drives. There is no easy way to have Windows pass credentials to mount the shares without storing both the name and password that samba recognises in the batch file – like this

net use m: \\hubshared\ibmdocsdata sambapassword /user:sambaaccount
net use n: \\hubshared\ibmdocsview sambapassword /user:sambaaccount
net use l: \\hubshared\conntestshare sambapassword /user:sambaaccount

Unfortunately after several weeks of different ideas from L3 support we admitted defeat to allow me to move on with the install.  I have minimised risk by ensuring the account isn’t a linux account and only has access to the samba shares.

The second part of the solution is the assumption that if you map the drives through task scheduler owned by a Windows user and that same Windows user starts the WAS services – the WAS services will be able to see the mapped drives.  To everyone’s disappointment that absolutely didn’t work because Microsoft kindly mapped the drives from the batch file in a different session to the one where it started the WAS services.  The servers couldn’t see the mapped drives.

So the install was simple but getting everything running securely and without the customer having to manually do anything held us up for weeks.  In the end I opted for a solution where I created a batch file to both map the drives and then start the WAS servers in a scheduled startup script.  That worked beautifully and this is what it looks like

net use m: \\hubshared\ibmdocsdata sambapassword /user:sambaaccount
net use n: \\hubshared\ibmdocsview sambapassword /user:sambaaccount
net use l: \\hubshared\conntestshare sambapassword /user:sambaaccount

Call “c:\IBM\WebSphere\AppServer\profiles\IBMDocs\bin\startnode”
Call “c:\IBM\WebSphere\AppServer\profiles\IBMConversion\bin\startnode”
Call “c:\IBM\WebSphere\AppServer\profiles\IBMViewer\bin\startnode”
Call “c:\IBM\WebSphere\AppServer\profiles\IBMDocsProxy\bin\startnode”

As you can see I only start the nodeagents. The servers themselves and the applications on them are bootstrapped to the start of those. To do that modify the server’s monitoring policy which is found under Java and Process Management for each server

Monitoring

Then set the “Node Restart State” to “RUNNING”

bootstrap nodeagents

Configuring Domino for SPNEGO

I was recently asked to put together a live demonstration for a customer on how they could use SPNEGO to access their web based Domino applications. To do that I opted to build a lab environment consisting of a Windows domain controller, a Windows based Domino server and a Windows 7 workstation so I could have a clean environment to present with.

Here is a modified copy of that presentation which will hopefully help you configure SPNEGO in your own environment.

Thank you to Sean Cull at Focul for clearing this presentation so I could share it.

If enough people are interested I would consider doing a webcast of this with a demo against my lab environment.

Creating SHA-2 4096 SSL Certificates for Domino

I’ve been doing a lot of work recently re-creating SSL certificates for customers who have SHA-1 or who want stronger certificates, mostly because so many sites are now failing validation in standard browsers because of SHA-1.  IBM have published several pieces of documentation on how to do this but I wanted to share my bullet list on the quickest and simplest way I have found .  It’s not hard there are just lots of new steps.

Firstly you need to know that SHA-2 support only really started with 9.0.1 FP3.  That means the Domino Admin client you are going to use to do this work must be at that level (yes there are hotfixes for FP2 but go with the latest Fix Pack on your client).

You also need to know that NO Domino 8.5x server will be able to use the keyfile you create, it simply doesn’t have the cryptographic understanding to decode SHA-2.

Finally if you use the CA process to generate internet certificates you will need to upgrade the server running that process to 9.0.1 FP3 too.

Oh and you’re also not going to be using the Domino Server Certificate database to do this at all.

  1. Download 9.0.1 and FP3 for Domino Administrator and upgrade your client. Fix pack 3 is in Fix Central and 9.0.1 is on the IBM download site (CIQ91EN)
  2. Download the latest “lite” version of OpenSSL from here and install it on your Windows machine where you have Domino Administrator running.  I installed it in c:\openssl for example
  3. Download the kyrtool from here and copy the executable to your Notes program directory
  4. Set the environment variable for OpenSSL by typing in a command prompt
    Set OpenSSL_Conf=c:\openssl\bin\openssl.cfg (or whatever your path is)
  5. Now we create our keypair using OpenSSL.  From C:\OpenSSL\bin directory type
    “openssl genrsa -out server.key 4096”
    obviously you can use any name if you don’t want to use server.key and you don’t have to create a 4096 strength keypair.  When finished you should have a file in that directory called server.key
  6. Now you have your keypair you need to create a CSR to send to the certificate authority
    openssl req -new -sha256 -key server.key -out server.csr
    the server.key name must match what you created in step 5 so if you used a different name there you need to use that name here. Similarly your server.csr filename can be anything you like.  When you enter this command be prepared to answer all the questions about the certificate you want generated including the common name etc.  The CSR this generates will be uploaded to your CA (Verisign, GoDaddy, Thawte, whoever) and your SSL certificate created based on the answers you give to those questions.
  7. Now we need to create a keyring file ready to add to certificate into when the CA sends it back.  Go to your Notes program directory and run the kyrtool
    kyrtool  create -k c:\notes\data\keyring.kyr -p <passwordyouwanttouse>
    again the keyring.kyr file can be called anything you like.  Once run you should have both a keyring.kyr and keyring.sth files in your data directory
  8. By now your CA should have sent you your certificate as well as some trusted and intermediate root certificates for their issuer.  We are going to create a single text file that contains the server.key we generated in step 5, the SSL certificate the CA just sent us (usually a .crt or .pem file) and any intermediate or root certificates the CA needs us to use.  Doing this is very simple.  Go to your c:\openssl\bin directory (the one where your server.key file was created) and enter
    type server.key server.crt intermediate.crt root.crt >server.txt
    note all the filenames will be specific to whatever you were sent by your CA.  If you were sent a single bundle then you would use server.key bundlename.crt for instance
  9. To verify your server.txt is created successfully your can validate it using the kyrtool.  Go back to your c:\notes program directory and type
    kyrtool verify <path to server.txt>
  10. Now we import our server.txt will all the certificates into our newly created keyring file we created in step 7
    kyrtool import all -k c:\notes\data\keyring.kyr -i c:\openssl\bin\server.txt
    again your filenames and paths may vary depending on what you chose

And that’s it.  You now have a keyring (kyr) file and stashed password file (sth) you can copy to you Domino 9.x servers and use.  If you want to validate the keys are correctly in the file then you can again use the kyrtool

kyrtool show keys -k c:\notes\data\keyring.kyr  AND

kyrtool show certs -k c:\notes\data\keyring.kyr

IBM’s documentation on the process and the supported platforms is here and here

The Recurring WebSphere Bug And Connections External Users

I wanted to share a recurring WebSphere bug that I noticed over a year ago because although it was irritating then, if it occurs now it can actually prevent you from deploying Connections external users the way you want.

Here’s the scenario (and it’s fairly common for me).

IBM Connections 5 CR2 on WebSphere 8.5.5 FP3

Primary LDAP is a Domino server

Secondary LDAP for external users is a separate Domino server in an isolated domain

When we want external users to access our Connections environment, the most secure approach is to have a dedicated LDAP server or branch for external users to appear in.  Especially if (as we do) you have a self registration / password reset process for those users.  The problem occurs because we want to use Domino as our LDAP.  LDAP servers other than Domino are built with hierarchical entries so on the WebSphere configuration screen where we are asked for the “unique distinguished name of base entries” that’s very easy, we just select the top level of the hierarchy.  Unfortunately in Domino LDAP we don’t always have a hierarchy – we have flat names and we have flat groups so if we try and use a O= xx value – those names and groups aren’t picked up.

We used to use C=US which would trick WebSphere into querying a level above O= and that would work but since WebSphere 7.0.0.23 we have been using the word “root” which validates both flat names and all hierarchies on the server.

So far so great.

Now we want to add another LDAP server which will be a Domino server where people will register.  We’ll have two TDI processes one connecting to the internal Domino server for internal users and another to the external Domino server for external user access.  It’s Domino so we want to use “root” as our base entry but since WebSphere requires all federated repositories to have unique base entries and since we already use “root” for our internal server, I have to fake a hierarchy for external users just so I can add the 2nd LDAP.  It’s ugly but not unworkable.  It’s also not our problem.

BaseEntries

 

The problem is that once I add the second Domino server or even a third.  My federated repositories in WebSphere look like this

repositories

Can you see what’s wrong?  That table reads from the underlying wimconfig.xml file found under the Deployment Manager profile /config/cells/<cellname>/wim/config.  That wimconfig.xml is fine which is why if I click on Manage Repositories they are all there.  I just can’t edit them from this screen, I can only edit from the previous screen and that one links to the last LDAP entry I added.

managerepositories

So that’s part of our problem.  It’s been there for a few years but since we could manually edit the wimconfig.xml to overwrite settings it was workable.  This is caused by the “root” base entry on the first LDAP.  That word “root” translates to an empty baseentries name= value in wimconfig.

Here’s the internal LDAP with baseEntries name=””

wimconfigroot

Here’s the external LDAP where I have defined a base entry of o=turtlehost

wimconfigexternal

 

The additional side effect of this bug (and I’m not sure we can call it a WebSphere bug since expecting hierarchical LDAP is a fairly standard thing) is that in the latest version of WebSphere, it refused to search the second external directory.  No error. Nothing.  Just refused to search it which meant those users couldn’t login.

I edited wimconfig.xml and added a O=Turtle to replace the baseentries name=”” etc and that fixed both the WebSphere view and the ability of users to login.

So where does that leave us.  Well it’s a problem because I want to use Domino. I don’t want to have to force a single hierarchy.  C=xx doesn’t work anymore to trick WebSphere.  “root” breaks both WebSphere and authentication.  That means I can’t have a secondary Domino server for external users and still use a “root” base entry for the internal server.  Without that “root” value, the flat Domino groups will be ignored.

That leaves me with a few options

1. Force a fake hierarchy on groups so I can have a base entry value that works and not use root

2. Use Directory Assistance and “root” but that allows external users to authenticate against my internal directory.  I don’t like that

3. Use an LDAP attribute to separate external from internal users instead of a dedicated LDAP server.  For security reasons i’m no fan of that either

4. Don’t use Domino for both LDAPs, only for one of them.  One “root” defined Domino server will work fine

 

Upgrading Filenet – Something To Watch Out For

Last night I was working on a Connections CR2 upgrade that included upgrading Filenet.    I was using this very nice piece of documentation from IBM on a lab walkthrough of upgrading to CR2 here .  To date my biggest problem with FileNet has been finding all the files needed and that’s especially true of the CR2 update files but I got there.  What tripped me up was upgrading the CE Client and FNCS (section 3.4.5 on the document).  The sample command is

update-fncs-ceclient.bat -was.dm.path “C:\IBM\WebSphere\AppServer\profiles\Dmgr01” – was.admin.user wasadmin -was.admin.password Passw0rd -fncs.fp.installer.location “c:\Downloads\FNCR2\IBM_CONTENT_NAVIGATOR-2.0.3.2-FP002- WIN.exe” -doInstallFNCS y -ceclient.fp.installer.location “C:Downloads\FNCR2\Filenet cr2\5.2.1-P8CPE-CLIENT-WIN.EXE” – doInstallCEClient y

The problem is that this script ran for about 6 minutes then bombed out.  I checked the fn-fncs-ceclient-update.log file in c:\ibm\connections\ccm\ccm\ccm\scripts (where the script is run from) and it showed a failure to make a SOAP connection (after it had already successfully made one earlier in the script).  I then checked wsadmin.traceout in the Dmgr profile under logs and saw references to “WASX7198W websphere The configuration service is not running” and other failures logging in like “empty credentials”.

OK so the problem was my login credentials used in the script for admin account and password right? Wrong.  Because that works fine earlier in the script. In fact the first thing it does is make a SOAP connection to the Dmgr server.  OK.  So the problem is that my password for the admin account contained a ! – we all know that WAS doesn’t like encoding and decoding special characters right?  Wrong. I tried another account, and another,  I tried wasadmin but that failed (and I wondered if that was because it was a FileNet update and FileNet wants an LDAP account).  At this point i’m bouncing between accounts trying to get this working.  I get the customer to remove the ! and give me a password with no special characters.  Still no luck.

Then I think a bit more.  What if the script isn’t using the values I gave it to run but instead is assuming they are already there in soap.client.props and is attempting to read them from that file. I go to check soap.client.props under Dmgr\properties and there is no value stored there at all.  I add my admin credentials in there and the script runs perfectly.

Today’s lesson is don’t assume a script you are running is using the credentials you give it!

 

Searching For The Elusive 5.2.0-P8CE-WIN.EXE

In this month’s adventures of Connections installs I offer you my search for a required Filenet installer.  If you’re installing CCM there are 4 files you need to have in a directory for the Connections install to complete – from the install instructions here and shown below .  I’ve done this lots of times and you basically put the executables together in one directory you can point to during the Connections install.

Filenet Install Files

However with CR2 came a requirement to update the installers see here and below

CR2 Requirements

Notice the difference?  CR2 doesn’t list the 5.2.0-P8CE-WIN (LINUX, AIX , ZLINUX) file at all as a required update.  That means that all the other files are in Fixcentral but not that one.  So I want the latest file and I don’t know if there’s a newer one.  I go to Fix Central and search for 5.2.0-P8CE and get offered the 5.2.0.3-P8CP8 files.  I try to search for a download list for IBM Connections Content Manager but it doesn’t exist (I like the download lists because they often have the latest part numbers).  There is one for IBM Connections but that doesn’t include any of the FileNet components.

Off I go to Partnerworld where I type in IBM Connections Content Manager and I get an eAssembly to go through including the file FN_CE_5.2.1_WINDOWS_ML which sounded hopeful but I already had that and it contains the following. Note 5.2.1-P8CPE-WIN not P8CE.  The 5.2.0 files were no longer showing on Partnerworld under Connections Content Manager

FN_CE_5.2.1_WINDOWS_ML

 

Luckily I’m a paranoid control freak and have backups of all the installers myself and there I found the original FN_CE_5.2_WINDOWS_ML file which, when download and extracted had the correct 5.2.0-P8CE-WIN file in it.  The one the Connections installer wanted and refused to progress without.

FN_CE_5.2.1_WINDOWS_ML

 

The sizes of the zip files should have made me suspicious.  It does look like the 5.2.1 zip file in partnerworld has the wrong content (possibly because there isn’t a 5.2.1 for P8CE only for P8CPE) and i’m not the only one who goes cross eyed staring at P8CE vs P8CPE.   Or maybe I’ve been staring at this too long. Either way thanks to my backup I’m sorted now.

Zip File Sizes

Adding DB2 Datasources Using db2cli

I recently blogged about Advanced Query Tool which I have started using on my VMs instead of one of the heavyweight IBM DB2 client tools.  AQT is a lightweight client that allows me to examine the databases easily but it works by reading in the datasources defined in Windows in the ODBC Manager.  To create datasources you must have some kind of DB2 client or driver installed.  I installed the minimal drivers which gives me this

Screen Shot 2015-03-23 at 11.18.05

Selecting ‘Configure DB2 .Net Data Provider” calls up a GUI interface that walks you through setting up a datasource.  To find the ODBC Manager under Windows 7 or 8 go to Control Panel and click on System and Security then click on Administrative Tools.

Screen Shot 2015-03-23 at 11.20.14

Each driver is configured to connect to a specific server and port.  The configuration is stored in db2cli.ini and db2dsdriver.cfg.  But what if you want to change the server or port address for a datasource.  Or in my case, add multiple datasources pointing to different servers?  Well you could try running the GUI tool again but that decision was made for me when Windows 7 decided to stop running the file and I decided I preferred to have more visibility / control of the configuration.  So instead I chose to use the command line to change and create new datasources.

Open an administrative command prompt and go to the DB2 client install directory (in my case c:\IBM\SQLLIB) and run

db2cli writecfg add -dsn PEOPLEDB_SA -database PEOPLEDB -host db2.turtlehost.net -port 50000

That writes a new datasource called PEOPLEDB_SA (you can call it what you want so long as it’s unique) that is connecting to a database called PEOPLEDB on server db2.turtlehost.net port 50000.  You don’t need to be able to connect to the database when you run the db2cli – it doesn’t validate or test at this point.

Now we need to add this newly created DSN to the Windows registry by running

db2cli registerdsn -add -alldsn

When you’re all done you need to restart Windows for the new registry to be read by AQT and you can go ahead and test the connection and use AQT to connect to the database by choosing the PEOPLE_SA datasource.

AQT Menu