Tuesday, September 23, 2014

Sametime 9 - Meeting rooms with "managed access" not working - solution

In my sametime environments that I manage, both internally and for customers, this issue was a common nominator:

When a user created a meeting room and ticked of the "managed access" setting, and then entered the room, other participants were not able to join the meeting.
The other participants would get this message box, indicating that the manager of the meeting room was not present in the room:

Looking at the SystemOut.log for the Meeting server, this is what I noticed:
[23.09.14 10:54:08:449 CEST] 00004d13 MeetingApplic W   Number of active managers read is still less than 1 after 10 iterations
[23.09.14 10:54:54:104 CEST] 000000b8 LogEventDAO   W   GWCLG0002W: User[9d08b1fbb89e7e40a929c3908545eb14] not in User table. Cant move to Usage table.
[23.09.14 10:54:54:104 CEST] 000000b8 LogEventDAO   W   moveUserToUserUsageTable, userId = [9d08b1fbb89e7e40a929c3908545eb14] sessionId = [4378b78a-8351-420e-8180-a64bbef9fa4f] serverId = [22ae37727fea628a61f8d1b5b22eb7c3]

[23.09.14 11:12:41:716 CEST] 000000b8 LoggingBean   E   GWCLG0003E:Exception processing a JMS message
                                 com.ibm.meetingserver.dao.DAOException: com.ibatis.common.jdbc.exception.NestedSQLException:  
--- The error occurred in com/ibm/meetingserver/logging/UserInfoDAO.xml. 
--- The error occurred while applying a parameter map. 
--- Check the UserInfoDAO.update-InlineParameterMap. 
--- Check the parameter mapping for the 'uniqueId' property. 

That last line in the log regarding the "uniqueId" got me on the right track.

By fluke, I had just gone through the Sametime Meeting server parameters in the SSC console, and I noticed this one:

Hmm, I can´t seem to ever have heard of a Ldap attribute with the name "uniqueId" before.

So I changed this parameter to have the value "mail".
Synced the nodes and restarted the Meeting server, and now participants were able to access meeting rooms with the option "Managed Access" set (and of course where the meeting room manager was present in the room".

If someone has some documentation regarding this meeting server parameter, please enlighten me about it. I have never used this parameter before, nor payed attention to it.


collaborationben said...

I'm not so sure that changing that variable fixed the problem, rather the restart fixed it. I have seen something similar with a customer running and started looking into the issue with IBM. I also found that the meeting statistics did not show the correct number of "active participants."

I found no DB2 exceptions in the SystemOut.log. I tried to enable JMS trace but it wouldn't take for some reason and then the server was restarted (to apply Windoze updates) and after the restart it worked fine.

IBM believe the following is what happened:

"When a user joins a managed room, the server checks a table in the database to see if the owner or a manager is in the room before allowing individuals into the room. The logging component (that we were trying to enable prints for) is responsible for populating the user table, so the logging component was either not getting the message from JMS that the user had joined, or there was a problem communicating with the database entering the user into
the table. I suspect that it was JMS, since I didn't see any db2 errors in the SystemOut.log indicating there were database issues. When the server was rebooted, the jms system must
have resumed it's normal operation, so things are back to normal.

This would also explain why you failed to see correct statistic values for other non-managed rooms."

Robert Farstad said...

Thx for your comment.

I now changed the parameter on 3 different ST9 environments, and "managed access" started working on all 3. And I restart 2 of those environments on a nightly, scheduled basis.
So, I do believe the parameter does it´s job, since the nightly restarts haven´t done the trick :-)

collaborationben said...

Fair comment. I wasn't seeing the exceptions you saw so probably different causes. Interestingly "ldapaclattribute" is a variable defined when you integrate with Connections Files. When I integrated Sametime meetings and Connections I didn't update this value, maybe that is why it didn't work and I haven't revisited since!

Tim E. Brown said...

I have this same issue on my current ST 8.5.2 IFR1 meeting server. This setting you mention does not exist there. Any other ideas?

Tim E. Brown

Robert Farstad said...

CollabBen: Aha, cool, you should check that parameter and revisit the cnx + sametime config once more. Tell me how it goes :-)

Robert Farstad said...

Tim: I don´t have a environment to compare with anymore. But what you could do in is just add the parameter into the meeting server config. Perhaps it should be there but it´s not.

Does´nt hurt to try :-)