According to the Connections 3.0.1 documentation this can be achieved in specifying your regular expression in the source_ldap_required_dn_regex property of the profiles_tdi.PROPERTIES file.

Looking at the underlying TDI Assembly Line code though I discovered that source_ldap_required_dn_regex is never being read. Instead a property of source_ldap_required_dn_regex_pattern is being evaluated.

Using the right property unfortunately still doesn’t make the regular expression filter work properly. Instead I received the following error in the ibmdi.log file when running the sync_all_dns Assembly Line:

ERROR [AssemblyLine.AssemblyLines/_internal_ldap_iterate.5] - [ldap_iterate]
CTGDIS181E Error while evaluating Hook 'After GetNext' in the Component
'ldap_iterate' (ldap_iterate.after_getnext).
com.ibm.jscript.InterpretException: Script interpreter error, line=26, col=74:
Unknown member 'test' in Java class 'java.lang.String'

Hunting down the offending line of code the cause of the error becomes quite obvious. According to the JavaScript introduction from the TDI Users online community, TDI specific objects are Java objects instead of JavaScript objects. In our example the source_ldap_required_dn_regex_pattern variable is a java.lang.String object, which does not have a method named test. The test method is part of the JavaScript RegExp object, which apparently has been expected in this case.

After a brief moment where I was wondering whether IBM ever tested that bit of code or if I am the only one with that issue I replaced:

if(!lcConf.source_ldap_required_dn_regex_pattern.test(sdn)) {

with:

var re = new RegExp(lcConf.source_ldap_required_dn_regex_pattern);
if(!re.test(sdn)) {

This results in my ‘re’ variable to be properly instantiated as a RegExp JavaScript object with the value of the source_ldap_required_dn_regex_pattern string variable. I can then successfully use the JavaScript RegExp.test function to test the value of sdn. As another way of solving the issue I could have also rewritten above line of code and use the matches function of the java.lang.String class, passing in the regular expression itself.

System Clocks are not synchronized within 5 minutes of one another, Please synchronize for federation.

Since I was working in a somewhat unreliable test environment I obviously believed in the message and dutifully compared the system times between the Sametime Systems Console server and the Sametime Meeting server. Without a lot of surprise the times were synchronised and the time zone settings didn’t cause any trouble either. This obviously didn’t help me in any shape or form hence I started to investigate the various log files created by the system.

Looking at the Deployment Manager’s System log I discovered an error, which was logged every time I tried to confirm the deployment plan for the Sametime Meeting Server:

[20/04/12 16:21:13:150 NZST] 00000065 exception     W com.ibm.ws.wim.adapter.file.was.FileAdapter login CWWIM4512E The password match failed.
[20/04/12 16:21:13:151 NZST] 00000065 exception     W com.ibm.ws.wim.adapter.file.was.FileAdapter login
                                com.ibm.websphere.wim.exception.PasswordCheckFailedException: CWWIM4512E The password match failed.
at com.ibm.ws.wim.adapter.file.was.FileAdapter.login(FileAdapter.java:2025)
at com.ibm.ws.wim.ProfileManager.loginImpl(ProfileManager.java:3519)
…
[20/04/12 16:21:13:153 NZST] 00000065 LTPAServerObj E   SECJ0369E: Authentication failed when using LTPA. The exception is <null>.

This triggered my memory. We recently had to change the password for the local Websphere administrative user. Researching above error message I learned from Dave (Thanks!) that the local file registry could still hold the wrong password. The link in Dave’s post pointed me to the instructions on how to How to reset the administrator’s password in the file registry. While those instructions obviously aim for Websphere Portal they still helped me solve my issues with the Sametime Systems Console deployment manager.

After synchronising all the nodes and restarting the application servers, node agents and the deployment manager I managed to successfully deploy the Sametime Meeting Server.

How to reset the administrator’s password in the file registry

HTML wrapper

HTML wrapper accessible

Just note the comment on the top of each document “This draft is refreshed quarterly, as necessary, but does not contain all of the latest updates and fixes made to the community-owned version of the wiki articles.”

Don’t hesitate to drop me a line if you need to know more details on any of the topics covered.

Feel free to download the presentation from here. Most presentations should also be made available in the AusLUG community after the event.

Issue:
Outgoing SMTP messages are rejected by ISP or Gateway appliance with error “Invalid sender address”

Investigation:
RFC 5322 requires a from field in the header of every email. Emails that were sent from LotusScript specifying an invalid entry for the Principal field caused Domino to create invalid message headers. The mandatory From field was missing.

Solution:
When using Principal fields, ensure to use valid names. This are full names or abbreviated names as listed in the Domino Directory but not email addresses. Using email addresses in the principal field causes above issue even if the address is listed as an additional entry in the User Name field.