We are experiencing an issue specifically with PowerPoint Online editing through WOPI. For the first time able to edit the ppt file but next time when try to open the same document it is not opening.

Hi,

I found this question here now, while trying to figure out what has started happened with our Microsoft Office for Web integration. Was there any solution found?

A few days ago we started to get reports from our users (production environment) that PowerPoint files are not opening, showing the same error as @Santanu DonePact posted here. Investigation showed that opening a pptx file the first time works, and the file can be edited. After closing it and then trying to re-open it fails with this error.

Analysis of this shows exactly the same flow as described here. During the first edit, the document is properly locked, putfile, unlocked. When opening a second time, it does the checkfileinfo, getfile, checkfileinfo, checkfileinfo. No locking requests are received. And after a while the GUI reports the error.

We have tried a most of the suggestion by @Gabriel-N (in development environment)

• Validating that version is consistent. A new version is generated after the putfile.
• "DisableCoauthoring": true
• Use the WOPI Validation Tool - works both in production and development environments (50 successful, 178 skipped).

This error only occurs for PowerPoint. Excel and Word works without any problem.

Hello @Santanu DonePact

I would like to first clarify that this is a user-to-user support forum, and we are not Microsoft support. Moderators here do not have backend access and cannot directly intervene in Microsoft products or perform escalations. We can only provide technical guidance and best-practice recommendations based on reported issues.

Based on my research, I have a few ideas that might be helpful to check.In some cases, if the co-authoring capability signals are not fully aligned or appear inconsistent, the client may stay in a safe polling state instead of proceeding to LOCK. You may want to try adding "DisableCoauthoring": true in the CheckFileInfo response to enforce single-user locking behavior. If co-authoring is intended, you could also verify that related signals (such as consistent FileId/WopiSrc and capability flags) remain stable across sessions.

Another area that may be worth checking is versioning behavior. Even if the same Version value is returned consistently, some clients rely on version changes to determine whether a fresh edit session should be initiated. If the version does not change after a PutFile, or if there is any mismatch between the Version in CheckFileInfo and the X-WOPI-ItemVersion header returned by GetFile, the client might decide not to proceed with LOCK.

As a test, you could try generating a new unique Version value after each successful PutFile, and ensure the exact same Version string is returned both in CheckFileInfo and in the X-WOPI-ItemVersion response header from GetFile.

You could also consider including a few additional standard metadata fields in CheckFileInfo to see if it improves consistency, for example:

• "LastModifiedTime" (ISO 8601 format)
• "IsEncrypted": false
• "BreadcrumbDocName"
• "UserFriendlyName"

These are not strictly required for PowerPoint, but in some implementations they appear to help the client establish a more stable edit context.

For diagnostics, you might want to capture a browser network trace while the polling is happening:

• Open Developer Tools (F12) > Network tab
• Observe requests to the Office endpoints
• Compare the request/response pattern between the first (working) open and the second one

This may not always expose a clear error, but sometimes subtle differences in headers or flow can provide useful clues.

Or you might want to use Microsoft’s official WOPI Validator tool. It is designed to test exactly these scenarios (edit flows, locking, PutFile, and version handling).

However, please note that these are suggestions based on research. I don’t currently have the same environment to reproduce this scenario, so I wouldn’t want to draw a definitive conclusion.

If the issue continues, it might be helpful to open a support request with Microsoft Cloud Storage Partner Program so they can review it from the service side and provide deeper diagnostics.

Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.