I have been working with a customer who is migrating to Connections 5.5 from Connections 5.0. When I do a migration I like to do it properly and create clean data by using dbt.jar to migrate content to new databases. I know a lot of people are happy with the backup/restore of databases idea but for me that leaves too much scope for bad data to carry over from old system to new.
Everything was going fine, the profiles data migrated and then I tried a sync all dns to sync the ldap data to the database. Something we schedule daily at this customer. It failed as it tried to hash the database tables. The error in the ibmdi.log was
Error: The sort page size property – source_ldap_sort_page_size= – must be greater than 10 if it is not 0. Aborting.
That’s a value that is set in profiles_tdi.properties and it was already set to 0. So why was it aborting?
I decided to troubleshoot just with a cutdown list of names in collect.dns and using populate_from_dn_file function. Again it failed but with the strangest error that would find the user in LDAP, get all their values then fail to find the user in the database and fail to update.
In SyncUpdates.log I could see the following error no matter what user I chose for populate_from_dn_file.
ERROR [com.ibm.di.log.FileRollerAppender.bc9c35a0-aae5-416e-9a99-1d418c3c564c] – [callSyncDB_mod] [ProfileConnector] null
I then tried copying the collect.dns to my 5.0 production environment and running there and it worked fine, found the users as duplicates and didn’t update them which is the correct behaviour.
I compared the map_dbrepos_from_source.properties files in 5.0 with 5.5 and it all looked pretty much the same. So I opened a PMR which was eventually escalated to development. As soon as they received it they knew what the problem was – apparently a known but not documented bug that was fixed in CR1 with files that you have to manually deploy (we were already at CR1).
Development’s report of the problem was
in log4j.properties causes TDI populate and sync commands to crash if an
EMPLOYEE is altered
Well the crashing was true but the value log4j.logger.com.ibm.lconn.profiles.internal.service=ALL was # out and unused so it wasn’t related to that particular log setting in my case.
The fix was to go find the two files
in the Connections install and copy them to your TDI\lib directory in your tdisol environment. In my case I had created a folder called TDISOL55 and under that I had a TDI directory with all the properties, script etc files in and the lib subdirectory full of jar files. That came from the D1 (day 1) release download of Wizards which contained updated TDIPopulation directory and was dated 18th Dec. There was no new tdisol with CR1 but clearly there should have been.
I found the files in my Websphere Application profile directory for the profiles application server under the directory
I copied those two files over and it al-most worked. I had one more problem. The value source_ldap_sort_attribute in profiles_tdi.properties which was initially set to empty (not null but = ) had been changed at the request of L2 to source_ldap_sort_attribute=mail which matched the 5.0 properties we were using. They asked me to change it for exact comparison and that broke the updates. Once I took out the “mail” mapping the scripts, both populate_from_dn_file and sync_all_dns ran perfectly.
The new environment does use different LDAP servers (but the same source data) and I don’t know if attempting to tell the server to sort the LDAP results failing is a problem with that server configuration (both environments are Domino 9.0.1) or 5.5 itself. I’ll investigate that and update.
So my two fixes were
- copy the two jar files from your CR1 installedapps directory to your TDISol directory (lib subdirectory).
- make sure source_ldap_sort_attribute= in profiles_tdi.properties
Thanks for sharing. My TDI config. didn’t crash but the end line stated that it failed on all entries. ( Upgrade from IC50CR3 -> IC55CR1, LDAP=AD )
CLFRN0037I: After synchronization, added or modified records is 0, deleted or in activated records is 0, unchanged records 0, and failure records is 92.
release sync lock
After updating the two JAR files it showed a correct result
CLFRN0037I: After synchronization, added or modified records is 0, deleted or in activated records is 0, unchanged records 92, and failure records is 0.
release sync lock
Glad that helped you too 🙂