Мы наблюдали действительно странную ошибку за последнюю неделю или около того, что заставило нас просто дергать себя за волосы.
Мы запускаем довольно загруженный Microsoft BizTalk Server на трех серверах в кластере и используем общий файловый ресурс (корпоративный NAS с точкой монтирования, к которой мы обращаемся) для чтения и записи файлов.
Мы определяем это так:
\наш_файлообменник\файлы
который является псевдонимом CNAME в AD
И NAS существует как NAS01, поэтому мы можем получить к нему доступ так же, как:
\NAS01\файлы
Однако с прошлой недели вдруг один из серверов перестал иметь доступ к \our_fileshare\files
Ошибка может возникать на всех серверах или только на одном из них или в комбинации между ними, и она не будет возникать одновременно на всех трех серверах, но если ее оставить без присмотра, произойдет на всех трех, что затем просто произойдет. заблокировать весь трафик.
Он выдает ошибку в BizTalk, которая говорит "Не удалось сохранить файл на диск!", файловый менеджер говорит "Не удалось подключиться к \our_fileshare\files" и если мы попробуем это из командной строки или из Windows + R, он укажет "Недостаточно системных ресурсов для выполнения запрошенной службы", та же ошибка возникает, если мы запускаем любое из наших собственных разработанных приложений .NET.
Однако странно то, что если \our_fileshare\files выдает нам эту ошибку, мы можем на том же сервере получить доступ к общему ресурсу с помощью \NAS01\files.
Итак, мы подумали, что это может быть проблема с DNS, и пока ребята из DNS изучали ее, мы изменили ее в BizTalk, чтобы вместо этого начать использовать \NAS01\files. Итак, мы сделали это сегодня, и вот проблема возникла СНОВА. Те же ошибки.
Итак, теперь \NAS01\files не будет работать, НО \our_fileshare\files работает нормально, И мы обнаружили, что \NAS01.ourdomain.local\files также работает нормально.
У кого-нибудь есть ЛЮБЫЕ подсказки относительно того, куда мы можем обратиться, чтобы найти основную причину этой проблемы? Единственным текущим решением, как мы видим, является ЛИБО перезагрузка рассматриваемого Windows Server ИЛИ перезапуск службы «Рабочая станция» в службах Windows.
Я пробовал гуглить ошибку и читать бесконечные документы MS и различные вопросы и ответы здесь и в других местах, но я не могу найти ничего, что сработает. Я видел какой-то вопрос, который идеально соответствовал этому, относительно поврежденного кеша автономных файлов, но CSC настроен на запуск «Отключено» на наших серверах, так что и здесь не повезло.
Мы используем Windows Server 2019.
