Hey Everyone,
I’'m looking to transition my organization (~7,500 users) to a Spark/Openfire solution. Let me describe the situation:
*Using Openfire 3.3.2 and Spark 2.5.4
*Integrated into the Active Directory via LDAP
*The usernames for Openfire are based off of the attribute in Active Directory. This is a 9-digit number.
*Everyone’'s names are from the attribute (in the format of “last name, first name”). Other options for names include the first name and last name .
*The “SSO” feature in Spark 2.5.4 works perfectly – the client seems to grab the Windows login session information perfectly.
*User search works ok (more details below). -
ISSUE #1: The Show-Stopper
If a user isn’‘t in my roster, and they IM me, their name doesn’‘t show up at the top of the chat window. Instead, I see “#########@openfire” (where ######### is their 9-digit SSO and “openfire” is the name of the server). However, if I add them to my roster – and erase ######### from the nickname field (leaving it blank) – their nickname shows up as it is defined in the AD. It would appear that Spark isn’‘t looking at the v-card until after a user is added to the roster – however, their email address and worker title show up under the “#########@openfire” name. I know it’‘s a small and picky problem, but its something I must figure out before I transition 7,500 people over to Openfire. I mean, they’'re not going to be happy anyhow (since something they commonly use will be changing drastically), but replacing it with something that has this nagging feature will make it ten times worse. Does anyone have a solution to this? Your help would be much appreciated! -
ISSUE #2: Would Be Nice…
User search in our present IM solution is bad anyhow, so this isn’‘t a show stopper. It would be nice to have it fixed though: I have the full name linked to in LDAP – which has the format of “last name, first name.” In our AD, a user’'s first name is and last name is . This creates an issue…
Let’'s say I want to search for “Justin White.” These searches work:
-
“Justin”
-
“White”
-
“White, Justin”
Yet this one does not work:
- “Justin White”
In our user focus groups, this is the search method people tried most often – and complained about. However, I don’‘t have an LDAP field that has names in this particular format (and I don’'t think I can have one made either).
Any thoughts on this one either? Thanks!!!