Response Group Service (RGS)

Microsoft Consultant Exchange & Skype for Business (m/w)
Kommen Sie zu Net at Work. Wir haben spannende Projekte bei innovativen Kunden. Unser Team arbeitet kollegial und kooperativ – ständiger Austausch und Weiterbildung sind bei uns Standard.
https://www.netatwork.de/unternehmen/karriere/

Mit dem Office Communications Server 2007 R2 wurden neben den Konferenzräumen auch Gruppenruffunktionen eingebaut. Damit können neben den direkten Durchwahlnummern der Mitarbeiter auch Teamgruppen gebildet werden. Anrufe an diese Teams werden dann je nach Einstellung bei allen Mitgliedern oder nacheinander signalisiert. Zudem können Sie einstellen, ob sich die Mitglieder selbst ein und austragen dürfen und welche Workflows an eine Rufnummer gebunden werden.

Agenten in einer Responsegroup-Lösung können nur Anwender sein die Enterprise Voice verwenden, d.h. über OCS/Lync/Skype for Business auch telefonieren. Remote Call Control ist nicht ausreichend.

Auch wenn RGS auf Windows Gruppen aufbaut, so können diese nicht verschachtelt werden
Siehe auch http://technet.microsoft.com/en-us/library/gg520949.aspx unter Punkt 12.
Eventuell hilft ihnen das Skript auf QuerybasedGroup.

Response Group Clients

Nicht jedes Endgerät, welches auf einen SIP-Invite klingelt, kann auch einen Anruf annehmen. Das ist aktuell mit Lync 2013 und den mobilen Clients ein Thema, die sehr wohl per WiFi oder GSM auch einen VoIP Call bedienen können. Interessanterweise bekommen diese auch einen Responsegroup Call gemeldet, aber können den Anruf nicht erfolgreich annehmen. Während IOS den Call "fast" bekommt, d.h. der Anrufer ist aus der Warteschlange raus aber fällt dann wieder zurück kann ein Android den Anrufer gar nicht erst aus der Warteschlange abrufen.

Auf der Liste der "supporteten RGS-Clients für Lync 2013 " stehen diese Clients auch nicht drauf.

  • Lync 2013 Communicator
  • Lync 2010 Communicator
  • Lync 2010 Attendant
  • Office Communications Server 2007 R2 Attendant
  • Lync Phone Edition

Allerdings sollten diese Clients dann auch den Ruf gar nicht bekommen oder zumindest nicht annehmen.

Anrufe an eine RGS werden an die Clients als "Secondary Call" gemeldet. So wird sichergestellt, dass individuelle Weiterleitungen die Voicemail eines angemeldeten Agenten anspringt.

Headset und Lync Telefon mit USB-Link
Ein eingehender Ruf kann am Headset oder am Bildschirm angenommen werden. Dennoch landet Audio auf dem Lync Telefon. Das ist wohl ein schon lange bekannter Bug im Lync Client. Lösung offen.

RGS und Mobilgeräte
Leider werden RGS-Calls auch an Lync 2013 Mobile Clients gemeldet. Zumindest mit Lync 2013 CU1 konnten aber weder IOS noch Android diese Calls auch annehmen. Es kam bislang keine Audioverbindung zustande. Mit Skype for Business 2019 sollen nun auch Mobilgeräte den RGS-Anruf annehmen können. Offiziell sind mobile Clients aber nicht als kompatibel aufgelistet.

Zusammenhänge

Wer die Konfiguration der Response Group Services über den Server gestartet hat, findet sich erst mal in einer neuen Welt. Bei OCS ist diese Funktion nicht in die übliche MMC eingebunden, sondern ein eigenständiges Programm und eine Webseite. Man könnte fast den Eindruck erwecken, dass die RGS gar nicht zum Produkt dazu gehört, sondern von einem anderen Team auf den APIs von OCS (Siehe OCS API) aufgesetzt wurde. Zuerst aber die Zusammenhänge. Damit RGS skalierbar ist, hat sich Microsoft auf mein mehrstufiges Gefüge festgelegt: 

Ein Workflow regelt den Ablauf der Anrufe und nutzt dazu entsprechende "Queues", in denen die Anrufer dann abgeworfen werden. Diese Warteschlangen werden von Agenten betreut, die ihrerseits aber nicht direkt der Warteschlange, sondern über Gruppen zugewiesen werden. ähnlich dem Gruppenkonzept unter Windows mit lokalen Gruppe für die Vergabe von Berechtigungen und globalen/universellen Gruppen zur Gruppierung von Benutzern und die Verbindung der Gruppen (Siehe auch Windows Gruppen und Berechtigungen) ist auch hier der Ansatz gewählt.

Responsegroups mit OCS Management Console starten

Die Verwaltung der Response Groups erfolgt in einer eigenen Management Console, welche über das Kontextmenü des Servers aufgerufen wird:

In der gestarteten MMC sehen Sie dann die vier Bereiche Workflows, Queues, Groups und Agents.

Auch wenn die GUI dies anders erscheinen lässt, so sollten Sie nicht erst einen Workflow definieren. Sie kommen dort nämlich nicht weiter, solange Sie keine Queues hinterlegt haben. Die Einrichtung erfolgt also von unten nach oben, indem zuerst die Agenten definiert werden, die dann in Gruppen zusammengefasst sind, die ihrerseits an Queues zugeordnet werden können.

Agenten definieren

Sie müssen zuerst die Agenten festlegen. Dazu können Sie über das Kontextmenü neue Agenten anlegen. Die MMC bietet ihnen dazu die bereits für OCS-Voice aktivierten Konten an, die Sie nach dem Addieren auch im Detail anzeigen können.

Sie sehen zwar hier auch die Karteikarte "Groups", aber diese ist nur informell. ändern können Sie hier nichts.

Groups definieren

Sie müssen dazu schon in den Bereich der Gruppen, wo Sie neue Gruppen anlegen können und dort dann Agenten in die Gruppen aufnehmen können. Hier sehen Sie am Beispiel einer "Support-Gruppe" die EinstellMöglichkeiten zur Verteilung der eingehenden Rufe.

Eine Gruppe habt aber noch keine Rufnummer, sondern ist nur eine Zusammenfassung von verschiedenen Agenten. Die kann aber natürlich schon von einem Communicator User genutzt werden. für die Erreichbarkeit über ein Telefon sind noch ein paar Schritte erforderlich.

Eine Gruppe kann übrigens so konfiguriert werden, dass sich die Anwender selbst an und abmelden können. Dazu muss aber auf dem Communicator Client noch etwas verändert werden, damit die entsprechenden Funktionen auch aktiviert werden. Dies ist weiter unten auf dieser Seite beschrieben.

Queues definieren

Der nächste Schritt ist die Definition einer Warteschlange.

Eine Warteschlange wiederrum erlaubt es, die Verbindungswünsche, welche später über die Workflows das System erreichen an eine oder mehrere Gruppen zu verbinden und zu steuern, wie mit Problemen umgegangen wird, wenn niemand antwortet oder alle Teilnehmer belegt sind.

Workflows definieren

Interessant wird es nun, wenn Sie tatsächlich eine "Rufnummer" in das System mit einbringen. Bislang kann diese Response Group nur per Communicator erreicht werden. Damit nun diese Responsegroup über eine Rufnummer erreichbar ist, muss nicht nur eine Kopplung der Telefonanlage mit OCs erfolgt sein (z.B. mit einem Gateway und einem Mediation Server).

Der erste Schritt ist die Anlage eines "passenden Kontakts" mit dem Programm "RGSCOT.exe". Dies könnte also wie folgt aussehen: (Das Programm liegt  meist in C:\Program Files\Common Files\Microsoft Office Communications Server 2007 R2". ein Aufruf mit "/?" liefert folgende Hilfe:

Microsoft Office Communications Server 2007 R2
Response Group Service Contact Object Tool
Copyright (c) Microsoft Corporation.  All rights reserved. Usage Instructions

rgscot      /Command (see below für available commands)
            [/PrimaryUri:<Sip address>]
            [/DisplayName:<Name>]
            [/PoolFQDN:<Pool FQDN>]
            [/EnabledForFederation:<TRUE:FALSE>]
            [/LineUri:tel:<phone #>]
            [/DisplayNumber:<Phone #>]
command:
            /Create            Create a new contact object für the response group service.
            /Edit              Edit some properties of an existing contact object.
            /PrimaryUri must be defined and cannot be overwritten.
            /Delete            Delete an existing contact object für the response group service.
            /?                 Shows help on usage.

Ein Aufruf könnten also wie folgt aussehen (Zeilenumbrüche zur Lesbarkeit ergänzt):

C:\rgscot.exe
    /create
    /PrimaryURI:sip:611@netatwork.de
    /Displayname:Support611
    /PoolFQDN:nawocsstd.netatwork.de
    /LineURI:tel:+495251304611
    /DisplayNumber:611

Starting to save the contact object...
A new contact object with SIP address sip:611@netatwork.de has been created.

Und ein paar Sekunden später ist das Kontaktobjekt im Active Directory auch repliziert. Dann kann der nächste Schritt beginnen und der Workflow mit diesem Kontaktobjekt erstellt und mit einer Queue verbunden werden.

Die "Kontakte" liegen übrigens in der Konfigurationspartition.

CN=Application Contacts,CN=RTC Service,CN=Services,CN=Configuration,DC=netatwork,DC=de

Weiterleitung nach Extern an PSTN

Eine Responsegroup hat auch die Möglichkeit, einen Anruf an eine andere Rufnummer, auch extern, weiter zu leiten. Die entsprechenden Felder gibt es einfach in der GUI von OCS 2007 R2:

Aber so einfach, wie das hier erscheint, ist es dann wieder nicht, zumindest nicht wenn Sie die Berechtigungen für ausgehende Rufe über eine "Voice Policy" kontrollieren. In vielen Firmen wird ja über Leitwege und "Phone usage" gesteuert (Siehe auch VoIP Routing und Rechte) Das Problem hierbei ist nun, dass der ausgehende Ruf ja nicht von einem OCS Benutzer und auch nicht von dem externen Anrufer sondern von der Response Group getätigt wird. Das ist das vormals angelegte Kontaktobjekt. Nur leider pflegt RGSCOT.EXE an diesem Kontakt keine "Phone usage" und eine andere GUI gibt es nicht. Sie sollten aber nun nicht dazu übergehen, per ADSIEDIT direkt an dem Kontaktobjekt etwas zu ändern. Mit WMI und PowerShell gibt es eine ganz elegante Möglichkeit diese Einstellungen fehlerfrei zu machen.

$VoiceUser = gwmi -q "select * from MSFT_SIPESUserSetting where primäryURI='sip:templatebenutzer@domain.tld'"
$RGSContact = gwmi -q "select * from MSFT_SIPApplicationContactSetting where primäryURI='sip:rgscontacthere@domain.tld'" 
$RGSContact.UCPolicy = $VoiceUser.UCPolicy
$RGSContact.Put()

Eine kleine Erläuterung der vier Zeilen:

  1. $VoiceUser = ....
    Zuerst holen wir uns per WMI aus OCS einen Benutzer, dessen Richtlinie für Telefonie wir für den Responsegroup ebenfalls verwenden wollen. An dem Benutzer wird später nicht geändert. Die Responsegroup wird aber dann genau die gleichen Berechtigungen wie dieser Benutzer im Moment des Kopierens erhalten
  2. $RGSContact = ...
    Nun holen wir uns über einen ähnlichen WMI Aufruf das Kontaktobjekt zur Responsegroup, welches aktuell eben noch keine Richtlinie hat und damit nicht nach extern (Aus Sicht von Lync) rufen darf.
  3. Kopieren der Vorlage
    Diese Zeile kopiert die Richtlinie des Vorlagenbenutzers einfach auf das Kontaktobjekt. Das passiert aber aktuell erst lokal im Speicher des Computers
  4. Zurückschreiben.
    Erst durch diese Zeile werden die Änderungen am Responsegroup-Objekt auch wieder zurück geschrieben.

Diese Zeilen können Sie "Interaktiv" ausführen oder auch als PS1-Datei speichern und starten. Die Ausführung sollte aber auf dem OCS-Server erfolgen, da dort auch die WMI-Zugriffe einfacher möglich sind. Theoretisch ist dies natürlich auch "remote" möglich.

Mit Lync ist dies deutlich einfacher geworden. Da reicht ein PowerShell-Kommando

Get-CsApplicationEndpoint -Identity "Response Group Workflow Name" | `
    Grant-CsVoicePolicy -PolicyName "Voice Policy Name"

Hier noch ein paar weiterführende Links

Steuerung und Signalisierung über den Client

Bei der Definition der Gruppe weiter oben konnten Sie einstellen, ob die Gruppe "informal", formal" oder "Nicht aktiv" ist. Wenn Sie hier "formal" anwählen, dann kann der Anwender selbst für die Gruppe aktivieren und deaktivieren.

Achtung:
Der Anwender kann sich nicht selbst in die Gruppe aufnehmen oder entfernen sondern nur seine Mitgliedschaft aktivieren oder deaktivieren. Es bleibt Aufgabe des Administrators, die möglichen Mitglieder hier zu pflegen.

Wenn man auf dem Client über den Policy-Schlüssel eine XML-Datei spezifiziert, kann man auf dem Client auch ein Addin aktivieren. Abhängig von den Berechtigungen kann ich dann auf dem Client mich selbst in die entsprechenden Gruppen ein und austragen. Ich sehe dabei aber nur die Gruppen, in die ich auch durch den Administrator eingetragen wurde, d.h. ich bleibe Mitglied aber kann einstellen ob die Mitgliedschaft "aktiv" ist oder nicht.

Damit im Communicator aber diese Funktion überhaupt erreichbar wird, muss noch etwas konfiguriert werden. Dazu ist eine XML-Datei anzulegen, welche dann auf dem Client eingebunden wird. Die Einbindung auf dem Client kann per Gruppenrichtlinien erfolgen.

Hier ein Beispiel für so eine XML-Datei:

<?xml version="1.0" ?> 
<tabdata>
<tab>
  <image>\\ocsserver\share\OCS\RgsOcTab.png</image> 
  <Userid>true</Userid> 
  <name>Response Group Tab</name> 
  <tooltip>Response Group Tab</tooltip> 
  <contentURL>https://ocsserver.firma.tld/rgs/clients/Tab.aspx</contentURL> 
  <contactid>false</contactid> 
  <siteid>1</siteid> 
</tab>
</tabdata>

Die XML-Datei muss natürlich noch über einen Eintrag in der Registrierung aktiviert werden.

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Communicator]
"TabURL"="file:///c:/temp/rgs..xml"

Natürlich sollten Sie in einer Firma die XML-Datei zentral auf einen Server oder per Softwareverteilung auf jeden Client in z.B. das Programmverzeichnis ablegen und den Verweis dort hin setzen.

In Lync wird diese Funktion übrigens über eine Webgui (https://<fqdn-ocs-server>/RgsClients/Tab.aspx ) ermöglicht ist und auch im Client dann sichtbar

Siehe auch Answer and make calls für a response group in Lync 2010  http://office.microsoft.com/client/helppreview.aspx?AssetId=HA101834781&lcid=1033&NS=COMM14&pc=oc&subver=0&bld=7353&bldver=1

Steuerung über den Client

Wen ich mich eine Gruppe eingetragen habe, dann landen die eingehenden Rufe an diese Gruppe natürlich auch auf meinem Communicator. Ich sehe in der Meldung auch, für welche Gruppe der Ruf war.

Status und Klingeln

Allerdings "klingelt" es bei mir nur, wenn ich "Frei" bin. Stelle ich meinen Status aber auf "Belegt", dann kommt der Anruf nicht rein. Das ist natürlich unglücklich, wen ich z.B. in meinem Kalender ein "Heute Support" eingetragen habe und der Communicator mich daher auf "Belegt" stellt. Manchmal gibt es ja auch die Aufgabestellung, dass ich eben mit "Telefonsupport" belegt bin und daher auch für Federation nicht als "Frei" angezeigt werden will. Direkte Telefonate kommen bei einem Anruf auf meine Durchwahl ja auch bei einem "Belegt" durch und landen nur bei einem "Nicht Stören" auf der Mailbox. Insofern sollte der Response Group Service doch bitte mal erst die Anklingeln, die Frei sind aber wenn keiner Frei ist, dann die Mitglieder anklingeln, die "belegt" sind. Nur die Mitglieder deren Status auf "nicht stören" steht, sollten unbehelligt bleiben.

So funktioniert aber die Responsegroup nicht. Ich muss "frei" sein, damit ich einen Responsegroup-Call bekomme. Ich kann aber natürlich eine zweite Queue als "Überlauf" einrichten, die über die Methode "Attendant" verteilt wird. Dann klingelt es auch, wenn ich Busy oder "am Telefon" bin. Hier das Verhalten bei Lync 2013

Status Gruppenrouting: Attendant Gruppenrouting: Longest Ide o.a.

Grün

Klingelt

Klingelt

Busy

Klingelt

Kein Ruf

DND

Kein Ruf

Kein Ruf

Klingelt

Kein Ruf

Abwesend 

Klingelt

Kein Ruf

Klingelt

Kein Ruf

Klingelt

Kein Ruf

Ein Wechsel des Status auf "grün", während ein Teilnehmer in der Warteschlange ist, signalisiert den wartenden Anrufer direkt. Wenn ein Anrufer aber schon gemeldet wird und ich setze dann meinen Status auf z.B. "Bitte nicht stören", dann bleibt der Ruf. Nur wen ich den Status im Dialog des eingehenden Rufs ändere, dann wird nicht nur mein Status geändert, sondern auch der Ruf hier abgelehnt.

Interessant ist natürlich auch die Reihenfolge, wie die Agenten angerufen werden, wenn mehrere Agenten in einer Responsegroup sind.

  User1 User2 User3 User4 User5
Status
Letztes Telefonat vor. 10 Minuten 2 Minuten aktiv 5 Minute irrelevant
Letztes Telefonat angenommen   Ja   irrelevant
Reihenfolge in Gruppe 1 2 3 4 5
Attendant

Klingelt

Klingelt

Klingelt

Klingelt

Kein Ruf

Parallel

Klingelt

Kein Ruf

Kein Ruf

Klingelt

Kein Ruf

LongestIdle

Klingelt

Kein Ruf

Kein Ruf

Klingelt nach
Timeout User 1

Kein Ruf

Round Robin

Klingelt nach
Timeout User 4

Kein Ruf

Kein Ruf

Klingelt

Kein Ruf

Serial

Klingelt

Kein Ruf

nein

Klingelt nach
 Timeout User 1

Kein Ruf

Die Tabelle kann nicht alle Sonderfälle abdecken.

Responsegroup und Rufweiterleitung

Die Funktion „Parallelruf“ oder „Weiterleitung“, die ein Anwender selbst einstellen gilt nur für „direkte Rufe“ zu dem Teilnehmer, bei denen es bei ihm quasi alleine klingelt. Eine Weiterleitung des Rufs z.B. auf einen anderen Teilnehmer oder auf ein Mobiltelefon oder ein „Lync Analogtelefon“ findet hingegen nicht statt, wenn es beim Teilnehmer klingelt, weil er in einer „Teamanrufergruppe“ oder in einer „Responsegroup“ ist. In diesen Fällen klingelt es nur bei den Teilnehmern die „Available“ sind und eventuell eingestellt Weiterleitungen werden nicht berücksichtigt.
Das hat durchaus seinen tieferen Sinn, denn für ein Mobiltelefon oder analoges Telefone kann Lync ja nicht dessen Status erkennen, was die Funktion stören könnte. Stellen Sie sich vor ein Kunde ruft beim „Support“ an, welches eine Responsegroup ist und es klingelt bei den drei eingetragenen und „freien/abwesenden“ eingetragenen Mitgliedern. Einer hat davon eine Weiterleitung auf ein Mobilteil (GSM/DECT) und es würde auch da klingeln. Gerade im GSM-Umfeld ist es oft der Fall, dass bei einer „Nichterreichbarkeit“ der Ruf z.B.: auf der Mailbox landet. Das würde aber bedeuten, dass alle Rufe an die Responsegroup auch auf dem Mobiltelefon des Mitarbeiters signalisiert werden und nach wenigen Sekunden auf der Mobilfunk-Mailbox landen.

Von Hause aus ist daher Lync hier nicht für „Parallelruf/Weiterleitung“ in Verbindung mit ResponseGroups geeignet.
Aber das muss nicht die abschließende Antwort sein. Wer noch eine TK-Anlage hat, kann durchaus überlegen, dass dort die „Anrufergruppe“ geführt wird und die TK-Anlage den ruf an das DECT/GSM-Telefon gibt und parallel an den Lync-Teilnehmer oder die Lync Responsegroup

Ein anderer Ansatz besteht darin, durch eine eigene Call-Routing-Applikation über die UCSMA-Schnittstelle dieses Verhalten entsprechend selbst zu programmieren. Was ich so an Beispielen gesehen habe, dürfte das sogar recht einfach sein.
Der Weg über eine Anwendung auf dem Client ist ebenfalls möglich, die den Eingang eines Rufs auf dem Lync-Client überwacht und dann eine zweite Verbindung zum Mobiltelefon aufbaut und beim „Connect“ dann den Ruf vermittelt. Aber das ist weniger elegant.

Es gibt natürlich noch die Funktion über die „Überlauffunktion“ in der Responsegroup einzustellen, dass der Ruf nach einiger Zeit oder wenn niemand in der Responsegroup angemeldet ist an einen anderen Anschluss (z.B. Bereitschaftsmobiltelefon) weitergeleitet wird. Das kann aber der Anwender nicht mehr selbst einstellen. Die Lösung von Lync in Verbindung mit parallel bereitgestellten Mobilteilen ist aktuell also noch nicht perfekt.

OCS Response Groups und Windows 2008

By Default scheinen die RGSs unter Windows 2008 R2 nicht sauber zu laufen. Der Zugriff erfolgt über folgende URL

https:///ocsserver/rgs/deploy/default.aspx

Wenn Sie dann aber nur einen fast weißen Bildschirm mit ein vier Buttons sehen, dann müssen Sie ein paar Dinge kontrollieren und eventuell fixen

möglich Fehler sind:

  • ServicePrincipalName
    Auf Windows 2008R2 kann es sein, dass der IIS seine SPNs nicht registrieren kann. Das müssen sie dann als Administrator einmal machen
rem Anzeige der aktuellen SPNs

setspn -L

Rem Setzen bzw addieren der SPNs

setspn -A http/ocsservername ocsservername
setspn -A http/ocsservername.domain.tld ocsservername
  • RTCUniversalServerAdministratoren
    Der Benutzer, der RGS-Einstellungen verwalten will, muss angeblich Mitglieder dieser Gruppe sein.
  • IIS Static Content
    Auf einem Windows 2008R2 Server waren alle Bilder und Stylesheets nicht zu sehen, obwohl die Dateien im richtigen Verzeichnis lagen und im IISLog sogar ein 200er Eintrag gelandet ist. Es hat etwas gedauert, bis ich die Ursache gefunden habe: Das "Feature" Static Content" war auf dem Server nicht installiert

    Damit hat der IIS zwar etwas ausgeliefert, aber das war einfach nichts außer ein Platzhalter
  • IIS Kernel Mode
    Diverse Hinweise im Internet sagen, dass die "Kernel-Mode Authentication" angeschaltet sein muss. Einen unterschied habe ich aber nicht gefunden.

    Hinweise: http://www.networkworld.com/community/node/40716
  • "Richtiger Browser
    Angeblich funktioniert die Konfiguration nur mit dem Internet Explorer (und hier nur 32bit). Das kann ich aber nicht bestätigen. Auch 64bit und sogar ein aktueller Firefox kann problemlos genutzt werden.

Ansonsten ist die Funktion der Response Groups auch unter Windows 2008 R2 problemlos gegeben

Response Group und PowerShell und Berechtigungen

Seit Lync ist natürlich PowerShell das primäre Werkzeug, um Responsegroups per Skript zu anzulegen und zu verwalten. Damit ergeben sich einige nette Möglichkeiten, die über das hinaus gehen, was das Lync Control Panel bietet. Lync kann von Hause aus nämlich nur sehr eingeschränkt die Berechtigungen auf die Verwaltung von Responsegroup delegieren. Es gibt nur die Managementrolle "CSResponseGroupAdministrator" die dann aber alle Commandlets auf den globalen Scope in sich vereint.

PS C:\> Get-CsAdminRole CSResponseGroupAdministrator


Identity       : CSResponseGroupAdministrator
SID            : S-1-5-21-11949449-30417519-71842111-6871
IsStandardRole : True
Cmdlets        : {Name=Get-CSRgsAgentGroup, Name=Get-CSRgsHoursOfBusiness, Name
                 =Get-CSRgsConfiguration, Name=Get-CSRgsHolidaySet...}
ConfigScopes   : {Global} UserScopes     : {Global}
Template       :

Eine Delegierung nach OUs oder Sites ist nicht praktikabel möglich, da die Konfiguration eben in der SQL-Datenbank liegt und es keine Gruppen in im Active Directory sind. Es wäre aber z.B. denkbar, dass jemand eben nur Gruppen anlegen und verwalten kann. Hier ein Beispiel

  • Gruppe anlegen
    Zu jeder administrativen Rolle muss es wie in Exchange auch eine Sicherheitsgruppe geben. Die wird einfach über die MMC für Benutzer und Computer angelegt.
  • CSAdminRole anlegen
    Das geht erst mal nur per PowerShell und natürlich müssen Sie eine bestehende Rolle als Template verwenden.
PS C:\> New-CsAdminRole -identity CSRGSGroupAdmin -Template CSResponseGroupAdministrator

Identity       : CSRGSGroupAdmin
SID            : S-1-5-21-11949449-30417519-71842111-9377
IsStandardRole : False
Cmdlets        : {Name=Get-CSRgsAgentGroup, Name=Get-CSRgsHoursOfBusiness, Name
                 =Get-CSRgsConfiguration, Name=Get-CSRgsHolidaySet...}
ConfigScopes   : {Global} UserScopes     : {Global}
Template       : CSResponseGroupAdministrator

Wer nun aber die Liste der CMDLets verändern möchte, wird sich täuschen:

Die Liste der CMDLets ist nämlich nicht beschreibbar. Neue administrative Gruppen gehen also nur als Unterscheidung nach dem UserScope/ConfigScope aber nicht um CMDLets anzupassen.

Response Group per PowerShell steuern.

Wenn die Rechte schon nicht per Lync PowerShell delegiert werden können, dann bleibt noch der Weg, eine eigene Applikation zu entwickeln, die dann die erforderlichen Änderungen "on behalf" ausführt. Damit sind wir beim gleichen Prozess, der auch im Provisioning von Benutzern immer häufiger an Bedeutung gewinnt. Dass eben ein Administrator oder Benutzer nicht mehr selbst direkt die Änderungen an einem System vornimmt, sondern über eine wie auch immer geartete Plattform den Auftrag einstellt und ein Backgroundprozess die Änderungen letztlich durchführt.

Bislang habe ich kein Programm gefunden, welches für Responsegroups z.B. die Verwaltung durch Personen erlaubt. Es wäre ja schon nützlich, wenn man einen "Queue-Administrator" bestimmen könnte, der dann die Agenten in der Queue z.B.: umsortiert, addiert, entfernt o.ä. ohne dass er als "Response Group Administrator" gleich alle Workflows, Queues und Gruppen komplett administrieren und im Extremfall auch löschen kann.

Folgende Befehle stehen in der PowerShell für die Responsegroups zur Verfügung

PS C:\Users\user1> get-help *rgs*

Name                              Category  Synopsis
----                              --------  --------
Get-CsRgsAgentGroup               Cmdlet    Returns information about the Re...
Get-CsRgsConfiguration            Cmdlet    Returns information about config...
Get-CsRgsHolidaySet               Cmdlet    Returns information about the Re...
Get-CsRgsHoursOfBusiness          Cmdlet    Retrieves information about the ...
Get-CsRgsQueue                    Cmdlet    Retrieves information about the ...
Get-CsRgsWorkflow                 Cmdlet    Returns information about Respon...
Import-CsRgsAudioFile             Cmdlet    Imports a new audio file für use...
Move-CsRgsConfiguration           Cmdlet    Enables you to migrate Response ...
New-CsRgsAgentGroup               Cmdlet    Creates a new Response Group age...
New-CsRgsAnswer                   Cmdlet    Creates a new Response Group ans...
New-CsRgsCallAction               Cmdlet    Creates a new Response Group cal...
New-CsRgsHoliday                  Cmdlet    Creates a new Response Group hol...
New-CsRgsHolidaySet               Cmdlet    Creates a new Response Group hol...
New-CsRgsHoursOfBusiness          Cmdlet    Creates a new set of Response Gr...
New-CsRgsPrompt                   Cmdlet    Creates a new workflow prompt fo...
New-CsRgsQuestion                 Cmdlet    Creates a new Response Group que...
New-CsRgsQueue                    Cmdlet    Creates a new Response Group que...
New-CsRgsTimeRange                Cmdlet    Creates a new Response Group tim...
New-CsRgsWorkflow                 Cmdlet    Creates a new Response Group wor...
Remove-CsRgsAgentGroup            Cmdlet    Removes an existing Response Gro...
Remove-CsRgsHolidaySet            Cmdlet    Removes an existing Response Gro...
Remove-CsRgsHoursOfBusiness       Cmdlet    Removes an existing set of Respo...
Remove-CsRgsQueue                 Cmdlet    Deletes an existing Response Gro...
Remove-CsRgsWorkflow              Cmdlet    Deletes an existing Response Gro...
Set-CsRgsAgentGroup               Cmdlet    Modifies an existing Response Gr...
Set-CsRgsConfiguration            Cmdlet    Modifies configuration settings ...
Set-CsRgsHolidaySet               Cmdlet    Modifies the property values of ...
Set-CsRgsHoursOfBusiness          Cmdlet    Configures an existing set of Re...
Set-CsRgsQueue                    Cmdlet    Modifies an existing Response Gr...
Set-CsRgsWorkflow                 Cmdlet    Modifies an existing Response Gr...

Wenn wir also schon nicht über die administrativen Rollen hier beschränkend eingreifen können, dann wird es wohl immer wieder auf eine eigene Applikation hinauslaufen.

Response Group Monitoring mit RGSAgentLive (nur 64bit !!)

Wer eine Responsegroup betreibt, der würde schon einmal gerne sehen, wie viele Anrufer gerade in welcher Warteschlange "warten" und wie lange die dort schon verweilen. Auch statistischer Erhebungen wären interessant um z.B. das Person einzuplanen. Dies sind aber alles Tätigkeiten, die eher eine echte Call Center Application bedienen kann. Die relative einfachen "Response Groups" sind hierauf noch nicht ausgerichtet. Mit einem Ressource Kit Tool, kann man aber zumindest ein wenig Einblick erhalten.

RGS Reporting

Es gibt mehrere Stellen, an denen Anrufe an eine Response Group protokolliert werden. Allerdings sind die Logs aus dem Gateway der eingehenden Anrufe oder Protokolle auf den Clients eher schlecht geeignet. Wer heute mit Response Groups arbeitet, wird auch immer die Skype for Business Monitoring-Rolle installieren. Dort landen sehr umfangreiche Daten zum Betrieb und können über die Reporting-Services ausgewertet werden.

RGS VoIP Flowchart

Ich habe im Rahmen eines Support Calls die SIP-Pakete einer Responsgroup aufgezeichnet und in eine logische Reihenfolge gebracht. Hier ein Visio-Bild der "rechten Seite", also die auf dem Agent zu sehen ist. Diese Daten können Sie ohne Mithilfe des Lync Administrators einfach auf ihrem Client mitschneiden.

Im alten Lync 2010 Ressource Kit gibt es noch ein weiteres Dokument, welches die Zusammenhänge  beschreibt.

Chapter_14_Response_Group_Application
http://download.microsoft.com/download/9/4/E/94ED1EF4-A2EF-4686-9841-B0390072D524/Chapter_14_Response_Group_Application.doc

Auch wenn hier von Lync 2010 die Sprache ist, so hat sich bei Lync 2013 und Skype für Business 2015 nicht viel geändert.

RGS Skalierung

Ich habe noch keine Information gefunden, wie viele RGS ein Lync Server bedienen kann. Wichtiger als die absolute Anzahl an Response Groups dürfte aber die Anzahl der Agenten sein. Die folgenden Links helfen aber beim Sizing:

RGS dokumentieren

Matt Landis hat ein PowerShell-Skript veröffentlicht, welches die RGS-Konfiguration in eine Textdatei exportiert, die dann von Visio wieder eingelesen und als über die Org-Chart-Funktion entsprechend grafisch aufbereitet

Andere Produkte und Tools zu Responsegroups

Hier liste ich das ein oder andere Tools, welches zu Responsegroups passt ohne aber eine Wertung oder Empfehlung damit zu verbinden. Wenn sie weitere Tools können, dann würde ich mich über eine Information freuen.

Weitere Links

Microsoft Consultant Exchange & Skype for Business (m/w)
Kommen Sie zu Net at Work. Wir haben spannende Projekte bei innovativen Kunden. Unser Team arbeitet kollegial und kooperativ – ständiger Austausch und Weiterbildung sind bei uns Standard.
https://www.netatwork.de/unternehmen/karriere/