MSOFBA stopped working with Version 2603 Build 16.0.19822.20086) 64 bits of microsoft word

We have the same problem with first broken Version 19530.20138 and last working 19426.20218

According to the traces the problem is WebView2 using Edge instead of WinINet with IE7.0. Previously, we see some tries using WebView2 but after that a fallback to IE7. Since IE7 seems to share the same cookies with Office (probably due to WinInet), it works as expected. With WebView2/Edge, there are two separate cookie stores and the cookie(s) seem to be copied over in the end. However there are multiple caveats:

1. Session Cookies with a Domain seem to be ignored
   1. This possible is due to https://github.com/MicrosoftDocs/win32/blob/docs/desktop-src/WinInet/http-cookies.md where WinInet states: "Session cookies that specify a domain are rejected."
2. If there was already a session cookie in the office Client (for example an expired previous cookie or a new cookie just set seconds ago by its first disovery calls using OPTIONS), the new cookie is added to the cookie store, not replacing the existing cookie. Therefore the next call from Office contains two cookies. Depending on the Server evaluating those cookies, the correct or the wrong might be considered.

Those insights are totally observation- and experiment-based, I've not found any official documentation describing those behaviours at all. The referenced MSOFBA Documentation is from around 2022 where WebView2 probably didn't even exist yet.

Hi @Arnaud DESAULTY   

Based on my research so far, I’m happy to share the insights I’ve gathered regarding your inquiries. 

1/ Has anyone observed similar behavior following a recent Office or Click to Run update? 

From the information I was able to find, I did not come across any similar public report linked to a recent Office update. 

2/ Are there known changes to how MSOFBA shares session cookies with the WebClient service that third party integrators should account for? 

Based on the latest MSOFBA documentation in [MS-OFBA]: Office Forms Based Authentication Protocol | Microsoft Learn, I did not identify any documented change related to how session cookies are shared with the WebClient service that third party integrators would need to account for. 

3/ Are there recommended diagnostics, such as Fiddler traces, WebClient logs, or registry keys, to confirm whether the cookie is being dropped between the authentication UI and the WebDAV client? 

Yes, the tools you mentioned would be very helpful for this type of investigation. They can help verify whether the cookie is being lost between the authentication UI and the WebDAV client, and they may also provide useful visibility into the overall WebDAV authentication flow. 

In addition, the most relevant detail I found is that the authentication UI currently uses WebView2, which stores cookies in the user data folder. 

Based on your scenario, it seems possible that WebDAV may not be able to access or read that cookie store under the newer architecture. 

With that in mind, you may want to temporarily disable WebView2 integration and check whether the behavior changes. 

• Registry path: Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\AAD 
• Registry value: Create a DWORD value named WebView2Integration and set it to 0 to turn WebView2 integration off. 

References:  

• Manage user data folders - Microsoft Edge Developer documentation | Microsoft Learn 
• Now generally available: Modernizing Microsoft Entra ID auth flows with WebView2 in Windows 11 - Wi… 

I would also like to clarify that, as a forum moderator, I do not have a dedicated testing environment to provide hands on validation or deeper implementation guidance. 

That said, for further insights, I recommend reaching out to community · Discussions · GitHub, where many experienced professionals with advanced environments and expertise actively share their knowledge. 

I hope this brings additional insight. 

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.

The behavior described is not documented in the provided context, and there is no information about MSOFBA or cookie‑sharing changes between Office 2112 and 2603.

The only relevant items in the context related to Office authentication and WebDAV are:

• Historical MSOFBA/Office fixes that required a registry flag to refresh form‑based auth cookies after token expiry.
• WebDAV redirector (WebClient) registry settings and troubleshooting guidance.
• Basic authentication over WebDAV (including security considerations and how to enable it via registry keys).

From this, the only concrete, supported diagnostics and mitigations that can be suggested are:

1. Verify and adjust WebDAV redirector settings on affected clients Check the WebDAV redirector (WebClient) registry configuration, which controls how the WebDAV client behaves:
   • Registry path: HKLM\SYSTEM\CurrentControlSet\Services\WebClient\Parameters
   Relevant values from the documentation:
   • AcceptOfficeAndTahoeServers (DWORD)
     • 0 = False
     • 1 = True (default)
     • Ensures WebClient can connect to SharePoint/Office Web Server endpoints.
   • FileNotFoundCacheLifeTimeInSec (DWORD)
     • For file‑not‑found issues, can be set to 0 to avoid stale cache entries.
   • BasicAuthLevel (DWORD)
     • 0 = Basic authentication disabled
     • 1 = Basic authentication enabled for SSL web sites only
     • 2 = Basic authentication enabled for SSL and non‑SSL web sites
   If the integration relies on Basic auth over WebDAV (for example, as a fallback or part of the flow), confirm that BasicAuthLevel is set appropriately for the environment and that SSL is used where possible. After changing any of these values, restart the WebClient service or reboot the machine as required by the documentation.
2. Confirm client‑side Basic authentication configuration (if applicable) If the EDM solution uses Basic authentication over WebDAV (for example, in combination with or as a result of the MSOFBA/OAuth flow), ensure that the client is configured to allow it:
   • Registry path: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WebClient\Parameters
   • BasicAuthLevel (DWORD) should be set according to the desired behavior:
     • 0 – disabled
     • 1 – enabled for SSL only
     • 2 – enabled for SSL and non‑SSL
   The documentation emphasizes that Basic authentication over non‑SSL is disabled by default in Office 2010+ due to security risks, and must be explicitly enabled if required.
3. Consider the historical MSOFBA cookie refresh behavior A prior Office issue required a registry flag to refresh form‑based auth cookies after token expiry:
   • Registry path: HKEY_CURRENT_USER\Software\Microsoft\Office\15.0\Common\Internet
   • RefreshFormBasedAuthCookie (DWORD) = 1
   That fix was tied to specific Office 2010/2013 updates and MS‑OFBA token expiry. While the context does not state that this applies to current Microsoft 365 Apps builds, it shows that Office has historically controlled MSOFBA cookie refresh behavior via registry.
4. Use WebDAV‑level diagnostics The WebDAV redirector guidance recommends:
   • Using Fiddler or similar HTTP tracing to inspect WebDAV requests and responses, verifying whether the auth cookie is present on the WebDAV traffic after the MSOFBA flow completes.
   • Checking for FileNotFound‑related caching issues and, if relevant, setting FileNotFoundCacheLifeTimeInSec to 0 for troubleshooting.
   Although the context does not provide a dedicated logging mechanism for WebClient beyond registry tuning, HTTP traces will show definitively whether cookies are missing from WebDAV requests.
5. Validate that the issue is build‑specific The context includes a separate Office 365 Apps issue introduced in build 2603 (16.0.19822.20086) where Exchange add‑ins fail to load, and the suggested mitigation is to revert to an earlier build:

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

   This shows that build 2603 has introduced at least one regression in Office behavior. As a diagnostic step, temporarily reverting to a known‑good build (such as the last working build in the environment) can confirm whether the MSOFBA/WebDAV issue is also build‑specific. If reverting resolves the problem, that strongly indicates a regression in the newer build and should be reported through official Microsoft support channels with traces and version details.
6. Security considerations The documentation reiterates that Basic authentication sends credentials in base64 over the network and is only considered acceptable over secure connections (SSL/TLS or dedicated lines). Any use of Basic auth in the integration should be protected accordingly.

Beyond these points, the context does not document any specific change in how MSOFBA shares cookies with WebClient or WebDAV, nor does it provide a direct fix for the described behavior.

References:

• Using the WebDAV Redirector
• Office applications open blank from SharePoint WebDAV or sites
• Operation fails when you try to save an Office file through Web Application Proxy in Windows Server 2012 R2
• Exchange Add-ins not loading for some users - Microsoft Q&A