Lync Hybrid

Schon 2013 gab es unter dem Namen Hybrid Voice einen Mode mit Lync On-Premise und Online, um Telefonie in die Cloud zu bringen. Das Experiment wurde schnell wieder verworfen. Aber dennoch gibt es einen Lync "Hybrid" Mode, bei dem Benutzer in Office 365 und On-Premise den gleichen SIP-Adressraum nutzen. Diese Seite beschreibt die Zusammenhänge.

Warum ?

Es gibt mehrere Konstellationen, für die Lync Hybrid ein Betriebsmodell oder zumindest ein Migrationsweg. ist. Die Lizenzierung von Office und Lync Clients über Office 365 ist oftmals interessant, so dass eine Firma schon das Recht für den Einsatz von Lync Online hat und so schnell starten kann.

  • Pilot
    Damit ist das erste Szenario schon genannt: Eine Firma kann mit Office 365 und Lync Online sehr schnell einen Lync Piloten starten, der ohne lokale Server beinahe die komplette Funktion bereit stellt. Auf jeden Fall geht Presence und Instant Messaging innerhalb der Firma und per Federation mit allen anderen Lync-Firmen auf Office 365 aber auch On-Premise. Zudem kann fast die komplette Lync Konferenz-Funktion genutzt werden. Selbst eine Konferenzeinwahl ist mit dem passenden Lync ACP (Audio Conference Provider) möglich. Und das alles auf einer hochverfügbaren mit viel Bandbreite versehenen Plattform, die eine kleine Firma On-Premise gar nicht aufbauen kann
  • Features
    Aber Lync Online ist dennoch beschränkt in der Funktion, die nur On-Premise bereit gestellt werden können. primäre ist es natürlich alles um das Thema Telefon. Enterprise Voice ist in der Cloud (noch) nicht möglich, so dass Benutzer mit "Telefonnummer" heute noch auf Lync On-Premise betrieben werden. Damit stellt sich die Frage nach der Migration dieser Benutzer von Office 365 auf eine selbst betriebene Plattform. Auch andere Funktionen wie z.B. Persistent Chat, ResponseGroup oder API-Zugriffe (UCMA, MSPL etc.) sind in der Cloud nicht möglich.
  • Netzwerk
    Die schöne Cloud ist immer dann von Nachteil, wenn viele Personen interne Meetings nutzen und daher die Audio/Video-Daten aller Benutzer durch die Internetanbindung in die Cloud müssen. Das kann eine Internetanbindung einer Firma schon überfordern, speziell wenn es keine lokalen Breakouts in die Cloud gibt und die Daten noch über das interne WAN müssen. In Verbindung mit dezentralen Internet-Breakouts ist aber die Cloud gerade wieder eine Chance solche Audio/Video-Daten nicht über das eigene WAN zu routen.
  • Standort
    Der Standort ist aber ein weiterer Aspekt, da ein Tenant immer genau in einer Region angesiedelt ist. Wenn eine Firma in Deutschland mit Office 365 arbeitet, dann sind die Datacenter in Europa (Aktuell Amsterdam/Dublin). Wer weltweit aufgestellt ist und auch viele Benutzer z.B. in Asien hat, wird die Laufzeit der Pakete stören. Eine On-Premise-Installation kann mit lokalen Pools hier flexibler agieren.

Es gibt also einen Bedarf für einen Hybridmode um Lync Online mit einer On-Premise-Plattform zu verbinden.

Feature

Durch die Verbindung einer Lync On-Premise und der Lync Online-Welt können Sie jeden Benutzer auf der Plattform betreiben, die ihm die erforderlichen Funktionen bereit stellt. Und es ist schon abzusehen, dass zukünftig auch die On-Premise-Anwender durch eine Hybrid-Kopplung weitere Dienste nutzen können. Beide Welten haben eine sehr großen Überlappung bei den Funktionen aber es gibt einige Funktionen, die nicht auf jeder Plattform vorhanden sind.

Feature Lync 2013 On-Premise Lync Online

Persistent Chat

Anzahl der Teilnehmer in einem Meeting

1000

250

Telefoneinwahl in eine Konferenz

Über Lync ACP

Federation mit IBM Sametime und andere XMPP Dienste

CAC, QoE, Media Bypass, QoS

Enterprise Voice, Survivability Branch Appliance

API: UCMA, Trusted Application, Trusted Server

Damit sind einige Benutzer schon auf eine ZielUmgebung festgelegt. Wer also unbedingt Enterprise Voice nutzen will, kann nicht in der Cloud arbeiten.

Vorab

Ein paar wichtige Punkte zur Erinnerung und Abhaken:

Vorbedingung Status

Beide Plattformen sind "Ready"

Hybrid wird erst eingerichtet, nachdem beide Lync Umgebungen betriebsbereit sind. Alle Vorarbeiten wie Planung, Sizing, Installation, Konfiguration, Netzwerk Readyness etc. müssen bereits erfolgt sein, ehe Sie an die Einrichtung von Hybrid gehen.

Edge und Reverse Proxy

Die On-Premise-Installation muss zwingend mit einem Edge-Server und einem Reverse Proxy versehen sein, damit Hybrid funktioniert. Die Verbindung erfolgt über die Edge-Server

DNS verweist auf On-Premise

Nur die Lync On-Premise-Installation ist in der Lage, den Hybrid-Mode zu verwalten. Daher werden alle DNS-Einträge während des Hybrid-Mode immer auf die On-Premise-Umgebung verweisen. Wer also mit Lync On-Premise beginnt, wird das schon habe. Wer aber mit Lync Online begonnen hat, wird im Prozess umstellen müssen und sollte schon sicher sein, dass alles korrekt gesetzt ist

SIP Domains identisch

Für die Funktion ist es essentiell, dass alle SIP-Domänen in beiden Welten identisch sind. Sollte dies nicht sein, wird die Federation nicht sauber funktionieren und wenn ein Benutzer in die Cloud verschoben wird, dessen SIP-Domain dort nicht gepflegt wird, dann erhält er in der Cloud eine "tenantname.onmicrosoft.com"-Adresse und damit ist der Benutzer nicht mehr synchron.

Static Route On-Premise

In Lync können SIP-Routen eingetragen werden, z.B. Um Video-Konferenzsysteme einzubinden (SIP:user@video.<sipdomain.tld> via Gateway). Dies wird mit Hybrid nicht zuverlässig funktionieren

DirSync mit AD-Accounts zwingend

Für die Funktion des Hybrid Mode ist es essentiell, dass die Lync Benutzer der On-Premise-Umgebung in die Cloud synchronisiert werden. Sie müssen die Benutzer mit Lync Online immer Active Directory Benutzer sein. Der Betrieb mit "Azure-AD"-Benutzern funktioniert nicht, da diese Objekte nicht auf die "On-Premise"-Umgebung repliziert werden und daher die On-Premise-Server diese Benutzer nicht zur Cloud weiterleiten können.

Durch die Einrichtung eines Hybrid-Mode wird es daher auch Änderungen in den internen Prozessen der Benutzerverwaltung geben, die kontinuierlich berücksichtigt werden müssen

Hybrid einrichten

Um ihnen und mir die Einrichtung möglichst fehlerfrei zu ermöglichen, habe ich wieder meine Checkliste zur Einrichtung veröffentlicht, in der eigene Erfahrungen und zusätzliche Informationen einfließen.

Schritt Status

Tenant beantragen

Eigentlich eine Selbstverständlichkeit, aber um Hybrid einzurichten, benötigen Sie ein Office 365 Tenant.

Lync On-Premise einrichten

Wenn Sie bislang nur Office 365 genutzt haben, müssen Sie natürlich die komplette Lync On-Premise Umgebung aufbauen. Stellen Sie in dem Fall aber noch nicht den DNS-Eintrag auf die On-Premise Umgebung um.

Anmeldedaten

Um die Hybrid-Bereitstellung zu konfigurieren, müssen Sie sowohl On-Premise als auch in der Cloud einen Lync Admin haben. Prüfen Sie vorher, dass Sie die Rechte haben. Es ist unschön, wenn man auf der Hälfte des Wegs nach Zugangsdaten suchen muss.

SIP-Domains abgleichen

Für den Hybrid-Mode ist es zwingend erforderlich, dass die SIP-Domains On-Premise und auf der Cloud identisch sind. Gleichen Sie daher die SIP-Domänen in beiden Welten ab und stellen Sie auch sicher, dass die dauerhaft so bleibt.

DirSync

Die Identitäten On-Premise und in der Cloud müssen synchron sein. Das einzige Werkzeug hierzu ist der Office 365 Verzeichnisabgleich (Aktuell DirSync oder ADSync). Beachten Sie, dass Sie dazu vorher auf jeden Fall auch die Objekte "aufräumen" sollten. Siehe auch Office 365:DirSync Check.

ADFS

Kaum jemand wird einen Hybrid Mode mit getrennten Anmeldedaten in der Cloud benutzten. Solange DirSync mit Office 365':Password Sync mit Lync nicht funktioniert, ist ein ADFS-Server der einzige Weg aktuell ein "Sigle SignOn" bereitzustellen.

On-Premise: Edge Federation einrichten

Für den Hybrid Mode muss eine Edge-Federation mit Office 365 eingerichtet werden. Eventuell ist die schon der Fall, aber prüfen Sie dies auf jeden Fall:

Hinweis
Diese Einstellung erlaubt auch den externen Zugriff und Federation im allgemeinen. Ggfls. müssen Sie die Policies pro Benutzer zur Verwendung des Edge-Servers anpassen.

# Edge fuer Federation bereit machen
set-CSAccessEdgeConfiguration `
   -allowOutsideUsers $true `
   -allowFederatedUsers $true `
   -EnablePartnerDiscovery $true `
   -UseDnsSrvRouting

#Lync Online als Hosting Provider einstellen
# Alten Eintrag eventuell entfernen
Remove-CsHostingProvider -Identity LyncOnline

# Neuen Eintrag anlegen, wenn noch nicht da
New-CSHostingProvider `
   -Identity "Skype For Business Online" `
   -ProxyFqdn "sipfed.online.lync.com" `
   -Enabled $true
# Werte setzen
Set-CSHostingProvider `
   -Identity "Skype For Business Online" `
   -Enabled $true `
   -EnabledSharedAddressSpace $true `
   -HostsOCSUsers $true `
   -VerificationLevel useSourceVerification `
   -IsLocal $false `
   -AutodiscoverURL https://webdir.online.lync.com/Autodiscover/AutodiscoverService.svc/root

Damit kennt nun die Lync On-Premise Umgebung den Weg zu Office 365 und lässt auch Federation zu.

Office 365 für SIP-Sharing aktivieren

In diesem Schritt weisen Sie die Office 365 Umgebung an, dass die SIP-Domänen in der Cloud nicht exklusiv sind, sondern es ein "Sharing" der SIP-Domäne gibt. Dazu ist eine Remote PowerShell auf die Office 365 Umgebung erforderlich.

$cred = Get-Credential
$session = New-CsOnlineSession -Credential $cred
Import-PSSession $session

Set-CSTenantFederationConfiguration `
   -SharedSipAddressSpace $true

Sie sehen, dass die Einstellung global für den Tenant ist und nicht pro SIP-Adresse definiert wird. Danach wird die Cloud alle Zugriffe auf SIP-Adressen, die nicht lokal vorliegen, über die DNS-Einträge auf die On-Premise-Umgebung weiter reichen. Er also mit Lync On-Premise gestartet hat, ist hier auf der sicheren Seite. Wer aber mit Lync Online begonnen hat, sollte hier noch nicht die DNS-Einträge ändern, denn On-Premise gibt es vielleicht noch keine user, die wieder in die Cloud verweisen.

Cloud-Benutzer "On-Premise anlegen

Für den Fall, dass Sie zuerst mit Office 365 gestartet sind, dann sollten Sie nun zuerst alle Benutzer aus Office 365 auch in ihrer "On-Premise-Umgebung" aktivieren und in die Cloud verweisen lassen.

Enable-CSUSer `
  -identity "Username" `
   -SIPAddress "sip:username@msxfaq.de" `
   -hostingproviderProxyFQDN "sipfed.online.lync.com"

Dies ist natürlich nicht erforderlich, wenn Sie bislang mit Lync On-Premise gearbeitet habe und Benutzer in die Cloud verschieben wollen.

Wenn wirklich alle Benutzer in der On-Premise-Umgebung vorhanden sind und der DirSync die Einträge auch mit der Cloud abgeglichen hat, dann können Sie die DNS Einträge auf ihre "On-Premise"-Umgebung umstellen, sofern dies nicht schon immer der Fall war. Siehe dazu auch Hybrid to Cloud

Edge-Namensauflösung

Beachten Sie dabei auch, dass der Eintrag "_sipfederationtld._tcp.<domain>" von ihrem eigenen Edge-Server auch auflösbar sein muss. Das ist immer dann der Fall, wenn der Edge externe DNS-Server abfragt und der Weg zu den internen Servern per HOSTS-Datei bekannt gemacht wird. Wenn der Edge aber per DNS interne Server fragt, die dann per Forwarder das Internet auflösen, dann ist mit Split-DNS-Konfiguration nicht automatisch der Fall.

Damit ist die serverseitige Konfiguration zu Lync Hybrid abgeschlossen

Benutzermanagement

In einer reinen Office 365 Umgebung werden Benutzer für Lync dadurch aktiviert, dass diese eine Lizenz zugewiesen bekommen, in der Lync Online enthalten ist. Kurze Zeit später erscheinen die Benutzer auch in der Lync Verwaltung und können weiter konfiguriert werden. Allerdings sind die Einstellmöglichkeiten hier deutlich beschränkt und die SIP-Adresse kann schon gar nicht geändert werden. Der UPN des Benutzers wird automatisch zur SIP-Adresse.

When a user’s Office 365 sign-in address (also known as the user Principal Name, UPN, or user ID) is changed, the Lync Online SIP address für the user is automatically synchronized. Previously, when a user’s Office 365 sign-in address was changed, the IT administrator had to Update the user's SIP address separately to match the new Office 365 sign-in address. Otherwise, the two values would be mismatched. A mismatch between a user ID and the user's SIP address may cause confusion für the Lync Online user during sign in.
Quelle: 2537764 Considerations für Lync Online when you change an Office 365 sign-in address

Das bedeutet natürlich, dass alle Benutzer aus dem AD den "richtigen" UPN haben müssen und Sie dann in der Cloud einfach "aktiviert" werden können.

Beachten Sie bitte, dass die Benutzer auch wirklich in der Cloud ankommen. Auf der Seite Office 365:DirSync Setup habe ich exemplarisch gezeigt, wie man z.B. das Feld "Mail" als zusätzlichen Filter benutzen kann. Wenn aber nun ihre Anwender "nur" Lync aber kein Exchange machen, ist so ein Filter natürlich anzupassen.

Ein Benutzer, der in der Cloud ist, ist im Lync Control Panel auch sichtbar:

Selbst auf den Benutzer können Dinge eingestellt werden, die (noch) keinen Sinn machen:

Wobei der Eintrag einer LineURI schon sinnvoll ist, z.B. damit der Benutzer im Lync Adressbuch auch diese Nummer hat und über Reverse Name Lookup bei der Wahl der Nummer z.B. der Lync Client per SIP angesprochen wird.

Umgekehrt können Sie in Lync Online aber nur die Benutzer sehen, die auch auf Lync Online gehostet sind. Per PowerShell können Sie aber sehr wohl die komplette Liste erstellen. Die On-Premise User sind natürlich in der Cloud bekannt.

Hinweis
Get-CSOnlineUser liefert alle Lync Objekte in der Cloud, d.h. auch solche, die keine user ist, z.B. Responsegroups und andere Objekte, die aus der On-Premise-Welt per DirSync in der Cloud angelegt werden.

Es gibt zwei Fälle bei der Verwaltung der Benutzer:

Szenario Beschreibung

Benutzer mit Lync On-Premise

  1. Der Benutzer wird ganz klassische "On-Premise" im AD angelegt
  2. Der Benutzer wird in Lync "On-Premise" entsprechend aktiviert
  3. Der DirSync legt den Benutzer in der Cloud an und überträgt die AD-Properties

Das ist im DirSync problemlos zu finden:

Damit wird die Lync Information dieses Benutzers in der Cloud bekannt gegeben und entsprechend den Anwender dprt auch bereit gestellt.

Benutzer mit Lync in der Cloud

Umgekehrt ist es etwas komplizierter.

  1. AD-Benutzer anlegen
    Zuerst muss der Benutzer natürlich "On-Premise" erst mal als AD-Benutzer angelegt und mittels DirSync in Office 365 übertragen werden.
  2. Office 365 Lizenz zuweisen
    Ohne Lizenz kann der Benutzer in Office 365 sich nicht anmelden. Das Zuweisen einer Lizenz aktiviert den Benutzer aber schon für Lync, obwohl die Umgebung "On-Premise" ihn noch nicht kennt. Der Zustand sollte nur kurz anhalten.
  3. User auf Lync On-Premise aktivieren
    Hierzu ist die PowerShell erforderlich, um On-Premise einen Eintrag zu setzen
Enable-CSUSer `
   -identity "nawdemo365b" `
   -SIPAddresstype EMaiLAddress `
   -hostingproviderProxyFQDN "sipfed.online.lync.com"

Auch wenn es nicht mehr erforderlich wäre, wird diese Änderung durch den DirSync erkannt und in die Cloud übertragen:

Aber mit Lync arbeiten kann der Benutzer dennoch erst, wenn er in der Cloud auch eine Lizenz bekommen hat.

Die Reihenfolge ist eigentlich egal, da das On-Premise AD aktuell immer der Master ist und die Replikation der Lync Properties im Gegensatz zu Exchange Hybrid nur in Richtung Cloud funktioniert. Wer aber einen Lync Online Benutzer aber On-Premise nicht anlegt oder die Verbindung dort löscht, hat immer noch einen "aktiven Benutzer" in der Cloud, der sich aber nicht mehr anmelden kann.

Der Office 365 DirSync kann weder die Lizenzen noch die Region für die Lizenz zuweisen. Dies ist also ein zweiter Schritt, den Sie ggfls. per Skript automatisieren müssten.

Denken Sie bitte daran, dass auch Lync Online-Benutzer weitere Properties haben, die konfiguriert werden können. Diese sind nicht "On-Premise" einstellbar und werden erst recht nicht durch den DirSync in der Cloud nachgehalten.

Kleiner Tipp hierzu: Im Lync Admin Center erhalten Sie die Anzahl der Benutzer, die per DirSync abgeglichen werden. Idealerweise ist diese Zahl ganz nahe an der Zahl der Online user.

Die reinen OnlineUser sind dann nur die Benutzer, die losgelöst vom DirSync mit der SIP-Domäne "<tenant>.onmicrosoft.com" betrieben werden.

Benutzer Provisioning per Skript

In der Regel starten Sie mit Skype for Business "On-Premise" und addieren die Cloud später dazu. Es kann aber auch anders herum passieren, dass eine Firma z.B. Skype for Business Online getestet hat aber nun auch On-Premise nutzen will. Sie können hier problemlos Hybrid einrichten aber die DNS-Einträge dürfen Sie erst dann umstellen, wenn die lokale Umgebung steht. Dazu gehört aber nicht nur der Edge-Server sondern auch die Benutzer, die per DirSync in die Cloud repliziert werden. Sie müssen also für jeden lokalen Benutzer, der noch in Office 365 mit Skype for Business Online arbeitet, lokal die entsprechenden Einträge setzen. Ansonsten wird der Client nach dem Schwenk der DNS-Einträge nicht mehr in die Cloud verwiesen.

In Office 365 gilt die Regel, dass der UPN zugleich auch die SIP-Adresse ist und so ist es relativ einfach, vor dem Schwenk der DNS-Einträge alle Benutzer, die sie heute schon in Office 365 haben, auch lokal anzulegen. Sie könnten Sich die Benutzer natürlich aus der Skype for Business Online Powershell holen. Ich habe hier den schnellen Weg gewählt, auf eine Gruppe zu filtern, die beim ADDSync als Filter genutzt wird. Sie können natürlich andere Filterkriterien nutzen oder das Skripte mit einer Office 365 Anbindung ausbauen.

# Aktivieren aller User in AADConnect für SfBOnline, wenn Sie nicht schon lokale sind
Get-ADGroup `
   -Filter {SamAccountname -eq "o365sync"} `
| get-adgroupmember `
| get-aduser `
   -properties * `
| where {$_."msRTCSIP-UserEnabled" -eq $null} `
| foreach { `
   Enable-CSUSer `
      -identity $_.UserPrincipalName `
      -SIPAddresstype UserPrincipalName `
      -hostingproviderProxyFQDN "sipfed.online.lync.com" `
   }

Auf Dauer sollten Sie natürlich ihr Provisoining generell darauf ausrichten, dass es die lokalen AD-Objekte mit dne richtigen Werten versieht, damit AADSync diese in die Cloud übertragen kann und die Funktion damit möglich ist.

Benutzer verschieben

Wenn die Hybrid-Installation abgeschlossen ist, können natürlich nicht nur Anwender auf beiden Seiten angelegt sondern eben auch verschoben werden. Auch hierzu ist aktuell noch die PowerShell erforderlich (Feb 2015), da weder das On-Premise Controlpanel noch die Cloudversion entsprechende Funktionen anbietet. für die Migration muss aber eine Service-URL angegeben werden, die abhängig vom Tenant unterschiedlich sein kann. Sie müssen sich als Office 365 Admin daher erst einmal am Lync Admin Center in der Cloud anmelden und dann aus dem Browser einen Teil der URL übernehmen:

In diesem Beispiel ist der Hostname ein "admin0a.online.lync.com". Als Pfad wird aber nun ein "/HostedMigration/hostedmigrationservice.svc" angehängt. Die URL ist dann also:

Mit dieser URL in den Berechtigungen eines Office 365 Administrators können Sie dann Benutzer verschieben.

Achtung:
Der Benutzer muss in Office 365 zuerst eine Lizenz erhalten haben, da ansonsten der Move mit einem Fehler abgebrochen wird:

$cred = Get-Credential
Move-CsUser `
   -Identity <user's AD UPN> `
   -Target sipfed.online.lync.com `
   -Credential $cred `
   -HostedMigrationOverrideURL <Hosted migration override URL fuer den eigenen tenant>

Nach einer Sicherheitsabfrage, die man mit "-confirm" auch noch vorgeben kann, wird der Benutzer dann "sehr schnell" verschoben. Schnell daher, da über Lync ja nicht wirklich viele Daten zu übertragen sind.

Auch in die Gegenrichtung wird einfach migriert. Dabei wird nur der lokale "On-Premise"-Pool als Target angegeben, die URL für den Webservice, der die Migration durchführt, bleibt der Office365 Service.

$cred = Get-Credential
Move-CsUser `
   -Identity <user's AD UPN> `
   -Target <On-Premise-Pool-FQDN> `
   -Credential $cred `
   -HostedMigrationOverrideURL <Hosted migration override URL fuer den eigenen tenant>

Vergessen Sie nicht nach der Migration des Benutzers die Lync Online Lizenz in der Cloud ggfls. wieder frei zu geben.

Der DirSync hat mit dieser Verschiebung übrigens nichts zu tun. Er wäre mit seinem Scanintervall von 6h auch viel zu langsam. Das Lync Commandlet aktualisiert die Eigenschaften "On-Premise" und in der Cloud. Wenn der DirSync später dann einen "Change" erkennt, dann ändert sich nichts mehr.

Entsprechend gibt es wenige Punkte zu beachten:

  • Unterbrechung für den Anwender
    Sobald die Verschiebung passiert ist, verliert der Lync Client die Verbindung, da der bisherige Server nicht mehr die "UserServices" bereit stellt. Der Client muss sich also neu verbinden und geht damit wieder mit Lyncdiscover und DNS-Anfragen gegen die "On-Premise" Umgebung, die ihn zum richtigen Server sendet. Das kann einige Minuten dauern, bis nach einer  Verschiebung die Änderung im AD repliziert und dann über den UserReplikator letztlich in der Lync Datenbank angekommen ist. Einige Minuten sind da durchaus möglich
  • Buddyliste
    Bei der Migration von On-Premise in die Cloud werden die Buddy-Listen mit übertragen.
  • MeetingURLs
    Durch den Wechsel auf einen anderen Pool ändert sich aber die MCU des Anwenders und damit werden alle seine Meeting-URL's und IDs ungültig. Der Anwender sollte daher alle geplanten Termine neu einplanen und ein Update an die Teilnehmer versenden.
  • Meeting Content
    Wenn der Anwender in Vorbereitung auf ein Meeting z.B. eine PowerPoint-Datei schon hochgeladen oder umfragen erstellt hat, dann sind die nach dem Move natürlich auch hinfällig und müssen neu erstellt werden
  • Enterprise Voice
    Der Move-Befehl prüft vorher nicht ab, ob der Benutzer Funktionen nutzt, die in Lync Online nicht vorhanden sind. Als Admin wissen Sie ja, was sie tun.

Generell muss man schon sagen, dass Lync Hybrid recht gut funktioniert aber Fehlkonfigurationen nicht aktiv verhindert werden. Wer also einen user in der Cloud mit einer Lync Lizenz versieht und vergisst, diesen "On-Premise" als "Hosted user" zu addieren, wird vermutlich einige Zeit suchen, wenn der Anwender sich nicht anmelden kann.

Anmeldung

Wie schon weiter oben beschrieben funktioniert Lync Hybrid derart, dass alle DNS-Einträge auf die On-Premise-Umgebung verweisen. Damit ist auch klar, was jeder Client beim Anmelden durchführt:

  • Ein alter Client erreicht die On-Premise-Umgebung über die DNS-Abfragen nach _sip._tls.<sipdomain> und wird durch die On-Premise-Umgebung auf die Office 365 Umgebung umgeleitet
  • Ein neuer Client fragt nach "LyncDiscover" und erhält so die neue Adresse der Server zur Anmeldung

Die Anmeldung selbst erfolgt dann auch zweimal

  • Lync On-Premise
    Damit der Lync On-Premise-Server den Client ggfls. Umleiten kann, muss der Client sich erst mal Authentifizieren. Das geht ganz klassische über die Lync Anmeldungen per SIP bzw. die Webservices. Wenn der Client dann nicht On-Premise ist, gibt es eine Weiterleitung in die Cloud
  • Anmeldung an der Cloud
    Diesmal will dann natürlich auch die Lync Umgebung in der Cloud gerne wissen, wer hier Zugang begehrt und fordert vom Client die Anmeldedaten ab. Der Client holt sich ein ADFS-Ticket und meldet sich damit in de Cloud an. Sollte ADFS nicht vorhanden sein, dann muss das Kennwort des Kontos in der Cloud angegeben werden. Leider funktioniert das im Feb 2015 noch nicht mit einem durch DirSync kopiertem Kennwort.

Internals

Für die Hybrid-Bereitstellung gibt es ein paar wesentliche Dinge:

  • SIP-Routing Richtung Cloud
    Dies erfolgt über den Edge Server, wobei die On-Premise Umgebung immer führend ist und hier die Benutzer in der Cloud quasi mit einer Weiterleitungsadresse im Feld "msRTCDeploymentLocator" versehen sind. Das ist durchaus mit dem Feld "TargetAddress" bei Exchange vergleichbar. Damit weiß der Lync Server "On-Premise", dass diese Empfänger über den Edge und Federation in der Cloud zu erreichen sind.
  • SIP Routing von der Cloud
    Umgekehrt wird der Cloud per PowerShell gesagt, dass Sie nicht mehr alleine für die Domänen autoritativ ist. Dort gibt es ebenfalls die Verweise für Benutzer die nun "On-Premise" liefen. Mittels Get-CSOnlineUser können Sie dies auch sehen. Aus der Cloud zur On-Premise-Umgebung helfen die DNS-Einträge im Internet, die auf den Edge Server der On-Premise-Umgebung verweisen
  • LDAP-Konfiguration
    Damit die Verweise bezüglich SIP-Leitwege zum Tragen kommen, müssen die Benutzer in beiden Welten entsprechend konfiguriert sein. Dazu zählen eigentlich nur ein paar LDAP-Felder

Interessant sind folgende Felder mit ihren Werten (Jeweils die Werte im On-Premise AD)

Feld Cloud Only Hybrid Cloud user Hybrid Local user

msRTCDeploymentLocator

<leer>

sipfed.online.lync.com

SRV:

msRTCSIP-PrimaryHomeServer

<leer>

cn=LC Services...(lokaler Pool)

cn=LC Services...(lokaler Pool)

msRTCSIP-Userenabled

<leer>

True

True

Im Azure AD sind die Werte nicht direkt per LDAP auslesbar. Aber ein get-csonlineuser  liefert erweiterte Daten. Die Ausgaben hier sind

Feld Cloud Only User Hybrid User

HostingProvider

SRV:

SRV:

RegistrarPool

sippoolsn20a06.infra.lync.com

$null

OnPremHostingProvider

$null

SRV:

OnPremOptionFlags

0

z.B. 385

OnPremSIPEnabled

$null

$True

OnPremSipAddress

$null

sip:user@domain.tld

OnPremLineURI

 

 

Hier ist also gut zu sehen, dass auch in der Cloud hier wieder neben dem User ein weiteres Feld dafür sorgt, dass SIP-Meldungen aus der Cloud nach extern weiter gegeben werden. Das ist vergleichbar zum Feld "TargetAddress" in Exchange.

Weitere Links