microsoft€¦ · web viewauthor katrina purcell last modified by v-keblue created date 6/9/2011...

This document is provided “as-is”. Information and views expressed in this document, including URL and other Internet Web site references, may change without notice.

Some examples depicted herein are provided for illustration only and are fictitious. No real association or connection is intended or should be inferred.This document does not provide you with any legal rights to any intellectual property in any Microsoft product. You may copy and use this document for your internal, reference purposes.

Copyright © 2011 Microsoft Corporation. All rights reserved.

Microsoft, Lync, Windows, and Windows PowerShell are trademarks of the Microsoft group of companies. All other trademarks are property of their respective owners.

Microsoft Lync Server 2010 Resource Kit Interoperability with XMPP Systems Using the XMPP Gateway

This chapter is part of the Microsoft Lync Server 2010 Resource Kit book that is currently being developed. Chapters will be available for download while this book is being completed. To help us improve it, we need your feedback. You can contact us at [email protected]. Please include the chapter name.

For information about the continuing release of chapters, check the DrRez blog at http://go.microsoft.com/fwlink/?LinkId=204593.


ContributorsProject Manager: Susan S. Bradley Content Architect: Rui Maximo Chapter Lead: Rob PittfieldTechnical Reviewers: Amey Parandekar, Chris Eagan, Jason Bubolz, Jerome Berniere, Lekshmi Menon, Stuart BirkettLead Editor: Katrina PurcellArt Manager: Jim BradleyProduction Editor: Kelly Fuller Blue


Table of ContentsContributors................................................................................................................................................4

Introduction.................................................................................................................................................6

Scenarios.....................................................................................................................................................6

Adding a Contact.................................................................................................................................6

Updating Presence...............................................................................................................................7

Sending a Message..............................................................................................................................8

Internals......................................................................................................................................................9

Capturing SIP and XMPP Traffic to and from The XMPP Gateway.........................................................10

Adding an XMPP Contact and Subscribing to Presence.........................................................................10

Composing Notification.........................................................................................................................14

Sending Messages.................................................................................................................................15

Troubleshooting....................................................................................................................................16

Planning.....................................................................................................................................................19

Configuration.............................................................................................................................................19

Configure Edge Server.......................................................................................................................20

Configure XMPP Gateway..................................................................................................................21

Firewall, Port, and Protocol Requirements........................................................................................26

Verify the Configuration....................................................................................................................27

Summary...................................................................................................................................................27

Additional Resources.................................................................................................................................27


IntroductionThe Microsoft® Office Communications Server 2007 R2 Extensible Messaging and Presence Protocol (XMPP) gateway enables Microsoft® Lync™ 2010 users to use instant messaging (IM) with and view presence of users who are using XMPP systems such as Google Talk and Jabber. This chapter focuses on ways to deploy, troubleshoot, and gain a deeper understanding of how the XMPP gateway functions. As of the publication of this chapter, the supported version of the XMPP gateway that works with Lync 2010 is the Office Communications Server 2007 R2 XMPP gateway. This chapter focuses on interoperability between Lync 2010 and this gateway.XMPP is an XML-based protocol for exchanging messages in real time. It allows for users to exchange messages and presence. The major Request for Comments (RFCs) that define it are RFCs 3920 and 3921 (for details, see the “Additional Resources” section later in this chapter), although there are several other XMPP protocol-related RFCs. The XMPP gateway converts SIP traffic from Microsoft® Lync™ Server 2010 to the XMPP protocol. It allows for IM and presence related communications between Lync users and users on XMPP services.The XMPP gateway currently supports the following XMPP servers and services:

Jabber Extensible Communications Platform (Jabber XCP 5.4) Gmail.com, googlemail.com, and other available Google Apps domains

ScenariosTo Lync users, adding an XMPP-based contact, viewing that contact’s presence, or exchanging IM with that contact is no different from using Lync to communicate with any other federated contact.

Note: IM and presence are the only supported modalities.

Adding a ContactTo add a contact, type the user name of the person you want to communicate with (for example, [email protected]). When the user name appears in the search results, right-click the name, select Add to Contacts List, and then select the group where you want to place the user.


Figure 1. Adding an XMPP-based contact to the Contacts List

Updating PresenceWhen you change your presence information, XMPP contacts will see your status changes. You will also see your XMPP contacts’ status changes.


Figure 2. Changing presence status

Sending a MessageSending a message to an XMPP contact is the same as sending one to other federated contacts. You double-click the contact to open up a Conversation window, type the message you want to send, and then press Enter.


Figure 3. Sending an XMPP contact an instant message

InternalsThis section contains details of the protocol level traffic that occur between the Lync Edge Server and the XMPP gateway (SIP traffic) and the XMPP gateway and a third-party XMPP partner. The following diagram shows the two legs of traffic and the following details show the relevant protocol traffic that is sent over the wire.

Figure 4. Traffic flow reference

The areas we’ll focus on for traffic are: SIP traffic between the Lync Edge Server and the Office Communications Server 2007

R2 XMPP gateway XMPP traffic between the Office Communications Server 2007 R2 XMPP gateway and

the XMPP partner third-party providerThere are three types of messages that can flow through the XMPP gateway:

Contact additions Presence updates


Sent messagesWe’ll examine how the SIP and XMPP traffic for each of these transactions are translated by the XMPP gateway.There are several limitations to the XMPP gateway that you should be aware of:

Only one SIP domain is supported per deployment. This means that if the Lync deployment has multiple SIP domains there can be only one SIP domain that can federate through XMPP. This is a current limitation in the XMPP gateway.

Enhanced presence is not shown on the XMPP network because there are differences between the implementations of presence and status indicators. For a full description of the mapping of presence states between Lync and XMPP, see Planning Deploying and Administering XMPP Gateway, which you can download with “Microsoft Office Communications Server 2007 R2 XMPP Gateway” from http://go.microsoft.com/fwlink/?LinkId=220444.

Lync Server 2010 cannot federate with an XMPP server with the same domain name. The SIP domain name and the XMPP domain name must be different. The following modalities, group IM, conferencing, and Enterprise Voice do not interoperate with XMPP by using the XMPP gateway. Only two-party IM and presence is supported with the XMPP gateway.

Capturing SIP and XMPP Traffic to and from The XMPP GatewayThere may be times when messages between Lync users and XMPP users fail, presence is inconsistent or failing, and the issue isn’t immediately presenting itself. In these cases it’s helpful to capture the SIP and XMPP traffic to find out where the issue lies. To capture the traffic sent across the XMPP gateway, do the following:

To capture the SIP traffic between the Edge Server and the XMPP gateway, use OCSLogger on the Edge Server to collect SIPStack tracing, or use OCSLogger on the XMPP gateway to collect S4 tracing. After you’ve captured the SIP traffic, use Snooper to view the traffic. For details about how to collect logs on the XMPP gateway, see the “Troubleshooting” section later in this chapter.

To view the XMPP traffic, use Network Monitor or another network monitoring tool (for example, WireShark) to capture the network trace of XMPP messages. The network trace is viewable only if you configure the TCP Dialback method with the federated XMPP server. For details about collecting and filtering network traces, see “Troubleshooting XMPP TCP Dialback Issues with the Communications Server XMPP Gateway” in the Office Communications Server 2007 R2 documentation, http://go.microsoft.com/fwlink/?LinkID=220272.

Adding an XMPP Contact and Subscribing to PresenceTo add a contact or subscribe to a contact’s presence, the Lync client sends a SUBSCRIBE message by using the Session Initiation Protocol (SIP). SUBSCRIBE messages are used to subscribe to another user’s presence status. NOTIFY messages are then used to send the actual presence status after the SUBSCRIBE is successful.The following is an example of a SUBSCRIBE message sent by the user, [email protected], to the XMPP gateway by Lync Server to subscribe to the user, [email protected]. SUBSCRIBE sip:[email protected] SIP/2.0FROM: "pkrebs"<sip:[email protected]>;tag=43ba7bea59;epid=85071315ef


TO: <sip:[email protected]>CSEQ: 1 SUBSCRIBECALL-ID: 3e40666bab8f4a35be02e8234d84b830MAX-FORWARDS: 67VIA: SIP/2.0/TLS 192.168.100.10:62348;branch=z9hG4bKD95E3C9F.ED1FED440ABD3CEE;branched=FALSE;ms-internal-info="asAubwv-JvEyTHkkOOhNdIawNKORxE7R_tLy0yhgAA"VIA: SIP/2.0/TLS 172.16.100.13:56284;branch=z9hG4bK23182B93.463222A8E3B02CEF;branched=FALSE;ms-received-port=56284;ms-received-cid=C6C00VIA: SIP/2.0/TLS 172.16.100.5:61848;branch=z9hG4bKCA767509.3D1F0C810ABD3CEE;branched=FALSE;ms-received-port=61848;ms-received-cid=76BC00VIA: SIP/2.0/TLS 192.168.100.254:51024;ms-received-port=51024;ms-received-cid=CD800RECORD-ROUTE: <sip:sip.contoso.net:5061;transport=tls;epid=85071315ef;lr>;tag=17B2AAE3101263915449FE6B737134CCACCEPT: application/msrtc-event-categories+xml, application/xpidf+xml, text/xml+msrtc.pidf, application/pidf+xml, application/rlmi+xml, multipart/relatedCONTACT: <sip:[email protected];opaque=user:epid:7i2uo7tBd1-7iqYdVSS1uAAA;gruu>CONTENT-LENGTH: 457EVENT: presenceSUPPORTED: com.microsoft.autoextendSUPPORTED: ms-piggyback-first-notifyUSER-AGENT: UCCAPI/4.0.7306.0 OC/4.0.7306.0 (Microsoft Office Communicator 2010 (Beta))CONTENT-TYPE: application/msrtc-adrl-categorylist+xmlms-asserted-verification-level: ms-source-verified-user=verified<batchSub xmlns="http://schemas.microsoft.com/2006/01/sip/batch-subscribe" uri="sip:[email protected]" name=""> <action name="subscribe" id="7600352"> <adhocList> <resource uri="sip:[email protected]"/> </adhocList> <categoryList xmlns="http://schemas.microsoft.com/2006/09/sip/categorylist"> <category name="state"/> <category name="services"/> <category name="contactCard"/> <category name="note"/> <category name="calendarData"/> </categoryList> </action></batchSub>The following information from the preceding SUBSCRIBE message shows the user is subscribing to the other user’s presence:EVENT: presence… <action name="subscribe" id="7600352">


… <resource uri="sip:[email protected]"/>The Lync client sends this SIP message to the Lync Front End pool, which forwards it to the Edge Server because the SIP domain name of the recipient, ‘gmail.com’, is not recognized as an internal SIP domain (for example, ‘contoso.net’). Based on its static routing rules, the Edge Server routes the SIP message to the Office Communications Server 2007 R2 XMPP gateway. The VIA headers in the SIP message shows all the server hops the message took before reaching the XMPP gateway. VIA: SIP/2.0/TLS 192.168.100.10:62348;branch=z9hG4bKD95E3C9F.ED1FED440ABD3CEE;branched=FALSE;ms-internal-info="asAubwv-JvEyTHkkOOhNdIawNKORxE7R_tLy0yhgAA"VIA: SIP/2.0/TLS 172.16.100.13:56284;branch=z9hG4bK23182B93.463222A8E3B02CEF;branched=FALSE;ms-received-port=56284;ms-received-cid=C6C00VIA: SIP/2.0/TLS 172.16.100.5:61848;branch=z9hG4bKCA767509.3D1F0C810ABD3CEE;branched=FALSE;ms-received-port=61848;ms-received-cid=76BC00VIA: SIP/2.0/TLS 192.168.100.254:51024;ms-received-port=51024;ms-received-cid=CD800The XMPP gateway translates this SIP message to XMPP and forwards it to the federated XMPP server:<presence from="[email protected]" to="[email protected]" type="subscribe" /> The XMPP response received by the XMPP gateway shows that the subscribe request was successful:<presence from="[email protected]" to="[email protected]" type="subscribed" />Note the reply contains the word “subscribed”. This shows the request was successful.The XMPP gateway then sends a 200 OK SIP response back to the Edge Server to confirm the subscription was successful:SIP/2.0 200 OKFROM: "User1"<sip:[email protected]>;tag=43ba7bea59;epid=85071315efTO: <sip:[email protected]>;tag=c8a78021CSEQ: 1 SUBSCRIBECALL-ID: 3e40666bab8f4a35be02e8234d84b830VIA: SIP/2.0/TLS 192.168.100.10:62348;branch=z9hG4bKD95E3C9F.ED1FED440ABD3CEE;branched=FALSE;ms-internal-info="asAubwv-JvEyTHkkOOhNdIawNKORxE7R_tLy0yhgAA",SIP/2.0/TLS 172.16.100.13:56284;branch=z9hG4bK23182B93.463222A8E3B02CEF;branched=FALSE;ms-received-port=56284;ms-received-cid=C6C00,SIP/2.0/TLS 172.16.100.5:61848;branch=z9hG4bKCA767509.3D1F0C810ABD3CEE;branched=FALSE;ms-received-port=61848;ms-received-cid=76BC00,SIP/2.0/TLS 192.168.100.254:51024;ms-received-port=51024;ms-received-cid=CD800RECORD-ROUTE: <sip:sip.contoso.net:5061;transport=tls;epid=85071315ef;lr>;tag=17B2AAE3101263915449FE6B737134CCCONTACT: <sip:ocsxmppgw.contoso.net:5061>CONTENT-LENGTH: 0EVENT: presenceEXPIRES: 14400ms-asserted-verification-level: ms-source-verified-user=verifiedThe federated XMPP server then replies with the actual status of the federated user as shown in the following:


<presence from="[email protected]" to="[email protected]"> <show>dnd</show> <priority>1</priority></presence>Note the presence state when translated comes across as dnd (do not disturb) inside the <show></show> tags.Finally, the XMPP gateway sends a SIP NOTIFY message back to the Lync client that shows the current presence of the XMPP user:NOTIFY sip:;[email protected];opaque=user:epid:St1wQwJPPFOu2jGeIi2oVAAA;gruu SIP/2.0FROM: <sip:[email protected]>;tag=9df8f48864TO: <sip:[email protected]>;epid=201a3f28aa;tag=162c213697CSEQ: 1 NOTIFYCALL-ID: 7e161a0c81e64f03b668b2eab8855211MAX-FORWARDS: 70VIA: SIP/2.0/TLS 192.168.1.26:49202;branch=z9hG4bK8586391eROUTE: <sip:edge.contoso.net:5061;transport=tls;epid=201a3f28aa;lr>CONTENT-LENGTH: 299EVENT: presenceSUBSCRIPTION-STATE: active;expires=14400CONTENT-TYPE: application/pidf+xmlms-asserted-verification-level: ms-source-verified-user=verified<?xml version="1.0"?><presence entity="[email protected]" xmlns="urn:ietf:params:xml:ns:pidf"> <tuple id="0"> <status> <basic>open</basic> <activities xmlns="urn:ietf:params:xml:ns:pidf:status:rpid-status"> <activity>busy</activity> </status> </tuple> <display-name xmlns="urn:ietf:params:xml:ns:pidf:cipid">[email protected]</display-name></presence>Note the information enclosed in the <activity> </activity> tags. That’s the actual presence of the other user being sent back to the user who requested it. It will vary based on the XMPP user’s presence.The following SIP message shows an example of a Lync client sending a presence update to an XMPP user (logs taken from XMPP gateway):NOTIFY sip:ocsxmppgw.contoso.net:5061 SIP/2.0FROM: <sip:[email protected]>;tag=AF544073TO: <sip:[email protected]>;tag=3b683ff3b1CSEQ: 1 NOTIFYCALL-ID: a4f2f0f8071c4b8cb44985bb39d0e2a5MAX-FORWARDS: 69VIA: SIP/2.0/TLS 192.168.100.10:62348;branch=z9hG4bKDDB57EB7.4A9021F120643D47;branched=FALSE;ms-internal-info="asuL1fxaS7FZe_EpPzbtbJsX-AswnxIZBKLy0yhgAA"


VIA: SIP/2.0/TLS 172.16.100.13:56284;branch=z9hG4bK142E71B5.268191D5F9572D48;branched=FALSE;ms-received-port=56284;ms-received-cid=C6C00CONTENT-LENGTH: 362EVENT: presenceSUBSCRIPTION-STATE: active;expires=27503SUPPORTED: ms-dialog-route-set-updateCONTENT-TYPE: application/pidf+xmlms-asserted-verification-level: ms-source-verified-user=verified<?xml version="1.0" encoding="UTF-8"?><presence xmlns="urn:ietf:params:xml:ns:pidf" xmlns:ep="urn:ietf:params:xml:ns:pidf:status:rpid-status" xmlns:ci="urn:ietf:params:xml:ns:pidf:cipid" entity="sip:[email protected]" > <tuple id="0" > <status> <basic>open</basic> <activities xmlns="urn:ietf:params:xml:ns:pidf:status:rpid-status"> <activity>busy</activity> </activities> </status> </tuple> <ci:display-name>User1</ci:display-name></presence>Note the full qualified domain name (FQDN), ocsxmppgw.contoso.net, in the first line of the Notify. This is the FQDN of the XMPP gateway that’s receiving the message.Note the status of busy in between the <activity> </activity> tags in the preceding section.The XMPP gateway translates this SIP message to XMPP and forwards it to the federated XMPP server:<presence from="[email protected]" to="[email protected]"> <show>dnd</show> <priority>1</priority></presence>Note the presence state when translated comes across as dnd (do not disturb) inside the <show></show> tags.

Composing NotificationThe Lync user starts an IM conversation with an XMPP user. While the Lync user is typing a message, Lync 2010 sends an INFO notification of this activity to the XMPP client as shown in the following (logs taken from XMPP gateway). INFO sip:ocsxmppgw.contoso.net:5061 SIP/2.0FROM: <sip:[email protected]>;tag=1e59370e30;epid=85071315efTO: <sip:[email protected]>;tag=825ea92f85CSEQ: 2 INFOCALL-ID: bf47db68a35e4ab691f402e099ab79f2MAX-FORWARDS: 67VIA: SIP/2.0/TLS 192.168.100.10:62348;branch=z9hG4bK238506C6.216629A624BC8D59;branched=FALSE;ms-internal-info="asok-d6E6WExYqhkoFdLOaDKmBI_WmKWYhLy0yhgAA"


VIA: SIP/2.0/TLS 172.16.100.13:56284;branch=z9hG4bK79B11B0E.098EBE23FDAE7D59;branched=FALSE;ms-received-port=56284;ms-received-cid=C6C00VIA: SIP/2.0/TLS 172.16.100.5:61848;branch=z9hG4bK121BEC51.83EE236024BC8D59;branched=FALSE;ms-received-port=61848;ms-received-cid=76BC00VIA: SIP/2.0/TLS 192.168.100.254:51024;ms-received-port=51024;ms-received-cid=CD800CONTENT-LENGTH: 87SUPPORTED: ms-dialog-route-set-updateSUPPORTED: timerUSER-AGENT: UCCAPI/4.0.7306.0 OC/4.0.7306.0 (Microsoft Lync 2010)CONTENT-TYPE: application/xmlms-asserted-verification-level: ms-source-verified-user=verified<?xml version="1.0"?><KeyboardActivity> <status status="type" /></KeyboardActivity>The relevant fields to show that the Lync user is typing are:<KeyboardActivity> <status status="type" /></KeyboardActivity>The XMPP gateway converts this SIP message to the following XMPP message:</message><message from="[email protected]" to="[email protected]" type="chat"> <x xmlns="jabber:x:event"> <composing xmlns="" /> <id xmlns=""> </id> </x></messageThe relevant field in this message showing the composing notification is: <composing xmlns="" />

Sending MessagesWhen Lync sends an IM, the SIP message is of type MESSAGE containing the IM (in this example, the content of the message is “test”) logs taken from XMPP gateway.MESSAGE sip:ocsxmppgw.contoso.net:5061 SIP/2.0FROM: <sip:[email protected]>;tag=1e59370e30;epid=85071315efTO: <sip:[email protected]>;tag=825ea92f85CSEQ: 4 MESSAGECALL-ID: bf47db68a35e4ab691f402e099ab79f2MAX-FORWARDS: 67VIA: SIP/2.0/TLS 192.168.100.10:62348;branch=z9hG4bK7792368D.4CCAE8DF251C3D5A;branched=FALSE;ms-internal-info="as6d31lfP8r869IUvdTAyFOxkgub_f6MpMLy0yhgAA"VIA: SIP/2.0/TLS 172.16.100.13:56284;branch=z9hG4bK2A589FA3.561B4450FE0D2D5B;branched=FALSE;ms-received-port=56284;ms-received-cid=C6C00


VIA: SIP/2.0/TLS 172.16.100.5:61848;branch=z9hG4bK1C415B74.564FE697251B3D5A;branched=FALSE;ms-received-port=61848;ms-received-cid=76BC00VIA: SIP/2.0/TLS 192.168.100.254:51024;ms-received-port=51024;ms-received-cid=CD800CONTENT-LENGTH: 4SUPPORTED: ms-dialog-route-set-updateSUPPORTED: timerUSER-AGENT: UCCAPI/4.0.7306.0 OC/4.0.7306.0 (Microsoft Lync 2010)CONTENT-TYPE: text/plain; charset=UTF-8;msgr=WAAtAE0ATQBTAC0ASQBNAC0ARgBvAHIAbQBhAHQAOgAgAEYATgA9AE0AUwAlADIAMABTAGgAZQBsAGwAJQAyADAARABsAGcAJQAyADAAMgA7ACAARQBGAD0AOwAgAEMATwA9ADAAOwAgAEMAUwA9ADAAOwAgAFAARgA9ADAACgANAAoADQAms-asserted-verification-level: ms-source-verified-user=verifiedms-archiving: TRUE

Note: Lync Server does not show the actual messages in the SIP Stack tracing output collected through the Lync logging tool. You can tell this is the appropriate message because the CONTENT-LENGTH field is set to 4. That's how many characters are in the message body that our logging does not collect.

The XMPP gateway translates this SIP message into the following XMPP message:<message from="[email protected]" id="Kt9ag126" to="[email protected]" type="chat"> <body>test</body></message> The actual message is shown in the following inside the <body></body> tags: <body>test</body>

TroubleshootingBecause the XMPP gateway interconnects two different protocols (SIP and XMPP), configuration issues can arise in different areas. The following are areas to check when issues arise:

Federation configuration Event logs XMPP gateway Logging using the OCSLogger tool on the XMPP gateway Networking and firewalls Domain Name System (DNS) name resolution Certificate issues

When troubleshooting connectivity issues with the XMPP gateway, the first thing to check is federation configuration on your Edge Server. If federation is working properly with other federated domains, you can eliminate this area as a potential culprit. If federation fails with other federated domains/partners, check your configuration to ensure federation is set up properly.If federation with other federated domains works but not with the XMPP domain, then check the configuration of your XMPP gateway. Review the Lync Server and Office Communications Server 2007 R2 XMPP gateway event logs. Search for errors or other helpful information.If no events in the logs provide any indication of a problem, test the connection between the Edge Server and the XMPP gateway, and then test the connection between the XMPP


gateway and the federated partner as explained in the “Verify the Configuration” section of this chapter. If the SIP connection validation fails, collect S4 logging by using OCSLogger.exe while running the Connection Validation steps. If the XMPP connection validation fails, collect OCSXMPPGateway tracing by using OCSLogger.exe while validating the connection. For details, see the section titled “Verify the Configuration” later in this chapter.To collect S4 or OCSXMPPGateway tracing, perform the following steps:

1. Run the tool: %Program Files%\Microsoft Office Communications Server 2007 R2\XMPP Gateway\Tracing\OCSLogger.exe.

2. Select S4 (if SIP connection validation fails) or OCSXMPPGateway (if XMPP connection validation fails) in the left pane.

3. Click Start Logging to enable tracing.4. Reproduce the connection failure.5. Click Stop Logging.6. Click Analyze Log Files.7. Select S4 or OCSXMPPGateway. 8. Click Open to view the log in Snooper.

If no data is displayed in Snooper, this likely indicates a name resolution or connectivity issue. Try the following:

1. Close Snooper, and go back to OCSLogger.2. Click Open Log Files.3. Select S4, and then click Open to view the log in Notepad.

If no data is displayed in Snooper for OCSXMPPGateway tracing, it’s because the data is not properly formatted for the tool. Click Open Log Files when tracing the OCSXMPPGateway component.To collect the SIP tracing on the Lync Server 2010 Edge Server, On the Start menu, click inside the Search box. Type OCSLogger.exe, and then press Enter. The log to collect in that instance is SIPStack. The method to view the logs is the same as using the OCSLogger.exe tool on the Office Communications Server 2007 R2 XMPP gateway explained previously.Understanding the output of these logs can be challenging. The following are a few tips to help you navigate these logs:

Start from the end of the log file and slowly work your way back to the beginning of the log file until you see an entry that could indicate the symptom to the problem. Examples are locating DNS records or establishing a SIP Transport Layer Security (TLS) session. This process takes patience and practice to get used to, so don’t be discouraged if you can’t immediately find what you’re hoping to find in the log. The following is an example of a timeout error that might have useful information:

TL_INFO(TF_COMPONENT) [0]0548.04D4::11/07/2009-07:53:10.550.000000ff (OCSXMPPGateway,SipStackInterface.BuildErrorResponse:18.idx(2151))

( 00000000012BE968 ) <-- Sending Error 408-Request Timeout, [email protected], [email protected]

Search for TL_ERROR or TL_WARN. Lines in the log file that start with those two words are usually the most helpful way to narrow down an issue.


Use cserror.exe to look up error codes (for example, cserror.exe 0x80092013) shown in the information in the TL_ERROR or TL_WARN entries. You can download this tool with the “Microsoft Lync Server 2010 Resource Kit Tools” at http://go.microsoft.com/fwlink/?LinkId=203466.

If cserror.exe doesn’t return any helpful information because the error is network related or returned by another Windows component, use the err.exe tool. The err.exe tool works the same way as the cserror.exe tool. You can download the “The Microsoft Exchange Server Error Code Look-up” at http://go.microsoft.com/fwlink/?LinkId=220461. The download link states it’s for Microsoft Exchange Server, however this error code tool works for most Windows error codes.

Compare the log file to the log file of a connection that you know works successfully. Note where the log entries diverge. This helps you quickly understand where things went wrong.

If the log file indicates a network issue such as a timeout (preceding log information) or a connection failure, consider collecting a network trace. For details about collecting network traces, see “Troubleshooting XMPP TCP Dialback Issues with the Communications Server XMPP Gateway” in the Microsoft Office Communications Server 2007 R2 documentation, http://go.microsoft.com/fwlink/?LinkID=220272. If you suspect a firewall is blocking connectivity, use telnet to test connectivity to the XMPP gateway from the Edge Server and vice-versa. From the Edge Server, test connectivity to the XMPP gateway on TCP on port 5061:telnet ocsxmppgw.contoso.net 5061Test the opposite direction to ensure TCP connectivity on port 5061 is open from the XMPP gateway to the Edge Server.From the XMPP gateway, test connectivity to a federated XMPP server on TCP port 5269:telnet federatedserver.xmppdomain.com 5269Also, test connectivity to the XMPP gateway from the Internet or from a federated XMPP server on TCP port 5269.Use telnet to test DNS name resolution. If using telnet or the other methods mentioned previously leads you to believe there may be a DNS problem, use the command line tool, nslookup, to try to resolve the appropriate servers (XMPP gateway, Edge Server, or Federated XMPP domains).To resolve the XMPP gateway IP address, run the following command:nslookup ocsxmppgw.contoso.netIf the query is successful, expect to see output similar to this:Non-authoritative answer:Name: ocsxmppgw.contoso.netAddress: 192.168.1.110You can run similar queries for any of the other A records for Lync Edge Servers or even federated XMPP domains to ensure they resolve properly.To resolve DNS SRV records is a bit trickier. Run the following from the command prompt replacing ‘contoso.net’ with your own SIP domain name. nslookupset type=srv_xmpp-server._tcp.contoso.net


If the query is successful, expect to see output similar to this where ocsxmppgw.contoso.net is the FQDN of your XMPP gateway.Non-authoritative answer:_xmpp-server._tcp.contoso.net SRV service location: priority = 20 weight = 0 port = 5269 svr hostname = ocsxmppgw.contoso.netYou can run similar queries for any of the other SRV records like the SRV record for your Lync Server, Edge Server to ensure they resolve as you expect them to.

PlanningBefore the XMPP gateway can be deployed, you must have a functional Lync Server deployment. An Edge Server must be deployed and configured for federation with XMPP domains. The XMPP gateway must be installed on a stand-alone computer running the Windows® Server 2008 SP2 operating system. This server can be configured with one or two network adapters. The preference for using two network adapters is to maintain the SIP traffic on a separate network segment from the XMPP traffic. Only the network adapter assigned to handle the XMPP traffic is exposed to the external firewall. This segments encrypted traffic (SIP TLS) from unsecured traffic (XMPP federation over TCP Dialback).For details about planning for this role, see “Microsoft Office Communications Server 2007 R2 XMPP Gateway” (which includes the “Planning, Deploying, and Administering Office Communications Server 2007 R2, Extensible Messaging and Presence Protocol (XMPP) Gateway” guide) at http://go.microsoft.com/fwlink/?LinkId=220444.

ConfigurationTo configure XMPP federation with Lync Server, follow these steps:

1. Deploy an Edge Server.2. Configure the Edge Server to federate with the XMPP domain.3. Install the XMPP gateway.4. Configure certificates on the XMPP gateway.5. Configure the relevant DNS records.6. Configure the firewalls.7. Test the configuration.

If the Edge Server is already deployed, proceed with configuring federation to the XMPP domain.

1. On the Access Edge Policy tab, create or modify a Remote Access Policy to allow federation.

2. On the Access Edge Configuration tab, enable federation.3. On the Federated Domain tab, add the Federated XMPP domain.

For details about creating and modifying Remote Access Policies and Enabling Federation, see “Configuring Support for External User Access” in the Lync Server 2010 documentation, http://go.microsoft.com/fwlink/?LinkID=220458.


To federate with an XMPP domain, the Edge Server must route traffic for the XMPP domain to the XMPP gateway. The XMPP gateway is then responsible for converting the SIP traffic into XMPP traffic and forwarding to the federated XMPP server.

Configure Edge ServerTo add an XMPP federated domain and configure routing to the XMPP gateway, open Microsoft Lync Server 2010 Control Panel, and then perform the following steps:

1. In the left pane, click External User Access.2. Click Federated Domains in the top navigation bar.3. Click New, and then click Allowed domain. 4. In the Domain name (or FQDN) box, type the XMPP domain you want to federate

with (for example, gmail.com).5. In the Access Edge service (FQDN) box, type the (FQDN) of the XMPP gateway (for

example, ocsxmppgw.contoso.net).6. Specify any relevant comments of your choice in the Comment box.7. Click Commit.

Figure 5 illustrates this configuration in the Lync Server 2010 Control Panel.

Figure 5. Configuring the Edge Server in the Lync Server Control Panel

The same task can be performed from the Lync Server Management Shell:New-CsAllowedDomain –Domain <XMPP domain> –ProxyFqdn <XMPP Gateway FQDN> –Comment “OCS XMPP Gateway”Where:

<XMPP domain> is the domain name you want to federate with (for instance, gmail.com).


<XMPP Gateway FQDN> is the FQDN assigned to the network adapter of the XMPP gateway that will accept SIP traffic from Lync Server.

To view a list of the allowed federated domains, run the following Windows PowerShell™ command:Get-CsAllowedDomain

Configure XMPP GatewayThe installation steps for the XMPP gateway are not detailed here because this process is simple and covered in the product’s documentation (for details, see the section titled “Additional Resources” later in this chapter). However, it is helpful to keep the following tips in mind:

Although configuring the XMPP gateway with two network adapters is supported; only a single network adapter is required.

After you complete the installation wizard, make sure to specify the IP address of your network adapter in the following file: "%ProgramFiles%\Microsoft Office Communications Server 2007 R2\XMPP Gateway\TGWConsoleGUI.dll.config"

This is the configuration file used by the XMPP gateway service. Because setup does not prompt for this information during installation, it can be easily overlooked. The example shows the contents of the config file. Assuming your XMPP gateway uses a single network adapter, specify the server's IP address as the value for the SipIP and XmppIP fields.<?xml version="1.0" standalone="yes"?> <configuration> <appSettings> <add key= "cultureName" value = "en-US"/> <add key= "SipIP" value= "XXX.XXX.XXX.XXX"/> <add key= "XmppIP" value="XXX.XXX.XXX.XXX"/> </appSettings> </configuration>In our example, the XMPP Gateway's IP address, 192.168.1.20, is entered in the SipIP and XmppIP fields in the preceding configuration file.Next, define the FQDNs for the XMPP gateway. We recommend using two FQDNs. One of the FQDNs is internal and is used by your Edge Server to connect to your XMPP gateway. This internal FQDN is not exposed to the Internet and maps to the actual IP address of the XMPP gateway. This FQDN is used by the Edge Server to validate the XMPP gateway's server certificate when establishing a mutual TLS (MTLS) connection. In this example, the internal FQDN is called srv_xmpp.contoso.net. If a firewall separates the Edge Server from the XMPP gateway, make sure that SIP traffic over MTLS on port 5061 is open bidirectional.The other FQDN is for external use by the federated XMPP partners to locate your XMPP gateway. This external FQDN is exposed to the Internet and maps to your firewall's public IP address, which is configured to route XMPP traffic over TCP on port 5269 to your XMPP gateway. This external FQDN is called xmpp.contoso.net in our example.You might be wondering why not use a single FQDN instead of two? You can use a single FQDN. If you use a single FQDN, you must use the externally published public FQDN. You can use the same FQDN as long as the FQDN resolves to the internal IP of the XMPP gateway (the SIP IP) from the public edge of the Access Edge Server and resolves to the external IP of the XMPP gateway (the XMPP IP) from the Internet.


Configure the Domain Name on the XMPP GatewayAfter you define an FQDN for your XMPP gateway, you must configure the domain name portion of this FQDN for your XMPP gateway. (This assumes that the server running the XMPP gateway is configured in a stand-alone workgroup). In our example, the internal FQDN of the XMPP gateway is srv_xmpp.contoso.net. The domain name portion of this FQDN is contoso.net. You must configure this value in the Primary DNS suffix of this computer box on the XMPP gateway. To do this, follow these steps:

1. Click Start, right-click Computer, and then click Properties. 2. Under Computer name, domain, and workgroup settings, click Change

settings. 3. On the Computer name tab, click Change. 4. In the Computer Name/Domain Changes dialog box, click More. 5. In the Primary DNS suffix of this computer box, enter the domain name.

Figure 6. Configure computer's DNS suffix

Install Server Certificates on the XMPP GatewayYour XMPP gateway requires a server certificate to communicate with your Edge Server. This certificate, along with its corresponding private key, must be installed in the local computer's Personal store. Without a certificate, the connection will fail and the Edge Server will refuse the MTLS connection. This can often be a source of frustration and can be caused by a variety of reasons such as an untrusted root certification authority (CA) or a mismatch between the XMPP gateway's FQDN and the Common Name in the Subject Name field of the server certificate. If you run into issues, use the ocslogger.exe tool to help you troubleshoot. If you still have issues, let us know and we'll consider developing a DrRez blog article on this topic. For details about what new articles we have available and to suggest articles you’d like written, see the NextHop blog, http://go.microsoft.com/fwlink/?LinkID=203149.Given that everyone has a preferred way for requesting certificates, we will not cover all the ways this can be done. However, there are two things to keep in mind:

Make sure the Common Name of the certificate is identical to the internal FQDN assigned to the XMPP gateway.


Use at least 2048 encryption strength. For details, see “Set up Edge Certificates” in the Lync Server 2010 documentation, http://go.microsoft.com/fwlink/?LinkID=220453.

If your sole objective for setting up an XMPP gateway is to connect to Gmail, this certificate will be used only to authenticate to your Edge Server. In this case, you can use a certificate from your private CA. No certificates will be used on the Gmail side (XMPP) As federation with Gmail/Google Talk only supports TCP Dialback (which does not use certificates). Make sure that your XMPP gateway trusts the root CA of your Edge Server's certificate and vice versa.Define DNS records for the XMPP GatewayDNS entries must be defined for the XMPP gateway. You must publish to your external DNS server the external FQDN of your XMPP gateway so that federated XMPP partners (for example, Gmail gateways) can locate your XMPP gateway. Remember your XMPP gateway's external FQDN should be mapped to your external firewall's IP address unless you expose your XMPP gateway directly on the Internet (we do not recommend this). In our example, the external firewall's IP address is 192.168.2.11.After you name your XMPP gateway's external FQDN (In Contoso’s case, this FQDN is xmpp.contoso.net), you must create an A record in your public DNS to map this FQDN to your external IP address. In our example, xmpp.contoso.net maps to 192.168.2.11.In addition to creating this A record, you must create an SRV record in the following form: _xmpp-server._tcp.<SIP domain> This is the service record locator that is used by XMPP gateways to discover the external FQDN of your XMPP gateway. Figure 7 shows how to create this SRV record for Contoso.net.

Note: The protocol must be set to _tcp, and the port number must be set to 5269. The domain name of both the A record and the SRV record must match your SIP domain.

The following screenshot shows what this record would look like on a DNS Server running the Windows Server operating system:


http://technet.microsoft.com/en-us/library/gg412858.aspx

Figure 7. Creating the SRV record for Contoso.net

Configure Federated PartnersThe next step is to configure your XMPP gateway to connect to your Edge Server and federated XMPP partners. On the XMPP gateway, under Administrative Tools, open the Lync Server XMPP gateway console. Select the SIP Configuration node (as shown in Figure 8), and then configure the connection to the Edge Server with the following instructions:

1. On the Domain tab, specify your SIP domain name in the Domain box. For our example, ’contoso.net’.

2. Specify the FQDN of your Edge Server in the Host Name box. In our example, the Access Edge's external FQDN is srv.contoso.net.


Figure 8. SIP configuration of XMPP gateway

For the Edge Server to trust your XMPP gateway, you must configure the XMPP gateway with a server certificate. To request this server certificate, perform the following steps:

1. In the Lync Server XMPP gateway console, click the TLS Certificate tab (as shown in figure 9).

2. Click Select Certificate, and then select the certificate that you requested previously. If you are unable to find it, you may have installed the certificate in the wrong certificate store.

Note: The certificate's common name must match the XMPP gateway's internal FQDN.


Figure 9. Configuring the XMPP gateway with a server certificate

3. After you finish the SIP configuration, click the Validate Connection tab to validate your configuration to the Edge Server.

Next, configure the connection to the federated XMPP partners by completing the following steps:

1. In the left pane, click the XMPP Configuration node. 2. On the Allow List tab, click Add. 3. In the Federated XMPP Domain names dialog box, in the Domain Name box,

enter gmail.com, and then select TCP Dialback (required). 4. Click OK.

Because Gmail does not use any authentication or encryption (TLS), no certificate is required to be configured in the TLS Certificate tab. To validate your configuration, click the Validate Connection tab.

Firewall, Port, and Protocol RequirementsThe next step to get XMPP federation using the XMPP gateway functional is to configure any firewalls to allow the required network traffic for SIP and XMPP. For communication between the Edge Server and the XMPP gateway, TLS traffic must be allowed in both directions because either server can initiate a SIP over TLS connection. If a firewall is deployed between these two servers, configure it to allow the following network traffic:

Source ports: TCP 1024-65,555 Destination ports: TCP 5061 IP addresses:

o XMPP gateway internal (SIP) IP Address o Lync Server Access Edge external IP Address.


XMPP traffic must be allowed inbound and outbound through the external firewall because the XMPP gateway can initiate outbound XMPP traffic, and federated XMPP partners can initiate traffic to the XMPP gateway on TCP port 5269.The external firewall must be configured to allow the following traffic:

Source ports: TCP 1024-65,535 Destination ports: TCP 5269 IP addresses:

o XMPP gateway XMPP IP Address o Any external IP Address

Verify the ConfigurationThere are several ways to test your configuration. The easiest is to try to add a contact from a federated XMPP domain in Lync 2010, and then see if you can exchange instant messages and presence information. The next easiest is to test connectivity by using the XMPP gateway console. To test SIP connectivity from the Microsoft Management Console (MMC):

1. In the left pane, click SIP Configuration.2. Click the Validate Connection tab.3. Select your SIP domain in the list next to Allowed Domain. This will test a SIP over

TLS connection from your XMPP gateway to your Edge Server.

Note: This will not test SIP TLS connectivity from the Access Edge Server to the XMPP gateway.

Next, test the XMPP connectivity to the federated XMPP domain:4. In the left pane, click XMPP configuration.5. Click the Validate Connection tab.6. Select the XMPP domain in the list next to Allowed Domain. This will test XMPP

connectivity from your XMPP gateway to the federated XMPP domain.

Note: This will end up testing connectivity from the XMPP gateway to the federated XMPP domain and cause the other domain to initiate a connection back to the XMPP gateway.

If you run into issues, see the “Troubleshooting” and “Additional Resources” sections in this chapter.

SummaryXMPP deployment for Lync Server isn’t very different from deploying it for Office Communications Server 2007 R2. We hope this chapter has given you enough information and insight to deploy XMPP, along with your Lync environment, quickly and easily, and also has given you some ideas to solve issues when things don’t go as planned.

Additional ResourcesFor more details, see the following:

Microsoft Office Communications Server 2007 R2 XMPP Gateway download (including the Planning, Deploying, and Administering Office Communications Server 2007 R2, Extensible Messaging and Presence Protocol XMPP Gateway guide), http://go.microsoft.com/fwlink/?LinkId=220444


Extensible Messaging and Presence Protocol (XMPP): Core, http://go.microsoft.com/fwlink/?LinkId=220447

Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence, http://go.microsoft.com/fwlink/?LinkId=220452

Set Up Edge Certificates that appears in the Lync Server 2010 documentation, http://go.microsoft.com/fwlink/?LinkID=220453

Troubleshooting XMPP TCP Dialback Issues with the Communications Server XMPP Gateway that appears in the Microsoft Office Communications Server 2007 R2 documentation, http://go.microsoft.com/fwlink/?LinkID=220272

Configuring Support for External User Access that appears in the Lync Server 2010 documentation, http://go.microsoft.com/fwlink/?LinkID=220458

Microsoft Lync Server 2010 Resource Kit Tools download, http://go.microsoft.com/fwlink/?LinkId=220458

Microsoft Exchange Server Error Code Look-up download, http://go.microsoft.com/fwlink/?LinkId=220461


microsoft€¦ · web viewauthor katrina purcell last modified by v-keblue created date 6/9/2011...

Documents