Cisco Jabber logs analysis
It’s been quite a while since I have written something, so I thought to write on how to read the logs (jabber) for rookies. I am going to discuss the on-premise version: The most important of all in jabber are the SRV records must be discoverable and updated correctly in DNS. Because, these can make your MRA connectivity insane, as the goal of service discovery is to find the primary source of authentication, select the operating mode( Cloud or on-premises), subscribe to UC services, determine the location( inside or outside the organization) and discover the UC services domain, respectively.
For the Service Discovery Flow:
User Launches Client >> Client determines service domain >> client checks if the network is inside or outside the firewall>> client sends the HTTP request to check for Webex services >> If no Webex services found >> Client looks for SRV record: _cisco-uds, _cuplogin >> If none of the records are found it checks for the expressway is it available? If not then it prompts the user to manually enter connection details.
Here Jabber sends both DNS queries and HTTPS requests simultaneously, among all the returned requests the record with the highest priority would be used for connecting to UC services.
|Priority||Service||HTTP Request / DNS SRV|
|1||WebEx Messenger||HTTP CAS lookup|
|2||Unified CM 9.x||_cisco-uds._tcp <domain name>|
|3||Cisco Presence 8.x||_cuplogin._tcp <domain name>|
|4||Cisco Expressway||_collab-edge._tls <domain name>|
Edge determines whether the jabber is inside or outside the organization/ corporate firewall, which is entirely based on the records returned from the DNS.
- If _cisco-uds SRV record returns an address, this determines that jabber is inside the organization network.
- If _collab-edge SRV record lookup returns an address: Jabber determines that it is outside the organizations’ network. HTTP transform all traffic and route through expressway-e.
That was the basics of a part of the jabber tshoot. First, we need to generate a problem report. Open your jabber client >> settings >> help >> report a problem >> select a problem type for the drop-down menu >> enter the problem summary >> click save. For crash issue troubleshooting, we require to check the Memory box otherwise it is not required.
- Open the .ZIP file which you have saved on your system. It looks like this:
2. jabberAllConfig.xml contains all configuration from service discovery, the service profile, and the jabberconfig.xml file.
3.jabberAllContacts: This is a listing of all contacts of the Jabber user and all contact details for each user.
4.DiagnosticsContent – This HTML file is the Jabber Diagnostics tool output at the time of problem report creation.
5.gdi.txt – this log contains kernel access information for Jabber to use locally.
6. Jabber.log – these files are the Jabber client logs and are the most important as most of the client activities are logged in here.
7. Metadata.txt – contains the Username, login mode, client version, IM Address
8. PRT.txt – Log showing the execution and internal workings of the Jabber Problem Reporting Tool.
All detailed discovery-related logs have [csf.dns] or [service-discovery] logger name in them:
- 2020-12-31 15:49:42,146 INFO [0x00002e14] [rc\dnsutils\win32\win32DnsUtils.cpp(343)] [csf.dns] [csf::dns::DnsUtils::executeSRVRecordQuery] – About to make DNS SRV record query ‘_cisco-uds._tcp.<domain.com>.’
- Discovery Failed – 2020-12-31 16:06:29,445 WARN [0x00000848] [vices\impl\DiscoveryHandlerImpl.cpp(681)] [service-discovery] [CSFUnified::DiscoveryHandlerImpl::handleFailedDiscoveryResult] – Discovery failed: ServiceDiscoveryNoSRVRecordsFound.
- 2020-12-30 09:26:51,788 WARN [0x00000688] [vices\impl\DiscoveryHandlerImpl.cpp(719)] [service-discovery] [CSFUnified::DiscoveryHandlerImpl::callOnFailedDiscoveryResultOnDispa tcherThread] – Discovery Failure:: (1005) ServiceDiscoveryNoSRVRecordsFound.
- Here 1005 ID denotes that NO SRV records were found.
- User Inactive in LDAP – INFO [http-bio-443-exec-15] handlers.LoginHandlerNonSSO – doLogin:End user status is INACTIVE for kanishkas| IMS result code:7
- Incorrect Password – INFO [http-bio-443-exec-15] handlers.LoginHandlerNonSSO – doLogin:Wrong credential for kanishkas| IMS result code:1
- cisco-uds: this provides the location of CUCM: It shows here failed2020-12–29 15:49:53,427 WARN [0x00009fd8] [src\dnsutils\win32\win32DnsUtils.cpp(52)] [csf.dns] [csf::dns::mapFromWindowsDNSResult] – *—–* DNS query _cisco-uds._tcp.ap. com. has failed: DNS name does not exist (9003).
- Cannot communicate with server2020-12-29 15:50:45,301 ERROR [0x0000ee54] [indowplugin\lifecyclecontroller.cpp(713)] [HubWindowPlugin] [LifecycleController::DisplayError] – LifecycleController::DisplayError – Cannot communicate with the server.Service Discovery Failure Codes:
- 1001 >> Service Discovery Failure >> This is generally a DNS issue.
- 1002 >> Service Discovery Authentication Failure >> Failed to authenticate with CUCM
- 1003 >> Failed to connect with CUCM Server >> cannot connect with CUCM
- 1004 >> Service Discovery No CUCM configuration >> CUCM is misconfigured
- 1006 >> Service discovery cannot connect with edge >> cannot connect to an expressway edge server
- 1007 >> No network connectivity >> ensure the system has network connectivity and can reach the DNS.To ensure the SRV records are available, we could do nslookup from the system:Open the command prompt >> type nslookup >> then type “set type=srv”
I hope this would have been informative for you and I’d like to thank you for viewing.
Happy New Year !!
Published by Team UC Collabing
CCNA Routing and Switching
I am a technology enthusiast. I work in network support providing support with implementation, maintaining and precisely troubleshooting the infra. Am having 3.9+ years of experience working with Cisco Collaboration platforms: CUCM, Cisco Unity Connection, IM and Presence, VCS C and E, Expressway C and E, Cisco Meeting Server,Solarwinds, Gateways. Realm of collaboration makes me want to learn and face new challenges more and more. Feel free to reach out to me.