Cisco Jabber for Windows - Global Catalogue Servers DNS

[Carl Ratcliffe]

Hi Support Community

We have 50 offices around the world and all use local domain controllers for DNS however when someone does a directory lookup in Jabber we are getting intermittent slow responses. Investigations show this is because the local Jabber client is connecting to a DNS server for directory lookups at the other side of the world.

Now it seems Jabber is looking for global catalogue servers using for example  _gc._tcp.test.domain.local with the domain part being the client PC domain. However it looks as though Jabber has been hard coded to make the assumption the global catalogue server response is going to come from this PC domain when actually in our case it needs to query the root domain so  _gc._tcp..domain.local 

As _gc._tcp.test.domain.local gets no response it then queries   _ldap._tcp.test.domain.local which just returns all global catalogue servers and then it chooses one at random DNS server which could be anywhere in the world.

So the question is, how do we get Jabber for Windows to query for global catalogue servers in the root domain ?

Thanks, Carl Ratcliffe

Preston Lancashire England

[Mark Swanson]

It depends on your deployment of Cisco Jabber. What version of IM&Presence and Cisco Jabber do you have? Which mode is Cisco Jabber running; Full-UC, IM-Only or Phone? What type of SRV (i.e. _cisco-uds, _cuplogin or _collab-edge) do you advertise via DNS?

Your jabber-config file might contain Directory information, so this might explain why. The jabber-config file applies to all users... unless you create a custom jabber-config files. Within the jabber-config file, you can specify a type of Directory Server (i.e. BDI, EDI, UDS and now, CDI), the Connection Type... (0) default is GC whereas (1) is DC, primary and secondary Directory Server Names, ports and so on.

Therefore, if you specified a primary Directory Server within the jabber-config file... then, all users would reference this Directory Server. Likewise, if you simply advertise the domain as the primary Directory Server... then, users would randomly select a Directory Server upon logging into Cisco Jabber.

Are you using Service Profiles? If not, please reference the link below;

http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/jabber/11_0/CJAB_BK_C04C09E7_00_cisco-jabber-110-planning-guide/CJAB_BK_C04C09E7_00_cisco-jabber-110-planning-guide_chapter_0101.html

[Carl Ratcliffe]

Hi Mark

First of all thanks for taking the time to respond.

We use IM&P 11.5 with JFW 11.8 however the same thing happens with any version of IM&P and JFW combination and we use full UC mode for 95% of our users.

Service Discovery is done via _cisco-uds and this all works fine and I'm pretty sure is unrelated to the directory lookups.

We use CDI and we don't specify anything in our Jabber .xml in relation to directories except an OU search base and we have actually tried using "Connection Type... (0) default is GC whereas (1) is DC" and changing the default from 0 to 1 however this just means you can then specify LDAP servers to use. Now the problem with doing this is we have offices in 50 countries with local DC's so it would be un-manageable.

Jabber doesn't seem to work the same way as other applications in that it can search the forest and select its local domain controllers it seems to be hardcoded ( at least I cant find any way of changing it ) to look for global catalogue servers in the machine domain - gc._tcp.example.domain . Our global catalogue servers are in the root domain and I know this isn't uncommon but when it cant resolve the global catalogue DNS query in the machine domain its forced to use LDAP which will just return a random server anywhere in the world hence a London Jabber client using a Sydney DC.

If we could tell the Jabber client to look in the root domain for GC's then I'm pretty sure it would be as simple as that but there doesn't seem to be a way ?

Thanks, Carl Ratcliffe

Preston Lancashire England

[dion_austrade]

Hi Carl,

Did you hear back anything from Cisco about this?

We are in the same boat, where we have 70+ global offices, each with local DC infrastructure.

SRV lookup chooses something on the other side of the world..

Apart from using a separate Jabber-config file for each different location & specifying the local DC, I don't see another way to do it..

Cheers!

Dion

[Carl Ratcliffe]

Hi Dion

Still no update from Cisco I'm afraid. Please see below bug details, although they are calling it a feature enhancement not a bug. Not sure how they can say this when it was available in 11.7 and not 11.8.

Its not good that they make the assumption that everyone is on a flat domain, this causes very poor performance when you have Jabber deployed globally.

The bug has up to 11.8.3 in the affected versions although I have tried 11.8.4 and confirm this doesn't work either. 11.8.5 is out now but not had time to test this yet.

https://bst.cloudapps.cisco.com/bugsearch/bug/CSCve46086/?referring_site=bugquickviewredir

Thanks, Carl Ratcliffe

[dion_austrade]

Hi Carl,

Thanks for the reply,

I will save you the suspense :)

Just tried this and Wireshark shows still just a standard SRV request.. and chose a DC half a world away..

No idea why they took this out..

thanks again!

Dion

[Carl Ratcliffe]

Hi Dion

Jabber for Windows 11.9.0 has just been published however the issue still exists in this version as seen in the open caveats for the release notes.

Open Caveats in Release 11.9

Identifier	Severity	Headline
CSCve40856	3	Desktop share button is grayed out during a call (BFCP) via MRA.
CSCve70085	3	Unable to check alerts when Available, for contacts not part of the contact list.
CSCve71805	3	Jabber for Windows takes focus from any application being used after a call ends.
CSCve72240	3	Search result display window occasionally does not show the Directory Contacts.
CSCve79355	3	Jabber crashes while calling MAPILogonEx in Citrix VMware.
CSCve86254	3	Unable to send a response to re-invite for transfer on Jabber Softphone.
CSCve99283	3	Unable to paste more than one number into the dial pad or dock window.
CSCvf31386	3	Jabber for Windows 11.8.4 crashes when directory (ldap) connection is not established.
CSCvf24293	3	Contact list cache not set to expire after 24-hours.
CSCvf26291	3	Jabber video stuck on Surface Pro 4 with Win10 Creator Updates if the camera is switched quickly.
CSCvf32185	3	Jabber incorrectly sends DTMF flash event even when peer doesn't support it.
CSCve57321	3	Jabber 11.8 unable to search users from multiple domains.
CSCvc87612	3	Call filter list view error for screen reader.
CSCvf42432	3	Cyrillic letters are encoded and garbled while in deskphone control mode.
CSCvf28619	3	Invalid warning message shown when chatting with a blocked user.

[Carl Ratcliffe]

I do also have a TAC case open for this and we were initially asked to disable UPN in the install and test again however this didn't make a difference so TAC are making further investigations.

[Carl Ratcliffe]

Finally got an answer from Cisco TAC and it seems it is an enhancement feature that was added then removed and has been requested to be put back.

The feature was made available in JFW 11.7 then removed in JFW 11.8  - not sure on the logic of this whoever decided it. In a large global environment how can this feature not be a requirement !

Need Site aware/specific directory source search Jabber 11.8 CSCve46086

Symptom:
Jabber 11.8 does not use the Microsoft API anymore to discover the directory source/domain instead uses the following options

-- USERDNSDOMAIN system variable.
-- LdapUserDomain parameter in the jabber-config.xml file.
-- The domain from the email address used to log into the client.

Beacuse of this change, Jabber is unable to do DNS SRV query based on site specific/aware. Jabber 11.8 uses _gc._tcp.domain.com and _ldap._tcp.domain.com which is not site specific. This feature was available with Jabber 11.7 which does dns srv on _gc._msdcs._tcp.domain.com and _ldap._msdcs._tcp.domain.com.

This is an enhancement request to implement the feature back in Jabber 11.8

Conditions:
If Directory search should be done based on site specific/aware

Workaround:
include local DC's in the DNS SRV results

Further Problem Description:
n/a

Thanks, Carl Ratcliffe

Preston Lancashire England