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
![]()
Step 1. Find the below in your Fiddler trace (will be on left side).
![]()
![]()
![]()
![]()
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.