FEB / Connections Surveys – custom LDAP attributes

Thanks to Christopher Dawes in the IBM Forms support team a long running issue I have seen with FEB (Forms Experience Builder) / Connections surveys is now resolved!!

Once of my long standing very awesome customers was seeing a problem with Connections surveys. They do not use a standard LDAP attribute for their displayname – the cn is the employee number and the uid is a short name which is not always easy to differentiate between users. These are the 2 attributes that FEB expect to use as the user display name. Not always easy to tell who abc12345 is .. or sbell123 so I opened a PMR to get to the bottom of how to change this to a custom LDAP attribute – in this case we use fullName – which displays my user as Sharon E Bellamy.

After a bit of backwards and forwards, many logs and tracing and a bit of DB hacking to prove the theory we now have a solution.

So here is how to resolve it.

Firstly you need your custom LDAP attribute – fullName
You will the repository Id of your LDAP – this is basically the label you have given the LDAP in the configuration. In this case it was novell as the LDAP is Novell E Directory

LDAPID

 

 

 

 

 

 

but in another example here you can see an Active Directory example (ADInternal)

 

 

LDAPID2

 

 

 

 

 

 

 

Step 1:

Add a new WebSphere Entity Type – wsadmin

open a command prompt to the deployment manager/bin directory

run wsadmin (you do not need to set the lang type to jython)

enter the command to set the new entity type – were name = your LDAP attribute name and repositoryIds is your LDAP identifier

 

[blockquote]

$AdminTask addIfMgrPropertyToEntityTypes { -name fullName -dataType String -isMultiValued false -entityTypeNames PersonAccount -repositoryIds Novell}

[/blockquote]

 

 

 

 

 

This registers the attribute in the WIM config.

 

 

 

Step2:

Add the entity type into WebSphere

open the WebSphere admin console / ISC

browse to Security > Global Security > Configure federated repositories

Click on the link for your repository identifier (novell in my case)

LDAPID3

 

 

 

Once in the repository config, click on the Federated repositories property names to LDAP attribute mappings

 

LDAPIDs4

 

Enter a the new attribute for our custom LDAP entry (fullName)

 

LDAPIDs5

 

Where Name = a meaningful name for the new attribute

 

Property name = the LDAP attribute name

 

Entity types = PersonAccount

 

Apply and save

 

Save a lot

 

then restart the deployment manager.

 

Step 3:

Edit the Builder_config.properties on the node where FEB is installed (in my case the primary connections node)

the default directory where this is kept is

Windows – C:\IBM\Forms\extentions

Linux – /opt/IBM/Forms/extentions

Open the property file in your favourite text editor

near the top of the file ensure the

ibm.was.MemberManager.userProps.displayName property is not commented out and add your new LDAP attribute

in my case

 

[blockquote]

ibm.was.MemberManager.userProps.displayName = fullName

[/blockquote]

 

 

 

 

 

Save and close the file

 

and restart everything

 

Now when you create a survey or fill one in your new attribute it used.

Existing surveys are updated with the owner / creators name when they log in. The freedom (FEB) DB is updated when the user logs on and the display name is updated.

 

There you have it – took a while as there was a little bit of jiggery pokery with the wsadmin command and the PersonAccount attribute but it works 🙂

Hope this helps anyone else seeing the same problem

Do you monitor your Connections environment?

After being to a few user groups lately and seeing all the great monitoring tools for Domino I am interested in what people use to monitor connections.

The WebSphere piece of connections can put a lot of people off and I am wondering if something was available would you use it?

  • If you do monitor, what do you use
  • If something was available with a *dashboard* would you use it?
  • What features would you like in a monitoring app
  • Would you be interested in something bundled in Nagios etc

I have created a quick survey which should only take you 2 mins to fill in, if you can spare the time to fill it in I would be most grateful

You can use the survey below or head to the link here: https://www.surveymonkey.com/s/NZBDNW6

 

Create your free online surveys with SurveyMonkey , the world’s leading questionnaire tool.

Connections 101 – what a fantastic idea

I think a community high five is in order for Mr Paul Mooney and Ms Gabriella Davis.

They have taken on the mamoth task of creating a Connections 101 site that will assit those new to Connections and WebSphere to get you up and running with advice, information and assistance.

Something like this can not come soon enough.

I am lucky, I have been what I would describe as “mucking about with” WebSphere for the past 11 odd years. I had a very good teacher (thank you Bleddyn), and the best hardware to play with it on (the iSeries – or As400 for oldschool people or IBMi for new school people).

I was in at the deep end with Websphere 4 and 5 and IBM Commerce (which runs on WebSphere) and it went from there.

11 years later .. I am still at it. Athough I have swapped WebSphere Commerce for IBM Connections now.

This new site along with blogs (like mine I hope), useful presentations at lugs (like WebSphere for Domino people, or WebSphere what you really need to know), and the help of the community will get people up and running and working confidently with Connections. It’s a fantastic piece of software and once you know what bits you need you can get up and running fairly quickly.

I would love to help or contribute in anyway .. so if you feel I have something to add – let me know

Connections fix pack 3.0.1.1 now available

At last Connections fix pack 3.0.1.1 is now available to download and fixes lots of little issues, including the firefox feature with files and wikis and the issue chrome has with files.

I installed it on my test system yesterday and it went very smoothly.

The fix pack can be downloaded from Fix Central. Fix ID is: ​3.0.1.0-LC-Multi-FP001​

The Fixpack is installed using the IBM installation manger (IM).

It was very straight forward – basic steps are as follows

Download the fixpack zip file

Stop the Connections WAS servers, but leave the Deployment manager and Nodeagent servers running

Start the IBM installation manager

From the installer manager menu , click File -> Preferences

Add a repository (if you have used eclipse or RAD (Rational Application Developer)  / WSAD (WebSphere Application Developer) in the past you will be familiar with these steps)

Point the repository path to the full path of the fixpack zip file and click ok

If there is an issue connecting to the repository the IM will let you know at this point.

Click update and follow to the guide to install the fix pack – ensure all applications are selected and enter a valid wasadmin user name and password.

Review the summary information. Click Back to change the information or click Update to install the selected fix packs.​
​
When the installation is complete, synchronize all the nodes and restart all the clusters

 

As ever please review the full technote / read me which can be found here

 

IBM are making these fixes easier and easier for people without a huge amount of WebSphere / Connections knowledge to install – good on them.

 

I am very impressed with all the improvements I have seen over the past 3 or 4 years around fixes and fix packs – IBM has come along way since I first started “mucking about with WebSphere” 11 years ago.

Joined Up Thinking In Identity & Access Management: WebSEAL and WebSphere Portal – An Integration Pattern

Fantstic new post from the Identity Management Guru (ans all round lovely bloke) – Mr Stephen Swann

Joined Up Thinking In Identity & Access Management: WebSEAL and WebSphere Portal – An Integration Pattern

Very well put together post on Securing Portal with Tivoli Access Manager (TAM), with some sensible suggestions for approach and useful gotchas.

Stephen is a legend when it comes to this kind of thing, be sure to look him up if you need any assistance and tell him I said Hi.

Portal 6.1.5 do i love it or hate it ..??

Answers on a post card … first impressions of the installer was Wow that was neat, it installed the vanilla *everything* install fairly quickly and was up and running on it’s cloudscape db and basic security very quckly, looks funky, is fast and the new connections style theming is very sexy …

Now I am trying to do something wild and crazy …. point it at an oracle db … so far I am losing this battle .. although after a lot of swearing at windows 2008 for being TOO secure and the info centre for not making much sense I feel we may be winning the battle and be well on the way to winning the war, once the oracle piece is sorted it should be a straight forward secure against Active Directory federated LDAP cluster and go ..SHOULD – it was straight forward in Portal 6.1.1 but then so was securing it against an Oracle db …

Once I have it working I will doc the steps mainly for my reference but you never know some other poor little geek may also have to use Portal with the Oracle / AD solution and I would hate people to go through pain if they don’t have to 🙂

watch this space kiddies you never know I may post something useful 🙂

Connections 2.5 – WebSphere Tips

WebSphere Tip : 1

When clustering Connections you may encounter issues when the wizard attempts to federate the node into your deployment manager. This is a known WAS issue as the JVM suffers out of memory errors (is you delve deep in the add node log file / dmgr log you will find them).

There is a quick work around that can solve this:

Increasing the WAS HEAP size
In order for the add node command to work correctly when running the cluster wizard please do the following:

Connection servers
On each of the connections servers browse to bin and edit the addNode file (.bat or .sh depending on your OS).

Insert the line set WAS_HEAP=-Xms256M -Xmx1500M at the top of the file to set a variable (for example – under the set CMD variable)

set CMD_NAME_ONLY=%~n0
set WAS_HEAP=-Xms256M -Xmx1024M

at the bottom of the file find the “%JAVA_HOME%binjava” line and add the variable

“%JAVA_HOME%binjava” -Dcmd.properties.file=%TMPJAVAPROPFILE% %WAS_HEAP% %WAS_DEBUG% %WAS_TRACE% %CONSOLE_ENCODING% “%CLIENTSOAP%” “%JAASSOAP%” “%CLIENTSAS%” “%CLIENTSSL%” %USER_INSTALL_PROP% “-Dwas.install.root=%WAS_HOME%” “-DWAS_HOME=%WAS_HOME%” “com.ibm.wsspi.bootstrap.WSPreLauncher” -nosplash -application “com.ibm.ws.bootstrap.WSLauncher” “com.ibm.ws.runtime.NodeFederationUtility” “%CONFIG_ROOT%” “%WAS_CELL%” “%WAS_NODE%” %*

save the file.

Deployment Manager
On the deployment manager machine.
Open the Administrative Console.
Open System Administration > Deployment Manager > Process Definition > Java Virtual Machine.
Specify 256 for Initial Heap Size and 1500 for Maximum Heap Size.

Save your changes and restart the Deployment Manager.

This should resolve the issue – you may need to increase the Dmgr maximum heap slightly more but I found 1000 was just not enough and 1500 did the trick.

When you run the cluster wizard now it should run as expected 🙂

WebSphere Tip : 2

A handy tip to note if you are not a huge WebSphere guru.

To enable commands to be run from the command line without the need of the -username and -password arguments configure SOAP security.

Every WebSphere profile has a file called soap.client.props which hold soap connector client information. The path to the files is as follows : /profiles//properties

SOAP connector security is disabled by default.

When enabled with the correct information it is possible to run the standard WAS start , stop and status commands for instance by just running the .bat or .sh command without passing the extra credentials.

### EXAMPLE ###

###############################################################################
#
# JMX SOAP Connector Client Properties File
#
# This file contains properties that are used by the JMX SOAP Connector Client
# of the WebSphere Application Server product. SOAP Connector executes on WebSphere
# java servers and client systems with java applications that access WebSphere servers.
#
# ** Encoding Passwords in this File **
#
# The PropFilePasswordEncoder utility may be used to encode passwords in a
# properties file. To edit an encoded password, replace the whole password
# string (including the encoding tag {…}) with the new password and then
# encode the password with the PropFilePasswordEncoder utility. Refer to
# product documentation for additional information.
#
###############################################################################

#——————————————————————————
# SOAP Client Security Enablement
#
# – security enabled status ( false[default], true )
#——————————————————————————
com.ibm.SOAP.securityEnabled=true

com.ibm.SOAP.loginUserid=wasadminuser
com.ibm.SOAP.loginPassword=wasadminpassword

#——————————————————————————

Connections 2.5 Clustering – how to avoid some pain

All was going exactly to plan when I installed my primary node – federated correctly worked as expected and I even managed to change it fairly easily to point to a different DB and shared content store I was a very happy bunny UNTIL I decided to add node2 – then it all went “pear shaped”.

So here is a quick over view of the issue and how I have got around it – but I really want to know how this happened and if I can do anything to fix this for the future – I have a PMR open and IBM are trying to recreate the issue now.

I created node1 using the Connections install wizard to create a primary node – I supplied DB(jdbc:oracle:thin:@ < my Original DB server name >:1521:conn1) and file system info (//< my Original File server name >/LotusConnectionsData/< featureName >) and it clustered successfully and node 1 was fine.

I then moved the DB to another machine and also moved the file system. I edited the data source info at cluster and server level (jdbc:oracle:thin:@< my NEW DB server name >:1521:conn1) and also changed the file system (< my NEW File server name >/portal_collabdata$/< featureName >) in the Websphere variables section of the ICS as per the instructions in the info center. Node 1 has always worked as expected even after moving these.

When I added any subsequent node it configured the server with the original file store information (//< my Original File server name >/LotusConnectionsData/< featureName >)) and defaulting back to the original DB data source (jdbc:oracle:thin:@< my Original DB server name >:1521:conn1).

If I change these manually and resynch and restart the servers they work as expected – the Datasource although it is set at Cluster level .. is also set at server level – I had to change the datasource EVERYWHERE to fix the issue (as I have 4 servers per machine and 4 machines that is a lot of editing).

This has prompted me to ask these questions of IBM:

The WebSphere Variables for the file stores are also picking up the original path – It appears that when Node1 was federated and the config was created that it has made some kind of *template* which it creates further nodes/servers from. As I have changed the config the template is not getting updated (if this is how it is doing it).

Am I doing anything wrong?
If so what?
And if no how to I prevent this from happening in the future?

== IBM’s Response ==
I received an email back from IBM regarding the issues that I experienced after changing some settings in my cluster. The bad news is it is a limitation, the good news is they are going to fix it:

The customer is right, this is a limitation in the LC 2.5 install and is being addressed for the next release.

In LC 2.5, variables/datasources/providers/etc are created at the server level, then this is used as a template for additional servers…
the problem is that server level settings like this override higher (node, cluster, cell) level settings, causing the difficulty updating the customer experienced.
ideally, these settings would be at cluster level.

Since the customer has this working, they do not have to change anything, but, if they wish to simplify future changes they can do the following:

1. create cluster level variables, datasources, providers, etc
2. [optional… for testing] create a new node — this node will have all the server level settings by default
3. only if you did 2… delete the server level settings for the items you created at cluster level in step 1
note: if you don’t delete the server level settings for this new node, it would continue to use the server level settings
4. only if you did 2… test that the applications deployed on the new node behave correctly (basically you are verifying the cluster level settings)
5. after verifying (or reviewing) the cluster level settings (variables, datasources, etc), you can delete the server level items corresponding to the new cluster level items
note: if you don’t delete the server level settings for this new node, it would continue to use the server level settings
6. now, when you make changes to the cluster level variables thru the deployment manager, you just need to save changes and synchronize nodes
all the nodes and servers that don’t have node or server level instances of the same variables will get the cluster level values

Again, the order of precedence for finding variables, datasources, etc is….
first, is it defined for the Server? If yes, the server level item is used
second, is it defined for the Node?
third, is it defined for the Cluster?
fourth, is it defined for the Cell?

Wow .. This looks awsome

today thanks to the lovely Mr Stuart McIntyre for the tip off .. but Mr David Hay IBM consultant and general technical guru and geek has posted a guide to Portal 6.1.5 (with screen shots) .. WOW IBM, you have made the portal interface look as cool as the connection one does 🙂

I am downloading it now and looking forward to a play