After installing the usual client security updates on my Microsoft Windows Client Virtual Machine I was suddenly no longer able to connect to the customers Windows Servers. First, I had suspected a server security update shutting out my VM (which would have been understandable). But further investigation pointed to a client issue. Especially the specific error message (if you read it *ahem*) helps:

An authentication error has occurred.
The function requested is not supported.
Remote computer:
This could be due to CredSSP encryption oracle remediation.
For more information, see

So if you read upon that link, it appears that a Windows Update on my client installed and activated the CredSSP fix for CVE-2018-0886 in "Force Updated Clients" mode which hindered me to connect to the unpached (*ahem*) servers.

In order to "fix" my access problem, I had to modify the behaviour of the client fix via this command line:
reg add "HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System\CredSSP\Parameters" /f /v AllowEncryptionOracle /t REG_DWORD /d 2

/via Remote desktop connection error after updating Windows 2018/05/08 - CredSSP updates for CVE-2018-0886 - Super User


Back to top

To activate the new Newsletter design in Connections 6.0 to CR4, you’ll first need to update the notification config.

In the properties section of the notification-config.xml you have to add the following line:

<!-- New notification design -->
<property name="globalNotificationTemplateTheme>notifications_v2</property>

Via Martti Garden.


Back to top

Although every communication is (rightfully) moving to TLS, the cleartext tool "telnet" is still quite handy on a Windows based server to check if a port is open and/or basic network connectivity is working. Unfortunately, the telnet client (NOT the server) is no longer part of a Windows default install.

To install the telnet client (NEVER install the server), you could either click through the GUI (Server Manager -> Add roles and features -> ..) or you could use the fast way via the command line:

Enabling the telnet client through command prompt

dism /online /Enable-Feature /FeatureName:TelnetClient

Enabling the telnet client through PowerShell

Install-WindowsFeature -name Telnet-Client

And now a simple
telnet localhost 80
just works :D.


Back to top

 Usually, the filter for syncing LDAP users into IBM Connections using the Tivoli Directory Integrator (TDI) looks something like this:


If you are using Microsofts Active Directory (AD), this also syncs users that are "disabled" in AD, which is usually not what you want.
Fortunately, there is a Microsoft Knowledgebase entry called "How to query Active Directory by using a bitwise filter" that sheds some light on this:
An example is when you want to query Active Directory for user class objects that are disabled. The attribute that holds this information is the userAccountControl attribute. This attribute is composed of a combination of different flags. The flag for setting the object that you want to disable is UF_ACCOUNTDISABLE, which has a value of 0x02 (2 decimal). The bitwise comparison filter that specifies userAccountControl with the UF_ACCOUNTDISABLED bit set would resemble this:

So all we habe to do is to incorporate this attribute into our filter statement (of course negated), to only sync "active" users:


Back to top

In my current project, we had the issue that the logs were flooded with CWWIM4564I warnings like the one below

[10/1/18 18:36:21:401 CEST] 00000443 LdapConnectio I getDirContext CWWIM4564I  The user registry is now connected to 'ldaps://' LDAP Server. Or, the user registry is able to ping the LDAP server successfully.

and the ISC was very unresponsive when switching to the list of servers or the list of nodes (in an environment with 59 application servers on 13 different nodes).
Even with the workaround found by Dave Hay​, the warnings were flooding the logs (but only for the secondary Active Directory LDAP, the IBM Domino LDAP just worked).

What we did was twofold. As the context pool for the Domino based repository was already enabled, we also activated the context pool for the Active Directory repository, which cut down the number of CWWIM4564I warnings dramatically.

In addition to that, we also followed the steps Martijn de Jong outlined in his blog entry. As the transport memory size was already set to 200 and the IBM_CS_WIRE_FORMAT_VERSION was also already set to 6.1.0, we just had to add the IBM_CS_HAM_PROTOCOL_VERSION custom coregroup property with a value of

With those two changes and a reboot, we experienced a dramatic increase in performance when using the ISC and the logs were a lot easier to read without the CWWIM4564I warnings.


Back to top

If you enable round-trip editing for files according to the IBM Connections documentation (I have no idea, why this is still not on by default), in theory, the following (IMHO very useless) popup should show up only once.

Unfortunately, this is not the case. This rather useless dialog will pop up several times/quite often, even if the user selects "Don't show this message again".

Fortunately, Wickerl and I found a way to disable this useless popup once and for all via an simple IHS rewrite rule in the httpd.conf:

# Enable rewriting engine
RewriteEngine On

# Suppress RoundTripEditing-Dialog

RewriteRule .* - []

This sets the cookie "" via the [CO], or [cookie] flag of mod_rewrite, during each request, thereby disabling the "Edit on Desktop" prompt for good.


Back to top

The IBM Knowledge Center has a nice chapter on "Informing users of a migration or update". You basically redirect everyone to a static maintenance page unless they arrive from a certain IP adress (so you as an administrator can still work):

LoadModule rewrite_module modules/
RewriteEngine on

RewriteCond %{REMOTE_HOST} !^

RewriteCond %{REMOTE_HOST} !^

RewriteCond %{REMOTE_HOST} !^

RewriteRule !^/upgrading.htm$ /upgrading.htm [L,R=500]

ErrorDocument 500 /upgrading.htm

Unfortunately, in a current customer project, that did not work for me, as this
  • blocked the healtcheck from the Load Balancer (LB) in front of Connections as well, which resulted in the requests not getting forwarded to the IHS
  • "%{REMOTE_HOST}" always being the IP of the load balancer

So I had to modify the statement a little bit:
LoadModule rewrite_module modules/
RewriteEngine on

RewriteCond %{REMOTE_HOST} !^

# Allow traffic from the Healthcheck host aka. Load Balancer ...

RewriteCond %{REMOTE_HOST} !^

RewriteCond %{REMOTE_HOST} !^

# Check the "X-Forwarded-For" http header for the original IP of the requester

# and block if not certain IP (add more lines for more IPs)

RewriteCond %{HTTP:X-Forwarded-For} !^

RewriteCond %{HTTP:X-Forwarded-For} !^
RewriteRule !^/upgrading.htm$ /upgrading.htm [L,R=500]

ErrorDocument 500 /upgrading.htm


Back to top

As you probably know, IBM Notes supports "Notes-URLs" in the form of " notes://servername/applicationName?OpenApplication"; (eg.: Notes:///C1257802004BEEDD/CB71294887486E9CC125780E0034017E/D2060AA524CE62F5C125820B00371A6B). A lot of my IBM Connections customers are also Notes users so they also want to store Notes-URLs inside IBM Connections Wikis, Bookmarks, Forums, etc.

Unfortunately, with IBM Connections 6.0 CR1, IBM introduced a new white-listing mechanism for Active Content Filtering. This is fine, as it provides additional security, but is bad, as it breaks a few things. Additionally, the release notes only mention that the new filtering works "by only allowing uploads of content that meets your criteria" and does not mention, that the protocol part of an URL also gets checked. And that part prohibits the possibility to add Notes-URLs to IBM Connections, as you can see in the screenshot below:

Fortunately, this new feature can be modified to allow additional URL protocols, so there is no need to reactivate the legacy active content filters. Let me sum up the necessary steps from the slightly confusing ;) documentation.

1. Navigate to the "extern" directory of your LotusConnections-config directory. eg cd F:\IBM\WebSphere\AppServer\profiles\ic-dmgr01\config\cells\ic-cell\LotusConnections-config\extern

2. Copy the "ojhs-whitelist-default.xml" and change "default" to a string of your liking ("wyd" in my example). eg:  copy ojhs-whitelist-default.xml ojhs-whitelist-wyd.xml

3. Open "ojhs-whitelist-wyd.xml" in a proper editor and find the "allowUrlProtocols" section. Within that, add the notes protocol. Save and close the file. Afterwards, the section should look like this:
<protocol name="ftp" />
<protocol name="tel" />
<protocol name="notes" />
</ allowUrlProtocols>

4. Copy the "acp-configkey__default.xml" and change "default" to a string of your liking ("wyd" in my example). eg:  copy acp-configkey__default.xml acp-configkey__wyd.xml

5. Open "acp-configkey__wyd.xml" in a proper editor and find the "defaultKey" parameter. Replace "default" with the string you chose before ("wyd" in my case). Save and close the file. Afterwards, the parameter section should look like this:
<param value="defaultKey= wyd" />

6. Start the wsadmin client and check out the LotusConnections-config.xml file. Open that file in a proper editor.

7. Now find EVERY " sloc:serviceReference"; entry you want to modify (Wikis, Forums, Dogear, ...) and change the acf_config_file attribute for EACH ENTRY from "acp-configkey__default.xml" to the filename you specified in step 4 (in my case "acp-configkey__wyd.xml"). This should look like this for Wikis and Dogear:
  < sloc:serviceReference acf_config_file="acp-configkey__wyd.xml" bootstrapHost="admin_replace" bootstrapPort="admin_replace" clusterName="ICCluster" enabled="true" person_card_service_name_js_eval="generalrs.label.personcard.wikislink" person_card_service_url_pattern="/home/search?uid={userid}&name={displayName}" serviceName="wikis" ssl_enabled="true" >
 < sloc:serviceReference acf_config_file="acp-configkey__wyd.xml" bootstrapHost="admin_replace" bootstrapPort="admin_replace" clusterName="ICCluster" enabled="true" person_card_service_name_js_eval="generalrs.label_personcard_dogearlink" person_card_service_url_pattern="/html?userid={userid}" serviceName="dogear" ssl_enabled="true">

8.  Check in the modified LotusConnections-config.xml file.

9.  Restart Common and the applications you modified the configuration for in step 7

10. Profit!


Back to top

If you want to use the IBM Domino Webserver to offer a few files for download from the file system and not a database, you will face the issue that Domino does not allow "Directory Browsing" by default.

This would force you to either create a new index file or similar, every time you add or remove a file or send an explicit list of files to the person that should download the files.

Fortunately, there is an .INI parameter for that! Add

to your notes.ini, Server Configuration Document or directly to the server console via "set config", restart the webserver and voila, directory browsing is enabled:

Be aware, that is a server wide setting and applies to all Web Sites/Virtual hosts/... and may cause severe security issues!

Source: IBM Notes and Domino 9.0 Social Edition Forum - How to enable DOMINO 9.01 HTTP directory browsing ?


Back to top

During the installation of IBM Connections Touchpoint for a customer a stumbled upon an "issue" that is not (yet) covered in the documentation but is/will be an issue in the "real world™": "ssl-only environments" (properly: "tls-only"). The Connections documentation has a whole chapter called "Forcing traffic to be sent over an encrypted connection" on how to redirect all HTTP traffic to Connections to HTTPS (which you should do in times like these).

Unfortunately, as I learned the hard way, Touchpoint can't handle those redirects. What happens is the following error in the WAS logs:

 [17/04/XX 10:09:31:659 BST] 000000a1 SystemErr     R   [WebContainer : 5] ERROR - Failed to put image to Profiles API @ '': Moved Permanently
[17/04/XX 10:09:31:659 BST] 000000a1 SystemErr     R   org.apache.http.client.HttpResponseException: Moved Permanently

The error can also be found in the IHS logs.

What this basically means is that Touchpoint doesn't handle the redirect we set up on the IHS. So we have to tell Touchpoint to do it's work via https per default.

This is actually quite simple. All you have to do is add a few custom properties to the Ressource Environment Entry "REE Touchpoint Config".
Log into the ISC and navigate to "Resources -> Resource Environment -> Resource Environment Entries"

and select the "RRE Touchpoint Config " entry. Once you have that open, click "Custom Properties".

On that screen you should already have one entry for "" from the installation. You now need to add the following values in order to force Touchpoint to talk with Connections via https:  https    443

This should look something like this:

Now restart the WAS application server(s) (restarting the Touchpoint app was not enough in my case) and everything should just work.


Back to top

This is the Blog of Martin Leyrer, currently employed as IT-Specialist at IBM Austria - IBM Software Group, IBM Collaboration Solutions.

The postings on this site are my own and do not represent the positions, strategies or opinions of any former, current or future employer of mine.