Hybrid mit Ressource Forest

Mit SfB hat Microsoft die Anzahl der "Tested Configurations" verändert. Diese Fälle beschreiben, in welchen Konstellationen ein Produkt installiert und betrieben werden kann, so dass Microsoft dieses auch unterstützt. Das heißt nicht, das andere Konfigurationen nicht funktionieren, aber Sie sind nicht getestet und damit bleibt ein Restrisiko, das ein Update, ein Patch oder eine Einstellung den Betrieb unerwartet stört.

Auch mit Skype4B ist es natürlich weiter möglich einen Ressource Forest zu verwenden. Sie können also wie bisher in Firmen einen zentralen Forest Skybe4B betreiben und drum herum mehrere Forests für die Anmeldung der Benutzer, so genannte Account-Forests. In der Hinsicht ist noch keine Änderung mit Lync 2013 oder Lync 2010 zu sehen. Entsprechende Beschreibungen habe ich auf folgenden Seiten beschrieben:

Diese Seite soll einen anderen besonderen Aspekt beleuchten.

Hinweis
Dieser Text betrifft nur Firmen, die einen Ressource Forest betreiben und ist aktuell viel Text ohne Bilder und entsprechend schwer zu verdauen. Den Stoff präsentiere ich in der Regel bei Firmen in Gesprächsrunden mit Flipchart und Whiteboard abgestimmt auf die jeweilige Umgebung. Insofern ist dies hier etwas allgemeiner und sie müssen sich selbst die relevanten Aspekte arbeiten.

Unterstützung durch Net at Work:
Wir können Sie aktiv unterstützen. Rufen Sie einfach unter 0800-MSXFAQ (0800-638 28 96) an.

Office 365 und Ressource Forest

Mit der Zunahme von Office 365 haben immer mehr Firmen nun natürlich auch Lync im Hybrid-Mode mit Office 365 betrieben. Wer sich etwas mit Office 365 auskennt, weiß um die Bedeutung des Office 365:DirSync beim Hybrid Mode. Diese Funktion ist zwingend erforderlich um die Objekte auf beiden Seiten synchron zu halten. Die Einrichtung des DirSync in Verbindung mit mehreren Forests in der Quelle ist aber an sich schon ein Problem. Der Office 365 DirSync konnte nämlich immer nur einen Quell-Forest mit einem Office 365 Tenant abgleichen. Natürlich konnte man mehrere DirSync-Instanzen installieren und hoffen, dass ein Abgleich mehrerer Quellen in das gleiche Ziel keine Replikationsprobleme mit sich gebracht hat. Erst der ADSync (Seit 2014 als Beta und seit 2015 dann auch final) erlaubt den Verzeichnisabgleich mehrerer Quell-Forests in einen Tenant. Allerdings war zumindest im März 2015 der ADSync noch nicht für Lync freigegeben.

Aber selbst dann ist so eine Konfiguration nicht ganz trivial, denn es geht ja nicht darum ein Objekt aus einem Quell-Forest auf ein Objekt im Tenant zu synchronisieren. Wenn die verschiedenen Informationen schon in der Quelle auf zwei Forests verteilt sind, dann wird das  Zusammenführen schon knifflig. Schließlich liegen in einem Forest die Anmeldekonten mit dem Kennwort und Sicherheitsgruppen, während in dem Ressource Forest die Eigenschaften bezüglich Lync und Exchange liegen können. Aber selbst wenn z.B. Lync eine einem Ressource Forest installiert ist, ist damit nicht automatisch Exchange im gleichen Forest. Selbst hier kann Exchange sogar in einem dritten Forest betrieben werden.

Support für Lync 2013

Auf der Seite "Supported Active Directory Topologies in Lync Server 2013" (https://technet.microsoft.com/en-us/library/gg398173.aspx) führt Microsoft folgende Szenarien auf:

Type Bild Beschreibung

Single forest with single domain

Der klassische Betrieb in kleinen oder mittleren Firmen, die in den Anfangszeiten nicht Microsoft und anderen gefolgt sind und eine Root-Domain angelegt haben.

Single forest with a single tree and multiple domains

Innerhalb eines DNS-Baums gibt es unter einer Top-Domain entsprechende unterdomains. Dies finde ich oft in größeren Firmen, die eine fast leere Root haben für Schema und zentrale Dienste und z.B. nach Regionen oder Konzernteilen eigene Domains aufgebaut haben.

So können z.B. dezentrale Administratoren als "Domänen Administratoren" in ihren Bereichen tätig sein. Früher war auch die AD-Replikation ein Aspekt.

Ob hier die Lync-Server nun in der Root-Domäne oder einer andere Domäne stehen, ist wahlfrei. Sie können sogar in mehreren Domänen installiert sein. Auch die "Lync User" können in allen Domänen des Forest vorliegen.

Single forest with multiple trees and disjoint namespaces

Dieses Modell unterscheidet sich von dem vorigen Modell nur, dass es mehrere Trees in dem gleichen Forest gibt, die entsprechend andere DNS-Namen haben.

Sowohl Lync Server als auch Benutzer können wahlfrei in jeder Domäne angelegt sein.

Multiple forests in a central forest topology

Dies ist nun die erste Topologie, in der mehrere Forests zum tragen kommen. Dienste werden in einem zentralen Forest bereit gestellt, der über Trusts den Anmeldeforests vertraut.

Im zentralen Forest gibt es durchaus aktive Benutzer. Andere Anwender, die die zentralen Lync Dienste nutzen wollen, werden über einen DirSync als Kontakte im zentralen Forest angelegt.

In den "äußeren" Forests gibt es kein Lync und keine entsprechenden Properties

Multiple forests in a resource forest topology

Der reine Ressource Forest unterscheidet sich vom Central Forest darin, dass es keine aktiven Benutzer im Ressource Forest gibt, sondern die Platzhalter als deaktivierte Konten angelegt werden.

Auch hier gibt es in den Anmelde-Forests keine Lync Dienste und ein DirSync oder Provisioning ist ratsam.

Dieses Modell wird auch gerne als "internes Hosting" genutzt, d.h. wenn eine Firmengruppe gemeinsame Dienste bei hoher unabhängigkeit bereit stellen will. Dies ist aber kein "Hosting" im klassischen Sinn, da dazu mehr als nur eine "shared Plattform" gehört, sondern z.B. auch die Separierung von Adresslisten, die korrekter Einstufung von Kontakten als Intern und Extern etc.

Multiple forests in a Lync resource forest topology with Exchange Online

Diese Topologie entspricht im wesentlichen dem Ressource Forest, erweitert diesen aber nun um die Exchange Komponente, welche als "Voice Mail" für Lync quasi erforderlich.

Dieses Modell ist erst seit Lync 2013 möglich.

Interessant ist hier der letzte Punkt, der es durchaus erlaubt, Lync in einem Ressource Forest zu betreiben und parallel "Hybrid" aufzubauen. Allerdings steht hier nicht "Lync Online" oder Office 365, sondern "Exchange Online". Der Hybrid-Betrieb mit Lync On-Prem, auch als Ressource Forest, mit Exchange Online z.B.: als VoiceMail-System möglich. Von einem Lync Hybrid Mode habe ich da nichts explizit gelesen. Insofern könnte man schon mit Lync 2013 sagen, dass Lync Hybrid damit nicht "Supported" gewesen sein könnte. Andererseits haben im Jahr 2013 nur ganz wenige Firmen überhaupt über Office 365 und Hybrid nachgedacht, so dass die Frage selten akut gewesen sein dürfte.

Nicht supported

Es ist auf den erste Blick klar, dass eine Umgebung mit Ressource Forest nicht die Mehrzahl der Office 365 Interessenten darstellt. Die Überlegungen zu Office 365 haben einen Forest mit einer oder wenigen Domains, in der heute alle Dienste installiert sind. Diese Firmen können aus technischer Sicht meist problemlos in die Cloud gehen oder den Hybrid-Mode einrichten.

Wer aber heute schon On-Prem eine Ressource Forest Umgebung betreibt, hat spätestens mit Skype für Business und Skype Online ein Problem mehr (oder weniger). Microsoft bezeichnet das als "Partner Hosted", da die Umgebungen mit Ressource Forests oft als "internes Hosting" genutzt wurde. Microsoft hat dies im März 2015 noch einmal explizit in der Zusammenfassung des White Paper Downloads geschrieben.


Quelle: “Deploying Lync in a Multi-Forest Architecture (Partner Hosted Lync with Exchange Hybrid)
http://www.microsoft.com/en-us/download/details.aspx?id=44276

Da diese Ergänzung im gleichen Zeitrahme einer hitzigen Diskussion in verschiedenen Kanälen erfolgte, interpretiere ich dies derart, dass es zumindest nicht kurzfristig kommen wird. Folgende Konstellationen sind also mit Lync Hybrid/Skype Online nicht möglich:

Modell Bild Beschreibung

Ressource Forest mit Online

Wer heute einen Lync Ressource Forest betreibt, könnte ja Office 365 nutzen, um bestimmte Benutzer in die Cloud zu verschieben. Technisch kann man das sicher irgendwie hinbekommen aber es ist eben "not supported". Das Risiko, dass eine einmal laufende Installation mit dem nächsten Update "bricht" ist nicht zu unterschätzen.

Zudem muss natürlich hinterfragt werden, ob so ein Single Tenants für viele Benutzer quasi missbraucht werden kann. Auch Adressbuch Separierung etc. sind technisch nicht gelöst geschweige denn vom DirSync

Zudem würde der Account Domäne ein eigener Tenant quasi unterbunden werden.

Tenant pro Kunde

Stellen Sie sich dann mal vor, dass der Betreiber des "Anmeldeforest" selbst Dienste von Office 365 benutzen will und mehr oder weniger ohne ihr Wissen einen Office 365 Tenant samt DirSync einrichtet und dann sich wundert, dass "Hybrid" nicht geht ?

Neu an dem Thema ist an sich nichts, außer dass nun natürlich durch die explizite Beschreibung deutlich gemacht wurde, was eigentlich schon immer galt aber vermutlich einfach noch nicht nachgefragt wurde. Aber mit der Weiterentwicklung von Lync nach Skype für Business und der Zunahme der Funktionen in der Cloud rückt der Lync Hybrid Mode immer mehr in den Fokus des Interesse. Vermutlich wurde aus dem Grund die Klarstellung erforderlicih.

Supported Active Directory topologies in Lync Server 2013
https://technet.microsoft.com/en-us/library/gg398173.aspx

Microsoft verschenkt Umsatz ?

Aus kommerzieller Sicht bin ich natürlich schon überrascht, dass es keinen offiziellen Weg dafür geben soll. Office 365 verbaut sich damit selbst den Weg, solche Umgebungen über den Hybrid-Mode mit Office 365 zu verbinden und letztlich zu migrieren.

Leider gibt es keine "Übersicht" wie viele Firmen und "Seats" (= Lizenzen) heute mit einem Ressource Forest) betrieben werden und wie viele davon letztlich an einem Hybrid-Mode oder einem umzug in die Cloud interessiert sind. Ich gehe aber davon aus, dass Microsoft natürlich sehr gut weiß, welche Firmen in dieses Raster fallen. Schließlich haben solche Firmen immer mal wieder Kontakte mit Microsoft, z.B. über RAP (Assessments) oder normale Support Calls. Zudem wird Microsoft aus den Lizenzunterlagen auch wissen, wie viele Seats eine Firma hat und ob Sie z.B. im Rahmen eines EA-Vertrags (Enterprise Agreement) sowieso schon Office 365 Dienste nutzen dürfte. Das Geld ist da also schon eingenommen. Und natürlich wird der Vertrieb, gesteuert durch seine Zielvorgaben, seine Kunden schon auf Office 365 angesprochen haben und die Kunden streichen, die kein Interesse haben.

Wenn all das intern passiert ist, und das Potential vielleicht doch nicht so groß ist, dann kann man sich viel Zeit und Kosten sparen, wenn solche komplexe Umgebungen eben nicht zu einer "Tested Topology" zählen.

Der Verzicht auf den Hybrid Mode für Lync/Skype4B ist ja kein Verbot, dass der Kunde nicht trotzdem per DirSync und ADFS seinen Account-Forest mit einem eigenen Office 365 Tenant verbindet und so vielleicht nur SharePoint Online nutzen oder Exchange Online für eine andere SMTP-Domäne bereitstellt.

Denkbare Migrationswege

Nehmen wir an, Sie sind heute für eine Umgebung mit Ressource Forest und mehreren Account Forests verantwortlich und sie wollen als Betreiber diese Umgebung dennoch mit der Office 365 Welt mit genau einem Tenant verbinden, dann müssen Sie ihre Konfiguration umstellen. Gleiches gilt, wenn eine ihrer Kunden vielleicht nur seine Umgebung mit seinem eigenen Tenant verbinden will.

Um die Beschreibung nicht zu lange werden zu lassen, habe ich einige Themen unterschlagen, z.B.: die Migration von Buddylisten, Exchange UM, Konferenzinhalte etc. Auch die Frage der Bandbreite muss natürlich beleuchtet werden.

Ich habe mal drei Szenarien heraus gepickt:

  • Migration in Lync im Account Forest
    Eine Lösung wäre die Auflösung des Ressource Forest, indem zuerst eine komplette Lync Topologie im Account-Forest aufgebaut wird. Nach Abschluss der Konfiguration und der verschiedenen Tests werden die Benutzer, DNS-Seiten, TK-Trunks etc. Umgeschwenkt. Natürlich sind das neue zusätzliche Server und der Umschaltmoment ist durchaus knifflig. Aber danach ist es ein Single Forest mit Lync, der problemlos auch Hybrid mit Office 365 gefahren werden kann.
  • Migration in die Cloud ohne Hybrid-Mode
    Dieser Weg ist gangbar, wenn Anwender in einer Ressource Forest Umgebung komplett mit ihrer SIP-Domäne in die Cloud wechseln wollen. Per DirSync werden die Anwender in Office 365 angelegt, mit Lizenzen versehen und dann müssen nur noch die DNS-Einträge umgestellt werden und die Firma ist in der Cloud. Dies geht natürlich nur, wenn die Cloud auch alle Dienste bereitstellt, die erforderlich sind. Telefonie ist zumindest in 2015 noch nicht möglich.
  • Ressource-Forest als User-Forest
    Prüfen Sie, ob die Voraussetzungen für einen Ressource Forest überhaupt noch vorliegen. Normal sind im Account-Forest die Benutzer, Sicherheitsgruppen, Clients, lokale Server und entsprechende Gruppenrichtlinien, während im Ressource-Forest die "komplexeren Dienste" laufen. Vielleicht hat ihr Betreiber des Ressouce Forest für sie aber schon andere Dienste wie z-B. Softwareverteilung, Client Management, VPN etc. übernommen. Dann könnte es durchaus sinnvoll sein, die nur noch zur Anmeldung genutzten Account-Forests aufzulösen. Die Anwender und gruppen könnten per ADMT in eine OU des Ressource-Forest migriert werden und sich dann direkt dort anmelden. Viele Dinge sind auf einmal möglich, die ein Trust bislang erschwert hat. für eine Firmengruppe kann dies durchaus eine Option sein. Mit einem zentralen Forest ist dann auch wieder Office 365 Hybrid möglich.

Das sind nur drei Optionen von vielen Wegen, die zumindest nicht für jede Firma passen müssen. Hier die richtige Entscheidung zu finden, ist ein Prozess, der viele beteiligte Personen und Abhängigkeiten berücksichtigen muss.

Partner Hosting nach Microsoft Lesart

Nun werden bestimmte Firmen sich damit vielleicht nicht abfinden, dass Lync bzw. Skype für Business zukünftig nur noch On-Premises betrieben oder als Cloud-Lösung von Microsoft Online genutzt werden kann. Wenn Sie sich dann noch erinnern, dass Microsoft das "Lync Hosting Pack" nicht mehr weiter entwickelt, dann könnte man könnten Sie schon den Verdacht hegen, dass andere "öffentliche" Hoster von Kommunikationsleistungen auf Basis von Lync so gar nicht mehr in den Markt eintreten können. Der einzige Ansatz wäre eine eigenes "Azure"-Hosting, identisch zum Ansatz von Microsoft nur mit einem anderen Betreiber. Das dürften, wenn überhaupt, dann wieder nur sehr große Provider stemmen können, die einen guten Draht zu Microsoft haben. Denn der Code, den Microsoft bei Office 365 verwendet, ist kein frei verfügbares Produkt. Hinzu kommt ein Statement von Microsoft bezüglich dem Hosting für Partner:

The recommended approach für Partner Hosted Lync is extension of the customer Forest to the partner datacenter rather than the creating a new forest für Lync. This dramatically simplifies the topology and corresponding effort to build and run. This is a standard online topology.
Quelle: Beschreibung zu “Deploying Lync in a Multi-Forest Architecture (Partner Hosted Lync with Exchange Hybrid)
http://www.microsoft.com/en-us/download/details.aspx?id=44276

Wobei man hier dann natürlich die Worte abwägen muss, ob ein "Recommended" eine absolute und ausschließliche Empfehlung ist oder es noch andere Optionen gibt, die vielleicht nur nicht "recommended" aber dennoch möglich und (noch) supportet sind.

Technisch bedeutet dies aber, dass hierzu einige Fakten einen solchen Einsatz "erschweren"

  • öffnung des AD
    Der Kunde muss damit einverstanden sein, seinen bisher eigenen Forest "zum Provider" auszunehmen, damit der im gleichen Forest die Dienstleistung erbringen muss. Selbst wenn der Kunde eine eigene Subdomain erhält, ist trotzdem eine sehr enge Verzahnung mit der On-Prem-Umgebung gegeben.
  • Keine "Shared Server"
    Der Hoster muss, auch wenn Virtualisierung dabei helfen kann, für jeden Kunde eine eigene Lync Umgebung bereit stellen. Das können je nach Anforderungen auch einige Server, Loadbalancer, SQL-Cluster etc. sein. Zwar kann man Hardware durch Virtualisierung dynamisch nutzen, aber hilft aber nicht gegen die vielen Server, die natürlich lizenziert und betrieben werden wollen.
  • Zertifikate
    Hier gibt es zumindest einen kleinen Vorteil. Wenn jeder Kunde "seine" Lync-Umgebung hat, kann er dafür auch eigene passende Zertifikate nutzen
  • Providerwechsel
    Technisch könnte der bisherige Provider einfach die VMs an den neuen Provider übergeben. Ob er das aber macht, ist zumindest zu prüfen.

Selbst wenn Sie diesen Weg gehen, dann bedeutet dies aber für den Kunden eine Öffnung seines Forest für den Provider. Auch der Provider kann dann Lync für den Kunden zwar betreiben, aber für jeden Kunden muss er eine komplett eigene Topologie aufbauen und betreiben. Die Kostenvorteile einer "Shared Plattform" ist damit nicht mehr gegeben und kann durch Virtualisierung nur bedingt aufgefangen werden. Andererseits hat dann jeder Kunde "seine" Topologie und ist damit nicht mehr den verschiedenen Einschränkungen einer Shared Umgebung unterworfen, .z.B. MSPL, UCMA etc. Das kann auch als Chance verstanden werden, wen die Office 365 Plattform zu stark einengt.

Wirklich "unsupported"?

Dass Microsoft eine Umgebung mit Ressource-Forest und Account Forests nicht testet und die Komplexität vielleicht heute einfach zu hoch ist, um dies über Office 365 im Selbstversuch zu machen, heißt ja nicht, dass es nicht doch möglich ist. Wenn Sie sich die drei exemplarischen Migrationsmodelle anschauen, dann könnten Sie aus dem dritten Modell, Ressource Forest wird zum Single Forest, ein viertes Modell ableiten:

Ich kann ihnen keine Garantie dafür geben, dass dieses Modell dauerhaft bestand haben wird. Auch dies wäre eine Evaluierung und vielleicht einen Advisory-Call wert, wenn Sie in diese Richtung gehen wollen.

Das dritte Modell beruht darauf, die Anmeldekonten aus dem Account-Forest in den bisherigen Ressource Forest z.B. mit ADMT zu verlagern und dann die klassische Office 365 Anbindung auszuführen. Das hier skizzierte Modell geht den gleichen Weg, nur dass die Benutzer weiter im Account-Forest arbeiten aber auch im Ressource Forest arbeiten könnten.

Idealerweise wird dazu ein permanenter DirSync etabliert, der die Benutzer und Gruppen aus dem Account Forest permanent mit den entsprechenden Identitäten im Ressource Forest abgleicht und dabei auch die SID z.B. in Form der SID-History und optional auch das Kennwort überträgt. Die Konten im bisherigen Ressource Forest sind auch aktiv, nur wird z.B. per Firewall dafür gesorgt, dass sich kein Anwender direkt mit diesen Konten "interaktiv" anmelden kann. Selbst wenn er es könnte, wäre es aber auch nicht schlimm, da er nur an seine Daten kommt. Exchange und Lync haben kein Problem damit, wenn die vormals deaktivierten Konten nun aktiv sind. Es bleibt eine "Linked Mailbox" und ein Lync Linked User

Office 365 und der Office 365 DirSync müssen gar nicht wissen, dass der Forest mit Exchange, Lync und den "semi"-aktiven Konten gar nicht der eigentliche Anmeldeforest der Benutzer ist und dass dieser Forest dem Anmelde-Forest vertraut. Aus Sicht von Office 365 ist es ein Forest, in dem auch alle Benutzerkonten und Sicherheitsgruppen, Exchange und Lync und andere Dienste installiert sind. Computerkonten von Desktops sind in diesem Forest nicht enthalten aber die sind für Office 365 auch nicht relevant.

Der Betreiber dieses Forest kann nun einen Office 365 Tenant einrichten und mit diesem Forest koppeln. Die einzelnen Account Forests können und dürfen dies nicht. Eine Kopplung mit mehreren Tenants ist nicht vorgesehen.

Die Anwender können nun aber problemlos die Dienste in der Cloud nutzen, denn das Anmeldekonto im Account Forest wird über den internen DirSync identisch im früheren Ressource Forest gepflegt und von dort über den Office 365 DirSync in der Cloud verwaltet.

Damit bleibt noch die Anmeldung: Wenn hier auf ADFS verzichtet wird, dann muss der interne DirSync natürlich das Kennwort aus dem Account Forest zeitnah in den zentralen Forest übertragen, damit es von dort per Office 365 DirSync in die Cloud kommt. Größere Firmen werden aber eher auf ADFS setzen. Hier ist es dann wichtig, dass die UPN-Suffixes passen. Denn wir können auf zwei Wege nun den Benutzer authentifizieren.

  • ADFS gegen den zentralen Forest
    Das ist der einzige Weg, wenn Anwender verschiedener Account Forests das gleiche UPN-Suffix verwenden. Office 365 verweist je Domäne die Anwender auf einen ADFS-Host. Dank interner Kennwort-Synchronisation kann der Anwender sich am ADFS-Server authentifizieren und weiter arbeiten. Die ADFS-Dienste werden also wie die anderen Dienste zentral bereit gestellt.
  • ADFS gegen Account Forest
    Wenn die Firma mit einem eigenen Account Forest auch einen eigenen UPN hat, kann sie den Tenant-Besitzer  darum bitte, alle Authentifizierungsanfragen an diesen UPN zu einem eigenen ADFS-Server zu leiten, der nun im Account-Forest aufgebaut ist. Damit sollte es überflüssig werden, das Kennwort intern vom Account Forest zum zentralen Forest zu replizieren

Mit diesen Überlegungen sollte es möglich sein, eine Umgebung mit Lync und Exchange als Ressource Forest und der weiteren Nutzung von Account Forests über Trusts zumindest über den zentralen Dienstleister als Hybrid-Konfiguration mit Office 365 zu verbinden.

Das eigentliche Problem von Ressource Forest und Hybrid ist ja nicht das Produkt Exchange, Lync oder Skype für Business, sondern die Beschränkungen beim DirSync, der nicht auf der einen Seite die Benutzerstammdaten aus einem Account Forest beziehen und diese mit den Lync/Exchange-Daten eines Ressource Forest über die SID verknüpfen kann, und das Ergebnis dann in das Azure-AD schreibt.

Offen bei all dieser Diskussion ist natürlich z.B. das Lizenzthema. Wenn der Betreiber eines so aufgerüsteten Account Forest diesen mit genau einem Office 365 Tenant verknüpft, dann muss er diese User natürlich lizenzieren. Die Kosten laufen damit beim Betreiber auf. Darf er die Lizenzen dann aber an seine "Kunden" weiterreichen? Da ist ja durchaus ein Office 365 ProfessionalPlus mit drin und vielleicht hat die Tochter ja schon entsprechende Lizenzen mit einem Enterprise Agreement. Wie können diese Office 365 Lizenzen dann in den Tenant des Betreibers addiert werden?. Neben den technischen Fragen sind da auf jeden Fall noch juristische, finanzielle und Steuerfragen zu klären.

Weitere Links