Word 2609 Still Hides PDFs After the SharePoint Fix

Microsoft marked Word 2609’s SharePoint PDF save as fixed after a service change fully rolled out on September 25, 2026. The same 16.0.20430.x family still sent network-drive PDFs into a hidden Windows cache, and Word showed no error.

Those files land in Content.MSO with random names such as 1f10f000, while the SharePoint library the user picked stays empty. Colleagues never see a new document, and the only copy sits in a folder Windows is allowed to clear.

Microsoft Marks the SharePoint Path Fixed

The known issues note applies to Word for Microsoft 365 on Windows after a move to version 2609, build 16.0.20430.x. Microsoft says the failure hits only one path: Save or Save As, PDF as the file type, and a SharePoint Online folder as the destination.

No dialog appears. The PDF is written to C:\Users\username\AppData\Local\Microsoft\Windows\INetCache\Content.MSO with a random file name. The known issues page, last updated September 29, 2026, now lists the status as Fixed, fixed by a service change that fully rolled out on September 25, 2026.

This issue has been fixed by a service change which fully rolled out on 9/25/26.

Microsoft Support, Word for Microsoft 365 known issues, last updated September 29, 2026

Anyone who still sees the miss is told to close every Office app and open Word again so the change is picked up. That is a cloud-side flip, not a new Word build. PCs can stay on 2609 and still be told the SharePoint case is done after a restart.

The First Report Was a Network Drive

The public thread did not start on SharePoint. On September 15, 2026, a Microsoft Q&A user posting as Jeff said Save As PDF from a file on a network drive wrote the output to Content.MSO instead of the source folder, with names such as 1f10f000 and 458d72b7. The build was Microsoft Word for Microsoft 365, Version 2609, Build 16.0.20430.20032, 64-bit. Print to PDF still worked.

More than 30 people marked the same question. Volunteer moderator Jay Freedman noted that 16.0.20430.20032 sat on Current Channel (Preview), the Insider track, and that newer preview builds had already shipped. The failure did not stay there.

On September 25, 2026, Manuel Mahr wrote that Microsoft 365 Apps for business, Version 2609, Build 16.0.20430.20092, reproduced the miss on multiple PCs. His team narrowed it to PDF saves aimed at network locations. Local destinations worked. When the network-to-network export failed, the PDF appeared under %LOCALAPPDATA%\Microsoft\Windows\INetCache\Content.MSO.

MANUEL MAHR’S DESTINATION TESTS

Microsoft’s known issues line never names a mapped drive or a UNC path. It names SharePoint Online. That gap is why network-drive PDF saves still fail in later posts even after the SharePoint ticket flipped to Fixed.

Who Got Version 2609, and Who Did Not

Check the build under File, Account, About Word. A 2609 install whose number starts with 20430 is in the family Microsoft listed. Home users and other Current Channel devices took 2609 in production on September 22, 2026, as Build 16.0.20430.20092. A follow-up, Build 16.0.20430.20118, shipped on September 30, 2026.

The Current Channel notes for version 2609 describe 16.0.20430.20118 as various fixes to functionality and performance. They do not list a Word PDF or SharePoint save item. The September 22 notes for 16.0.20430.20092 mention an Excel hang on close, not this PDF path.

WHERE 2609 ACTUALLY LANDED

Monthly Enterprise Channel, on Microsoft’s channel history, was still on version 2608 as of September 8, 2026. Those devices never took the 20430.x builds named in the known issues note. The miss clustered on Current Channel and its preview ring, which is why a help desk that only watches Monthly Enterprise can think the bug is theoretical.

The Folder Windows Is Allowed to Empty

Content.MSO is not a user documents folder. Microsoft’s own older guidance on slow network saves describes Content.MSO and Content.Word as hidden, system-protected subfolders that Word, Excel, and PowerPoint use for temporary files during a save. On modern Windows the parent is INetCache, the renamed Temporary Internet Files tree.

The bug leaves the finished PDF in that temp location under a hex-style name, so a search for the document title finds nothing. Word behaves as if the save succeeded. The SharePoint folder later shows no new file, and audit events that fire on upload never run, because the library never received an object.

Recover the Random-Named PDFs

Recovery has a clock on it. INetCache is a cache. Disk cleanup tools, and advice that Content.MSO objects can be deleted to free space, treat those files as disposable. Independent Advisor Harry Phan, answering a separate Microsoft Q&A thread in March 2026, called Content.MSO files temporary cache objects that can be removed without breaking Office.

STEPS TO PULL THE FILES BACK

• Open the cache: In File Explorer’s address bar, paste %LOCALAPPDATA%\Microsoft\Windows\INetCache\Content.MSO and press Enter.
• Sort by time: Use Date modified so the newest objects rise to the top, then open PDFs created around the failed save.
• Rename and move: Give the right file its real name and copy it to the SharePoint library or network folder that should have received it.
• Delete leftovers: Remove extra copies of confidential PDFs from Content.MSO after the real file is stored where policy requires.

Do that before Storage Sense or another cleanup job treats the cache as junk. Microsoft documents Storage Sense as a tool that deletes unused temporary files when it runs, including when a PC is low on disk space.

A Temp Folder Is Not a Library

A PDF meant for a locked SharePoint site is now a local file with no random name that matches the title, sitting outside retention labels, sensitivity processing for uploaded PDFs, and the FileUploaded trail admins search in Purview. The user thinks the record is in the library. The library never saw it.

That is the second failure, after the missing file. The copy that does exist is the one least covered by the controls that justified saving to SharePoint in the first place.

Build 20118 Still Splits Testers

On October 1, 2026, Giannis Kyriazakos wrote that the latest build, 20118, fixed the issue. On October 2, 2026, a user posting as Seryoga replied that the same update did not fix Save as PDF to network drives.

WHAT WE KNOW

• SharePoint path: Microsoft lists Save As PDF to SharePoint Online on 2609 (16.0.20430.x) as fixed after the September 25, 2026 service change, with a full Office restart required.
• Silent miss: Word presents no error; the PDF is stored in Content.MSO under a random name.
• Network tests: On 16.0.20430.20092, network-to-network PDF save failed and local PDF save worked.
• Older build: Rolling back to version 2608, Build 16.0.20326.20072, restored the network path in those tests.

WHAT IS UNCONFIRMED

• Build 20118: Testers disagree on whether Save as PDF to network drives is repaired.
• Old cache copies: Microsoft has not said the service change uploads PDFs that already landed in INetCache.
• Other channels: Monthly Enterprise was not on 20430.x in the September 8, 2026 history snapshot, so a later 2609 drop there is still an open admin question.

A service change can stop new SharePoint misses after Word is restarted. It does not, by itself, prove that every remote destination is healthy, and it does not vacuum hex-named PDFs out of AppData.

Export, Print, or a Full Rollback

Microsoft’s workaround, while the known issues page still described a live bug, was to save somewhere else or to use File, Export, Create PDF/XPS Document. That Export command is the supported way to save or convert to PDF or XPS from Word, and a Q&A comment from a user posting as DC on September 25, 2026, said Export worked when Save As did not.

Saving the PDF to the local disk, then uploading it to SharePoint, also avoids the broken handoff. Print to PDF still ran for Jeff on 16.0.20430.20032. Printed PDFs typically lose clickable links, bookmarks, and accessibility tags, so it is a weaker stand-in when those features matter.

Jeff’s accepted note on September 17, 2026, was a rollback. From an elevated Command Prompt:

• Change folder: cd "C:\Program Files\Common Files\Microsoft Shared\ClickToRun"
• Pin the older build: OfficeC2RClient.exe /update user updatetoversion=16.0.20326.20072
• Stop the bounce-back: He then disabled automatic Office updates, because a later 2609 drop would undo the pin.

Ten people marked that rollback helpful. Jesús San Miguel wrote that “Version 92” (16.0.20430.20092) was also affected and that dropping to “72” (16.0.20326.20072) worked. JamesM_111 said the same rollback helped, then warned that auto update made it a short-term fix.

Admins who cannot freeze Current Channel can still tell PDF-to-SharePoint users to use Export, and can inventory devices on 16.0.20430.x before the next silent miss.

Copies That Never Reached the Library

The status line on SharePoint is now Fixed. The first complaint, and the October 2 complaint, were about network drives. Seryoga’s wording was blunt.

I checked, and this update didn’t fix the issue. It still won’t save to network drives when using Save as PDF.

Seryoga, Microsoft Q&A, October 2, 2026

Until those two stories agree, a “fixed” SharePoint save is not the end of the file. It is a restart, a different menu, and a cache folder that may still hold the last PDF nobody could find.

Check About Word for 2609 and 20430. If a PDF went missing between mid-September and the restart, open Content.MSO before anything empties it, and put the real file in the library that never logged the save.