none
Lync 2013 and XMPP Federation with GTalk (error 32014)

    Question

  • Hi,

    when I try to contact a Gmail contact I've got this error in the eventviewer : source LS XMPP Translating Gateway Proxy, ID : 39013.

    The public certificate on the Edge seems correct, the SRV DNS record has been set and XMPP federation is active in the topology. The Partner has been set :

    Get-CsXmppAllowedPartner

    Identity                   : gmail.com
    AdditionalDomains          : {}
    Domain                     : gmail.com
    ConnectionLimit            :
    Description                : GTalk
    EnableKeepAlive            : False
    ProxyFqdn                  :
    SaslNegotiation            : NotSupported
    SupportDialbackNegotiation : True
    TlsNegotiation             : NotSupported
    PartnerType                : PublicUnverified

    Using OCSLogger and Snooper, I've got those traces (I found nothing in Google with this error code):

    TL_ERROR(TF_COMPONENT) [0]0238.100C::01/17/2013-09:19:14.102.0000025a (XmppTGWProxy,XmppEndPointSink.HandleInternalErrorForOutgoingStanza:108.idx(293))

    (0000000002ECC2EF)message outgoing stanza from vrivoire@logfi.fr to vincent.rivoire@gmail.com, MS diagnostic code: [32014]

    Any idea to continue the debug?

    Thanks,

    Vincent
    Thursday, January 17, 2013 9:30 AM

Answers

  • Hi,

    Please double check the DNS record. Here is a similar case just for your reference. As spat3 said, he has a DNS record (sip.domain.com) for an old OCS R2 FE server and this conflict with FQDN of Edge server.

    http://social.technet.microsoft.com/Forums/en-US/lyncinterop/thread/dfabef1d-813d-45eb-926f-6a3f703617fb


    Kent Huang
    TechNet Community Support

    • Marked as answer by Kent-Huang Tuesday, February 05, 2013 8:32 AM
    Friday, January 18, 2013 8:59 AM
  • The Technet can be a "little" misleading. I've recently worked through this myself.

    Lync allows you to configure a seperate XMPP Edge pool for load balancing purposes. In most consolidate edge servers you'll have a single Access Edge FQDN.

    So your SRV record should look like this _xmpp-server._tcp.contoso.com = sip.contoso.com.

    If you move to another edge pool for XMPP connectivity (more along the lines with Technet). You'll have xmpp.contoso.com = Edge Pool XMPP IP Address and your SRV record _xmpp-server._tcp.contoso.com = xmpp.contoso.com. With this configuration the "xmpp.contoso.com" will need to be in the SAN list on the certificate, which is on the Edge pool providing XMPP.


    Microsoft fan since 93'

    • Proposed as answer by Kent-Huang Tuesday, February 05, 2013 8:32 AM
    • Marked as answer by Kent-Huang Tuesday, February 05, 2013 8:32 AM
    Thursday, January 31, 2013 1:36 AM
  • I found the cause of my error with the help of Microsoft Support.

    On my Edge Server, I had installed an Update for Root Certificates (KB931125) because some companies I'm federated with are using not well known AC. My store was containing more than 120 root certificates. I had a Schannel warning saying that the list of certificates was truncated (I didn't see it at first time).

    The replication between my front end and the edge was not working, so the settings about XMPP were not send to the edge.

    After cleaining the certificates store, everything is working.

    The cleaning part is detailed here : http://social.technet.microsoft.com/Forums/en-US/ocsedge/thread/1cd3be72-1f65-48ae-aa8c-498f79917492

    Tuesday, February 05, 2013 8:57 AM

All replies

  • Hi,

    Please double check the DNS record. Here is a similar case just for your reference. As spat3 said, he has a DNS record (sip.domain.com) for an old OCS R2 FE server and this conflict with FQDN of Edge server.

    http://social.technet.microsoft.com/Forums/en-US/lyncinterop/thread/dfabef1d-813d-45eb-926f-6a3f703617fb


    Kent Huang
    TechNet Community Support

    • Marked as answer by Kent-Huang Tuesday, February 05, 2013 8:32 AM
    Friday, January 18, 2013 8:59 AM
  • Hello, I've double checked the DSN records, everything seems right.

    My error code is not the same as spat3.

    Tuesday, January 22, 2013 6:52 PM
  • The Technet can be a "little" misleading. I've recently worked through this myself.

    Lync allows you to configure a seperate XMPP Edge pool for load balancing purposes. In most consolidate edge servers you'll have a single Access Edge FQDN.

    So your SRV record should look like this _xmpp-server._tcp.contoso.com = sip.contoso.com.

    If you move to another edge pool for XMPP connectivity (more along the lines with Technet). You'll have xmpp.contoso.com = Edge Pool XMPP IP Address and your SRV record _xmpp-server._tcp.contoso.com = xmpp.contoso.com. With this configuration the "xmpp.contoso.com" will need to be in the SAN list on the certificate, which is on the Edge pool providing XMPP.


    Microsoft fan since 93'

    • Proposed as answer by Kent-Huang Tuesday, February 05, 2013 8:32 AM
    • Marked as answer by Kent-Huang Tuesday, February 05, 2013 8:32 AM
    Thursday, January 31, 2013 1:36 AM
  • I found the cause of my error with the help of Microsoft Support.

    On my Edge Server, I had installed an Update for Root Certificates (KB931125) because some companies I'm federated with are using not well known AC. My store was containing more than 120 root certificates. I had a Schannel warning saying that the list of certificates was truncated (I didn't see it at first time).

    The replication between my front end and the edge was not working, so the settings about XMPP were not send to the edge.

    After cleaining the certificates store, everything is working.

    The cleaning part is detailed here : http://social.technet.microsoft.com/Forums/en-US/ocsedge/thread/1cd3be72-1f65-48ae-aa8c-498f79917492

    Tuesday, February 05, 2013 8:57 AM