Skype for Business Hybrid Mode

Schon 2013 gab es unter dem Namen Hybrid Voice einen Mode mit Lync On-Prem 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-Prem 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-Prem. 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-Prem gar nicht aufbauen kann.
  • Features
    Aber Lync Online ist dennoch beschränkt in der Funktion, die nur On-Prem 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-Prem 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-Prem-Installation kann mit lokalen Pools hier flexibler agieren.

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

Feature

Durch die Verbindung einer Lync On-Prem 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-Prem-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-Prem 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-Prem-Installation muss zwingend mit einem Edge-Server und einem Reverse Proxy für die LyncWeb-Webseite  versehen sein, damit Hybrid funktioniert. Die Verbindung erfolgt über die Edge-Server.

DNS verweist auf On-Prem

Nur die Lync On-Prem-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-Prem-Umgebung verweisen. Wer also mit Lync On-Prem 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.

Edge-Namensauflösung für sich selbst

Beachten Sie dabei auch, dass der Eintrag "_sipfederationtls._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.

_sipfederationtls._tcp im internen LAN

Eigentlich ist es nicht erforderlich, dass ein interner Server den Federation-Eintrag extern auflöst. Zumal bei einer "Closed Federation" der Eintrag vielleicht gar nicht da ist. Dennoch scheint das Fehlen dieses Eintrags die Federation zu stören.

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-Prem

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.

Get-CsStaticRoutingConfiguration

DirSync mit AD-Accounts zwingend

Für die Funktion des Hybrid Mode ist es essentiell, dass die Lync Benutzer der On-Prem-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-Premises-Umgebung repliziert werden und daher die On-Prem-Server diese Benutzer nicht zur Cloud weiterleiten können.

Prüfen Sie dies einfach durch ein Vergleich der Ausgaben von:

get-csonlineuser | group HostingProvider -NoElement
get-csouser      | group HostingProvider -NoElement

Die Werte sollten übereinstimmen. Durchaus auch ein Test, der per Monitoring immer mal wieder durchgeführt werden kann, um AADConnect zu prüfen.

Federation

Hinsichtlich Federation sind noch einige Einstellungen erforderlich

 

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.

Skype for Business/Lync On-Prem einrichten

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

Anmeldedaten

Um die Hybrid-Bereitstellung zu konfigurieren, müssen Sie sowohl On-Prem 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-Prem 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.

Verzeichnisabgleich (ADSync)

Die Identitäten On-Prem 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.

Authentifizierung

Kaum jemand wird einen Hybrid Mode mit getrennten Anmeldedaten in der Cloud benutzten. Also wollen Sie die Anmeldung an den Cloud-Diensten mit dem lokalen Active Directory verbinden. Das geht über Pass-Through Authentifizierung (PTA), Password Hash Sync (PHS). Wenn Sie ein Signle SignOn möchten, dann geht das per ADFS oder Seamless Single Sign On.

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. Ich mache das in der Regel zuerst, da in der Cloud meist nur ein paar Testanwender sind und daher die Änderung niemand stört und etwas braucht, bis sie aktiv ist.

$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-Prem-Umgebung weiter reichen. Er also mit Lync On-Prem 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-Prem gibt es vielleicht noch keine User, die wieder in die Cloud verweisen.

On-Prem: Edge Federation einrichten

Im zweiten Schritt muss ich dann natürlich dafür sorgen, dass die On-Premises Umgebung die Pakete der Cloud auch annimmt.

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
Get-CsHostingProvider `
| ?{ $_.ProxyFqdn -eq "sipfed.online.lync.com" } `
| Remove-CsHostingProvider 

# Neuen Eintrag anlegen

New-CsHostingProvider `
   -Identity Office365 `
   -ProxyFqdn "sipfed.online.lync.com" `
   -Enabled $true -EnabledSharedAddressSpace $true `
   -HostsOCSUsers $true `
   -VerificationLevel UseSourceVerification `
   -IsLocal $false `
   -AutodiscoverUrl https://webdir.online.lync.com/Autodiscover/AutodiscoverService.svc/root

Damit kennt nun die Skype for Business  On-Prem Umgebung den Weg zu Office 365 und lässt auch Federation zu.

Cloud-Benutzer On-Premises 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-Premises-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-Prem gearbeitet habe und Benutzer in die Cloud verschieben wollen.

Wenn wirklich alle Benutzer in der On-Prem-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-Premises -Umgebung umstellen, sofern dies nicht schon immer der Fall war. Siehe dazu auch Hybrid to Cloud.

Damit ist die serverseitige Konfiguration zu Skype/Teams 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-Prem 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-Prem-Welt per DirSync in der Cloud angelegt werden.

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

Szenario Beschreibung

Benutzer mit Lync On-Prem
  1. Der Benutzer wird ganz klassische On-Premises im AD angelegt
  2. Der Benutzer wird in Lync On-Premises 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.

  • AD-Benutzer anlegen
    Zuerst muss der Benutzer natürlich On-Premises erst mal als AD-Benutzer angelegt werden.
  • User On-Prem aktivieren
    Hierzu ist die PowerShell erforderlich, um On-Prem einen Eintrag zu setzen
Enable-CSUser `
   -identity "nawdemo365b" `
   -SIPAddresstype EMaiLAddress `
   -hostingproviderProxyFQDN "sipfed.online.lync.com"
  • Weiteres Provisioning, z.B. Exchange
    Siehe Exchange Online Provisioning
  • ADSync repliziert
    Wenn die lokalen Einstellungen komplett sind, dann darf ADSync auch die Objekte in die Cloud synchronisieren. Hier sehen Sie dann auch die Felder
     

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

  • 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-Premises ihn noch nicht kennt. Der Zustand sollte nur kurz anhalten.
  • Teams Konfiguration
    Allerdings werden nicht alle Einstellungn durch das lokale Actie Directory vorgegeben. Es bleibt schon noch etwas Arbeit mit der SfB ONline PowerShell, z.B. Richtlinien zuweisen oder den Interop Mode auf "Teams Only" zu setzen.

Die Reihenfolge ist eigentlich egal, da das On-Prem 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-Prem 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-Premises 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-Premises 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-Prem 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 Provisioning generell darauf ausrichten, dass es die lokalen AD-Objekte mit den richtigen Werten versieht, damit ADSync diese in die Cloud übertragen kann und die Funktion damit möglich ist.

Benutzer verschieben

Siehe dazu auch Hybrid to Cloud

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-Prem Control Panel noch die Cloud-Version 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:

https://admin0a.online.lync.com/HostedMigration/hostedmigrationservice.svc

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-Premises-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-Prem-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-Premises 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-Premises 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-Prem 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. Wenn das Postfach in Exchange Online ist, kann Exchange die Meetings alleine aktualisieren. Ansonsten gibt es das "Skype for Business (Lync) Meeting Update Tool " https://support.office.com/de-de/article/skype-for-business-lync-meeting-update-tool-2b525fe6-ed0f-4331-b533-c31546fcf4d4
  • 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-Premises 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-Prem-Umgebung verweisen. Damit ist auch klar, was jeder Client beim Anmelden durchführt:

  • Ein alter Client erreicht die On-Prem-Umgebung über die DNS-Abfragen nach _sip._tls.<sipdomain> und wird durch die On-Prem-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-Prem
    Damit der Lync On-Prem-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-Prem 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-Prem 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-Premises, 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-Premises liefen. Mittels Get-CSOnlineUser können Sie dies auch sehen. Aus der Cloud zur On-Prem-Umgebung helfen die DNS-Einträge im Internet, die auf den Edge Server der On-Prem-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-Prem 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.

Fehlerbilder

Hier sammle ich die ein oder anderen Fehlerbilder, die sie sehr einfach mit den UCCAPI-Log (Siehe Lync Keyhole Diagnose) ermitteln können.

Wenn Sie von On-Premises den Status eines Benutzers in der Cloud abfragen wollen, dann sendet ihr Client einen "SUBSCRIBE" an die SIP-Adresse und die Antwort darauf sollte ein "200 OK" sein. Denkbar ist aber auch:

05/29/2017|20:15:19.755 4598:459C INFO  :: SIP/2.0 404 Domain is not hosted by this service
ms-User-logon-data: RemoteUser
Authentication-Info: TLS-DSK qop="auth", opaque="6D8666BB", srand="492922CB",
    snum="42", rspauth="xxxxxxxxxxxxxx",
    targetname="EPGLBSBv002.icig.global", realm="SIP Communications Service", version=4
From: "UserOnPrem"<Useronprem@uclabor.de>;tag=f0a9af3799;epid=2ee09eca55
To: <Useronline@uclabor.de>;tag=9925237F3A3B3541468D1774C15F64C9
Call-ID: 2e13aa908012417da0b35d002779861e
CSeq: 1 SUBSCRIBE
Via: SIP/2.0/TLS 172.17.8.243:58472;received=185.207.63.18;
   ms-received-port=16838;ms-received-cid=7CF100
ms-telemetry-id: B46E47E9-059F-5BD1-9A40-5D3AE4F2A668
Server: RTC/7.0
Content-Length: 0
ms-diagnostics: 1036;
   reason="Previous hop shared address space peer did not report diagnostic information";
   Domain="uclabor.de";PeerServer="sipfed.online.lync.com";source="sip.uclabor.de"
05/29/2017|20:15:19.755 4598:459C INFO  :: End of Data Received -80.66.20.21:5061 (To Local Address: 172.17.8.243:58472) 976 bytes

Die Fehlermeldung "404 Domain is not hosted by this service" in der ersten Zeile sagt z.B. dass die Domäne in Office 365 nicht für die Verwendung mit Skype for Business aktiviert ist. Im Office 365 Admin-Center können Sie die Verwendung pro Domäne und Dienst konfigurieren:

Das Ergebnis ist, dass On-Premises Anwender den Präsenzstatus eines Office 365 Benutzers nicht sehen können.

Weitere Links