如何在组策略中执行例外？

有没有更好的方法来完成我们正在努力完成的任务？

使用安全组过滤来免除各种计算机策略的计算机是有意义的，我认为你正在以正确的方式去做。

在“文件夹redirect”设置中，我不确定自己实际上正在完成的任务是否完全清除。 什么是最终的业务目标？ 这些特殊的文件夹redirect计算机configuration，使用户可以自由地在他们之间移动？ 如果在使用“文件夹redirect”之后使用“无法find文件”的计算机，那么预期的用户体验是什么？ 我不确定你是否完全想到这一点。

看起来好像你厌恶应用组策略到用户对象。 我很想知道原因。 仅当用户login到某些计算机时才应用“文件夹redirect”有点不合常规。 更一般地讲，组策略的环回处理并不是常态，但我承认我经常使用它。 在环回中进行潜水处理从学习的angular度来看，这是一个大胆的举动。

要特别谈论文件夹redirect，我通常会发现，文件夹redirect在组织中作为默认应用时效果最好。 与漫游用户configuration文件一起，它可以使客户端计算机在用户数据方面几乎“无状态”。 我通常希望几乎每个用户都能够访问几乎所有的计算机，login并访问其文件和用户设置。

这并不是说我没有计算机可以使用环回处理来“免除”文件夹redirect（并且我可能只强制本地configuration文件），但这些将是less数和exception，而不是默认设置。 （例如信息亭电脑和专用的单任务电脑。）

我也有我需要免除用户从文件夹redirect的情况下（承包商，面向任务的用户等），由于我几乎专门向用户应用文件夹redirect策略，这只是一个OU层次结构“没有文件夹redirect“用户所在的位置，或者安全组过滤来免除用户的文件夹redirect。

大多数组织是否将所有工作站都保存在一个单一的OU中（就像我们正在做的那样），还是将它们分开（就像我们已经实现的那样）？

在实践中，我已经看到了两者，但是我发现“让所有计算机都放在一个单一的OU中”很笨拙，通常会导致安全组成员过滤使用组策略应用程序。 我个人从来没有这样做过。 如果没有别的，我仍然会把客户端计算机分解成描述它们物理位置的OU，以便更容易find。

首先，您的OU层次结构应该被devise为委派Active Directory对象的pipe理控制权。 公司往往没有对客户端计算机对象的pipe理控制的描述。 请记住，我并不是在计算机上谈论“本地pipe理员权限”，而只是pipe理AD中计算机对象的pipe理控制权。

在满足您的授权控制需求之后，OU层次结构的第二个devise决策应与组策略的应用有关。 我希望尽可能使用OU来控制组策略的应用，因为它消除了对安全组过滤的需要（并且消除了忘记填充计算机的安全组成员的可能性）。 可能有一些GPO需要应用到OU分层结构中的“scattershot”计算机分布， 这是使用安全组过滤的最佳位置。

我们想要做什么types的例外甚至是有意义的？ 防火墙的工作正常，因为它们是计算机策略，但当我们想要将用户策略应用到login到这些PC的所有用户时，该系统就会崩溃。

根据您在这一主题的最后一句中的表述，您对Loopback Processing的理解似乎是正确的。 要清楚它：环回处理可以正常工作。 我几乎在所有的计算机上都在几个客户站点上广泛使用它。

你可以做什么/有select地应用文件夹redirect可以完成，但我会提醒的是，文件夹redirect不一定与从pipe理模板应用于用户registry的设置一样。 没有看到你的AD的所有细节，我很难说为什么你没有看到你期望的结果。 例如：如果用户configuration了漫游用户configuration文件并login到使用环回处理的计算机，以便将文件夹redirect应用于该用户的configuration文件，则文件夹redirect设置将“粘”到他们的configuration文件，甚至“跟随”没有通过回送处理应用文件夹redirect的计算机。

除了GPRESULT / RSOP以外，还有哪些工具可以解决这类问题？

当然，我发现这些工具很有用。 有时候，如果我觉得我在单个组策略客户端扩展（CSE）方面遇到问题，我可能会启用debugging输出（使用Windows 7中的RunDiagnosticLoggingGlobal设置或者Windows XP上的UserEnvDebugLevel或RunDiagnosticLoggingGlobal设置）。

主要是，我认为能够在您的脑海中概念化组策略应用程序是非常重要的。 我认为组策略pipe理控制台中的“build模”和规划function是支撑系统pipe理员的懒惰，他们懒得学习产品如何做出策略应用决策。

确定给定计算机或用户对象（我称之为“主题”）的组策略应用程序的algorithm如下：

• 从域顶部开始，查找任何链接的组策略对象。 不要担心安全组或WMI过滤 – 只需find域顶部链接的所有GPO即可。 按照链接顺序对它们进行标注，标题为“非强制GPO”。 如果您发现GPO链接到“强制”（或者，在过去的日子里，“不强制”）选项集，请将其添加到名为“强制GPO”的第二个列表的底部， 而不是“非强制GPO”列表。 始终按照在每个OU链接的顺序（链接的顺序）将这些GPO添加到列表中。

• 将OU层次向下移动到主题所在的OU。 在每个OU中，find任何链接的GPO，并将其添加到您的列表之一（“非强制GPO”或“强制GPO”），就像您在域顶部所做的一样。 如果您发现带有“块inheritance”选项的OU，则在将该OU链接的GPO添加到您的列表之前，请先清除“非强制”列表中的所有内容。 尽pipe如此，“块inheritance”不会影响“强制”列表。

• 当您向下移动OU时，可能会发现多次链接相同的GPO。 没关系。 将其添加到相应列表的底部，即使它已经在列表中。

以下是了解Loopback Processing背后的机制的重要地方。 所有正在启用的环回处理都会导致构build要应用的GPO列表的algorithm发生变化。

在“replace”模式中启用“环回处理”时，只需将待login计算机的OU看作是用户login的位置，然后相应地构buildGPO列表即可。 当它处于“合并”模式时，首先在用户自己的OU中为用户创build列表，然后再次从域顶部开始，添加到已经build好的列表中，添加在域顶部链接的GPO并沿层次结构中的每个OU向下移动到计算机对象。

在到达主题所在的OU之后，您所做的列表是可应用于该主题的GPO列表。 它们的应用顺序是“非强制GPO”列表的首位，然后是“强制GPO”列表，如下所述。

您可以使用以下过程从这些列表中计算策略的结果集：

• 与“非强制GPO”列表中的第一个GPO一起检查其权限和WMI过滤设置，以确定它是否可以应用于主题。 当您计算计算机的RSoP时，请考虑计算机的组成员身份以确定安全性筛选资格。 在为用户计算RSoP时考虑用户的组成员资格。 在环回处理模式下计算用户RSoP时， 只有用户的组成员身份适用于安全筛选器（即启用了环回处理后，用户login时计算机组成员身份对RSoP 没有任何影响）。

• 如果可以应用GPO，则基于安全组筛选和WMI筛选，在标题为“策略的结果集”的新列表中标注其应用的设置。 （很明显，如果您正在为计算机构buildRSoP，则只需查看GPO的计算机部分以进行设置，然后查看用户的用户部分。）

• 当您向下移动GPO列表时，如果较低的GPO更改了已经放置在您的“结果集策略”列表中的设置，请删除已经存在的设置，并将其replace为GPO中较低位置的设置名单。 这就是GPO如何相互“覆盖” – 这些设置仅适用于已经应用的设置。 没什么特别的

• 如果在列表中find多次链接相同的GPO，请不要做任何特别的事情。 只要应用相同的逻辑。 当涉及到这个algorithm的时候，它被链接的事实是无关紧要的。

• 在完成所有“非强制GPO”条目之后，对“强制GPO”列表执行同样的操作，从列表顶部开始，将列表中每个GPO的设置应用于相同的“结果集您已经将“非强制GPO”设置应用于“策略”列表。 通过执行“强制GPO”列表，最后让您的设置比“非强制GPO”承载更多的“权重”。 在幕后，“强制”没什么特别的。 该设置只是使“强制”GPO适用于以后的过程中。

上述algorithm有一个特殊的例外：域控制器计算机只能识别来自域顶级链接的OU的“计算机configuration/ Windows设置/安全设置/帐户策略”设置。 这些GPO为域创build密码和帐户策略。 （这些设置可以使用精细粒度密码策略进一步覆盖，但这超出了本讨论的范围。）链接到OU的GPO的“计算机configuration/ Windows设置/安全设置/帐户策略”部分中的任何设置低于顶部域控制器计算机将忽略该域的级别。

而已。 这是组策略应用程序algorithm。 （在产品中执行方式略有不同，但这种方法在function上是等同的。）没有什么比这真的多。

我在社区学院教了几年“微软官方课程”的authentication课程。 我发现，一旦学生理解了这个algorithm，“灯会亮”，我得到的关于“这个策略为什么不适用”的问题的数量呢？ 几乎下降到零。

任何人都可以推荐任何video/博客/专家来查看更多关于GP最佳实践？ 微软是否有这个文件的地方？ 这似乎很难find。

在Active Directorydevise方面，针对Windows 2000 Server和Windows Server 2003的文档仍然是完全有效的。 影响Active Directory结构devise决策的基本function和因素今天与AD发布时相同。

同样，组策略也没有发生巨大的变化。 是的，组策略可以影响的特定设置发生了变化，但是pipe理应用程序过程的规则是相同的，尽pipe有些事情的名称已经更改（例如，“无替代”变为“强制”），并且添加了function（如WMI过滤）。 所有的基本概念仍然有效。

我所看到的大多数组策略文档和参考网站似乎都陷入了“哦，天哪，看看你可以应用的所有这些令人兴奋的设置”，并且学会了关于应用程序的学习，有些事情你只是使用GPMCbuild模处理。 对我来说，这是倒退的想法。 一旦您了解了GPO的实际应用情况，您可以深入了解这些设置。 （在学习如何启动汽车之前，先弄清楚声音系统和电动车窗是如何工作的，当然 – 敞篷车是华丽的，但如果你不能启动汽车，它将不起作用。

以下是一些与Active Directorydevise有关的Microsoft资源，我认为这些资源是合理的：

• 组策略规划和部署指南

• devise一个组策略基础设施

• deviseActive Directory逻辑结构 – 与组策略不直接相关，但对Active Directorydevise有很好的讨论

• devise工作的OU结构

除了参考资料之外，我认为做实验和testing是非常重要的，既要熟悉产品的function集，也要validation您的devise。

假设您正在使用一组隔离的OU以及可以在您的生产域中“玩”“用尽”用户和计算机对象，而不受惩罚（至less对于客户端计算机 – 对于服务器，特别是域控制器，在testing环境中玩游戏可能会更好）。 如果需要的话，你可以模拟域的顶部带有“块inheritance”OU，并在其下build立一个完整的模拟环境。 （如果您需要模拟网站级别的组策略，您也必须创build一个模拟Site对象……除了我之外，几乎没有任何人可以使用它）。

除此之外：Zow–在使用服务器故障将近5年之后，我终于有时间和机会写下我的旧社区大学课程中的GPO处理讲座。 所以，让我们看看这里 – 我已经写了我的老讲义中的IPv4子网划分文章，我已经打了100K，并且正在closures这个“传奇”徽章。

我的任务几乎完成。