Localized UK Dialing Rules for the Optimizer

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

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

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:

1. 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.
2. Survivable Branch Server (SBS) - A "Lync-lite" installation containing the Lync registrar and mediation server roles.
3. A PSTN gateway and a standalone Lync mediation server
4. 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

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

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
   }
}

Enable All Users in a Group for Lync Enterprise Voice
#Uses existing office number in AD for Enterprise Voice
Import-Module ActiveDirectory

$Users = Get-ADGroupMember lync_group

ForEach ($User in $Users)
{
    Enable-CsUser $User.SamAccountName -RegistrarPool LYNCPOOLNAME -SipAddressType EmailAddress
    $OfficePhone = (Get-CSADUser $User.SamAccountName).Phone
    $OfficePhone = $OfficePhone -replace "\D", ""
    Set-CSUser $User.SamAccountName -EnterpriseVoiceEnabled:$TRUE -LineURI "tel:+$OfficePhone"
}

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, Mail
$Output += New-Object PSObject -Property @{DisplayName=$LyncUser.DisplayName; Department=$ADUser.Department; Title=$ADUser.Title; SAMAccountName=$ADUser.sAMAccountName; Mail=$ADUser.Mail; SIPAddress=$LyncUser.SIPAddress; LineURI=$LyncUser.LineURI; EVEnabled=$LyncUser.EnterpriseVoiceEnabled}
}

$Output | Export-CSV -Path .\Output.csv
$Output | FT DisplayName, Title, Department, SAMAccountName, Mail, 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

Add Enterprise Voice Users to an AD Group
Foreach ($User in get-csuser -filter {EnterpriseVoiceEnabled -eq $TRUE})
{Add-ADGroupMember -Identity -Members $User.SamAccountName}

Enable All Users in an AD Group for Lync EV/Exchange UM
#Takes the office number from AD, assuming its formatted correctly, extracts the last 4 digits to use
#as the extension (for dialin conferencing), and uses it for the LineURI and extension for UM.

Import-Module ActiveDirectory

#Import Exchange Powershell
$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri http://EXCHANGESERVERFQDN/PowerShell/ -Authentication Kerberos
Import-PSSession $Session

$Users = Get-ADGroupMember TARGETADGROUP

ForEach ($User in $Users)
{
    Enable-CsUser $User.SamAccountName -RegistrarPool LYNCSERVERFQDN -SipAddressType EmailAddress
    $EmailAddress = Get-CSADUser $User.SamAccountName).WindowsEmailAddress
    $OfficePhone = (Get-CSADUser $User.SamAccountName).Phone
    $OfficeExt = $OfficePhone.Substring($OfficePhone.Length - 4)
    $OfficePhone = $OfficePhone -replace "\D", ""
    $OfficePhone = $OfficePhone + ";ext=" + $OfficeExt
    Set-CSUser $User.SamAccountName -LineURI "tel:+$OfficePhone"
    Set-CSUser $User.SamAccountName -EnterpriseVoiceEnabled:$TRUE
    Enable-UMMailbox $User.SamAccountName -UMMailboxPolicy "UMPOLICYNAME" -SIPResourceIdentifier $EmailAddress -Extension $OfficeExt
}

List All Remote PowerShell Sessions On A Machine
Get-WSManInstance -ComputerName COMPUTERNAME -ResourceURI Shell -Enumerate | FT Owner, ClientIP, State

Lync Dialing Rule Optimizer Gets Optimized

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

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.

First, copy and paste the holiday definitions into the Lync Management Shell as shown below.  If the dates and/or actual holidays are incorrect for your site, go ahead and change them.

2016 Holidays

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

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 "2016 US Holidays" -HolidayList ($NewYear, $MLK, $Presidents, $GoodFri, $Memorial, $USDay, $Labour, $Columbus, $Veterans, $US_Thanks, $Christmas)

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

2017 Holidays

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

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 "2017 US Holidays" -HolidayList ($NewYear, $MLK, $Presidents, $GoodFri, $Memorial, $USDay, $Labour, $Columbus, $Veterans, $US_Thanks, $Christmas)

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

Enjoy!

Inbound Number Normalization Bug in Lync (FIXED)

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

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:

1. 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)

2. 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.

3. Once you take ownership, delete the entire xds-replica folder under C:\RtcReplicaRoot.  
4. 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.
5. 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.
6. 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

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:

1. Start with a clean Enterprise Voice slate
2. 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.
3. 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://ucdialplans.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!

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:

1. 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.
2. Added user controls for adjusting the sound/vibration for incoming notifications
3. Improved the Lync status icon : know if you can receive IM messages
4. Enabled copy of IM text to the clipboard
5. 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

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

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:

1. Will the majority of internal clients be running Lync?
2. Will the majority of external clients be running Lync?
3. Do you require high-availability when federating with companies running OCS 2007 R2 or older, or MSN/Yahoo!/AOL/GoogleTalk/Jabber?
4. 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

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

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:

1. Using the Network Connections interface, make sure your NICs have descriptive names that make sense (Ie. Internal and External)
2. Open a command prompt in Administrative Mode on the edge server.
3. Make sure you know what the internal default gateway should be.  In this example, we will use 192.168.100.1
4. 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

UPDATE (21-Aug-2013): Improved UI and additional control options for rule creation. See this post for more information.
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/2013, 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/2013.  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:

E.164 Formatting

Normalization

Usages and Routes

Extensions

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.

1. 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.  
2. Make sure you have a PSTN gateway defined in your Lync topology for each Lync site you wish to run the Optimizer.
3. 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.
4. 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

1. 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.
2. Go to http://www.LyncOptimizer.com.  
3. Pick your country from the drop-down list.

4. 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 or area where your Lync server resides from the list provided.

North American Area Code Selection

International Area Code Selection (UK example)

5. To use simplified call routing which uses only a single all-encompassing route for all calls, instead of the default local, national, international etc routing, select the Simple Ruleset checkbox. You'll notice the Rule example will update to show the effect on the ruleset. Keep in mind that least-cost routing is not possible in this configuration. 

6. To force English language rulenames and descriptions for countries that would normally use the local language, select the Force English Rulenames checkbox. This option only appears on countries where the default language is other than English. Again, you'll see the effects on the Rule example line.

7. The rule naming convention can be changed if desired.  The country abbreviation prefix and rule type suffix can't be modified to ensure least-cost routing calculations can function normally. Select the Change Rulename Base checkbox and type the new rulename base to use for all rules.

Toronto Rule Name Change Examples

8. 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.

9. 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).

10. 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.

11. 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. 

12. 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.

13. 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.

14. 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.

15. To receive updates should the ruleset change, enter your email address.  Only applies to North American users.
16. After pressing Generate Rules, wait a minute for the rules to be generated.
17. The program will generate a single .PS1 file.  Save this file onto your desktop.  
18. 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.

19. 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.

20. If there are multiple mediation pools or PSTN gateways in the specified site, the script will prompt you to select one.  
21. If the Optimizer detects multiple Lync sites, it will ask if you want to apply least-cost/failover routing to the new voice policies.
22. If the Optimizer detects the presence of Lync network sites, it will ask if you want to enable location-based routing at a site (Lync 2013 only).  See this post for more information.  You will also be prompted to select the network site to apply location-based routing, as well as which class of calls to allow users at that site.
23. 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.

NOTE: If you selected the Simple Ruleset option, then none of this applies, because only a single voice policy that allows all calls is assigned.

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.