MSIT’s Lync “Dogfood” Deployment

Microsoft internal IT department has released this new Whitepaper on their Lync deployment that was used to displace 7 PBX’s. It has some great lessons learned and driving reasons behind the internal deployment of Lync.

Of course Microsoft were always going to deploy Lync internally but MSIT are pretty straight forward and honest when it comes to product feedback to Microsoft product groups and customers. They had a voluntary program for people to sign up as beta users. Over 28,000 signed up to be on the “dogfood” program which shows just how popular the features of OCS R2 had been internally.

As for me I have been on the MSIT Lync “dogfood” program since they launched. Having been through a number of upgrades as they moved from Beta to RTM code it really has been a successful program with great results. I haven't experience a single service interruption and considering I am a mobile worker rarely stepping into the office this is impressive.

If you get the chance check the whitepaper out. Its in point format so it’s a quick easy read.

Comments welcomed.

VoIPNorm

Lync Work Flow Poster

Paul from NexusIS has done a great job putting together this Lync work flow poster. Well worth checking out as he has done a great job.

Clicking on the picture will take you to the larger view. Remember that this is copyright protected material and belongs to Paul Gurman and Nexus IS.

Comments welcomed.

VoIPNorm

More on Lync Inbound Normalization

A question arose from an earlier blog post around inbound normalization which I thought I would respond with a much larger post rather than just a comment.

For a great in-depth look at normalization rules check out this blog post by Jon from Time2Market here. Also the TechNet guide can be found here.For this post I am just focusing on inbound normalization configuration.

There are three options for inbound normalization in regards to granularity. Either Global, Site and Pool can be selected when creating a new dial plan. Two important points about granularity:

1 .Dial plans are not additive and neither are the normalization rules. So what I am trying to say is that inbound normalization will only happen against one dial plan and with that…

2. The most granular is the dial plan that will be used for inbound normalization. So if you create a gateway dial plan it will be used and a site or Global dial plan will be ignored for inbound normalization. Same can be said if you create a site dial plan with no gateway dial plan, in this case the global (default) dial plan will be ignored for inbound normalization and the site will be used.

Below is a diagram showing how the hierarchy works within Lync. At the pool level you have a service level dial plan specific to gateways.The service level PSTN gateway dial plan is applied to the incoming calls from a particular gateway.

Below is a great diagram that shows in detail the inbound and outbound normalization process when using a gateway service level dial plan.

Thanks to Clive for providing the diagrams used in this post.

As you can see getting inbound normalization right is pretty important and not terribly complex with Lync. There is a few important steps but once its in place it doesn’t require a lot of tending unless your inbound dialing behaviors change which means an update to your normalizations rules. At a high level it seems pretty obvious unless you have a specific need inbound normalization is best to happen at a site or global level. This simplifies your environment and centralizes your inbound normalization configuration but this may not always be possible. Infinite control of inbound normalization may be required which means gateway service level dial plans will be required.

Comments welcomed.

VoIPNorm

How to Disable IM in Communicator/Lync

Sounds strange but it can be done. This means that you will still see presence and still be able to do video, voice etc. but no longer have the option for IM. I have heard it works for Lync as well. Basically it’s a registry key setting on the PC. See below.

http://support.microsoft.com/kb/954648

1. Install the Communicator 2007 update package that is dated October 24, 2008. For more information, click the following article number to view the article in the Microsoft Knowledge Base:

   957707 (http://support.microsoft.com/kb/957707/ ) Description of the update for Communicator 2007: October 24, 2008

2. Configure the DisableIM registry entry. To do this, follow these steps:
   1. Click Start, click Run, type regedit, and then click OK.
   2. Locate and then click the following registry subkey:

      HKEY_CURRENT_USER \Software\Policies\Microsoft\Communicator

   3. On the Edit menu, point to New, and then click DWORD Value.
   4. Type DisableIM, and then press ENTER.
   5. Right-click DisableIM, and then click Modify.
   6. In the Value data box, type 1, and then click OK.
   7. Exit Registry Editor.

VoIPNorm

New RIM Client for Lync 2010 Coming Soon

This has been in the works for quite sometime and I am sure a welcomed client for Blackberry users. The Lync Client is still greyed out but at least we know it is coming soon.

http://ca.blackberry.com/apps-software/business/server/full/addons.jsp#tab_tab_eim

VoIPNorm

Voice Migration Strategies: CUCM to Lync

This is a common topic that I get really excited about because there some great options with Lync. If you haven’t already seen the Lync OIP interoperability page, CUCM has direct SIP IP-PBX support. Versions 4.2, 6.1 and 7.1 are now supported for direct SIP interoperability.See the excerpt from the page below:

Cisco	Cisco Unified Communications Manager	Direct SIP	UCM 4.2 2000-4-4a UCM 6.1.3.2000-1 UCM 7.1.3.10000-11
	Configuration Notes: 1. On the Cisco IP-PBX, configure MTP to enabled and PRACK to disabled (the default for PRACK). The PRACK message sent by CUCM 4 is malformed by missing the MAXFORWARDS header. 2. On Lync Mediation Server, Media Bypass is set to enabled. RTCP and REFER are set to disabled, as Cisco doesn't send RTCP messages and REFER is not supported by this IP-PBX. Known Limitations: 1. When a Lync user transfers a PBX call to another PBX user, the local PBX phone will still show connected to the first Lync user. 2. Comfort noise generation is not supported. As a result, comfort noise is not played on Microsoft Lync. 3. When a Lync user configures call forward or simul-ring to a PSTN IVR number, the calling party will not hear early media played from the IVR.

Back in 2009 I wrote about a similar topic with OCS R2. There have been four very significant changes in Lync that make migrations and interoperability less challenging compared to my original OCS post . They are

1. Media Bypass,

2. outbound number translation on the mediation server,

3. 1: many Mediation Server to gateways and

4. Mediation Server collocation.

Both the scenarios outlined below can take advantage of these features. Not only will you lower your server count because of these changes but it will also lower the amount of changes required to a CUCM dial plan. All-round these are great improvements.

So what migration or interoperability scenarios does Lync present?

Scenario 1

Pretty straight forward. Direct SIP from Lync to CUCM with media Bypass to the MTP. This is really a starting point for most organizations. Establishing the Lync deployment as a subtending PBX is a good way to get the Lync migration underway. CUCM has the capability to allow a combination of Single Number Reach to a Lync client to ring both the Cisco handset at the same time as well as the Lync client or in the case where the user no longer requires a Cisco handset port the DID to Lync. If you port the DID to Lync, CUCM becomes a tandem PBX being used for traffic management rather than endpoint termination.

Scenario 2

Seems like a simple step but adding a direct SIP trunk from the gateway to Lync once you have a numbers of users taking advantage of Enterprise Voice can make interoperability a little easier. A user could also use Sim Ring from Lync to ring a Cisco Phone with having the call trombone from CUCM to Lync then back to CUCM to ring the Cisco IP Handset. Call it a substitute to using Cisco’s Single Number Reach feature in CUCM which some see as a complex feature to setup.

This allows calls from the PSTN direct access to the Lync conferencing service rather than going through CUCM. My theory is the less you have transition through other systems the easier interoperability becomes. In this case you can really start to treat the trunk between CUCM and Lync as a simple tie trunk for interoffice calls rather putting every call through CUCM to get to Lync.

In the case of the ISR shown in the diagram you can use dial peers placed into a hunt group to route calls from the gateway. The caveat here is that Lync has to have the highest priority for it to work effectively otherwise the calls will still all be routed via CUCM unless there is a CUCM failure.

If you haven’t already noticed I am trying to avoid any IP-IP GW/CUBE functionality as this will add to your overall cost due to CUBE licensing. Although this feature has its place, interoperability with direct SIP between these platforms does not require the use of the CUBE feature. I have seen instances where companies have been told using a gateway with CUBE is the best way to achieve CUCM interoperability. This is not true.

For more information on interoperability check this post here. I also talk more about branch interoperability in my previous post.

Comments welcomed.

VoIPNorm

Lync Secondary Registrar Discovery

How a Lync client finds its secondary registrar is a very important topic. After some research and reading an excellent blog by Doug Deitterick on Technet about the process there are some very clear best practices that standout to me. The reason I bring it up here is that my opinion around using a Director for secondary registrar discovery is slightly different to Doug’s. There is a more critical component than the Director for this function. Let me explain.

Let’s take a quick recap at how the process works. The diagram below give’s a good outline of how this works when you have a Director pool in place.

The most important functions related to our discussion are the prioritized DNS SRV responses and the SIP 301 redirect message that is sent back to the client. The DNS SRV records point to the Director as the primary logon and authentication pool with a alternate pool as a backup. The 301 message contains the Primary and secondary registrar. Both of these items are very important to the logon process. Firstly should the Director pool (or any pool related to the DNS SRV record) be unavailable you have an alternative to actually logon and secondly once you have authenticated you can learn where your primary and secondary registrar is located for failover.

It is best practice that you have prioritized DNS SRV records regardless of a Director.  Every registrar in your deployment has the ability to use the 301 redirect message process including the SBA. The only time you do not receive your backup registrar information via a 301 is when you log directly onto your primary registrar. Once you have successfully logged onto your primary registrar and it is cached by the client (using the EndpointConfiguration.cache  file) unless there are issues, you are very unlikely to receive a 301 message. As Doug points out EndpointConfiguration.cache  doesn’t cache your secondary registrar. So in other words the Director is little help after you successfully logon for the first time.

I did a small experiment in my home lab. I started up my Lync client and as it had a cached primary registrar it did not perform the DNS SRV record lookup and it logged on using cached information. I then stopped the frontend service on my Lync Server. The Lync client then preformed the DNS SRV lookup to find an alternate location to logon. Once it received the alternate SRV records it was been able to locate an alternate place to logon. It then received a SIP 301 redirect. Had I actually had a real alternate SE running in my environment it would have logged in there as its secondary registrar after referring to the SIP 301 redirect secondary information.

So how would you create your DNS SRV records ? There two options:

1. Deploy a Director with prioritized DNS SRV records that point to the Director(s) as the first choice and a pool (whether it be a SE or EE pool) in another datacenter as your second choice.

2. With no Director(s) point your prioritized DNS SRV records at the pools that make sense but are most likely located in different datacenters.

Doug’s blog post does make a great point that you will not always get backup registrar information every time you logon but its regardless of whether you are using a Director or not because of the cached primary registrar. This is why it is important to ensure your DNS SRV records are correctly configured when using data center voice resiliency features, so don’t leave home without them.

Comments welcomed.

VoIPNorm

We put the You in UC

Putting the glossy well produced marketing aside I think the overall message is great. “Networks aren’t human, people are”.

Comments welcomed.

VoIPNorm