Installing WebSphere Portal Server 6.1.5 on Windows ...

Whilst working to help out a colleague who was struggling with the download of the relevant images, I was able to successfully download and install WebSphere Portal Server 6.1.5 onto Windows ( I'm using XP as a dev. environment, running under VMware Fusion 3 on my Mac ).

I used the following script to unpack the images: -

unzip CZ8G7ML.zip -d c:\temp\W-Setup
unzip CZ8H2ML.zip -d c:\temp\W-1
unzip CZ8H8ML.zip -d c:\temp\W-2
unzip CZ8I4ML.zip -d c:\temp\W-3
unzip CZ8I5ML.zip -d c:\temp\W-4
unzip CZ8I6ML.zip -d c:\temp\W-5
unzip CZ8I7ML.zip -d c:\temp\W-5A

using the ubiquitous unzip.exe tool ( part of PKZip iirc ) to expand the ZIP files.

Hope this helps ...

Configuring Microsoft Windows single sign-on for IBM Lotus Connections

Windows SSO support is a new feature in Lotus Connections 2.5, enabling users who are already logged on to a Windows desktop to log on to Lotus Connections automatically, without needing to re-authenticate.

The SSO is achieved by means of Simple and Protected GSSAPI Negotiation Mechanism (SPNEGO), which is a GSSAPI "pseudo mechanism" used to negotiate one of a number of possible real mechanisms. The negotiable sub-mechanisms include Windows NT LAN Manager (NTLM) and Kerberos, both of which are supported by Microsoft Active Directory.

Windows SSO can be implemented in a variety of ways, including via WebSphere® Application Server SPNEGO Trust Association Interceptor (TAI), Tivoli® Access Manager, or other third-party access managers.

In Lotus Connections 2.5, the Windows SSO support is built on WebSphere Application Server SPNEGO TAI. Figure 1 illustrates how the SPNEGO authentication is performed with WebSphere SPNEGO TAI (excerpted from the developerWorks article titled, "Administering the SPNEGO TAI: Tips on using Kerberos service principal names").

http://www-10.lotus.com/ldd/lcwiki.nsf/dx/Configuring_Microsoft_Windows_single_sign-on_for_IBM_Lotus_Connections

Using Lotus Sametime Connect client in a load-balanced Sametime server environment

Following a client's recent experiences, I'm pleased to report that it appears to be possible to have a Sametime Connect client ( actually the Sametime 8.0.2 client within the Notes 8.5.1 client ) authenticate with a clustered Domino server via a load balancer.

Whilst the Sametime client itself does not allow the load balancer's hostname to be entered ( it assumes that the hostname is actually that of a Domino server ), there is a useful circumvention, documented in SPR PMIA6A9MMW: -

SPR# PMIA6A9MMW - When a notes client connects to a Domino server part of the protocol exchange includes the notes client telling the server what it thinks the server's name is. If the names do not match, the connection is terminated. This mechanism is part of the code which supports partitioned servers running on the same IP address.

However, because of this algorithm, we cannot use network sprayers in front of Domino servers. When a Notes client uses a Network Sprayer address as a Domino server address, the network sprayer may make the final connection to any of the Domino servers behind it. If the name supplied by the client is not the Domino server name of the selected server, the connection will be broken.

This fix provides a mechanism to skip the server name checking to allow this configuration to work.

NOTE: This mechanism is suitable ONLY if the database being accessed is available on all the Domino servers being sprayed to! This is only true for very constrained configurations. For example - Sametime Servers that want to use SSO, or clusters in which all accessed databases have replicas on all servers! There are many configurations in which this feature will not work.

To enable this feature, on each of the Domino servers behind the network sprayer add NETWORK_SPRAYER_ADDRESS=sprayer to notes.ini. Where "sprayer" is * * to match any name, or the DNS or HOST file name of the sprayer itself, or a comma separated list of names.

This is further documented in this Technote.

WebSphere Portal NOW - BP Enablement @ IBM Hursley Park on February 17/18

For more details, and registration, please click here: -

https://www-304.ibm.com/isv/spc/events/description.jsp?event=BA9F4D92AA0D38948625769400543CBF

Now this is a sight that you don't see every day ...

Want to run Windows applications natively on the Mac, without using VMware Fusion, BootCamp etc. ?

Then check out WineBottler - with thanks to Mr Bill Buchan for sharing ( also known as u235 )

IBM Support Portal - Wow, what a difference ...

http://www-947.ibm.com/support/entry/portal

Using Tivoli Directory Integrator to populate Lotus Connections Profiles from a Domino group

As per a previous blog post , I've recently worked out how to use TDI to populate the Lotus Connections Profiles database from a Domino group.

The "problem" is that Domino does not support the memberOf attribute that other LDAP servers support, meaning that there is no simple way to identify members of a Domino group via a LDAP search filter.

As is probably well known by now, Lotus Connections includes TDI as a  mechanism for integrating data from various systems, including LDAP directories, into the Profiles database.

The Connections product includes a set of scripts ( known as the Profiles Population Wizard ) that use TDI for this, and other related purposes. The wizard actually invokes one or two TDI processes, known as Assembly Lines. In my particular scenario, there are two Assembly Lines involved: -

collect_ldap_dns

This Assembly Line iterates through the LDAP specified in profile_tdi.properties, and then writes dn into the collect.dns file.

Populate_from_dns_file

This Assembly Line runs after collecting dns in the collect.dns file. It iterates over the collect.dns file, fetches data from the LDAP, and syncs the database with details of the employees. This Assembly Line is invoked while running the populate_from_dn_file.sh script.

The LC Wiki outlines this in far more detail here.

My solution replaces the collect_ldap_dns Assembly Line, and uses consists of three elements: -

Domino_Group_Members_into_Profiles.properties

##{PropertiesConnector} savedBy=root, saveDate=Fri Jan 01 11:57:23 GMT 2010
source_ldap_url=ldap://dmht60p.uk.ibm.com:389
source_ldap_search_filter=CN=LC25
source_ldap_user=CN=domadmin,O=ibm
source_ldap_password=passw0rd

Domino_Group_Members_into_Profiles.sh

#! /bin/sh
rm collect.dns
/opt/IBM/TDI/V6.1.1/ibmdisrv -s . -c Domino_Group_Members_into_Profiles.xml -r Domino_Group_Members_into_Profiles

Domino_Group_Members_into_Profiles.xml

This is "Blue Glue" that joins the two together - the shell script invokes the TDI server ( ibmdisrv ) which reads the properties file AND the XML file, which contains the details of the Assembly Line ( called Domino_Group_Members_into_Profiles - yeah, I know my naming convention isn't the best ... ).

This Assembly Line uses an LDAP Connector to read the members of the group, specified by source_ldap_search_filter=CN=LC25, via iteration, and parse the user name ( Distinguished Name ) to remove everything apart from the preceding CN= and the closing O= . This list of user names is then written, line by line, to a text file, collect.dns.

That's it, simple as that.

Now if I was REALLY smart, I'd work out how to (a) amend the out-of-the-box Assembly Line ( collect_ldap_dns ) or (b) invoke the Populate_from_dns_file Assembly Line from my own version.

However, that'll do for the time being ...

With thanks and kudos to many, including: -

Eddie Hartman
Keith Brooks
Mitch Cohen
Sjaak Ursinus


and three  awesome products; Lotus Domino and Tivoli Directory Integrator and Lotus Connections.