Ken's Unified Communications Blog

Viewing Extensions in the Lync Client

2013-05-08T15:57:00.000-04:00

In companies that use extensions off the main number, I’ve always recommended they format their numbers using the main office number for the “base” and followed by the extension (ie. tel:+14165551111;ext=222 for North America, or tel:+4420555111;ext=222 for elsewhere). In Active Directory, I’ve recommended they use the same type of format (ie. +1.416.555.1111 X222), and use the Company_Phone_Number_Normalization_Rules.txt to enforce the same formatting.

Background

For those unfamiliar with how Lync displays phone numbers, the Lync client will only display numbers it can parse from Active Directory. It doesn't show the actual TelURI defined in the Lync Control panel, which is a good thing, because there are often additional settings applied there that administrators don't want to have appear in the address list. The Company_Phone_Number_Normalization_Rules.txt file is helpful in re-formatting phone numbers in AD to the E.164 format we like to see in Lync. For a good overview of the Company_Phone_Number_Normalization_Rules.txt, see Jeff Schertz's blog entry on the topic.

The Problem

I've found that when using the Lync 2010 client, North American phone numbers would always display with the typical North American formatting properly along with the extension when dialed, (ie. +1 (416) 555-1111 X222). However, when applying similar rules to international numbers, the extension would never display. It would show +4420555111 instead of +4420555111 X222. The number would be dialed properly, but it would be confusing to the user, because the extension wouldn't appear.

Fast forward to Lync 2013 client, and the situation appeared even worse. Even North American phone numbers with extensions wouldn't appear properly when dialled. I assumed this was a client bug that was getting worse with each client revision.

The Solution...Sort of

Fellow Lync MVP Tom Pacyk of ConfusedAmused.com brought to my attention a little known (well, little known by me) feature added with the October 2012 update for the Lync 2010 client. In short, the client update finally fixed the bug for international extensions, but with a catch....you had to first add a new client policy entry to your Lync client policy. If only the global client policy is being used, the commands are:

$x = New-CsClientPolicyEntry -Name "ShowExtensionInFormattedDisplayString" -Value "True"
$y = Get-CsClientPolicy -Identity Global
$y.PolicyEntry.Add($x)
Set-CsClientPolicy -Instance $y

Since this policy setting was a part of the Lync 2010 client updates, it would be very easily missed by someone whose focus has changed to Lync 2013. I can only assume the same settings are required in a pure Lync 2013 environment, although there is very little information on the topic.

If you're running Lync Server 2010, it appears as though you need at least the October 2012 Lync 2010 server updates for this to work. I tried to apply this client policy entry to a client's deployment whose got Lync 2010 and 2013 in parallel, but the Lync 2010 environment is a bit out of date. The policy entry showed up properly when I ran the following:

$y = Get-CsClientPolicy -Identity Global
$y.PolicyEntry

...but neither my Lync 2010 or 2013 clients would show extensions properly. Applying the policy entry to a 2010/2013 server mix where the 2010 environment was up-to-date worked fine...at least for 2010 clients...mostly.

So, make sure your Lync 2010 infrastructure is up-to-date before attempting to apply this setting.

What's Still Not Working

I setup a few test users with extensions off a fictitious Toronto, Canada and London, UK main office number. The Toronto user's office number in AD was set to +1.416.555.1111 X111, and the London user's number in AD was set to +44.20.444.2222 X999. Both users were setup in Lync with their TelURI properly defined as tel:+14165551111;ext=111 and tel:+44204442222;ext=999 respectively.

A Company_Phone_Number_Normalization_Rules.txt file was placed in the ABFiles folder on the shared folder for the Lync server pool with the following rule to ensure Lync would be able to parse phone numbers with extensions in Active Directory properly:

\+(\d{6,14})\D+(\d+)
+$1;ext=$2

When testing with the Lync 2010 client, North American numbers showed up properly in both the list view and the dialing view, as shown below:

However, international numbers did show numbers a bit differently between the views, using the ;ext= from the TelURI instead of the X:

Interestingly enough, the Lync 2013 client doesn't seem to fully honour the extension setting for either North American or international numbers. The number shows up properly when hovering over the phone icon, but only shows the main number when dialing:

North America

United Kingdom

Needless to say, this can be very confusing to the average user.

This appears to be a bug introduced with the Lync 2013 client. I've brought this up with the Lync product managers, and we should see a future patch that will address the issue for Lync 2013 clients.

Location-Based Routing in the Lync Optimizer

2013-04-30T16:24:00.001-04:00

The Lync Server Update for February 2013 included a much asked for feature: location-based routing. Location-based routing basically ensures the routes that phone calls can take are dependent on where the user is currently located.

Before the February 2013 update, the path calls would take were solely determined by the assigned Lync voice policy. Normally, call routes are somewhat local to the user (at least within the same country). If a user were to go to another office on the other side of the planet, their calls would still route via the same paths as if the user were at their home office.

Normally, this isn't a very big issue, but some countries have very strict rules about how calls may enter and exit the country. India is an example where they don't want to see any calls leave the country via the Internet. All calls must leave the country via the PSTN. Toll bypass or least-cost routing is not allowed.

Fellow Lync'er Richard Brynteson wrote up a great post on how to setup location-based routing in Lync 2013 CU1. He even put me on the spot by saying that I was working on adding location-based routing to the Optimizer. So, that pretty much meant that I had to do it.

So, in the spirit of the Lync Optimizer doing all the work required to setup Enterprise Voice in Lync, I've added an option to configure location-based routing when the Optimizer is run for a given Lync deployment.

There is a single prerequisite in order to make it all work. The Lync environment must have at least one Lync network region, site and subnet configured (preferably/obviously for the location where location-based routing is to be enabled). If call admission control has already been deployed, then this should already be done. If not, the Lync network site/subnet can be setup manually by following the guide on Technet. If AD Sites & Services has been fully populated with site/subnet information, I've created a script that will transfer this into Lync.

When the Optimizer runs, it will check to see if the deployment is running Lync 2013 and has at least one network site defined. It will then prompt the user to apply location-based routing to that site (or others if more than one site is found).

If you are unsure whether or not to apply location-based routing, then DON'T DO IT. It will ensure that all calls made from within the network site use only the routes defined for that site. It may have unintended consequences for users visiting the site. It can be undone, but if you are not comfortable with the inner workings of Lync, its best not to open up that can of worms.

As a final note, the Lync Optimizer now includes dial rules for India, which is one of the main reasons why location-based routing was added to Lync in the first place.

Best of luck out there!

Automatically Creating Lync Sites and Subnets using AD Sites

2013-04-01T13:25:00.000-04:00

To use call admission control or location-based routing in Lync, one of the first steps is to define all the sites and subnets used in the company and to assign the sites to network regions. In larger companies, this can be a tedious process if this information is not stored in a central, easily accessible location.

One place where network site/subnet information can sometimes be centrally found is within Active Directory itself. Active Directory and other applications such as Exchange uses site/subnet information to determine where to direct clients for authentication services (among other things). Ideally, every site and subnet should be defined using the Active Directory Sites and Services snap-in. If the Active Directory administrator has diligently defined all the sites/subnets, this information can be easily parsed and used in Lync.

I've created a short script that will automate the creation of network sites and subnets using the information stored in AD Sites and Services. Again, this script is only useful if all the sites/subnets have been defined in AD.

Copy the below script into a .PS1 file on a Lync server and run it. As always, be careful and test this in a lab first. I can't be responsible for any damage this script will cause.

# Load Active Directory Powershell module if its not already loaded
if(-not(Get-Module -name ActiveDirectory)){Import-Module ActiveDirectory}

# If a Lync network region doesn't exist, create one and name it the same as the first Lync site
# If one or more does exist, select the first one associated with the first Lync site

if(-not(Get-CSNetworkRegion))
{
 $SiteName = (Get-CSSite 1).DisplayName
 New-CSNetworkRegion $SiteName -CentralSite 1
}
else
{
 $SiteID = (Get-CSSite 1).Identity
 $SiteName = (Get-CSNetworkRegion | Where {$_.CentralSite -eq $SiteID} | Select-Object -First 1).NetworkRegionID
}

# Get the ConfigurationNamingContext from AD and go to the Sites container
$ConfigDN = (Get-ADRootDSE).ConfigurationNamingContext
$SiteContainerDN = ("CN=Sites," + $ConfigDN)

# Select all the site objects
$Sites = Get-ADObject -SearchScope OneLevel -SearchBase $SiteContainerDN -filter {ObjectClass -eq 'Site'}

foreach ($Site in $Sites)
{ 
 # Create Lync network sites based on AD site
 $SiteObj = Get-ADObject $Site.distinguishedName -properties "siteObjectBL", "description" 
 New-CSNetworkSite -NetworkSiteID $SiteObj.Name -Description $SiteObj.Description -NetworkRegionID $SiteName

# Add each defined AD site subnet to the Lync network site object
 foreach ($SubnetDN in $SiteObj.siteObjectBL) 
 {
  $Subnet = Get-ADObject -Identity $SubnetDN -properties "description"
  $SubnetName = $Subnet.Name  #Subnet name is in format 192.168.100.0/24
  $SubnetSplit = $SubnetName.Split("/")  #Need to split subnet name into IP and mask for command
  $SubnetID = $SubnetSplit[0]
  $SubnetMask = $SubnetSplit[1]
  New-CSNetworkSubnet -SubnetID $SubnetID -MaskBits $SubnetMask -Description $Subnet.Description -NetworkSiteID $SiteObj.Name
 }
}

#Create subnet object with 32-bit mask for all public edge A/V IP addresses
$EdgeServerPools = Get-CSService -EdgeServer | Where {$_.SiteID -ne "Site:BackCompatSite"}
foreach ($EdgeServerPool in $EdgeServerPools)
{
  $EdgeServers = (Get-CSPool $EdgeServerPool.PoolFQDN).Computers
 
  foreach ($EdgeServer in $EdgeServers)
  {
    $NetworkInterfaces = Get-CSNetworkInterface -ComputerFQDN $EdgeServer | Where {$_.Interface -eq "External" -and $_.IPAddress -ne "0.0.0.0"} 
    if (($NetworkInterfaces).Count -eq 3)
    {
      $NetworkInterface = $NetworkInterfaces | Where {$_.InterfaceNumber -eq 3}
    }
    else
    {
      $NetworkInterface = $NetworkInterfaces
    }

if ($NetworkInterface.ConfiguredIPAddress -ne $NULL)
    {
      $IPAddress = $NetworkInterface.ConfiguredIPAddress
    }
    else
    {
      $IPAddress = $NetworkInterface.IPAddress
    }

$Description = "A/V external edge IP for " + $EdgeServer
    New-CSNetworkSubnet -SubnetID $IPAddress.IPAddressToString -MaskBits 32 -Description $Description
  }
}

The script will first check to see if a Lync network region already exists. If so, it will select the first one it sees as the base for all the subnets. If one doesn't exist, it will create one using the first Lync site as the base. If need be, you can define additional network sites later.

The script will then create all the sites/subnets based on information from AD. All the sites will be assigned to the one network region selected according to the rules in the previous paragraph. Since there is no way for the script to know which site belongs to which region, this will have to be done manually if multiple Lync network regions exist.

IMPORTANT: The script will also create the required subnets for all the Lync edge A/V public IP addresses with a 32-bit subnet mask as per the requirements for call admission control. You will have to manually assign these subnets to the sites where you deployed the edge servers.

While this script doesn't try to do everything associated with setting up call admission control, it does go a long way towards automating a good chunk of the process. A future revision of the Lync Optimizer will hopefully close the loop and help completely automate the work required to setup location-based routing.

As a final side note, one thing I don't understand is why Lync can't leverage AD Sites & Services for this information directly. Exchange versions since 2007 have used AD Sites & Services for mail routing, so its not like it hasn't been done before. Maybe a future version of Lync will add this functionality. Until then, this script should help those who have well-defined site/subnet information in Active Directory.

Assigning a Throttling Policy to all iOS 6.1 Devices in Exchange 2010

2013-02-13T14:18:00.000-05:00

UPDATE 14-Feb-2013: After being linked to from Ars Technica, I felt the need to improve the script. My original version of the script tried to use the UserDisplayName field that is returned from Get-ActiveSyncDevice. However, that field had a maximum number of characters, and a number of longer user DNs got cut off, which would make the script fail for that user. I figured out a way around it, and the script has been updated.

If you're an Exchange administrator, you have probably heard about the issues caused by Apple's iOS 6.1 on Exchange servers. It seems that screwy calendar code in iOS 6.1 ends up generating tons of transaction logs in Exchange, and can bring CAS servers to its knees.

As an aside, its rather timely that this has come up just after the new Blackberry 10 came out. Coincidence?????? Heh.

The temporary workarounds that MS recommends were to either apply a throttling policy to affected users, or block iOS 6.1 devices completely. Since an all-out block is generally a Bad Thing, throttling policy is the way to go. However, determining who is using iOS 6.1 and applying a throttling policy to them was not provided.

A company I do work for experienced the exact issue. Exchange transaction logs were being generated at a prodigious rate. So, rather than blocking them, we went the throttling route. First, I created a throttling policy called iOS61 and set the ActiveSync throttling to the lowest recommended values:

New-ThrottlingPolicy -Name iOS61 -EASPercentTimeInCAS 10 -EASPercentTimeInAD 10 -EASPercentTimeInMailboxRPC 10

Then, I created a short Powershell script to apply the policy to any user with a device using iOS 6.1:

$DeviceList = Get-ActiveSyncDevice -ResultSize Unlimited | Where {$_.DeviceOS -match "iOS 6.1"}
foreach ($Device in $DeviceList)
{
$DeviceDN = $Device.DistinguishedName
$MBName=$DeviceDN.SubString($DeviceDN.IndexOf("CN=ExchangeActiveSyncDevices,")+29)
Set-Mailbox $MBName -ThrottlingPolicy iOS61
}

The script will likely throw up some warnings about completing the command but not making any changes. This happens because users may have more than one device, and the script tries to update the mailbox for every device it finds. Nothing to be alarmed about.

Quick and dirty, but gets the job done.

Once Apple comes up with a solution, you can remove the throttling policy like this (assumes the users didn't have a throttling policy before this whole debacle):

Get-Mailbox -ResultSize Unlimited | Where {$_.ThrottlingPolicy -eq 'iOS61'} | Set-Mailbox -ThrottlingPolicy $NULL

Limiting Call Forwarding and Simultaneous Ringing in Lync 2013

2013-01-24T09:55:00.002-05:00

In Lync 2010, users were able to forward calls or setup simultaneous ringing to any number that they were able to call themselves. This could lead to people forwarding all their calls to a long distance or even international number (assuming their voice policy allowed international calling). This can lead to increased telephony costs to the company, and there wasn't very much the administrator could do to control this, short of disabling the feature entirely.
A new feature in Lync Server 2013 Enterprise Voice allows administrators to limit where users are able to setup call forwarding/simultaneous ringing. You'll see the new option at the bottom of the voice policy screen in Lync 2013 Control Panel (as highlighted in red).

The selectable options are:

Route using the call PSTN usages (default) - essentially means to allow users to forward calls to any destination phone number they are allowed to call (the same behaviour as in Lync 2010). So if a user is allowed to call international numbers, they will be allowed to forward/simultaneous ring international numbers. The option wording here could really use some improvement, because to me it doesn't make much sense as it currently stands.
Route to internal Lync users only - allows call forwarding/simultaneous ringing only to other Lync users within the company.
Route calls using custom PSTN usages - allows administrators to limit call forwarding/simultaneous ringing to only the PSTN usages defined by the administrator.

When the last option is selected, the Control Panel will display a box where administrators can select the appropriate PSTN usages. For instance, to limit call forwarding/simultaneous ringing to only local numbers, select a local PSTN usage, as shown below:

Administrators can add multiple usages to allow calls forwarding/simultaneous ringing to any combination of PSTN usages. Since voice policies can be applied either globally, site-wide or down to the user level, this should allow administrators to grant different policies to any number of users.

This assumes the Enterprise Voice deployment has been designed granular enough to break out local, national and international calling. If there is only a single catch-all usage for all calls, then this won't work and the Enterprise Voice configuration will have to be re-designed.

Luckily, the Lync Dialing Rule Optimizer (shameless plug) creates usages for local, mobile, national, premium, and international usages, which should be enough for any administrative need.

Unfortunately from the user's perspective, they won't get a notification in the Lync client if they try to forward/simultaneous ring a phone number that is outside the dialing areas allowed by their voice policy.

For example, assume a user's voice policy only allows forwarding/simultaneous ringing to local numbers. If the user sets up simultaneous ringing to a number outside the local dialing area, they won't get any feedback that it isn't allowed by the policy. When someone phones the user, their Lync devices will ring as usual, but the simultaneous ring number simply won't ring. This could generate an unnecessary helpdesk call, which could also confuse the helpdesk, if they haven't been made aware of the policy.

Similarily, the user doesn't get any feedback in the Lync client when setting up call forwarding to a number outside the allowed dialing areas. In this case, calls will simply go straight to Exchange voicemail without attempting to forward. However, the user will get an email stating the forwarding isn't allowed. Slightly more helpful, but still likely to generate a helpdesk call.

Curiously, the interface still refers to Office Communicator, but since I'm still running Exchange 2010, maybe this is to be expected.

The situation would be greatly improved if the Lync client would be more informative in this respect. In my perfect world, there would be no war, global warming would turn Canada into a tropical paradise, gin and tonic would flow freely from taps all around my house, and the Lync client would provide feedback like this when users try to forward to a number that isn't allowed:

A man can dream, can't he?

Either way, the new control administrators have to limit call-forwarding/simulring is a much needed new feature, and I'm glad it made it into Lync 2013.

Least-Cost/Failover Routing in the Lync Dialing Rule Optimizer

2013-01-09T10:17:00.001-05:00

The Lync Dialing Rule Optimizer tries to take care of all the Enterprise Voice configuration necessary for all deployments. On most fronts, it does a pretty good job (IMHO). One area that has been lacking is the ability to automatically arrange PSTN usages to provide least-cost/failover routing for multi-site Lync deployments. Once an administrator has run the Optimizer for all their sites, they have to manually configure the voice policies to provide least-cost/failover routing.

If you're not familiar with how least-cost/failover routing works in Lync, please refer to my post on the subject in my Lync Enterprise Voice Best Practices series.

With version 9.0 of the Lync Dialing Rule Optimizer, Lync administrators now have the option to create least-cost/failover routing between all sites that have been deployed using the Optimizer (or at least follows the same naming conventions used by the Optimizer).

When the Optimizer-generated script detects multiple Lync sites, it will prompt the user if they want to apply least-cost/failover routing to the voice policy being generated. If the user allows it, the Optimizer will add PSTN usages for all the other sites to the new voice policies. This assumes the existing PSTN usages are named with the country abbreviation first, and ends with either Local, National, International etc in any of the languages currently supported by the Optimizer as in the following examples: UK-Leeds-113-Local, IT-Rome-06-Nazionali.

The output can be best summarized by way of example. Assume a company has Lync Enterprise Voice deployed in the following locations:

Toronto, Canada

Vancouver, Canada

London, UK

Rome, Italy

Belém, Brazil

After running the Optimizer script against all sites, the PSTN usages for the Toronto International user voice policy would look like this (you might want to sit down for this):

NA-ON-Toronto-416567-Local

NA-BC-Vancouver-604678-Local

NA-ON-Toronto-416567-National

NA-BC-Vancouver-604678-National

NA-ON-Toronto-416567-Premium

NA-BC-Vancouver-604678-Premium

NA-ON-Toronto-416567-Service

UK-London-20-Local

IT-Roma-06-Locali

BR-Belém-91-Local

UK-London-20-Mobile

IT-Roma-06-Cellulari

BR-Belém-91-Celular

UK-London-20-National

IT-Roma-06-Nazionali

BR-Belém-91-Nacional

NA-ON-Toronto-416567-International

NA-BC-Vancouver-604678-International

UK-London-20-International

IT-Roma-06-Internazionali

BR-Belém-91-Internacional

The Optimizer will group PSTN usages from the same country near the top, using the assumption that most of the calls will be made to in-country locations and that the fewer PSTN usages the system needs to evaluate for each call, the better.

The ordering is such that least-cost routing and failover routing will occur. PSTN usages from other countries will be placed lower in the list while still providing least-cost and failover routing for all calls. If there are multiple Lync sites out-of-country, the ordering of PSTN usages within the National and International usages will be somewhat random. Administrators should review the PSTN ordering to make sure it suits their needs.

It is assumed that premium numbers can only be dialed from in-country locations, so out-of-country premium PSTN usages are not assigned. Also, only the local service PSTN usage is assigned for similar reasons.

All calls will use the least-cost route where possible. If a route assigned to a specific usage is unavailable, calls will use a route in another site, again keeping the call in-country if possible.

With the inclusion of least-cost/failover routing in the Lync Optimizer, administrators now have a tool that can completely build the Enterprise Voice environment for even the largest enterprise-level Lync deployment.

As always, feedback is greatly appreciated. Let me know if you come across any issues with functionality or scalability as I haven't tested if there is a limit to the number of PSTN usages that can be assigned to a voice policy.

Blocking International Calls to Specific Countries in Lync

2013-01-04T12:49:00.001-05:00

A question that often comes up in my travels is that Lync administrators want an easy way to allow users to dial internationally but exclude specific countries for some reason.

This is very easy to accomplish once you understand the ins and outs of regular expressions, and assuming you follow all my best practices regarding number normalization, and Enterprise Voice setup. To summarize, every number a user enters in Lync should be normalized to E.164 standards, which starts with a + followed by the country code, then the area/city code and finally the local subscriber number. A Canadian example (country code 1) would be +14165551111. A UK example (country code 44) would be +442033334444. If you use the Lync Dialing Rule Optimizer to create your Enterprise Voice configuration, you'll be all set.

When all numbers are normalized to E.164, and you already have separate usages and routes for local, national and international calls, it makes it very easy to design regular expressions that meet any specific criteria required by your business.

Say your company is based in North America, and is required to block international calls to Iran (98) and North Korea (850). The Lync Dialing Rule Optimizer routing rule for international calls is this:

^\+[2-9]\d{6,14}$

This rule allows any number that doesn't start with a 0 or 1 to be routed out. Only North American countries (US/Canada and some Caribbean countries) use the country code 1. All other country codes start with the digits 2-9. So essentially, this rule allows calls to any international destination.

To block calls to Iran and North Korea, modify the rule to look like this (new stuff highlighted in yellow):

^\+(?!98|850)[2-9]\d{6,14}$

This will allow any number starting with 2-9, but excludes numbers that start with 98 or 850 as required.

If you're not in North America and used the Lync Dialing Rule Optimizer to create your Enterprise Voice setup, your international rule looks a little different, because we want to make sure that North American numbers are formatted correctly (as highlighted in blue), while making sure that it does not try to route national numbers as international (using UK +44 as an example, shown in green):

^\+((1[2-9]\d\d[2-9]\d{6})|(?(?!(44))([2-9]\d{6,14})))$

To block calls to Iran and North Korea using this example, modify the rule as follows (new stuff highlighted in yellow again):

^\+((1[2-9]\d\d[2-9]\d{6})|(?(?!(44|98|850))([2-9]\d{6,14})))$

Now, anybody who tries to dial a number in Iran or North Korea will be met with a notice that the call couldn't be completed.

This method is pretty granular as you could create separate routes to block countries selectively or for a specific group of users. If you want to just block those numbers globally, you can use Unassigned Numbers to provide an announcement to users that those numbers are not allowed to be dialled. The only downside to that method is that you need to know in advance how long phone numbers are in the country you want to block.

Happy Enterprise Voicing everyone!

Localized UK Dialing Rules for the Optimizer

2012-12-05T09:47:00.001-05:00

Using data from a number of web sources and some helpful users, I've been able to create customized Lync dialing rules for over 30 countries worldwide and made them available to all via the Lync Dialing Rule Optimizer. These customized dialing rules account for country-specific dialing patterns for local, national, international, toll-free, mobile, premium and service numbers.

However, true localized dialing rules have been out of reach for countries other than those in North America until now. For all non-North American countries, I have been forced to create generic dialing patterns for local numbers simply because I don't have access to any source of local dialing rule data. This isn't generally a problem because most local dialing rules are different enough from other patterns that conflicts are rare. For example, a local dialing rule for a country might specify that the number start with digits 2-9 and are between 5 and 6 digits in length. As long as there aren't any other dialing patterns in that country that use that same pattern (ie national, international, mobile, service, toll-free or premium), there won't be a problem. I try to make sure that is the case for all dialing rules created for the Optimizer, but it is sometimes difficult.

The United Kingdom has more than 60 different local dialing rules. Local numbers can be 4 to 8 digits in length and area codes have from 2 to 5 digits. Some 41 area codes have mixed length numbers where some numbers have a total 10 digits and others have only 9. In some area codes the local number cannot begin with certain digits, or certain digits will not come into use for many decades. The generic UK local dialing rule used by the Optimizer tries to account for all these in a single regular expression, but obviously some generalizations had to be made.

Enter Ian Galpin of the UK. Ian has made it a personal mission to ensure that the UK has a complete set of dialing rules written as regular expressions. Over the past year, he's helped me ensure the regex for UK dialing rules are correct. He's also created a localized set of dialing rules for every area code in the UK as an XML file along with a list of all the area codes used in the UK. He's done this to help various telephony vendors create the appropriate rulesets for PBX deployments. I've been able to incorporate that into the Lync Dialing Rule Optimizer, so that UK users now have true customized local dialing rules for Lync that will differ depending on which area code you select in the Optimizer.

I've modified the Optimizer code to be able to use local dialing rules for other countries if available. If anybody can point me to a similar source as provided by Ian for other countries, it would be greatly appreciated.

Lync 2013 is Code-Complete

2012-10-12T09:40:00.000-04:00

For those who haven't heard through Twitter or other channels, Lync 2013 is code-complete, with a general availability target of first quarter 2013 as part of the Office 2013 suite. It isn't clear from the announcement, but this is for the Lync 2013 CLIENT, not server. Since Exchange 2013 and Sharepoint 2013 have been announced, I'm sure we'll be hearing about Lync Server 2013 achieving the same milestone fairly soon.

UPDATE: Well, confusion reigned among some of the MVP mailing lists. While some were saying the Lync 2013 announcement was for the client, others were saying it was for the server. Seeing how all the other servers in the "suite" have been announced, I think its safe to say that Lync Server 2013 is part of it.

Lync Branch Site Options and Recommendations

2012-10-04T10:15:00.002-04:00

A large-scale Lync deployment typically consists of at least one central site that contains either a Standard or Enterprise Edition pool and one or more branch sites that don't warrant having a full-blown Lync deployment, but still need local voice connectivity in case of a WAN outage.

You have 4 options when considering what to deploy at a branch site:

Survivable Branch Appliance (SBA) - an all-in-one solution that consists of a PSTN gateway with the appropriate interface required for connectivity to the PSTN and a "Lync-Lite" installation that has only the Lync registrar and mediation server roles.
Survivable Branch Server (SBS) - A "Lync-lite" installation containing the Lync registrar and mediation server roles.
A PSTN gateway and a standalone Lync mediation server
A full-blown Lync deployment (typically Standard Edition)

Microsoft doesn't give much guidance as to which option is right other than saying that an SBA is appropriate for branches up to 1000 users, an SBS or 2 SBAs is good for 2000 users, and anything beyond that should be a Standard Edition Server.

What a lot of people don't realize is that there is more to consider than simple user counts. Let's start by looking at where an SBA is appropriate, and where it isn't.

Survivable Branch Appliance

As noted earlier, a Survivable Branch Appliance is an appliance that contains a PSTN gateway along with a small Windows Server 2008 R2 deployment with the Lync registrar and mediation server roles. SBAs are purchased from vendors such as NET, Audiocodes, Dialogic, or Ferrari, among others. An SBA is paired with a central site that has a full-blown Lync deployment and is designed to be dropped into an office that doesn't have much local IT support.

Lync clients are homed on an SBA, and will register/login directly against it. PSTN calls are routed through the mediation server role and onto the PSTN gateway component of the SBA.

While clients register against the SBA, their contact list is still homed on the central Lync deployment. Also, all conferencing features and response group functionality is provided by the central Lync deployment. So, if the WAN link between the central site goes down, clients will lose their personal contact list, the ability to do multiparty web/video conferencing and any response groups whose phone numbers terminate on the SBA won't work. This is beautifully illustrated by VOIPNorm on his blog post on the topic. What DOES work is one-to-one IMs/telephone calls, PSTN calling, searching for contacts and any other features that don't require the full Lync deployment's involvement. Again, see the blog post by VOIPNorm for full details.

When to Use a SBA and When Not To

Use an SBA when you your site meets the following criteria:

Up to 1000 users (2000 if you use 2 SBAs)
Have a T1/E1 or analog connection to the PSTN
Won't miss conferencing or response group functionality during a WAN outage
Have limited IT staff on site

Don't use an SBA if your site meets any of these criteria:

Does a lot of conferencing and has a slow/expensive WAN pipe to the central site. Conferencing services come from the central pool, so this can be a strain on WAN resources.
Requires high availability for conferencing features and/or Response Group services
Use a SIP trunk for PSTN connectivity, unless the SBA can be configured as a SIP gateway and doesn't have PSTN interfaces you don't need (they aren't cheap)

Survivable Branch Server

A Survivable Branch Server (SBS) has the same capabilities as an SBA, but without the PSTN gateway component. It isn't something that you purchase from a vendor. It's simply a "Lync-lite" server you define in the topology and install yourself on a regular Windows Server 2008 R2 (or Windows Server 2012 for Lync 2013) server. Like the SBA, it only has the Lync registrar and mediation server roles.

Incidentally, you won't see an option to define an SBS in the Lync topoology. Your only option is an SBA. Since the functionality of the Lync portion of the SBA is identical for an SBS, it doesn't need to be defined separately. Lync doesn't care if the PSTN gateway is part of the same chassis as in an SBA or a separate component as with an SBS.

When to Use a SBS and When Not To

Use an SBS when your site meets the following criteria:

Have up to 2000 users
Have the local infrastructure to support a full-blown Windows Server deployment (either VM or physical server)
Have a SIP trunk connection to a Lync-certified SIP provider, or you already have a standalone PSTN gateway
Won't miss conferencing or response group functionality during a WAN outage
Have at least some local IT staff

Don't use an SBS if your site meets any of these criteria:

Does a lot of conferencing and has a slow/expensive WAN pipe to your central site. Conferencing services come from the central pool, so this can be a strain on WAN resources.
Requires high availability for conferencing features and/or Response Group services
Have either a T1/E1 or analog service for PSTN access. You would still need to purchase a PSTN gateway, and would probably be better served by using an SBA (unless either of the above 2 points apply)

PSTN Gateway and Mediation Server

This option is an interesting one in that I've not seen it "in the wild". A site with just a mediation server role is entirely dependent on the WAN link to the central site. If the WAN goes down, then so do your clients. You need the infrastructure to support a Windows installation, something many small branch sites don't have. If you have a SIP trunk connection, you may not need a PSTN gateway at all. Conversely, you may not require a mediation server if you use media bypass to send client audio traffic directly from the client to the PSTN gateway.

When to Use this Option and When Not To

Use a PSTN Gateway/mediation server when your site meets the following criteria:

You have a 100% reliable WAN connection to your central site or your users will be OK with no functionality in the event of an outage

Don't use a PSTN Gateway/mediation server if your site meets the following criteria:

Your WAN isn't reliable

Standard Edition Deployment

Sometimes, you will need a full-blown Lync deployment at your branch site. With even just a Standard Edition server, local clients will get all the functionality Lync has to offer, so WAN outages won't be a big issue.

When to Use this Option

Use a Standard Edition server when your site meets one or more of the following criteria:

You have more than 2000 users in a site
Your WAN link reliability is low
Your users do a lot of conferencing with each other
You need local Response Group functionality

Hopefully, this post will give you some better guidance as to what branch role to deploy at your sites. If you have any questions or comments, please let me know. By the way, the above is relevant for both Lync 2010 and Lync 2013.

What's New in Lync 2013

2012-07-16T16:08:00.000-04:00

With the recent announcement about Lync 2013 (previously known in beta circles as Lync 15), I'm sure everyone is interested in what's new. Lync 2013 doesn't re-invent the wheel when compared to Lync 2010. Lync 2013 builds on the features introduced in Lync 2010 in a way that makes Lync 2013 a compelling upgrade. Here is a quick rundown of the new features (note this is information from the beta product so things may change before its final release):

Roles

There has been significant role consolidation in Lync 2013. There is no longer a separate server role for monitoring and archiving. Each front-end server communicates directly with the monitoring and/or archiving database, eliminating the need for a separate monitoring/archiving server.

You can no longer install the A/V conferencing server role separately. It is now always co-located with the front-end role.

Directors are now an optional role, which is kind of funny because I've always treated them as optional myself.

DR/High Availability Options

Lync 2010 introduced the concept of a backup registrar. When a user's home pool becomes unavailable, the client can automatically register with a pre-defined backup pool. This maintains basic voice availability, but the client loses conferencing capabilities, and the user's contact list is unavailable. In Lync 2013, users will maintain nearly all functionality in the event of a failed pool. This is made possible because all user data is now replicated between all Lync servers in the enterprise. Every server maintains multiple copies of the user database, so there is almost no reduction in service availability. I say "almost" because Response Groups are still not highly available (something that was sorely missed in Lync 2010). So, should you suffer a failure on your home pool that hosts response groups, those response groups will not be available.

Each front-end server stores a complete copy of all the databases stored in the SQL back-end, so if the back-end SQL database server is unavailable, the front-end will still function.

Also, Lync 2013 supports SQL mirroring on the back-end databases. This can reduce hardware costs typically associated with the older clustering options in SQL (separate shared storage).

Enterprise Voice

In Lync 2010, if you had multiple mediation servers connecting to the same PSTN gateway or SIP trunk, you had to fake the Topology Builder out by creating multiple DNS A records pointing to the same IP. Lync 2013 now supports M-N trunk routing. This allows you to have multiple trunks to different gateways, and a gateway to have multiple trunks to different Mediation Servers.

Lync 2013 includes support for inter-trunk routing. This feature allows Lync to act as an intermediary between two or more different phone systems. For example, Lync can accept calls from one PBX, and pass the call through to another PBX. This can be very useful in larger environments and allows Lync to be the backbone of a corporate telephone network.

In Lync 2010, you could use trunk translation rules to modify the CALLED phone number before passing it to the next hop. However, you couldn't make any changes to the CALLING number (ie the person making the telephone call). Lync 2013 now allows you to make changes to both the called and calling number. This is very useful when the PSTN provider does not accept E.164 formatted phone numbers. For example, in North America, many PSTN providers do not accept the country code 1 as part of the number and only accepts 10-digit numbers. In the past, an external gateway would have to do the necessary manipulation, but with Lync 2013, all the number manipulation can be done in Lync.

There are also several other new Enterprise Voice related enhancements. Delegates can setup simultaneous ringing to their mobile devices for incoming calls to their manager. When a user has setup simultaneous ringing to a mobile phone, and the device is turned off or out of range, Lync 2013 can determine that an incoming call was immediately routed to voicemail, and disconnect that endpoint so the call can continue to ring other endpoints. Caller ID presentation allows administrators to modify the Caller ID format in a much more scalable way than in Lync 2010, which only allowed Caller ID changes based on the route.

Response Groups

Not much has changed here, but you can configure Response Group Managers and Administrators, allowing you to delegate Response Group tasks to other users. If this seems familiar, its because that feature was in OCS 2007 R2, but was removed from Lync 2010 for some reason.

Integration with Lync Online

You can now create hybrid deployments with a mix of on-premises and Lync Online servers (similar to Exchange 2010). This means that you can have some users running "in the cloud" and some users on traditional on-premises servers. Microsoft calls this "hybrid voice". You can also have all your users running in Lync Online and make calls via an on-premises PSTN gateway. This means you can allow Lync Online users to dial legacy PBX extensions, or make calls via a traditional PSTN connection (T1/E1 or similar) in situations where SIP trunking isn't desirable or an option. Media bypass will work in this situation, so a user's media stream won't be hairpinned through the Lync Online service when making phone calls from an office running a local PSTN gateway.

Mobility

Mobile clients will finally get the featureset people have been asking for. Mobile clients will be able to make audio and video calls from their mobile device using either a mobile data connection or wi-fi. I have no idea if this will be available at launch or sometime after. There isn't a Lync 2013 mobile client available yet that I've seen, but there are definite signs around mobile A/V in some updated Powershell commands like Get-CSMobilityPolicy. I saw an early demo of Lync 2013 on a tablet running Windows 8, and it pretty much guaranteed I'll be buying a Windows 8 tablet when it comes out. Lync on a tablet was just THAT cool.

Persistent Chat

Persistent chat (or group chat), is now a full-fledged Lync service, unlike older versions which was really just tacked on (and quite poorly, in my opinion). You now define servers in the Topology Builder as with other roles, and the persistent chat features are included in the base Lync 2013 client (no separate client required).

Other New Features

Other features that don't fall into the above categories include:

Full A/V capabilities on the Lync Web App client
Full IPv6 support
VDI plugin - allows full A/V support in virtual desktop environments
H.264 SVC codec support
Skype federation support

There are a lot of other small enhancements that go a long way towards improving the overall product or enhancing usability. If I were to go into detail here on all of them, it would become a very long post. I will do future deep-dives into some of the specific improvements at a later time.

Get the preview here.
Technet documentation.

Useful Lync Powershell Scripts

2012-07-11T16:01:00.003-04:00

I find myself having to create and use the same Lync Powershell scripts over and over again, so I thought I'd compile a list of some of the ones I've created for others. It will get updated as time goes on.

Enjoy, and suggest others in the Comments.

Finding all the people who have a telephone number set in Lync
Get-CsUser -Filter {LineURI -ne $NULL} | FT Name, LineURI

Change SIP domain for all users

$UserList = Get-CsUser

foreach ($User in $UserList)

{

$oldAddress = $User.SipAddress

$newAddress = $oldAddress -replace "@olddomain.com", "@newdomain.com"

Set-CsUser -Identity $User.Identity -SipAddress $newAddress

}

Setting the AD office phone number to the TelURI for all users
#Only need to add the AD Powershell instance once
Add-WindowsFeature RSAT-AD-Powershell
Import-Module ActiveDirectory

$users = Get-CSUser

Foreach ($user in $users)
{
   $Tel = $user.LineURI
   $Tel = $Tel.Replace("tel:", "")
   If ($Tel -ne "")
   {
      Set-ADUser -Identity $user.SAMAccountName -OfficePhone $Tel
   }
}

Move All OCS Users Homed on a Specific Pool to Lync
Also sets conferencing policy and external access policy to automatic, rather than the legacy migrated OCS policies. Replace items in bold with your environmental specifics.

get-csuser -OnOfficeCommunicationServer | Where {$_.HomeServer -eq "CN=LC Services,CN=Microsoft,CN=OCSPOOLNAME,CN=Pools,CN=RTC Service,CN=Services,CN=Configuration,DC=contoso,DC=com"} | Move-CsLegacyUser -Target LYNCPOOLFQDN -ExcludeConferencingPolicy -ExcludeExternalAccessPolicy -Confirm:$FALSE

Count How Many Users are on OCS and Lync
(Get-CsUser -OnOfficeCommunicationServer).Count
(Get-CsUser -OnLyncServer).Count

Get a List of All Lync-Enabled Users Along with Selected AD Properties
#Asked by a commenter. Harder than it initially looked....

$ErrorActionPreference = 'SilentlyContinue'
Import-Module ActiveDirectory
$Output = @()

Foreach ($LyncUser in Get-CSUser -ResultSize Unlimited)
{
$ADUser = Get-ADUser -Identity $LyncUser.SAMAccountName -Properties Department, Title
$Output += New-Object PSObject -Property @{DisplayName=$LyncUser.DisplayName; Department=$ADUser.Department; Title=$ADUser.Title; SAMAccountName=$ADUser.sAMAccountName; SIPAddress=$LyncUser.SIPAddress; EVEnabled=$LyncUser.EnterpriseVoiceEnabled}
}

$Output | Export-CSV -Path .\Output.csv
$Output | FT DisplayName, Title, Department, SAMAccountName, SIPAddress, EVEnabled

Create Lync Network Sites and Subnets using Info from AD Sites & Services
http://ucken.blogspot.ca/2013/04/automatically-creating-lync-sites-and.html

Lync Dialing Rule Optimizer Gets Optimized

2012-05-31T18:40:00.000-04:00

It was recently brought to my attention that some of the normalization rules created by the Lync Dialing Rule Optimizer in certain cases were not being used by the Lync client. Specifically, the issue only arises if you select the option for the Optimizer to create 7-digit local dialing rules (only available for North America dialing rules). The 7-digit rules are simply never used. If you enter a 7-digit number that should be normalized to a 11-digit E.164 North American phone number, it doesn't happen. Interestingly, if you use the Lync Voice Routing Test Case applet in the Lync Control Panel, you'll see that it normalizes just fine.

I did some testing of my own, and found out that the first part of the 7-digit rules were causing the Lync client to ignore the entire rule. The first part of each 7-digit normalization rule is this cryptic piece of regex:

(?=^\d{7}$)

This bit of regex says that whatever number is entered has to be a total of 7 digits long. The rest of the regular expression dictates the allowable first 2 or 3 digits for that particular area code. At the time, this was the only way I could think of to ensure the total number of digits entered was exactly 7.

I put the question to Microsoft, who acknowledged that the server and the client can use different criteria for evaluating the validity of regular expressions. It may be fixed in a future patch, but rather than waiting, I went about figuring out how to ensure 7-digit numbers without that bit of cryptic regex at the beginning.

After a good amount of research, work, and testing, I was able to figure out a way to ensure 7 digits in a much simpler way. At the same time, I got a bit of regex schooling by Dan Berry of Acrodex. He told me I had way too many brackets in my regular expressions, so with his prompting, I was able to reduce the number of brackets by quite a bit. He also gave me some other ideas for reducing the length and complexity of my regular expressions.

The end result is a much shorter and more robust set of regular expressions for all the North American local dialing rules. For example, one ruleset for Toronto, ON used to be 820 characters long. With the new optimizations, the character count is down to 621. This reduction can result in fewer rules, especially in larger cities.

If you've previously used the Optimizer to create your rulesets for 7-digit dialing, I recommend you apply the updated rules. If you subscribe to the monthly email rule update, then you'll get the updated ruleset starting next month. If you come across any issues with the new rules, please let me know.

Holiday Sets for Lync Response Groups

2012-05-03T14:57:00.002-04:00

If you use Lync Response Groups, you have probably noticed the lack of any built-in holiday definitions for any country. Setting these up yourself is a labour intensive and very boring process using Powershell. I figure I'd take the time to publish the commands necessary to setup the default holidays for both US and Canada. When it gets closer to 2014, I'll take the time to do the holidays then. I won't do them now, because things might change with the release of Lync 15.

First, copy and paste the holiday definitions into the Lync Management Shell as shown below. I didn't bother with holidays that have already happened in 2012. If the dates are incorrect for your site, go ahead and change them.

2012 Holidays

$Victoria = New-CsRgsHoliday -Name "Victoria Day 2012" -StartDate "5/21/2012" -EndDate "5/22/2012"
$CADay = New-CsRgsHoliday -Name "Canada Day 2012" -StartDate "7/2/2012" -EndDate "7/3/2012"
$USDay = New-CsRgsHoliday -Name "US Independence Day 2012" -StartDate "7/4/2012" -EndDate "7/5/2012"
$Civic = New-CsRgsHoliday -Name "CA Civic Holiday 2012" -StartDate "8/6/2012" -EndDate "8/7/2012"
$Labour = New-CsRgsHoliday -Name "Labour Day 2012" -StartDate "9/3/2012" -EndDate "9/4/2012"
$Columbus = New-CsRgsHoliday -Name "Columbus Day 2012" -StartDate "10/8/2012" -EndDate "10/9/2012"
$CA_Thanks = New-CsRgsHoliday -Name "CA Thanksgiving 2012" -StartDate "10/8/2012" -EndDate "10/9/2012"
$Veterans = New-CsRgsHoliday -Name "Rememberance/Veterans Day 2012" -StartDate "11/12/2012" -EndDate "11/13/2012"
$US_Thanks = New-CsRgsHoliday -Name "US Thanksgiving 2012" -StartDate "11/22/2012" -EndDate "11/23/2012"
$Christmas = New-CsRgsHoliday -Name "Christmas 2012" -StartDate "12/25/2012" -EndDate "12/26/2012"
$Boxing = New-CsRgsHoliday -Name "CA Boxing Day 2012" -StartDate "12/26/2012" -EndDate "12/27/2012"

Then run this Powershell command to create the holiday set. Replace YOURPOOLFQDNHERE with the actual name of the Standard or Enterprise Edition pool you want to create the holiday set. If your company has different holidays (ie Banks/government in Canada get Easter Monday off), add them to the holiday list (ie $EastMon)

For US
New-CsRgsHolidaySet -Parent "ApplicationServer:YOURPOOLFQDNHERE" -Name "2012 US Holidays" -HolidayList ($USDay, $Labour, $Columbus, $Veterans, $US_Thanks, $Christmas)

For Canada
New-CsRgsHolidaySet -Parent "ApplicationServer:YOURPOOLFQDNHERE" -Name "2012 CA Holidays" -HolidayList ($Victoria, $CADay, $Civic, $Labour, $CA_Thanks, $Christmas, $Boxing)

2013 Holidays

$NewYear = New-CsRgsHoliday -Name "New Year's Day 2013" -StartDate "1/1/2013" -EndDate "1/2/2013"
$MLK = New-CsRgsHoliday -Name "Martin Luther King Jr. Day 2013" -StartDate "1/21/2013" -EndDate "1/22/2013"
$FamilyPres = New-CsRgsHoliday -Name "Family/Presidents Day 2013" -StartDate "2/18/2013" -EndDate "2/19/2013"
$GoodFri = New-CsRgsHoliday -Name "Good Friday 2013" -StartDate "3/29/2013" -EndDate "3/30/2013"
$EastMon = New-CsRgsHoliday -Name "Easter Monday 2013" -StartDate "4/1/2013" -EndDate "4/2/2013"
$Victoria = New-CsRgsHoliday -Name "Victoria Day 2013" -StartDate "5/20/2013" -EndDate "5/21/2013"
$Memorial = New-CsRgsHoliday -Name "Memorial Day 2013" -StartDate "5/27/2013" -EndDate "5/28/2013"
$CADay = New-CsRgsHoliday -Name "Canada Day 2013" -StartDate "7/1/2013" -EndDate "7/2/2013"
$USDay = New-CsRgsHoliday -Name "US Independence Day 2013" -StartDate "7/4/2013" -EndDate "7/5/2013"
$Civic = New-CsRgsHoliday -Name "CA Civic Holiday 2013" -StartDate "8/5/2013" -EndDate "8/6/2013"
$Labour = New-CsRgsHoliday -Name "Labour Day 2013" -StartDate "9/2/2013" -EndDate "9/3/2013"
$Columbus = New-CsRgsHoliday -Name "Columbus Day 2013" -StartDate "10/14/2013" -EndDate "10/15/2013"
$CA_Thanks = New-CsRgsHoliday -Name "CA Thanksgiving 2013" -StartDate "10/14/2013" -EndDate "10/15/2013"
$Veterans = New-CsRgsHoliday -Name "Rememberance/Veterans Day 2012" -StartDate "11/11/2013" -EndDate "11/13/2013"
$US_Thanks = New-CsRgsHoliday -Name "US Thanksgiving 2013" -StartDate "11/28/2013" -EndDate "11/29/2013"
$Christmas = New-CsRgsHoliday -Name "Christmas 2013" -StartDate "12/25/2013" -EndDate "12/26/2013"
$Boxing = New-CsRgsHoliday -Name "CA Boxing Day 2013" -StartDate "12/26/2013" -EndDate "12/27/2013"

Then run this Powershell command to create the holiday set. Replace YOURPOOLFQDNHERE with the actual name of the Standard or Enterprise Edition pool you want to create the holiday set. If your company has different holidays (ie Banks/government in Canada get Easter Monday off), add them to the holiday list (ie $EastMon)

For US
New-CsRgsHolidaySet -Parent "ApplicationServer:YOURPOOLFQDNHERE" -Name "2013 US Holidays" -HolidayList ($NewYear, $MLK, $FamilyPres, $GoodFri, $Memorial, $USDay, $Labour, $Columbus, $Veterans, $US_Thanks, $Christmas)

For Canada
New-CsRgsHolidaySet -Parent "ApplicationServer:YOURPOOLFQDNHERE" -Name "2013 CA Holidays" -HolidayList ($NewYear, $FamilyPres, $GoodFri, $Victoria, $CADay, $Civic, $Labour, $CA_Thanks, $Christmas, $Boxing)

Enjoy!

Inbound Number Normalization Bug in Lync (FIXED)

2012-04-27T16:39:00.000-04:00

I came across an issue recently where a North American company had deployed Enterprise Voice using the Lync Dialing Rule Optimizer. Outbound calling would work fine, but inbound calls would fail with a busy signal. I was testing against a number that was supposed to route to an Exchange auto-attendant.

I ran a trace using the Snooper tool and found a big glaring red error staring at me:

404 - No matching rule has been found in the dial plan for the called number.

The detailed error looked like this:

Direction: outgoing;source="local"
Peer: lyncpool.contoso.com:58964
Message-Type: response
Start-Line: SIP/2.0 404 No matching rule has been found in the dial plan for the called number.
From: "604xxxxxxx";epid=5A81C7C2F0;tag=b356e0ebc3
To: ;tag=FCA83E847F99452AC4A563DB1552D6C4
CSeq: 2389 INVITE
Call-ID: 9d03fadf-282b-461b-912b-fbefe95a111b
ms-application-via: LYNCMON.contoso.com_LyncMonitoring;ms-server=LYNCFE.contoso.com;ms-pool=lyncfepool.contoso.com;ms-application=51FB453D-5B9F-45df-83B4-ADD1F7E604A8
Via: SIP/2.0/TLS 10.0.5.10:58964;branch=z9hG4bK71da34d1;ms-received-port=58964;ms-received-cid=18FC00
ms-diagnostics: 14010;reason="Unable to find an exact match in the rules set";source="LYNCFE.contoso.com";CalledNumber="4165551111";ProfileName="HeadOffice";appName="TranslationService"
Server: TranslationService/4.0.0.0

The inbound phone number was coming in as 10-digits, and excluded the North American country code 1 (which isn't unusual for a lot of phone providers). I knew the normalization rules were working properly for outbound calls, but I couldn't figure out why inbound was failing.

I zeroed in on my NA-National rule. The rule is formatted as follows:

^1?([2-9]\d\d[2-9]\d{6})$ ----NormalizeTo----> +1$1

This rule will accept any 10-digit valid North American formatted telephone number OR any valid 11-digit North American formatted telephone number starting with a 1. Users in many areas tend to use 10-digits and exclude the leading 1 when dialing phone numbers, or they may use the full 11-digit proper format. The NA-National rule deals with both these cases by starting the rule with 1?. When a question mark is present in a regular expression, it means that the preceding element is optional. So, in our case, the NA-National rule will match both 10-digit and 11-digit North American numbers.

Unfortunately, there seems to be a bug in earlier versions of Lync Server 2010 (prior to the March 2012 update from what I can tell) that results in inbound numbers failing to normalize against a rule that includes a question mark. When I removed the 1? from the rule, inbound calls worked as expected.

Thankfully, it appears that someone at MS has already caught this and fixed it somewhere between the November 2011 Lync Server update and the March 2012 update. I didn't try to figure out which update fixed it, but I knew it was broken on a server running the November 2011 updates, and was fixed with the March 2012 update.

If you keep up-to-date with your Lync server patches, you won't come across this bug. So, make sure you have the latest Lync Server updates applied before running the Optimizer for North American deployments.

Resetting Lync CMS Replication

2012-04-20T15:43:00.003-04:00

The Central Management Store (CMS) stores a copy of the entire Lync topology for your deployment. Every server has a copy of the CMS, but there can be only one master. Each Lync server downloads a copy of the CMS from this master at regular intervals. By default, the first Lync server you deploy is designated the master CMS. However, there may be cases where you have to move the master CMS to another server. This can be done relatively easily, assuming you follow the documentation properly.

The CMS replication process uses a local file share to copy updates between servers. The share is called \\servername\xds-replica. Every server has this share, including the CMS master. The share is typically located in the root of the C: drive in the folder C:\RtcReplicaRoot\xds-replica. If you installed Lync on another drive, this folder will be in the root of that drive.

Sometimes, you may find that CMS replication is not working on a specific server. You can check the CMS replication status by running the command Get-CsManagementStoreReplicationStatus. If all is well, every server's UpToDate status will be True. If a server's status is False, try to force replication by running Invoke-CsManagementStoreReplication -ReplicaFqdn servername. Wait a few minutes to see if its status changes. If not, then look in the Event Log for both the failed replica and the CMS master for clues as to what is wrong.

If you can't find any reason for the failed replication, I've found that deleting the xds-replica folder on the failed replica and recreating it seems to reset things and solve the problem. Unfortunately, even full Lync administrators do not have permissions to view the contents of the xds-replica folder (likely to prevent people like me from making a mess of things).

To "reset" the xds-replica to installation default follow these steps:

Stop the following services used for CMS replication:

Lync Server File Transfer Agent
Lync Server Replica Replicator Agent (courtesy of the Department of Redundancy Department)

Take ownership of the C:\RtcReplicaRoot\xds-replica folder, using the below picture as a guide. Be warned, that once you start this procedure, you're committed to following through. When you take ownership of the folder, you will wipe out the required permissions Lync needs to replicate the CMS and remove the share.

Once you take ownership, delete the entire xds-replica folder under C:\RtcReplicaRoot. Now, go to Control Panel - Programs and Features, select Microsoft Lync Server 2010, Core Components and select Repair. This will create a new xds-replica folder/share and set the proper permissions.
Go back to the Services snap-in and restart the two services. The Replicator service may have been set to Disabled by the repair process. Just set it to Automatic before starting it.
Run Invoke-CsManagementStoreReplication -ReplicaFqdn servername and after a few minutes you should see the CMS replication status for the server change to True.

This procedure worked like a charm for me on a few occasions. Let me know if it doesn't work for you.

Localized Dialing Rules in the Lync Optimizer

2012-03-01T13:04:00.000-05:00

I'm always looking for input from the community about things they'd like to see in the Lync Dialing Rule Optimizer. I met Pat Richard at the MVP Summit this week and he needed help in the following scenario:

He has a customer who has a centralized Lync deployment located in the United States. There are several small offices located in other countries who connect to the US Lync server and use it for Enterprise Voice. He wanted the users in the small offices to be able to dial phone numbers as if they were logged into a local Lync server.

For example, a UK user wants to be able to dial local UK numbers by dialing 6 or 7 digits. They dial national numbers by prepending a 0. They know they have to prepend 00 for international calls. They don't want to have to dial 01144xxxxxxxx for what they perceive to be a local call.

After some thought, I've updated the Optimizer to be able to handle this situation. If you want to provide localized dialing rules for different countries, just do the following:

Start with a clean Enterprise Voice slate
Run the Optimizer against your Lync site using the generated script appropriate for your country, which will generate the necessary dialing rules for the country where your Lync server resides.
Run the Optimizer for each country you want to create localized dialing rules and apply the generated script against your central Lync site.

By default, the rulesets for all countries use the official language for that country. If you want the Optimizer to use English for all rulesets, then click on Click for English-Only Version, on the top-left corner of the page (or go directly to http://lyncoptimizer.com/english.htm).

When you run the Optimizer script for the first time, it will create a site-level dial plan with normalization rules for the desired country. When you run the Optimizer script additional times, using scripts generated for different countries, it will detect the existence of a site-level dial plan and will create a user-level dial plan with normalization rules appropriate for that country.

Assign the user-level dial plan to the appropriate users and they will be able to dial phone numbers as they are accustomed to. Continuing the previous example, US users will dial local and national numbers using either 10 or 11 digits, and international calls starting with 011. UK users will dial local numbers using 7+ digits, national numbers starting with a 0, and international numbers with 00. The UK users won't be aware that when they dial a 7 digit local number, it actually gets dialed out from the US Lync server as 01144xxxxxxx.

Again, thanks to Pat Richard for the feedback and the suggestion, and for being the first person to actually give me a Paypal donation!

Lync Mobile for Android Updated!

2012-02-23T15:00:00.001-05:00

When the full suite of Lync mobile clients first came out, the Android experience was less than thrilling. One key feature missing was the ability to use the mobile client to make the Lync server call your mobile phone and then connect you to the person you are calling (call-via-work). All the other mobile clients had that feature, and the reason given was that it was difficult to program in Android's fragmented OS space. Fair enough, but it certainly wasn't a barrier to the hundreds of thousands of other apps that are available for Android.

It seems as though someone at MS finally got the message and they've just released a Lync Mobile update for Android in the Market. When I was at the Lync 15 Airlift last week, they said there would be an update "in a few months". Happily, they should have said "a few days". Wish this were the way for all upcoming MS products. The details for the update are as follows:

What's in this version:

Enabled call-via-work – allowing Enterprise Voice enabled users to make and receive calls using your Enterprise Voice (Lync ID) number only. Connect with others using a single identity.
Added user controls for adjusting the sound/vibration for incoming notifications
Improved the Lync status icon : know if you can receive IM messages
Enabled copy of IM text to the clipboard
Multiple bug fixes

Of course, I installed the update and had a poke around. Right off the bat, Lync Mobile asked me to verify my mobile number to be used for Lync to phone me back when using Call-via-Work. Immediately, it seemed as though the client was more responsive than before. This could just be wishful thinking, but it did seem snappier.

The My info screen now gives the ability to change your call forwarding settings, in addition to the usual ability to change my status from Available to Busy/Away etc.

Clicking on Call forwarding takes you to a screen where you can edit your settings. Any changes you make here are immediately reflected in your Lync desktop client.

The Options screen has new options for changing sound and vibration settings. When you select those options, you are able to change it to System settings or Never.

The Contacts screen looks the same as before. Status updates did seem quicker than before, so maybe that was part of the bug fixes. Clicking on a user brings up the same screen. No changes to the UI were noted here.

Before the update, when you clicked a phone number, it would just use your mobile phone to make the call. There was no integration with Lync. Now, when you make a call, Lync will notify you to answer the next incoming call.

The next call will appear to be coming from your office phone number, which you should recognize. As soon as you pick up the call, you'll hear it ringing the other end. That user will also see your office phone number. This effectively hides your mobile number from other users and will also be useful in situations where incoming mobile calls are free or where a call would be cheaper when being made through the Lync server PSTN connection.

There is a new screen called Keypad. From here, you can dial a number directly. As with the previous example, the Lync server will call your mobile number and then connect you to the number. One thing I noticed is that the normal normalization rules don't seem to kick in. So, I have to dial the full 11-digits instead of 10-digits like I normally do (Lync adds the 1 for me).

The most welcome addition for me was the ability to do one-click meeting joins from my Android phone. Before the update, I would have to manually enter the conference ID info, which would mean memorizing or writing down the confID and then entering it. Tough to do when you're trying to join a call from a car. Now, you can just click the meeting invite from your email, and it will call you and connect you to the meeting seamlessly. Even better, when I tested this feature while I was already joined to a meeting via Lync on my desktop, it dropped the desktop audio and seamlessly joined me via my mobile. So, if you have to leave, you can transfer to your mobile without missing a beat. Very slick and impressive!

The notification icon has also been updated to be more informative. While Lync is running and actively connected, you'll see the familiar Lync icon in your notification bar. When Lync is disconnected, the icon will show a little X (as highlighted in red below).

Since there isn't a Lync push notification service for Android, you won't get conversation updates when disconnected. However, if your phone works like mine (using JuiceDefender), the phone will shut off all network connectivity when not being actively used, but will periodically do a check. At that point, you will get any queued notifications. The user at the other end might get a failed delivery notification, so this isn't a very clean way to operate.

Even with the downsides, these updates are an extremely welcome addition to the Android Lync client. This brings Lync for Android up to near-feature parity with the other mobile clients. This Android fan is extremely happy!

Re-routing Incoming Lync Calls to AutoAttendant Using MSPL Scripting

2012-02-22T12:29:00.000-05:00

Many companies assign extensions to their users rather than dedicating a full external phone number. In companies with thousands of users, this is often the only option, plus it can save significant amounts of money. If you've followed my Enterprise Voice Best Practices for extensions, then you know that I recommend you assign phone numbers to Lync Enterprise Voice users using the main office number as the base followed by the extension, using the format tel:<OfficeNumberinE164Format>;ext=<Extension>. For example, if your main office number is 15553334444, and your extension is 222, then your Tel URI would be tel:+15553334444;ext=222. You then create a normalization rule that takes the main office number and routes it to an Exchange autoattendant at an unused extension, such as tel:+15553334444;ext=999. When someone calls the main office number, the phone call will be routed to the Exchange autoattendant where they can enter the extension of the user they wish to reach.

This works fine in many deployments, but in situations where the incoming phone number is already formatted in E.164 format (as with many SIP providers), it breaks down. When Lync sees a number that starts with a +, it assumes the number is normalized properly and does not apply normalization rules, no matter how hard you try. Users get a busy signal and if you do a log trace, you'll see the error 485 Ambiguous. Lync sees many users with the same base phone number, and doesn't know where to send the call.

In many of those cases, you can either set your PSTN gateway (if you are using one) to not send the + to Lync, or you can ask your SIP provider to drop the +. If neither of those options are available, then you can employ MSPL scripting to re-route the incoming call to the appropriate autoattendant.

MSPL scripts are simple text-based programs that can do custom message routing and filtering in Lync. They can be very powerful, if you know how to create them. Now, having exactly zero experience with MSPL scripting, I turned to the only way I know how to program: Google/Bing for examples. Thanks to some excellent blog posts by Michael Greenlee (which made me hyperventilate because most of it was totally incomprehensible to me) and a terrific example by Lasse Wedø (where he did the bulk of the work for me), I was able to figure out how to make this work in my specific example.

First, copy the contents of the below window into Notepad on a server that is running the Mediation Server role.

<?xml version="1.0"?>
<lc:applicationManifest
 lc:appUri="http://www.contoso.com/ReroutePilotNumtoAA"
 xmlns:lc="http://schemas.microsoft.com/lcs/2006/05">
<lc:allowRegistrationBeforeUserServices action="true" />
<lc:requestFilter methodNames="INVITE"
   strictRoute="false"
                        registrarGenerated="true"
                        domainSupported="true" />
<lc:responseFilter reasonCodes="ALL" />
<lc:proxyByDefault action="true" />
<lc:scriptOnly />
<lc:splScript><![CDATA[

// // // // // // // // // // // // // // // // // // // // // // // // // //  
// February 2012 - Application
// This script re-routes inbound calls from a specific number and routes it to
// an Exchange autoattendant.
// 
// Originally created by Rune Strand for OCS 2007
// Modified for Lync by Lasse Wedø then Ken Lasko
// // // // // // // // // // // // // // // // // // // // // // // // // // 
//
// CRITICAL:  Must be run before UserServices  (as 3. in list from above)
// When installing the app on server, use the -priority 2 switch
//

//
    // Filter out irrelevant requests
    //
    Log("debugr", 1, "ReroutePilotNumtoAA:           *  Inside app.");
    
    //
    //  Process only sipRequests
    //
    if (!sipRequest)  
     {
      Log("debugr", 1, "* * * * * * * ReroutePilotNumtoAA:*  Not a sipRequest. Leaving.");
      return;  // Message is not our business. Let Lync handle this.
    }

//
    // Avoid processing RE-INVITEs
    //
    foreach (sessionExpires in GetHeaderValues("Session-Expires")) 
    {
        if (ContainsString(sessionExpires, "refresher", true)) 
        {
            Log("debugr", false, "ReroutePilotNumtoAA: * Session refreshing invite. Leaving");
            return;  
        }
    }

//
    // INVITE is from a mediation server? If not, end processing
    //
    foreach (userAgent in GetHeaderValues("USER-AGENT")) 
    {
        if (! ContainsString(userAgent, "mediation", true)) 
        {
            Log("debugr", false, "ReroutePilotNumtoAA: * Request not from Mediation server. Leaving");
            return;  // Only external requests are of interest!
        }
    }

Log("debugr", 1, "ReroutePilotNumtoAA: * App is processing a request - ", sipRequest.Method);

//
    // Build the user@host from the To: header.  (and some other convenient variables)
    //
    toUri = GetUri(sipRequest.To);
    toUserAtHost = Concatenate(GetUserName(toUri), "@", GetHostName(toUri));
    telNum = GetUserName(toUri);

//
    // Look for +15552229999@contoso.com in the sipRequest object
    // This is the Attendant no. 
    //
    if (ContainsString(toUserAtHost, "+15552229999@contoso.com", true)) 
    {
        Log("Event", 0, "ReroutePilotNumtoAA: Autoattendant match. Re-routing +15552229999 to Autoattendant", toUserAtHost);
        
        Respond("302","Moved Temporarily","Contact=<sip:Main_AA@contoso.com>");
        
        // Return initiative to Lync.
        return;
    }
          
    // Return initiative to Lync/Default Routing.
    return;

]]></lc:splScript>
</lc:applicationManifest>

Do a search-and-replace for contoso.com and use your public domain name instead.

Then do another search-and-replace for 15552229999 and use your main office number instead.

Finally, do a search-and-replace for Main_AA@contoso.com and replace it with the SIP URI of your Exchange autoattendant or response group. You can determine the SIP URI by running the OcsUmUtil.exe program (located in C:\Program Files\Common Files\Microsoft Lync Server 2010\Support). This program is used to create the necessary contact objects to connect Lync to Exchange UM. Once you click Load Data, make note of the SIP URI for the appropriate AA, and do a search-and-replace for Main_AA@contoso.com in the script using the information you found from OcsUmUtil.

Then save the script on your mediation server/front-end in a folder like C:\MSPLScripts, calling it ReroutePilotNumtoAA.am. If you have multiple servers in the pool, copy the script to each server.

Now, open Lync Management Shell and type the following (make sure you replace contoso.com with your public domain name):

New-CsServerApplication -Name ReroutePilotNumtoAA -Parent Service:Registrar:
<lyncpoolFQDN> -Uri http://www.contoso.com/ReroutePilotNumtoAA -Enabled $TRUE -Critical $FALSE -ScriptName c:\MSPLScripts\ReroutePilotNumtoAA.am -Priority 2

If all goes well, you should see a few events in the Lync Server Event Viewer like the following:

Log Name: Lync Server
Source: LS Script-Only Applications
Event ID: 30803
Description: Loading application - 'c:\MSPLScripts\ReroutePilotNumtoAA.am'

Log Name: Lync Server
Source: LS Applications Module
Event ID: 30208
Description: Lync Server application has successfully registered.
Application Uri 'http://www.contoso.com/ReroutePilotNumtoAA'

Open Lync Control Panel and go to Topology - Server Application and you should see the new script between TranslationService and UserServices.

If the script doesn't work you will see the error logged in the Event Viewer. If so, click Action and Disable Application. After a few minutes, you should see an event saying the script was disabled. Make any necessary fixes and re-enable. It will take a few minutes to restart. Once you get a clean start, try calling the main office number. You should be directed to the chosen Exchange autoattendant.

Every time the script runs, it will log a warning event saying that the number was forwarded to the autoattendant. If you don't want to see this event, comment the line that starts with Log("Event" with a //.

What is happening behind the scenes is that the script is looking for an INVITE for the main office number. If it sees that, it will respond to the system making the call with a 302 Moved Temporarily. This tells the system to forward the call to the new destination.

I recommend that you thoroughly document the procedure for future Lync administrators. If you hand off Lync administration to someone else, it will be very difficult to determine that a script is being used to re-route the office number. It doesn't make itself known when doing a typical log trace. If you make a call to the office number, the trace will only show the phone call is going to the AA. It won't show the script making the forward.

Also, note that this procedure can be used to forward calls to ANY SIP URI, not just an Exchange autoattendant. It can be an autoattendant, a response group or an individual user.

This is my first foray into MSPL scripting. If you notice any errors, please let me know.

For more funtastic MSPL examples, check out VOIPNorm's blog.

Hardware Load Balancers in Lync

2012-02-07T12:27:00.001-05:00

Over the past while, I've come across several Enterprise Edition Lync deployments done by other companies that utilized hardware load balancers for all Lync services. In every case, the reason given for using the hardware load balancers was "so we could have high-availability". They were shocked to find out that hardware load balancing all Lync services is actually not recommended in a wide variety of scenarios and they could have saved themselves a lot of time and money.

When I design a highly-available Lync deployment, I ask four questions whose answers determine where hardware load balancers are required:

Will the majority of internal clients be running Lync?
Will the majority of external clients be running Lync?
Do you require high-availability when federating with companies running OCS 2007 R2 or older, or MSN/Yahoo!/AOL/GoogleTalk/Jabber?
Do your external users need to play messages on their phone during a failover?

If the answer to #1 is "No", then I recommend against using hardware load balancing (HLB) for all internal Lync front-end pools. If the answer to #2, #3 and #4 are also "No", then I recommend against using HLB for edge servers as well.

Before I go on, I should stress that HLBs are still required for load balancing HTTP/HTTPS traffic to the front-end servers. Since web connections are session based, they are not suitable for DNS load balancing. So, for your web services (which includes address book downloads, meeting content and meet/dialin URLs), you will still need a simple HLB solution, which can be provided by either hardware or even a dedicated software-based load balancer (but don't use Windows NLB, its not supported)

Using hardware load balancers in Lync can be a costly endeavour for many reasons:

For a full HLB solution for a single Lync site with edge services, you would need an HLB for the front-end pool, an HLB for the internal interfaces on your edge pools and an HLB for the external interfaces on your edge pool. That's 3 HLBs.
Many HLBs are not well suited to real-time communication. HLBs that support real-time media are much more expensive than one used only for web traffic balancing.
Configuring the load balancers to work with Lync is much more complicated and extends the implementation time. It can also complicate troubleshooting connectivity issues.
Putting additional hardware between your users and the servers also introduces additional network latency, which is something you want to minimize where possible.
Finally, the HLBs themselves can be a single point of failure, unless you deploy multiple nodes.

Lync can use DNS load balancing to provide high availability. That term is misleading, because it implies that DNS is responsible for load balancing, which is not true (or possible, since you can only do DNS round-robin in most cases). DNS is only used to present the initial list of available front-end or edge servers (depending on if the user is internal or external). Once the Lync client successfully connects to Lync, it caches the IP address of each server in the pool. The user will preferably connect to the same server at each login (calculated using an algorithm described here), but if that server is unavailable, the client will automatically and seamlessly connect to another server in the pool. The same is also true for federated connections from other companies, as long as they are using Lync for their edge servers.

For legacy connections or 3rd party IM provider connections to a DNS load balanced Lync pool, the clients/edge server will only connect to the first IP address that is returned from a DNS lookup. Should that server go down, they will not failover to an alternate server. The same is true for external users who try to listen to Exchange-based voicemail messages during a failover. If legacy/3rd party connections or external access to voicemail (and remember that voicemail messages are always accessible via Outlook) are important, then this is the ONLY reason I would deploy HLB on your edge servers. In most cases, the company accepts the reduced potential for legacy high-availability in return for a simpler, cheaper and more reliable solution.

So before you go and drop a ton of money on hardware load balancers, make sure you understand the built-in high-availability capabilities in Lync first, so you can make an informed decision.

For more information on DNS load balancing in Lync, check out these links:
Lync DNS Load Balancing on Technet
Lync DNS Load Balancing on NextHop

Going to MVP Summit

2012-01-13T13:52:00.000-05:00

I got accepted into the Microsoft MVP program for Lync a few weeks ago, and have just booked passage to my very first MVP Summit in Seattle the week of February 27 to March 2, 2012.

Since I have to keep up with the Hoff persona, you can expect to find me driving up to the beach in my '80's black Pontiac Trans-Am, stripping down to some red shorts and running down the beach in slow-motion. My chest hair will keep me warm in Seattle's February climate.

If you're going to be at the summit, I'm sure I'll get the chance to meet you! See you there.

Lync Edge Server Static Routes

2012-01-06T13:36:00.000-05:00

If you're following the Technet articles on how to setup your edge server, you will eventually get to the point where you have to setup your NICs on your edge server. According to the Set Up Network Interfaces for Edge Servers page:, you should set the default gateway on the external interface, but not the internal. The guide then helpfully tells you to....

Create persistent static routes on the internal interface to all internal networks where clients, Lync Server 2010, and Exchange Unified Messaging (UM) servers reside.

If you're not a Windows networking expert, this might stump you a bit. Doing some searches might help, but here's a simple way to ensure that all internal networks are covered, even if you aren't aware of exactly which ones are in use. This can easily happen if you're a consultant doing a Lync deployment for a large, multi-site company.

There are 3 well-known IP subnets that are reserved for internal use. Any networking person can tell you what they are, and should be using these for their internal corporate network. If not, then I would recommend running away. The 3 well-known subnets are 10.0.0.0/8, 172.16.0.0/12 and 192.168.0.0/16.

I typically add static routes for all 3 subnets even if they aren't all in use. This will future-proof your deployment in case the company adds or changes their subnetting scheme. To add these static routes on the internal interface of your edge server, do the following:

Using the Network Connections interface, make sure your NICs have descriptive names that make sense (Ie. Internal and External)
Open a command prompt in Administrative Mode on the edge server.
Make sure you know what the internal default gateway should be. In this example, we will use 192.168.100.1
Type the following commands in the command window:

netsh interface ipv4 add route 10.0.0.0/8 "Internal" 192.168.100.1
netsh interface ipv4 add route 172.16.0.0/12 "Internal" 192.168.100.1
netsh interface ipv4 add route 192.168.0.0/16 "Internal" 192.168.100.1

When you do a netsh interface ipv4 show route, you should see the new routes show up at the bottom of the list. If you make a mistake, you can delete a route by using the same command above, and replace add with delete. Now, your Lync edge server should be able to route to any internal address, both now and in the future.

UPDATE: Apparently, I'm part Amish, and I was using ROUTE ADD instead of the updated netsh commands shown above. Thanks to @twharrington on Twitter for pointing out the error to this ol' timer. I'M DOIN' IT OLD SKOOL!

Complete Guide to the Lync Optimizer

2012-01-03T14:46:00.002-05:00

UPDATE (09-Jan-2013): Least-cost and failover call routing is now built into the Optimizer. See this post for information.
UPDATE (05-Dec-2012): Added true customized local dialing rules for the UK. See this post for information.
UPDATE (31-May-2012): Significant optimizations to North American local rulesets, and fix of normalization rule bug affecting 7-digit dialing rules. See this post for more information.
UPDATE (16-Mar-2012): Now creates separate dialing rules for toll-free and premium calls. Makes it easier to limit dialing to some groups while granting additional dialing rights to others.

UPDATE (29-Feb-2012): Will allow you to run multiple Optimizer output files against a site to provide localized dialing rules for international users. See this post for more information.
UPDATE (17-Feb-2012): Program will now create separate dialing rules/usages for mobile networks in non-North American dial plans. Allows for administrators to easily control who is able to dial mobile numbers, which usually cost more than land-lines.

Introduction
Whenever I've added new features to the Lync Dialing Rule Optimizer, I've created a post outlining the new functionality. This has led to information being scattered across several different posts and isn't readily available. I figured it would be best to create a single, all-encompassing post that outlines how to get the most out of the Lync Optimizer. It will be updated over time as new features are added.

The Lync Optimizer began its life in February 2009 as a locally run VBScript designed to create optimized dialing rules for Dialogic and Audiocodes gateways, as detailed in this post dug up from ancient times (2010). Its primary purpose was to figure out what phone numbers were local and which were long distance for any given area. People who knew me would email me the phone number they would want optimized and I would run the program and email the results. The earliest known versions of this code are now archived in the Smithsonian for future historians. It has since grown and evolved into the well-oiled Lync-centric online machine it is today.

There are tons of documentation available on how to setup Enterprise Voice in Lync Server 2010, but reading through them all can be daunting and there is not very much guidance on the WHYs as much there is on the HOWs. The Lync Dialing Rule Optimizer is designed to take care of 95% of the typical setup required to make Enterprise Voice work in Lync Server 2010. It takes advantage of the knowledge gained from multiple deployments from several Lync professionals on the best way to do things in Lync. All this knowledge is funnelled down into a simple set of options that outputs a Powershell script that takes care of almost all the work for you.

For some more background on Lync Enterprise Voice Best Practices, I encourage you to read through some of my posts on the subject:

Migrating to Enterprise Voice

Tested Scenarios
The Optimizer has been tested to work with the following topology combinations:

Single central site
Multiple central sites
Multiple central sites with multiple branch sites
Single central site with multiple mediation pools
Multiple central/branch sites with multiple mediation pools/PSTN gateways

Before You Start
Before you jump in and use the Optimizer, its best to make sure your Lync environment is up to speed.

Make sure that all your user's phone numbers in Active Directory are in E.164 format, as described in my post on E.164 formatting.
Make sure you have a PSTN gateway defined in your Lync topology for each Lync site you wish to run the Optimizer.
Don't mess around with any of the Enterprise Voice sections at this time. It will just complicate your life. If practical, delete any routes/usage/policies you've already defined.
If you do have existing policies/routes etc. back them up by going to Action - Export Configuration under the Voice Routing section of the Lync Control Panel.

Using the Lync Optimizer

Ensure the Lync site you wish to apply the rules have at least one PSTN gateway assigned to it. If you don't, the script will not run.
Go to http://www.LyncOptimizer.com. If you wish to create rules that use only English, regardless of the official language in the chosen country, click on Click for English-Only version.
Pick your country from the drop-down list.

For North American (including Hawaii and Alaska) and Caribbean users, enter the area code and local exchange information for the Lync site you want to apply the script to. For other countries, pick the city where your Lync server resides from the list provided.

North American Area Code Selection

International Area Code Selection (UK example)

Non-North American users have the option to add a rule suffix to each generated rule. This is handy when deploying Lync to multiple sites within the same city. Without customizing rule names, the rulesets can conflict with one another, producing unexpected results. With the example shown below, the non-customized rule would be UK-Leeds-113-Local. Adding Downtown changes each rule so they start with UK-Leeds-113-Downtown-

Some countries (Brazil for example) requires a carrier access code to be dialed when dialing long distance phone numbers. If your country requires a carrier access code (Brazil is the only one in the Optimizer so far), you can enter it here. The carrier access code will be added to the dialed number after the national/international access code and before the subscriber number. For example, if you select 19 as the carrier access code, then long-distance numbers will be sent to the PSTN as 019xxxxxxxxx, instead of just 0xxxxxxxxxx.

If you have to enter 9 (or some other digit) to get an outside line, enter it in the External Access # box. This should only apply to connections to an existing PBX. Don't enter numbers you would normally have to use to make a call from outside the office (ie. 00).

If you want your users to be able to enter an extension to reach someone, select the Use Extensions checkbox. When you select the checkbox, it will show an Edit Extensions button. Clicking it will bring up the Extension Entry screen.

If none of your users are directly dialable (ie. have to go through a receptionist), then enter the full main phone number and the corresponding extension range. In the above example, if a user dials 244, it will normalize to +14165551111;ext=244. This assumes that you've assigned the phone number to the user in the format tel:+14165551111;ext=244. If you entered it as just 244, this will not work. See my post on Extensions for more information.

If your extension range maps to an external DID, select the DID checkbox and enter the prefix and extension start/end range. This will create a normalization rule that will translate typed extensions to the full DID. As in the above example, if a user dials 3055, the number will be normalized to +14165553055. Again, this assumes you've assigned the phone number to the user in the format tel:+14165553055. If you've used the extension only, this will not work.

You can enter up to 10 extension ranges here. If you need more, please send me a note, and I will see about increasing the limit. Make sure you press Submit when done, or else it won't save your work.

If you are using a SIP trunk that accepts E.164 phone numbers, select the SIP Trunk Connection option. If selected, the program will not create trunk translation rules. All numbers will be sent to the next hop formated as E.164. It will also set encryption on the trunk to Optional and will disable REFER support, as this is not supported by most SIP providers. Note: Don't select both an external access number AND SIP trunk options. The two options are mutually exclusive.

If you want Lync to block premium rate phone numbers (like 900 in North America) for all users, select the Block Premium Numbers checkbox. The program will use the Announcement service to let the user know they can't dial those numbers. This will apply to ALL users in the company, so don't use this option if you want to be more selective. See the original post for more information.

If you want to use the Call Park feature, select the Enable Call Park option. When selected, you will be able to enter a range for the call park orbit. The range must be 2-digits or longer and can include * or # at the beginning. To ensure the call park orbit doesn't conflict with an existing normalization rule, the program will create a Call Park specific normalization rule to make sure those numbers are not normalized to something else. Check out the Call Park Deployment Guide for more information on Call Park.

If your North American local dialing area supports 7-digit dialing, select the 7-Digit Normalization checkbox. If you're unsure if your local dialing area supports 7-digit dialing, leave this blank. Selecting this option when 7-digit dialing isn't available can lead to unpredictable results. Doesn't apply to other countries other than North America.

To receive updates should the ruleset change, enter your email address. Only applies to North American users.
After pressing Generate Rules, wait a minute for the rules to be generated.
The program will generate a single .PS1 file. Save this file onto your desktop.
Right-click the .PS1 file and click Properties. Click the Unblock button to allow the script to be run. Alternatively, run the Powershell command Set-ExecutionPolicy -ExecutionPolicy Unrestricted on your Lync server.

Run the .PS1 file by typing .\Filename.ps1. For the above example, use .\Toronto-ON-416678-Lync.ps1. You will be prompted to select the site to apply the dialing rules.

If there are multiple mediation pools or PSTN gateways in the specified site, the script will prompt you to select one.
If the Optimizer detects multiple Lync sites, it will ask if you want to apply least-cost/failover routing to the new voice policies.
The script will then create all the necessary dial plans, routes, usages etc. to get you going.

After Running the Optimizer Script

If you have multiple mediation pools and/or PSTN gateways in the site, you can re-run the script and select the other gateway. The script will add the gateway to the existing routes. Calls using that route will round-robin between the gateways.
If you want least-cost/failover routing applied to all the sites where you've applied Optimizer-generated scripts, run each of the scripts again, ensuring you select the option to configure least-cost/failover routing. It will update the voice policy to include the additional PSTN usages. See this post for more information.
If you have users from different countries using a single Enterprise Voice deployment, run the Optimizer for each country and run the resulting script. It will create user-level dial plans so those users can have localized dialing rules, as described in this post.

Verifying Settings

To verify the settings were applied properly, go to the Voice Routing section of the Lync Control Panel.

Dial Plan Settings

The script creates a site level dial plan for the site you selected in the script. All users assigned to the Lync servers in that site will have this dial plan automatically applied to them.

Drilling down into the details of the dial plan shows the normalization rules applied to the dial plan. You'll note the External access prefix has been set in this example. For more information on what this does, see my post on internal extension dialing.

If you've setup localized dialing rules against a central Lync deployment, there will be user-level dial plans here. This will allow people homed in different countries to use their local dialing rules, instead of the rules assigned to the central pool. You will have to manually assign the dial plan to the appropriate users, or use a Powershell script.

The normalization rule for call park is highest in the list (if selected), followed by internal extensions (if selected), then national, international, service and in the specific case of Canada, 310 numbers.

Voice Policy Settings
The script then creates multiple voice policies. Voice policies are used to assign calling features to groups of users. A site-level policy is assigned to everyone by default and allows local, national and international calls. Three user-level policies allow varying degrees of calling rights. The Local policy allows only local calls (excluding mobile phones in non-NA countries), the National policy allows local, mobile and national calling, and the International policy allows all calls, including premium rate calls.

The calling rights assigned to each policy is summarized in the table below:

	Calling Rights
Policy	Local	Service	National	Mobile	Toll-Free	Premium	International
Site	X	X	X	X	X		X
User-Local	X	X			X
User-National	X	X	X	X	X
User-International	X	X	X	X	X	X	X

You can elect to change any policy to allow any combination of dialing abilities. You do this by editing the appropriate policy and adding or removing the appropriate PSTN usage records as shown below. You can also change the calling features available to users. You can always create new policies if the default ones don't match your needs.

Routes
Each route created are assigned to a PSTN gateway as selected at the beginning of script execution (if there are more than one choice). If you have multiple PSTN gateways assigned to a mediation pool, you can run the Optimizer script multiple times, selecting a different PSTN gateway each time. The script will add the gateway to each route. With multiple PSTN gateways in a route, calls will round-robin between the gateways.

PSTN Usages

Usages are the links between voice policies and routes. A usage can have multiple routes assigned to it, and can be assigned to multiple voice policies. This provides a very flexible and easily modified structure for voice rules. There are 5 usages for each site (6 for non-NA countries): Local (if local dialing available in selected country), National, International, Mobile (for non-NA countries), Premium and Service. Each usage has the appropriate routes assigned (ie. the Local usage has routes for local, internal and toll-free numbers).

Trunk Configuration

The trunk configuration does final outgoing phone number manipulation before sending the call to the PSTN gateway. Since all phone numbers are coming to the gateway in E.164 format, its simple to strip digits as required. For instance, local calls strip the national prefix, international calls add the international prefix for the selected location, and so on.

If the SIP Connection option was selected in the Optimizer, there will be no modification of outbound phone numbers. Everything will be sent to the SIP provider in E.164 format. Also, REFER support will be turned off, and encryption will be set to Optional.

Blocked Premium Numbers

If you selected the Block Premium Numbers option, the program will automatically setup the unassigned number range and relevant announcement for your country. For more details on this feature see my post on blocking premium numbers in Lync.

Call Park

If you selected the Call Park option, the script will create the relevant call park orbit, and also a normalization rule to ensure the number range is never normalized to something else.

Next Steps

If you only have a single Lync site, then your work is pretty much done. You can enable users for Enterprise Voice and things should work just fine (assuming your PSTN gateway connection is setup properly).

If you have multiple sites, and selected the option to apply least-cost/failover routing, ensure the ordering of the usages meets your requirements. Change the order as required.

Conclusion

This should give you a good overview on what the Lync Dialing Rule Optimizer does. As mentioned earlier, this page will be updated as new features are added. If you have any questions, feel free to drop me a line.

Also, if you find the Lync Optimizer useful, please consider donating using the PayPal link on the bottom of the Optimizer page. I've invested a significant amount of my own time putting this tool together (and continue to do so), and I do have hosting costs to consider.

Lync Mobility Documentation Now Available

2011-12-09T09:59:00.001-05:00

The Lync Mobility Planning, Deploying and Monitoring documentation and associated autodiscover service are now online. Get the documentation here and the server bits here. The Windows Mobile 7 client will be available on Monday, December 12. The iOS and Android clients should be available sometime that same week (pending the appropriate market approvals).

The documentation surrounding this is quite complex. This is not a simple setup. Already, people are finding out what happens when you try to blindly run setup for the autodisover service (see http://ariprotheroe.wordpress.com/2011/12/09/how-not-to-install-the-lync-2010-mobility-and-autodiscover-services/). It pays to read the documentation carefully before running setup.

One thing that I find disappointing is the requirement for a new DNS namespace (lyncdiscover and lyncdiscoverinternal). When I was at the Exchange 15 summit last August, they made a big deal about reducing the number of namespaces required for a functional Exchange deployment. I hope there's a good reason why the Lync team has decided to increase the namespace requirements for Lync. Why not use the existing SRV-based infrastructure to publish the required information?

There's a Microsoft conference this afternoon about the Lync mobility service. Hopefully there will be an explanation about this. I will update this post with more information as I get it.

Lync and 3rd Party PBX Integration

2011-11-18T13:17:00.001-05:00

I've been reading the comments over at VOIPNorm's blog post about Avaya ACE. There's a lot to wade through there, but it got me thinking about customer expectations around unified communications. I've got this one particular customer who's got Cisco phones deployed everywhere. They've also got Lync everywhere and people love it. They recognize that Lync has nailed the user experience, encompassing a full featureset along with an easy-to-use interface. Naturally, this customer doesn't want to toss out their significant investment in Cisco hardware, and they want Cisco and Lync to work together. They want Lync to work with their existing phone system with little fuss, and still maintain the rich UI experience of Lync.

What I want to tell them is that you will NEVER have a truly seamless easy-to-use experience when you try to join two competitors' UC products together. To paraphrase one of the commentors at VOIPNorm's blog: when you mix a nice red wine with a nice white wine, the end result isn't a great rosé.

At this client, we attempted to go down the integration path with OCS and a third-party product that promised seamless remote call control with Cisco. They were looking at a 3rd party for RCC rather than Cisco's Unified Presence Server (CUPS), because of apparent scalability issues with CUPS. From an administrative standpoint, the 3rd party product was an absolute nightmare to configure and troubleshoot. Once we did get it working, it did provide remote call control, but there were significant usability issues. The product worked fine when the user was in the office. Users could make or take calls on their deskphone using Lync to control it. However, when the user went home they got frustrated when they couldn't answer incoming calls they could see on their Communicator client because it would answer it on the deskphone back in the office.

We tried giving them the best of both worlds by enabling them for Enterprise Voice, but that became a support nightmare when they got confused about which way to answer the phone or to make calls. If they were set to answer via Communicator, they were confused why their deskphone didn't go off-hook. If they made a call from home and they were set to RCC mode, then they didn't understand what was going on when they dialed a number and they couldn't hear anything (because the call was going out via the deskphone at the office). Not only that, but we now had two separate phone systems to manage.

We tried CuciMOC and CuciLync as well. I remember saying that if CuciMOC could deliver on even half of what they were promising, then our integration problems would be solved. Unfortunately, the end-user experience was so lacking that the project never went beyond the IT pilot phase. Not only that, but the administrative burden involved in configuring and maintaining it was not something that the IT group wanted to deal with on a large scale.

Both projects died a well-deserved death, but the CIO has been demanding seamless connectivity between Cisco and OCS/Lync ever since. It's interesting that people expect so much more from Microsoft than any other vendor. I don't think I've ever heard anyone demanding that Cisco and Avaya integrate with each other. Why should Microsoft get such different treatment?

Unfortunately, when we are dealing with two COMPETING vendors like Cisco and Microsoft, there will never be the sort of tight integration that will allow companies to both leverage their existing investment AND take full advantage of the UC capabilities of Lync. Each vendor has their own very good reasons to push the benefits of their own particular solution. Companies need to stop trying to get the best of both worlds and fully invest in either one or the other solution, not both.

I truly believe that Lync is the best and most cost-effective unified communications solution out there. No other vendor has the same level of product functionality built into the base product as Lync. Companies can get IM, presence, video/audio conferencing, whiteboarding, application/desktop sharing and Enterprise Voice with as little as ONE server. Of course, high availability requirements and larger deployments do require more servers, but it does serve to illustrate what is possible with just one server. Add ONE more server for seamless external connectivity with other companies and remote users. Lync can provide companies with the sort of unified communications their users desire, but sadly even with my best pre-sales pitch, I can't convince everyone.

We are in the early days of a true revolution in communications. Its natural to be resistant to the big changes necessary to put the pieces in place. However, once the switch is made, it will pay dividends in terms of ease-of-communications, cost and flexibility.