Lync Location Information Services / Client Request & Response

I am preparing for a meeting to outline what Lync can do for E911.  Being the visual learner, I wanted to show how the Lync client asks for Location Information Services and where the data is stored on each Lync Front End / Edge.

What is Lync Location Information Services (LIS) and where is it stored?  
Essentially LIS is a wire-map of your network that is stored in a database.  This database can be populated with things like subnets, Wi-FI AP’s, switches, and ports to name a few.  Why is this useful?  Well, you can configure your wiremap/LIS to say if a client has IP X, this mean they are in building X and then provide the Lync client this info that it can use when an end user dials 911.  Essential this data will be sent down your E911 sip trunk and based upon the Civic Address sent, your E911 provider will route to the appropriate Public Safety Answering Point (PSAP).  Remember, if you are rolling out E911, you MUST have a dedicated E911 trunk….this blog section will not go into E911 but i may do one later.

So, where is LIS stored.  There is a database that is stored on the backend CMS called LIS.  When you run commands such as set-cslissubnet with all the available parameters, the data is first committed to the LIS database.  But if the data only lived in the LIS database, this would mean there would only be one copy of the info (thus making the backend CMS a failure point).  See for yourself, open up a lync front end RTCLocal database or a lync backend database (NON CMS) and see if you can find a LIS database….Trust me..it’s not there.  I looked.

The next question is how does LIS get replicated around to all servers.  The first command (set-cslissubnet) writes the data to the LIS database but there is another command that MUST be ran to commit the data to the topology (and thus move it into the CMS).  Note…The CMS database is actually called XDS.  The command that moves the data from LIS to the XDS is publish-cslisconfiguration.  Now that we have ran this, the LIS info is now in the XDS database which of course is replicated around.

At this point you can run debug-cslisconfiguration and you can then see all the info published.  Note that the debug-cslisconfiguration command ONLY works after you have actually ran the publish-cslisconfiguration

Myself being curious I wanted to see the LIS data on each front end so I opened up SQL Mgmt studio, hooked into the RTCLocal instance, XDS database, and started looking around.  To my surprise there was nothing LIS related…..so where is it actually stored….

Within the XDS database there is a table called dbo.item.  If you right click that and select top 1000 rows (Please use caution when opening this up as to NOT alter any of the data) you’ll see SQL mgmt studio spit out data in the right hand side.  Find the one that says “LocationInformationSettings”

If you click on this it will open up an XML file that looks like this

The highlighted above is an encoded version of what is populated in LIS.  Because you see this, you know you have published LIS.  At this point if you want to see what it looks like in a more human readable version you can run the debug-cslisconfiguration and it will output what you have in LIS.

Lync Client Requesting and Receiving Location Info:
As usual, I exited my Lync client, deleted my Ucappi log file, fired up the lync client, waited till my client showed location, opened snooper, and started to inspect the new Ucappi log (I mean everything is in the Ucappi log…right???).  Low and behold I could not find ANYTHING related to LIS within the Ucappi log.  I then remembered that LIS is a web service hanging off each Front End

So next I decided to fire up Fiddler and see if i could capture the data that way.  Sure enough the Lync Client does a “GetLocationRequest” and “GetLocationResponse”…..lets see it

Step 1.  Find the below in your Fiddler trace (will be on left  side).

Step 2. On the right then click “Inspectors” and “XML” and you’ll see the below…this is the GetLocationRequest
Step 3.  Again on the right you’ll see the below with is the GetLocationResponse
Notice the TimeStamp in the above.  I started thinking about why that would be included.  If you remember with location policies you can set how often a client asks for locations.  By default it’s 4 hours.  You can see this by running the get-cslocationpolicy commandlet.  So after i put that together, I now understood why this was not in the tracing logs.  Most if not everything configuration wise for the Lync client is done during inband provisioning (thus at client logon).  For clients to get new settings you will need them to sign out and sign back in (thus become re-inband provisioned).  So how would you tell a client to re-check back in….you make it web based and not done during inband provisioning.
Hope this helps….I learned a lot through this process.

8 thoughts on “Lync Location Information Services / Client Request & Response

  1. Great article, but I hope someone is still looking at comments as I have a question: How does the client know which info in the LIS to use?

    In our environment, we routinely import csv files that contain switch port mapping info (ChassisID (i.e. switch IP), PortID (gi1/0/14, etc…), Description, Location, CompanyName, HouseNumber, HouseNumberSuffix, PreDirectional, StreetName, StreetSuffix, PostDirectional, City, State, PostalCode, Country). A typical line of data imported would look something like this: 192.168.1.17, gi1/0/17,MARQ-218-CLR, MARQ-306, Contoso, 225, S, Mulberry, St, , Beverly Hills, CA, 90210, US.

    So, when a client logs on, how does it ‘know’ which line in the LIS db to use for that client? Is it able to somehow detect what switch it is on (via the switch’s IP address) and which port it is connected to and then find that info in the LIS db?

    Like

    • Hi David,
      For a client to be able to detect the Switch Port it is on the operating system must support LLDP. Windows started supporting this i believe with Windows 10. VVX phones have been supporting LLDP for sometime now so if you are using Port info to define locations then your VVX phones are good to go but any Windows 7 and below client will not be able to received the LLDP info from the switch.

      hope this helps. If you need any more info please respond…happy to give additional info.

      Like

      • Thanks, that does help me understand the process better. However, is there any way to override this process? In our environment, we are noticing that if a client cannot find a port mapping, it is displaying the switch mapping (if there is one). Not all our ports are mapped but only for specific users with unified messaging. So, clients without a port mapped are getting location for the switch they are connected to displayed, which could be in a different building and/or floor. Users are able to manually change this, but must reset it every time they need to reboot their client or phone. We would like to override this somehow so that if no port is mapped, then either nothing is displayed or some default info is displayed.

        Like

  2. HI David,
    The behavior you are seeing is the expected behavior and i do not believe there is a way to override. If you do not want to provide the mapping of the switch chassis, then you will need to remove and add subnet mapping. It is important to work with your networking team to tell them what you need. When we rolled out E911 we met with our networking team and told them we could not have any subnets that were spread between civic addresses. If you have subnets that are different floors that’s OK, just know you can not populate the “Location” with anything that indicates a given floor and thus all you would be providing is the civic address of the building.

    You also mentioned that users could manually put in their address. The act of doing this i believe when 911 is called and should you have an E911 provider, when 911 is dialed and sent to your E911 provider, it would contain the MSAGVALID flag to False. This would cause the call not to route to the local PSAP but would still route to a National Relay center for address validation.

    Also note that if your end users are on laptops, in the morning when they are docked, the client will sign in and leverage the physical NIC to get its address. Now the client has the location and it has 2 IP’s (Physical and wireless). Should that staff undock, got to a meeting, this would cause the client to lose it’s connection to the FE and would re-register with it’s Wireles address. When the user re-docks, the client will NOT re-establish the connection over the physical address but would still use it’s Wireless address. The only way to tell the client to pull location off the physical nic is to turn of wireless, and thus force the client to re-connect with the physical address.

    Another note is to NEVER populate VPN ranges into LIS. This can be potentially deadly as when i’m working from home, i would want location to say i’m at the office.

    Hope this helps.

    Like

    • Thanks for the response. I should mention that I incorrectly stated that users were having to manually set their locations on their client OR phone. This is incorrect. They are only having to reset it on their client because the users having the issue are those NOT using unified communication.

      See, not everyone in our environment uses Skype with VOIP. But the ones who do need their ports mapped for e911. Thus, we get situations were a switch is mapped because one or two people connected to it need it mapped for e911, along with the ports they are connected to on that switch. But other people who don’t have VOIP don’t need their ports mapped (it would be too costly at this point to map every port on every switch, so we only do it as needed). So, it appears the Skype client for those without VOIP is still checking for a port mapping, not finding any info, and just taking whatever location the switch itself is mapped to.

      The short of it is that these incorrect location mappings aren’t affecting e911 as the people it affects don’t have VOIP phones. Still, we get complaints–people still want their location to show correctly.

      Thanks for the advice on not populating VPN ranges. Luckily, we aren’t doing that but it is good to keep in mind for future reference.

      Like

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 )

Twitter picture

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

Facebook photo

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

Google+ photo

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

Connecting to %s