Lync 911 Location Based Policies Based on Network Site

Lync 2010 introduced Enhanced 911 dialing.  This has been vastly documented and therefore, I will not be blogging on how Enhanced 911 works.  For a great blog post on this, please see the following TechNet blog post from Jens Trier Rasmussen here.

One thing Jens does touch on is using Network Sites for using the Location Policies.  My intent of this blog post is show you how to configure users so their Location Based Policy can change based on what Network Site they are assigned to.  This can be beneficial for both E911 deployments and 911 deployments.  Where it is beneficial in non-E911 deployments is where you want users to always route a local PRI/POTS when they switch Network Sites. This will be beneficial for organizations who will not be deploying Enhanced 911.

Configuration

The first thing we will want to do is get all of our Network Sites and Subnets defined. I have created two scripts for this that will help you automate this process.

• New-CSMultiRegionNetwork.ps1
  • Make a connection to AD and record every AD subnet that exists and its corresponding AD Site
  • Export Data to CSV
  • Allows you to specify Lync Network Regions and their corresponding Lync Central Sites
  • Allows you to assign Location Policies to Sites (Note: The Location Policies need to be created beforehand as the script will not create Location Policies)
  • Allows you to assign Bandwidth Policies to Sites (Note: The Bandwidth Policies need to be created beforehand as the script will not create Bandwidth Policies)
  • Will create the Lync Network Regions and assign them to the corresponding Lync Central Site as defined in the CSV
  • Will create the AD Site in Lync Network Sites
    • Something to note is that AD Sites support non-alphanumeric characters such as a hyphen while Lync Network Sites do not support non-alphanumeric characters.  Because of this, this script will create the Lync Network Site without any non-alphanumeric characters.  It is safe to re-run the script more than once as the script will always take notice that an AD Site with non-alphanumeric characters will match a Lync Network Site with non-alphanumeric characters.  Important: Be sure that you don’t have an AD Site that would match another AD Site if non-alphanumeric characters were to be removed.  An example if you had two AD Sites: One called Site01 and another called Site-01.  When the process to remove non-alphanumeric characters occur, they will both conflict.
    • If any Lync Network Sites are created, the script will pause for 15 seconds to allow the Lync Network Sites to instantiate.  If no Lync Network Sites exist, it will move immediately on to subnets.
    • It will create the Lync Network Subnets and assign them to their corresponding Lync Network Site
    • It will assign the Lync Bandwidth Policies and/or Lync Location Policies as defined in the CSV
• New-CSSingleRegionNetwork.ps1
  • Make a connection to AD and record every AD subnet that exists and its corresponding AD Site
  • Will create the AD Site in Lync Network Sites
    • Something to note is that AD Sites support non-alphanumeric characters such as a hyphen while Lync Network Sites do not support non-alphanumeric characters.  Because of this, this script will create the Lync Network Site without any non-alphanumeric characters.  It is safe to re-run the script more than once as the script will always take notice that an AD Site with non-alphanumeric characters will match a Lync Network Site with non-alphanumeric characters.  Important: Be sure that you don’t have an AD Site that would match another AD Site if non-alphanumeric characters were to be removed.  An example if you had two AD Sites: One called Site01 and another called Site-01.  When the process to remove non-alphanumeric characters occur, they will both conflict.
    • If any Lync Network Sites are created, the script will pause for 15 seconds to allow the Lync Network Sites to instantiate.  If no Lync Network Sites exist, it will move immediately on to subnets.
    • It will create the Lync Network Subnets and assign them to their corresponding Lync Network Site

After creating the network sites with subnets attached, we can see all that data has been imported into Lync.  The client subnet we will be testing on will be 192.168.1.0/24 which is assigned to the Chicago Site.

What we now need to do is create a PSTN Usage which we will be assigning to the Chicago Voice Policy.  This PSTN Usage will be assigned to a 911 route.  That way, my test user will be in the Chicago Voice Policy which will have the 911 PSTN Usage which will allow them to utilize the 911 route.

Go into the Chicago Voice Policy that will be assigned to your test user account. Go ahead and click New under PSTN Usages.

Go ahead and give the PSTN Usage a name.  Because this will be for local 911 routes, give it a prefix of Chicago.  In my example, I name it Chicago-911. Then click New for Associated Routes.

Just like with our PSTN Usage, we’ll want to prefix the 911 route with the site name because the intent of this entire configuration is so users route out a local trunk.  It’s site-based routing.   Our 911 numbers will route out as +911.  I will show you why later.  In our example, the 192.168.1.99 trunk would route our +911 number over to this gateway which is a gateway located in Chicago.

We can now see our Voice Policy for Chicago contains the Chicago-911 PSTN usage.  And the Chicago-911 PSTN usage is assigned to the Chicago-911 voice route.  This is what allows Chicago Voice Policy users to be able to hit the Chicago-911 Route.

Now it’s time to create the Location Policy. You will need to create a user policy.  Site policies will not work for this type of automation.  This Location Policy will be assigned to our Chicago Network site which is what allows the automation to happen.

In our Location Policy, the below configuration is sufficient since we’re not using Enhanced 911.  We’re just leveraging Location Policies that will be assigned to Network Sites so when you hop from one site to another, you’ll get a new Location Policy.  This means you will have one Location Policy for every site.  And the Location Policies for each site will have their local PSTN Usage to ensure when a person goes from one site to another, they’ll get a new Location Policy so if they dial 911, it will use a different PSTN Usage which will route out the local trunk for that site.

The E9-1-1 dial number will automatically have a + added to it when it gets sent to the route.  This is the reason why our route pattern was +911.  The E9-1-1 dial masks, when entered, are automatically normalized to the E9-1-1 dial number.  So for example, if I enter 9911 or 4411, it will automatically normalize to +911.  And if you need multiple dial masks, you can use a semicolon.

Go back to the Site, and specify Location Policy as Chicago-911.  Now, anytime someone who is in this site (192.168.1.0 or 192.168.2.0), will automatically get this Location Policy.

Make sure your user has the Chicago Voice Policy assigned.

Now before logging out, lets take a look at what happens if I try dialing 911.

We see that no normalization has occurred.  But after signing out and back in, we can see that it will now display +911.  That means that the location policy has correctly been applied to the account.  We can also see that the 9911 and 4411 is also working.

That’s all there is to it.  However, what happens to users who happen to fall onto a subnet that happens to not be assigned to a site?  Thankfully, there is a fallback.  In the user properties, assign the user to a Location Policy that is in their home site.  What happens is, if the Network Site they are on has a Location Policy, that Location Policy is handed back to the user.  If they happen to not be assigned to a Network Site due to the subnet they are on not being assigned to a Network Site, they will utilize the Location Policy assigned to their user account. You can see Jens Trier Rasmussen explaining this in this TechNet Post here.  Specifically, Jens calls this out in the “Configuring Location Policy” section.  Jens states the following:

• If the subnet (defined by the cmdlet New-CsNetworkSubnet) is associated with a network site (defined by the cmdlet New-CsNetworkSite) and that network site is associated with a LocationPolicy, this location policy is returned to the client.
• If the subnet is unknown or if the network site isn’t associated with a LocationPolicy, the location policy associated with the user is returned.
• If the user is not associated with a location policy, the global location policy is returned.

Therefore, it is recommended that if my Client User 1 is primarily based in Chicago, assign that user the Chicago Location Policy.  When they travel and they’re  not on a network site, their 911 will still route, even if it’s not a trunk that is local to their current location.  But at least they’ll hit the 911 PSAP who can then ask for the user’s address and route accordingly.  This is where Enhanced 911 would be better.  But if Enhanced 911 is not used, it is very important to make sure all the appropriate subnets are added to the Network Sites so you don’t have to revert to the fallback mechanism and potentially have a user route out of a trunk that is not local.

To assign the Location Policy to the user as part of this fallback mechanism, go into the Users section, open up that users settings, and choose that user’s Location Policy.