The Microsoft documentation for Lync Server 2013 has improved considerably from previous releases. Having recently walked through a couple of installations of the native Lync Monitoring reports, the process is documented much better than in the Office Communication Server days! The documentation related to installing the prerequisite SQL Server Reporting Services (SSRS) for example is much improved.  

If you are installing the native Lync Server 2013 reports, along with the TechNet documentation, these 5 tips will get you up and running faster.

1] What are the High Level Steps to get the Lync 2013 Monitoring Reports Working?

There are many Microsoft TechNet articles on planning, configuring, deploying, and installing the monitoring reports. The basic process boils down to these 4 steps (and many associated configuration tasks):

1. Enable and Activate Monitoring on your Front End Pools
2. Install Microsoft SQL Server Reporting Services
3. Install the Lync Server 2013 Monitoring Reports
4. Set the Native Lync Monitoring Reports URL

The associated configuration tasks for each of these steps are described in more detail in this Microsoft TechNet article: Deploying Monitoring.

2] Can the Monitoring Reports be Installed on the Lync Back End SQL Database?

Yes.  This is likely in Lync Server 2013 because you can collocate one monitoring database with one back-end database on a single SQL instance, and it is recommended to install the native Lync Monitoring reports on the same computer where the monitoring database is installed to simplify permissions.

If the Lync deployment requires more than one monitoring database, it must be installed an another SQL instance. See the TechNet article “Server Collocation in an Enterprise Edition Front End Pool Deployment” for more information.

Also remember that a single monitoring store can be used by multiple Lync pools – as long as it can scale.

3] How can I Quickly Determine if the SQL Server Reporting Services are Installed? 

The SQL Reporting Services Configuration Manager can be used to check if SQL Server Reporting Services (SSRS) is installed. In the screen shot below, if there is no Report Server Instance available to connect to (i.e. the Connect button is greyed out), you do not have SSRS installed.

When you do have a Report Server Instance installed, it will look like this:

Quick Tips for Installing SSRS:

• You can start the installation through: Programs | SQL Server 2008 R2 | Configuration Tools | SQL Server Installation Center (64-bit)
• Advance to the Feature Selection page in the installation wizard and select "Reporting Services" (see screenshot)
• Enter an Account Name that the SSRS service will run under.  I used my Domain Administrator.
• After installing SSRS, be sure to follow the directions for creating a new Report Server database (i.e. the “If no database is listed next to the Report Server Database Name label then do the following…” step).

4] How do I know if Lync Monitoring is Installed, Configured, and Enabled on my Lync pool?

Because the Monitoring service in Lync Server 2013 is now collocated with the Front End, and is a check-box during installation, it can be easy to forget if it is installed and configured.  A quick look at the Pool properties in the Topology Builder let’s you know if monitoring is enabled and where the database is configured.

The next question is whether Call Detail Record (CDR) and Quality of Experience (QoE) data is actively being collected and stored. You can check this through the Lync Control Panel or the Lync management shell.

In the screen shot below we can see that CDR data is enabled and it will keep the data for 60 days:

See the "Configuring Call Detail Recording and Quality of Experience Settings" in TechNet for the all the CDR and QoE configuration settings (http://technet.microsoft.com/en-us/library/jj204621.aspx).

5] Setting the Native Lync Monitoring Reports URL

Although this last step is described as a “must” in the TechNet documentation (Installing Lync Server 2013 Monitoring Reports), the native Lync monitoring reports seem to work fine without it.  Following this step however does enable the “View Monitoring reports” link work in the Lync Control Panel Home Page (see screen shot below).

I have found an issue with the TechNet documentation describing how to set the native monitoring reports URL (Installing Lync Server 2013 Monitoring Reports).

The instructions for finding and specifying the “ReportingURL” parameter used in the Set-CsReportingConfiguration cmdlet will set the URL to the "Report Manager URL” instead of the intended home page for the Lync Monitoring Reports Home Page.  The consequence is that the “View Monitoring reports” link in the Lync Server 2013 Control Panel home page will go to root Report Manager web page and not the home page for the Lync reports.

Instead follow the directions in the Set-CsReportingConfiguration cmdlet documentation as follows:

1. Open the SQL Server Reporting Services Configuration Manager for the SQL Server instance that contains your monitoring database.
2. In the Configuration Manager, click Report Manager URL and then click the URL for your Monitoring Reports. If you see two URLs, click the one that uses the https protocol.
3. In SQL Server Reporting Services, click LyncServerReports.
4. On the LyncServerReports page, click Reports Home Page. That will take you to the home page for the Monitoring Reports. You can then copy the URL and use that URL in conjunction with the CsReportingConfiguration cmdlets.

BONUS TIP : Enabling the Call Leg Media Quality Report

The February 2013 Cumulative Updates for Lync Server 2013 included an update to the Core Components that enables a Call Leg Media Quality Report. See An update is available that enables you to use a Call Leg Media Quality Report in a Lync Server 2013 environment for more information.

The Call Leg Media Quality Report allows you to analyze the number of calls and the associated media quality on call legs between devices on the network.

I will start this blog post with a caveat: it is huge and more of a beginners encyclopedia of Lync SIP trunking configuration and troubleshooting tips than a blog post! It also adds some new specific Lync Server 2013 configuration information to the existing information available on configuring a SIP trunk with previous releases of Lync Server.

It includes some great tips on getting up and running with a SIP Trunk and I am hoping it is one of the best troubleshooting reference for Lync Server and SIP trunk connectivity available. If you are familiar with SIP trunking and Lync and are having some issues, you might want to skip ahead to the sections “Noteworthy Configuration Tips” and “Troubleshooting Tools and Tips”. Here are some particularly useful tips you might want to check-out below:

• Problems with older Firewalls or Gateways Mangling SIP Packets
• The "Enable outbound routing failover timer” Setting on the Lync
• NAT IP addresses at the Session Description Protocol (SDP) level

Configuration Used in this Article

This post focuses on the practical steps required to get a simple SIP Trunk to work with Lync 2013 with the most basic scenario:

1. One Lync Server 2013 Enterprise Pool and One Lync Server 2013 Mediation Pool – each with one server.
   • It is possible to also configure a SIP trunk with a Lync 2013 Mediation server collocated with the front-end, but this is not recommended for production scenarios, and depending on your scenario it could pose a security risk.
2. Unencrypted Traffic. For this basic setup the SIP signaling and media is not encrypted. When you move into production, it is recommended to encrypt the traffic.
3. A SIP Trunk over a Public Internet Connection. In this configuration, the Mediation Server connects to the SIP trunk by using a direct Internet connection. Unlike the private and VPN options, this topology does not leverage an isolated link to the SIP trunk.
4. A Lync 2013 Mediation Server with 2 NICs.  One NIC is connected to the external Internet through a Firewall (which has network connectivity to the SIP trunk), and the other NIC is connected to the internal LAN.
5. A SIP Trunk from IntelePeer.  This configuration uses a Lync SIP trunk from IntelePeer (you can read more about their SIP trunk offering for Lync 2013 here: http://www.intelepeer.com/SIPTrunking-microsoft-lync).  You can purchase a Lync SIP trunk from other vendors and here are some tips:
   • Pick a vendor that is on Microsoft’s list of Services qualified for Microsoft Lync. This helps ensure there will be no interoperability issues.
   • Some SIP trunking providers require a piece of hardware called a Session Border Controller (SBC) whereas other vendors can connect their SIP trunk directly to a Lync Mediation server (usually through an external firewall).

Here is a simplified diagram of the call flow:

What’s Changed in Lync Server 2013 for SIP Trunking?

Rather than focus on the steps to get up-and-running with Lync Server and a SIP trunk, I will focus on what has changed with Lync Server 2013 which supplements the excellent article that fellow MVP Brian Ricks wrote for NextHop: Configuring an IntelePeer SIP Trunk Solution in Lync Server 2010. Not a lot has changed in Lync 2013, so I recommend following the steps outlined in Brian’s NextHop article if you are not familiar with Lync server voice routing, and then read this article for tips and troubleshooting information.

To provide the new capability in Lync Server 2013 of “M: N trunk routing” (that is, the ability for any number of Lync Trunks to be paired with any number of Lync Mediation servers), Lync Server 2013 introduced “Trunks” as a component that can be defined in the topology as shown here:

Your first step in the Lync configuration side will be to define a Lync SIP trunk and associated PSTN Gateway that will be used to route the call to the SIP trunk.  Here are some important tips:

1. Trunks are Logical entities. The topology definition of a Lync trunk (and the associated Lync trunk configuration) are logical entities. The physical connectivity is established through the the Associated PSTN Gateway that you specify when defining the trunk. It follows then, that you need to define an associated PSTN gateway before you can define the trunk in the Topology.
2. The PSTN Gateway is the External SIP Trunk. Don’t let the terminology confuse you. In the Lync Topology Builder, the PSTN Gateway that you associate with the trunk is the external SIP trunk. When you define a new PSTN Gateway, just enter the external IP of the SIP trunk (given to you by your provider) as the gateway FQDN.  Note: the trunk can be defined in the same wizard that you used to create the PSTN Gateway.
3. Configure the Trunk through the Lync Control Panel. Many people get confused because there is now a trunk definition in the Topology Builder and a Trunk Configuration in the Lync Control Panel. The trunk definition in the topology just contains basic connectivity information (e.g. physical gateway, what mediation pool to associate with, etc…).  An associated trunk configuration in the Control Panel allows you to configure how the trunk is used and configured at protocol level. See the step “Defining the SIP Trunk Configuration in the Lync Control Panel” for more information.

Adding the SIP Trunk to the Lync Topology

As mentioned above, to add the SIP Trunk to the Topology as a new PSTN Gateway, add a new PSTN Gateway as follows in Topology Builder:

1. Define the PSTN Gateway FQDN = IP Address of the external SIP Trunk
2. Define the Root Trunk (the associated trunk can be defined at the same time you create the PSTN gateway)
   • Trunk Name: <IP address of the SIP trunk>
   • Listening port for IP/PSTN Gateway: 5060   (in this case unencrypted TCP is being used; use 5061 for TLS encrypted)
   • Transport: TCP
   • Associated Mediation Server:  <Lync Front End Pool + Lync Site>
   • Associated Mediation Server port:  5060

* Don’t forget the publish the topology and make sure the Mediation server has picked up the changes (see “If I Make a Routing Change in the Lync Control Panel, How do I Know if my Mediation Server Picked Up the Change?” below for more information on this).

Defining the Associated SIP Trunk Configuration in the Lync Control Panel

Under the Voice Routing panel, click on the “Trunk Configuration” heading, and define a new Pool trunk.  With a Pool trunk, you will be able to associate the trunk with the PSTN Gateway defined in your Topology that represents the SIP trunk.

The the New Trunk configuration dialog is show here:

In my experience, four settings that you want to pay particular attention to are:

1. Encryption support level: this identifies what encryption (if any) will be made on the media traffic. They key is, you need to match whatever your peer SIP trunk is configured for. Note that encryption will use TLS which requires certificates.
2. Refer support: in my experience, setting this option to “Enable sending refer to the gateway” will allow the caller-ID to be passed through to the SIP trunk and on to the called party.
3. Centralized media processing:  this indicates to Lync that the SIP trunk peer uses the same IP address for media as it does the SIP signaling. If you are having trouble getting Lync audio working, but the call is established, try enabling this if it is not already enabled.
4. Enable outbound routing failover timer: when enabled, the SIP trunk has 10 seconds to tell Lync that the call has been processed or else the call get’s dropped.  Lync Server 2010 did not have this setting.
5. Associated PSTN Usages:  this instructs Lync to only allow calls through this trunk the match the PSTN usages listed here.

Note: all the Lync Trunk configuration settings are defined here: Microsoft TechNet – Configuring Trunks.

Finishing your Topology Changes and add the Lync Voice Routing Changes

For the rest of the required Topology changes and Lync voice routing additions, the steps outlined in Brian Rick’s article still apply for Lync Server 2013: http://blogs.technet.com/b/nexthop/archive/2011/04/21/configuring-an-intelepeer-sip-trunk-solution-in-lync-server-2010.aspx.

Noteworthy Configuration Tips

This section outlines some important configuration and troubleshooting tips.

Do you need to define a Lync Server 2013 SIP Trunk in the Lync Control Panel?

A common question is: once I have the SIP trunk defined in my Topology, do I need to define an associated Lync Trunk Configuration in the Lync Control panel?

In theory “no” because there will always be a Global Lync trunk that will be used. In practice though the answer is “yes” – you should because it enables you to control the Lync configuration for calls intended specially for the SIP trunk.

This Microsoft Technet article has all of the information you need to know to Configure a SIP trunk in Lync 2013: Configuring Trunks.

Problems with older Firewalls or Gateways Mangling SIP Packets

You can save yourself many potential headaches by using hardware (e.g. SIP-PSTN Gateways) that have been certified by Microsoft for PSTN integration by visiting the Microsoft Infrastructure qualified for Microsoft Lync web site.

Unfortunately that interop program does not cover firewalls, and some firewalls like to mess with SIP packets!

For example, several model’s of the older Cisco PXE firewalls will be configured to do a “inspect sip” or a “fixup protocol sip” on the SIP packets. In my experience this will cause the inbound packets to be mangled. You will first noticed this problems with ‘NO RESPONSE’ errors to SIP OPTIONS messages in the event log on Lync 2013 Mediation server. The Mediation server is sending the OPTIONS requests but not receiving the replies because the SIP packets are getting mangled.

I have read this can also be a problem with interoperability between Lync and Asterisk PBX’s.

The fix is to remove the command “inspect sip”, “fixup protocol sip”, or any other packet manipulation on the firewall.

I have read about older SIP-PSTN Gateways with packet manipulation capabilities, so you might want to check that if your are using a Gateway between Lync and the SIP Trunk.

A Lync Edge Sever is only needed to Support SIP Trunk Calls for External Lync Users

If you start searching the Internet and forums for problems with Lync SIP trunk configurations, you will run into several errors and references to the Lync Edge server.  To save yourself some time, the Lync Edge is only used to support external Lync users. The Edge Server allows the Mediation Server to interact with users who are located behind a NAT or firewall – external to the organization.

An Edge is not required to provide call connectivity over a SIP Trunk for Lync users inside your network as long as an Internet Telephony Server Provider’s Session Border Controller (SBC) is configured to receive traffic from any Mediation Server in the pool, and can route traffic uniformly to all Mediation Servers in the pool

A good overview of a SIP trunk implementation can be found in the Microsoft TechNet article: How Do I Implement SIP Trunking?

Note: if you are trying to configure the Edge to allow external Lync users to make calls over the SIP trunk, be sure to use the Set-CsMediationServer cmdlet.  This tells the Mediation server what Lync Edge server is used for external users.

Fellow Lync MVP Ståle Hansen recently blogged about this. See his post “No media connectivity with Lync Server 2010 collocated mediation server and external users” for more information.

Check the "Enable outbound routing failover timer” Setting on the Lync Server 2013 Trunk if the Call is Dropping After a Successful Connection

This Lync trunk setting requires that the SIP Trunk notifies Lync within 10 seconds that it is processing an outbound call from Lync. Some SIP trunks will either not provide this notification, or are not able to get it back to the Lync server within 10 seconds.

In this case the call will drop in about 10 seconds and a “SIP/2.0 487 Request Terminated” will appear in the Lync server SIP transaction logs (more information on this error is in the troubleshooting section).

Here is the explanation of the failover timer setting in the Lync 2013 trunk:

Enable outbound routing failover timer should be selected to enable fast failover. The gateway associated with this trunk can give notification within 10 seconds that it is processing an outbound call. Rerouting to another trunk will occur if this notification is not received by the Mediation Server. On networks where latency may delay the response time or the gateway takes longer than 10 seconds to respond, the fast failover should be disabled..

This setting is enabled by default.  Disabling it will solve your issue.

Explicitly Setting the Audio Port Range on the Mediation Server is not Always Required

The audio port range used by the Lync Mediation server can be configured with the Set-CsMediationServer

cmdlet. For example, IntelePeer requires ports 5000 thru 65535 to be used for the RTP Audio.

The Lync 2013 Mediation server defaults for the port range are 49152 to 57500. I have not needed to change the default Mediation audio port range to successfully do SIP trunking however. As such, I am not clear when the port range need to be explicitly configured on the mediation server, but I have not had problems, even when the port range used by the SIP trunking audio is much larger than what the default port range.

If you do need to set a custom port range on the Lync Mediation server, the cmdlet to do it would look like this:

Set-CsMediationServer -Identity "MediationServer:<Lync Pool FQDN" -AudioPortStart 5000 -AudioPortCount 60535

If you do explicitly set the audio range to a custom port range, remember to allow for CMS replication restart the mediation server service so that the Lync mediation server picks up the change.

You can see the existing settings used for the Mediation Server with the cmdlet “Get-CsService –MediationServer”.  Here is an example:

Identity             : MediationServer:<Lync Pool FQDN>
Registrar            : Registrar:<Lync Pool FQDN>
EdgeServer           : EdgeServer:<Lync Edge Server FQDN> 
SipServerPort        : 5070
SipClientTcpPort     : 5060
SipClientTlsPort     : 5067
AudioPortStart       : 49152
AudioPortCount       : 8348
DependentServiceList : {PstnGateway:<IP G/W 1>, PstnGateway:<IP G/W 2>}
ServiceId            : 1-MediationServer-4
SiteId               : Site:<Lync Site> 
PoolFqdn             : <Lync Pool FQDN> 
Version              : 6
Role                 : MediationServer

If you detect a port conflict (either on the SIP signaling or Media Port), you can use this command to see what IP address have are using specific ports:

netstat -ant

netstat –ant | finder 5060  (to find references to port 5060)

Troubleshooting Tools and Tips

This section details the best tools to use to troubleshoot SIP trunk issues, and how to resolve some common problems.

Tools of the Trade

1. Microsoft PortQryUI
   • http://www.microsoft.com/en-ca/download/details.aspx?id=24009
   • PortQryUI is the GUI version of the free Microsoft utility for PortQry command line port scanner utility which shows the port status of TCP and UDP ports on the remote computer specified.
   • This tool is most useful to test the ports that should be open on your firewall.  It is best to run it on a computer outside of your network with access to the firewall and you can use it to ensure TCP port 5060 (or 5061) and the UDP ports used for the media or available.
2. Free Online Port Scanners
   • If you need to do some quick port checking and do not have access to a Windows machine outside your network to run PortQry, a good alternative are online port scanners which run on a web server on the Internet.
   • You can enter the IP address of your firewall and the port(s) that you want to query and run the query from the remote web site. Do a Bing search for “online port scanner” and pick one that seems reputable.
3. OCSLogger & Snooper
   • OCSLogger can be used to set server-side logging to debug SIP trunking activity.
   • The Lync 2013 Centralized Logging service will also give you debugging information, but to show details of the SIP protocol, I find OCSLogger and it’s log analysis counterpart tool, Snooper, the best.
   • These two tools now ship in the Microsoft Lync Server 2013 Debugging Tools; in Lync Server 2010 they were part of the resource kit.
4. WireShark
   • http://www.wireshark.org/
   • If you experience network connectivity issues that cannot be figured-out at the SIP or Lync server logging levels, you may need to capture network activity on the wire. Hopefully it won’t come to that, but if it does, WireShark is one of the best network troubleshooting tools available.
   • You will want to run WireShark on the Lync Mediation Server.
5. The Test-CsPstnOutboundCall Lync Test Cmdlet
   • This test cmdlet is available in the Lync Management Shell and is good for quick outbound test calls to identify any high level problems.
   • Caveat: I have had some cases where the error messages returned by this cmdlet masked the real problem.
   • Here is a quick sample of how to use this cmdlet:
     

     $cred1 = Get-Credential "domain\LyncUser1"

     Test-CsPstnOutboundCall –TargetFqdn LyncPool.domain.com -TargetPstnPhoneNumber "123 456 7890" -UserSipAddress "sip:LyncUser1@domain.com" -UserCredential $cred1

Specific Troubleshooting Tips

This section details some hard learned lessons which will hopefully save you time.

OCSLogger Categories to Select to Debug SIP Trunk Issues

Here are the categories I found most useful to debug connectivity and configuration issues with a SIP Trunk.

On a Lync 2013 Standalone Mediation Server

On a Lync 2013 Front-End Server

No SIP Protocol Messages Show up in the Lync Server 2013 Version of Snooper

There have been several reports of Snooper not showing any SIP traffic despite the appropriate categories being selected.

As of April 30, 2013 Microsoft is aware of this issue and is investigating. It is not known whether this issue is environmental or a bug

If I Make a Routing Change in the Lync Control Panel, How do I Know if my Mediation Server Picked Up the Change?

You may be wondering this especially if you are running a standalone Mediation pool. The key is to look for Event ID 3013 “LS Replica Replicator Agent Service” in the event log on the Mediation server.  It looks like this.

Outbound SIP Error: SIP/2.0 487 Request Terminated

While making an outbound call, if you experience the scenario where the call rings through but then terminates shortly afterwards and the following SIP error appears in Snooper:

ms-diagnostics-public: 5025;reason="Cancel sent by application for INVITE client transaction.";AppUri="http%3A%2F%2Fwww.microsoft.com%2FLCS%2FOutboundRouting"

ms-diagnostics-public: 5011;reason="ACK is being generated on receipt of a 487 canceled response for an INVITE forked by application";AppUri="http%3A%2F%2Fwww.microsoft.com%2FLCS%2FOutboundRouting"

One likely possibility is that the “Enable outbound routing failover timer setting” is set in the Lync trunk configuration and it should not be. See the ‘Check the Enable outbound routing failover timer” Setting on the Lync Server 2013 Trunk if the Call is Dropping After a Successful Connection’ previously in this article for more information.

Event Log Error: “14613, LS Protocol Stack”

Sometimes debugging is to know what not to pay attention to.  I’ve yet to get to the bottom of this error, but the SIP Trunk will work while this error is present on the Lync Enterprise Front-End server. I believe this is not specific to a SIP trunk configuration. The event log error is shown here:

Outbound Error: 403

This is a very common error that will appear in both the Lync client and in the SIP logs (e.g. using Snooper).

Generally a 403 means “forbidden” and in the context of an outbound call it usually means that the Lync user making the call (the caller) is not authorized to call the destination number. The reason is usually that the caller has not been configured to have the required PSTN Usage for the called number.

To resolve this error, ensure that the Lync user making the call is configured with a Lync server Voice Policy that contains a PSTN Usage record that the chosen Lync Voice Route maps to based on the called number.

A great way to test what PSTN usage will be used if a specific Lync user dials a specific number is the "voice routing test case” functionality in the Lync Control Panel.  This feature is somewhat hidden, so I have highlighted where in the Voice Routing panel you can find this functionality, and where the specific user information is populated:

Event ID 25051 – There was no response from a Trunk to an OPTIONS request sent by the Mediation Server.

This is a very common problem reported in the event log of the Lync 2013 Mediation Server.  The details of Event ID 25051 look like this:

The Trunk, {IP Address};trunk={IP Address}, is not responding to an OPTIONS request sent by the Mediation Server service.
Cause: The Mediation Server service cannot communicate with the Trunk Service over SIP due to network connectivity issues.
Resolution: Please ensure network connectivity and availability of the Trunk for the Mediation Server service to be able to function correctly.

The most likely cause is network connectivity – specifically the port configured for inbound SIP signaling is not open on the firewall (i.e. TCP Port 5060 or TCP Port 5061).

As part of normal operations the Lync 2013 Mediation server periodically sends a SIP OPTIONS message to the SIP trunk to ensure the SIP Trunk is able to service requests – similar to a heartbeat.  Event ID 25051 appears if the Mediation server has sent the request but did not receive a response.

To resolve this error, use the Microsoft PortQry tool, or an online port scanner and make sure that the SIP signaling port (TCP 5060 or 5061) is open on the firewall and the Mediation server is able to issue a response. Any port scanner utility should report a “LISTENING” status.

If the ports are open, another problem could be that the firewall or externally connected Gateway is mangling the inbound SIP packets. This problem is described earlier in this blog entry – see: “Problems with older Firewalls or Gateways Mangling SIP Packets”.

Outbound Error 503:  Gateway Not Available

This manifests itself as Event ID 46046 in the event log or a 503 response to the a call attempt in the Lync client or the Test-CsPstnOutboundCall cmdlet, and the details look like this:

A call to a PSTN number failed due to non availability of gateways.

Called Number: +1xxxxxxxxxx
Phone Usage: International All
Route: International All
CallId: 524d2e6d-b938-466e-b8b7-8f31d170d58a

Cause: All gateways available for this call are marked as down.
Resolution:
Verify that these gateways are up and can respond to calls.

This error can be deceiving.  The Lync Mediation role has the ability to * remember * when their was a prior failure to a particular trunk or gateway and if a call to that same trunk or gateway is attempted in a certain time frame, the Mediation server will immediately return this error without actually trying the call because it has flagged the gateway as down.

If you restart the “Lync Server Mediation” service, it will reset the “bad gateway” flag and you can try your call again. It is also supposed to reset after a specific amount of time, but in my experience with Lync Server 2013, it doesn’t.

Outbound: Event Log Error 10001

This is another common outbound error. The Lync client will show an error like this:

The details of the event log error will show:

ms-diagnostics-public: 10001;reason="Gateway did not respond in a timely manner (timeout)";component="MediationServer"

In a nutshell, the PSTN gateway associated with the SIP trunk which is responsible for handling the call is not reachable (i.e. unavailable).

Make sure you have restarted the Lync Mediation Service after adding the new SIP trunk to the topology and configured the ports on the Mediation Server.

This error will also be generated if Lync has marked the PSTN Gateway as down from previous failures. Restarting the Lync Mediation Service will solve this.

Outbound Error – “Busy Network”

This error can occur for several reasons. The experience is that the call initially rings through to the called party, but then it will drop and the Lync client will display an error like this:

This might manifest itself as a “Service Unavailable” in the snooper logs:

TL_INFO(TF_PROTOCOL) [0]1238.0C84::03/28/2013-21:48:26.505.00000082 (SIPStack,SIPAdminLog::ProtocolRecord::Flush:2420.idx(196))[3323817907] $$begin_record
Trace-Correlation-Id: 3323817907
Instance-Id: 17BB
Direction: outgoing;source="local"
Peer: <Peer IP>:62802
Message-Type: response
Start-Line: SIP/2.0 503 Service Unavailable
From: "Lync User 1"<sip:LyncUser1@domain.com>;tag=f75e2a3e27;epid=fd52f25f59
To: <sip:+16132701611@qms-l13.dev.kan.ca.qsft;user=phone>;tag=F5D5957753477DCEBB3D60994713111A
Call-ID: 649bee354cb24e8d86891483086008ce
CSeq: 1 INVITE
Via: SIP/2.0/TLS ….. :62802;ms-received-port=62802;ms-received-cid=3D300
Content-Length: 0
ms-diagnostics: 12000;reason="Routes available for this request but no available gateway at this point";source="<LyncServer FQDN>";appName="OutboundRouting"

If the call drops after a few seconds, you will want to check the “Enable outbound routing failover timer” setting in the Lync Server 2013 Trunk that you defined for the SIP Trunk.

Specifically, this setting will cause Lync to drop the call if it doesn’t complete it in 10 seconds. Some SIP trunks can take longer to setup the call, so you might need to disable this settings. This is described further previously in this blog entry under “Key Tips”.

Inbound Issue: No Inbound Audio and a SIP/2.0 400 BAD Request

If an inbound call rings through to the Lync user, but no audio can be hear from the caller, in my experience there are three potential problems.

1. The Inbound Media Ports are not Opened on the Firewall.  The most obvious cause is that the media ports are not open on the firewall. A network port scanning tool should be used to verify that the port range that the SIP trunk uses to send the audio through is opened.
2. Centralized Media Processing needs to be Enabled on the Associated Lync SIP Trunk.
   • This setting in on the Lync trunk tells Lync that the IP address for the SIP trunk used for the media is the same as the IP address on the SIP trunk that is used for the SIP signaling.  If the IP addresses are the same, and this is not set, you will experience audio issues – specifically no inbound audio in my experience.
   • You can see all the Lync Server 2013 Trunk configuration settings on Microsoft Technet here: Modify SIP Trunk Configuration Settings.
3. The external Firewall is not configured (or does not support) the ability to NAT IP addresses at the Session Description Protocol (SDP) level.
   • This problem can easily be configured by doing a packet capture on the SIP trunk side. If the IP address used in the out-going Lync SDP requests are the internal NIC of the Lync Mediation server there is no NAT being done. Most SIP trunks require require the public IP (of the firewall or externally connected gateway) in the SDP layer.
   • Many older firewalls from certain manufactures (such as the Cisco PXE 515e) do not NAT at this level.  Some SIP Trunk providers such as IntelePeer are able to NAT it on their end, and this will resolve the issue.
   • As mentioned above, the hallmark flag for this issue is a SIP/2.0 400 BAD Request in the Snooper logs:

SIP/2.0 400 BAD Request

TL_INFO(TF_PROTOCOL) [0]1388.2388::04/24/2013-19:09:55.121.0001ca88 (SIPStack,SIPAdminLog::ProtocolRecord::Flush:2420.idx(196))[1487080697] $$begin_record
Trace-Correlation-Id: 1487080697
Instance-Id: 101E
Direction: incoming
Peer: <Lync mediation server>:5070
Message-Type: response
Start-Line: SIP/2.0 400 Bad Request
FROM: <sip:LyncPoolFQDN>;tag=78487B30899D015765DB0B0D60A1A729;ms-fe=LyncFrontEnd_FQDN
TO: <sip:LyncMediationServerFQDN>
CALL-ID: 9F3C3F68F0322050961C
CSEQ: 1 NEGOTIATE
VIA: SIP/2.0/TLS 10.4.49.177:53575;branch=z9hG4bKC5687AD3.FB2A5CCBDD249253;branched=FALSE
CONTENT-LENGTH: 0
REQUIRE: ms-compression
ms-negotiate-data: LZ77-64K

References

These are the best references I found to get up-and-running with Lync Server 2013 and a SIP Trunk:

Kuando’s BusyLight has been a fan favorite in the Lync community for sometime. I rarely write about Lync products on this blog, but I find this product unique because it touches on the ability to extend the power of Lync’s presence into the physical world – using customer hardware – which can potentially increase productivity in the work environment.

For me, the ability to physically show my Lync Presence in the front of my office and not be disturbed when I was busy or on a conference call was enough of a carrot to give it a whirl. Kuando recently released updated software that integrates with Lync that supports Lync 2013. My experiences are below.

BusyLight Overview

If you are not familiar with the device, at a high level it is a USB light that displays the Presence in your Lync client and can also play different sounds based on events in Lync (e.g. when you receive a Lync call).

Colors. Out-of-the-box the default colors for the default Presence states in the Lync client map well to the BusyLight. Not all the Presence states map to a single solid color however. For example, the do-not-disturb state is a red icon with a horizontal white line through it in the Lync client. To accommodate this, Kuando has introduces a Purple for do not disturb, but you can customize it.

Sounds. The BusyLight can play several ringtones at a customized volume when a Lync call is received. At first I questioned the need for this, but in some shared office environments this could be very useful, not to mention for the visually impaired.

Here is a picture of the BusyLight mounted in the window at the front of my office.

* Note: the latest and greatest version is now black.  See the main product page for a screen shot.

What’s new in version 1.1.164?

1. Support for the Lync 2013 Client
2. Busylight now has Busy In a Call status. The default setting for Busy In a Call is a pulsing red.
   You can change it back to standard red via the system tray icon.
3. Do Not Disturb is now purple (to distinguish it from Busy). You can change it back to
   standard red via the system tray icon.

There is a small software package that needs to be installed on your client machine that is a bridge between the Lync client and the BusyLight.

Tips

1] If your BusyLight ever gets into a state where it is not accurately reflecting your Lync state. Kuando is aware of this bug and it will be fixed in the next software release. This only happened to me twice, and here is how you can correct it:

• Try the Reset Lamp action on the BusyLight tray application
• If that doesn’t rectify it, just restart the BusyLight application

2] It works when you switch SIP identities on the fly.

3] The BusyLight FAQ contains some good information on system requirements and how to install if you are not an administrator.

Conclusions

The BusyLight is a good device to physically extend the power of Lync presence. I am already thinking of getting one for home and training my kids to respect that status light .

I would pay extra for a WiFi model that would allow the presence device to easily be mounted anywhere (I had to use a USB extension cord to get it to my office door).

Microsoft Lync Server 2013 ships with Microsoft PowerShell Version 3.0 which has many improvements to the PowerShell command line interface. Coupled with new additions in the Microsoft Lync PowerShell module, the two bring a lot of great new things to the Lync Administration table. This blog post contains the top 5 things I have discovered so far.

1] The Show-Command CmdLet

The new PowerShell V3 Show-Command cmdlet bridges a bit of the gap between a CLI and GUI interface – which eases some of the syntax-challenges with a CLI interface.

Running this cmdlet opens a small user interface with a list of all available PowerShell modules in your PowerShell session and a full listing of all of the cmdlet’s, aliases, drives, and functions available in those modules.

Even if you are comfortable with the command line, the new Show-Command cmdlet can help you:

1. Easily discover and explore what cmdlet’s are available and what module they reside it (see the Tip below)
2. Easily see what parameters need to be entered to run the cmdlet

Tip – You can quickly filter on the cmdlet’s available in a particular PowerShell Module by using the Modules drop-down. Here is a screen shot with the filter applied to the Lync PowerShell module. This shows all the Lync Server 2013 cmdlets that are available.

Hmm…notice the new LyncOnlineConnector module.

Any available cmdlet can be selected (or type its name in Name textbox), and the GUI presents a bottom panel with the parameters for that cmdlet. Below is a screen shot of the Get-CsUser cmdlet. The parameters can be supplied in the GUI and it can be run directly from the GUI  – which in-turn runs the cmdlet on the command line.

2] Easily Return the Lync Policies Assigned to a User

There is a new Lync Server 2013 PowerShell cmdlet called Get-CsEffectivePolicy that returns all the Lync policy assignments for a Lync user – regardless of whether the policy is a user policy, a service policy, a site policy, or the global policy. This simplifies user account management and reporting compared to Lync Server 2010.

In Lync Server 2010 the only cmdlet available to see which Lync policies have been assigned to a particular user was the Get-CsUser cmdlet – and this cmdlet only returns any user level policies; any assigned global, service, or site policies will not be shown (just a blank value beside the policy property). Instead, a non-trivial Lync Powershell script was required to return all of the policy assignments for a user as documented here: http://blogs.technet.com/b/csps/archive/2010/06/07/scriptuserpolicyassignments.aspx.

Here is an example of how the Lync Server 2013 Get-CsEffectivePolicy simplifies life.

The Get-CsUser cmdlet’s returns the following 15 Lync policy assignments for user “Curtis Johnstone”:

> Get-CsUser “curtis johnstone”

…
VoiceRoutingPolicy      :
ConferencingPolicy      :
PresencePolicy          :
DialPlan                :
LocationPolicy          :
ClientPolicy            :
ClientVersionPolicy     :
ArchivingPolicy         :
ExchangeArchivingPolicy :
PinPolicy               :
ExternalAccessPolicy    : User Policy
MobilityPolicy          :
PersistentChatPolicy    :
UserServicesPolicy      :
HostedVoicemailPolicy   :

But the Get-CsEffectivePolicy returns all the policy assignments for the Lync user – regardless of whether they are user, site, service, or global policies as shown here:

> Get-CsEffectivePolicy “curtis johnstone”
Identity              : curtis johnstone
ConferencingPolicy    : Global
PresencePolicy        : Global
LocationPolicy        : Global
VoicePolicy           : Tag:International All
LocationProfile       : Global
ClientVersionPolicy   : Global
ClientPolicy          : Global
ImArchivingPolicy     : Global
UserPinPolicy         : Global
ExternalAccessPolicy  : Tag:User Policy
HostedVoicemailPolicy : Global
MobilityPolicy        : Global
PersistentChatPolicy  : Global
VoiceRoutingPolicy    : Global
UserServicesPolicy    : Global

3] New Features and Enhancements to the PowerShell ISE

PowerShell V3 ships with the Windows PowerShell 3.0 Integrated Scripting Environment (ISE). While it lacks some advanced features of more mature 3rd-party PowerShell development environments used for heavy script development, it does have some nice enhancements and feature additions which makes it a lot better for Lync Administration.

IntelliSense and Context Sensitive Syntax Help

PowerShell by nature is a syntax-heavy language. Providing IntelliSense (type-ahead possibilities) and pop-up syntax references is a big help.

This is available in both the PowerShell ISE IDE and the ISE console window:

This is also particularly useful for interrogating variables such as the environment variable as shown here:

In-Place Updating of Windows PowerShell Help

Directly from the PowerShell ISE you can update the help (select Help | Update Windows PowerShell help). This will update the content for all the cmdlet’s in the loaded modules:

Microsoft Powershell MVP Shay Levy has some great pointers about the updatable help system in this post: Improving the output of Update-Help such as you must be running as an Administrator in order to update the help.

Windows PowerShell ISE Add-On Tools

The PowerShell ISE has the ability to be extended with ISE Add-On’s. An Add-On is a piece of PowerShell code which extends the functionality of PowerShell ISE – for example, you can add the ability to do a spellcheck or create an html version of the current script for printing or add custom menu entries that carry-out an action.

There is a lot of potential here for Lync Administration. For example, if you have a Lync administration script that returns a list of Lync users and their properties, you could extend the PowerShell ISE to query the policy settings of a Lync policy assigned to a user that you have highlighted in the output.

See the Microsoft TechNet Windows PowerShell ISE Add-On Tools website to get started.

4] New & Changed Lync PowerShell CmdLets

New Lync Cmdlets

There are 173 new Lync specific cmdlet’s added in Lync Server 2013 PowerShell module (567 Lync Server 2010 versus 740 in Lync Server 2013). Rather than list all the new cmdlet’s here I will summarize the new cmdlet’s associated with the new Lync 2013 functionality (if you do want a full listing fellow Lync MVP Tom Arbuthnot did a nice job of this on his blog during the Lync 2013 Preview Release).

Lync Cmdlet’s that have Changed from Lync 2010

During my Lync Server 2013 travels, I have not found many Lync specific cmdlet’s that have changed behavior.

Several cmdlet’s return more properties – usually reflecting the new Lync 2013 features. For example, the well used Get-CsUser cmdlet returns 64 Lync user properties, whereas Lync 2010 returned 56. Here are some of the new Lync user properties:

• ExchangeArchivingPolicy
• UserRoutingGroupId
• VoiceRoutingPolicy
• LegalInterceptPolicy
• PersistentChatPolicy
• UserServicesPolicy
• ExperiencePolicy
• HostingProvider

The Get-CsConfigurationStoreLocation cmdlet now returns 2 properties BackEndServer & MirrorBackEndServer to reflect the high availability and backup and recovery features of Lync 2013, whereas in Lync 2010 this cmdlet just returned one string with the SQL Server path to the computer running the CMS.

5] The Windows PowerShell Web Access feature

PowerShell V3 boasts another useful Administration feature – the ability to host a PowerShell session within a web browser. The PowerShell console is hosted on an IIS web site and provides a basic text console where you can run PowerShell cmdlet’s. The console will connect to the remote computer that you specified during the sign-in process (in this case a Lync 2013 server).

This opens the door for doing basic Lync Administration from a web browser, which would be really useful on a device or computer that has a web browser available but is not running Windows – such as your favorite tablet smartphone if it has network access to the IIS web site.

This is available in Windows Server 2012, but not Windows 2008 or Windows 2008 R2, and Windows Server 2012 does not have the Windows PowerShell Web Access feature enabled by default, so you first need to enable the feature using the new Server Manager.

Tip – making this feature work requires several non-trivial configuration steps in addition to installing the PowerShell Web Access (including assigning a certificate, etc…). Nevertheless, it can be a useful Administration feature if you need it.

There are some limitations compared with the regular Windows PowerShell console which are outlined here: http://technet.microsoft.com/en-us/library/hh831417.aspx#BKMK_web.

Here are some good references to get you started:

• Microsoft TechNet – Deploy Windows PowerShell Web Access
• Microsoft TechNet – Use the Web-based Windows PowerShell Console
• MVP Jan Egil Ring’s blog – Windows PowerShell Web Access

A restriction to public certificates was introduced several months ago that could affect your planning of a Microsoft Lync, Exchange, or other application service deployment. While this change restricts only public certificates that contain an internal name with an expiry date after November 2015, you should be aware of this change for planning and certificate renewal purposes.

The Change: No Public Certificates with Internal Names Allowed

In a nutshell, the change will mean that Public Certificate Authorities (e.g. GoDaddy, DigiCert, VeriSign, Entrust, etc..) will no longer issue public certificates that contain an internal only name – i.e. a name that cannot be publicly verified. For Microsoft Lync and Exchange this equates to not allowing public certificates used on servers that have an internal (private) AD suffix – e.g. domain.local.

Note: before this restriction, many public CA’s frowned upon this type of certificate, and wouldn’t issue them anyway.

The specific requirement for this change can be found in the CAB Baseline Requirements document here: https://www.cabforum.org/Baseline_Requirements_V1.pdf.  Section 9.2.1 details the requirement: “

“….the CA SHALL NOT issue a certificate with an Expiry Date later than 1 November  2015 with a subjectAlternativeName extension or Subject commonName field containing a Reserved IP Address or Internal Server Name”

The CAB is a voluntary organization of certification authorities (CAs) and web browser vendors.

This restriction is targeted at certificates with expiry dates after November 1, 2015, but apparently some Certificate Authorities that previously did this are already rejecting these types of certificate requests. Any of these types of certificates already issued will be good until their expiry date however. The CAB specification states that “the practice will be eliminated by October 2016”.

What Does it Mean for Microsoft Lync and Exchange?

While not common-place in Lync and Exchange deployments, it was sometimes used in deployments with two namespaces – one public (domain.com) and the other private (domain.local) with an associated split-brain DNS deployment – as a useful solution to a couple of challenging Lync and Exchange authentication issues.

For example, in Microsoft Lync, using a certificate that is signed by an internal Certificate Authority will present problems for any client that does not trust the private CA certificate chain.  This includes any non-domain joined Lync clients or Lync Phone devices that could not download the internal certificate. The issue was amplified with the introduction of the Lync Mobile clients which would sometimes connect internally via the Lync autodiscover service but did not natively trust an the internal CA.

Lync MVP Jeff Schertz nicely details how this issue is magnified in Lync Server 2013 with the introduction of more Lync clients that depend on the Lync autodiscover service, and concludes:

“The first solution would be to simply start issuing public certificates to the internal Lync servers but this approach may not work for all environments as many third party certificate authorities will not allow certificate requests which contain internal-only domain names”.

Several Public CA’s, such as DigiCert, did allow public certificates with internal names, and it made for a simple solution to these types of issues. Jeff offers some updated guidance (in his blog entry) which does not require a public certificate with an internal name for this situation.

I have had other Microsoft Lync and Exchange authentication issues that were nicely solved with a public certificate that contained an internal name. So why was it frowned upon?

What was the Issue with these Types of Certificates?

While public certificates that contained internal names simplified some deployments, it was somewhat frowned upon because it was seen as a potential security risk:

1. It is generally not a good security practice to put internal names on things that are meant for public purposes; even if they are used for internal only services.
2. A potential security risk – in theory at least – that went along the lines of:
   • A hacker (aka bad guy) finds out the internal name (e.g. domain.local) used inside a company (e.g. through some sort of network access) by looking at the certificate.
   • The hacker goes to a CA and acquires a public certificate issued with this internal name on it (e.g. domain.local).
   • The hacker then set’s up a rogue version of a popular application service using this certificate that accepts user authentication attempts (user name and passwords) – for example, a network service that mimics Lync Server on port 5061.
   • The hacker then get’s corporate users to logon to the rogue network service (via DNS poisoning, DHCP impersonations, etc…).
   • This allows the hacker to collect user names and passwords.

As someone pointed out to me, a hacker could achieve the same thing with an internal certificate that they issued themselves with their own internal CA – with the exception that users will have a chance to opt-out from connecting because they will get the “…this certificate is not trusted” warning – but 90% of users would accept that warning if it meant getting at their Outlook email.

Nevertheless, restricting certificates of this nature is more secure.