我为一所有近千名用户（教职员工）的大学工作。 许多工作人员也兼职教授，许多教员在不同的部门任教。
由于知道用户和/或计算机只能存在于一个单一的OU中，哪一种策略会允许有一个很好的层次结构，并且仍然足够灵活以允许不同的部门组策略应用于相同的用户。
这不能太罕见的情况下，但我只是没有看到最简单或最干净的布局。
没有一些你正在寻找的具体情况的解释，很难给你任何“一步一步”。
用户组策略应用程序受以下影响：
这些都是控制用户组策略应用程序的机制。 在所有这些function之间，您可以创build相当复杂的部署scheme。
应始终根据计划的控制委派来devise您的OU层次结构。 您只能获得一个OU层次结构，并且没有好的机制来从OU层次结构中分离控制委派。 首先devise控制权，组策略申请第二。
我专注于使用安全组成员来过滤用户组策略应用程序。 不要忘记，GPO中的某些设置具有与GPO本身分开的ACL。 应该谨慎使用“块inheritance”和“强制执行”/“无覆盖”function，并且通常指示破碎的devise。 环回组策略处理可以是一个非常强大和有用的工具，但是它的理解有点复杂。
你关注的是用户，但是我也会花一点时间提一下电脑。 计算机组策略应用程序具有与用户组策略相同的过滤function，但也包括WMI筛选。 WMI筛选可以让您将GPO定位到计算机的特定硬件或与操作系统相关的属性。 过滤计算机组策略时，经常会看到忽略安全组过滤。
对于计算机组策略，可以使用WMI筛选和安全组筛选来完成一些操作。 WMI筛选具有在每个组策略应用程序上dynamic计算的附加function（相对于安全组成员身份，必须手动更改以影响筛选）。 如果计算机位于不同的OU中，而没有需要应用公共组策略对象的WMI可过滤属性，则安全组筛选仍可能是有益的。 我经常使用计算机安全组过滤来控制软件安装策略（其中我有一个分配了多个软件包的GPO，每个都有一个包含一组控制软件安装的唯一ACL）。
你可以做的最重要的事情就是保留上面所说的一切，确保你完全理解组策略客户端如何计算策略的结果集，并且用这些知识在投入生产之前集思广益并testing可能的devise。 我坚信testing应该从笔和纸（白板等）开始，而不是软件。 你需要有足够的组织知识才能devise出真实的场景并进行testing。 参与其他组织（如果需要的话，在IT组织之外）。 例如，您的服务台团队将具有控制需求的委派，这将驱动物理OU层次结构。 您的桌面支持团队可能具有推动计算机组策略过滤的软件安装需求。 有许多可能的情况需要通过讨论，在纸上制定出来，最后在实验室情况下进行testing，然后投入生产。