Документы Excel медленно сохраняются в UNC-путь.

Я обращаюсь сюда как к последнему средству по этой проблеме, я только что начал работать в ИТ, и это был первый запрос в службу поддержки, который я получил, и я уже выгорел, пытаясь решить его в течение последних двух дней.

Ситуация заключается в том, что у нас есть два компьютера, подключенных к сети. Один компьютер делится папкой, содержащей файлы Excel, и она смонтирована на обоих компьютерах (включая хост на (S:) как “\10.0.0.200\Shared”).

Это работало хорошо в течение многих лет, пока на прошлой неделе пользователи вдруг начали жаловаться, что теперь существует задержка при сохранении их документов Excel. Появляется сообщение на около 3-4 секунд с текстом “пытается подключиться к \10.0.0.200\Shared”, прежде чем исчезнуть.

Используя модель OSI, я исключил проблему на уровне сети, поскольку скорость пинга между двумя компьютерами менее <1мс, а копирование файла размером 1 ГБ занимает всего несколько секунд, поэтому проблема должна быть на уровне приложения. За последний месяц не было зарегистрированных обновлений Windows, и я пытался отключить всю антивирусную защиту и отключить режим защищенного просмотра в Excel (и добавить сетевые расположения в доверенный список).

Хост-компьютер не испытывает проблем с сохранением в локальный путь (такой как C:), но когда я пытаюсь сохранить в UNC-путь (10.0.0.200), возникает задержка, хотя это на одном диске.

Я рву на себе волосы, поскольку это кажется противоречащим законам причинности. Я пытался объяснить пользователям, чтобы они просто приняли задержку в 3-4 секунды, но они жалуются, что это мешает их работе. Если я не смогу решить эту проблему, я, вероятно, брошу это дело и уйду из ИТ в что-то другое.

Эта проблема только что начала возникать у наших пользователей тоже. Мы используем Office365 (который, как я понимаю, обновляется автоматически), поэтому я предполагаю, что это недавнее изменение в Excel. Мы используем перенаправление папок для документов и папок рабочего стола. Если я использую F12 (горячая клавиша для “Сохранить как”), диалоговое окно “Сохранить как” в проводнике Windows открывается мгновенно без задержки, однако, если мы используем встроенный диалог сохранения Excel через ленту, тогда возникает эта проблема. Не знаю, происходит ли это в других офисных приложениях, но мы в основном используем Excel, так что просто, возможно, не наткнулись на это еще. Наше перенаправление папок указывает на UNC-путь, аналогичный \\server\share и не через смонтированный диск. Пока не нашел решения, кроме как сказать нашим пользователям инициировать операцию ‘Сохранить как’ через горячую клавишу F12.

Наша конфигурация для общей папки следующая:
\\server\share\userfolder
Пользователи имеют полный контроль над разрешениями на общий доступ \\server\share
Пользователи могут видеть папки под \\server\share
Пользователи имеют полный контроль над своей папкой \\server\share\userfolder

На всякий случай, мы используем DFS, поэтому наш фактический путь:
\\domainname\dfsnamespace\redirection\userfolder
и файловые серверы, которые лежат в основе DFS, составляют 3 сервера в кластере файловых серверов.

Я видел это поведение на версиях Excel: (Version 2206 Build 16.0.15330.20246) 64-bit и (Version 2206 Build 16.0.15330.20144) 32-bit на данный момент.

Судя по всем поступающим отчетам, это определенно похоже на недавно введенный баг в Office. Все остальное на компьютере работает нормально. Нет проблем с DNS, нет проблем с подключением/скоростью. Сохранение как через диалоговое окно Windows мгновенно. Другие приложения не испытывают никаких проблем.

Я просто публикую обновление, чтобы предоставить некоторую заключенность по этому изначальному вопросу. В основном я потерял свою работу из-за этой проблемы, главным образом из-за того, как я с ней справился с клиентом.

Поскольку я не знал, в чем проблема, я просто начал найти решение вслепую, внося изменения, которые, как я надеялся, в конечном итоге решат проблему. В первый день я попытался отключить что-то под названием SMB, и это, похоже, не повлияло на общий доступ к файлам, поэтому я ушел домой, но, похоже, на следующий день общий доступ к файлам перестал работать (я не был в тот день на работе), поэтому команде поддержки пришлось потратить некоторое время, чтобы выяснить, что я сделал, что нарушило общий доступ к файлам. Они выяснили, что когда я отключил SMB, это остановило работу общего доступа к файлам, так что они повторно включили его, и, по сути, это привело к моему первому предупреждению, потому что я не зафиксировал изменения, которые сделал.

Моя вторая попытка решить эту проблему заключалась в сбросе разрешений общего доступа к файлам. Я сделал это и протестировал смонтированные диски сразу после внесения этого изменения, и доступ к файлам был в порядке. Но, похоже, на следующий день клиент пожаловался, что никто не может получить доступ к общему доступу файлов, поэтому кто-то должен был вмешаться и исправить проблему.

Кто-то другой взял этот запрос, и меня уволили. Насколько я слышал до своего ухода, человек, который взял на себя, просто мигрировал их файлы в SharePoint, что обошло проблему. Я думаю, что это немного нечестно, так как он даже не пытался решить исходную проблему с хостингом файлов на сервере. В любом случае, просто хотел добавить это для завершения вопроса. Интересно, пострадала ли чья-то карьера из-за глупых багов вроде этого.

Такая же проблема
Решения пока нет.

Но если вы монтируете пути как смонтированные диски, они, похоже, работают нормально через смонтированные диски, что не является идеальным, если у вас есть тысячи пользователей.