Seit der Installation der August 2026-Updates beklagen sich verschiedene Benutzer, dass etwas an der Darstellung von Bildern in Signaturen von Outlook Classic kaputt gegangen zu sein. Es wird nur noch ein rotes X anstelle des Bilds angezeigt. Die Schwarmintelligenz der Blog-Leserschaft hat bestätigt, dass dieser Bug durch GPO-Ordnerumleitungen verursacht wird.
Rückblick: Office-Updates August 2026
Zum 11. August 2026 hat Microsoft diverse Sicherheitsupdates für die noch im Support befindlichen Office-Anwendungen veröffentlicht. Ich hatte im Beitrag Patchday: Microsoft Office Updates (11. August 2026) einen Überblick gegeben. Es gab auch Sicherheitsupdates für Outlook Classic (alle Versionen), die mehrere RCE-Sicherheitslücken (in Word) schließen sollen.
Outlook-Problem fehlende Bilder
Bereits kurz nach Freigabe der August 2026-Updates meldeten sich Leser hier im Blog mit Problemberichten. Blog-Leser Stefan schrieb in diesem Kommentar, dass in seiner Unternehmensumgebung nach Installation der August 2026-Updates bei vielen Nutzern von Outlook Classic die Bilder in der Signatur fehlen. Stattdessen werde nur noch ein "rotes x" angezeigt.

Selbst wenn man diese Bilder wieder manuell einfügt, ist der Fehler nach dem Speichern wieder zurück. Mehrere Blog-Leser bestätigen diesen Bug, der sich über alle Versionen von Outlook Classic (von 2016 bis 365) hin zieht. Auffällig ist, dass nicht alle Nutzer von Outlook Classic betroffen sind. Ich hatte das Problem im Blog-Beitrag Patchday-Nachlese August 2026 (Office, Windows) kurz erwähnt.
Eine GPO-Ordnerumleitung ist wohl Ursache
Inzwischen kristallisiert sich aus Rückmeldungen der Leserschaft die Information heraus, dass nur Systeme betroffen sind, in denen Speicherorte per GPO umgeleitet wurden. Blog-Leser Stefan, der das Problem als erster hier im Blog gemeldet hat, merkte in diesem Kommentar folgendes an:
In Outlook Classic sind bei allen Usern die Bilder in der Signatur verschwunden, welche eine Ordnerumleitung GPO aktiv haben. Hier wird auch der Ordner %appdata% umgeleitet… Bei anderen konnte ich das Problem nicht feststellen bisher. Kann das jemand bestätigen oder ist es Zufall?
In diesem Kommentar zum Blog-Beitrag Patchday: Microsoft Office Updates (11. August 2026) findet sich die Bestätigung. Dort schrieb Leser MaBa, dass sie dieses Problem ebenfalls festgestellt haben. Vor allem in RDS- oder Citrix-Umgebungen, bei denen der Profil-Ordner %appdata% auf eine Netzwerkfreigabe umgeleitet wurde, tritt der Fehler auf. Nach Installation des August 2026-Update sind laut Leser Microsoft Office 2016, 2019, 2021 und 2024 betroffen.
In Folgekommentaren bestätigen weitere Leser, dass der Effekt auch unter Outlook 365 (M365 Apps for Business, Current Channel 20228.20190 und Monthly Enterprise Channel 20228.20188) betroffen sind. Der Kommentar hier grenzt den Sachverhalt noch ein wenig ein:
Der Fehler tritt nur in Verbindung mit einer aktiven Ordnerumleitung auf und wenn für AppData ein UNC Pfad definiert wurde. Ändert man den Pfad auf einen absoluten Pfad, sieht wieder alles gut aus.
Das wäre dann der Workaround, bis Microsoft das Ganze wieder gefixt hat. Ein Leser hat darauf hingewiesen, dass das obige Fehlerbild bereits mit Updates von Mai 2026 aufgetreten sei. Ich hatte seinerzeit im Blog-Beitrag Outlook (Classic): Microsoft bestätigt Anzeigeproblem mit Bildern auf das Problem hingewiesen. Am 5. Juni 2026 hat Microsoft dann den Supportbeitrag Images are not displayed in emails, newsletters, or signatures in classic Outlook aktualisiert und bestätigt, und den Status auf "fixed" gesetzt.
Ähnliche Artikel:
Microsoft Security Update Summary (11. August 2026)
Patchday: Windows 10/11 Updates (11. August 2026)
Patchday: Windows Server-Updates (11. August 2026)
Patchday: Microsoft Office Updates (11. August 2026)
Patchday-Nachlese August 2026 (Office, Windows)



MVP: 2013 – 2016





Auch wir können das Problem mit den Bildern in der Signatur unter Office 2024 LTSC bei aktiver Ordnerumleitung bestätigen. Ohne Ordnerumleitung gibt es versionsunabhängig keinerlei Probleme.
Leider haben die Lösungen, welche beim gleichen Fehler im Mai bereits geholfen haben, nicht mehr funktioniert.
hätte doch nur jemand Platintext durchgesetzt …
die Umleitung von %appdata% in einem UNC Pfad verursacht schon seit 2000 immer wieder Probleme, da diverse Programme nicht mit UNC Pfaden zurecht kommen.
Workfolders anstelle Folder Redirection sind technisch die bessere Alternative, dafür aber mit anderen Problemen in der Praxis.
gibt es Mal wieder eine Schwachstelle, die einen Angriff über Bilder erlaubt, die aus einer Netzwerk quelle geladen werden? dann wäre das wohl eine Erklärung.
einfache Idee, ist bei denen wo der Fehler Auftritt der UNC Pfad als Intranet deklariert?
Wären User Profile Disks die Lösung für alle Umleitungsprobleme oder tauscht man da nur den Teufel gegen den Belzebub?
Wir hatte das mal überlegt sind aber damals daran gescheitert, dass in einem Terminalserverumfeld die Disk nur an eine Instanz gebunden sein kann. Wir verwenden einen zweiten Terminalserver Cluster als Notfallumgebung und da konnte sich keiner anmelden, wenn die Disk auf dem produktiven Cluster noch gelockt war. Ist das immer noch so?
Frohes Schaffen,
Stefan
deswegen gibt es FSlogix ;-)
man sollte sich eher Gedanken machen, ob es sich lohnt Profile in irgendeiner Form zu zentralisieren.
was ist das konkrete Problem für einen Anwender, bei einem neuen Profil?
die wichtigsten Dinge lassen sich dynamisch bei Anmeldung schreiben …
mit FSLogix kann mit 2 Benutzer-Instanzen gleichzeitig auf das gleiche Profil zugreifen?
Problem sind gespeicherte Kennwörter und was weiß ich was noch alles in der Ordnerumleitung liegt…
Wir speichern auch deswegen zentral, um nicht die Profile von 1000en Usern lokal auf jedem RDP Clustermitglied zu speichern.
/appdata/local reicht da völlig aus…
Oder habe ich einen Denkfehler?
Grüße
Stefan
du hast ja immer %localappdata%, das auch angelegt wird. Profile lassen sich nach Alter aufräumen.
die Frage ist halt, ob appdata gerettet werden muss, denn das war schon immer fehleranfällig
FSlogix muss auch die vhds mergen, das liegt in der Natur einer gemounteten vhds.
Passworte gehören in einen Manager, nicht in den Browser, das wäre eine einfache Lösung zu dem Thema.
Profile sind am Ende immer eine riesen Bastelei und man akzeptiert Fehler.
UE-V war eine tolle Idee, aber technisch kompletter Sch**ss.
Da fällt einem der aktuelle CVE-2026-65346 ein, sowas muss ja nicht auf Apple beschränkt sein…
Wir haben nun mal geprüft, ob es wieder funktioniert, wenn wir den umgeleiteten Ordner per GPO wieder zurück auf das lokale Userprofil verschieben, und beim Test User wurden anschliessend die Bilder in den Signaturen tatsächlich wieder angezeigt.
Wozu um Himmels Willen leitet man denn AppData um?
Weil man im großen Stil VDI macht oder Terminal Server einsetzt. Aber wie hier auch schon mal erwähnt sind Profil Container mit FSLogix oder Citrix Profile Container hier die beste Lösung.
Seit einigen Wochen werden bei uns ebenfalls keine Bilder mehr im OWA angezeigt, in Outlook Classic hingegen schon. Erst wenn man bei Mails mit im Body enthaltenen Bildern auf „Antworten" klickt oder den Druck-Dialog aufruft, sieht man die Bilder im Mail-Verlauf. Im Edit-Mode sieht man sie zunächst, allerdings bleiben die Bilder-Anzeigen eingefügter Bilder im Mail-Entwurf oder wenn abgesendet oder empfangen aus und es sind nur große Freiflächen zu sehen, die darauf hindeuten, dass dort Bilder angezeigt werden müssten. Aktuell fügen wir Bilder daher als Attachment an, statt sie in den Mail-Body-Text einzufügen. Denn als Attachments lassen die sich immer anzeigen. Es unterbricht halt nur unschön den Lesefluss.
Ich frage mich, ob die Probleme hier und dem vorhergehenden verlinkten Artikel hier dieselben Ursachen haben, wie auch die Probleme mit Bildern und OWA?
Das ist ein Schutzmechanismus, den Microsoft wegen einer Schwachstelle ausgerollt hat. Mit aktueller Exchange-Version ist die Schwachstelle behoben, aber diese Notfallmaßnahme wird nicht automatisch zurückgerollt. Hir im Block gab es auch Artikel dazu.
Infos von Microsoft:
https://learn.microsoft.com/en-us/exchange/plan-and-deploy/post-installation-tasks/security-best-practices/exchange-emergency-mitigation-service
Gibt es denn hierzu ein Update oder hat jemand schon bei Microsoft ein Support Ticket erstellt?
Bei einerm unserer Kunden konnten wir das Ganze umgehen, indem wir die Mail im Outlook auf Richtext umgestellt haben.
Exchange OnPrem kann ja bei ausgehenden Mails Richtext wieder in HTML konvertieren.
Das ist aber natürlich nicht möglich, wenn man noch irgend eine Form von automatisierter Bearbeitung der Mail im Workflow hat.
Oder man zeitgemäßes Mailencoding bevorzugt.
Das scheint also vermutlich wieder ein Thema mit einem Sicherheitsfeature zu sein, das verhindert, dass Dateien in HTML nicht aus Netzwerkpfaden nachgeladen werden.
Hallo Richard,
vielen Dank dafür, habe das ebenfalls umgestellt und es funktioniert.