I'm turning here as a last resort for this issue, I just started an IT job and this was the first support ticket I got and I'm already burnt out trying to solve it over the last two days.
Basically the situation is we have two computers connected on the network. One computer is sharing a folder containing Excel files, and it is mapped to both computers (including the host on (S:) as "\10.0.0.200\Shared."
This was working well for years until last week when suddenly the users are complaining that their is now a delay when saving their Excel documents. A message will appear for around 3-4 seconds saying "trying to connect to \10.0.0.200\Shared" before disappearing.
Using the OSI model I've ruled out the network layer being an issue since the ping speeds between the two computers are less then <1ms, and copying a 1GB file takes only a few seconds, so the issue must be at the application layer. There have been no recorded windows updates for the last month, and I've tried disabling all AV Security, and disabling protected mode in Excel (and adding network locations to trusted list).
The host computer has no issues saving to a local file path (such as C:), but when I try to save to a UNC path (10.0.0.200) there is a delay, even though it's on the same disk.
I'm tearing my hair out over this since it seems to be defying the laws of causation. I've tried reasoning with the users to maybe just accept the 3-4 second delay, but they are complaining that it's interfering with their work. If I can't get it resolved I'll probably throw the towel in and leave IT for something else.
答案1
This just started happening to our users too. We are on Office365 (which I believe auto-updates itself) so I assume it is a recent change to Excel. We use folder redirection for the documents and desktop folders. If I use the F12 (shortcut for Save As), the Windows Explorer Save As dialog opens immediately with no delay, however, if we use the built-in Excel save dialog through the ribbon then we get this issue. Not aware of it happening in other office apps but we primarily use Excel here so just might not have come across it yet. Our folder redirection points to a UNC path, similar to \\server\share and not via a mapped drive. Found no fix yet other than to tell our users to initiate a 'Save As' operation via the F12 shortcut.
Our configuration for the shared folder is as follows:
\\server\share\userfolder
Users have full control over the \\server\share share permission
Users have ability to see folders underneath \\server\share
Users have full control over their \\server\share\userfolder folder
For what it is worth, we use DFS so our actual path is:\\domainname\dfsnamespace\redirection\userfolder
and the file servers that underlie the DFS share are 3 servers in a file server cluster.
I have seen this behavior on Excel version: (Version 2206 Build 16.0.15330.20246) 64-bit and (Version 2206 Build 16.0.15330.20144) 32-bit so far.
Given the reports all coming in right now, certainly seems like a newly introduced bug into Office. Everything else on the computer is operating normally. No DNS issues, no connection/speed issues. Save As via the windows dialog is instant. No other apps are having any issues.
答案2
So I'm just posting an update to provide some closure to this original question. I basically lost my job over this issue, mainly due to the way I handled it with the client.
Because I didn't know what the issue was, I just started taking shots in the dark, making changes that I had hoped would eventually solve the issue. The first day I tried disabling this thing called SMB, and it didn't seem to affect the file shares, so I went home, but apparently the next day the file shares stopped working (I wasn't in that day), so the support team had to spend some time working out what I did that broke the file shares. They found that when I disabled SMB it stopped the file shares working, so they reenabled it, basically that got me my first warning because I didn't log the changes I made.
My second attempt to resolve this issue was to reset the file share permissions. I did this and tested the mapped drives immediately after making this change, and the file access was okay. But apparantly the next day, the client complained that no-one could access the file shares, so somebody had to jump on and fix the issue.
Someone else took over this ticket, and I was let go. From what I heard before I left, the guy that took over just migrated their files to sharepoint, which bypassed the problem. I think this was cheating a bit, as he didn't even try to attempt to resolve the original issue with server file hosting. Anyway, just thought I'd add this for closure on the issue. I wonder if anyone elses career has been killed over stupid bugs like this
答案3
Same issue No fix yet.
But if you map the paths as mapped drives, they appear to work fine via mapped drives, not ideal if you have thousands of users.