Trying to connect message when Saving in Excel 365

Hello

We have the same issue in Excel with "Save As" using a DFS virtual path.

While the message is displayed, we can observe the computer trying to connect to each Domain Controller of our domain oh HTTP port 80 !!!!

Fortunately it fails with SYN_SENT TCP messages.

C:\Users\PBALVERDE>netstat -an 1 | findstr SYN

  TCP    xxxx:57610      yyyyy:80         SYN_SENT

  TCP    xxxx:57610      yyyyy:80         SYN_SENT

  TCP    xxxx:57610      yyyyy:80         SYN_SENT

.....

  TCP    xxxx:57610      zzzz:80         SYN_SENT

  TCP    xxxx:57610      zzzz:80         SYN_SENT

  TCP    xxxx:57610      zzzz:80         SYN_SENT

....

(whe yyyyy and zzzz are two DCs)

If this info could help the community to resolve the issue...

Best regards.

WM.

Are your DCs also hosts of DFS then? That would explain this behavior.

From what I have discovered the problem is that instead of using the provided path as a UNC path (over SMB), it is first contacted using webdav (which is the port 80 request). When the server doesn't respond to port 80, it will eventually time out which is why the message box is displayed on screen that it is trying to connect. As soon as Outlook/Excel stops the connection attempts over webdav, it tries to connect using port 445 and as DFS/File servers accept these connections, you will be prompted with the window asking you where to save.
I already posted my findings on a different forum so I won't repeat them here.
The TL;DR version is that if you want another workaround for this (at least one that worked for me) is that you can set an outbound block rule for port 80 on the client to the server(s) hosting the fileshare. Only an outbound block worked for me, creating an inbound block on the server-side did not work.

Hope that helps anyone

We have this issue in Excel and Outlook and I am on Version 2208 (Build 15601.20064 Click-to-Run). We are using Folder Redirection using UNC path. We are not using DFS. The F12 trick works for Save-As in Excel, however this is not practical for our users and does not help for Outlook.

TLDR

• Issue was present for us on 2207 (Build 15427.20194).
• Issue is still present for us on 2207 (Build 15427.20210).

BEHAVIOR

We have been fighting with the "Trying to connect to" issue for a few weeks.

End users are quite frustrated.

Can navigate to a file share and open an Excel document fine.

Can confirm it occurs when initially trying to Save As or Browse to a network share through Excel.

If I wait and let it figure itself out and connect, which takes anywhere from 15-60 seconds (roughly), I can do another Save As right away without issue (no pop up). But if I let it sit for awhile (exact time unknown) or open the file again later in the day - it will go through the "Trying to connect to" process all over again.

We have DFS + Redirected Desktop and Documents folders.

Concerned about the long-term effects of disabling WebClient service but will give it a test today.

For those that have implemented this workaround - have you run into any issues?

VERSIONS

Issue was present for us on 2207 (Build 15427.20194).

Updated to 15427.20210 on a few machines yesterday.

Seemed better at first but the "Trying to connect to" message cropped up again today.

Might be my imagination but the "Trying to connect to" message seems to clear quicker on 2207.

Issue is still present for us on 2207 (Build 15427.20210).

The issue is present in the latest Enterprise Monthly Channel, Version 2206 (Build 15330.20298).

We saw the same issue with the Current Channel, Version 2206 (Build 15330.20230). The issue occurs even when saving a new blank Excel document after selecting File, Save, Browse. The save location in our case is a redirected My Documents folder using a UNC Path. We tested against a Windows 2012 and Windows 2019 file server before reverting to an older Office version that did not have this issue.