Random thoughts from an unusual company

ST Connections and Domino LDAP Not Playing Well Together

Gabriella Davis  22 January 2013 00:58:01
An interesting problem I wanted to write up here.  A customer is using Domino LDAP serving both Sametime and Connections (currently 3.0.1).  For Sametime I always configure the LDAP settings in the Global Configuration document to require a minimum of 3 characters before a wildcard search.  It's a performance setting that prevents LDAP being overloaded in large Sametime environments and it works well.  

Then we look at the Connections install and the TDI scripts that can be scheduled to run nightly to sync profiles to Domino.  There are two scripts, collect_dns and sync_all_dns.  Collect_dns does a search of your LDAP environment (as defined in your profiles_tdi.properties file).  It creates a text file called collect.dns with one line per user entry that matches your LDAP search and then sync_all_dns uses that file for part of its sync.  Unfortunately the collect.dns file was empty and in the logs directory ibmdi.log file had an error

CTGDJQ107W The selectEntries method was unable to perform the search. Exception occurred

By turning on LDAPDebug on the Domino console I quickly saw that the problem was the script in collect_dns.bat trying to do a full wildcard search against Domino LDAP.  The search criteria in the profiles_tdi file was (&(uid=*)(objectclass=*)) instead of the usual (&(uid=*)(objectclass=inetOrgPerson)).  Domino saw that as a wildcard search and since it didn't have at least 3 characters specified, Domino refused the connection.  To get the collect_dns.bat file to work I had to either remove the wildcard restriction I'd put in place for Sametime or modify the search definition.

So.. lessons learnt.   Yes I could use TDI assemblylines instead of scripts but where possible I prefer the stability and control (I do love that word) of scheduled script runs. It was a simple enough fix once I found the root of the problem but I can see it happening again.  The key here is that the collect_dns.bat file was triggering correctly but then failing so early on it was never writing the collect.dns file so the last successful instance of the file was being used each night and it was some time before the problem was even noticed.  If you're scheduling nightly tasks for Connections updates, keep an eye on the date/time stamps on the collect.dns and employee.adds employee.updates etc files that are created.