LIS - Location Information Service

Hinweis:
LIS unterstützt noch nicht IPv6. Der Client versucht also immer anhand einer IPv4-Adressen den Standort zu ermitteln, was in einer Dual-Stack Konfiguration auch gehen sollte. In einer "Native IPv6-Umgebung" aber nicht.

Ihnen ist sicher schon aufgefallen, dass Sie im Lync Client ihren Standort hinterlegen können. Dabei können Sie sogar selbst die Standorte benennen. Der Lync Communicator merkt sich die Eingaben und ordnet diese anhand der MAC-Adresse des Default Gateway wieder zu.

Das ist eine Möglichkeit, wie ein Mitarbeiter manuell seinen Standort pflegen kann, z.B. wenn er zuhause oder im Hotel unterwegs ist. Die Informationen werden in einer binären Datei im Benutzerprofil abgespeichert, die aber dennoch eingesehen werden kann

C:\\AppData\Local\Microsoft\Communicator\sip_frank.carius@netatwork.de\PersonalLISDB.cache

Mit etwas Phantasie können Sie die Standorte und auch die MAC-Adressen erkennen.  Innerhalb von Firmennetzwerken ist dies aber nicht wünschenswert. Hier kann ein Administrator die Informationen vorgeben.

Die Pflege der Standorts ist in den USA für Notrufe (911) wichtig. Siehe auch Notruf/LIS.

Lync LIS

Die LIST-Datenbank in Lync muss ein Administrator erst einmal mit Leben füllen.

Um die LIS-Konfiguration zu ändern müssen Sie Mitglied der Gruppe "CSLocationAdministrator" sein

Die Mühe ist aktuell nur für Installationen in den USA erforderlich. Und selbst da ist dies nur relevant, wenn Teilnehmer an verschiedenen Standorten sitzen und einen zentralen Übergangspunkt nutzt. Wenn Sie pro Filiale in den USA auch ein eigenes "lokales Gateway" per T1 angebunden haben, dann sieht der Carrier auch ihren Anschluss und meldet die Daten weiter. Fragen Sie dazu am besten ihren Provider.
Interessanter wird dies beim Einsatz von SIP-Trunks, wo der Telko-Provider nicht mehr "lokal" sitzen muss.

Das erfolgt alles erst mal nur über die PowerShell:

  • Set-CsLisLocation
  • Set-CsLisPort
  • Set-CsLisSwitch
  • Set-CsLisSubnet
  • Set-CsLisWirelessAccessPoint

z.B. für Net at Work wäre das:

Set-csLisSubnet `
   -Subnet 10.164.25.0 `
   -Description "Zentrale" `
   -Location "Paderborn" `
   -CompanyName "Net at Work GmbH" `
   -HouseNumber 32 `
   -HouseNumberSuffix "" `
   -PreDirectional "" `
   -StreetName "Am Hoppenhof 32" `
   -StreetSuffix "" `
   -PostDirectional "" `
   -City "Paderborn" `
   -State "" `
   -PostalCode 33106 `
   -Country DE

Wer natürlich viele Subnetze hat, hat hier entsprechend etwas Arbeit.

Achtung
Set-CsLisSubnet setzt das angegebene Subnetz auf die Werte der Parameter. Bestehende Werte werden überschrieben. Wurde ein Wert nicht angegeben, dann ist der danach leer !!

Subnetting und Supernetting.
Leider kann man bei dem Netz keine Netzmaske mit angeben. Wer also Supernetting betreibt, muss dann eben 4 oder 8 oder 16 Einträge anlegen. Der Client fragt einfach gezielt nach seiner IP-Adresse und den gängigen Netzmasken. Das gleiche gilt übrigens für Media Bypass.

Die Daten liegen dann auf dem Lync-Server vor. Sie können das ebenfalls mit der PowerShell überprüfen:

Get-CsLisCivicAddress

All diese Befehle beziehen sich aber auf die gleiche Datenbank, die sie "Read-Only" auch problemlos anzeigen können.

Wenn Sie nun glauben, die soeben eingegebenen Daten würden sofort sichtbar werden, dann haben Sie sich getäuscht. Die Pflege der Daten per PowerShell füllt nur die LIS-Datenbank, die aber eigentlich gar nicht genutzt wird.

LIS publizieren

Für den Client und alle Lync-Server ist stattdessen das LIS-Dokument in der XDS-Datenbank relevant. Dort müssen die Daten aber erst mal hinein. Als Administrator müssen Sie dies durch folgenden Befehl ausführen

Publish-CsLisConfiguration

Eine große Bildschirmausgabe dürfen Sie aber nicht erwarten. Letztlich liest das Commandlet die LIS-Datenbank aus, erstellt eine XML-Datei und legt diese in der XDS-Datenbank ab. Über die Lync Replikation wird diese Information dann auf alle anderen Server verteilt und steht dann den Clients zur Verfügung.

Client Policy

Jeder Client fragt bei der Anmeldung am Lync Server nach, wo er sich gerade befindet. Diese optionale Funktion können Sie auch per Client-Richtlinie verändern. Dies geht z.B. über das Control Panel:

Neben einer globalen Einstellung können Sie natürlich auch weitere Richtlinien erstellen und an Netzwerke oder Benutzer verbinden

Je nach Einstellung verhält sich der Client dann auch anders.

Einstellung Bild Bedeutung

Nicht erforderlich

Die Eingabe eines Standorts ist freiwillig. Manuell lokal gepflegte Standorte werden automatisch übernommen

Required

Der Benutzer wird an einem neuen Standort nach den Daten gefragt, kann diese Anfrage aber wegklicken

Disclaimer

Der Benutzer wird ebenfalls gefragt aber wenn er die Angaben nicht vornimmt, wird ein definierter Hinweistext eingeblendet.

Speziell bei der Einstellung "Disclaimer" kann der Anwender zwar das kleine rote "x" drücken, aber bekommt dann den Standard-Disclaimer bzw. den von ihnen definierten Text angezeigt:

Wenn der Anwender dann den Button "Ort festlegen" drückt, dann kommt die folgende Maske.

Ein Europe und besonders in Deutschland sind diese Einstellungen aktuell noch nicht erforderlich. In den USA werden diese Daten u.a. für die Meldung an die Notrufzentrale übermittelt. Der Disponent in der Notrufzentrale kann die Adresse sehen und auch erkennen, ob sie von einem System verifiziert übermittelt wurde oder der die aktuelle Position nachfragen muss.

Die Frage des Clients

Wer etwas tiefer in die Anfrage des Clients schauen will, kann dies mit dem "Lync Server 2010 Logging Tool" tun (Snooper).

Sie sollten dann auf dem Server die eingehenden Anfragen ("GetLocationsRequest") die Übereinstimmung mit einem Eintrag in ihrer Datenbank und die entsprechende Antwort ("GetLocationsResponse") sehen.

<GetLocationsRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<Entity>sip:frank.carius@lyncme.test</Entity>
<RSSI>0</RSSI>
<MAC>00-24-D7-17-93-16</MAC>
<SubnetID>192.168.103.0</SubnetID>
<IP>192.168.103.23</IP>
</GetLocationsRequest>

Der Webservice hat mir dann eine Antwort gesendet, die meine Adressen ausgegeben hat.

LIS über Edge ?

Wenn Anwender "im Internet" draussen unterwegs sind, dann macht es natürlich nur bedingt Sinn, einen Standort des Clients automatisch zu ermitteln. Es gibt einfach viel zu viele unstimmigkeiten

  • Der SoHo Switch hat kein LLDP
    Also kann ich als Admin über den Weg dem Client keine Information über seinen Standort geben
  • Jedes Heimnetz ist fast gleich
    Wenn 50% aller DSL-Router von AVM sind und alle intern die 192.168.178.x vergeben, dann ist die IP-Adresse kein guter Indikator für den Standort. Und die MAC-Adressen des Default Routers möchte ich als Administrator auch nicht pflegen
  • Externe IP ist dynamisch
    Es hilft auch nicht über SIP die vom IP-Adresse zu erfassen, die der Client per NAT extern bekommt. Bei den meisten DSL-Anschlüssen ist die Adresse alle 24h eine andere. Bei UMTS-Verbindungen versteckt sich ein Client oft sogar hinter einen ganzen Pool von IP-Adressen

Aber selbst wenn es so einen Weg gäbe, so kann das zumindest mit Lync 2013 nicht funktionieren, da die LIS-Services (WebService) auf der "External Web Site" gar nicht verfügbar sind. Über die normale Veröffentlichung ist diese Seite also gar nicht zu erreichen.

Ein Anwender kann also maximal manuell lokal seinen Standort eintragen, der dann übermittelt wird. Er wird lokal in der Datei PersonalLISDB.cache im SIP Profilordner gespeichert. Bei mir ist das

C:\\AppData\Local\Microsoft\Office\15.0\Lync\sip_frank.carius@netatwork.de\PersonalLISDB.cache

Die Datei ist aber binär. Per Notepad kann man erahnen was darin steht aber das Format ist nicht offen gelegt.

Lync und VPN / Home Office

Auch wenn der Einsatz von VoIP über VPN nur bedingt geeignet ist, kann es natürlich passieren, dass ein Anwender sich z.B.: per VPN einwählt und eine IP-Adresse bekommt. Wer aber so ein VPN mal genauer anschaut, wird oft ein sehr kleinen "Subnetz" sehen. Bei Windows-VPN ist der Client quasi alleine in seinem Tunnel. Das zeigt sich dann auch bei der LIS-Abfrage an den Server, wie sich per Snooper oder im Client Log ersehen lässt:

GetLocationsRequest:[
<?xml version="1.0" encoding="utf-16"?>
  <GetLocationsRequest xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <Entity>sip:User1@msxfaq.net</Entity>
  <RSSI>0</RSSI>
  <MAC>ab-cd-ef-01-02-03</MAC>
  <SubnetID>192.168.99.8</SubnetID>
  <IP>192.168.99.8</IP>
</GetLocationsRequest>
] 

Das "Subnetz" hat hier keine 192.168.88.0 als Netzwerk, sondern wirklich genau die eine Adresse. Wer also per LIS auch VPN-Benutzer bedienen will, darf in dem Beispiel für jede IP-Adresse ein LIS-Subnetz anlegen.

Andererseits darf man schon mal hinterfragen, welchen Sinn das denn hat, denn die Einwahl per VPN ist in den meisten Fällen sowieso "mobil" und damit kann LIS dem Teilnehmer oder der IP-Adresse auch nicht viel mehr mitteilen als ein "Du bist im VPN". Insofern macht es wenig Sinn z.B. IP-Adressen im Internet oder die privaten IP-Adressen "zuhause" im LIS zu pflegen.

Weitere Links