Lync Betriebsmodelle

Es gibt von Microsoft ein Lync Hosting Pack und nur dieses ist offiziell für das Hosting von Lync vorgesehen. Aber auch eine normale Lync Installation können Sie als Plattform für mehrere Firmen nutzen. So ein Modell kommt auch sehr häufig zum Einsatz wenn eine direkte Abschottung der Teilnehmer gar nicht erforderlich ist, d.h. wenn zwei Personen in unterschiedlichen Firmen auf dem gleichen Lync System quasi "ohne" Federation miteinander kommunizieren können und damit vielleicht per Default mehr sehen können. Firmengruppen nutzen solche Konstellationen gerne

Betriebsarten

Die erste Frage ist die Konfiguration es Active Directory. Die meisten Hosting-Umgebungen nutzen genau einen Forest mit genau einer Domäne, um darin dann für jeden Kunden z.B. eine OU anzulegen und darunter die Benutzer. Aber es gibt noch andere Optionen. Ich habe hier einfach mal einige aufgezählt:

Kurzzeichen Modell Beschreibung

Eigenbetrieb

Eigenbetrieb

Zum Einstieg in die Materie stellt dieses Bild das einfache "Selbsthosting" dar.

  • Benutzer werden nur "OnPremise" verwaltet
  • Lync Properties sind am "OnPremise"-Benutzer zu pflegen
  • Authentifizierung erfolgt gegen OnPremise-Forest
  • Server stehen "OnPremise" und werden hier verwaltet
  • TK-Anbindung erfolgt lokal
  • VoiceMail kann lokal oder in der Cloud (O365) erfolgen

AD-Ausdehnung

AD-Ausdehnung

Einige Kunden möchten nur die "Arbeit" an Spezialisten übergeben und vielleicht die Server "netztechnisch" besser aufstellen und verlagern den Betrieb zu einem Hoster. Technisch bleiben die Server aber immer noch im Kunden Forest:

  • Benutzer werden nur "OnPremise" verwaltet
  • Lync Properties sind am "OnPremise"-Benutzer zu pflegen
  • Authentifizierung erfolgt gegen OnPremise-Forest
  • Server stehen "beim Hoster" und werden hier verwaltet
  • TK-Anbindung erfolgt lokal oder beim Hoster
  • VoiceMail kann lokal oder in der Cloud (O365) erfolgen

Das ist also eher ein „Hardware Outsourcing“ mit „Managed Services“.

Lync Hosting Pack

Lync Hosting Pack

Das klassische "Lync Hosting", wie es auch Microsoft mit Office 365 vor macht ist, ist ein großer Forest beim Hoster mit einer entsprechend großen Lync Installation. Alle Kunden bekommen "Konten" in diesem Forest, die in der Regel pro Kunde in einer OU gruppiert sind und über spezielle Lync Felder (TenantID) logisch von einander abgeschottet werden.

  • Benutzer werden "OnPremise" undin der Cloud verwaltet
    Hilfreich ist ein DirSync, der dieses Abgleichen automatisiert.
  • Lync Properties sind am "Cloud"-Benutzer zu pflegen
  • Authentifizierung erfolgt gegen Cloud-Forest
    Alternativ könnte mit ADFS o.ä. eine Anmeldung an der user Domäne erfolgen.
  • Server stehen "beim Hoster" und werden hier verwaltet
  • TK-Anbindung erfolgt lokal oder beim Hoster
    Office 365 erlaubt aktuell keine Anbindung. Technisch sind aber beide Wege denkbar
  • VoiceMail liegt in der Regel in der  Cloud (O365)

Dedicated Forest

Dedicated Forest

Ein Hoster ist aber nicht gezwungen alle Kunden in einem großen Forest zu betreiben. Er kann natürlich problemlos auch für jeden Kunden einen eigenen Forest mit eigener Lync Umgebung aufbauen. Speziell mit größeren Firmen ist dieser Weg interessant, da hier individuelle Anforderungen besser abgedeckt werden können, z.B. MSPL/UCMA-Lösungen. Die Client-CALs sind zum Shared Hosting vergleichbar und es kostet "nur" ein paar Lync Server Lizenzen mehr.

  • Benutzer werden "OnPremise" undin der Cloud verwaltet
    Hilfreich ist ein DirSync, der dieses Abgleichen automatisiert.
  • Lync Properties sind am "Cloud"-Benutzer zu pflegen
  • Authentifizierung erfolgt gegen Cloud-Forest
    Alternativ könnte mit ADFS o.ä. eine Anmeldung an der user Domäne erfolgen.
  • Server stehen "beim Hoster" und werden hier verwaltet'
    Es soll aber auch Hoster geben, die beim Kunden eine "Appliance" hinstellen.
  • TK-Anbindung erfolgt lokal oder beim Hoster
    Technisch sind aber beide Wege denkbar
  • VoiceMail liegt in der Regel beim Hoster

Dieser Betrieb wird z.B. mit dem "Lync Hosting Pack v2" bereit gestellt

Soweit mal ein erster Überblick. Ich habe schon aus Vereinfachungsgründen hier einige Dinge weg gelassen, z.B.

  • TK-Anbindung / Telefonie
  • Exchange UM-Funktion
  • Fax, Telefone, andere Endgeräte
  • Administrative Tätigkeiten bezüglich Server aber auch Clients

Es kann also durchaus noch etwas komplexer werden.

Interessant dabei ist, dass nicht alle Hoster das "Lync Hosting Pack" verwenden und die Kunden auf einer gemeinsamen Plattform betreiben. Diese "Shared Plattform" ist wohl eher für kleine Firmen geeignet, aber wenn eine Firma eine bestimmte Größe überschreitet, dann scheint der Trend eher zu Dedicated Lösungen zu gehen. So eine Lync Umgebung lässt sich per Skript mittlerweile schon hoch automatisiert anlegen.

Anmeldung

Die Benutzer sind angelegt und mit Lync Konfiguration, der Anwender startet seinen Lync Client, gibt seine SIP-Adresse ein und dann kommt die Frage der Authentifizierung. Hier gibt es ebenfalls mehrere Varianten, wie ein Betreiber einer Lync-Plattform die Authentifizierung abbilden kann:

Kurzzeichen Anmeldemodell Beschreibung

Getrennte Anmeldedaten

Der für den Hoster einfachste Weg sind natürlich aktive AD-Konten in seiner Hosting-Umgebung mit eigenen Kennworten. Der Anwender muss sich beim Start von Lync mit dem "Hosting-Kennwort" anmelden und kann Arbeiten.

  • Die Anmeldung funktioniert auch, wenn die OnPremise-Umgebung ein Problem hat.
  • Der Anwender muss sich zwei Kennworte merken und synchron halten.
  • Kennwort-Reset sind je Umgebung anders
  • Entry/Exit-Management: Wird ein Konto deaktiviert, muss es auch in der Cloud angepasst werden

KennwortSync

Über einen DirSync kann auch das Kennwort (als Hash-Wert) übertragen werden

  • Die Anmeldung funktioniert auch, wenn die OnPremise-Umgebung ein Problem hat.
  • Der Anwender muss sich nur ein Kennworte merken und nicht selbst synchron
  • Kein Single-SignOn, Anwender muss Anmeldedaten erneut eingeben

Federation

Office 365 macht es vor, wie Anwender sich an der Cloud per ADFS anmelden. Der Cloud Server verweist den Anwender an den lokalen ADFS-Server um sich ein Ticket zu holen, was dann der Client wieder dem Cloud Server vorzeigt und dieser der kryptografisch gesicherten Information vertraut.

  • Der Anwender muss sich nur ein Kennwort merken
  • Der Kunde muss einen ADFS-Server bereitstellen
  • Die Einrichtung muss die ADFS-Trust-Konfiguration umfassen
  • Anwender muss sich in der Regel am ADFS-Server erneut anmelden

Trust-Account

Lync kennt den Betrieb als Ressourcen-Forest. Dabei werden in einem Forest "deaktivierte" Benutzer angelegt, die einfach die Lync Konfiguration tragen. Über einen Domain Trust aber erfolgt die Anmeldung. Dieser Betrieb ist oft beim "Inhouse-Hosting" üblich, wenn eine Firmengruppe eine gemeinsame Kommunikationsplattform hat, aber jede Tochter doch eigenständig die Anwender verwaltet

  • Anwender muss sich nur am Accocunt-Forest anmelden
  • Einseitiger Trust zwischen Forests erforderlich
  • Provisioning der Ressource Konten muss msRTCOriginatorSID berücksichtigen

Forestaccount

Zuletzt gibt es natürlich noch den ganz klassischen Weg, bei dem das Anmeldekonto auch zugleich das Lync-Konto ist. Das hinderd Sie dennoch nicht, bestimmte Dienste und Server bei einem Hoster zu betreiben.

  • Anwender muss sich nur am Accocunt-Forest anmelden
  • Kein Trust aber Lync-Server und die eigene Domäne reicht auch zum Hoster hinein.
  • Trennung der Zuständigkeiten kann knifflig sein.

Diese vier Anmeldeverfahren können Sie mit einem Teil der Betriebsarten kombinieren.

Provisioning

Mit dem Aufbau des AD ist natürlich auch die Frage verbunden, wie die Anwender bezüglich Lync verwaltet werden. Auch hier gibt es mehrere Abstufungen.

Modell Beschreibung

Manuell per Webseite

Als ersten Schritt einer Verwaltung dient in der Regel einfach eine Webseite, auf der ein Administrator die Benutzer interaktiv verwaltet. Hier wird dann meist auch ein Kennwort hinterlegt, welches komplett losgelöst von einer eigenen AD-Umgebung in der Firma ist. Benutzer müssen das Kennwort bei der Anmeldung angeben und können es z.B. in ihrem Portal bei Bedarf auch ändern.

Skripting

Wenn der Provider etwas fortschrittlicher ist, dann stellt er eine Schnittstelle bereit, über die müssenÄnderungen einfach möglich sind. Das kann wieder ein per Webbrowser gesteuerter CSV-Export/Import sein. Vielleicht gibt es aber auch einen Webservice, eine Remote PowerShell, eine REST-API o.ä., so dass Sie als Kunde per Skript Änderungen umsetzen können

DirSync

Die Kür wäre natürlich ein DirSync, bei dem die Informationen eines lokalen Active Directory als Basis für die Konfiguration beim Hoster genutzt werden.

  • Lokaler Agent (Push)
    Office 365 erlaubt dem Kunden z.B. die Installation eines FIM-Servers, der lokal die Änderungen im AD überwacht und per WebService in der Cloud die Benutzer entsprechend administriert.
  • Remote Pull
    Denkbar wäre aus meiner Sicht auch, dass der Kunde das Active Directory z.B. per ADWS für bekannte IP-Adressen des Providers "veröffentlicht" und der Provider sich dann die Daten per WebService oder LDAP selbst lädt. Das spart eine VM beim Kunden und vor allem hat der Hoster deutlich mehr technische Expertise, wenn hier etwas klemmt

Dies sind aus meiner Sicht die drei häufigsten Modelle, die sich nicht gegenseitig ausschließen, sondern auch in Teilen nebeneinander existieren können.

Weitere Links