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