[English]Wenn ich es richtig mitbekomme, fährt der Zug in vielen Firmen ja in Richtung Cloud. Mit dabei ist die Hoffnung, wenn die On-Premises Exchange-Funktionen erst in die Cloud in Exchange Online verlagert sind, wird man die On-Premises-Lösungen los. Die Tage bin ich auf einen interessanten Artikel gestoßen, dessen Botschaft schlicht auf "Ihr werdet weiterhin auf On-Premises Exchange angewiesen sein" lautete.
Anzeige
Mit der Cloud ist das so eine Sache. Microsoft wird zwar nicht müde, die Vorzüge der Azure-Cloud zu preisen und deutet auch an, dass man die Pflege und Weiterentwicklung der On-Premises-Angebote zurückfährt. Schwachstellen wie ProxyShell in Microsoft Exchange bestärken viele Kunden, ihr Heil in einer Flucht zu Exchange Online zu suchen. Die Idee: Dann braucht kein On-Premises Exchange Server mehr administriert und gepatcht zu werden. Ich hatte aber bereits im Blog-Beitrag Warum man Azure AD Domain Services nicht als Windows AD-Ersatz verwenden sollte auf Fallstricke bei der Migration von On-Premises Windows Servern in die Cloud hingewiesen.
On-Premises Exchange wird noch gebraucht
Ich habe zwar keine Aktivitäten in Sachen Exchange, aber der Beitrag In Microsoft's world, cloud email still often requires on-premises Exchange. Why? auf The Register weckte sofort mein Interesse. Die Botschaft des Beitrags: Microsoft besteht in einigen Fällen darauf, dass On-Premises Exchange weiter eingesetzt wird, selbst wenn alle E-Mail-Postfächer über Exchange Online abgewickelt werden. Das Problem stellt sich für Kunden, die AD Connect benötigen bzw. einsetzen. Das ist ein Dienst, der das Active Directory (AD) vor Ort mit der Azure-Version synchronisiert.
AD Connect ist für größere Unternehmen so gut wie zwingend, da immer noch ein lokales Active Directory benötigt wird, sei es, um Berechtigungen für lokale Ressourcen wie Drucker zu verwalten, oder für ältere Anwendungen, die dies erfordern (Sage ist ein Beispiel). The Register schreibt, dass On-Premises AD tief in Microsofts Plattform eingebettet sei. So erfordert Microsofts Windows 365 Cloud-Desktops AD Connect für die Enterprise-Pläne.
Exchange Server von Microsoft (Cloud oder On-Premises) ist ein weiteres Beispiel für eine Anwendung, die mit AD integriert ist. Teil einer Exchange-Installation ist eine Erweiterung des AD-Schemas, um Exchange-spezifische Daten hinzuzufügen. Sobald also AD Connect im Spiel ist, erfordert die Synchronisierung, dass Exchange-spezifische Daten sowohl vor Ort (On-Premises) als auch online (Exchange Online) vorhanden sind. In diesem Microsoft-Dokument heißt es dazu:
Anzeige
Customers with a hybrid configuration often find after a period of time that all of their mailboxes have been moved to Exchange Online. At this point, they may decide to remove the Exchange servers from on-premises. However, they discover that they can no longer manage their cloud mailboxes.
When directory synchronization is enabled for a tenant and a user is synchronized from on-premises, most of the attributes cannot be managed from Exchange Online and must be managed from on-premises. This is not due to the hybrid configuration, but it occurs because of directory synchronization. In addition, even if you have directory synchronization in place without running the Hybrid Configuration Wizard, you still cannot manage most of the recipient tasks from the cloud.
Kunden mit einer hybriden Konfiguration stehen vor dem Problem, dass die Postfächer zwar zu Exchange Online verschoben sind. Schalten sie dann aber die On-Premises Exchange Server ab, müssen sie jedoch feststellen, dass sie ihre Cloud-Postfächer nicht mehr verwalten können.
Bei Bedarf könnt ihr im Beitrag In Microsoft's world, cloud email still often requires on-premises Exchange. Why? auf The Register weitere Details nachlesen. Eine Diskussion ist auf Techcommunity im Artikel Exchange Online and Azure AD Connect von Sept. 2018 zu finden. Microsoft überlässt seinen Kunden in solchen Szenarien sogar eine kostenlose On-Premises Exchange Server-Lizenz, wie The Register schreibt.
Vor dem Schreiben des Blog-Beitrags habe ich noch ein wenig recherchiert und bin auf obigem Tweet von Exchange-Experte Frank Carius gestoßen. Im deutschsprachigen Artikel LES – Last Exchange Server hat Frank seine Gedanken im Hinblick auf die Migration auf Exchange Online notiert. Vielleicht für Leute, die vor einem solchen Schritt stehen, ganz hilfreich.
Anzeige
Naja das sollte doch eigentlich hinreichend bekannt sein, dass das Standartszenario AD mit Exchange Schema Update und AD Connect nicht zu einer Umgebung ohne Exchange mit Support umgebaut werden kann.
Mann kann es durchführen und die AD Attribute manuell pflegen, das funktioniert auch alles, ist jedoch einfach nicht supported und deswegen muss der blöde Dummy Exchange weiterbetrieben werden.
Offiziell.
Inoffiziell hilft der Support trotzdem bzw. gibt Hinweise was geändert werden muss, damit es funktioniert.
Nur mit erweitertem Exchange Schema wird es wirklich schwierig.
D.h., man betreibt einen teuren Server/Lizenzen vor Ort UND noch das Cloudangebot dazu.
Klingt für mich irgendwie überzeugend ;-).
MS stellt die Lizenz für den lokalen Exchange kostenlos zur Verfügung.
Wie immer: Die größte Kritik kommt von Leuten, die nicht mal den Text gelesen und/oder verstanden haben.
Sorry – konnte nicht widerstehen ;-).
Also ich habe mehrere Domänen aufgesetzt oder mit MSO via ADSync verbunden, die aber nie einen lokalen Exchange hatten, und die Postfächer in Exchange Online angelegt.
Das funktioniert ohne Probleme. Das einzige was man lokal im AD pflegen muss sind die Felder Mail und ProxyAddress (falls benötigt) und damit läuft das sauber durch. Dafür wird aber kein Exchange benötigt.
Natürlich sind das kleinere Domänen, bei der es sowas spezielles Mailrouting, SMTP an eingehende Geräte usw. nicht gibt. Lediglich eine handvoll Geräte die ausgehend Mails versenden wollen, was aktuell noch via SMTP/POP3 via TLS über spezielle Service Postfächer geht. Die können können kostenfrei als freigeben3 Resource angelegt werden und brauchen keine Lizenz.
Ich kenne aber das Problem. Für mich macht es aber einen Unterschied ob ich einen lokalen Exchange für Verwaltungszwecke ohne aktive Postfächer / MailDB betreibe, der dann auch keine Anforderungen an Verfügbarkeit hat und ich diesen auch noch tief hinter der Firewall verstecken kann, als wenn ich Exchange Server für ein paar hundert oder tausend User betreiben muss inkl. Public Frontend (OWA, Active Sync, Inbound Mail), Avaibility Groups, Backup, sofortige Updates, Spamfilter-Wartung, Überwachung von ausgehenden Traffic wegen Blocklist Einträgen/gehackten Postfächern usw.
Danke für die Ergänzungen. Habe ich also den richtigen Knopf gedrückt: Ein Thema aufgreifen und schauen, was an Diskussionen kommt. War ja das Ziel des Beitrags – denn zumindest nach meinem Gefühl bleibt immer eine fruchtbare Essenz für diejenigen zurück, die sich mit den jeweiligen Themen befassen müssen bzw. dürfen.
Denn für das Nachbeten der Meldungen "Microsoft hat mal wieder ein Icon bei Produkt xyz von rot auf grün umgepinselt" ist mir die Zeit eigentlich zu schade.
Auf jeden.
In den verlinkten Diskussionen sieht man noch mehr Leute, die entweder ganz ohne Exchange die Umgebung betreiben, mal einen Exchange hatten oder mindestens die Schemaerweiterung gemacht haben – sehr interessant, zumal wohl alles funktioniert. Zumindest letzteres wusste ich nicht dass das funktioniert.
Wir hatten bis jetzt nur kleinere Kunden, wo kein Sync benötigt wird, wusste gar nicht das das so eine herkuläische Aufgabe ist, welche MS noch immer micht im Griff hat. Einen lokalen Exhange nur für die Verwaltung der Onlinepostfächer? 🤦