Windows共享:指定的networking名称不再可用

我们有一个EMC NX4 SAN盒子,可以将CIFS共享分配给多个Windows Server 2008 R2应用服务器。 应用程序服务器使用CIFS共享来提供大量图像文件(共享上约2500 ops / sec),但是SAN和应用程序服务器都没有显示任何明显的压力迹象。

偶尔一个应用程序服务器会突然间断开与SAN的连接。 试图从SAN提供文件的任何.NET代码将失败:

System.IO.IOException: The specified network name is no longer available 

如果我将RDP添加到应用程序服务器,并尝试通过资源pipe理器访问“\ san-name”,则会得到相同的错误。 所有其他应用程序服务器可以访问它就好了。 我也可以完美地访问“\ ip-of-san”,ping也可以。

应用程序服务器的重新启动修复了这个问题,但是这对于这个问题来说是一个很激烈的措施,因为看起来SAN似乎工作正常,计算机可以访问它 – 它看起来像“\ san-name”访问barfed了。

这在上周发生在两个不同的应用程序服务器上,所以我不怀疑是一个单一的应用程序服务器的原因。 现在忽略原因 – 如何在不重新启动计算机的情况下恢复“\ san-name”连接? 我能不知何故查询出了什么问题?

事件日志没有显示任何东西(除了相关的ASP.NET错误),无论是在应用程序服务器还是在SAN上。

更新:
根据这些build议,我会在下次尝试重新启动Workstation服务,看看是否有助于解决问题。 绝对不是一个修复,但更快的方式比重新启动整个机器,因为我目前一直在做。 任何方式来查询工作站服务维护的连接的状态?

更新2:
确认重新启动工作站服务“修复”问题。 下一步是尝试注册更改以提高MaxCmds值。 将无法确认是否是这个问题,只能假设,如果它运行了一个漫长的时期没有问题。

这听起来像MaxCmds已经用完了。 这里有两篇很好的文章: 这里和这里 。

现在来改变它。 创build一个名为update.reg的文件,并在其中放置以下内容:

 Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\lanmanworkstation\parameters] "MaxCmds"=dword:00000800 

保存,然后双击并接受提示。 需要重新启动。

也许重新启动应用服务器上的工作站服务!

我曾经遇到过这样的情况,虽然没有EMC后端。 对于用户级应用程序,强制closures与远程服务器的连接并重新打开将会使其恢复,尽pipe您可能需要尝试几次才能使其一起工作。 对于serverland应用程序,为该服务回收应用程序池是可行的。 如果失败,回收工作站服务可以避免重新启动,但几乎同样激烈。

来源:

你能否提供关于安装在应用程序服务器上的软件的更多细节? 在networking上,你会发现它通常是一个AV的问题,但既然你不运行任何…也许是另一种内核模式的应用程序,如备份软件?

防火墙是否激活? 你有没有检查故障的应用程序服务器在DC上的事件日志?

出现问题时,您还应该嗅探CIFSnetworkingstream量,看看会发生什么情况。

我遇到这个错误的唯一的时候是服务器/工作站以某种方式“丢失”与域的链接。 重新强制域成员做了窍门(netdom / resetpwd)。 出现问题时,您可以访问其他networking共享(从RDP会话到应用程序服务器)吗?

这可能是与名称parsing问题。 你可以检查你的DNS服务器? 如果这不允许解决名称,并重新启动您的应用程序服务器,它将允许访问。

我有同样的问题,当一些工作站用户抱怨,他们无法访问应用程序存储在另一台服务器,我们已经做了相同的尝试访问与服务器IP将工作,但没有名称,所以我们已经检查了DNS。 我们已经改变了应用程序访问另一台服务器使用IP地址,因为我们有静态IPnetworking。

让我知道,如果我的build议适合你。

我遇到了类似的问题。 我没有能够从Windows 2003服务器映射共享到Windows Server 2012。

networking组实施了一个AD策略,将较低的Windows版本隔离到AD容器,而AD容器不允许较低版本的TLS连接到运行更高版本的TLS的服务器。 移回服务器或禁用与较低版本的TLS连接的策略已更正此问题。

以下是我在系统日志中遇到的一些错误:

从远程服务器接收到的证书由不受信任的证书颁发机构颁发。 正因为如此,证书中包含的数据都不能被validation。 SSL连接请求失败。 附加的数据包含服务器证书。

致命的警报已生成并发送到远程端点。 这可能会导致连接终止。 TLS协议定义的致命错误代码是48. Windows SChannel错误状态是552。

希望它有助于解决您的问题。