组策略devise

背景：

自从2000年年中开始部署Windows 2000 Server和Windows 2000 Professional客户端以来，我一直在我的客户站点中大量使用组策略。 与其他Samba和其他与Windows客户端操作系统兼容的单点login机制，Windows Server / Active Directory平台上的组策略是最引人注目的function之一。

您在实施组策略时学到了什么？

• asynchronous策略处理提供了非确定性的体验。 它在Windows 2000 Processional中被默认closures，但在Windows客户端操作系统的所有更高版本中默认打开。 我强烈build议强制过程重新同步，以提供确定性的体验。

• 了解如何selectGPO中的设置并将其应用于计算机和用户，具有巨大的价值。 algorithm真的非常简单（和“块inheritance”和“无覆盖”只是稍微复杂的algorithm）。 大多数策略应用程序问题最终成为系统pipe理员对用于应用组策略的algorithm的理解与操作系统实际执行的操作之间的不匹配。 依靠像RSoP或GPRESULT这样的工具，而不是完全理解特征的工作方式是一个坏主意。

• 不要忘记站点级别的GPO链接。 他们可以非常非常方便。 当便携式计算机在站点之间移动时，请注意可能导致重大事件发生的设置（例如，当计算机“超出范围”时强制移除的软件安装）。

• 在部署到生产之前（尤其是使用软件安装function），在实验室OU和testing计算机上进行规划和testing。 testing，testing，testing，然后再testing。 如果您犯了一个错误，组策略可以让您非常非常容易地损坏成千上万台计算机的configuration。

• 不要把组策略视为为了安全而做任何事情。 组策略可以帮助实现“纵深防御”策略（开启AppLocker等function，强制组织成员身份等），但是如果有人在某台机器上获得“pipe理员”权限，他们将很容易“杀死”组该机器上的政策。

• 确保您了解“块inheritance”，“不覆盖”以及WMI和安全组过滤的工作方式。 这些function可以让您pipe理在OU中简单链接GPO的场景无法处理。 尽量不要过度使用这些function，因为它们在几个月后可能是非直观的反向工程或其他系统pipe理员理解的。

• 在进行更改之前备份关键的GPO。 GPMC工具增加了这个function，非常非常方便。 无论如何，您应该做AD的系统状态备份，但是使用GPMC从备份中恢复单个GPO比系统状态恢复更方便。

• 我经常利用脚本作为“陷阱门”。 只要客户不是特定组的成员，客户就可以应用这些脚本。 脚本的最后一行将客户端放入该组中，以便在下次启动时客户端不再执行脚本。 这是非常方便的行为。

你会改变什么？

不多。 我有我的组策略应用程序“风格”各种不同“修订”的不同客户。 我本人不会“做任何不同的事情”，但是我的确努力将一切正常化为一个非常相似的configuration。 对我来说，这只是调整GPO的“风格”，而不是做任何广泛而彻底的改变。 我必须做的主要变化是在投入生产之前没有足够的testing结果。 我有没有提到你应该尽早和经常testing？

你是如何devise它与客户端和服务器兼容的？

就像我隔离不同类别的用户或客户端计算机。 我将客户端计算机和服务器计算机分隔到不同的OU中，并将不同的GPO链接到这些OU。 不同angular色的服务器可能会进一步分离（或放入安全组，并且GPO应用程序被过滤）。 我有适用于这两种types的计算机的通用GPO（通常只有一些选定的几个设置）。

你是如何处理或容纳各种操作系统的？

WMI筛选是处理各种Windows版本的一种方法。 它工作正常，但我个人不喜欢它。

我通常会部署一个启动脚本（我写在客户的时间，不幸的是，所以我不能在这里分享）来检测Windows版本的组策略客户端（以及他们的32/64位和是否他们是裸机或运行在给定的pipe理程序）填充组，使我可以使用安全组过滤，而不是WMI过滤。 由于WMI筛选仅对GPO具有primefaces性，而我可以在GPO内的单个软件安装中使用安全组筛选，所以我更喜欢安全组筛选。

我没有客户端软件的经验，允许非Windows客户端使用组策略，所以我不能说这个。

是否应该遵循普遍接受的组策略devise？

我来自“老学校”，所以我学会了根据微软“当天回来”的build议deviseActive Directory。 当我构build我的OU结构时（与控制委派，这是我首先关注的是：OU结构），我非常重视组策略。

就个人而言，我更喜欢尽可能less的GPO来完成工作，而无需在多个GPO中重复常用设置。 我尽可能限制地使用“块inheritance”，“不覆盖”和安全组过滤（尤其是使用“拒绝”权限）。 我尝试将GPO命名为“自我logging”。 我从不修改使用Active Directory“开箱即用”的默认GPO，这样我可以在“紧急”情况下禁用所有其他GPO，并将产品返回到“库存”行为。

嵌套策略来创build一个像模型一样的分层树是否是一个好主意？

这是我的总体战略，对我来说效果很好。 我可以在多个位置链接相同的GPO（例如，在“成员服务器”OU和默认“域控制器”OU）中链接的名为“成员服务器和域控制器计算机的通用设置”的GPO。 然后，我将链接addt'l具有更多具体设置的GPO，因为我向下移动到我的OU层次结构中。 连接“愚蠢”的GPO（数十或数百）将会影响性能。 我有客户连接7 – 12个GPO的客户，没有不良的性能影响。

在devise政策结构方面，客户端机器的login速度是否有任何顾虑？

某些组策略客户端扩展（CSE）模块可能会很慢。 在某些情况下（如文件夹redirect或软件安装策略），它可能只是一次性放缓。 在其他情况下（如Windows XP SP3中的IE策略），它可以为每个login添加几秒钟。 一般来说，尽量保守，尽可能less的GPO链接。 根据需要运行尽可能less的脚本（如果您正在同步处理它们，它们可以真正加起来）。 testinglogin时间应该是您testing的一部分。

既然有Windows XP和Windows 7的机器，那么ADM文件和ADMX文件有什么不同？ 我怎么知道什么时候使用一个呢？ 它甚至重要吗？

ADM文件与ADMX文件创build的REGISTRY.POL文件没有区别 。 如果要从Windows 2003或Windows XPpipe理组策略，则需要保留ADM文件。 如果您要限制您的GPOpipe理到Windows Vista或更新的操作系统，那么您可以放弃ADM文件。 我个人并不担心，但是我最大的SYSVOL只有大约400MB。 如果我有数百个GPO，那么我可能要尽快从ADM文件迁移出去。

回送处理是一个好主意使用？

如果你需要它提供的function，那绝对是一个好主意。 有一些情况下，你不能没有它configuration。 回环策略处理工作正常，只要你明白它是如何工作的。 这对于提供服务的目的非常有用（无论用户login如何将一致的用户设置应用于计算机）。

有人告诉我，我应该看看利用组策略对象中禁用的用户configuration设置或禁用计算机configuration设置选项。 这是一个聪明的事情吗？ 这是否设置是否重要？

这涉及到login时间的问题。 你可以对它进行基准testing，并看到你的环境，但坦率地说，我没有看到性能差异。 我不担心在我的客户网站。