Lync, XMPP and Google Apps Domain Talk Service Validation Errors

In my original XMPP post, I discussed how to troubleshoot TLS errors relating to Lync and the Microsoft OCS 2007 R2 XMPP gateway. If you believe you’re having TLS related issues, please refer to my previous post. This blog will focus on Lync troubleshooting techniques and Google XMPP responses when establishing federation between the two environments. 

Background

A Lync 2010 architecture was deployed with an XMPP server for instant messaging federation to Google (gmail.com and other Google App domains).  Once the XMPP service was deployed, my customer started receiving the infamous “presence unknown” for Google contacts.  For the purposes of this blog, let’s say the Lync SIP domain (chi.contosouniversity.edu) was used by faculty and the Google Apps domain (gmail.com & contosouniversity.edu) was used by the student population.  Side note… Let’s be real, everyone should be using Lync at this point… Anyways, moving on.
The environment was built to spec, but when Lync users tried to add Google users (gmail.com or contosouniversity.edu) they would simply receive “presence unknown.”  If you didn’t catch it previously, the Lync SIP domain (chi.contosouniversity.edu) is a sub-domain of contosouniversity.edu.  The root domain (contosouniversity.edu) was enabled for Google Apps Talk Service. 
Long story short, the presence issue was caused by a misconfiguration in the Google Apps portal prior to the Lync deployment.  The sub-domain (chi.contosouniversity.edu) was mistakenly enabled for the Google Apps Talk Service.  Unfortunately at the time, I did not have access to the Google Apps Portal.  If you fall into the same boat, below are the troubleshooting techniques that can be used to pinpoint the misconfiguration.
The architecture looks similar to:

 

Troubleshooting Overview

To begin troubleshooting, we’ll first start tracing on the XMPP gateway.

• Log onto the XMPP server
• Navigate to C:\Program Files\Microsoft Office Communications Server 2007 R2\XMPP Gateway\Tracing
• Double-click Snooper

• Once the Office Communications Server 2007 R2 Logging Tool appears, select the following options:
  • OCSXMPPGateway
    • Level – All
    • Flags – All Flags
  • S4
    • Level – All
    • Flags – All Flags
• Finally, click the Start Logging button
• Attempt to send an IM from a Lync user to a Gmail user
  • In the example trace provided below, the Lync user is joe@chi.contosouniversity.edu and the Google Apps user is sarah@contosouniversity.edu

• After the instant message fails, click Stop Logging
• Click View Log Files
  • If you mistakenly click Analyze Log Files, the snooper trace will be blank as shown in the figure below

Revolutionize Your Business With Generative AI

From product design and software development to virtual agents, content creation, and reporting, GenAI is transforming business. Our AI experts help you unlock GenAI’s full potential and drive growth.

Let’s Get Started

Once the log file appears, sift through the log and the snippet should appear similar to the one below. 

 
Sifting through the trace, one can quickly tell that the captured trace is not extremely helpful in telling us what exactly caused the communication to fail. While we see a 481-Call Leg/Transaction Does Not Exist and Connection failed to contosouniversity.edu (or gmail.com, etc.) on port 5269 on Connection timer elapsed so removing Outgoing Queue and Outgoing Connection error, one might assume there is a communication issue between the Lync Edge server(s) and XMPP gateway or between the XMPP gateway and Gmail… Well, not so fast.
To ensure firewall rules are open, I first recommend establishing an external telnet session to the external IP address assigned to the XMPP gateway on port 5269. This connection should be successful. Next, I recommend establishing a telnet session from the XMPP gateway to the following Google XMPP servers on port 5269. Again, the majority of these connections should be successful.

• xmpp-server.l.google.com
• alt1.xmpp-server.l.google.com
• alt2.xmpp-server.l.google.com
• alt3.xmpp-server.l.google.com
• alt4.xmpp-server.l.google.com

If all telnet sessions are successful and you’re still questioning why IMs are failing, switch gears and open Network Monitor on the XMPP gateway.  If you were like me previously, you probably do not have the NtSimpleSearch Expert installed.  You can quickly tell by clicking the Experts tab near the top menu.  If all you see is Download Experts, you have your answer.

To make this process easier, navigate to the MSDN NMSimpleSearch website to download the expert.  Once the NMSimpleSearch Expert has been installed, it should appear under the Experts window.

Forget the NMSimpleSearch Expert for a moment and start a new network capture. Send another IM from a Lync user to a Gmail user.  Once the trace is stopped, the cause to our 481-Call Leg/Transaction Does Not Exist error will actually be returned from Google’s XMPP servers.  To find the answer, you can 1) manually read through each packet inspecting the Hex details for the following XML information…
<stream:error><undefined-condition xmlns=”urn:ietf:params:xml:ns:xmpp:-streams”/><str:text xmlns:str=”urn:ietf:params:xml:ns:xmpp-streams”>chi.contosouniversity.com is a Google Apps Domain with Talk Service enabled.</str:text></stream:error></stream:stream>
… or 2) use the NtSimpleSearch Expert to locate error. 
Assuming you want to save yourself the headache, I’ll proceed with option 2. 

• To use NtSimpleSearch, first save the network trace.
  • When saving the file, ensure All captured frames is selected

• Once the trace has been saved, close and reopen Network Monitor
• Open the previously saved network capture
• Select Experts | NtSimpleSearch
• Once the NmSimpleSearch dialog box appears, enter Google Apps in the search field

If we’re troubleshooting the same issue, at least one instance should be found.

Lo and behold, Google is telling the Microsoft XMPP gateway that the domain (chi.contosouniversity.edu) is a Google Apps Domain with Talk Service enabled. 

There you have it!  Simply disable the Talk Service for the appropriate domain(s) in the Google Apps portal and instant messages should start working.

Comments Welcomed.