Outlook New Experience update - network save location bug

We have been having this issue on and off for about 2 years in our organization. Microsoft fixes it, breaks it, fixes it, breaks it. We are now stuck on v 2302 (Build 16130.20500) as 2305 and 2306 are both experiencing this issue. We're having to manage versions in group policy and would love to be patched and running the new version but when you have users constantly complaining about this, it makes daily work on client side rough and administration on sysadmin side rough.

Hi Gabe,

we thought that 2305 had fixed that bug last week, this week after the latest server updates it seems to be back.

I got it twice today. We also had the problem in Excel and had, until last week when it was closed, a separate question on that here.

I can confirm that other users of Excel have been having similar issues too so I thought we may be looking at a bug that affected Office all versions so did some searching and found this. Saving Office documents to a network server is slow when using EFS

It is rather out of date despite being updated May last year. The link to Enabling Delegated Authentication goes to a page about Server 2K3 and the registry locations are for Windows 8 and before.

The bottom line is it points to a problem with a server that is enabled for Encrypting File System but not configured to use it.

We tick that box but not the rest of the article.

Symptoms

Assume that you use the Encrypting File System (EFS) to help secure the Temporary Internet Files folder. You save Microsoft Office documents to a remote server than can support encryption, but the server is not configured to do remote encryption. In this situation, it takes longer than expected to save the documents.

By default, the "Content.MSO" and "Content.Word" subfolders are used by Excel, Word, and PowerPoint. They are hidden, system-protected subfolders of the Temporary Internet Files folder, as seen in the following example path:

C:\User<user name>\AppData\Local\Microsoft\Windows\Temporary Internet Files\Content.MSO

In Windows 8, the Temporary Internet Files folder is now known as the "INetCache" folder. Therefore, the path to the "Content.MSO" subfolder would be as follows:

C:\Users<user name>\AppData\Local\Microsoft\Windows\INetCache\Content.MSO

As far as I can tell there are no files or directories showing the Encrypted attribute, if it is still valid instructions I am told that adding the Attributes Column to the Details View in Explorer should show an E against any encrypted folder. I have also checked the properties of the folders and under Advanced there is no tick in the box for Encrypt this folder. At first I thought this ruled it out as a potential fix.

However, we do use Bitlocker so by default the entire disk is encrypted. I suspect that EFS is not the only form of Encryption and therefore BitLocker may count too.

Based on that I have chosen to follow option 2 in the article referenced and set the following in registry on our file server

Disable EFS encryption support on the server by changing the following registry entry:

• PATH: HKLM\SYSTEM\CurrentControlSet\Control\FileSystemValue
• DWORD: NtfsDisableEncryption
• VALUE: 1

I will update you after I have observed it for a few days more and canvassed the rest of the staff.

I would however be very interested in any comments you have about checking for EFS on a folder or file and Bitlocker being treated as an EFS file system by a server when dealing with a network share. It seems to me this could be the underlying cause of both Outlook and Excel delays when they try to open the save dialog if the default save location is to a mapped drive or UNC fileshare.

Nick,

Those are several issues, but I can comment on these two:

a:

we are in the middle of migration to office 365 so have both office 2013 and office 365 installed on a number of Windows 10 22H2 machines.

When this bug first hit 365 we noticed that it did not affect office 2013. Around the release of 2208 which fixed it for 365 an update for Office 2013 introduced the same bug into office 2013. This was later fixed in 2013 we assume by another update and has since returned in 365.

[Gabe] For this issue the fix is now in all Office channels including SAEC via Version 2208 (Build 15601.20538). I have not seen any new support cases or queries from support engineers about this bug. If you still repro in any of the fixed builds, please open a ticket in the support center in the M365 admin center.

Fixes to all channels so far:

Fix is in CC, MEC, with

Version 2211 (Build 15831.20190)

Fix is in SACP, SAEC with

Version 2208 (Build 15601.20538)

Only SAEC-Extended does not have the fix

b:

Windows 11 is so broken that even Microsoft can’t fix it | TechRadar

"Microsoft has just made a pretty remarkable admission, essentially conceding that it doesn’t have a solution for some Windows 11 problems.

As Neowin reports, some people using Windows 11 and Windows 10 have found a bug which prevents the Start menu, Windows search bar and some Universal Windows Platform (UWP) apps from starting or working correctly.

It appears that the bugs coincide with damaged registry keys and data related to Microsoft Office apps, and apps that are integrated with Office software, as well as Windows and Outlook."

[Gabe] For this issue, Windows 11, version 22H2 known issues and notifications | Microsoft Learn (Start menu, Windows Search and UWP apps might have issues opening), the fix is in Office Current channel Version 2304 (Build 16327.20214).  This build should get to the MEC channel on patch Tuesday June 13th.

This fix was a big effort across multiple product teams with changes in both Windows and Office. There were a lot of moving parts to this and probably why the delay from Windows updating the article linked above.

If you are asking about SAEC it appears the fix is in Version 2208 as noted below. I don't see any edits to the bug to indicate any issues with the fix released so far.

Release notes for Semi-Annual Enterprise Channel (Preview) releases in 2022 - Office release notes | Microsoft Learn

Version 2208: February 14

Version 2208 (Build 15601.20538)

Office Suite

• Fixed an issue where a dialog box saying "Trying to connect" would appear for multiple minutes while trying to save a new file to a network share, e.g., while using Save As or Browse in Word, Excel, and PowerPoint. This issue also affected saving email attachments to a network share.

Hi Gabriel,

" I don't see any edits to the bug to indicate any issues with the fix released so far."

Sadly with all the best will in the world that could mean that Microsoft has either

a: not yet realised, despite plenty of users reporting it, that they have inadvertently reintroduced the problem

b: is not interested in fixing it because it is broken beyond economic repair.

I have evidence for both those assertions.

a:

we are in the middle of migration to office 365 so have both office 2013 and office 365 installed on a number of Windows 10 22H2 machines.

When this bug first hit 365 we noticed that it did not affect office 2013. Around the release of 2208 which fixed it for 365 an update for Office 2013 introduced the same bug into office 2013. This was later fixed in 2013 we assume by another update and has since returned in 365.

b:

Windows 11 is so broken that even Microsoft can’t fix it | TechRadar

"Microsoft has just made a pretty remarkable admission, essentially conceding that it doesn’t have a solution for some Windows 11 problems.

As Neowin reports, some people using Windows 11 and Windows 10 have found a bug which prevents the Start menu, Windows search bar and some Universal Windows Platform (UWP) apps from starting or working correctly.

It appears that the bugs coincide with damaged registry keys and data related to Microsoft Office apps, and apps that are integrated with Office software, as well as Windows and Outlook."

The 365 platform has also recently been hit by another self inflicted problem that took a long while to fix.

MO545600 additional impact - Search queries may have returned partial results.

The post incident report makes for interesting reading.

Code changes had to be rolled back to prevent further corruption of search indexes and remedial re-indexing scripts had to be deployed to repair the damage already done.

I find it very good practice that the team have admitted the problem, documented the fix and looked at preventative measures to stop it happening again.

However, I can also add that Microsoft has a history, with me at least, of not admitting they have a problem.

I have an open support ticket on a part of the 365 Defender platform that appears to be a coding problem with the web UI as well as search filter related in Quarantine.

That problem has existed for months but Microsoft would not admit to it.

My reports via the Admin Console kept getting closed as false positives so I was forced to open a support ticket via our CSP.

Watching the failed page loads and other error messages appear on screen prompted me to open he Edge and Chrome Developers Console.

The output is very interesting.

I just opened the 365 Defender home page a few seconds ago and the problem is still there

Client Error Database is not online. WebstoreApplication("defaultconfig\messagetracedb") WstError(EcMarkedOffline): Database is not online.

The list of major and minor errors is quite long.

That is what Microsoft called a false positive when I tried to report it.

The below error list is just the dashboard page for the 365 Defender loading and this is just a selection.

Going into quarantine also intermittently produces similar errors i.e. failure to load, database offline, very long load times and previously inconsistent application of search filters (probably now resolved by MO545600 as it did eventually load after a very long time the requested view.

POST https://security.microsoft.com/api/m365/shared/DataProvider/GetAll?providerIds=EnterpriseSecurity\_RiskyUsers 500

AJAX error from /api/m365/shared/DataProvider/GetAll?providerIds=EnterpriseSecurity_RiskyUsers.

Uncaught (in promise) Error: Request failed with status code 500

at e.exports (createError.js:16:15)

at e.exports (settle.js:17:12)

at XMLHttpRequest.E (xhr.js:66:7)

GET redacted failed status 404

GET redacted failed status 400

GET redacted failed status 400

Request failed with status code 400 {stack: 'Error: Request failed with status code 400\n

at …urces/ww/scc/static/axios/0.24.0/axios.js:1:7142)'}

Request failed with status code 400

{stack: 'Error: Request failed with status code 400\n at …urces/ww/scc/static/axios/0.24.0/axios.js:1:7142)',

errorMessage: 'wicd-common bootMtp failed on load.'}

AJAX error from /apiproxy/mtp/k8s/mgmt/TenantContext. {data: {…}}

Uncaught (in promise) Error: Request failed with status code 400

at e.exports (createError.js:16:15)

at e.exports (settle.js:17:12)

at XMLHttpRequest.E (xhr.js:66:7) with-bootstrap.hoc.tsx:54

Uncaught (in promise) Error: Request failed with status code 400

at e.exports (createError.js:16:15)

at e.exports (settle.js:17:12)

at XMLHttpRequest.E (xhr.js:66:7)

GET failed with a 500 status

Client error popup opened for: /apiproxy/psws/QuarantineMessage?
PageSize=100&Page=1&MyItems=false&$filter=(QuarantineTypes%20eq%20'TransportRule'%20or%20QuarantineTypes%20eq%20'Bulk'%20or%20QuarantineTypes%20eq%20'Phish'%20or%20QuarantineTypes%20eq%20'Malware'%20or%20QuarantineTypes%20eq%20'Spam'%20or%20QuarantineTypes%20eq%20'HighConfPhish'%20or%20QuarantineTypes%20eq%20'DataLossPrevention')%20and%20(ReleaseStatus%20eq%20'NOTRELEASED'%20or%20ReleaseStatus%20eq%20'RELEASED'%20or%20ReleaseStatus%20eq%20'REQUESTED'%20or%20ReleaseStatus%20eq%20'APPROVED'%20or%20ReleaseStatus%20eq%20'DENIED')%20and%20(PolicyType%20eq%20'AntiMalwarePolicy'%20or%20PolicyType%20eq%20'SafeAttachmentPolicy'%20or%20PolicyType%20eq%20'AntiPhishPolicy'%20or%20PolicyType%20eq%20'HostedContentFilterPolicy'%20or%20PolicyType%20eq%20'ExchangeTransportRule'%20or%20PolicyType%20eq%20'DataLossPreventionRule')&StartReceivedDate=2023-05-24T09%3A45%3A03.490Z&EndReceivedDate=2023-05-25T23%3A00%3A00.000Z&StartExpiresDate=2023-05-24T23%3A00%3A00.000Z&EndExpiresDate=2023-06-24T23%3A00%3A00.000Z Status: 500 {data: {…}}

Uncaught (in promise) Error: Request failed with status code 500

at e.exports (createError.js:16:15)

at e.exports (settle.js:17:12)

at XMLHttpRequest.E (xhr.js:66:7)

If you are asking about SAEC it appears the fix is in Version 2208 as noted below. I don't see any edits to the bug to indicate any issues with the fix released so far.

Release notes for Semi-Annual Enterprise Channel (Preview) releases in 2022 - Office release notes | Microsoft Learn

Version 2208: February 14

Version 2208 (Build 15601.20538)

Office Suite

• Fixed an issue where a dialog box saying "Trying to connect" would appear for multiple minutes while trying to save a new file to a network share, e.g., while using Save As or Browse in Word, Excel, and PowerPoint. This issue also affected saving email attachments to a network share.