Location-Based Routing in the Lync Optimizer

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

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.  Thanks to Greig Sheridan who fixed the script to deal with AD site names that have characters that are invalid for Lync site names (such as underscore).

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" #Remove dashes from site names and replace with underscore $ADSiteName = $SiteObj.Name $ADSiteName = $ADSiteName -replace "-","_" New-CSNetworkSite -NetworkSiteID $ADSiteName -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 $ADSiteName } } #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.