Capturing Network Traceroutes in Lync/Skype for Business

If you've ever trolled through the QoEMetrics database (a great way to while away a lazy Saturday afternoon) you may have come across a few tables that made you go "What the....?".  One table that might catch your eye is the TraceRoute table.  In all likelihood,  this table is probably empty, which might make you wonder what it's for.

Microsoft publishes pretty detailed information on the structure of the QoEMetrics database where you can find information about the TraceRoute table in this Technet article.

As you can surmise by the name, this table is meant to capture trace route information for calls. However, the table description gives no information on how to enable this feature.

You can enable this by adding a custom policy entry to a Lync/SfB client policy.  Custom policy entries are used to enable features that Microsoft has decided not to make too obvious for users for one reason or another.  If you've got custom policy entries, you'll see them at the top of the list when you run Get-CsClientPolicy.  If you have several of those, you can see it in a more readable format by typing (Get-CsClientPolicy policyname).PolicyEntry

The relevant policy entry for enabling tracerouting is called "EnableTraceRouteReporting", and you can add it to a client policy by running the following commands:

$x = New-CsClientPolicyEntry -Name "EnableTraceRouteReporting" -Value "TRUE"

$y = Get-CsClientPolicy -Identity policyname
$y.PolicyEntry.Add($x)

Set-CsClientPolicy -Instance $y

Whoever has that policy applied to them will now publish trace route reports to the QoEMetrics database. However, the built-in Lync/SfB reports do not expose this anywhere, so you would only want to turn this setting on if you are using a 3rd party reporting and analytics tool such as Event Zero's UC Commander (FYI, if you don't already know, I work for them).

Sample screenshot of traceroute data as it appears in UC Commander

This can be very useful to help track down network issues in the call path. This won't necessarily point the finger at a specific switch or router in every circumstance, but it can help.

Be warned that enabling this will add a bit of size to your QoEMetrics database. The additional data isn't huge but its not negligible either.  You should carefully evaluate the impact before turning this on.

Lync Edge Server Static Routes

If you're following the Technet articles on how to setup your edge server, you will eventually get to the point where you have to setup your NICs on your edge server.  According to the Set Up Network Interfaces for Edge Servers page:, you should set the default gateway on the external interface, but not the internal. The guide then helpfully tells you to....

Create persistent static routes on the internal interface to all internal networks where clients, Lync Server 2010, and Exchange Unified Messaging (UM) servers reside.

If you're not a Windows networking expert, this might stump you a bit.  Doing some searches might help, but here's a simple way to ensure that all internal networks are covered, even if you aren't aware of exactly which ones are in use.  This can easily happen if you're a consultant doing a Lync deployment for a large, multi-site company.

There are 3 well-known IP subnets that are reserved for internal use.  Any networking person can tell you what they are, and should be using these for their internal corporate network.  If not, then I would recommend running away.  The 3 well-known subnets are 10.0.0.0/8, 172.16.0.0/12 and 192.168.0.0/16.

I typically add static routes for all 3 subnets even if they aren't all in use.  This will future-proof your deployment  in case the company adds or changes their subnetting scheme.  To add these static routes on the internal interface of your edge server, do the following:

1. Using the Network Connections interface, make sure your NICs have descriptive names that make sense (Ie. Internal and External)
2. Open a command prompt in Administrative Mode on the edge server.
3. Make sure you know what the internal default gateway should be.  In this example, we will use 192.168.100.1
4. Type the following commands in the command window:

netsh interface ipv4 add route 10.0.0.0/8 "Internal" 192.168.100.1
netsh interface ipv4 add route 172.16.0.0/12 "Internal" 192.168.100.1
netsh interface ipv4 add route 192.168.0.0/16 "Internal" 192.168.100.1

When you do a netsh interface ipv4 show route, you should see the new routes show up at the bottom of the list.  If you make a mistake, you can delete a route by using the same command above, and replace add with delete.  Now,  your Lync edge server should be able to route to any internal address, both now and in the future.

UPDATE:  Apparently, I'm part Amish, and I was using ROUTE ADD instead of the updated netsh commands shown above.  Thanks to @twharrington on Twitter for pointing out the error to this ol' timer.  I'M DOIN' IT OLD SKOOL!