Office 365 Outlook (and Excel both 365 and 2013) slow to save or browse to network shares.

Dear Nick Kulkarni,

Good day!! Thanks for posting your concern in this Microsoft Community.

Apologies for the inconvenience caused due to the latest version of the Office apps and appreciate for sharing the detailed information.

As per the description shared, I understand the problem facing at your end and it seems the problem could be related to incompatibility of the latest version of Microsoft apps and servers. My suggestion is to contact the related Office apps team where they can reproduce the problem and collect the Fiddler logs to find the out the cause of the problem, to create a support ticket from the Office 365 admin center, please refer to this KB: Get support - Microsoft 365 admin | Microsoft Learn

Moreover, I will keep this thread open so that experts and MVPs in this community can share their experiences on your concern.

Thank you for your patience and understanding.

Sincerely

Mia | Microsoft Moderator

Hi Mia,

Thanks for your comments, as far as I know the method of dealing with this you suggest will not work.

Support from the MS Admin Centre is marked with the following disclaimer

We are a break-fix team, and we would not be doing any Root Cause Analysis (RCA), deployment, change request in the product design, and scripting of PowerShell commands. Please note that according to the Microsoft Policy each support incident can only address one problem. We are only allowed Quick assist for the remote sessions.

Nick,

See if the issue in this known issue might apply, Outlook Desktop is slow to save attachments to a network path - Microsoft Support. You could try reverting to Version 2303 or stopping the Web Client Service and confirm if that mitigates the issue. The Outlook Support Escalation Team is working on getting this escalated for a bug.

Hi Gabriel.

Thank you for the information.

I have just checked that I can stop and disable the Web Client Service when logged on as a domain user (we have a very restricted domain for users but an elevated .msc worked for me). It seemed a lot quicker than trying to revert to an earlier build and safer too because I cannot recall exactly how far back this originally started.

I am certain we had the problem a lot earlier than Version 2303. See here on Spiceworks Community Forum from July 2022. This would be somewhere around Build 2202 - 2206 depending on release channel I think.

I am on 2307 Build 16626.20134 at the moment and to be honest the problem was not present when I saved an attached PDF this morning which was much to my surprise because it was still here last week.

I am going to re-enable the Web Client and wait to see if the problem returns then test your suggested fix by closing outlook, disabling the Web Client and reopening Outlook and trying again. If it does and the workaround fixes it I will update you.

cheers

Nick

Hi Gabriel,

Did some testing and I can now reproduce it at will and disabling the Web Client does not fix it.

Outlook is unique amongst the Office 365 suite in that the GUI does not allow you to set the default save location.

Instead you have to use a registry key see here

If this REG_EXPAND_SZ "DefaultPath"  is set in HKEY_CURRENT USER\Software\Microsoft\Office\1x.0\Outlook\Options to a UNC path the problem occurs

If it set to a mapped drive, even if the ultimate destination is identical, the problem does not occur.

I hope this helps escalate this to a bug because it is now reproducible and we know what the problem is for Outlook now.

This is not the first time I have seen Office treat UNC and Mapped Drives differently. It was breaking links to Excel Workbooks on a regular basis for us.

According to the Microsoft Learn article it is not limited to Excel only and includes Outlook in the list of affected applications. There is no workaround for this shown there. The problem with Excel seems insolvable due to the inconsistency in behaviour created when calling a workbook which may be invisible to a user as shown by this Microsoft article Network Mapped Drive Hyperlinks resolve as UNC in Office Products - Office | Microsoft Learn

Symptoms

After a user inserts a hyperlink to a file residing on a network mapped drive within an Office product, the hyperlink's text displays the network mapped drive path, however the link is resolved as the UNC path.

The above article taken together with the an article about the behaviour of links in Excel suggests strongly that the handling of network links in Office Apps is not consistent between apps and possibly not even within functions of the same app. That there are differences in the way files opened via UNC and Mapped paths respond is explained in some detail, including the fact that how Excel creates a hyperlink is defined by the path used to open that Workbook. See Description of workbook link management and storage in Excel - Microsoft Support

Given the above and my testing the suggested workaround is to map as a drive the save location for Office Apps (for redirected user folders this is often already done) and apply that as the DefaultPath in the registry for Outlook. Then do the same via the GUI inside Word and Excel etcetera using File > Options > Save and ticking "Save to Computer by Default" and placing the mapped drive in the "Default Local File Location" box.

Nick,

The previous iteration of this issue started in Version 2206 and was later fixed in CC Version 2211 and backported to SAC 2208. Here is the forum thread for that issue for reference, Outlook New Experience update - network save location bug - Microsoft Community. I recall at the time I could repro that issue easily.

I have not reproduced this new variant yet. The investigation for the new issue they are reproducing with the DefaultPath=\\server\dfs\User\Personal\foldername\foldername\Documents. This path is a DFS share.

I just tested with a local machine UNC path and it did not repro for me. The first time I saved it took a few seconds and I saw the "Trying to connect" dialog. That was at most three to five seconds. After that first save then all future saves were very fast.

If you test with a local share do you still see the issue?

Hi Gabriel,

we don't use DFS here, single server running 2012 R2 (yes I know, its on my list of "have to be upgraded before October")

When you say "a local share" what do you mean exactly please?

Do you mean I share a folder on my own PC and then set the DefaultPath variable to point to the UNC path to the share?

Hi Gabriel,

update on the workaround of using a mapped drive as a default save location.

It has worked fine for the main account in outlook for most of today, however if I access other email accounts i.e. shared mailboxes, the bug returns seems to remain active the first one or two times you attempt to save and later attempts do not activate the bug.

Not sure what that is about at all but I have tried three shared mailboxes I have access to and the behaviour seems consistent.

Is it possible that the Shared Mailbox "Save As" code does not read the DefaultPath registry key?

A strange behaviour occurs after you have accessed a shared mailbox from within Outlook and triggered the bug again. If you have attempted to save at least twice so the bug goes away for that email in that mailbox, when you return to the main mailbox you have the bug again for the next save or two.

Is Outlook Desktop caching a network connection and attempting to reuse it?

I then decided to test the Local UNC Path you suggested.

Closed Outlook.

Created a folder in the root of my C: Drive then shared it with everyone.

Copied the UNC path for this folder to my DefaultPath registry key.

Exited RegEdit then opened Outlook.

Saved an attachment from my main Outlook account, trying to connect box flashed up, almost too quick to see, and was replaced by the normal Save As Window.

Hope this helps

Cheers

Nick

Nick,

I checked with the engineers working to submit the bug and they say it does not require DFS to cause the issue. A UNC share will cause it to repro. I have not had much time to test with it further.

Thanks for confirming Gabriel