Dub*_*ese 4 group-policy shares
我有难得的机会在一家中型公司（大约 250 人）中从头开始设置我们的第一个家庭和部门共享服务器，并希望做出一些合理的事情。
我们将使用 Windows 2012 系统（我们有一个现有的数据中心许可证）。我们也有一个很好的 AD 设置。
在我看来，将不同的共享放在不同的 SAN LUN 上并将它们映射为具有不同工作负载的数据存储（最终是主机驱动器）是个好主意。我需要处理用户主文件夹、公司范围的“临时”驱动器、特定于用户的“pst 导出”驱动器和某种跨部门共享存储。我不确定是否应该创建多个来宾（例如家庭共享的 FS1 和部门共享的 FS2）。
在我看来，我应该构建某种 powershell 脚本来创建用户文件夹并建立 ntfs 权限，然后是一些组策略规则来实际映射驱动器。
这是一种合理的方法，还是我应该考虑一些不同的方法？
为不同的共享使用不同的 LUN 看起来真的有点矫枉过正。我可以肯定地告诉你，我从未见过这样做过。它们都将采用随机访问模式，因此工作负载将非常接近相同。将它们放在单独的 LUN 上可能会使在不停机的情况下重新配置存储变得更加困难。我认为对这些共享使用不同的 LUN 不会有任何好处。（我绝对不认为你会看到使用单独的操作系统实例/来宾的任何好处。）
回复：用户文件夹
您绝对应该阅读文件夹重定向作为将用户内容传送到服务器计算机的一种方式。它基于组策略，非常易于管理和配置。在我看来，唯一的负面影响是用户在策略应用后首次登录时必须等待，同时他们的所有内容都复制到服务器计算机上。
不同的人对文件夹重定向的权限有不同的看法。有些人使用 Windows 中的库存功能，允许自动创建文件夹。我认为这是一种潜在的 DoS 攻击，并且更喜欢使用配置脚本预先创建文件夹。
最近我一直在使用文件夹重定向文件夹结构，如下所示：
用户仅被授予对“<username>”文件夹的权限。在这种情况下确定用户的磁盘空间利用率非常容易。（我还将用户的漫游用户配置文件存储在此处的“配置文件”/“配置文件.V2”文件夹中。）
（是的，是的——我喜欢AppData 文件夹重定向。有些人不同意这一点，但我从中得到了很好的结果，而且好处超过了我的“成本”。）
我武断大约在另一个服务器故障的回答一些细节和尚未另一个服务器故障的答案。为了省心，我不会在这里重复所有这些。
回复：部门文件夹
这是我认为你有最大的机会“做对”或“做错”的地方。我经常不得不处理公司中的“公共驱动器”，这些驱动器已退化为我所说的“文件堆”。这是一个巨大的混乱，通常具有不完整且经过深思熟虑的权限，并且几乎不可能得到控制。
我会花时间思考设计权限和文件夹结构的最佳方法，以使这部分正确。我在另一个答案中对此进行了夸大其词，所以我也不会在这里重述。