SDN:Lync Dialog Manager 2.1

Der Lync Dialog Manager ist im Lync Architekturbild die Komponenten, die von dem Lync Dialog Listener die Daten der verschiedenen Frontend Servern erhält und dann diese Daten zusammenfasst um diese dann an den Netzwerk Controller zu übergeben.

There is an short english version available at SDN Live View

Download

Auch der Lync Dialog Manager ist Teil der Lync SDN API und in folgendem Paket enthalten:

Lync SDN Interface
Version 2.1 http://www.microsoft.com/en-us/download/details.aspx?id=44274

Installation Lync SDN Manager

Die Installation läuft immer mit dem aktuellen Benutzer, stellen Sie sicher, dass dieser Benutzer ausreichende Rechte hat. Zudem muss das .NET 4.5 Framework installiert sein.

Die Installation des Lync Dialog Listeners (LDL) und des Lync SDN Managers (LSM) sind getrennte MSI-Installer, die separat installiert werden müssen. Dass da nicht so viel drin sein kann, macht schon die Größe der Dateien deutlich:

Die Installation des Managers konnte ich sogar auf meinem Windows 7 starten, um die Dialoge zu betrachten. Installiert werden muss es aber schon auf Windows 2008 oder 2012 Servern. Zuerst wird der Zielpfad erfragt. Hier sollten Sie für die Logfiles vielleicht ein passenderes Verzeichnis wählen, z.B. ein unterverzeichnis im Programmpfad (C:\Program Files\Microsoft Lync Server\Microsoft Lync SDN Manager\Log)

Seit der Version 2.1 können Sie nun mehrere Installationsoptionen auswählen.

Wenn ich nur einen einzelnen LDM benötige, dann ist die dritte Option die passende Auswahl. Sobald Sie einen Pool oder eine gemeinsam genutzte Instanz installieren, benötigen Sie einen SQL-Server im Hintergrund, der bei der Installation angegeben werden muss. Der SQL-Server muss bereit vorhanden sind.

Dann erfragt das Setup die URL für den Netzwerk Controller, an den die konsolidierten Daten gesendet werden.

Über den Button "Configure", kann man je nach Subnetz unterschiedliche Backend-Server hinterlegen.

Der durch das Setup installierte Dienst startet automatisch.

Der Manager sammelt die Daten, loggt Sie in einem Verzeichnis, was sie natürlich anpassen sollten und "POST"ed diese dann als XML-Information auf die hinterlegte Webseite. Der Webserver, der hier einfach als "http://networkController/Site" gelistet ist, muss vom Netzwerkanbieter bereit gestellt werden.

Konfiguration

Die erste Konfiguration erfolgte schon durch das Setup. Aber im Programmverzeichnis liegt eine ".CONFIG"

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <appSettings>
    <add key="submituri" value="http://networkController/site"/>
    <add key="backwardcompatibility" value="false"/>
    <add key="clientcertificateid" value=""/>
    <add key="submitqueuelen" value="100"/>
    <add key="calltimeout" value="6:00:00"/> <!-- 6 hours -->
    <add key="invitetimeout" value="0:02:00"/> <!-- 2 min -->
    <add key="qoetimeout" value="0:00:05"/> <!-- 5 secs -->
    <add key="endedtimeout" value="0:01:00"/>  <!-- 1 min -->
  </appSettings>

Die hier hinterlegten Werte scheinen den Manager anzuweisen, Calls nach diesen Zeiten zu entfernen. Anscheinend rechnet Microsoft selbst auch damit, dass der ein oder andere HTTP-Request von einem LDL-Clients vielleicht doch mal verloren geht.

Auch interessant ist der Bereich der "Bindungen". Hier können Sie gut erkennen, dass der Dienst nicht nur auf 9333/http sondern auch auf 9332/https verbinden annehmen wird, zumindest solange ein passendes Computerzertifikat gefunden wird.

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <system.serviceModel>
    <bindings>
      <webHttpBinding>
        <binding name="wsHttpEndpointBinding">
          <security mode="Transport">
            <transport clientCredentialType="Certificate"/>
          </security>
        </binding>
        <binding name="wsHttpEndpointBindingNoCert">
          <security mode="Transport">
            <transport clientCredentialType="None"/>
          </security>
        </binding>
      </webHttpBinding>
    </bindings>
    <services>
      <service name="Microsoft.Rtc.Enlightenment.Hub.LyncHandler" behaviorConfiguration="CustomValidator">
        <endpoint address="http://localhost:9333/LDL" binding="webHttpBinding" behaviorConfiguration="webby" name="ep0" contract="Microsoft.Rtc.Enlightenment.Hub.ILyncHandler"/>
        <endpoint address="https://localhost:9332/LDL" binding="webHttpBinding" bindingConfiguration="wsHttpEndpointBinding" behaviorConfiguration="webby" name="ep1" contract="Microsoft.Rtc.Enlightenment.Hub.ILyncHandler">
          <identity>
            <dns value="ServerSideCert"/>
          </identity>
        </endpoint>
      </service>

Ich habe aber noch nicht versucht den LDL auf HTTPS umzustellen.

Obfuscation

Während bei SDN2.0 die Einstellung zur unkenntlichmachung der SIP-Partner noch beim LDL vorgenommen wurde, ist dies in SDN2.1 nun in den LDM gewändert. Hier finden Sie die Einstellung an folgender Stelle in der XML-Datei

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <loggingConfiguration name="" tracingEnabled="true" defaultCategory="Error">
  <appSettings>
    <add key="hidepii" value="false"/> <!-- Whether to obfuscate user names -->     
  </appSettings>
</configuration>

Setzen Sie hier den "hidepii" auf False, dann werden vom LDM die From/To-Adressen in lesbarer Form an den Netzwerk Controller gesendet.

Monitoring

ähnlich wie der LDL schreibt auch der LDM in ein eigenes Eventlog entsprechende Hinweise auf Fehler und Betrieb.

Aktuell fehlt mit der Netzwerk Controller, so dass ich die entsprechenden Pakete erst dann sinnvoll beschreiben kann.
Die Seite wird weiter geführt.

Performance Counter

Analog zum Lync Dialog Listener füllt auch der Manager ein paar Performance Counter, die eine Überwachung der Funktion erleichtern.

Praktische Werte habe ich hier aber noch nicht zu vermelden

Uplink zum Netzwerk Controller

Damit nicht nur Microsoft sondern auch andere Applikationen ihre Daten an unterschiedliche Controller und Netzwerksysteme übertragen können, bietet sich natürlich ein Standard an. Auf der Seite SDN Grundlagen lesen Sie, dass hierzu die "Northbound"-API von OpenFlow zum Einsatz kommen kann. Wie so oft gibt es aber auch hier immer wieder Dialekte.

Der Lync Dialog Manager überträgt die zusammengefassten Meldungen aller Lync Dialog Listener letztlich zu den angegebenen Netzwerk Controllern, die basierend darauf die aktiven Komponenten umkonfigurieren. Leider habe ich zwar keine passenden Controller aber durch verschiedene Versuche habe ich herausgefunden, dass es sich um einen WebService handelt, an den Lync per HTTP-POST die Daten übermittelt. Dann war es auch nicht mehr schwer mal einen WebService zu schreiben, der die Daten annimmt.

Die Details hierzu habe ich auf SDN - LDM 2 Network beschrieben.

Weitere Links