Freitag, 28. Mai 2021

After Domino 11.0.1 FP3 - Kyrtool not starting - error 0x110

 I just recently tried to create a new Keyring from my Domino and received an error message...

 

 After asking the HCL support for details on the issue they told me with FP3 a new security feature was released. KB0090343 explains this new behaviour and its implication:

Subsequent Domino processes (e.g. nfixup.exe & kyrtool.exe) can not be run using another Windows account as the first Domino process. This means if you start kyrtool from command line as user "Administrator" & Domino starts as "SYSTEM" you will have to apply the workaround & add "Administrator" to the SMAclAccess.ini file.





Montag, 17. Mai 2021

HCL Connections MS Desktop Plugin - uploading files < 100mb with enabled IHS upload module

If you have configured file uploads through IBM HTTP server for your Connections envoirnment and the set the limit for simpleUploadAPI <100mb you will need to adjust the registry of your client: 

HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\IBM\Social Connectors\Settings - "LargeFileSize" must match the value that is set for "simpleUploadAPI" inside files-config.xml. But: by default only a value down to 25MB is allowed.

If you envoirnment requires IHS handling attachments < 25 mb you will need to ask for a customized MSDesktop Plugin @HCL. They will enable the plugin to be configured for smaller sizes.

CS0227039 for any case reference

Montag, 1. März 2021

TDI load_photos_from_ldap.bat is not importing photos from Domino LDAP

It had been a while(several years) since I was last asked to import profile pictures from a Domino NAB into Connections . The process & technology has not been changed since years and I felt pretty confident to deliver a solution very soon to my customer. But this was a BIG deception which started a long journey....

For testing purposes I imported a binary image into a custom LDAP field into my Domino NAB.
*This was mandatory in the past: RichtTextField with images are not binary images for LDAP clients and you needed a third party tool like "ldapadmin" to import images correctly. Since Domino V11 the NAB already contains a very handy binary-photo-field for this:


Taking a look into to the documentation the chapter only covers 2 steps:

1. Open profiles_tdi.properties, locate the load_photos_from_ldap_attr_name property, and set it to the name of the LDAP binary attribute that contains the photo.
2. Run the load_photos_from_ldap command...

As you may have already guessed: This did not work. It will just iterate over all profiles and do nothing.

So I create a case and HCL came to the conclusion that you manually need to populate a return list of the TDI process ("ldapReturnAttributes"). The workaround is described in KB0092095





     

Sonntag, 1. November 2020

HCL Connections Docs 2.0.1 installer fails on Windows - "can not create directory"

 I just recently started a new Connections envoirnment including Docs.
After performing the default Connections installation I prepared the Windows envoirnment for the Docs 2.0.1. After all network path & mounts were set I started the installation....
After some time the Installation Manager cancelled the installation "can not create directory K:". K: is the shared data drive for Docs-Editor component. To workaround the issue I just started installing 2.0 CR3 instead. This installation was successfull.

Afterwards I tried to reproduce the issue in my testing envoirnment on Windows: Same issue here. 2.0 CR3 installation works fine - 2.0.1 installer fails with error message "can not create directory". I opened a case @HCL and after several months they came to the following conclusion:

We discussed this issue in team again and per our communication with L3/Dev, the current installer behavior is a more proper logic as most of customers has few knowledge about CIFS.
We embed checking steps to help them build once and success all the time. If you have security concerns, you can configured CIFS with SYSTEM before the Docs installation. After installation, you can try to change CIFS mount user to the one you'd prefer. But make sure the user you choose has privilege to allow the user that running Docs program access CIFS. The info center documentation will be updated and we will clearly state that customer must configure CIFS with SYSTEM user, as we already have notes in place that the procedure of mounting the shares must be done by SYSTEM user. From current documentation you are correct, I also didn't see it is a "must". It only says, if customer wants to start CIFS automatically, it is a must.

 Lessons learned : always install Docs with Websphere running as "SYSTEM"

Montag, 6. November 2017

IBM Connections - side-by-side migration of Activities fails - table mismatch - OPNACT . OA_NODE

I had a few migration from 5.5 to 6.0 within the last weeks and I came accross the following error every time:

11/02/17 10:32:39.347 CET] Processing table -{ OA_NODE->OA_NODE }- 
11/02/17 10:32:39.347 CET] SELECT * FROM "ACTIVITIES"."OA_NODE" 
[11/02/17 10:32:39.722 CET] Transferring table --{ ACTIVITIES.OA_NODE} -- to table --{ACTIVITIES.OA_NODE }--
[11/02/17 10:32:39.957 CET] ERROR: Error validating data. The number of values is not equal to the number of columns in the destination table OA_NODE
 [11/02/17 10:32:39.957 CET] ERROR: The number of values is 38 while the number of columns is 37 
 [11/02/17 10:32:39.957 CET] error.executing.transfer com.ibm.wps.config.DatabaseTransferException: Column number mismatch
I was able to solve this error by just adding the missing table in the target database (DB2) with the following command:
  ALTER TABLE ACTIVITIES.OA_NODE ADD COLUMN OWNERMEMBERUUID CHAR(36) NULL;
ALTER TABLE ACTIVITIES.OA_NODE ALTER COLUMN OWNERMEMBERUUID DROP DEFAULT;
ALTER TABLE ACTIVITIES.OA_NODE ALTER COLUMN OWNERMEMBERUUID DROP NOT NULL;
ALTER TABLE ACTIVITIES.OA_NODE ALTER COLUMN OWNERMEMBERUUID SET DATA TYPE CHAR(36);
CALL SYSPROC.ADMIN_CMD( 'REORG TABLE ACTIVITIES.OA_NODE' ); 
I opened a PMR for this because I wanted to know what was causing this issue:
The table itself was no longer used in 5.5 which is why it was removed from the 5.5 createDB.sql and the upgrade-50CR1-55.sql script at some point.
But all "old" 5.0 envoirnments that were migrated to 5.5 still have this obsolete table.

To solve this problem you may also just delete the column and its index from the OA_node table in the source db. Thanks to David McCarthy from ICS Support IRL for this hint.


Regards,
Jan


Freitag, 24. Februar 2017

IBM Verse On Premise - problems with integration of IBM Connections Files



I just setup an testing envoirnment for Verse On Premise.
To get the full features I also tried to integrate IBM Connections which enables you to use business cards, photos & also let you use your Connections files for your mail correspondence.


After performing all required steps based on the official documentation it seems to be working fine:






 But when I tried to attach a file from IBM Connections I got the error message "service unavailable".
Checking the IHS access logs the following error is printed:

 [24/Feb/2017:10:00:55 +0100] "OPTIONS /files/basic/api/people/feed?self=true&xhr=1&sq=1 HTTP/1.1" 403 162
[24/Feb/2017:10:00:55 +0100] "OPTIONS /profiles/atom/profile.do?mcode=5b65e3542ff4be446f8cd1db987ac3df HTTP/1.1" 403 162

I tried to find a cause why the access should be "forbidden" but I couldn't find any indicator in theSysOut logs and also accessing the referenced URLs directly was working fine - so I asked Google for a solution.

Luckily I found this article from Roberto Boccadoro. He also had the same error and one of his buddies found a solution:
Instead of using the provided IHS configuration of IBM add the following lines to your configuration in the VirtualHost section:


RewriteEngine on

# Minor change to adjust for Cloud vs On-Premises API variation of parameter name
RewriteCond %{REQUEST_METHOD} PUT
RewriteCond %{QUERY_STRING} ^(.*)uid=(.*)
RewriteRule ^/profiles/photo.do /profiles/photo.do?%1userid=%2 [L]

# Added necessary CORS headers when Origin header present
Header unset Access-Control-Allow-Origin
SetEnvIf Origin "^https://(vop_server_hostname\.)?(domain_name)$" origin_is=$0
Header always set Access-Control-Allow-Origin %{origin_is}e env=origin_is
Header always set Access-Control-Allow-Credentials "true" env=origin_is
Header always set Access-Control-Allow-Headers "X-Requested-With, Content-Type, slug" env=origin_is
Header always set Access-Control-Allow-Methods "POST, GET, OPTIONS, DELETE, PUT" env=origin_is

Header always set Access-Control-Max-Age "1000" env=origin_is
Header always set Access-Control-Allow-Methods "POST, GET, OPTIONS, DELETE, PUT" env=origin_is
# Header always set Access-Control-Allow-Headers "X-Requested-With, Content-Type, Origin, Authorization, Accept, Client-Security-Token, Accept-Encoding, slug" env=origin_is
Header always set Access-Control-Allow-Headers "X-Requested-With, Cache-Control, Content-Language, Content-Type, Expires, Last-Modified, Pragma, slug, X-Update-Nonce" env=origin_is
Header always set Access-Control-Expose-Headers "Content-Disposition, Content-Encoding, Content-Length, Date, Transfer-Encoding, Vary, ETag, Set-Cookie, Location, Connection, X-UA-Compatible, X-LConn-Auth, X-LConn-UserId" env=origin_is

# Added a rewrite to respond with a 200 SUCCESS on every OPTIONS request.
RewriteCond %{REQUEST_METHOD} OPTIONS
RewriteRule .* - [R=200,L]

# Remove the Origin header if it exists for other requests (POST, GET, DELETE, PUT). Causes problems with Connections returning 403 response.
RequestHeader unset Origin env=origin_is

....I would have never expected a RewriteRule to be the workaround for a 403 error but now I finally got my envoirnment running 😌


Freitag, 30. Dezember 2016

IBM Connections 5.5 CR2 - CCM Upgrade does not complete " the deploy application task has one or more blank passwords "

This week I wanted to install CR2 in my test envoirnment.
IBM Connections upgrade worked perfectly but the CCM upgrade stopped working after around 20 minutes.
Checking the "fn-ce-update.log" actually showed the cause for the problem immediatly:


"C:\IBM\Connections\FileNet\ContentEngine\tools\configure\configmgr_cl" execute -task deployapplication -profile CCM
The Deploy Application task has one or more blank passwords:
Application server administrator password

Do you want to specify these passwords now (passwords will not be saved to disk and will only be used to run the task) (yes/no)? [no]

Wait, what?  I didn't provide this information....
 
Searching on the web, Google directed me to the blog of Nico Meisenzahl . He provided a easy solution for this problem:

  • navigate to \FileNet\ContentEngine\tools\configure\profiles\CCM\
  • edit "applicationserver.xml"
    • look for <property name="ApplicationServerAdminPassword">

    • and set the right value for the property -  <value>MYADMINPW</value> 
 You will also have to do this for the CEClient-script (\FNCS\configure\profiles\CCM\applicationserver.xml) if you are performing a update/rollback for this component.

During updates I am always using "baretail" to check the progress of the upgrades. This may spare you much time. Otherwise you will wait more than 1 hour and nothing further will happen.


Hope this will help you.


Happy New Year !

Jan