Der Ansatz Microsofts, Nutzer in den kommenden Jahren auf den neuen Outlook-Client zu schieben, hat einen unschönen Nebeneffekt, den ich so nicht sofort auf dem Radar hatte. Durch den Wegfall der COM-Unterstützung funktionieren dann Office/Access-Automatisierungs- und VBA-Lösungen nicht mehr.
Anzeige
Neuer Outlook-Client kommt
Ende September 2023 hat Microsoft die Verfügbarkeit der neuen Outlook-App für Windows bekannt gegeben. Diese App ist im Microsoft Store verfügbar, und soll die bisherigen Windows-Apps Mail und Kalender abzulösen. Ich hatte im Juli im Beitrag Microsoft 365: Ende August 2023 werden erste Nutzer von Windows Mail und Calendar auf das neue Outlook umgestellt über diese Umstellung berichtet.
Im Beitrag New Outlook for Windows now available geht Microsoft auf die Verfügbarkeit der App ein. Es handelt sich um eine kostenlose App für Windows-Benutzer, die es ermöglicht, verschiedenen E-Mail-Konten und Kalender einzubinden, so dass sich diese unter der neuen Oberfläche verwalten lassen. Die App ist im Microsoft Store für Consumer (über deren persönliches Microsoft-Konto) unter Windows 11 herunterladbar.
Die App mit dem neuen Outlook soll auf Geräten die mit Windows 11, Version 23H2, verkauft werden, sowie auf Maschinen, die auf Windows 11, Version 23H2, aktualisiert wurden, bereits vorinstalliert sein. Solange ein konventioneller Outlook-Client für Firmenumgebungen unter Microsoft Office verfügbar ist, wird sich kaum jemand groß Gedanken machen. In Formenumgebungen dürfte die neue Outlook-App eher seltener eingesetzt werden. Aber der Trend, auch in diesem Bereich auf Apps zusetzen, nimmt zu.
Neue Outlook-App: Ein potentielles Problem
Es war ein Hinweis, der mich Ende September 2023 auf Facebook von Blog-Leser Rolf P. erreichte, der mich bewogen hat, das Thema hier im Blog aufzugreifen und anzusprechen. Rolf schrieb:
Anzeige
Guten Morgen Günter,
heute früh stolpere ich über ein Thema, welches für viele Office Entwickler große Brisanz und weitreichende Konsequenzen haben kann. Vielleicht möchtest Du es in Deinen Blog aufnehmen um dem Thema etwas Brisanz zu verleihen und Microsoft zum Umdenken zu bewegen?
Rolf hat dann in seiner Nachricht auf den Beitrag The New Outlook and Access/VBA von Karl Donaubauer verlinkt. Donaubauer weist darauf hin, dass die neue Outlook-App ein gravierendes Problem aufwirft. Microsoft sei bisher mit seinen öffentlichen Informationen über die neue Outlook-App bisher etwas unscharf gewesen. Der Dreh- und Angelpunkt ist, ob die neue Outlook-App auch das konventionelle Outlook aus Office ablösen soll. Donaubauer sieht Microsofts Hinweise auf die (ebenfalls enthaltene) Ablösung der weniger wichtigen Windows Mail und Calendar als irreführend für viele Anwender an, da der Bezug auf das klassische Outlook in Windows verschleiert wird.
Alles soll durch das neue Outlook abgelöst werden
Lange war unklar, welche Strategie Microsoft verfolgt und welche Programme oder Varianten von der Änderung betroffen sind. Das habe sich sich mit dem Video vom 12. September geändert (siehe Video zu neuem Outlook für Windows). Im Video wird klargestellt, dass alle aktuellen Outlook-Varianten (Windows, OWA, Mac, Android, IOS) auf einer gemeinsamen Codebasis und Schnittstelle vereinheitlicht werden.
Plattformübergreifend bedeutet heutzutage webbasiert und Javascript-sprachig. Outlook sei aufgrund seiner Natur als Kommunikationsanwendung mit starker Beteiligung des Internets der natürliche Kandidat für eine solche Änderung, merkt Donaubauer an.
Damit kippt die VBA-Unterstützung
Und damit gibt es ein Problem, auf welches Donaubauer hinweist: Mit dem Wechsel hin zur neuen Outlook-App entfällt die Unterstützung der COM-Schnittstelle, die es ja nur unter Windows gibt. Das bedeutet, dass das traditionelle Objektmodell, die Programmierbarkeit und die Automatisierung von Outlook aus anderen Windows-Anwendungen wie Access verloren gehen werden.
Auch Lösungen, die VBA zur Automatisierung verwenden, funktionieren nicht mehr mit der neuen Outlook-App. Das wird nicht nur unzählige Firmen treffen, die sich solche VBA-Lösungen gestrickt haben. Auch alle Software-Entwickler, die die COM-Schnittstelle verwenden, um Informationen aus Outlook herauszuziehen oder Abläufe zu automatisieren, stehen vor dem Aus ihrer Lösungen.
Details und weitere Gedanken lassen sich im Blog-Beitrag von Donaubauer nachlesen. Es komme nun darauf an, die Interessen der Software-Entwickler zu artikulieren, schreibt Donaubauer. Dessen Artikel habe bereits zu einem konstruktiven Dialog und ersten Bewegungen bei Microsoft geführt. Daniel Pineault hat einen Artikel zu diesem Thema im Microsoft Feedback Portal verfasst, den Entwickler mit ihrer Stimme und und Kommentaren unterstützen können, damit Microsoft sich des Problems annimmt.
Ergänzung: Microsoft hat klar gestellt, dass die neue Outlook-App kein COM unterstützen wird (siehe Neues Outlook: Microsoft wird COM-Add-Ins definitiv nicht unterstützen) – VBA ist schon länger abgekündigt.
Ähnliche Artikel:
Neue Outlook-App kommt am 26. September 2023 per Store
Video zu neuem Outlook für Windows
Microsoft 365: Ende August 2023 werden erste Nutzer von Windows Mail und Calendar auf das neue Outlook umgestellt
Anzeige
Ich würde das nicht als Problem ansehen. das Problem war gerade die COM/VBA Unterstützung. Nicht umsonst handelt es sich um einen Teil der "Trinität des Bösen" und jede Aktion das unsichere Zeugs zu entfernen, kann nur begrüßt werden.
Doch, das ist ein Riesenproblem, denn sehr viele Lösungen setzen genau auf die COM/VBA-Unterstützung.
Habe ich hier auch im Einsatz:
Aus Access heraus werden Emails in Outlook generiert, mit Inhalten aus der Access-Datenbank gefüttert und dann aus Outlook heraus versendet.
Ohne diese Unterstützung müssten die Leute die ganzen Daten etc. manuell aus der Access-Anwendung abtippen.
Es ist doch hier über die Outlook-App und nicht Outlook (Aus dem Office Paket) die Rede. Wer Access benutzt wird wohl auch Outlook benutzen und nicht die Outlook-App aka Windows Mail aka Outlook Express aka weißderteufelwas…
Langfristig soll aber die neue Outlook App das Outlook aus dem Office Paket ablösen. Am Ende soll es nicht beide Lösungen geben.
Langfristig wird wohl nicht nur Outlook aus der Office Suite rausfliegen. Sehe es aber auch als Chance an, vorallem im Enterprise Umfeld kann man das neue Outlook mit Conditional Access und Co gut steuern.
Addons kann man als App hinzufügen und Schnittstellen über Graph API abfackeln. Aber ja, es wird wohl ziemlich viel Arbeit geben, weil selber gestrickte Applikationen, welche über Jahre gewachsen nicht mehr gehen.
Und aus Endanwender, es ist alles neu, wenn man nicht vorher mit der WebApp gearbeitet hat und da spielt die Gewohnheit einen gewaltigen Faktor.
Mit Thunderbird und libre office habe ich mir genau so etwas unter Linux gebastelt. Gibt also Möglichkeiten, dass auch anders zu machen.
Webbasierte heisst aber, dass das mailpasswort im Klartext [!] bei Microsoft liegt.
Den zweiten Part verstehe ich jetzt nicht.
Warum muss "das Mailpasswort im Klartext bei Microsoft" liegen?
Ich traue Microsoft ja viel Blödsinn zu, aber warum sollten die das tuen, wenn sie faktisch über all SSO per App einführen? – Das wäre ja zusätzlicher Aufwand.
Wahrscheinlich arbeitet Microsoft auch in dem Bereich mit gehashten Passwörtern, welche Hashwerte sie da nehmen und inwiefern diese möglicherweise 3-Buchstaben-Agenturen freundlich sind, mag ich nicht beurteilen.
Es geht dabei nicht um die Microsoft-Konten, sondern die anderer Mailprovider wie Google Mail, GMX, web.de und wie sie alle heißen. Deren Mailkonfiguration samt Zugangsdaten, wenn in der Outlook-App eingerichtet, sind bei Microsoft in der Cloud abgelegt und nicht lokal.
gilt das auch für die Desktop App oder verwechselst du jetzt die Mobile App…nur von der kenne ich das, dass in der Cloud die Postfächer eingerichtet werden und dann zur Mobile App gesynct werden, aber auch dort liegen keine Passwörter im Klartext.
App Entwickler werden nicht vor die Tür gesetzt, Microsoft lässt nur die individuelle Programmierung fallen. Solche Abläufe wie mit Access lassen sich einfach mit PowerAutomate einrichten.
Ich denke auch das Microsoft seine Kunden zu PowerAutomate bringen will damit diese "Trinität des Bösen" wie es von mw sehr schön beschrieben wurde los wird.
Das die VBA Unterstützung endlich wegfällt begrüße ich auch.
So sehe ich das auch. Die ganzen selbstgstrickten "Schrott"-Applikationen (habe da schon einige gesehen) sind zum großen Teil einfach nur ärgerlich und haben im operativen Geschäft nichts zu suchen.
Wenn man mal erlebt hat, dass ein Unternehmen 3 Produktionswerke 1 Woche lahmlegen muss, weil die ganze Produktionsplanung, die mit Excel & VBA gemacht wird, nicht mehr funktioniert ("Eigenprodukt" eines Mitarbeiters in der Abteilung, dann die Ergebnisse manuell im ERP erfasst … keine Doku, keiner wusste Bescheid was da läuft), dann steht man dem Thema eher kritisch gegenüber.
Ich behaupte, das beschreibt einen Großteil des deutschen Mittelstands treffend.
Schnelle Lösung, keine Doku und nur einer der weiß wie es geht.
Das Problem, dass du aber beschreibst ist kein Problem mit Excel und VBA sondern ein rein organisatorisches.
Tausche Excel und VBA mit Python, Powershell, OpenSource XYZ Anwendung – wenn da nichts dokumentiert ist und sich nur ein Mitarbeiter auskennt, der dann ausfällt hast du das Problem mit dem Abdrehen von VBA nur auf ein anderes verlagert und nichts dazugewonnen.
Da muss man dann halt "erfinderisch" werden und die Daten aus Access heraus entweder in eine Vorlagendatei einpflegen oder als Datenbank-Datei exportieren. Das Ergebnis könnte man mittels PowerShell an die Empfänger mailen. Lösungen per Umweg gibt es wahrscheinlich reichlich. Die Frage ist halt, wie sehr die Entwickler Zeit in eine irgendwie funktionierende Lösung investieren wollen und dürfen.
Die Frage die sich mir stellt, ob die tatsächlich so geistig umnachtet waren, dass sie die Applikation mit überhaupt gar keine API-Schnittstelle konzepiert
hatten und jetzt auch erst einmal eingeführt haben. Falls ja, wird das ja noch lustiger, wenn die jetzt etwas nachträglich einfügen wollen, dann schaffen die es bequem ihre eigene Codebasis kaputt zu machen, nur um wieder "irgendwie" Ansprechbarkeit einzufügen.
Klar, jede Sicherheitsfunktion stellt Möglichkeiten ab. Wenn vorher alle Mails ohne Authentifizierung lesbar waren und jetzt eine Anmeldung nötig ist blockiert das auch Anwendungsmöglichkeiten, z.B. dass aus Drittprogrammen heraus ohne großen Aufwand angezeigt werden kann, ob neue Mails angekommen sind. Dennoch wird heute wohl niemand auf Authentifizierung verzichten wollen, obwohl früher IIRC die Telekom bei Einwahl über Modem keine weitere Authentifizierung benötigte und jedes Programm dadurch Mails "einfach so" abrufen konnte.
In Deinem Beispiel muss man eben beispielsweise aus Access heraus direkt mit dem Mailserver kommunizieren. Geht auch. Allerdings müsste dann ein (Access-)Programmierer ja wissen, wie Mail-Authentifizierung geht (bzw. wie man entsprechende Libraries bedient). Nach dem, was man so als "Industrie-Programme" sieht sind da einige 30 Jahre hintendran – auch mit Versionen, die 2023 herausgekommen sind.
Mit etwas Glück (man wird noch träumen dürfen…) wird dann auch 2FA und verschlüsselte Übertragung unterstützt.
Wir sind ohnehin verwöhnt. Früher haben Schnittstellen alle paar Jahre gewechselt. Wir hatten jetzt (leider?) Jahrzehnte Ruhe.
Bewahre! Er hat Access gesagt!
Und morgen nehmen wir Fortan 72, Cobol 90 und DBase?
Wir haben da noch 450000 Zeilen Code!
Die können wir doch nicht einfach wegkippen.
Da stecken zig Mann-Jahre an Entwicklung drin…
OK, diese Männer sind in zwischen alle in Rente, und von den Neuen traut sich keiner mehr etwas zu ändern, wegen der unabsehbaren Nebeneffekte durch 30 Jahre Rucksäcke bauen…und fehlender Dokumentation.
Manchmal fällt MS dann doch "mal" eine richtige Entscheidung…
wenn Ende, dann Ende.
Danke! Sehe ich genauso!
Och Leute … Fangt endlich an mit CodeSigning und erzwingt diese per GPO.
Das ist ja kein Hexenwerk, sondern nur administrativer Aufwand.
Seltsamerweise heulen lieber alle und beklagen sich, statt ihren Dreck zu signieren. Dann kann ich dem Zertifikat vertrauen, das auch per GPO verteilt werden kann und fertig ist die Laube.
… und ja, das geht. Die Admins wollen es nur nicht.
Es reicht ein simples SelfSigned und damit signiert die IT alles, was genutzt werden soll. Dann mit demselben Zertifikat ein schickes Allowlisting hintendran und schon ist es sicher. (Es darf auch mehr als ein Zertifikat sein …)
Aber nein, dann lieber alles Neumachen und vor allem keine Manpower verwenden, lieber die Verantwortung abgeben und ein EDR/XDR/NMR kaufen.
Nicht vergessen. Outlook 2021 lebt noch bis 2026.
https://learn.microsoft.com/en-us/lifecycle/products/outlook-2021
Für SW-Entwickelnde hilfreich:
https://learn.microsoft.com/en-us/office/dev/add-ins/outlook/one-outlook
Und ja, es gibt sicher Arbeit für Menschen.
Outlook und die Cloud:
https://learn.microsoft.com/de-de/deployoffice/endofsupport/microsoft-365-services-connectivity#minimum-version-requirements-for-outlook-for-windows
Zunächt begrüße ich das "Abschneiden alter Zöpfe" definitiv, gerade Outlook hat ja durch seine vielfältigen Schnittstellen immer wieder für Sicherheitsprobleme gesorgt.
Auch das durch WebView2 vereinheitlichte "Look & Feel" hat definitiv seine Berechtigung, bei mir sieht das neue Outlook bis hin zur Farbigkeit dem Web-Pendant zum Verwechseln ähnlich.
Eine Grundfunktionalität zum Versenden über mailto:-Links (denen man über Sublect: und Body: auch komplexere Inhalte mitgeben kann) ist weiterhin gegeben.
Das oben in den Kommentaren genannte Access-Problem sehe ich auch nicht als solches, es gibt durchaus Möglichkeiten, Mails direkt aus der Datenbank heraus zu versenden – sollte es sich bei der Anwendung um eine "Enterprise-Lösung" handeln sind die sowieso vorzuziehen.
Ein kleines Problem gibt es noch, bei dem auch Microsoft schreibt, daß es "in Arbeit" ist: zum Signieren bzw. Verschlüssen von Mails per S/MIME wurde bisher auch ein Addin verwendet, für welches Microsoft noch keinen Ersatz hat.
Ich habe auf einem Test PC das Office 365 mit Outlook installiert. Gleichzeitig habe ich im Windows Mail den Hinweis zum wechseln auf das neue Outlook durchgeführt. Beide Outlook laufen parallel ohne Einschränkungen. Die neue Outlook APP Version soll doch nur das schreckliche Mail-Programm in Windows ersetzen. Bei Windows XP gab es doch auch Outlook Express als einfachen E-Mail-Client.
Fürs erste soll es nur die Mail App in Windows 10/11 ersetzen. Der Fahrplan von Microsoft sieht aber vor, bis ca. September 2024 (ob die das bis dahin auch schaffen, sei mal dahingestellt) auch den Outlook-Client von Office 365 durch die Outlook App zu ersetzen.
Ich bevorzuge auch das klassiche Outlook, dennoch gitb es keinen Grund wegen dem Wegfall dieser Schnittstellen zu weinen, es ist eher eine Chance die gazen alten Zöpfe abzuschneiden die in Outlook meist nur Probleme bereitet haben.
Exchange bzw. o365 besitzt eine REST API die sich gut un zuverlässig anteuern lässt., man muss es halt eben mal machen und 2 Jahre Vorlauf sollten doch genug sein um das umzusetzen.
Schaut euch mal –>> Qubes OS <<– an. VMs auf dem Desktop PARALLEL laufen lassen! Klingt interessant, Grafik-Performance ist dann aber eher mau. Zocken geht da minder, gute Sicherheit aber dafür besser + man kann 'echt' parallel auf versch. OSen arbeiten mit Linux als Unterbau.
Eine weitere Schwierigkeit ist uns im Unternehmensumfeld untergekommen. Blockiert man aus regulatorischen Gründen jeglichen Zugriff auf private Webmailer (GMail, Gmx, etc.) zum Beispiel in Sophos Endpoint, wird damit auch der neue Outlook-Client geblockt. Er wird aus technischer Sicht als Webmailer gesehen.
Klickt also ein unvorsichtiger Admin auf den "Testen Sie das neue Outlook"-Button, kommt er auch nicht mehr zurück zum alten Client, weil ist ja geblockt. :)
Wenn du eine *.eml öffnest kannst du beide Clients parallel benutzen. Musst einfach die Shortcuts pinnen.
Ihr habt ein Führungs-Problem, wenn ihr private Webmail sperren müsst (man kann keine sozialen Probleme mit Technik lösen, auch wenn die bunten Prospekte anderes verkaufen wollen.) oder arbeitet im höchsten Sicherheits Bereich. Dann aber fragt man sich, warum Arbeitsplätze überhaupt ins Internet kommen müssen…und warum Microsoft genutzt wird.
Achso, ja, sorry, ist ja Cloud…alle machen Cloud.
Millionen Fliegen fressen Sch….!
Das kann also nicht falsch sein.
(Ist klar das Du nix dafür kannst. Sind halt die da oben.
Die kriegen ja auch viel mehr Geld … Kann man nix machen. )
Was ist den besser? Private emails sperren oder Mitarbeiter nach ThreeStrikes kündigen wenn sie sich nicht dran halten?
Sorry aber egal wie gut dein Führungsqualitäten sind, du hast immer Arschl**** die meinen für sie gelten Regeln nicht.
Ist doch immer so:
Ich bot meinen Mitarbeitern Kaffee umsonst, dann kamen einige auf die Idee man könnte ja vor Feierabend auch noch die Thermokanne voll machen und mit nach hause nehmen.
Zigarettenpause wurden nicht gestempelt bis einige dann 30 Min. Zigarettenpause machten alle 2h. usw. entweder du regulierts oder du kündigst die dann… man möchte aber ja auch keine Existenzen zerstören, wegen sowas, also reguliert man.
Die neue Outlook Store-App ist nunmal kein Office Outlook.
Auch bei Office 2019/2021/365 funktionieren COM-AddIns nur, wenn das normale Setup und nicht die Store Installation genutzt wird.
Aber ja, sehr viele 3rd Party Programme werden darüber genutzt/angesprochen – darauf wollen die Kunden in den nächsten 10 Jahren auch nicht verzichten.
"Solange ein konventioneller Outlook-Client für Firmenumgebungen unter Microsoft Office verfügbar ist, wird sich kaum jemand groß Gedanken machen. In F_i_rmenumgebungen dürfte die neue Outlook-App eher seltener eingesetzt werden."
Eben. Im Privatumfeld wird COM/VBA eher keine Rolle spielen, schon garnicht wenn auch kein O365 installiert ist. Ich glaube nicht mal, dass das bisherige in Windows integrierte Outlook / MAIL sowas überhaupt kann, und dafür ist ja dieses neue Outlook erstmal nur Ersatz. Und VBA ist ja auch eher verbrannt, weil es für Hackerangriffe verwendet wird. VBS ist ja schon abgekündigt, VBA wird dem möglicherweise eines Tages noch folgen.
Verwirrend finde ich leider diese Namensgebung, beides heißt Outlook. Das ist nicht richtig und stiftet nur Verwirrung. Vielleicht wird COM/VBA mal ein Thema (siehe oben), wenn die Outlook-App tatsächlich mal O365-Outlook ablösen sollte. Aber wenn man sich die Outlook-App mal ansieht, die kann das alles was O365-Outlook kann ja noch garnicht, taugt also noch nicht als Ersatz.
Ps: Wann wird mein Beitrages zur Linux-Anleitung von MS freigeschaltet? Ist meine Meinung dazu zu Quer? (=geschicktes Marketing seitens MS!…)
Einige Änderungen in der neuen Outlook App begrüße ich ebenfalls. Auch den Wegfall von VBA. Das wurde wirklich Zeit. Die Frage, die sich mir aber stellt, was steht da noch alles auf dem Fahrplan? Wie sieht es künftig mit PSTs aus, Import/Export, usw… Outlook on prem hat doch noch einige Funktionen mehr als die neue App.
Im übrigen könnne viele Konstrukte inzwischen mit dem Dataverse und PowerAutomate gelöst werden. Es muss sich halt nur mal jemand hinsetzten und den Uraltkram rausschmeißen und was neues bauen. Und das am besten schon jetzt und nicht erst, wenn die neue App das bisherige Outlook ablöst.
VBA sehe ich hier unkritisch, da MS da schon relativ früh aus Sicherheitsgründen bei Outlook den Stecker gezogen hat. Bei der Addin Schnittstelle werden einige Grosskunden höchstwahrscheinlich sauer werden. Bin mal gespannt wie MS denen das erklärt.
gar nicht… friss oder Stirb, bleibt den "Großkunden" ja kein Alternative ;-P oder denkst du die migrieren mal eben nach Linux und verlieren damit noch mehr Funktionalität?
Da werden einige Admins fluchen und nen Berg voll Arbeit haben.
siehe
https://answers.microsoft.com/en-us/officeinsider/forum/all/does-the-new-outlook-desktop-client-support-mapi/e752fb02-0ea6-48ce-8ef7-5e48e7fbd500
MAPI wird also auch nicht gehen …