我们有一个脚本，每晚在我们的Win2K SP4服务器上运行。 （我知道，我们需要升级服务器的操作系统，我们计划尽快这样做。）
有时，当人们将共享文件夹从桌面上打开时，脚本失败了。
所以我们使用net files和net file NNNN /close批处理命令来查找和closures它们。 这已经为我们工作。
不过截至上周，一些文件夹从Windows 7桌面打开。 像往常一样脚本“closures”它们，日志显示The command completed successfully. 为每一个。 但是这些文件夹显然还是打开的：脚本以后对这些文件夹的操作失败了。
当我login到Win2K服务器并使用计算机pipe理>共享文件夹>打开文件/右键单击>closures手动closures打开的文件夹时，这一点已被确认。 当我这样做的时候，打开的文件夹首先从列表中消失，但是当我刷新列表时，这些文件夹又回来了。
值得注意的是， 在Windows 7的资源pipe理器中打开的文件夹会发生这种情况 ，例如， 在Windows XP上打开的文件夹不会 。 如果共享文件夹在XP的Windows资源pipe理器中打开，并且从服务器端closures该文件夹，它将保持closures状态。 在某些其他应用程序中打开的文件也不会发生此问题; 例如，如果我在Notepad ++中打开了一个文件，并在服务器上closures它，它将保持closures状态。
在服务器端，我已经在Win2003 Server和Win2008 Server Standard SP2中testing了这个现象。 结果是一样的：当你从服务器端closures一个打开的共享文件夹时，它会立即重新出现（或者在Win2008中永远不会消失）。 但是，只有从Windows 7打开才可以; 不从例如Win2003服务器。
所以我不知道最近是否有一些Windows 7更新导致Explorer立即重新打开已被服务器closures的文件夹？
如果是这样，我可以从服务器端做些什么，以保持这些文件夹closures，直到我们的脚本完成运行？
感谢您的任何帮助或build议。
我不知道如果我喜欢这个build议，但我会反正。 那么使用“净停止服务器”，然后一旦过程完成“networking启动服务器”呢？ 由于共享服务将处于脱机状态，因此客户端工作站上的任何尝试都不应允许它重新连接。 我不知道你的企业会有什么其他副作用。 打印机和其他Windows服务也将脱机，所以只是预先警告。