我有一个难得的机会，从零开始设立一个中型公司（约250人）的第一个家庭和部门共享服务器，并希望做出合理的事情。
我们将使用Windows 2012系统（我们有一个现有的数据证书许可证）。 我们也有一个很好的AD设置。
在我看来，将不同的共享放在不同的SAN LUN上并将它们映射为数据存储（最终是主机驱动器），并将其映射为不同的工作负载是个不错的主意。 我需要处理用户主文件夹，公司范围内的“临时”驱动器，用户特定的“pst导出”驱动器以及某种部门间共享存储器。 我不确定是否应该创build多个访客（例如家庭股份的FS1和部门的FS2）。
在我看来，我应该build立一些PowerShell脚本来创build用户文件夹和build立ntfs权限，然后一些组策略规则来实际映射驱动器。
这是一个合理的方法，还是应该考虑一些不同的东西？
对不同的份额使用不同的LUN确实看起来像是矫枉过正。 我可以肯定地告诉你，我从来没有见过这样做。 他们都将有一个随机访问模式，所以工作量将几乎相同。 将它们放在单独的LUN上可能会使重新configuration无线存储更加困难。 我不认为你会看到这些股票使用不同的LUN的好处。 （我绝对不认为你会看到使用单独的操作系统实例/客人，任何好处）。
重新：用户文件夹
您应该仔细阅读“ 文件夹redirect” ，以便将用户的内容放到服务器计算机上。 它基于组策略，非常易于pipe理和configuration。 唯一不利的，就像我看到的那样，用户必须等待策略应用后第一次login，而所有的内容都被拷贝到服务器上。
不同的人对文件夹redirect的权限有不同的意见。 有些人在Windows中使用股票function，允许自动创build文件夹。 我认为这是一个潜在的DoS攻击，并且倾向于使用configuration脚本预先创build文件夹。
最近我一直在使用文件夹redirect文件夹结构，如下所示：
用户只被授予“<username>”文件夹的权限。 在这种情况下计算用户的磁盘空间利用率是相当容易的。 （我也将用户的漫游用户configuration文件存储在“Profile”/“Profile.V2”文件夹中）。
（是的，我喜欢 AppData文件夹redirect，有些人不同意，但我从中得到了很好的结果，而且这些好处大于我的“成本”。）
我在另一个服务器故障答案和另一个服务器故障答案中提供 了一些更多的细节 。 为了保持呼吸，我不会在这里重复这一切。
重新：部门文件夹
这是我认为你有最大的机会来“正确”或“错误”的地方。 我经常不得不面对那些退化成我所谓的“一堆文件”的公司的“公共驱动力”。 这是一个巨大的混乱，往往是零散的和思想不深的权限，几乎不可能得到控制。
我会花时间思考最好的方法来devise权限和文件夹结构来获得这个部分的权利。 我在另一个答案中提到了这个问题 ，所以在这里我也不会重复。