我想得到一些有关您用于发布网络共享的最佳实践的反馈。
现在，我们的文件服务器上有：
- 为每个用户指定一个目录，每天备份
- 每个服务一个命名目录，每天备份
为了轻松发布这些共享，我们使用一个在 Windows 会话打开时运行的脚本，该脚本将一个字母映射到该共享，如下所示：
Net use * /delete /yes
NET USE P: \\SRVFILES01\MyName /PERSISTENT:NO
NET USE S: \\SRVFILES01\MyService /PERSISTENT:NO
这样做的问题是：
- 我们的笔记本电脑用户无需连接网络即可登录，因此当他们连接到网络时，他们就没有网络共享
- 如果服务器出现故障，我们的用户需要重新打开他们的 Windows 会话以获取他们的网络共享
你们在组织中是如何管理这个问题的？不要犹豫，分享你们的技术解决方案和组织方式吧！
非常感谢，
答案1
我们采用了多种方法。
应用程序存储：与 Safado 一样，我们使用 AD 组策略来映射驱动器，尽管我们通常仅将其用于特定应用程序存储。如果用户是 AD 中特定安全组的成员，则组策略适用并映射驱动器。安全过滤用于确保特定组策略仅适用于某个安全组的成员，即使组策略本身在域级别链接。这就是我们如何绕过 OU 结构的限制，而不一定与谁需要映射驱动器相匹配。当然，相应的自主访问控制列表 (DACL)用于共享本身，以确保只有组内的成员才具有访问权限。
用户文件：在 DC 上创建一个共享，并向所有经过身份验证的用户授予对该共享的只读访问权限。在共享中创建一个文件夹，其名称与每个人的用户名相同，并且用户的帐户是唯一被授予该文件夹访问权限（读取、写入、执行）的帐户。 基于访问的枚举已为共享启用，因此其他用户无法查看其他用户的文件夹，无论是否被允许读取主共享文件夹。 AD 中的用户配置文件部分包含允许单个映射驱动器的设置，我们仅将其用于用户文件。 %username% 宏可用于这些框，并且正如宏所暗示的那样，它在登录时被替换为实际用户名，从而产生一个包含特定于该用户的内容的映射驱动器。
容错性：如果映射驱动器需要更容错，并处理一个（或多个）DC 的丢失或断开连接，则可以使用 DFSR（分布式文件系统复制）。例如，可以在三个 DC 上创建 DFS 命名空间，并且可以在组策略或 AD 用户配置文件中使用 DFS 命名空间 UNC 路径。这将导致即使 DC 发生故障也可以访问文件的设置，此外，如果您在其他地理位置拥有属于 DFS 命名空间的 DC，则系统可以充当 CDN。
就像 Safado 所说的那样，如果无法连接，共享将显示一个红色的 X，只要在服务器上线后双击共享即可允许访问。
注意：由于声誉低于 10，我无法发布 DFSR 的 MS 页面链接 :-(
编辑：将大量 GPO 对象链接到域级别的顶部并不是一个好主意。经过深思熟虑的 OU 结构可能允许您将驱动器映射 GPO 对象链接到仅包含需要安装共享的用户的 OU。在这种情况下，无需使用安全过滤的细微差别，因为您的 OU 的继承结构已经处理了这一点。当然情况并非总是如此……例如，在处理管理不善的客户端 AD 域时 :P。
答案2
我们使用 GPO（用户 > 首选项 > Windows 设置 > 驱动器映射）来映射用户个人共享和部门共享的驱动器。我们将其标记为重新启动后重新连接，因此即使他们在断网时启动计算机，共享仍会列出，但会显示红色 X。然后当他们重新连接到网络时，只需单击共享即可重新连接。
答案3
几年前我遇到过同样的问题：一旦笔记本电脑与网络断开连接，挂载的共享就不可用。
当我在用户桌面上创建指向 \\myserver\myshare 的快捷方式时，用户非常高兴。操作系统宣布共享无法访问的速度也快得多（尽管我没有数据支持这一点）。因此，解决方案是在桌面上创建快捷方式通过 GPO例如。
如果您想保留已挂载的共享，对于笔记本电脑用户，您可能还会修改登录脚本以检查服务器是否可访问，在这种情况下请不要挂载它。
至于服务器宕机的情况，本来就不应该发生，尤其是当用户需要共享时。如果您可以规划服务器维护并总体上保持高可用性，则第二种情况不会对最终用户造成太大影响，因此不再是问题。