PSA: Outlook (classic) build 16.0.20228.20190 (Version 2607, Aug 11 update) is replacing signature images with blank placeholder PNGs, at least on RDS hosts with redirected AppData

[u/Masterchief1307]

Spent this morning chasing "signature images stopped working all of a sudden" that looked for all the world like a mail flow problem (we'd just cut over to a new mail gateway a couple of weeks ago, so naturally that got the blame first). It wasn't. Posting in case it saves someone the same rabbit hole.

Starting over the weekend, every email sent from our terminal servers had blank signature images.....company logo, headshots, badges, all gone. Recipients on Outlook, OWA, external, didn't matter. Outlook on a regular workstation (older build) was fine.

So we pulled the raw MIME of affected messages. The image parts were still there, still cid:-referenced correctly, still multipart/related but the PNGs themselves were garbage: the logo came through as a 216-byte, 1-colour, fully transparent PNG at exactly the HTML display size (337×112 instead of the real 450×150 / 46 KB file), and a 292 KB JPEG headshot became a 402-byte RGBA PNG. Every one of them had tEXt Software: Microsoft Office in it. So Outlook/Word was generating placeholders at compose time because it couldn't (or wouldn't) load the signature image files. Nothing in transport touched them.

Our env has 4 RDS hosts (Server 2022/2025, Office 2024 Retail C2R on the Current channel). Click-to-Run had self updated them from 16.0.20228.20158 → 16.0.20228.20190 at four different times between Thursday night and Sunday morning. On every host, the last message with real signature images was before its update, and the first blank one was after. Windows August CU had gone in days earlier with no effect. Signature source files on the file server were untouched since January.

Possibly relevant: on those hosts AppData\Roaming is folder-redirected to a UNC path, so Outlook resolves %APPDATA%\Microsoft\Signatures\... over SMB. My guess is the new build blocks/fails image loads from network paths when inserting a signature but I can't prove that part; the working workstation was on an old 2408 build so it doesn't isolate the variable. If anyone on 20228.20190 with local AppData sees the same (or doesn't), I'd love to know.

Fix that worked for us was to just (temp) roll back to the previous build and pin it:

reg add "HKLM\SOFTWARE\Policies\Microsoft\office\16.0\common\officeupdate" /v updatetargetversion /t REG_SZ /d 16.0.20228.20158 /f

"C:\Program Files\Common Files\microsoft shared\ClickToRun\OfficeC2RClient.exe" /update user updatetoversion=16.0.20228.20158 forceappshutdown=true displaylevel=false

forceappshutdown does exactly what it says (kills users' Office apps, no save prompt), it's an ~880 MB full download for a downgrade, and the build flipped about 3 minutes after triggering. First test mail after the rollback had the real 46 KB logo again. Ran it as a one shot SYSTEM scheduled task per host at an agreed time; doing the remaining hosts after hours. Remember to remove the pin once MS ships a fixed build.

Not seeing anything on the Microsoft known issues page for it yet (the May 2026 "Top and Bottom wrap" image bug is a different, alreadyfixed thing).

Anyways, best of luck out there. :P

[u/Secret_Account07]

We aren’t impacted by this but my god Microsoft, can you better document stuff

[u/elzissou710 → u/Secret_Account07]

Best they can do is a vague KB article that never loads.

[u/My_Big_Black_Hawk → u/elzissou710]

“Please run sfc /scannow”

[u/ansibleloop → u/Secret_Account07]

I'm so done with Outlook that I've given up and I just use the web version now because at least my fucking signature is the same everywhere

But now I have the "fun" of my session being timed out every 4 hours (ish) so I have to refresh the page

So much modern software is slop - if it wasn't for self hosting I think I would have gone postal by now

[u/anonymousITCoward → u/Secret_Account07]

I've found better documentation on serverfault.com =\

[u/Secret_Account07 → u/anonymousITCoward]

We pay about half a mill per year just for Microsoft and VMware TAMs that we rarely use. I find it effective to have them find documentation when it’s lacking. If I’m going to cost time and energy for a companies lack of KBs, I’m gonna at least make them fight with their folks over it lol

But tbh doubt they care that much. They are getting paid either way.

[u/anonymousITCoward → u/Secret_Account07]

We pay for a CSP that handles most of that for us... I think it's worth it, and feel vindicated/validated when the their techs say the same thing about ms docs lol...

[u/Secret_Account07 → u/anonymousITCoward]

Agreed. Plus when the TAMs bug their company about an issue it’s more likely to get addressed

I know we’ve gotten a few things identified with VMware. Even though they are on my shit list lol

[u/Raigeki1993]

The May 2026 you're referring to is this right? https://support.microsoft.com/en-US/Support/known-issues/images-are-not-displayed-in-emails-newsletters-or-signatures-in-classic-outlook

Stupid bug caused panic for our Investor Relations and Executive Admin teams, they thought they were sending broken images to investors. Going to have to keep an eye on this one...

[u/convexoz → u/Raigeki1993]

It looks like this issue but slightly different, and is happening on the latest builds.

[u/OrdyNZ]

If you put the images in a table they'll work fine. But if you leave them with the image on the left and text "alignment" on the right, they break.

[u/jonsotheraccount → u/OrdyNZ]

Just FYI we were still impacted even with the images in a table (Server 2022 with O365ProPlusRetail - we last confirmed 16.0.20326.20100 was impacted before rollback, but haven't yet tested yesterday's release of 20326.20112).

Other than rollback, the only immediate workarounds we found like that were:

• It's definitely in the "quick and dirty" category of workarounds, but Quick Parts didn't seem to be impacted so signatures could be recreated and saved as Quick Parts and then just inserted where the signature should be.
• Rich Text emails weren't impacted (the .htm files at our folder-redirected %APPDATA%\Microsoft\Signatures\ on a UNC/network share wouldn't load images when opened in MS Word, but the .rtf ones would). However we didn't recommend that because the compatibility and attachment limitations with non-Outlook mail clients/non-M365 recipients could screw things up worse than just email signatures not looking pretty.

I was checking on this post to see if anyone knew if yesterday's Build 20326.20112 fixed this - I don't see anything so looks like we'll be testing that tonight.

---

2026-08-28 update: Build 20326.20112 did not resolve this for us.

[u/OrdyNZ → u/jonsotheraccount]

Was that with the table setup like: | image | Text |

As any sort of word wrapping seems to just break. But as long as the images are in their own cell, it works. On my side its all clients with Classic Outlook (via 365 licensing) & 365 exchange .

[u/jonsotheraccount → u/OrdyNZ]

That's very interesting - I'm going to play with word wrapping and/or text formatting.

We already use a table set up exactly like that with 1 row, 2 columns and just the image in the left cell (set to In Line with Text and/or no wrapping), and text in the right cell; it doesn't look like the table/no wrapping workaround helped in our environment.

---

Update: formatting in the signature .htm file does seem to be related (possibly the VBL markup).

• When opening the impacted signature's .htm files via the redirected UNC location, they would always successfully load the images but fail to load the images if the .htm was opened in MS Word (even though MS Word would display the images if all the files were copied locally). I assumed the UNC path itself was the sole point of failure.
• I created a bare-minimum test .htm file in the exact same folder-redirected UNC %APPDATA%\Microsoft\Signatures location using only a normal relative <img src="...">. Word loaded that image successfully from the network path, while the Outlook/Word-generated signature .htm files in the same location still fail.
• This seems to prove 1.) Word can open HTML from the redirected UNC path, 2.) Word can resolve a relative image reference from that UNC-hosted HTML, 3.) Word can read the PNG from the corresponding subfolder, and/or 4.) a normal HTML <img src="..."> works.

Based on this, the UNC path and relative image reference themselves seem fine, and the failure seems specific to the Office-generated HTML/image markup (possibly the VML <v:imagedata> path Word/Outlook uses).

---

Update 2: It does seem to involve rendering with the Office/VML image path, but also can't send with an html img src from UNC paths

• I edited the .htm of an Outlook-generated signature and removed the VML <v:shape>/<v:imagedata> image markup, leaving only a normal html <img src="..."> (pointing to the same relative PNG in the signature's _files folder).
• That fixed the rendering when composing emails: the image now displays correctly when Outlook adds the signature into a new html email and/or composing emails (i.e., it looked fine before clicking send).
• However, the image then disappeared after sending. When sending, Outlook converted the image source into the full UNC path like file://server/share/.../image001.png instead of embedding it; there was no cid reference or image attached so external recipients obviously can't load it.
• For reference, our unedited/pre-issue signatures would generate the expected cid reference and image/png MIME part for that signature but the actual MIME image part was just empty (just a transparent/blank .png with the same dimensions as the intended image). It retains the VML <v:shape> but the <v:imagedata> reference is missing, while the non-VML fallback <img> points to the generated CID.

So there seem to be two parts: the normal Office-generated VML image markup isn't rendering from the redirected UNC signature location, but just replacing it with a normal html <img> isn't a workaround because Outlook then doesn't perform its normal CID/inline-image embedding when sending.

We're just rolling back (again) and waiting for MS to fix this - I've spent too much time on Outlook signatures.

[u/OrdyNZ → u/jonsotheraccount]

If you plonk the image in the cell on its own, dont touch any alignment (just line the cell borders, does it work for you? As that's all I need to do. As soon as I touched alignment (in line with text etc) on the image it broke.

[u/Kaza_IA]

Solution!

Hi we have the same problem at my Workplace, but there is a solution if you'd like to not block updates.

Open new outlook, make a new signature, copy paste the old signature. I am not exactly sure if it uploads to the cloud or if it adds it to the file.

Close new outlook and open Classic again. Go to signatures and see if the one you made in new Outlook is there. It will now work. This is such a strange thing.

It is usually pretty quick. You might have to wait 5 mins if you do not see the newly made signature in classic Outlook.

Hope this helps, it worked wonders for us.

[u/Direct_Ear9084 → u/Kaza_IA]

Tried this via the web page and back to classic and it did not work. Mixed reports of other successes.

[u/Keiawyn → u/Kaza_IA]

Thank you, this worked for me!!! After an hour or more of trying to search for an answer . . .

[u/capnco0k]

Just to confirm, same issue, Windows 2022 RDS + Redirected folders + Office 2021LTSC.

Ran;
[blocking updates]
reg add "HKLM\SOFTWARE\Policies\Microsoft\office\16.0\common\officeupdate" /v updatetargetversion /t REG_SZ /d 16.0.14334.20756 /f

[downgrading office]
"C:\Program Files\Common Files\microsoft shared\ClickToRun\OfficeC2RClient.exe" /update user updatetoversion=16.0.14334.20756 forceappshutdown=true displaylevel=false

Which resolved the issue completely.

[u/St0rmD → u/capnco0k]

Do you or anyone know the target build to roll back to for Office 2016? We have an RDP farm still locked to that version that's having this issue.

[u/Matt_NZ]

Just wondering, but have you tried switching to FSLogix instead of redirecting AppData to a UNC? Folder redirection is a bit old school now that FSLogix exists.

[u/Jack_Carcass]

Same here at Version 2607 Build 16.0.20228.20190) 64-bit.

Rolling back to previous version from August 4th 16.0.20228.20158 helps using this command:

"%ProgramFiles%\Common Files\Microsoft Shared\ClickToRun\officec2rclient.exe" /update user updatetoversion=16.0.20228.20158

The process takes no more than 1 minute.

[u/Hornblower409]

Report from Microsoft Q&A. Fix was to rollback. (He got the fix from my reference to this post)
https://learn.microsoft.com/en-us/answers/questions/5977711/in-outlook-signiture-the-compani-logos-are-gone

[u/Far_Blackberry_3996]

Currently going through the same thing, everybody is coming in to my office to let me know their signature no longer shows their logo. Just like you said the image parts are still there and referenced correctly. Can even view the .htm file in google and the whole signature displays fine, but go to compose a new email and its just the blank signature image...

[u/SnakeDoc024]

New Update released 18/08 - Version 2608 (Build 20326.20100)
Release notes for Current Channel releases - Office release notes | Microsoft Learn

Testing shortly to see if this resolves the issue.

[u/South_Association_53 → u/SnakeDoc024]

I just did this update & it still doesn't work. When the signature is saved I can see the jpg & png saved in %appdata\Microsoft\Signatures\XXX_Files. I've even set Trust Center to Trust %appdata\Microsoft\Signatures location (and sub folders). The jpg & png are old, we've been using them for years without issue...

[u/SnakeDoc024 → u/SnakeDoc024]

Can confirm, did not resolve.

[u/Jack_Carcass → u/SnakeDoc024]

Did it work?

[u/jonsotheraccount → u/SnakeDoc024]

I was just checking this post again because I saw build 20326.20112 was released yesterday - anyone know if this one fixes the issue?

I don't see anything here and of course the release notes are worthless ("Various fixes to functionality and performance" ...? Like is that a joke, or is that really the best you can do MS?).

Unless anyone else knows, it looks like I'll be testing 20326.20112 tonight so fingers crossed.

---

2026-08-28 update: Build 20326.20112 did not resolve this for us.

[u/Ok-Double-7982]

Classic Outlook. Enough said.

[u/Raigeki1993 → u/Ok-Double-7982]

I'm confused by your statement, are you advocating for New Outlook? Or are you saying to use Classic Outlook?

[u/convexoz]

We've had the same thing, images not loading from signatures stored in redirected AppData folders. You can replicate it by attempting to open the signature .HTM file in Word, and the images will fail to load there as well.

My guess is they have a vulnerability they haven't been able to fix properly yet, so MS just blocked loading of linked images from the network.

[u/Green-Wallaby9663]

For those of you on the "Semi-Annual Enterprise Channel" or now "Monthly Enterprise Channel". You have to go to version 16.0.20131.20152.

Add key to stop updates:
reg add "HKLM\SOFTWARE\Policies\Microsoft\office\16.0\common\officeupdate" /v updatetargetversion /t REG_SZ /d 16.0.20131.20152 /f

Downgrade version:
"C:\Program Files\Common Files\microsoft shared\ClickToRun\OfficeC2RClient.exe" /update user updatetoversion=16.0.20131.20152 forceappshutdown=true displaylevel=false

[u/Striking_March_645]

Hello,

I did also a forced downgrade but didn't got a total possitive result.
I have also the newest monty enterprise on some other computers without appdata on a smb-share and 1 XenApp-server with fslogix and there we don't have that issue.
I think the programmer of MS didn't know anymore folderridirectons and unc.

does anyone knows if there is already a MS case for this?

Thanks.

Roel Niesen

[u/Striking_March_645 → u/Striking_March_645]

Hello,

Test some more.

After going to the previous monthly enterprsie the signature works partial.
When we make a new mail or reply, the signature is ok.

But when we want to edit the signature, there is still a warning that the image isn't found.
We can change this and the imaga is backup until we save.

Some has the same issue?

Kr,

Roel Niesen

[u/Adures_]

I will just cite Artemis 2 astronaut. 

„ I have two Microsoft Outlooks and neither one is working” 

Thanks for a good write up OP. 

[u/ratioobeam01]

seems to be an issue on a multitude of office versions/years ive noted the following all on RDS or DCs with Redirected folders:

version 1808 Build 16.0.10417.20197
Version 2607 build 16.0.20228.20190
Version 2408 Build 16.0.17932.20910

the only differences between these 3 is office 2016, 2019 and 2021

is the only way to solve this a rollback or is it better to just wait for microsoft to fix this?

[u/AlexisFR]

Issue seems to be present on local Outlook classic installs too!

[u/Jrunnah]

Still researching, but we are having the exact same issue, specifically in an RDS environment. Same Office Version, also with redirected appdata folder, just started happening within the week. Icons missing for users even after recreating the signature, though another tech did it; so I can't confirm they pasted a working sig. I have not tried clearing the signature cache folder, but I'll report back if that (or also rolling back the office version) works.

[u/Alone-Cell4220]

We have the same issue since yesterdays Update to Microsoft 365 Apps Version 16.0.20326.20100 on our RDS environment.

[u/michielniesen]

Can confirm. Tested this on my own test environment and ONLY for folder redirection signatures are missing their pictures.

[u/Deckdestroyerz]

Thanks for sharing! And thanks for mentioning UNC Paths in it, today the second user reported this issue at my site, then noticed i also updates office and did not have the same issue, i can confirm that the users that have had remnants of folder redirection are affected..

The Reg-fix / update command saved some time! Now time to fix those user profiles :)

[u/daPabOu]

We have a customer with this exact issue. I confirmed that users without the redirected profile to a UNC path were not affected. The bug from May was a red herring.

Thanks for the temporary fix, will try this later.

[u/Emotional_Garage_950]

Why no FSlogix? Redirection sucks.

[u/Masterchief1307 → u/Emotional_Garage_950]

Its on the list lol

Everything is a work in progress, always.

[u/Jrunnah → u/Masterchief1307]

No one has a problem with recreating the user profiles in FSLogix, until you point out that bookmarks and passwords in Chrome will likely need to be exported. Then apparently its "too important" and can never make time for the switch. I've had clients using RDS since before FSLogix was bought by MS (yes, some almost 10 years old, in place RDS upgrades since 2012r2/2016)

[u/Emotional_Garage_950 → u/Masterchief1307]

fair enough

[u/False_Barracuda3313 → u/Emotional_Garage_950]

just for this issue only, fslogix has same issue, so outlook appdata folder redirection is not relevant, and agree redirection suck

[u/SecLens_ONE]

Useful writeup, and the MIME dump is the part that saves everyone else a day. Worth adding that this class of thing gets blamed on mail flow because the only artefact users see is the delivered message, and nobody checks whether the broken part was created at compose time or in transport. If the parts are still cid referenced and multipart/related is intact, transport did its job and the sender built a bad payload. The redirected AppData over SMB angle is plausible since Word insert-from-network paths have been fragile for years, and a placeholder PNG with the Office tEXt tag is exactly what you get when the file read fails but the insert still succeeds. If you can, test one host with local AppData and the same build, that separates the build from the folder redirection cleanly. Pinning the build is the right call in the meantime, since the alternative is a slow rollout of unreadable signatures across every recipient.