Cisco ISR – Lync Integration Issue

February 24, 2011 2 comments

Great post by voipnorm here regarding issues with Cisco gateways and
Microsoft Lync!

http://voipnorm.blogspot.com/2011/02/issue-alert-cisco-gateways-with-lync.html

Categories: Lync

Integrating Microsoft Lync and Cisco Unified Communication Manager Part 1: Understanding the Capabilities and Terminology

February 21, 2011 14 comments

This is part one of a multipart series I will be writing on the integration of two of the most popular Unified Communications systems. This is based off many hours of research and historical and recent personal experience actually doing this integration.

As in any project, it is important to understand your customer’s requirements and to set proper expectations. Microsoft and Cisco have in the past worked to provide recommendations for integrating their products but as of recently have increased the competition part of their relationship due to the realization that Microsoft has a player with Lync.

Let’s start to define the features that might be desired with a Microsoft Lync and Cisco UCM integration:

Feature Capabilities
Enterprise Voice Cisco and Lync are both fully functional Enterprise Voice Solutions and provide integrations together utilizing a direct SIP (SIP Trunk in Cisco world)
Media Bypass Microsoft Lync Server 2010 can utilize media bypass and send direct G.711 traffic to a Cisco gateway configured as a Media Termination Point (MTP)
Survivable Branch Microsoft and Cisco both provide a means for a survivable branch, Cisco through Survivable Remote Site Telephony (SRST) and Lync through Survivable Branch Appliance or Survivable Branch Server
Dual Forking / Simultaneous Ring Microsoft and Cisco both provide technology to ring another device.
Unified Messaging Both Microsoft Lync and Cisco UCM can be easily integrated into Microsoft Exchange Server 2010 for Unified Messaging. And yes, you can light the Message Waiting Indicator natively.
Call Admission Control Lync 2010 provides Call Admission Control based on Regions, Sites and Links with the ability to provide CAC to roaming users not just the device. Cisco also has the ability to provide CAC to Cisco based devices. The same CAC solution cannot control the competing product.
Quality of Service Microsoft and Cisco both utilize Differential Services (DiffServ) markings for Quality of Service.
Conferencing Conferencing can be easily provided to users of Cisco UCM and Lync utilizing Lync Server’s conferencing MCU. The conferencing MCU also has certified integrations with Polycom RMX and LifeSize MCUs through the Unified Communications Open Interoperability Program for Lync.
Remote Call Control Microsoft Lync has the ability to control Cisco desk phones in order to enable you to dial a number in your Lync client and have it make your Cisco desk phone go off hook and dial the number in Lync. This also enables presence information to pass between the Cisco desk phone and your Lync client to show that you are “In a Call” when you pick up your Cisco desk phone.

It should be noted, that I will provide some opinions and recommendations during this multi-part series of blogs, that is why this is my blog and hopefully why you read it. I write this blog because I know there are a lot of people out there looking for information on what works and not just from someone that has read about it themselves, but someone that has done this themselves and knows the good, bad and ugly. I know that there are reasons for organizations to keep their investment in Cisco, whether they are technical or probably more likely political. With all that said, let’s get started on what part 1 will focus on: Understanding the Capabilities and Terminology.

In our environment we will try to replicate what I would expect to see in any midsize to large organization. Our main location in the US has a Cisco environment built with Cisco 2851 ISRs and a single publisher and multiple subscriber nodes. Our ISDN/PRI lines terminate at our Cisco 2851 which are MGCP controlled by our Cisco UCM infrastructure. Our dial plan is centrally maintained by call manager and our 2851 is configured for SRST and has necessary configuration information to allow calls to the PSTN in the event of an outage of our cluster (which never happensJ).

We have also deployed a highly available Microsoft Lync 2010 consisting of a two node Lync Enterprise Edition Pool with DNS load balancing for the SIP traffic and a pair of Hardware Load Balancers for the HTTPS traffic. Management has decided to begin to provide users the option to switch from their desk phone to a soft phone to reduce licensing cost and provide a better user experience for users that have laptops that tend to work remotely a lot.

The decision to begin offering Lync as an alternative to a desk phone needs to come from management. There needs to be buy-in at the top levels which is not necessarily due to the capabilities but due to pushback organizations receive from telecom departments. In addition, to provide an easy to manage environment moving from a desk phone to a soft phone will typically require a user to change their phone number. This is not necessary for technical reasons, but sure makes management of both systems much easier. This is due to the fact that one system will “own” the phone number. In our implementation Cisco “owns” the phone numbers since the gateway is MGCP controlled and there needs to be either a Directory Number (DN) or a route pattern in the CUCM*.

* It is possible but an administrative nightmare to have a directory number for a number that should be in Lync, this can be done by forwarding all calls to a dummy route pattern across a SIP trunk to the Lync server. This is not recommended due to the added complexity of managing the CUCM and Lync environment. In addition, it would typically require coordination with multiple groups for implementation and troubleshooting.

Back to our scenario…

Before you begin the integration, it is important to take your requirements and map them to the capabilities of the integrated Lync and Cisco environment. One of the features that we want to implement is media bypass which allows the Lync client to talk directly to the Cisco 2851 gateway using G.711. Cisco gateways support this capability by using Media Termination Points or MTPs. MTPs are resources that do a number of functions depending on the protocol used. In our scenario, MTPs are required to provide RFC 2833 compliant SIP services between the Lync and Cisco environment such as DTMF and a relay point for media between Cisco and Lync endpoints. RTP traffic encoded with G.711 flows from the Lync client to a MTP then to a Cisco IP Phone when the client has detected that the site that it is in has that capability and the administrator has allowed and configured it.

There are two types of MTPs:

  1. Software based MTP resources can be configured on the router or CUCM Subscriber nodes. Software based MTP resources use server based hardware resources (memory, processor) and degrades the performance and capabilities of the cluster or gateway
  2. Hardware based MTP resources are configured on the gateways. These resources utilize Digital Signal Processors (DSPs) rather than the built-in hardware on the router. It is recommended to use hardware based MTP resources to provide added scalability to your environment.

A typical configuration for hardware based MTP resources will look something like this:

sccp ccm group 1
bind interface FastEthernet0/0
associate ccm 1 priority 1
associate profile 102 register LyncRouter1

dspfarm profile 102 mtp
codec g711ulaw
maximum sessions hardware 100
associate application SCCP

MTP resources, once created on a gateway will be available use on our “SIP Trunk” when we create it in our CUCM environment. It is required when we create our “SIP trunk” to enable direct SIP integration between Lync and CUCM that we require a Media Termination Point and select a of Media Resource Groups List (MRGL). A MRGL provides a prioritized list of Media Resource Groups (MRGs). In our next section, we will discuss how to complete the integration between the CUCM and Lync environments in our main site. Further sections will talk about branch office scenarios and what happens when we experience a failure. I will leave you with a high level diagram of what this environment will look like at our main site.

Categories: Lync

Lync 2010 Edge Server – OCS R2 FE Pool Problems

February 11, 2011 3 comments

Let me premise this by saying you should follow Microsoft support guidance when migrating from OCS 2007 R2 to Microsoft Lync Server 2010. It is recommended that you migrate internal services and users to Microsoft Lync Server 2010 before migrating the Edge services to a Lync 2010 Edge Pool. (Migrating from OCS 2007 R2 to Lync Server 2010 – http://technet.microsoft.com/en-us/library/gg413057.aspx)

Sometimes however you want to add new features to your environment that were not previously available. This was the case when I began to assist a colleague today with an interesting issue. Existing OCS 2007 R2 users were amazed that when they took their laptops home with Communicator R2 running that they were able to connect without VPN. They did not previously have this capability and this was due to corporate policy. In an attempt to resolve this issue, user policy was updated to remove “External Remote User Access”


This however did not resolve the issue. Communicator R2 users were still able to login via the Lync Edge Server. The topology was as follows for external user connectivity: Lync Edge Pool next hop = Lync FE Pool, Lync FE Pool and OCS R2 Pool Federation Route = Lync Edge Pool.

We logged SIPStack on the OCS FE server and Edge Servers and identified that the flag ms-edge-proxy-message-trust is being set. A call to PSS and our engineer was able to easily replicate the issue in less than 15 minutes. The important part about this post isn’t that OCS R2 clients are able to log in when remote user access is disabled, that is understandable given that it isn’t supported. The problem is that when you add a Lync Edge Pool to the environment and merge the topologies it adds the edge server as the federation route for OCS 2007 R2. Regardless of your policies you have in place, users will be able to connect via edge services during this time until they are either migrated to Lync and disabled for external user access or you remove the Edge server from the OCS 2007 R2 environment.

Categories: Lync

The Most Common Question I Answer about Microsoft Lync

January 24, 2011 1 comment

“Is Microsoft Lync ready to handle my call load?” Miercom, a well-known and respected consultancy performed a myriad of tests against Lync Server (which was running in a virtual environment on Hyper-V). I was amazed to see that Lync was able to handle over 4 million calls over a 13 day period with 100% success.

So my answer to that question is a firm “Yes, absolutely it can!”

Report available here: http://bit.ly/hu39Gr

Source: http://blogs.technet.com/b/ucedsg/archive/2011/01/21/but-does-lync-server-2010-really-have-pbx-voice-reliability-or-call-scalability.aspx

Categories: Lync

Lync 2010 Response Group Call Transfer Fails

January 5, 2011 Leave a comment

I recently completed a Cisco Unified Communication Manager migration to Microsoft Lync Server 2010. During the planning stages we identified 2 simple Hunt Groups that needed to be created using Lync Response Groups. These were pretty simple in that an inbound call would use a list of agents when signed in and if nobody answered it would be sent to the Exchange UM Auto Attendant.

The problem comes when Lync transfers the call to another system like Exchange UM which as you can see in the process flow above we do if there is no agent available or it is outside of business hours. The configuration for the Response Group Forward is shown below with the SIP URI of the Lync Auto Attendant configured using OCSUMUTIL.exe.

By navigating to the Lync Server Control Panel – Selecting “Voice Routing” – then “Trunk Configuration” – then selecting Edit for the “Global” Trunk you will see “Enable Refer support”. “Enable refer support” when checked will send SIP REFER messages across the trunk (in this instance between Lync and Exchange 2010). However, it appears when selected calls from the PSTN to a Response Group that are then transferred to Exchange Auto Attendants will be dropped.

Categories: Lync

Microsoft Lync Has Reached RTM

December 1, 2010 Leave a comment

Yesterday, the Microsoft Communications Server Team announced that Microsoft Lync has reached the RTM milestone (Released to Manufacturing). This process begins the steps to get the code available to customers and partners worldwide called General Availability (GA). I know many of you are very anxious to get your hands on the final release and understand what it means to go from RC to RTM code, but please be patient. It typically takes 2 weeks from the RTM announcement to have code GA to Microsoft Volume Licensing (MVLS) and TechNet follows behind that. Make sure to follow the Microsoft Communications Server team here: http://blogs.technet.com/b/uc/archive/2010/10/27/microsoft-lync-released-to-manufacturing.aspx

RC to RTM Migration

Those of you that have deployed the Release Candidate of Microsoft Lync Server will take solace knowing that there will be a process to migrate to the RTM code. Notice however that I said migration; this will be a side by side migration with new servers and new enterprise edition pools (this includes a new SQL instance to avoid overwriting the RTC databases!).

There is a lot of excitement out about this product and how it is going to truly change the landscape of PBX deployments. This is the reason I started this blog 2 years ago! It is an exciting time to be a UC consultant and I am very proud to be a Microsoft UC MVP!

Categories: Lync

Lync 2010 Edge Server Deployment – “The Supplied Handle is Invalid”

November 29, 2010 Leave a comment

When deploying a Lync 2010 Edge server you may encounter the following error during the Enable-CsComputer operation:

Command execution failed: The supplied handle is invalid. This can happen when trying to set an ACL on an anonymous kernel object.

I have been able to replicate this issue several times on edge servers which have NetBIOS names that exceed 15 characters. It does not appear the length of the FQDN is an issue. To overcome this issue at this time simply use a server name for the edge server that is 15 characters or less.

Categories: Lync