Busy on Busy (BoB) - Setup

Diese Seite beschreibt, wie Sie nach der Installation von Skype for Business 2015 CU3 oder neuer die Funktion Busy on Busy (BoB) auf dem Server, in den Richtlinien und letztlich für den Anwender konfigurieren.

Voraussetzung

Die erste Voraussetzung ist natürlich, dass Sie Skype for Business Server 2015 On-Prem betreiben und das Juli 2016 Update oder neuer bereits installiert haben. Aber auch dann sind noch einige Schritte nachträglich erforderlich. BoB ist aktuell nicht mit Lync 2013 oder Lync 2010 verfügbar und es ist auch nicht sichtbar, ob dies dort nachgerüstet wird.

Hier bleiben Sie also auf Dritt-Produkte angewiesen, die ich auf Busy - Besetzt aufführe.

Voice Policy

Die Funktion muss über die Voice-Policy für die entsprechenden Anwender überhaupt freigeschaltet werden. Voice-Polices können Global, pro Site oder pro User konfiguriert werden. Siehe dazu auch Lync Policies. Ich mache mir das Leben hier einfach und aktiviere die Funktion global. Ich sehe auch erst einmal keinen Grund, warum diese Funktion nicht für alle Endpunkte bereit stellen sollte.

Set-CsVoicePolicy -EnableBusyOptions $true

Sollte es aber eine Site oder User-Policy geben, dann überstimmt die natürlich die globale Richtlinie. Dann müssen Sie diese Einstellung auch dort noch aktivieren. Sie können die Einstellungen übrigens auch im Skype for Business Control Panel (CSCP) per Maus machen:

Applikation auf den Pools aktivieren

Die "Busy on Busy"-Funktion ist als separate Application implementiert, die zwar vorinstalliert aber eben noch nicht aktiviert ist. Sie wird "pro Pool" aktiviert. Wenn sie mehrere Pools haben, muss das auf jedem Pool aktiviert werden. Folgende kleine Schleife vereinfacht das:

foreach ($pool in (Get-CsPool | ?{$_.services -like "registrar*"})){
   write-host " Processing " $pool.identity
   New-CsServerApplication `
      -Identity ('Service:Registrar:'+$pool.identity+'/BusyOptions') `
      -Uri 'http://www.microsoft.com/LCS/BusyOptions' `
      -Critical $False `
      -Enabled $True `
      -Priority (Get-CsServerApplication -Identity ('Service:Registrar:'+$pool.identity+'/UserServices')).Priority
}

Damit wird die Applikation auf den Pools aktiviert.

RBAC Rollen aktualisieren

Die "Busy"-Funktion ist mit neuen Commandlets verbunden, die natürlich nicht von "jedem" ausgeführt werden dürfen.

Über den Befehl "Update-CsAdminRole" werden die RBAC-Rollen entsprechend angepasst.

Dienste neu starten

Die Erweiterung des Skype for Business Frontend Servers um eine neue Applikation erfordert einen Neustart der Dienste. Genau genommen sollte der Neustart des RTCSRV ausreichend sein. Auf einem Standard Server ist dies schnell erledigt.

stop-cswindowsservice rtcsrv -graceful
start-cswindowsservice

Auf einem Enterprise Pool müssen Sie wieder mit Invoke-CSComputerFailover und Invoke-CSComputerFailBack arbeiten. Kontrollieren Sie dann das Windows Eventlog auf die Nummer 30253. Hier sehen Sie alle "Applikationen", die geladen wurden. Hier muss auch BusyOnBsy mit erscheinen:

Danach ist die allgemeine Einrichtung abgeschlossen.

Konfiguration des Anwenders

Mit der Aktivierung der "Busy"-Option auf dem Server sind die Vorarbeiten abgeschlossen. Der Benutzer kann aktuell aber nicht selbst einstellen, wie er auf ein "Besetzt" reagieren soll. Die Einstellung muss durch den Administrator auf dem Server erfolgen oder durch eine Provisioninglösung, die solche Einstellungen im Auftrag des Anwender machen kann. Microsoft sieht hier drei Optionen vor:

  1. Keine Busy-Einstellung
    Es bleibt alles wie es ist und Zweitanrufe werden gemeldet. Dies ist der Default
  2. Busy on Busy
    Wenn der Teilnehmer "Busy" ist dann wird ein eingehender Anruf mit einem Besetzt-Zeichen abgelehnt
  3. Voicemail on Busy
    Wenn der Teilnehmer "Busy" ist, dann wird der Anrufer auf die Voicemail (Exchange UM) umgeleitet. Die muss dazu natürlich eingerichtet sein.

Die Konfiguration der drei Optionen erfolgt aktuell nur per PowerShell. Leider ist die Einstellung kein zusätzliche Property mit Set-CSUser, sondern ein eigenes Commandlet und auch hier kann man die Option nur auf zwei der Werte setzen. Um den "Default" wieder zu erhalten, muss die Option entfernt werden:

Set-CsBusyOptions -Identity sip:User@msxfaq.de -ActionType BusyOnBusy
Set-CsBusyOptions -Identity sip:User@msxfaq.de -ActionType VoicemailOnBusy
Remove-CsBusyOptions -Identity sip:User@msxfaq.de

Das Commandlet prüft zwar nicht, ob für den Benutzer diese Option über seine Voice Policy überhaupt freigeschaltet ist, aber gibt "sicherheitshalber" eine Warnung aus.

Auch beim Auslesen der aktuellen Einstellungen für die Benutzer gibt es die ein oder andere Überraschung. Wenn bei einem Benutzer eine Option gesetzt ist, dann wird sie auch ausgegeben. Wenn die Option aber nicht gesetzt ist, dann wird ein Fehler generiert.

Das hätte Microsoft sicher besser machen können und statt des Fehlers einfach "Default" ausgeben können. Wer also einen Report generieren möchte, muss diesen Fehler entsprechend abfangen.

Wenn Sie mit NetMon 3.4 mitschneiden, dass dieses Commandlet macht, dann sehen Sie, das es per SIP mit dem Skype Server spricht und nicht per UCMWA, UCWA oder PowerShell zum Server geht und dort eine Konfigurationseinstellung tätigt. Wenn die API zur Einstellung aber schon SIP ist, dann frage ich mich schon, warum die Funktion nicht gleich in den Client gewander ist und der Anwender die Einstellung auch selbst vornehmen kann.

Die Zuweisung der Policy ist übrigens nicht an die Funktion "P2P AV" oder "Enterprise-Voice" gebunden. Die Option kann auch für Benutzer mit dem Status "Audio/Video disabled" gesetzt werden. Hier bringt sie natürlich nicht viel. Wer also nach der Umsetzung erst einmal alle Personen entsprechend behandeln will, kann das mit folgender Sequenz machen.

get-csUser `
   -resultsize unlimited `
   -Filter {HostingProvider -ne "sipfed.online.lync.com"} `
| Set-CSBusyOptions `
     -ActionType BusyOnBusy

Benutzer, die in einer Hybrid-Umgebung in der Cloud sind, können natürlich nicht mit dieser Option versorgt werden. Das Update der Einstellung bei einer größeren Anzahl an Benutzern kann durchaus länger dauern, da es hierbei nicht um die Änderung eines Felds beim AD-Objekt geht, sondern die Daten in der Skype for Business Datenbank hinterlegt werden.

Änderungen an den Einstellungen eines Benutzers werden quasi "sofort" aktiv, aber betreffen nur "neu eingehende Calls". Wenn ich also einen Call noch klingeln lasse und dann meine Option auf BusyOnBusy umstelle, dann wird der aktuelle Ruf nicht abgebrochen. Das gilt auch, wenn ich z.B.: meinen Status von "Verfügbar" auf "Busy" stelle oder eine Konferenz starte. Die Entscheidung wird also nur beim ersten INVITE des Anrufs auf dem Frontend gefällt.

Sie können eine Option übrigens mehrfach setzen. Das Commandlet bringt keine Rückmeldung, wenn die Einstellung schon vorher vorhanden war und daher nicht geändert werden musste.

Der Anwender kann dies aktuell nicht selbst umstellen.

Weitere Links