[English]Microsoft hat zum 20. August 2025 seine "Cloud-Managed Remote Mailboxes" vorgestellt. Es ist der Versuch, Unternehmen, die alle Postfächer in die Cloud zu Exchange Online verlagert haben, von den noch betriebenen On-Premises Microsoft Exchange Servern zu befreien. Diese Exchange-Server laufen noch, um Empfängerattribute verwalten zu können, denn das ist mit Exchange Online nicht oder nur aufwändig möglich.
Exchange-Server trotz Exchange Online erforderlich?
Wenn ich es richtig verstanden habe, ich bin kein Exchange Experte, betreiben viele Unternehmen, die alle ihre Postfächer zu Exchange Online migriert haben, noch einen lokalen Exchange-Server. Dieser On-Premises Exchange-Server hat nur einen Zweck: Er dient ausschließlich zur Verwaltung von Empfängerattributen.
Denn in hybriden Umgebungen können die Attribute von Postfächern von sogenannten "Verzeichnissynchronisierten Benutzerkonten" von Exchange Online aus nicht verwaltet werden. Versuche von Exchange Online-Administratoren, Postfachattribute in der Cloud zu bearbeiten, werden in der Regel blockiert, da sich die Objektquellenautorität (SOA) lokal befindet.
Administratoren sind dann auf einen lokalen Exchange-Server angewiesen, um Postfachattribute (wie E-Mail-Adressen, Aliase oder Flags zum Ausblenden aus dem Adressbuch) in Active Directory (AD) zu bearbeiten und diese Änderungen dann mit der Cloud zu synchronisieren. Das gilt selbst dann, wenn sich das Postfach in Exchange Online befindet.
Das ist die Abhängigkeit, in der sich Unternehmen befinden, die zu Exchange Online in die Cloud verlagert haben. Aber im Unternehmen läuft weiter ein On-Premises Microsoft Exchange Server zur Verwaltung der erwähnten Postfachattribute.
Frühe Versuche zur Ablösung von lokalen Exchange Servern
Mit dem Auslaufen des Supports für Microsoft Exchange Server 2016 und 2019 im Oktober 2025 sollte der lokale Microsoft Exchange Server endlich abgelöst werden. Aber dem stehen die oben skizzierten Abhängigkeiten entgegen.
Bereits im April 2022 stellte Microsoft per Update aktualisierte Exchange Server 2019-Verwaltungstools bereit (siehe Manage recipients in Exchange Hybrid environments using Management tools). Dies ermöglichte die Verwaltung von Exchange-Empfängern über die Exchange-Verwaltungstools auf einem domänengebundenen Computer, ohne dass ein Exchange-Server ausgeführt werden musste. Administratoren hatten damit ein Werkzeug, um den letzten Exchange-Server im Unternehmen herunterzufahren und stattdessen die Verwaltungstools zum Ändern der Empfängerattribute.
Der Pferdefuß war, dass dies eine umständliche Lösung war, da sie PowerShell-Kenntnisse erforderte und keine Protokollierungs- oder Überwachungsfunktionen bot. Es gab wohl keine Möglichkeit, die Eigenschaften der synchronisierten Benutzer-Remotemailboxen (die sich in der Cloud befinden) direkt in Exchange Online zu ändern. Ziel musste es sein, dass Administratoren die Exchange-Attribute von Cloud-Mailboxen vollständig in der Cloud verwalten: Gleichzeitig sollten die Identitätsdaten aus dem lokalen Active Directory (AD) synchronisiert werden.
Cloud-Managed Remote Mailboxes
Die Lösung kommt nun in Form einer neuen Funktion in Exchange Online, die Kunden mit Hybrid-Exchange-Umgebungen eine Verwaltung der Postfachattribute im AD remote aus der Cloud ermöglichen.
Microsoft hat das Ganze am 20. August 2025 im Techcommunity-Beitrag Introducing Cloud-Managed Remote Mailboxes: a Step to Last Exchange Server Retirement vorgestellt. Die neue Funktion in Exchange Online ermöglicht Administratoren festzulegen, dass Exchange-bezogene Attribute für einen bestimmten Benutzer in Exchange Online verwaltet werden. Das gilt auch, wenn die Identität des Benutzers weiterhin aus dem lokalen Active Directory stammt.
In der Praxis können Exchange-Attribute (E-Mail-Adressen, Postfacheinstellungen usw.) mit Exchange Online PowerShell, dem Microsoft 365 Exchange Admin Center oder dem Microsoft 365 Admin Center bearbeiten werden, während die zentralen Identitätsattribute (wie Name, Adresse, Telefonnummer usw. des Benutzers) weiterhin lokal verwaltet werden.
In Exchange Online und Entra ID wird dazu eine neue Mailbox-Eigenschaft namens IsExchangeCloudManaged eingeführt. Diese gibt an, ob die Exchange-Attribute für einen synchronisierten Benutzer ihre Quelle der Autorität (SOA) in der Cloud oder lokal haben. Standardmäßig ist dieser Wert für alle derzeit verzeichnissynchronisierten Benutzer auf "False" gesetzt (was bedeutet, dass die Exchange-Attribute lokal verwaltet und mit der Cloud synchronisiert werden). Wird IsExchangeCloudManaged für einen bestimmten Benutzer auf "True" gesetzt, überträgt dies die "Source of Authority" für die Exchange-Attribute dieses Benutzers in die Cloud. Ab diesem Zeitpunkt gilt Folgendes:
- Exchange-Attribute (Eigenschaften, die sich auf das Remote-Postfach beziehen) können in Exchange Online bearbeitet werden (und werden nicht mehr durch die lokale Synchronisierung überschrieben).
- Identitätsattribute (Kernobjekteigenschaften wie Name, Abteilung usw.) werden weiterhin lokal in AD verwaltet und können nicht über die Cloud geändert werden (wie bisher).
- Die Funktion unterstützt nur die SOA-Übertragung von Exchange-Attributen für Benutzer-, Freigabe-, Geräte- oder Raum-Postfächer. Für Gruppen und Kontakte müssen Administratoren die SOA-Übertragung auf Objektebene verwenden.
Mehr Details finden sich im Support-Beitrag Cloud-based management of Exchange attributes for Remote Mailboxes in hybrid environments. Microsoft stellt diese Funktion in zwei Phasen bereit:
- Phase 1 (Review, jetzt verfügbar): Einführung der Steuerung pro Postfach für die Cloud-Verwaltung von Exchange-Attributen. Administratoren können einzelne Postfächer für die Cloud-Verwaltung freischalten (durch Setzen von IsExchangeCloudManaged=True). In dieser Phase können Administratoren auch ein Postfach auf die lokale Verwaltung zurücksetzen (IsExchangeCloudManaged=False). Phase 1 konzentriert sich auf die Verwaltung bestehender Remote-Postfachattribute einzelner Benutzer und das Testen der Funktion. Sie umfasst auch eine Einstellung auf Organisationsebene, mit der alle neu synchronisierten Benutzer-Exchange-Attribute standardmäßig in der Cloud verwaltet werden (voraussichtlich im September).
- Phase 2: Fügt Writeback-Unterstützung für bestimmte Attribute und die Integration von Entra ID Cloud Sync hinzu. In Phase 2 werden Änderungen an kritischen Exchange-Eigenschaften, die in der Cloud vorgenommen werden, automatisch mit dem lokalen Active Directory synchronisiert (bis zu diesem Zeitpunkt sind sie möglicherweise nicht synchronisiert). Dadurch wird sichergestellt, dass Ihr lokales AD auf dem neuesten Stand bleibt, wenn beispielsweise eine Proxy-Adresse in Exchange Online geändert wird. Um Writeback nutzen zu können, müssen Kunden Entra Cloud Sync verwenden.
Weitere Details zu dieser Writeback-Funktion will Microsoft zu einem späteren Zeitpunkt bereitstellen. Alle für Writeback unterstützten Attribute sind in der oben angegebenen Dokumentation aufgeführt.
Frank Carius hatte das Thema zeitnah auf MSXFAQ im Beitrag IsExchangeCloudManaged aufgegriffen, ich komme aus persönlichen Gründen aber erst heute dazu, das Ganze hier im Blog aufzugreifen.
MVP: 2013 – 2016
ENDLICH!!
Habs noch nicht im Detail durchgelesen, geschweige denn getestet. Aber wenn die Funktion das hält, was sie verspricht, erspart sie uns grossen Aufwand.
Vor 2-3 Wochen habe ich bei einem Kunden den alten (Hybrid-Verwaltungs-) Exchange 2016 auf SE Migriert, das hätte ich mir sparen können.
Wurde auch Zeit!
Was soll da toll sein? Klingt irgendwie nach dem Schlechtesten aus beiden Welten:
1) man behält einen OnPrem Exchange
2) man begibt sich in Abhängigkeit von MS (und verliert alle CIA Schutzziele)
3) man fängt sich ein neues Komplexitäts-Konstrukt ein, was den AD/SOA Sync betrifft
Der einzige Vorteil, den ich sehe ist, dass man einzelne Postfächer/OAs migrieren kann ohne dass die Gesamtorganisation betroffen ist. Oder sehe ich das falsch?
Sofern die Migration in die MS Cloud als Vorteil erachtet wird.
Ich glaube, du hast das nicht ganz verstanden, oder nicht richtig gelesen:
– es ist anschliessend eben KEIN Exchange-Server mehr onPrem nötig
– in Abhängigkeit ist der Kunde sowieso bereits, wenn er M365 wünscht/hat
– ok, ist ein Argument. Aber auch das ist bereits gegeben, sobald Entra ID / Cloud Sync bereits aktiv ist. Das Ziel bei solchen Kunden wird/muss sein, alles in der M365 Cloud zu haben.
PS: nicht dass ich das toll finde, dass alles in M365 ist. Aber die Kunden wollen das so…
Inoffizielle Trennung vom Exchange Server vor Ort:
– Benutzer aus AD Sync Gruppe entfernen
– Synchronisieren lassen
– AD Sync stoppen
– den Nutzer online aus den Gelöschten wiederherstellen
– Immutable-ID leeren
– AD Sync starten
Tadaaa wir haben nun einen Cloud-only Account und der OnPremises Exchange kann dekommissioniert werden.
Invoke-MgGraphRequest -Method PATCH -Uri "https://graph.microsoft.com/v1.0/Users/USERMAIL@CONTOSO.COM" -Body '{"OnPremisesImmutableId": null}'
Der Exchange Server ist On-Prem nach der Migration aller Postfächer auch nicht mehr notwendig gewesen. Viele haben Ihn aber behalten, weil die Pflege der Postfächer darüber wesentlich komfortabler war als das pflegen der Parameter über AD Attribute oder Powershell. Nichts anderes hat der Exchange am Ende nämlich gemacht, er hat die entsprechenden Werte ins AD geschrieben. Verteilergruppe sind im AD, E-Mail Aliase sind im AD etc.
Alternativ hätte man auch den Exchange löschen und ein Server mit den Exchange Verwaltungstools installieren können, aber dann hätte man im Kern ja immer noch Teile eines "alten" Exchange Servers im Netzwerk.
Ich habe dazu einen Kommentar geschrieben, der nachher vermutlich freigeschaltet wird.
Der Exchange On Prem ist nicht direkt nötig gewesen aber – falls ich da nicht etwas völlig falsch verstanden haben (und ich habe jetzt wirklich schon lange dazu gelesen) – er ist indirekt weiterhin nötig gewesen, wenn man "Entra ID Connect Sync" weiter verwenden muss.
– EntraID Connect Sync wird nur supported, wenn man einen Exchange On Prem hat / eine Exchange Hybrid Umgebung eingerichtet hat.
– Ohne das muss man von EntraID Connect Sync zu Cloud connect wechseln
– Damit beraubt man sich aber vieler anderer Hybrid Funktionen: Kein Hybrid Join von Computern mehr möglich, dadurch auch viele Funktionen von Intune / Defender nicht mehr vollständig nutzbar.
MS hat also (immer gegeben ich habe hier nicht etwas vollkommen falsch verstanden) das Vorhandensein einer Exchange Hybrid Umgebung an die Verwendung von EntraID Connect Sync geknüpft und weil ohne Enra ID Connect Sync manche andere Sachen nicht mehr möglich sind, hängt einem der On Prem Exchange wie eine Eisenkugel am Fuß, die man mitschleifen muss.
Das scheint mir das eigentliche Problem zu sein, an dem MS nun aber schon wieder nichts geändert hat.
Die letzten On-Premise Exchange Server abzulösen ist sicher ein guter Plan. Aber solange man ein lokales Active Directory betreibt, welches mit dem Azure-AD von Exchange Online syncen muss, ist das nur eine halbe Sache. Wer heute noch ein rein lokales AD plus Exchange On-Premise hat hat, sollte sich überlegen, ob nicht ein paralleler Aufbau einer Cloud-Only Lösung mit Inter-Org Migration vielleicht eine gute Alternative zur Hybrid-Migration ist.
Oder man migriert direkt zu einer Cloud-Only Lösung mit outgesourcter Betreuung und wirft alle On-Premise Admins raus, die braucht man dann nicht mehr, das spart eine Menge Geld.
ja, man kann auch jeden erwirtschafteten Cent an Übersee überweisen. Denn um alle Produkte und Dienste OnPrem abzulösen (File, Druck, RDS, Fachanwendungen) brauchts einen bunten Strauß an M365 3rd Party Lösungen, die nicht nur enorme Abo Kosten verursachen, sondern auch implementiert und gepflegt werden wollen. Denn nichts ist kurzlebiger als Cloudlösungen mit Scheininnovationszwang, viel Spaß beim Händchenhalten teurer externer Consultants (die oft selbst nicht mehr mitkommen).
Ich vermute das ist Ironie.
Gerade der Wechsel zu MS wird, wenn man richtig absichert, sehr teuer. Externe Dienstleister ziehen auch die Preise an.
Vor allem wenn man produzierendes Gewerbe ist, kann man mit Cloud only so richtig auf die Nase fallen. Kostenexplosion auch wegen zunehmender Komplexität vorprogrammiert.
Bin immer wieder erstaunt was BWLer optimistisch planen – und wieviel teurer der Gang in die Cloud wird. Teurere Backupsysteme, teurerer Cloudspeicher, Security…
Plötzlich EdgeComputing und vieles wandert wieder On-Prem. Inkl. eigener, flexibler und Ideenreicher eigener Admins.
Bitte entschuldigt, wenn ich ganz frech mal nach einer Einschätzung nachfrage (kann den Artikel gerade nur sehr oberflächlich querlesen, weil ich im Urlaub bin). Aber irgendwie ist das doch wieder nur eine kleine Korrektur von MS, die die eigentlich großen Probleme gar nicht tangiert.
Ein Beispiel aus meinem Berufsumfeld, um diese These etwas auszumalen:
– Letzten On Prem Exchange loswerden war schon immer möglich: Über den Zwischenweg einer Hybrid Bereitstellung alles zu Exchange online migrieren, dann Entra ID Connect Sync deinstallieren/abschalten, letzten Exchange deinstallieren (und alle Exchange Attribute im AD verlieren)
– Dann zu Cloud Sync wechseln, hierdurch dann wenigstens noch den Sync der on Prem AD user ins Entra ID haben, um nicht doppelte Benutzerführung On prem/Online anfangen zu müssen.
Das wäre bei vielen Umgebungen absolut handlebar, dann richtige ich eben weiterhin Useraccounts On Prem ein, synce sie weiterhin in M365/ Entra ID, weise dort wie gehabt Lizenzen zu und es werden Exchange Online Postfächer erstellt. Alles Exchange bezogene manage ich über die Exchange Online Powershell oder die respektiven Graph API Module.
An und für sich also machbar.
Aber das Thema "Hybrid" fängt doch nicht mit dem Exchange an und hört nicht mit ihm auf. Und hier hat Microsoft bzgl. Entra ID Connect eine vollkommen unnötig existierende harte Abhängigkeit geschaffen, die mit dem neuen Feature des Artikels wieder nicht behoben wird. Oder doch und ich hab es einfach nicht verstanden?
Was bislang nämlich der große Pferdefuß war: Wenn man zwangsweise dann nach Dekommissionierung des letzten On Prem Exchange auf Entra ID Connec tSync verzichten muss (weil das nur supported ist mit Exchange On prem) und auf das sehr abgespeckte Cloud sync wechselt, dann beraube ich mich vieler anderer Hybridfunktionen, wie zB dem Hybrid Join von Computern (weil Cloud Sync keine Computerobjekte synct). Das ist für viele Intune und Defender Funktionen schon irgendwie ein defacto Muss ist, weil alle anderen Alternativen nicht alles erlauben oder es einfach sprunghaft viel mehr Arbeit macht.
Das heißt, der eigentliche Kram ist doch nicht, dass mir der Exchange Online die Exchange Attribute nichts ins on prem AD synct (was sicherlich in manchen Anwendungsfällen seine Berechtigung hat, aber bei weitem nicht jeder benötigt). Der eigentliche Kram ist, dass ich das abgespeckte Cloud Sync nutzen muss, sobald ich keinen Exchange mehr On Prem haben will.
Ich bin vollkommen OK damit, alles außer Exchange weiterhin On prem zu verwalten und Exchange Dinge online zu verwalten. Letztlich sind alles nur Skripte und Workflows kann man anpassen.
Aber in dem Moment, wo meine Computerobjekte nicht mehr ins Entra ID gesynct werden bzw. ich keinen hybrid Join mehr machen kann, werden viele andere Dinge in M365 aber so ätzend zu managen.
Lange rede, kurzer Sinn: Habe ich da nur was komplett falsch verstanden die ganze Zeit oder hat MS mal wieder an dem für mich eigentlichen Problem vorbeigearbeitet?
MS arbeitet an den eigentlichen großen Problemen vorbei
keine Gruppenverwaltung, Verzicht auf Device Reg durch Umstieg auf Cloud Sync.
Sieht für mich selbst in Phase 2 halbgar aus, die Komplexität wird an anderen Stellen höher (s. Thema Custom Attribute).
Viel schwerwiegender könnte es sein, dass man die Postfächer nicht wieder zurück synchronisieren kann, da vermutlich die Wiedereinführung von lokalem Exchange kaum möglich sein dürfte.
Diese Exit Option ist latent bei vielen Kunden aufzuspüren…
Ich bin, ehrlich gesagt, gerade etwas überrascht über die ganze Resonanz der Unmöglichkeit und des "Cloud Sync" Zwangs:
Wir betreuen mehrere Kunden und haben an allen Standorten eine Hybrid-Stellung aus lokalen AD DCs und EntraID mit Exchange Online im Einsatz. Keine lokalen Exchange Server, nirgends. Elemente werden mittels Entra Connect synchronisiert. Attribute, welche nicht über die Online-Tools gesetzt werden können, ändern wir auf dem lokalen DCs im Attribut-Editor, welche ganz normal synchronisiert werden.
Bisher sind wir damit gut gefahren und konnten alle benötigten Änderungen auch ohne on-prem Exch. anpassen. In welchem Szenario würden wir hier Probleme bekommen?
"Attribute, welche nicht über die Online-Tools gesetzt werden können, ändern wir auf dem lokalen DCs im Attribut-Editor, welche ganz normal synchronisiert werden."
Wo ihr hier Probleme bekommt ist sobald ihr mal einen Supportcase bei MS habt, ja es funktioniert und ansich spricht auch nichts dagegen das es funktioniert aber MS unterstützt nur die Verwaltung über Exchange Verwaltungstools, die man durchaus auch ohne Serverinstallatoin installieren und nutzen kann.
https://www.msxfaq.de/cloud/exchangeonline/betrieb/exchange_online_provisioning.htm#:~:text=The%20question%20of%20whether%20a,doesn't%20validate%20these%20tools.
Das ganze über adsiedit zu machen ist jetzt alles in allem auch alles aber nicht komfortabel und auch potentiell fehleranfällig.
Uff Writeback aktivieren nur für Exchange Online? Das schon naja.
Naja bleiben eben weiter die Exchange Server (onprem) Verwaltungstools
Alles schön und gut, aber über welchen Mailserver verschicken dann "dumme" Geräte , wie etwas ältere Drucker, ihre Mails, wenn es OnPremises keinen Exchange Server mehr gibt?
Bevor ich extra dafür einen eigenen, nicht-MS Mailserver aufsetze und diesen dann natürlich auch warten muss, migriere ich lieber einen bestehenden Exchange 2016/19 auf SE und gut ist. (imho)
Dazu haben wir uns jetzt entschieden.