<div dir="ltr">With Windows domain joined PCs, EDI over 3268 is the default.  So, are you saying you hard coded 389 somewhere, or that you're not domain joined?  I've seen quite a bit of confusion over jabber-config.xml, UC Service Profile, and Defaults of Jabber.  It's a mess.<div><i><br></i></div><div><i>"Install Cisco Jabber for Windows on a workstation that is registered to an Active Directory domain. In</i></div><div><i>this environment, you do not need to configure Cisco Jabber for Windows to connect to the directory. The</i></div><div><i>client automatically discovers the directory and connects to a Global Catalog server in that domain."</i></div><div>Source: <a href="http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/jabber/11_5/CJAB_BK_C6FFF6D8_00_cisco-jabber-115-planning-guide.pdf">Jabber 11.5 Planning Guide</a></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Apr 20, 2016 at 11:04 PM, Daniel Ohnesorge via cisco-voip <span dir="ltr"><<a href="mailto:cisco-voip@puck.nether.net" target="_blank">cisco-voip@puck.nether.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="font-size:10pt;font-family:Verdana,Geneva,sans-serif">
<p>Hi Guys,</p>
<p>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;</p>
<p><em>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]</em><br><em>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</em><br><em>2016-04-21 13:00:52,505 DEBUG [0x00002358] [rdsource\ADPersonRecordSourceLog.cpp(50)] [csf.person.adsource] [WriteLogMessage] - QueryResultsConverter::ConvertResultSet - processing handle [162896744]</em><br><em>2016-04-21 13:00:52,521 WARN [0x00002358] [rdsource\ADPersonRecordSourceLog.cpp(42)] [csf.person.adsource] [WriteLogMessage] - QueryResultsConverter::ConvertResultSet - Query Results Failed - COMException [0x80072030]</em></p>
<p><span>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:=<a href="tel:2147483648" value="+12147483648" target="_blank">2147483648</a>))(sAMAccountName=test group*)) the result comes up fine.</span></p>
<p>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.</p>
<div> </div>
</div>
<br>_______________________________________________<br>
cisco-voip mailing list<br>
<a href="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</a><br>
<a href="https://puck.nether.net/mailman/listinfo/cisco-voip" rel="noreferrer" target="_blank">https://puck.nether.net/mailman/listinfo/cisco-voip</a><br>
<br></blockquote></div><br></div>