任何处理过文件服务器权限的人都知道，NTFS 有一个有趣的设计特性/缺陷，称为移动/复制问题。
正如这篇 MS KB 文章中所述，如果文件夹或文件被移动并且源和目标位于同一个 NTFS 卷上，则该文件夹或文件的权限不会自动从父级继承。如果文件夹被复制或者源和目标位于不同的卷上，则权限将被继承。
这是一个快速示例：
您在同一个 NTFS 卷上有两个共享文件夹，名为“Technicians”和“Managers”。Technicians 组对 Technicians 文件夹具有 RW 访问权限，Managers 组对“Managers”文件夹具有 RW 访问权限。如果有人对两者都具有访问权限，并且他们将子文件夹从“Managers”文件夹移动到“Technicians”文件夹，则移动的文件夹仍然只能由“Managers”组中的用户访问。“技术人员”组无法访问子文件夹，即使它位于“技术人员”文件夹下并且应该从顶部继承权限。
可以想象，这会导致解决这些最终用户问题的支持电话、票证和浪费的周期，更不用说如果用户经常在不同的安全文件夹/区域之间移动文件夹，您最终可能会遇到的大量权限。相同的音量。
问题是：
解决此 NTFS 设计缺陷的最佳方法是什么，您如何在您的环境中处理它？
我知道链接的 KB 文章谈到了一些注册表项来更改 Windows 资源管理器的默认行为，但它们是客户端，并且要求用户能够更改权限，我认为在大多数环境中，如果您想要控制您的文件服务器权限（以及您作为系统管理员的理智）。
我发现大多数用户都忽略了 WSUS 推送的“有更新准备安装，单击此处进行安装”消息。到目前为止，我们还没有强制安装，但我正在考虑更改组策略以每晚强制更新。这有时需要重新启动，我也想通过 GP 强制执行。
我知道用户会反对，但我想知道这是否是可防御的最佳实践。这似乎是确保 PC 保持最新和安全的正确做法。
文件服务器是 IT 中的一个事实，我很好奇是否有任何普遍接受的做法（我在这里犹豫使用“最佳”一词）来说明如何创建组并应用权限来管理客户端对共享文件夹的访问文件服务器。
在我目前的工作中，我最终继承了很多不同的方法，从 ACL 上的数十个组到将单个用户直接放在文件系统上。我的任务是清理混乱，并在整个公司（大型环境、150k 人员、90k 客户端计算机、100 台文件服务器）中提出某种标准化方法来解决这个问题。
根据我对这个问题的理解，似乎每个受保护资源的每个所需访问级别至少需要一个组。这种模型似乎提供了最大的灵活性，因为除非您需要支持不同的访问级别，否则您不需要再次触及文件系统权限。缺点是与跨多个共享资源重复使用同一组相比，您将创建更多组。
这是一个示例，显示了我的意思：
在名为 FILE01 的文件服务器上有一个名为“测试结果”的共享，有些人需要只读访问、读写访问和完全控制。1 个安全资源 * 3 个访问级别 = 3 个安全组。在我们的 AD 环境中，我们将这些创建为通用组，以便我们可以轻松地从林中的任何域添加用户/组。由于每个组唯一地引用一个共享文件夹和访问级别，组名称包含这些“关键”数据，因此权限如下：
"FILE01-Test Results-FC" -- Full Control
"FILE01-Test Results-RW" -- Read & Write
"FILE01-Test Results-RO" -- Read Only
通常，我们还会包括内置 SYSTEM 帐户和具有完全控制访问权限的内置管理员。现在可以使用组成员身份来处理对谁实际获得此共享访问权限的任何更改，而不必接触 ACL（通过添加代表特定业务角色的“角色”组，例如经理、技术员、QA 分析师等，或仅添加个人一次性访问用户）。
两个问题：
1）这实际上是处理权限的推荐或有效方法，还是我错过了一些更简单、更优雅的解决方案？我对任何使用继承但仍然保持灵活性的解决方案特别感兴趣，因为当事情发生变化时不必重新 ACL 大部分文件系统。
2) 您如何处理环境中的文件服务器权限和组结构？那些也在大型环境中工作的人的奖励积分。