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

I had the pleasure to install an IBM Connections pilot for a customer together with Etienne Döhler a few weeks back.

One of the obstacles we faced during the install was a rather sealed off RedHat GNU/Linux box, that had only port 22 (ssh) open to the PCs we were using for the install (fortunately with X11 installed and X11 forwarding allowed). As the customer wanted the IBM HTTP Server (IHS) to listen on 8080/8443 for the communication with the already existing Reverse Proxy (RP, managed by Lufthansa) they also opened that port, but only for connections with the RP.

One of the "best practices" I try to convey at Social Connections is that you should always test your install without a Reverse Proxy, Load Balancer, ... and make sure everything works before you introduce the additional complexity of a Reverse Proxy or similar.

So how to connect to the IBM Solutions Console and the IHS when the only open port to that machine is SSH (22)? Well, SSH and its config file to the rescue!

SSH has a nifty feature called port forwarding. This allows you to forward local ports to a remote machine. Together with some creative hosts file editing, you can use your local browser to access the remote machine as if the necessary ports were open on the remote machine.

We needed the following URLs to work:


So the first thing to do was to modify the hosts file to point to    localhost

And then create an entry in ~/.ssh/config with the local port forwarding and further settings to spare us some typing:

Host customername 

        # Specify destination host by IP, as we have an hosts entry for the name
        Port 22
        User zaphod
        IdentityFile ~/.ssh/customername_rsa
        Compression no
        AddressFamily inet
        ForwardX11 yes
        LocalForward 9043
        LocalForward 8080
        LocalForward 8443
        PreferredAuthentications publickey,keyboard-interactive,password

So with a simple "ssh customername" I can now connect to the GNU/Linux machine with the key I created to that purpose and have X11 forwarding as well as local port forwarding activated. And as long as that ssh session is open, I can now access the ISC and the IHS in my local browser as if 9043, 8080 and 8443 were open network ports on the remote box.

And it was a good thing that we were able to test directly with the IHS and verify that everything was working as expected, as the RP had disabled SSLv3, which broke the IBM Connections Widgets at that time. But that is a story for another blog entry.

For more SSH voodoo, see my "Was, SSH kann auch das?" talk at the Grazer Linuxwochen 2013 (in german).


Back to top

If you need to open a VPN connections to Softlayers private network, you should do this via a browser, as described at From what I experienced, with Linux you would need to run a browser as root to follow the instructions.

Fortunately, there is another way: The command-line client. Using that is rather straight forward (except one gotcha).
1.        Download the VPN software from
cd ~/Downloads

2.        Rename the zip file to bin (I tried to uncompress it, which failed miserably)
mv ArrayNetworksL3VPN_LINUX.bin
3.        Make the file executable
chmod 777 ArrayNetworksL3VPN_LINUX.bin
4.        Execute it as root
sudo ./ArrayNetworksL3VPN_LINUX.bin

And your are done.

Now you can open up a VPN connections to Softlayer from the comfort of your command-line:
sudo /usr/local/array_vpn/array_vpnc -hostname -username [YOUR SOFTLAYER USERNAME] -passwd '[SUPER_SECRET PASSWORD]' &

Which should give you a

message back.

A quick "ifconfig tun[x]" should also show a valid 10.a.b.c Softlayer IP adresss.
ifconfig tun1 
tun1      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  
        inet addr:  P-t-P:  Mask:
        RX packets:1 errors:0 dropped:0 overruns:0 frame:0
        TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
        collisions:0 txqueuelen:500
        RX bytes:20 (20.0 B)  TX bytes:0 (0.0 B)

If you can also successfully ping or your server's private address,  you are successfully connected.
ping -c 3 
PING ( 56(84) bytes of data.
64 bytes from icmp_seq=1 ttl=253 time=35t4.6 ms
64 bytes from icmp_seq=2 ttl=253 time=34.9 ms
64 bytes from icmp_seq=3 ttl=253 time=35.1 ms

--- ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 34.605/34.886/35.148/0.222 ms

Pro-tip: Use the VPN server of the Softlayer datacenter where your machines reside.  Apparently, there exists at least one Softlayer VPN Server for every datacenter:
  • for Dallas, Texas, USA
  • for Seattle, Washington, USA
  • for Washington, D.C., USA
  • for Amsterdam, The Netherlands, Europe
  • and so on ...

I must say, that I was pleasantly surprised (again) by Softlayers support. I had a correct answer to my question in under 5 minutes after opening the ticket.


Back to top

Join subject matter experts from the IBM Domino team for an Ask the Experts Q&A session titled "Managing Domino - Admin Client, AdminP, and Policies." We'll begin the session with a short demo or presentation but the main focus of the session is Q&A. So bring your questions!

Topic: Managing Domino - Admin Client, AdminP, and Policies
Date: Tuesday, November 4, 2014
Time: 11:00 AM EST (15:00 UTC/GMT, UTC-4 hours) for 60 minutes
Webcast URL:
Webcast Password:  webcast

For a list of world-wide phone numbers, the phone passcode, and an iCalendar (.ics) file for this session, click here:


Back to top

Join John Ballam from the Domino team as he discusses installation, setup, and going into production with your Lotus Protector for Mail Security (LPMS) server.

After a presentation, attendees will be given an opportunity to ask questions to the technical experts we will have on hand. Throughout the event, attendees will also be encouraged to comment or ask questions in the IBM SmartCloud Meeting Web chat.

For a list of world-wide phone numbers, the phone passcode, and an iCalendar (.ics) file for this session, visit


Back to top

Running a Domino based web application behind a reverse proxy (as I am doing for quite some time now) is the latest craze (due to the SSL issues in the current Domino SSL stack). Sean Cull has instructions for configuring Apache, Jesse Gallagher for ngix.

There is one issue unsolved though in Seans configuration w(that Jesse solved for ngix). The field "Remote_Addr" in the web application will, due to Apache acting as a reverse proxy, not contain the IP of the client calling the app any more. Which can be an issue, if you need that information in your app. The Domino Blog for example can't block clients based on their IP any more.

The solution for that is to set the parameter "HTTPEnableConnectorHeaders=1" either in the notes.ini or a configuration document. With that, Domino maps the following additional headers to the corresponding, regular fields:

The Auth Type that is being used to make this request.

The Client Certificate used for this request. If the value is not base64 encoded for us by the Web server, then the plug-in will base64 encode it before sending it across to the application server.
Restriction: If you enable this, it is assumed you know what you’re doing, and how to protect direct access to the port at which the embedded http is listening.
Note: If you set the LogLevel to TRACE in the plugin XML config file, it is possible to see what headers are actually added for a given request. Appendix C. Domino 6 HTTP plug-in hints and tips 659

The cipher suite that the Web server negotiated with the client. This is not necessarily the cipher suite that the plug-in will use to send the request across to the application server.

This header will be set to either True or False depending on whether or not the request is secure (came in over SSL/TLS).

The scheme being used for the request. This header will normally be set to either http or https.

The HTTP protocol level being used for this request. The plug-in currently has support for up to HTTP/1.1 requests.

The remote IP address of the machine the client is running on.

The remote host name of the machine the client is running on. If the hostname can't be resolved, this header should be set to the IP address.

The remote user specified for the given request.

The server name used for this request. This should be the value that was specified in the HOST header of the incoming request.

The server port that the request was received on. This will be the port value that is used in route determination.

The SSL Session ID being used for this request. If the value is not base64 encoded for us by the Web server, the plug-in will base64 encode it before sending it across to the application server.

So in our case, "$WSRA" would get mapped to the Domino field "Remote_Addr", thereby "fixing" our problem of the missing client IP:

But what have we got to do in order to set  that additional Header in the proxy request from Apache to Domino? The following magic incantation in the correct httpd.conf does the trick:
SetEnvIf REMOTE_ADDR (.*) temp_remote_addr=$1
RequestHeader set "$WSRA" "%{temp_remote_addr}e"

(you need, of course, to enable mod_headers and  mod_setenvif )

This maps the REMOTE_ADDR, containing the clients IP address, to the environment variable "temp_remote_addr", which we then can use to set the $WSRA header in the proxy request. Rinse and repeat for other variables you need.

Simple, isn't it?


Back to top

The latest point release of IBM Mobile Connect, IMC, is available on the Recommended Maintenance page.  You can also find the latest builds of 6.1.5 and 6.1.4 in this location.

In there are new features including the ability for IBM Mobile Connect to act as a True Load Balancer in front of Traveler.  It will have the concept of a Traveler HA Pool Object!  
This means IMC can now sit in front of the pool and all of the servers in a pool are defined in this HA Pool Object. IMC's existing load balancing algorithms can be used to balance the traffic and help Traveler to manage users and follow their sessions when changing Traveler servers.


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.