Why I love Lync Server 2013 Standard Edition and so will you!

I am a big fan of Lync Server 2010 Standard Edition but it was lacking in some key areas which held it back from being a deployment architecture of choice. From my experience with UC over the last 7 years there is a lot to be said for simplistic architectures.  Lync Server 2013 SE has some new DR features that could mean it’s a whole lot more applicable in the UC space for mid to small organizations.

What can Standard Edition do for you?

    • Scalable up to 5000 users, which covers a large percentage of companies.
    • Simple to deploy. No load balancers required for the Front Ends.
    • Separate SQL deployment not required for Front Ends.
    • Supports all workloads (IM, Presence, Voice, Video, Desktop Sharing and Web conferencing).

What's new in 2013?

Overall Standard Edition has a lot to offer to small and midsized organizations. I expect to SE deployed more often with Lync Server 2013 as companies look to consolidate down their server footprint and simplify their environments.


Lync 2013 Preview Released

For those that were wondering here it is:


Looks for articles related to voice changes over the next few weeks as I step into the new way to do work!


CUCM SIP URI Dialing to Lync 2010-This could change your life or at least your dial plan!

While I am not about to promote the use of Cisco’s mobility feature to dual ring a Cisco phone and Lync, there is an interesting feature that could make your life easier if you insist on using it. Its called SIP URI dialing. This isn't a new feature as its been around since 7.x days or possibly earlier. It sparked my interest back in 2008 but I never really investigated it further until recently.
SIP URI dialing is really a pretty basic concept. Instead of using a normal DID route pattern to designate a destination you use a SIP URI such as lyncuser1@home.local. By specifying @home.local as your SIP route you assign a SIP trunk that points to Lync. Its actually pretty simple and works with Cisco’s mobility feature used in Remote Destinations.
There are some caveats with this feature though and its not terribly flexible. It does require some special configuration but could possibly make dial plans and migrations a little easier. Also you can remove the issue of having the same number used on both systems because now that your ringing between systems with a unique SIP URI using the same DID on both systems is much less problematic. So users don’t have to change numbers or use a new number for Lync, it can be the same as their Cisco IP phone.
To make things a little easier to understand, in this post I am referencing the To field in a SIP message when I am talking about Tel URI or SIP URI. I am using Tel or SIP to define trunk routing behavior even though both are configured as SIP trunks when configured in CUCM. Its just the routing behavior based on the address format I am trying to better define. Hope that’s not to confusing.
Why use it?
While working in the field I get a lot of questions from engineers around how do I make my Cisco phone and Lync ring at the same time. As I have covered here on my blog there are a couple of ways to do this from either CUCM, Lync or even potentially from a gateway. But there is a level complexity in regards to how to configure DID’s and how to make DID’s unique enough so that you can route between the two platforms. Well using SIP URI dialing instead of DID’s this simplifies this portion of the configuration and leaves Lync’s Sim Ring feature open for users to configure it for their cell phones. Using Sim Ring as the tool to ring a Cisco desk phone in my opinion is a waste of an easy to configure end user setting. I strongly believe this feature is better used to ring a cell phone or other devices self administered by the user.
Caveats for SIP URI dialing?
The single biggest caveat for SIP URI dialing is that when you create a SIP Route pattern it does not allow assigning a route group to it. You have to directly assign a trunk to the route pattern. The main issue is that once assigned to the SIP route pattern you can no longer assign the same trunk to a route group which limits your options. The best way to deal with this is to have a SIP trunk just for SIP URI routing. In CUCM 8.6 you can have multiple endpoints (in our case mediation servers) assigned within a SIP trunk which means that this isn't a redundancy problem. Its more a configuration issue on the CUCM side but since this configuration is for a specific purpose I don’t consider this a show stopper.
How to set it up?
The easiest way to do the setup is to follow this guide with a few alteration which I will call out below. This is the Microsoft produced guide which I prefer over the Cisco guide. In the Microsoft guide they make use of Calling Search Spaces (CSS) which gives a more complete picture of the settings required. In the Cisco guide there is no call authorization setup so unless you know which CSS to configure you could easily miss a setting as there are multiple places to set CSS on various pages. The one that caught me out was the rerouting CSS on the Remote Destination Profile.
What's needed for Lync?
The SIP URI trunk is for inbound use only. This means that setup on the Lync is pretty simple if you already have a SIP trunk setup for your CUCM deployment. As long as your CUCM servers are already added to the topology as gateways you are already done. Just make sure that the inbound SIP URI trunk to Lync is using already established ports. 
How do I configure CUCM?
In my testing I was using CUCM 8.6 so your settings may vary depending on the version you have.
SIP Trunk
The thing with this configuration is that you are creating a SIP trunk for one purpose and that is to ship messages with headers that have the “to” field with a SIP URI format to Lync. So LyncUser1@home.local as an example.
Your Tel URI and SIP URI SIP trunks can share the same SIP Security Profile and outbound ports to Lync but you will need to use different DNS/SRV names or IP address DNS name combinations. So as an example I used:
SIP URI Trunk – FQDN – home-lync-rtm.home.local
Tel URI SIP Trunk – IP Address
Below is my trunk configuration for my SIP URI routing with a FQDN for my Lync 2010 Mediation Server.
In my case I used a IP address on one trunk for Tel URI calling and the FQDN on the SIP URI trunk. Now if you are not that fixed on configuring route groups and route lists for the SIP trunk connecting to Lync you can configure the trunk directly on both DID and SIP URI route patterns and just have one trunk. I tried both in my lab and it worked either way.
SIP Route
Probably the new piece of configuration to most people will be the SIP route itself. Its pretty easy to configure. See below. I created a domain route to home.local to route my SIP URI traffic that I setup for my users on their Remote Destinations.
User Setup
As far as the user setup goes the only variation between the standard setup mentioned in the guide I referenced earlier is to configure the user with a SIP address to route calls in the Destination Number under Remote Destination configuration. In my case I used lync01@home.local as my destination number rather than a DID or other number.
This configuration is probably one of the most important interoperability pieces I have written in a while. I can see this alleviating quite a few issue I have come across in the field and hopefully this article will get good circulation so more people know about it.
If folks need more explanation please feel free to post your questions. Cisco’s Unified Mobility can be a pain to setup first time around but funnily enough the Microsoft guide does a really good job of walking through the configuration. I can’t say the same of Cisco’s.

Update: I have confirmed this configuration is valid for Lync 2013. I have not fully tested new routing capabilities in 2013 that could simplify this configuration but will update this post when completed.