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
_______________________________________________ cisco-voip mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-voip
