15
Eigene Domain in Teams ohne Exchange Online zu verwenden?
Moin zusammen,
wir fahren einen eigenen Mail Server On Premisses. Nun haben wir ein paar Teams Lizenzen dazu bekommen (Microsoft 365 Basic). Diese laufen unter der Adresse z.B. @meinedomain.onmicrosoft.com und wir verwenden nur die Teams Funktion ohne dem Email Paket darin.
Es läuft soweit, die Anwender können in Teams auch Besprechungseinladungen versenden.
Nun möchten wir diese onmicrosoft Adresse gegen unsere z.B. meinedomain.de austauschen. Diese füge ich hinzu und klicke bei der DNS Überprüfung die Exchange Einträge weg. Die Teams Einträge werden erfolgreich überprüft und die Domain ist hinzugefügt.
Die Benutzer habe ich noch nicht angefasst, sie laufen immer noch unter @meinedomain.onmicrosoft.com
Wenn jedoch nun ein Benutzer bei den Besprechungseinladungen eine interne Email Adresse angibt (@meinedomain.de), kann diese Adresse nicht mehr aufgelöst werden. Logisch, die Domain ist ja nun in Teams selbst bekannt, jedoch befindet sich kein Benutzer darin mit dieser Adresse. Also habe ich ein Teams Konto mit meiner Domain versehen und getestet. Beim Einladen wird der Name auch erkannt, jedoch erfolgt kein Email versand mehr.
Ich habe entdeckt, dass diese Adresse nun auch im Exchange Online Center angelegt wurde. Die Einladung ging also auf das Microsoft 365 Konto, das wir jedoch gar nicht verwenden. Ich kann die Email Adresse jedeoch nicht unter "akzeptierte Domänen" entfernen, um den Empfang zu verhindern.
Wie erreiche ich nun, dass die Einladungen zu unserer Domain nach extern versendet werden? Der DNS MX Eintrag schaut nach wie vor auf unseren On Premisses Mailserver, aber das scheint Teams nicht zu insteressieren.
Danke an euch schon mal and keep rockin
Der Mike
wir fahren einen eigenen Mail Server On Premisses. Nun haben wir ein paar Teams Lizenzen dazu bekommen (Microsoft 365 Basic). Diese laufen unter der Adresse z.B. @meinedomain.onmicrosoft.com und wir verwenden nur die Teams Funktion ohne dem Email Paket darin.
Es läuft soweit, die Anwender können in Teams auch Besprechungseinladungen versenden.
Nun möchten wir diese onmicrosoft Adresse gegen unsere z.B. meinedomain.de austauschen. Diese füge ich hinzu und klicke bei der DNS Überprüfung die Exchange Einträge weg. Die Teams Einträge werden erfolgreich überprüft und die Domain ist hinzugefügt.
Die Benutzer habe ich noch nicht angefasst, sie laufen immer noch unter @meinedomain.onmicrosoft.com
Wenn jedoch nun ein Benutzer bei den Besprechungseinladungen eine interne Email Adresse angibt (@meinedomain.de), kann diese Adresse nicht mehr aufgelöst werden. Logisch, die Domain ist ja nun in Teams selbst bekannt, jedoch befindet sich kein Benutzer darin mit dieser Adresse. Also habe ich ein Teams Konto mit meiner Domain versehen und getestet. Beim Einladen wird der Name auch erkannt, jedoch erfolgt kein Email versand mehr.
Ich habe entdeckt, dass diese Adresse nun auch im Exchange Online Center angelegt wurde. Die Einladung ging also auf das Microsoft 365 Konto, das wir jedoch gar nicht verwenden. Ich kann die Email Adresse jedeoch nicht unter "akzeptierte Domänen" entfernen, um den Empfang zu verhindern.
Wie erreiche ich nun, dass die Einladungen zu unserer Domain nach extern versendet werden? Der DNS MX Eintrag schaut nach wie vor auf unseren On Premisses Mailserver, aber das scheint Teams nicht zu insteressieren.
Danke an euch schon mal and keep rockin
Der Mike
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 590090
Url: https://administrator.de/contentid/590090
Ausgedruckt am: 25.11.2024 um 20:11 Uhr
15 Kommentare
Neuester Kommentar
Guten Morgen,
laut der Beschreibung von NordicMike wurde die Konfiguration schon wie im anderen Thread beschrieben durchgeführt.
Wenn ich das Problem richtig verstanden habe, reicht hier ein Connector im Exchange Online, welcher auf den lokalen Exchange zeigt und alle Nachrichten an @meinedomain.de an diesen weiterleitet, welche auf dem Exchange Online nicht vorhanden sind.
Siehe auch hier: https://docs.microsoft.com/en-us/exchange/mail-flow-best-practices/use-c ...
laut der Beschreibung von NordicMike wurde die Konfiguration schon wie im anderen Thread beschrieben durchgeführt.
Wenn ich das Problem richtig verstanden habe, reicht hier ein Connector im Exchange Online, welcher auf den lokalen Exchange zeigt und alle Nachrichten an @meinedomain.de an diesen weiterleitet, welche auf dem Exchange Online nicht vorhanden sind.
Siehe auch hier: https://docs.microsoft.com/en-us/exchange/mail-flow-best-practices/use-c ...
@goscho
Danke, ich bin bereits an dem Punkt, wo Teams die Domäne sieht, das, was du im letzten Beitrag darin geschrieben hast. Die Domain ist mit dem TXT Eintrag verifiziert und die Teams Benutzer können sie nun auch als Alias verwenden. Nur, sie können keine Termineinladungen an diese Domäne versenden. Die Emails landen intern auf den automatisch angelegten Microsoft365 Exchange Konten ohne den externen Mailserver zu kontaktieren, obwohl der MX Eintrag auf den externen Mailserver schaut.
@troebbe
Ausserdem befindet sich unser Exchange bereits in einer Hybridstellung mit einem Linux Mail Server. Eine weitere Hybridstellung würde nur noch Chaos erzeugen. Lass uns mal weiter überlegen, indem wir lokal z.B. nur einen normalen Linux Mail Server mit SMTP Empfang hätten.
Danke, ich bin bereits an dem Punkt, wo Teams die Domäne sieht, das, was du im letzten Beitrag darin geschrieben hast. Die Domain ist mit dem TXT Eintrag verifiziert und die Teams Benutzer können sie nun auch als Alias verwenden. Nur, sie können keine Termineinladungen an diese Domäne versenden. Die Emails landen intern auf den automatisch angelegten Microsoft365 Exchange Konten ohne den externen Mailserver zu kontaktieren, obwohl der MX Eintrag auf den externen Mailserver schaut.
@troebbe
Nachrichten an @meinedomain.de an diesen weiterleitet, welche auf dem Exchange Online nicht vorhanden sind.
Es handelt sich dabei um Adressen, die im Exchange Online sehr wohl vorhanden sind. Z.B. ein interner Teams Benutzer will einen anderen internen Teams Benutzer einladen. Beide verwenden diese unsere Domain und die Email verlässt den Exchange Online einfach nicht.Ausserdem befindet sich unser Exchange bereits in einer Hybridstellung mit einem Linux Mail Server. Eine weitere Hybridstellung würde nur noch Chaos erzeugen. Lass uns mal weiter überlegen, indem wir lokal z.B. nur einen normalen Linux Mail Server mit SMTP Empfang hätten.
Das Standard Know How der Hilfeartikel zu Hybrid Skype for Business und Split DNS hast du abgearbeitet?
Den Microsoft Support hast du noch nicht kontaktiert?
Den Microsoft Support hast du noch nicht kontaktiert?
Ok, jetzt ist mir die Konfiguration etwas klarer. Also um das nochmal aufzudröseln:
- Beim Zuweisen einer Basic-Lizenz wird automatisch ein Postfach angelegt.
- M365 geht davon aus, dass es authoritativer Server für diese Domäne sein darf, leitet deshalb alle Mails auf das neue Postfach weiter.
Mir fallen zwei Ansätze ein:
1. die saubere Lösung: Deaktiviere beim M365-Benutzer in der Basic-Lizenz die App "Exchange Online". Falls damit das Postfach auf dem Exchange Online deaktiviert wird, sollte der Server die Mails automatisch zum lokalen Mailserver weiterleiten
2. nicht so schön: Falls der erste Ansatz nicht funktioniert, die Mails von den Exchange-Postfächern mit einer Hilfs-Routing-Adresse an die jeweiligen lokalen Postfächer weiterleiten. Bedeutet aber viel Handarbeit und Fehlerquellen.
- Beim Zuweisen einer Basic-Lizenz wird automatisch ein Postfach angelegt.
- M365 geht davon aus, dass es authoritativer Server für diese Domäne sein darf, leitet deshalb alle Mails auf das neue Postfach weiter.
Mir fallen zwei Ansätze ein:
1. die saubere Lösung: Deaktiviere beim M365-Benutzer in der Basic-Lizenz die App "Exchange Online". Falls damit das Postfach auf dem Exchange Online deaktiviert wird, sollte der Server die Mails automatisch zum lokalen Mailserver weiterleiten
2. nicht so schön: Falls der erste Ansatz nicht funktioniert, die Mails von den Exchange-Postfächern mit einer Hilfs-Routing-Adresse an die jeweiligen lokalen Postfächer weiterleiten. Bedeutet aber viel Handarbeit und Fehlerquellen.
Zitat von @NordicMike:
@goscho
Danke, ich bin bereits an dem Punkt, wo Teams die Domäne sieht, das, was du im letzten Beitrag darin geschrieben hast. Die Domain ist mit dem TXT Eintrag verifiziert und die Teams Benutzer können sie nun auch als Alias verwenden. Nur, sie können keine Termineinladungen an diese Domäne versenden. Die Emails landen intern auf den automatisch angelegten Microsoft365 Exchange Konten ohne den externen Mailserver zu kontaktieren, obwohl der MX Eintrag auf den externen Mailserver schaut.
@goscho
Danke, ich bin bereits an dem Punkt, wo Teams die Domäne sieht, das, was du im letzten Beitrag darin geschrieben hast. Die Domain ist mit dem TXT Eintrag verifiziert und die Teams Benutzer können sie nun auch als Alias verwenden. Nur, sie können keine Termineinladungen an diese Domäne versenden. Die Emails landen intern auf den automatisch angelegten Microsoft365 Exchange Konten ohne den externen Mailserver zu kontaktieren, obwohl der MX Eintrag auf den externen Mailserver schaut.
MS schreibt im Microsoft 365 admin center folgendes:
Benutzerauswirkungen
Wenn Sie keine Domäne verbinden, wird Ihre Organisation für die Anmeldung und den Empfang von E-Mails die standardmäßige E-Mail-Adresse "firma.onmicrosoft.com" verwenden.
Sie sollten eine benutzerdefinierte Domäne hinzufügen, bevor Sie Ihre Benutzer hinzufügen. Wenn Sie dies nicht tun, müssen > Sie die E-Mail-Adressen Ihrer Benutzer aktualisieren, wenn Sie eine Verbindung dazu herstellen.
Wenn Sie keine Domäne verbinden, wird Ihre Organisation für die Anmeldung und den Empfang von E-Mails die standardmäßige E-Mail-Adresse "firma.onmicrosoft.com" verwenden.
Sie sollten eine benutzerdefinierte Domäne hinzufügen, bevor Sie Ihre Benutzer hinzufügen. Wenn Sie dies nicht tun, müssen > Sie die E-Mail-Adressen Ihrer Benutzer aktualisieren, wenn Sie eine Verbindung dazu herstellen.
@142583
Hybrid kann ich leider nicht einsetzen, da ich bereits einen Hybrid mit einem Linux Server fahre. Das gibt Chaos. Einigen wir uns darauf, die Einladungen (an Mitarbeiter in der internen Domain) sollen an einen externen Mail Server ohne Exchange Funktionalität.
@troebbe
Ansatz 1 gefällt mir und ich werde ihn testen. Die Domäne ist ja dann trotzdem noch dort. Meinem Verständnis nach müsste ich dann noch im Exchange Online ein Relay für diese Domain einstellen, damit er unbekannte Benutzer nach extern weiterleitet, richtig?
Das mit der Hilfs-Routing Adresse hatte ich auch schon im Kopf. Ich wollte nur vorher mit Euch reden, vielleicht wäre es ja nur irgendwo versteckt ein Häkchen zu setzen.
@goscho
Diese Aktualisierung passierte sogar von selbst. Die Benutzer waren schon vorhanden, ich habe die Aliase im Admin Center mit der neuen Domain zu den Benutzern hinzugefügt und im Exchange Online habe ich bei jedem Benutzer gesehen, dass er die Aliase eingetragen bekommen hat. Das macht es aber schlimmer, somit geht die Email definitiv nicht mehr raus an den eigentlichen Mailserver, sondern bleibt nicht abgeholt für immer auf dem Exchange Online.
Hybrid kann ich leider nicht einsetzen, da ich bereits einen Hybrid mit einem Linux Server fahre. Das gibt Chaos. Einigen wir uns darauf, die Einladungen (an Mitarbeiter in der internen Domain) sollen an einen externen Mail Server ohne Exchange Funktionalität.
@troebbe
Ansatz 1 gefällt mir und ich werde ihn testen. Die Domäne ist ja dann trotzdem noch dort. Meinem Verständnis nach müsste ich dann noch im Exchange Online ein Relay für diese Domain einstellen, damit er unbekannte Benutzer nach extern weiterleitet, richtig?
Das mit der Hilfs-Routing Adresse hatte ich auch schon im Kopf. Ich wollte nur vorher mit Euch reden, vielleicht wäre es ja nur irgendwo versteckt ein Häkchen zu setzen.
@goscho
Diese Aktualisierung passierte sogar von selbst. Die Benutzer waren schon vorhanden, ich habe die Aliase im Admin Center mit der neuen Domain zu den Benutzern hinzugefügt und im Exchange Online habe ich bei jedem Benutzer gesehen, dass er die Aliase eingetragen bekommen hat. Das macht es aber schlimmer, somit geht die Email definitiv nicht mehr raus an den eigentlichen Mailserver, sondern bleibt nicht abgeholt für immer auf dem Exchange Online.
Ansatz 1 ist schon mal fehlgeschlagen. Nach entfernen der Exchange Online App im Teams der Kalender nicht mehr vorhanden und der Button zum erstellen eines Meetings ist dann gar nicht mehr zu sehen. Outlook Benutzer können zwar dann noch ein Meeting über ihr Teams Plugins im Outlook Kalender erzeugen, jedoch haben wir auch Thunderbird Benutzer und diese haben dann gar keine Möglichkeit mehr ein Teams Meeting zu erzeugen.
Zitat von @NordicMike:
@142583
Hybrid kann ich leider nicht einsetzen, da ich bereits einen Hybrid mit einem Linux Server fahre. Das gibt Chaos. Einigen wir uns darauf, die Einladungen (an Mitarbeiter in der internen Domain) sollen an einen externen Mail Server ohne Exchange Funktionalität.
@142583
Hybrid kann ich leider nicht einsetzen, da ich bereits einen Hybrid mit einem Linux Server fahre. Das gibt Chaos. Einigen wir uns darauf, die Einladungen (an Mitarbeiter in der internen Domain) sollen an einen externen Mail Server ohne Exchange Funktionalität.
Ich meinte damit nicht dass du das Bauen sollst, sondern ob du das grundsätzliche Wissen was da drin steckt aufgenommen hast.
Oh, ja, gerne. Um welche Artikel handelt es sich da speziell?
Hallo Mike,
Kurz zum Verständnis:
Du hast einen On Premise Exchange
Du hast eine "Microsoft-365 umgebung"
Du möchtest mit deinen AD-Konten die O365 Funktionen nutzen.
Du legst die Benutzer im O365 Umfeld Manuell an?
Eins noch vorneweg. Die Termin-Planung (Kalender) im Teams funktioniert nur, wenn die Verbindung zu einem Exchange-Online Server besteht Rein Online, oder der Online-Teil einer Hybrid lösung). Ist dies nicht der Fall, fällt diese Funktion (Innerhalb von Teams) weg. Teams-Terminplanung über Outlook ist weiterhin möglich. Nur nicht direkt aus Teams heraus, da Teams dann nicht mehr mit dem Exchange sprechen kann um den Kalender einzustellen (in deinem Fall der On-Premise Server).
Von mir mal folgende lösungsansätze:
- Exchange ganz online nehmen (fällt vermutlich erst mal weg)
- Hybridstellung (wird nicht gemacht weil schon irgendwas hybrid läuft?!)
- Auf die Kalender Funktion innerhalb Teams verzichten und Einladungen über Outlook schicken.
Zum Anlegen der Benutzer im Azure-AD. Hast du dich mal informiert bezüglich "Azure-AD-Connect"? Hiermit kannst du deine Lokalen AD Benutzer in dein O365 Umfeld Synchronisieren.
Bevor du das jedoch tust, wäre eine Empfehlung: Stelle den "UPN" Deiner Benutzer auf euer E-Mail format um, falls das noch nicht der Fall sein sollte. Damit können sich deine Kollegen, richtige konfiguration vorausgesetzt (UPN als Anmeldename erlauben), dann mit ihrer "E-Mail" bei O365 anmelden, ohne dass es eine wirkliche Email im O365 Umfeld ist.
Wenn du das hast, dann sollte es möglich sein, den Benutzern Teams Lizenzen zuzuweisen, ohne dass das online-exchange konto genutzt werden muss. Solange es dort zu der eMail kein Postfach gibt, sollten die Emails bei euch on-Premise wieder ankommen (korrekte MX Records vorausgesetzt).
Grüße
Stig
Kurz zum Verständnis:
Du hast einen On Premise Exchange
Du hast eine "Microsoft-365 umgebung"
Du möchtest mit deinen AD-Konten die O365 Funktionen nutzen.
Du legst die Benutzer im O365 Umfeld Manuell an?
Eins noch vorneweg. Die Termin-Planung (Kalender) im Teams funktioniert nur, wenn die Verbindung zu einem Exchange-Online Server besteht Rein Online, oder der Online-Teil einer Hybrid lösung). Ist dies nicht der Fall, fällt diese Funktion (Innerhalb von Teams) weg. Teams-Terminplanung über Outlook ist weiterhin möglich. Nur nicht direkt aus Teams heraus, da Teams dann nicht mehr mit dem Exchange sprechen kann um den Kalender einzustellen (in deinem Fall der On-Premise Server).
Von mir mal folgende lösungsansätze:
- Exchange ganz online nehmen (fällt vermutlich erst mal weg)
- Hybridstellung (wird nicht gemacht weil schon irgendwas hybrid läuft?!)
- Auf die Kalender Funktion innerhalb Teams verzichten und Einladungen über Outlook schicken.
Zum Anlegen der Benutzer im Azure-AD. Hast du dich mal informiert bezüglich "Azure-AD-Connect"? Hiermit kannst du deine Lokalen AD Benutzer in dein O365 Umfeld Synchronisieren.
Bevor du das jedoch tust, wäre eine Empfehlung: Stelle den "UPN" Deiner Benutzer auf euer E-Mail format um, falls das noch nicht der Fall sein sollte. Damit können sich deine Kollegen, richtige konfiguration vorausgesetzt (UPN als Anmeldename erlauben), dann mit ihrer "E-Mail" bei O365 anmelden, ohne dass es eine wirkliche Email im O365 Umfeld ist.
Wenn du das hast, dann sollte es möglich sein, den Benutzern Teams Lizenzen zuzuweisen, ohne dass das online-exchange konto genutzt werden muss. Solange es dort zu der eMail kein Postfach gibt, sollten die Emails bei euch on-Premise wieder ankommen (korrekte MX Records vorausgesetzt).
Grüße
Stig
@Stiglitz:
NordicMike schreibt: "Ausserdem befindet sich unser Exchange bereits in einer Hybridstellung mit einem Linux Mail Server. Eine weitere Hybridstellung würde nur noch Chaos erzeugen. Lass uns mal weiter überlegen, indem wir lokal z.B. nur einen normalen Linux Mail Server mit SMTP Empfang hätten."
Ich gehe davon aus, dass deshalb kein lokale Exchange läuft und die Lösung so nicht möglich ist. Wäre dem so, würde ich deiner Lösung zu 100% zustimmen.
In diesem Fall wird wohl nichts anderes übrig bleiben, als die Einladungen per Dummy-Routing weiterzuleiten. Oder eben die Postfächer gleich auf den Exchange Online zu migrieren, wogegen es natürlich durchaus Gründe geben kann.
NordicMike schreibt: "Ausserdem befindet sich unser Exchange bereits in einer Hybridstellung mit einem Linux Mail Server. Eine weitere Hybridstellung würde nur noch Chaos erzeugen. Lass uns mal weiter überlegen, indem wir lokal z.B. nur einen normalen Linux Mail Server mit SMTP Empfang hätten."
Ich gehe davon aus, dass deshalb kein lokale Exchange läuft und die Lösung so nicht möglich ist. Wäre dem so, würde ich deiner Lösung zu 100% zustimmen.
In diesem Fall wird wohl nichts anderes übrig bleiben, als die Einladungen per Dummy-Routing weiterzuleiten. Oder eben die Postfächer gleich auf den Exchange Online zu migrieren, wogegen es natürlich durchaus Gründe geben kann.
Hm ok, wenn das wirklich so wäre, wird es natürlich schwerer.
Aber an irgend einem Punkt muss man sich auch mal auf einen größeren Aufwand einlassen, da sonst alles irgendwann nur noch schlimmer wird... Besser wird es durch "das lassen wir mal lieber so" nie.
Aber an irgend einem Punkt muss man sich auch mal auf einen größeren Aufwand einlassen, da sonst alles irgendwann nur noch schlimmer wird... Besser wird es durch "das lassen wir mal lieber so" nie.
Es ist keine Frage des Aufwands, sonder des Geldes. Weil 20 Leute ein Exchange Postfach benötigen, und 300 Leute nicht, stellen wir nicht komplett auf Exchange um und zahlen ein Vermögen für etwas, was nur 20 Leute benötigen. Zumal haben 50% davon kein Outlook.
Ich habe das jetzt mal mit dem Dummy Routing probiert. Es funktioniert soweit, bis auf einen kleinen Schönheitsfehler.
Alle Eingeladenen erhalten eine Einladung auf ihren externen Mailserver auf Outlook oder Thunderbird, nur, der Einladende selbst erhält nichts. Weil in dem Moment der Terminerstellung keine Weiterleitung auf seine Dummy Adresse stattfindet. Teams trägt sich einfach selbst in seinem O365 Kalender ein und versendet keine Einladung an sich selbst.
Dafür wird es wohl kein Hausmittel geben, ausser, ich synchronisiere beide Postfächer.
Ich habe das jetzt mal mit dem Dummy Routing probiert. Es funktioniert soweit, bis auf einen kleinen Schönheitsfehler.
Alle Eingeladenen erhalten eine Einladung auf ihren externen Mailserver auf Outlook oder Thunderbird, nur, der Einladende selbst erhält nichts. Weil in dem Moment der Terminerstellung keine Weiterleitung auf seine Dummy Adresse stattfindet. Teams trägt sich einfach selbst in seinem O365 Kalender ein und versendet keine Einladung an sich selbst.
Dafür wird es wohl kein Hausmittel geben, ausser, ich synchronisiere beide Postfächer.
Da bin ich ganz bei dir.
An deiner Stelle würde ich eher mit dem Schönheitsfehler leben.
Die Synchronisierung ist eher für die Migration gedacht. Die würde in diesem Fall ja über IMAP laufen, d.h. die Credentials müssen fix in O365 hinterlegt werden. Wenn da ein Benutzer sein Passwort ändert, bleibt auch die Synchronisierung stehen.
Eine mögliche Lösung wäre allerdings, dass die Mails zuerst nach O365 geroutet werden und dann für alle unbekannten Adressen (sprich: jene, die nur am Linux-Mailserver existieren) ein Connector läuft, welcher die Mails dann weiterreicht. Das Szenario wird auch während einer sanften Migration benutzt. Damit benutzen die Leute mit O365-Lizenz ein Exchange-Postfach und der Rest eben nicht.
Je nach Perspektive lebt man dann mit dem Vor- oder Nachteil, dass alle Mails zuerst bei Microsoft vorbei müssen.
An deiner Stelle würde ich eher mit dem Schönheitsfehler leben.
Die Synchronisierung ist eher für die Migration gedacht. Die würde in diesem Fall ja über IMAP laufen, d.h. die Credentials müssen fix in O365 hinterlegt werden. Wenn da ein Benutzer sein Passwort ändert, bleibt auch die Synchronisierung stehen.
Eine mögliche Lösung wäre allerdings, dass die Mails zuerst nach O365 geroutet werden und dann für alle unbekannten Adressen (sprich: jene, die nur am Linux-Mailserver existieren) ein Connector läuft, welcher die Mails dann weiterreicht. Das Szenario wird auch während einer sanften Migration benutzt. Damit benutzen die Leute mit O365-Lizenz ein Exchange-Postfach und der Rest eben nicht.
Je nach Perspektive lebt man dann mit dem Vor- oder Nachteil, dass alle Mails zuerst bei Microsoft vorbei müssen.
