Home > Lync > Lync E911 Deployment

Lync E911 Deployment

I have recently been working with a number of clients that are interested in deploying Enhanced 911 (E911) with Lync Server and there is one thing in common…. They have a lot of questions about the capabilities and functionality. When thinking about how end users will connect their Lync client to the environment we know there will be a couple of different scenarios:

  • A user with a phone at a desk
  • A common area phone
  • A roaming user with a laptop
  • A user with Lync installed on their desktop with only a soft phone

Thankfully, Lync has an answer for each of these scenarios, plus more! There are numerous ways you can automatically set the location of a user, and if you can’t identify their location automatically you can (and should) prompt them to enter their location. Think about a scenario where an employee working from home calls 911 from Lync. The call would be routed out the PSTN at the office. The Caller-ID would exist in the legacy PS-ALI database controlled by your local telco and most likely would not be associated with your home address and your call would get sent to the wrong PSAP.

This is where E911 comes in. With more offices going to a “hoteling” scenario and the significant increase in remote and travelling workforces, tools like Lync need to be smart enough to follow them where they go and work like they did in the office.

The configuration of E911 is not difficult; however, it requires planning in advance and consideration of the following:

  • What detail on location proximity do you need to provide to the emergency responder? Most laws are specifying a range in square feet (ie: 5,000 sq ft).
  • How will you assign an E911 policy to users?
  • Will you have multiple locations with security desks that you would like to inform in the event of an emergency?
  • What will you do in the event the Lync environment or WAN is down when trying to make 911 calls?

In many situations, the answers to these questions are very similar. Many customers want the flexibility to inform a security desk for larger offices, hospital buildings or retail facilities. This notification can be transmitted with a simple IM message indicating the person (or device) that called 911, their location and even the ability to conference in a security officer or security operations center.

The configuration detailed below includes 2 main sites (LA and NY) as well as outlines how a branch office and mobile user would utilize enhanced 911.

Our Lync configuration is a single Enterprise Pool which houses all users in our NY offices. Each branch office has a Survivable Branch Appliance deployed with local PSTN connections for alarm and emergency purposes only. We will be utilizing E911 services provided by 911Enable (Connexon) which at the time that this post was published is the only certified enhanced 911 service provider for Lync. Our network infrastructure consists of LLDP compatible switches and wireless access points.

We will configure the following in Lync:

  • A Location Policy for each site
  • A route for 911 for each site
  • A failover route for 911 for each site
  • A PSTN usage for 911 at each site
  • Location Information Services (LIS)
    • Civic Address
    • Switch Port for LLDP-MED
    • Wireless Access Point BSSID
    • Network Subnets for Lync clients
    • Validate the LIS database Civic addresses
    • A disclaimer for remote users


Lync Routing Configuration

First, we will configure the routes and PSTN usages required to make calls to 911.

Our Routes will be called E911(NY) and E911(LA), shown below is our E911(NY) voice route. The route will match the pattern +911. A normalization rule has been created that will add a + to all numbers dialed that are exactly “911”. In addition, we are suppressing caller ID and supplying a local number that is in the legacy PS-ALI database in case of a failure of 911 enable providing the location information to the PSAP. This will typically be the telephone number of your building security desk if you have one at the location.

Now to the PSTN usage which will reference this route. Our PSTN Usage will be called E911 (NY) and will use the route E911(NY) that we just created.


Since we do not have a global security operations center and our operations have local security offices, we will want to define a location policy per site. This will allow us to send security notifications via IM to the local security desk and to conference in the security desk number. We have already configured our sites in the topology and will be creating the Location Policy for the New York Site in the example below. Note however that we are creating a Location Policy that is scoped at for a User not for the Site. This policy will be assigned later to a Communications Server Network Site which is not the same as the Topology Builder Site, the main reason for this is when a user travels to a different site they will get a Location Policy based on the Network Site they are in (based on their subnet and the configuration of the CsNetworkSite). In the policy, I am requiring users to enter the location if it is not automatically applied by the Lync LIS detection. I am also enabling enhanced emergency services and assigning the E911(NY) PSTN usage to this site. In addition, I am sending a IM message to the security officer (NYSecurity@unplugthepbx.com) and conferencing in the security desk number. The conference URI does not have to be a Lync EV number, it could be any phone and if so should be in the format sip:+1<10digitnumber>@domain.com so it is routable by Lync.


In the event the WAN is out or the Mediation server pool that routes to the 911Enable SIP trunk is unavailable, it will still be necessary to allow users to make 911 calls. In this case, we will need to build a failover Route, PSTN usage, and assign that to a voice policy that gets assigned to a user. The configuration is shown below:

A new route is created called 911Failover that matches the same string as the 911Enable route. The failover route will point to a local gateway or in our case the SBA (Survivable Branch Appliance) gateway component.

Our PSTN usage for failover routing will utilize the route seen below.

The next step is to ensure the route list is ordered properly and has the E911 usage listed above the 911 Failover route. This will ensure that the E911 route will be preferred over the failover route and the failover route will only be used after the E911 route is marked as unavailable.

Location Information Service (LIS) Configuration

There are a number of PowerShell commands that perform various configuration tasks within the LIS. Those commands and some samples are shown below:


The Switch ChassisID and Port number are used in Set-CsLisPort to create an association between a switch port and a location. It can be difficult to identify what information is being provided to a phone via LLDP broadcast messages, but by using network monitor you can view the LLDP packet (even though Windows 7 does not honor LLDP broadcast messages). This will help you identify how the switch manufacturer identifies the switch port id.

I have configured a single switch port with the command:

Set-CsLisPort –ChassisID 3c-4a-92-30-ec-00 –PortId 7 –Description “New York Wired Connections” –Location “New York Wired” – CompanyName “UnplugThePBX” –HouseNumber “12345” –PreDirectional N -StreetName “Cedar” –StreetSuffix “Dr” –City “New York” –State “NY” –PostalCode 98765 –Country US



Lync clients that run on laptops with mobile users and do not typically connect to a wired network can receive location information based on the wireless access point they are connected to. This information is entered into the LIS is based on the access point BSSID. To configure wireless provisioning the following command can be used:

Set-CsLisWirelessAccessPoint -BSSID 00-19-5b-7f-77-0D –Description “New York Wireless Connections 3rd Floor” –Location “New York 3rd Floor Wireless” – CompanyName “UnplugThePBX” –HouseNumber “12345” –PreDirectional N -StreetName “Cedar” –StreetSuffix “Dr” –City “New York” –State “NY” –PostalCode 98765 –Country US



Lync softphone clients (non IP phones) cannot use LLDP-MED for location provisioning. Therefore we need to identify a way to determine their location when they are connected to the corporate network and not to a wireless base station. To do this, we will utilize network subnets which generally are consolidated to a floor, building wing, department, or other location. To configure a subnet:

Set-CsLisSubnet –Subnet -–Description “New York” –Location “New York 1st Floor” – CompanyName “UnplugThePBX” –HouseNumber “12345” –PreDirectional N -StreetName “Cedar” –StreetSuffix “Dr” –City “New York” –State “NY” –PostalCode 98765 –Country US



Lync requires the addresses entered to the LIS are validated against the 3rd party provider’s Master Street Address Guide to ensure the correct address is provided to the PSAP and the correct PSAP is contacted for the address. To do so, the E911 provider will provide a web service URL and certificate used to authenticate against the provider’s web service. This is done by completing the following:

Set-CsLisProvider –ServiceProviderName “911 Enable” –ValidationServiceURL “https://www.911enable.com/ocsvalidation&#8221; –CertFileName “C:\temp\911enablevalidation.pfx”



For users that are remote, users can be prompted to enter their address. Many times it also makes sense to provide a disclaimer to inform them of what should be expected when they call 911. We talk with many customers who want remote employees to use their personal phone, hotel phone, or mobile phone to dial 911 in the event of an emergency and avoid using their Lync client. An optional cmdlet provides the ability to display a global disclaimer to users who cannot have their location automatically detected. The example below directs users to use their personal cell phone in the event of an emergency.

New-CSEnhancedEmergencyServiceDisclaimer –Identity Global –Body “Please use your personal cell phone to dial 911 in the event of an emergency”

Note: The disclaimer message is configured globally. There is currently no ability to provide disclaimers per site or per pool.


Next up – you will need to make sure you have network sites configured that unite your network regions to the appropriate location policy. You will have to create a network region, network site, and network subnet that will be associated with the location policy that we created previously named “New York City”. We will first create a Network Site as shown below:

New-CsNetworkSite –SiteID “NY1” –NetworkRegionID “NorthAmerica” -LocationPolicy “New York Location Policy”


After creating the site we will now assign subnets to that site:

New-CsNetworkSubnet –SubnetID “” –Maskbits “24” –NetworkSiteID “NY1”



Now on to the important part – there are a few known issues or config items that you will want to address when configuring E911:

  1. The Global Trunk Group configuration in Lync does not send PIDIFLO information by default. This prevents location information from being sent to the E911 provider. To enable this for the Global trunk run Set-TrunkConfiguration –EnablePIDIFLOSupport $True
  2. IP Phones do not use the subnet as a fallback if the switch and port information is provided to the phone via LLDP-MED, but is not found in the LIS
  3. Don’t forget to run Publish-CsLisConfiguration after each change to the LIS
  4. Addresses not validated by the Master Street Address Guide (MSAG) will not be used by clients
  5. Analog devices do not use Lync LIS, numbers will have to be added to the Legacy PS-ALI database the provider maintains.

Big thanks to Ryan Gates for your great work getting reviewing, validating in our lab and proving out the solution!

Categories: Lync
  1. July 7, 2011 at 1:01 pm

    Hey Mark, great post – I have a few notes here:

    You shouldn’t need to order the routes. As long as a Location Policy has Emergency Services enabled it’s automatically placed as the first PSTN usage in the voice policy. Your failback route will be based on the order of PSTN usages within the user’s voice policy, not how the route list page is ordered.

    And as long as you have a dial mask there the 911 and 9911 numbers will automatically normalize to add a + with no dial plan rules required.

    I’d also recommend associating a tagged (user) location policy object to a specific network definition site as opposed to creating policies associated Lync Topology Builder site. In your scenario if a user homed to a NY pool travels to SF they would still be placing calls to NY 911. If you used a tagged location policy attached to the SF Network Site the client can send its 911 call to a local gateway instead. It would get the tagged policy from SF based on its IP address (associated with the SF site) it sends when it signs in. That way you can accommodate users moving between offices and still send 911 through the local office they are in.

    • July 7, 2011 at 7:22 pm

      Thanks Tom! I updated my post to point out that while in the lab we normalized service codes to add the + that this is not necessary. I guess I just kept it this way because my screenshots were already taken 🙂

      Also – Great point on the route list – I was not sure about the PSTN usage ordering and we didn’t test that part – so great advice! Not sure if I understand completely the tagged location policy object. Is this for fallback 911 only?

      • July 8, 2011 at 3:04 am

        So to be clear, the only dial strings that do not require dial plan normalization are the numbers you add as emergency number masks in a location policy. So while 911 and 9911 will normalize automatically, 411 would not without a dial plan rule.

        As for the 911 usages, keep in mind there are 3 places “Sites” show up:
        Topology Builder
        CSCP/Management Shell

        You’re scoping the policy to a site in Topology builder, but you should be associating it to a site you set up in CSCP. By assigning a location policy to a Topology Builder site you’re restricting users to a specific 911 usage.

        Say you have 2 offices with PSTN drop outs. Let’s assume a user is homed to pool in Topology Builder Site New York. The location policy plays out like this in your scenario:

        Lync client signs in
        Client gets the location policy scoped to the Topology Builder site (since this is the most specific to their pool)
        This location policy includes the PSTN Usage for Emergency Services in NY
        Client calls 911 and call routes out NY Emergency.

        BUT, now assume that user travels to LA. If they dial 911 *it will still use the NY PSTN Usage*. This is because the user is homed to the NY pool, which has a location policy scoped to the site it belongs to. The subnet or physical location of the user has no bearing here because of the site policy you created.

        What I am suggesting is this:
        Define your network sites and subnets (within CSCP)
        Create a location policy (user/tagged type)
        Associate the location policy with a CSCP network site

        This way you get this:
        Lync client signs in
        It sends its network subnet info to the server – “Hey, I’m on THIS subnet”
        The server will look up that subnet from your CSCP definition and determine which CSCP site it’s associated with
        Server returns the location policy associated to that CSCP site, NOT the Topology Builder site.

        So a NY pool user traveling to LA now gets assigned a location policy which includes a PSTN usage for Emergency Services in LA instead of NY.

        Hope that clears it up.

    • David
      April 20, 2012 at 9:24 pm

      Hi Tom or Mark,

      I think you have to order the routes correctly because in the tagged CSCP location policy was a PSTN usage assigned within that policy.

      You would create two emergency routes as Mark showed, ordered correctly, but using the same PSTN usage for both routes associated in the location policy. Therefore during a emergency call if the first route fails, it would choose another route based on the PSTN usage defined in the CSCP network site. I assume the user’s default voice policy is not used during an emergency call because the CSCP location policy is used.

  2. July 11, 2011 at 1:14 pm

    Ahh – I see what I did wrong – I took a screenshot that showed me creating a Site Location Policy which was just to get a screenshot where I was supposed to take a screenshot of a User level Location Policy. Fixing that now!

  1. July 10, 2011 at 6:59 pm

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: