A Welcome Addition to Lync 2013’s Snooper


I was recently troubleshooting a Lync 2013 XMPP <-> Gmail issue and came across a great new addition to Snooper – the Flow Chart (call flow) window. As you can see in the image below, it is similar to Wireshark’s SIP flow tool, but is diagrammed right from ocslogger’s logs – no TLS decryption required!


To use the tool:

1. Gather your logs in ocslogger. If you don’t have the 2013 debugging tools installed, you can get them here.

2. Click “Analyze” to launch Snooper

3. In either “Messages” or “Trace” view, click on the new call flow icon, highlighted in yellow


4. Presto! A nicely laid out SIP call flow.

Default view:



Aside from the overview, you have options to include timestamps and merge (semi) redundant SIP message – if you’ve troubleshot collocated mediation servers in the past this is a great way to minimize the clutter of the flow.

Merged View:



The tool is great for troubleshooting on your own, but even better when conveying complex topologies and call flow to customers or colleagues. In heterogeneous environments a visual aid like this can save hours of explanation and finger-pointing. I have yet to try it, but I’d expect the tool to work on any UCMA application, including Exchange UM (2010 SP1 + higher) and custom applications.

Nice work Snooper team!

Posted in Lync, Lync 2013 | Tagged , | Leave a comment

Capturing Lync Phone Edition Traffic, Part 1


Troubleshooting Lync phone edition is one of the harder aspects of Lync deployment engineering. One significant hurdle to overcome is the inability to directly capture network traffic on a Lync phone edition device.

Remember, you can always ask the closest network engineer to SPAN the traffic for you, but in some situations that individual may not be available, or the process may take an extended amount of time. This process gives an alternative way to directly capture network traffic.

What you’ll need:

* a Network TAP device. This provides the SPAN functionality to any network device. In this scenarios I’m using the Dualcomm DCSW-1005PT. I prefer this device as it’s cheap (under $100) and provides POE passthrough, perfect for Lync Phone Edition devices. It’s also usb powered so no power adapter is needed.

* Network sniffing software (Network Monitor 3.4 or Wireshark are popular)

* An Ethernet card (yes, seems obvious but just in case you have a laptop or tablet without an Ethernet NIC, you’ll need an adapter)


* Network Monitor Lync Parsers, for parsing Lync application-specific traffic

* Certificates of Lync servers (with private keys) – these allow for decryption of TLS and SSL traffic, aiding in the troubleshooting process

Let’s get started.

1. First, you’ll need to plug the devices into the right places. I’m using the dualcomm TAP, which is pretty straightforward.

A. Plug port 1 into the network uplink or POE injector (the port the phone was originally plugged into.

B. Plug port 2 into the phone (labeled “LAN” on the phone port)

C. Plug this into the PC used to monitor the traffic


2. Configure the Network card

A. Deselect all protocols except the “Microsoft Network Monitor 3 Driver” on the NIC used for capturing traffic.


This is necessary for the Dualcomm TAP as it acts as a port mirror AND a switch. The captures can be messy to analyze without disabling the additional protocols.


2. Configure network monitoring software

A. Start Network Monitor and select the appropriate network adapter.

NOTE: If no network cards are available, make sure you run Network Monitor “As Administrator.”

B. Select “P-Mode” for the adapter. This enables promiscuous mode, which is necessary because all protocols were disabled on the network card.


C. Start a “New Capture.” Click “Start.”

At this point all network traffic to and from the phone will be captured. If the phone is getting an IP address, add a filter to only show traffic to an from the phone using the “ipv4.Address==X.X.X.X” display filter in Network Monitor.


In the case above, we see the phone communicating with Exchange Web Services (EWS) and the Lync AV Edge server. In the next section I’ll cover analyzing Lync traffic with Network Monitor Parsers, as well as decrypting the SSL and TLS traffic being sent.

Happy Capturing!

Posted in Lync, Lync 2010, Lync 2013 | Tagged | Leave a comment

Lync XMPP Gateway Deployment without Edge Server

Over the past few weeks I’ve run into deployments requiring XMPP for multi-vendor application presence integration. One of the caveats that’s published is the requirement to allow federation for any of the user accounts requiring XMPP integration. In highly secure environments this is not an option. It also adds a layer of complexity when troubleshooting presence integration of internal applications.

This blog post doesn’t cover installing or configuring the XMPP gateway itself, or configuring certificates. It does cover:

  • Enabling XMPP communications between “domain.com” and “internalxmpp.domain.com” without the use of an edge server.

To configure XMPP integration:

1. Create a static route in Lync to enable routing for the appropriate SIP domain (internalxmpp.com in this case)

$tlsroute = New-CsStaticRoute -TLSRoute -destination “xmppservername.domain.com” -port 5061 -matchuri “internalxmpp.domain.com” -usedefaultcertificate $true

Note that the “destination” switch specifices the server name to send to, and that server must be resolvable from the front end server. Additionally, the server “xmppservername.domain.com” must have a certificate with “xmppservername.domain.com” for MTLS communication to occur.

2. Create a trusted application pool and application, so Lync can accept inbound requests and presence updates.

New-CsTrustedApplicationPool -Identity internalxmpp.domain.com -Registrar Registrar:lyncfe01.domain.com -site 1 -ComputerFqdn xmppservername.domain.com -ThrottleAsServer $true -TreatAsAuthenticated $true

New-CsTrustedApplication -ApplicationID XMPP -TrustedApplicationPoolFqdn internalxmpp.domain.com -Port 5061

3. Configure the XMPP gateway to send SIP requests to the front end server.



4. Voila!

Now we have XMPP integration without an edge server in place.

If you have an application that leverages this type of integration, or run into any issues/questions when deploying XMPP integration please let me know. With the abundance of XMPP, Web Services/LyncClientAPI/UCMA, and other presence and UC integration technologies being used it’s important to have templates for the UC community to understand and use. Thanks!


Posted in Uncategorized | 1 Comment