[cisco-voip] Jabber connecting to global catalog servers across slow wan links

[Brian V]

Observed with Jabber 12.5 and 12.6.1 (Windows, on Prem IM&P 12.5)

I have a customer with a large WAN with many sites and data centers.  We're
using the default auto-discovery for Windows clients to allow a Jabber on a
Domain-joined Windows workstation to find and select a global catalog
server.

 Not using UDS on the service profile.  Jabber 12.5 and 12.6 GSSAPI
auto-discovery LDAP.

 Jabber clients that are configured for the default Cisco Directory
Integration (CDI) and using the autodiscovery process are performing a
lookup for *_gc._tcp.domain.com <http://tcp.domain.com>* .

What we're seeing is that DNS SRV replies for *_gc._tcp.domain.com
<http://tcp.domain.com>* .  return a list of many servers with equal weight
and priority. (17 at current count) Some of the servers have 150-300 ms
ping times based on where the Jabber client is.

It's not feasible to adjust these weighs since you'd want Jabber clients in
a remote site to use a "close" GC server.  Adjusting priority on DNS SRV
records is not granular enough as it doesn’t account for the location of
the client making the request.

 I spoke to the customer about this and he informed that a native Windows
process running on workstation (Like a Windows Login) doesn't do simple SRV
lookup, but makes an API call to something called "*DC Locator*"  This will
return a list to the Windows client based on the AD Sites and Network
topology.  It's supposed to return the "closest" resource to the client
based on its current network subnet.  A simple DNS SRV request won't do
this.  Basically a SRV lookup is performed but adding in the <site> string
into the FQDN.  Getting that Site returned is the key part to find the
"closest" GC servers to the client. (See the links below for some
background)

 *Cisco should be utilizing this on Windows*.  Implementing the
*DsGetDcName* call API from the MS Locator function to find the best GC
server to connect to .

 I know I could utilize a *jabber-config.xml* file option to specify
*PrimaryServerName* and *SecondaryServerName.*  But these values can't be
correct for all users at all sites, and there is only a primary and
secondary.  This is why good AD design calls for placing Domain Controllers
/ LDAP / GC  across the WAN sites close to the users.

 Below are a few links on the subject.  Some are quite old but this
function hadn't really changed much in 15+ years.

Cisco should be utilizing this on Windows.  Implementing the *DsGetDcName* call
API from the DC Locator function to find the best GC server to connect to .

If this function doesn’t return anything , then perform what it's doing
today.

Not sure if it’s a windows only thing.  I doubt MAC implements it but you
never know.

Has anyone else run into this issue ?

https://searchwindowsserver.techtarget.com/tip/How-the-DC-locator-works-in-Active-Directory

 http://adcoding.com/using-dsgetdcname-in-c-sample/


https://ldapwiki.com/wiki/How%20Domain%20Controllers%20Are%20Located%20in%20Windows
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20190624/2ed11894/attachment.htm>