[cisco-voip] Jabber Directory Groups over port 3268

[daniel at ohnesorge.me]

Hi Guys, 

Just as a quick FYI, Jabber 11.0 - 11.5 doesn't seem to be able to
search for Directory Groups over port 389. CUCM>System>LDAP>Directory is
currently synced with port 389 and all User Groups (distribution groups
from AD) sync over fine. However when searching in Jabber using EDI over
port 389, the Groups don't show up. This is what we see in the logs; 

_2016-04-21 13:00:52,505 DEBUG [0x00002358]
[rdsource\ADPersonRecordSourceLog.cpp(50)] [csf.person.adsource]
[WriteLogMessage] - ConnectionManager::ExecuteQueryOnGroupSearchers -
Succeeded - Query string:
[(&(objectCategory=group)(!(groupType:1.2.840.113556.1.4.803:=2147483648))(sAMAccountName=test
group*))], Attributes: [sAMAccountName]_
_2016-04-21 13:00:52,505 DEBUG [0x00002358]
[rdsource\ADPersonRecordSourceLog.cpp(50)] [csf.person.adsource]
[WriteLogMessage] - QueryManager::ExecuteQuery - Query executed - about
to convert the results_
_2016-04-21 13:00:52,505 DEBUG [0x00002358]
[rdsource\ADPersonRecordSourceLog.cpp(50)] [csf.person.adsource]
[WriteLogMessage] - QueryResultsConverter::ConvertResultSet - processing
handle [162896744]_
_2016-04-21 13:00:52,521 WARN [0x00002358]
[rdsource\ADPersonRecordSourceLog.cpp(42)] [csf.person.adsource]
[WriteLogMessage] - QueryResultsConverter::ConvertResultSet - Query
Results Failed - COMException [0x80072030]_ 

0x80072030 means 'There is no such object on the server'. However, if I
use any LDAP Explorer and use the filter
(&(objectCategory=group)(!(groupType:1.2.840.113556.1.4.803:=2147483648))(sAMAccountName=test
group*)) the result comes up fine. 

Based on some research, I think the relevant Bug ID's are CSCuu47641,
CSCuu48043 and CSCuu48329 with the last 2 being internal bugs. All bugs
have little to no useful information. Work around is to use port 3268
and the Groups show up straight away. 
  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20160421/a1d44ced/attachment.html>