Sunday, February 26, 2012

Lync 2010 - the Dial Plan mystery

Enterprise Voice still reminds one of the mysteries of Lync deployment. While IM&P and conferencing is relatively well known and documented, EV is sort of gray area due to the fact it involves more than server and roles installation. The interaction with PSTN (Public Switching Telephone Network) often adds complexity that throws Lync Administrator in uncharted territory…

In this post, I will go over the best practices of creating Dial Plan. I have seen many people, overexcited of the possibility to make a phone call via Lync, often would omit the proper configuration and use “one fits all” rules.

Lync uses E.164 number format i.e. “international public telecommunication numbering plan”. As defined per ITU-T recommendations, E.164 format can have maximum of 15 numbers and must be prefixed with “+” sign. An example of such number is +14785550000 where “1” is the country code (US), “478” is area code (Central Georgia), “555”  is exchange (local provider’s PBX) and “0000” – extension

A very simplified explanation of the routing logic Lync uses is this: when a number is dialed from Lync client, the first action is to look if this number can be matched internally – to a user or any other object that have E.164 number assigned. If “Yes”, the call is routed internally to the object, if “No”, if appropriate action is defined, the call is “dispatched” to the destination. If there is no “routing definition”, the call fails. It is so simple!

Back to Lync and E.164. For EV enabled users, we must define the number in E.164 format, like +14785551234. The $64,000 question is – how in the world I dial “+” from my phone? From my Polycom CX600, I can dial 14785551234, but then this number will not match my user’s number because it does not have ”+” on front. Here comes the mystery of “normalization”. While “normalization” is the correct word (since we bring ANY number dialed to a “normal”, or E.164 format), I noted that people are handling the term “transformation” better. In any case, to “normalize” 14785551234 to +14785551234 OR to “transform” it - same action, just worded differently.

Here comes the magic of “Dial Plan” in Lync. Dial Plan uses RegEx (Regular Expressions) to evaluate the string and transform it (if match is found). Simply said – comes down to “what I am dialing” and “what final result I want to achieve”.


The above can invoke suicidal thoughts in any man or a woman! What does it mean??? Will I ever be able to understand how this works?

Now let’s use this approach – “when I dial something, my goal is the end result to be something else”. In this case, “When I dial 14785551234, I want the final result to be +14785551234”. The above RegEx will do just that. To write RegEx freely, however, requires you to be at least member of Mensa society or above. Fortunately, Lync Control Panel provides graphical representation of “when I dial something, my goal is the end result to be something else”.

It cannot be any easier:

Starting digits – it does not matte

Length – exactly 11 digits. (this means that RexEx will “count’ the number if digits and will not process if it is different from “11”

Digits to remove – in this case “do not remove digits”

Digits to add – add “+” on front.

Let see what happens when we test our RegEx:

We just normalized (or transformed if you wish), 14785551234 to +14785551234.

Now that we know what Normalization (or transformation) does and how to use it, let’s pull back and think about our environment. Every Lync deployment is like DNA – there could be a partial match (if two companies in same town, using the same PSTN provider deploy Lync Enterprise Voice) and yet it will never be the same because of company specifics. Proper evaluation and planning is absolutely vital for successful outcome of any EV deployment.

Here is an example if such process.
  1. In Milledgeville we dial 911 for emergency
  2. Our current “internal extensions” are 4 digit long
  3. We dial local numbers by dialing 7 digits only.
  4. Out of state we dial 11 digits (1 + area code + 7 digits)
  5. International calls – any length (011 + country code + number)
Now I will use Lync Control Panel to “convert” this to Lync Dial Plan.

***I will create new User Dial plan. For differences between Pool, Site and User dial plan, refer to the product documentation.

Here comes my first Normalization rule – for 911.

  Next is handling of 4 digits internal extensions.

***This example requires explanation. All numbers in my organization are from the block 1478387xxxx. From this prospective, it is safe to assume that when user dials (or “mash”, as they call it on South) four digits, the intention is to reach a colleague from the same organization and so, the number will always start with 1478387. Here is an illustration:

Now - local calls

***Because those calls are “Local”, they always stay within the local Area Code (478). We add +1478 on front of the number (to become E.164).

Next – Long Distance calls. There are two ways to dial LD – 10 and 11 digits. I will create two rules to capture both cases.

Lastly, a rule for International calls.

Just for fun, I will throw one more example. The Exchange Auto Attendant’s E.164 number in my organization is +14785559001. I want to provide an easy way for my users to dial the AA and reach a colleague by speaking the name. I selected *99 as “quick dial”.

The test result:

Here is the final result of my hard work:

At the end, I will commit the changes i.e. make it permanent.

In the next post, we will look at Lync Voice Policy and how it interacts in our EV environment.

Saturday, February 25, 2012

Lync 2010 on prem - Cloud UM integration

“Cloud computing is like sex in High School. Everybody is talking about it, only few did it, and they didn’t know what they are doing.”
                                                                                          Found somewhere in Internet

I have been thinking recently of one hypothetical scenario – let’s say my company has domain “” and we host Exchange and Lync on prem. We acquire small company B with domain “”. The management decides to decommission Exchange Server in Company B and move all users to Office 365 Exchange services. However, because "" already utilizes Lync Enterprise Voice, we also want to decommission Company B’s PBX and provide EV to”” users. The main question is - how to resolve the problem with Unified Messaging for Company B?

Let’s see if this is possible.

First, of course, I must sign up for Office 365 service. I created tenant “”, added “” and verified it as outlined on the online documentation.

For the purpose of this post, I created user “Myuc User” with ID This represents all users from Company B and the assumption here is the migration to Exchange Online has been competed, mailboxes migrated etc.

Next step is to prepare the Cloud service for Unified Messaging. I will create UM Dial Plan:

…and we can see, a default policy was automatically created. I might modify it later.

***I have not created Auto Attendant at this point – I am more interested if this concept will work to begin with…

Back in Users and Groups, I will enable our user for Unified Messaging

This concludes my Cloud based user configuration. now let's prepare hosted Lync for Cloud Integration.

Run the following command from Lync Management Shell:

New-CsHostingProvider -Identity "Hosted UM" -Enabled $True -enabledSharedAddressspace $True -HostsOCSUsers $false -ProxyFqdn "" -IsLocal $False -VerificationLevel UseSourceVerification

Get-CsHostingProvider -Identity "Hosted UM" cmdlet should return the following:

***I hit a bump at this point. Took me for a while to figure that the routing must be done toward the authoritative cloud domain. To see which domain is authoritative for my setup, I had to use Remote Power Shell:

$cred = Get-Credential
$s = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri -Credential $cred -Authentication Basic -AllowRedirection

$importresults = Import-PSSession $s

...and verify if our session is OK


 When i ran: Get-AcceptedDomain , the output showed that only "" is Authoritative and I will use it in my Lync configuration.

Next, create new Hosted Voice Mail Policy:

New-CsHostedVoicemailPolicy -Identity "MYUC Domain" -Destination -Description "Hosted voicemail policy for domain." -Organization ""

***Note that I am using  "" as Organization, because this is the only Authoritative domain returned.

Get-CsHostedVoicemailPolicy -Identity "MYUC Domain" should return

***Yesterday I already added "" as "Additional Supported Sip Domain" in my Lync topology, made the necessary changes in the public DNS, reissued the public certificate to include the new domain, you know the drill..Also, was added to Lync and provisioned for Enterprise Voice.

Now I will set HostedVoiceMailPolicy for this user to True. This way, when voicemail is to be deposited, my Lync on prem will route the call to the Cloud.

Set-CsUser -Identity lynclog\mu1 -HostedVoiceMail $True

...and grant the policy I created earlier:

Grant-CsHostedVoicemailPolicy -Identity lynclog\mu1 -PolicyName "MYUC Domain"

Let's examine our user' properties now:

Time to test our setup.

The call was connected and I left new Voice Mail.

***One last note - in this test,on my Edge Server, I used Public Certificate issued form Office 365 did not have any problem with it...