Warum ich gewechselt habe
Ich hatte meine Mails frisch kategorisiert und wollte die Kategorien auch im Alltag nutzen. Die Darstellung in Outlook Classic hat mich dabei nie überzeugt.
Im neuen Outlook sieht dieselbe Mailbox deutlich aufgeräumter aus. Also habe ich den Schalter umgelegt. Der Wechsel dauert einen Klick, und die Kategorien sahen sofort so aus, wie ich sie haben wollte. Nur der Button meines E-Mail-Optimierers war weg, und er ließ sich auch nicht wieder einbauen.
Das neue Outlook kann kein VBA
Meine erste Frage an Claude Code war, wie ich mein Makro ins neue Outlook bekomme. Das geht schlicht nicht. Das neue Outlook ist kein überarbeitetes Outlook Classic, sondern im Kern die Web-Oberfläche von Outlook in einer App-Hülle. Eine VBA-Engine gibt es dort nicht, COM-Add-Ins auch nicht. Erweiterungen laufen ausschließlich über Web-Add-Ins auf Basis von Office.js.
Zurück zu Outlook Classic wollte ich nicht, dafür hatte ich ja gerade gewechselt. Ein separates Tool neben Outlook kam auch nicht infrage, das Werkzeug sollte weiter in der Mail leben. Also habe ich das Makro als Web-Add-In portiert, mit derselben Randbedingung wie vorher: Ollama läuft lokal auf meinem Rechner, und die Mails bleiben dort auch.
Ein kleiner Server dazwischen
Web-Add-Ins laufen zwingend unter HTTPS. Hätte das Panel direkt bei Ollama unter
http://localhost:11434 angefragt, hätte ich mich mit Mixed Content, CORS und Ollamas
Origin-Konfiguration beschäftigen müssen. Stattdessen macht der kleine lokale Server, der das Panel sowieso
ausliefern muss, einen zweiten Job und reicht alle API-Anfragen an Ollama durch. Für den Browser kommt damit
alles aus derselben Quelle, und die drei Probleme entstehen gar nicht erst.
Outlook (neu) --> Panel https://localhost:3000
| /api/chat (same-origin)
v
server.js lokaler HTTPS-Server + Proxy
|
v
Ollama http://localhost:11434Der Server ist ein einzelnes Node-Skript ohne npm-Abhängigkeiten. Die Antwort des Modells streamt live ins Panel und lässt sich jederzeit abbrechen. Damit ich den Server nicht vor jeder Mail von Hand starten muss, richtet ein npm-Skript den Autostart ein, ohne dass dabei ein Konsolenfenster aufgeht.
Als Claude Code das Autostart-Skript zum Testen ausführen wollte, hat übrigens sein eigenes Berechtigungssystem dazwischengefunkt, weil ich nur gefragt hatte, wie die Nutzung im Alltag aussieht, und keinen Autostart genehmigt hatte. Eingerichtet wurde er erst nach Rückfrage. Von einem Werkzeug, das ungefragt Programme im Autostart verankern könnte, will man genau dieses Verhalten.
Die Portierung
Die Portierung selbst war unspektakulär. Claude Code hat das alte Makro analysiert, sein Verhalten in einer Spezifikation festgehalten und daraus das neue Add-In gebaut. Nach ein paar Sessions lief der Optimierer wieder wie gewohnt, samt der kleinen Regeln aus dem Makro. Aus „Hallo Max" wird kein „Sehr geehrter Herr Mustermann", und eine versehentlich mitmarkierte Signatur kommt unverändert zurück.
An einer Stelle habe ich die Gelegenheit für eine Verbesserung genutzt. Das Makro schrieb die optimierte Fassung direkt in die Mail und bot danach an, alles rückgängig zu machen. Das Add-In zeigt den Vorschlag erst im Panel, und in die Mail kommt er erst, wenn ich auf Übernehmen klicke. Das ist deutlich entspannter als das Undo-Hantieren vorher.
Die Installation
Alle Anleitungen zur Installation eigener Add-Ins, auch die von Microsoft, beschreiben einen Dialog in Outlook, den es im neuen Outlook nicht mehr gibt. Funktioniert hat bei mir der Weg über das Microsoft 365 Admin Center: Einstellungen, Integrierte Apps, benutzerdefinierte App hochladen. Ein paar Minuten später tauchte das Add-In in Outlook auf.
Beim Klick auf den Button passierte allerdings nichts, es kam nicht einmal eine Fehlermeldung. Mit dem Add-In selbst hatte das nichts zu tun. Das neue Outlook läuft in einer Windows-Sandbox, die standardmäßig alle Verbindungen zum eigenen Rechner blockiert, und so konnte das Panel meinen lokalen Server nicht erreichen. Eine einmalige Freigabe als Administrator behebt das:
CheckNetIsolation.exe LoopbackExempt -a -n=Microsoft.OutlookForWindows_8wekyb3d8bbweNach einem Neustart von Outlook funktionierte der Button. Diese Freigabe habe ich in keiner Add-In-Anleitung gefunden. Wer also vor einem Button steht, der auf Klicks nicht reagiert, sollte zuerst hier ansetzen.
Anheften statt Extra-Klick
In der Bedienung störte mich noch, dass ich das Panel für jeden Entwurf neu über das Apps-Menü öffnen musste. Mein erster Gedanke war, es bei jedem neuen Entwurf automatisch öffnen zu lassen, aber das gibt Office.js nicht her. Es gibt zwar Ereignisse für neue Entwürfe, doch deren Handler laufen im Hintergrund und dürfen keine Oberfläche öffnen.
Der vorgesehene Weg ist das Anheften. Eine Zeile im Manifest (<SupportsPinning>) schaltet
ein Nadel-Symbol im Panel frei. Einmal angeheftet, öffnet sich das Panel bei jedem weiteren Entwurf von
selbst.
Weil das Panel damit dauerhaft offen bleibt, überlebt sein Inhalt den Wechsel zur nächsten Mail. Ohne Gegenmaßnahme stünde im neuen Entwurf noch der Vorschlag für den alten, und Übernehmen hätte ihn in die falsche Mail geschrieben. Das Panel setzt sich deshalb bei jedem Mailwechsel selbst zurück und bricht eine noch laufende Anfrage ab.
Fazit
Wer seine VBA-Automatisierung ins neue Outlook mitnehmen will, muss sie als Web-Add-In neu bauen, einen anderen Weg gibt es dort nicht. Bei mir hielt sich der Aufwand mit Claude Code in Grenzen. Die Portierung war in wenigen Sessions erledigt, und die einzige echte Überraschung war die Loopback-Freigabe für die Sandbox. Der Optimierer arbeitet jetzt wie vorher, nur als Add-In statt als Makro, und alles bleibt weiterhin lokal. Die Kategorien sehen auch endlich so aus, wie ich sie haben wollte.
Quellen
- Implement a pinnable task pane in Outlook — Microsoft Learn
- Sideload Outlook add-ins for testing — Microsoft Learn
- Ollama — lokale LLM-Runtime
Weiterführende Links
- Copilot weg, selbst gebaut: ein lokaler E-Mail-Optimierer für Outlook — der erste Teil dieser Geschichte