Skype for Business SDN 2.4

Anfang März 2016 hat Microsoft eine neue Version der SDN-Tools veröffentlicht. Es wurde aber mehr getan, als nur im Namen aus "Lync" ein "Skype for Business" zu machen. So gibt es Module zur Steuerung per Powershell. Das geht sogar soweit, dass nur der der LDL bei der Installation konfiguriert werden kann. Der LDM hingegen hat seine GUI beim Setup verloren und wird per Powershell oder Kommandozeile konfiguriert.

Was ist neu ?

Auf den ersten Blick hat sich nicht viel geändert. Aber Microsoft entwickelt weiter und diesmal hält auch die Dokumentation schritt. Es gibt nicht nur ein Dokument mit den Änderungen sondern auch die API selbst wird endlich etwas besser offengelegt. Dies gilt zumindest halbwegs für die XML-Strukturen. Wie genau LDL, LDM und SDN Controller miteinander kommunizieren ist noch nicht beschrieben. Das habe ich hier vor längerer Zeit schon mit SDN2.1 erledigt. Aber ein Absatz finde ich sehr interessant:

„Skype for Business service providers and customers can use the Skype for Business SDN Interface to obtain call and quality data about the states of audio, video and app-sharing streams produced by Lync and Skype for Business clients on the network. The SDN Interface relies on the Dialog Listener component to capture call and quality data and then dispatches the captured data to the SDN Manager to process the raw data. The processed and aggregated data is then sent to subscribers, (for example, network management system, network controllers, or IT administration tools), which can in turn correlate the data with their own observations from the network, readjust policies, or reallocate network resources dynamically to improve the service quality
Quelle: https://msdn.microsoft.com/en-us/library/office/dn785190(v=office.16).aspx

Ich interpretiere das so, dass die Ausgabe des LDM an die "Subscriber" durchaus offen für allerlei andere Ziele ist.

Das XML-Schema für die Meldungen wurde schon für zukünftige Angaben erweitert, z.B. um den Tenant zu enthalten. Ich könnte mir vorstellen, dass zukünftig so vielleicht QoE-Daten in einem Office 365 Dashboard zugänglich gemacht werden. Ein integriertes Auditing loggt nun im Eventlog alle Konfigurationsänderungen in einem eigenen Eventlog und InCallQoE für Skype for Business 2016 Clients wird unterstützt und auch automatisch aktiviert.

Per Default werden auch weiterhin alle SIP-Adressen, Namen und Rufnummern mit einem Standard-Key unkenntlich gemacht.
wer allerdings eine Liste der SIP-Adressen hat, kann über den gleichen Weg den immer identischen unkenntlichen String ermitteln und so doch die Identitäten auflösen.
Auf dem Grund kann nun pro Subscriber (also Ziel an das der LDM die Daten sendet) ein eigener Key definiert werden.
Voraussetzung ist natürlich, das die Einstellung des Manager mit "hidepii=true"" auch aktiv ist.

Download

SDN 2.4 Download
https://www.microsoft.com/en-us/download/details.aspx?id=51195

Einrichtung

Die Installation von SDN 2.4 unterscheidet sich kaum von der Installation der früheren Versionen. Es gibt ein MSI-File für den Dialog Listener, der auf jedem Frontend installiert werden muss und die Daten per MSPL abgreift. Ein zweites MSI-File ist der Dialog Manager, der die Informationen der verteilten Listener annimmt und an die Subscriber weiter gibt. Es können zur Verfügbarkeit mehrere Manager auf verschiedenen Servern installiert werden, die die gleiche SQL-Datenbank oder REDIS-Datenbank nutzen. Aber so umfangreich soll es erst mal nicht werden. Die Installation erfolgt in wenigen Schritten und folgende Reihenfolge hat sich bei mir bewährt.

Einrichtungsphase Erledgit

Installation Dialog Manager

Ich habe mir angewöhnt, zuerst den Dialog Manager auf dem einen oder mehreren Servern zu installieren. Bei der Installation werden neben Lizenzvereinbarungen zwei Entscheidungen gefällt:

Achtung: Starten Sie die Installation unbedingt als Administrator.

  • Zielpfad der Installation

    Achten Sie hier auf den Pfad für die Debug Logs. Ich finde es erschreckend, dass Microsoft dazu das Temp-Verzeichnis des aktuell bei der Installation angemeldeten Benutzers nimmt. Darauf kann der Dienst sicher später nicht zugreifen. Ich ändere diesen Pfad nach "C:\ProgamData" oder zu einem Unterverzeichnis im Programverzeichnis.
  • Datenbank
    Im nächsten Schritt ist eine Datenbank auszuwählen, wenn sie mehrere LDM-Instanzen als Verbund betreiben wollen.

    Auch hier beschränke ich mit bei mir auf eine "Single Installation", ohne SQL oder REDIS. Diese beiden Datenbankoptionen sind in größeren Umgebungen mit entsprechenden HA-Anforderungen natürlich gerechtfertig.

Der oder die Server bekommen einen Poolname und auf den Servern wird ein Dienst installiert der auf Port 9333 lauscht. Dies Information ist wichtig, da bei der späteren Konfiguration immer wieder der SDNPoolName anzugeben ist. Der ist dann z.B.

http://servername.domain.tls:9333/Settings
http://localhost:9333/Settings

Merken Sie sich diese URL am besten für den späteren Einsatz. Eine weitere Konfiguration bei der Installation findet nicht statt.

Es ist nicht erforderlich, die Listener von Hand zu addieren. Die kommen alleine dazu

 

Installation Dialog Listener

Nachdem der Dialogmanager betriebsbereit ist, können Sie dann die Dialog Listener auf den Frontend Servern installieren.

Achtung: Starten Sie die Installation unbedingt als Administrator.

  • Zielpfad
    Auch bei der Installation der Listener werden Sie nach den Zielpfaden gefragt, die auch hier wieder anzupassen sind.
  • Parametrisierung des LDM
    Im nächsten Dialog wird die URL zum Dialog Manager angegeben. Der Einsatz von "Localhost" funktioniert natürlich nur, wenn LDL und LDM auf dem gleichen Computer laufen
  • Authentifizierung
    Optional kann nun noch ein Zertifikat ausgewählt werden, welches die Kommunikation zwischen LDL und LDM absichert

    Dies ist durchaus wichtig, wenn der LDM-Service nicht durch Firewalls entsprechend gegen "Fremdeinspeisungen" gesichert ist. Die API ist recht einfach und so könnte ein Schadcode sich eine Autobahn anfordern oder das Netzwerk nachhaltig stören.
  • Dienst Einstellungen
    Beim LDL können Sie auswählen, mit welcher Identität der Dienst gestartet wird

Nach der Installation startet der Dienst automatisch. Der Skype for Business Server selbst muss nicht neu gestartet werden und es gibt auch keine Betriebsunterbrechung. Der LDL wird auch automatisch schon im LDM eingetragen.

Das automatische Eintragen ist natürlich eine Lücke im Sicherheitssystem. Das kann aber gestopft werden, indem Sie den LDM entsprechend auf "Sicher" stellen. Dann müssen die LDL-Instanzen mit einem Zertifikat des Computers sich ausweisen. Für den Anfang aber verzichte ich darauf.

 

Konfiguration und Kontrolle des LDM

Die Konfiguration des LDL erfolgt schon bei der Installation und der LDM bekommt die LDL-Instanzen bei der Installation schon mit. Dennoch gibt es einige Einstellungen des LDM, die nun gemacht werden können. Dazu ist nun natürlich die SDN Powershell erforderlich. Alle Änderungen in der Konfiguration werden

 

PII-Obfuscation abschalten

Per Default macht LDM die SIP-Adressen und Rufnummern unkenntlich. Da ich mit SDN aber etwas mehr als "nur Switches" steuern will, möchte ich die Informationen in verwertbarer Form haben.

#Auslesen der Konfiguration
([xml](Get-CsSdnManager -SdnPoolUri http://localhost:9333/Settings )).configuration.parameter | ?{$_.key -eq "hidepii"}
 
key                                     #text
---                                     -----
hidepii                                 True
 
# oder 
(Get-CsSdnManager http://localhost:9333/Settings | select-xml "/Configuration/parameter[@key='hidepii']").node."#text"
True
 
# Setzen des Werts auf keine obfuscation
Set-CsSdnManagerParameter -SdnPoolUri http://localhost:9333/Settings -Parameter hidepii -Value False

Durch die Umstellung auf "False" werden die Daten nicht mehr unkenntlich gemacht.

 

Subscriber einrichten

Noch weiß der LDM nicht, wohin mit den Daten. Dazu ist die Einrichtung eines Subscribers erforderlich. Ein Subscriber ist ein Webserver, der vom LDM per HTTP-POST angesprochen werden kann.

Diese Komponente ist NICHT Bestandteil des SDN-Pakets sondern wird durch das Netzwerk bereit gestellt. Mit der Kenntnis um die API kann ich aber natürlich auch die Daten an "meinen" "Powershell" SDN-Controller senden. Dazu später mehr.

 Die Einrichtung als auch die Parametrisierung erfolgt per Powershell:

# Addieren eines neuen SDN Subscribers
Add-CsSdnSubscriber `
   -SdnPoolUri http://localhost:9333/Settings `
   -Identifier Subscriber1

Bei der Anlage des Subscribers ist keine weitere Konfiguration möglich. Wenn Sie sich aber die Konfiguration dann anschauen, finden Sie viele einstellbare Parameter

# Anzeige des gerade angelegten 
get-CsSdnSubscriber `
   -SdnPoolUri http://localhost:9333/Settings `
   -Identifier Subscriber1

<Configuration Version="2.0" culture="en-US" LastModified="2016-03-03T10:14:16.9565768Z">
  <Configuration Version="2.0" culture="en-US" Kind="Subscriber" Identifier="Subscriber1" LastModified="2016-03-03T10:14:16.9565768Z">
    <parameter key="submituri">http://localhost:9333/Log/poststuffhere</parameter>
    <parameter key="outputschema">D</parameter>
    <parameter key="clientcertificateid">
    </parameter>
    <parameter key="domainfilters">
    </parameter>
    <parameter key="subnetfilters">
    </parameter>
    <parameter key="tenantfilters">
    </parameter>
    <parameter key="trunkfilters">
    </parameter>
    <parameter key="quality">True</parameter>
    <parameter key="signaling">False</parameter>
    <parameter key="sendrawsdp">False</parameter>
    <parameter key="maxbackoff">30</parameter>
    <parameter key="maxdelaylimit">5</parameter>
    <parameter key="maxopen">100</parameter>
    <parameter key="maxretry">100</parameter>
    <parameter key="submitqueuelen">1000</parameter>
    <parameter key="Created">Manual</parameter>
  </Configuration>
</Configuration>

Eine Parametrisierung ist natürlich erforderlich. zumindest die "submiturl" muss auf einen sinnvollen Wert gesetzt werden.

Ich habe hier "http://localhost:85" eingesetzt, weil ich vorhabe, auf dem Server selbst einen Prozess auf Port 85 zu starten, der die Daten hier annimmt.

Set-CsSdnSubscriberParameter `
   -SdnPoolUri http://localhost:9333/Settings `
   -Identifier Subscriber1 `
   -Parameter submituri `
   -Value "http://localhost:85"
True

Zudem möchte ich noch, das der LDM auch die Events zur Signalisierung an diesen SDN Controller weiter gibt


Set-CsSdnSubscriberParameter `
   -SdnPoolUri http://localhost:9333/Settings `
   -Identifier Subscriber1 `
   -Parameter "signaling" `
   -Value "true"

Die anderen Parameter lasse ich unverändert.

 

Damit eine erste Konfiguration schon mal abgeschlossen. Uns fehlt nur noch der SDN Controller, der in diesem Beispiel auf Port 85 auf die Anfragen wartet.

Status prüfen

Ehe wir uns um den SDN Controller kümmern, möchte ich noch ein paar weitere Powershell Commandlets für SDN vorstellen. Insbesondere die Status-Anzeige ist interessant

# Abfrage der Listener, die Daten an den Manager senden
Get-CsSdnStatus -SdnPoolUri http://localhost:9333/Settings
<Status Version="1.0">
  <UpTime>23:23:00.7548914</UpTime>
  <Listener Name="192.168.100.31">
    <LastMessage>2016-03-01T16:37:31.5743635+01:00</LastMessage>
    <Count>119</Count>
  </Listener>
  <Listener Name="192.168.100.32">
    <LastMessage>2016-03-01T11:08:14.1552289+01:00</LastMessage>
    <Count>930</Count>
  </Listener>
  <Listener Name="192.168.100.33">
    <LastMessage>2016-03-01T11:09:00.7364929+01:00</LastMessage>
    <Count>847</Count>
  </Listener>
  <Listener Name="192.168.100.34">
    <LastMessage>2016-03-01T10:30:38.2979923+01:00</LastMessage>
    <Count>10</Count>
  </Listener>
</Status>

Hier melden vier Listener an einen Manager. Auch den Status des Subscribers können wir per Powershell abfragen:

Get-CsSdnSubscriberStatus `
   -SdnPoolUri http://localhost:9333/Settings `
   -Identifier Subscriber1
<Status Version="1.0" Subscriber="Subscriber1">
  <SDNManager>comgtslylog01</SDNManager>
  <SDNManagerVersion>2.4 7.0.1017.3</SDNManagerVersion>
  <SubscriberIPs>::1,127.0.0.1</SubscriberIPs>
  <QueueLength>0</QueueLength>
  <OpenRequests>0</OpenRequests>
  <PriorityQueueLen>0</PriorityQueueLen>
  <FailedMessages>0</FailedMessages>
  <SucceededMessages>0</SucceededMessages>
  <DroppedMessages>0</DroppedMessages>
  <FailedProcessing>0</FailedProcessing>
  <PriorityMessagesWaiting>0</PriorityMessagesWaiting>
  <LastError />
  <LastErrorTimeStamp>N/A</LastErrorTimeStamp>
  <LastMessageSent>N/A</LastMessageSent>
  <LastMsgDelivered>N/A</LastMsgDelivered>
</Status>

Hier kann man schon gut erkennen, dass die Commandlets nicht an das Niveau von Exchange oder Skype for Business heranreichen. Die Rückgabe der Daten ist einfach nur eine XML-Datei und mitnichten ein "Objekt".

Wenn Sie so eine System wieder zurückbauen wollen, dann geht das auch per Powershell einfach mit:

  • Remove-CsSdnListener
  • Remove-CsSdnSubscriber

SDN Powershell

Ich habe im Laufe des Artikels die meisten PowerShell Commands vorgestellt. Hier der Vollständigkeit halber noch mal die Übersicht:

# Details zum Modul
Get-Module sdncommands | fl
Name              : SdnCommands
Path              : C:\Program Files\Microsoft Skype for Business
                    Server\Microsoft Skype for Business SDN
                    Manager\SdnCommands.psm1
Description       :
ModuleType        : Script
Version           : 0.0
NestedModules     : {}
ExportedFunctions : {Add-CsSdnListener, Add-CsSdnSubscriber,
                    Get-CsSdnListener, Get-CsSdnManager...}
ExportedCmdlets   :
ExportedVariables :
ExportedAliases   :
# Übersicht der Commandlets
Get-Command -Module sdncommands
CommandType     Name
-----------     ----
Function        Add-CsSdnListener
Function        Add-CsSdnSubscriber
Function        Get-CsSdnListener
Function        Get-CsSdnManager
Function        Get-CsSdnStatus
Function        Get-CsSdnSubscriber
Function        Get-CsSdnSubscriberStatus
Function        Remove-CsSdnListener
Function        Remove-CsSdnSubscriber
Function        Set-CsSdnListenerParameter
Function        Set-CsSdnManagerParameter
Function        Set-CsSdnSubscriberParameter

Mein eigener SDN Controller

Was mache ich, wenn ich nun keine HP, Aruba, Cisco oder anderen Router in einem großen WAN habe, aber dennoch mit SDN etwas experimentieren möchte? Richtig, ich baue mir meinen SDN-Controller einfach in Software selbst. Ich habe schon früher mit SDN2.1 die Verbindung zwischen dem LDL und LDM abgelauscht um hier die Daten abzugreifen. Das geht aktuell nicht mehr so einfach aber ich habe viel über die Schnittstelle gelernt und erkannt, dass auch der Weg zwischen LDM und SDN-Controller genauso funktioniert.

Also brauche ich nur ein Programm,  bei mir eben wieder ein Powershell-Skript, welches auf einen Port einen rudimentären WebService bereit stellt und zum einen die POST-Requests des LDM annimmt und analysiert und auf der anderen Seite Zugriffe eines Clients nutzt, um eine hilfreiche Information zurück zu liefern.

Das beschreibe ich aber alles auf der eigenen Seite SDN LiveView 1

Weitere Links