Lync Hybrid

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

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

Feature

Durch die Verbindung einer Lync OnPremise 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 OnPremise-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 OnPremise 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 OnPremise-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 OnPremise

Nur die Lync OnPremise-Installation ist in der Lage, den Hybrid-Mode zu verwalten. Daher werden alle DNS-Einträge während des Hybrid-Mode immer auf die OnPremise-Umgebung verweisen. Wer also mit Lync OnPremise 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 OnPremise

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 OnPremise-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 "OnPremise"-Umgebung repliziert werden und daher die OnPremise-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 OnPremise einrichten

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

Anmeldedaten

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

OnPremise: 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 `
   -UseDnsSrvRouting

#Lync Online als Hosting Provider einstellen
Remove-CsHostingProvider -Identity LyncOnline

New-CSHostingProvider `
   -Identity LyncOnline `
   -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 Lync OnPremise 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 OnPremise-Umgebung weiter reichen. Er also mit Lync OnPremise 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 OnPremise gibt es vielleicht noch keine user, die wieder in die Cloud verweisen.

Cloud-Benutzer "OnPremise anlegen

Für den Fall, dass Sie mit Office 365 gestartet sind, dann sollten Sie nun zuerst alle Benutzer aus Office 365 auch in ihrer "OnPremise-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 OnPremise gearbeitet habe und Benutzer in die Cloud verschieben wollen.

DNS-Einträge

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

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 OnPremise 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 OnPremise-Welt per DirSync in der Cloud angelegt werden.

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

Szenario Beschreibung

Benutzer mit Lync OnPremise

  1. Der Benutzer wird ganz klassische "OnPremise" im AD angelegt
  2. Der Benutzer wird in Lync "OnPremise" 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 "OnPremise" 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 "OnPremise" ihn noch nicht kennt. Der Zustand sollte nur kurz anhalten.
  3. User auf Lync OnPremise aktivieren
    Hierzu ist die PowerShell erforderlich, um OnPremise 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 OnPremise 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 OnPremise 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 "OnPremise" 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 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 OnPremise 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 "OnPremise"-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 <OnPremise-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 "OnPremise" 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 "OnPremise" 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 OnPremise 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 "OnPremise" 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 OnPremise-Umgebung verweisen. Damit ist auch klar, was jeder Client beim Anmelden durchführt:

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