☰

powershell 与 GPO 的安装、配置和维护

tag-icon • tag-icon windows-server-2008 group-policy powershell best-practices
powershell 与 GPO 的安装、配置和维护

我的问题是关于使用 powershell 脚本在 2008R2 域中安装、配置、更新和维护 Windows 7 Pro/Ent 工作站，而不是使用 GPO/ADMX/msi。

情况如下：

由于公司内部不断出现各种不作为行为，我们突然发现自己必须在非常短的时间内设计、配置和部署完整的 Windows Server 2008R2 和 Windows 7 Pro/Enterprise，并且要按时交付。当然，我绝不是 Windows 专家，而且我们人手严重不足，所以我们的流行语包括“自动化”、“一键式”和“它需要正常工作”。（FWIW，我从 DEC 开始，然后是 solaris 和 cisco，然后是各种版本的 linux，现在还有少量的 BSD。我使用 Windows 来收发电子邮件和填写表格）。

因此，我们决定聘请承包商来为我们完成这项工作。他们按时完成了任务。系统已启动，并且基本可用，这很好。我们本来无法做到这一点。但现在事实证明，PIMA 的“基本”部分是关键，而且无论如何，我必须学习 Microsoft 的东西，直到/如果我们能与这些人签订新合同以进行持续运营。

这是我的问题。承包商几乎只使用 powershell 进行部署、配置和更新。我上周的深入阅读让我想到，部署、配置和更新微软产品的普遍接受的做法是使用 GPO 和 ADMX 模板的元素，以及可能一些第三方产品，如 PolicyPak。

是否存在我尚未找到的充分理由，表明 powershell 脚本比 GPO 方法更受欢迎？

等承包商主管休假回来后，我会和他讨论这个问题，他会直截了当地告诉我（我也不认为他们陷害了我们）。但我也知道这可能是一个宗教问题，所以我仍然想了解一下这方面的背景情况。

有什么想法？或者网页链接？

谢谢！

答案1

这里没有“正确”的答案。我个人倾向于使用组策略进行设置/策略，但对于应用程序部署，使用 PowerShell（或甚至旧的 WSH 脚本或批处理文件），假设您有一个没有复杂信任问题的单个域。但是，这有权衡。在 PowerShell 中执行所有操作肯定是合法的。

应用程序部署（GPO 与脚本）：

使用基于 GPO 的软件部署，您只能使用 MSI 包。对于不通过 MSI 分发的产品（例如 setup.exe），这可能会很烦人。在这种情况下，您必须将其打包为 MSI。享受 Adob​​e Reader 的 MSI+MSP 分发（必须制作 AIP）。如果您需要自定义安装，则需要处理 MSI 转换。脚本中一行代码可能变成复杂的多步骤过程。

当您部署的所有内容都可以作为 MSI 轻松获得，并且无需特殊自定义即可安装时，GPO 部署会非常顺利。您可以使用 WMI 定位并自动卸载不符合策略的内容。但是，一旦您走出这个框框，事情就会变得更加复杂。此外，当出现问题时，很难从事件查看器中找出发生了什么。

使用脚本，您可以安装或卸载几乎任何东西，MSI、EXE 等等。如果您需要在安装之前做一些清理工作（例如，清除未完全卸载的先前版本的旧注册表项），您可以这样做。如果出现问题，您可以根据需要添加尽可能多的调试/重试/解决方法代码，并且可以在启用日志记录的情况下运行 msixec。

您的脚本通常需要一些条件逻辑来检查软件是否已安装（以及安装的版本），然后在需要时调用安装程序。如果您没有编程背景，这可能会令人生畏。它不再是一个点击式解决方案。由于您自己编写了脚本，因此您也更有可能搞砸事情。

我们从 GPO 切换到 PowerShell 进行应用程序部署，这让事情变得简单多了。当新版本发布时，我们只需将新的安装程序文件放入我们的 AppDeployment 共享中并更新脚本中的 $expected_version 变量。所用时间约为十分之一。

您还可以采用混合方法，即使用 GPO 处理 MSI 内容，使用脚本处理其他内容。我不太喜欢这种方法，因为我喜欢在一个地方查看已安装的内容。

请注意，使用组策略时，应用程序部署直到重新启动才会发生。如果您使用启动脚本，情况也是如此。但是，如果您使用PowerShell 远程处理或者您可能无需重新启动即可完成计划任务（但可能会变得混乱）。

设置和配置（GPO 与脚本）：

组策略首选项使用起来非常简单，可以执行诸如创建注册表值、映射网络驱动器、创建快捷方式等操作。组策略具有后台刷新功能，这一点非常巧妙，因为您可以应用设置而无需强制用户重新启动。项目级别定位为您提供了很大的灵活性（这是 GPO 级别的 WMI 和安全过滤的补充）。

但是，组策略首选项远非完美。我的一些不满之处如下：

  1. 管理 Internet Explorer 的方法太多了，有些方法已经过时了，有些方法不适用于最新的 IE。我总是直接管理注册表设置。

  2. 事件查看器中随机出现的愚蠢错误。例如：我创建了一个删除计划任务的项目。太好了，它从我所有的工作站上消失了。现在事件查看器开始出现错误“我无法删除该任务，因为它不存在”。真是的！

  3. 申请一次，不要重复申请在你的职业生涯中至少会伤害你一次。

  4. 更新与替换。请注意，因为您可能会选错。

  5. 使用项目级别定位所能做的事情是有限的。如果您需要 for() 循环或字符串操作（修剪字符、调整大小写），那么您将回到脚本。

  6. GPP 文件操作总是会发生，即使文件没有被更改。您的工作站会不断从服务器复制相同的文件，即使它们并不需要它。这可能会意外地损坏您的服务器和网络。项目级别定位可以帮助缓解这种情况，但请注意您是否选中了“若未应用则删除”。

  7. 事件查看器中的许多 GPP 错误不包含任何有用的信息来实际修复问题。您必须开启追踪。

您可以使用 PowerShell 进行设置，但它也有一些缺点：

  1. 使用 PowerShell 管理注册表设置会变得很麻烦（至少使用本机注册表提供程序时）。在我看来，微软在将注册表值设为“属性”而不是实际项目时搞砸了。这让事情变得比需要的复杂得多。您需要一堆条件逻辑来测试注册表项并在创建值之前创建它们。组策略在这方面要简单得多。

  2. 有很多“基本”系统管理任务无法在 PowerShell 中直接执行（例如创建快捷方式、管理计划任务）。您必须调用 Wsh、.Net Framework 或使用第三方模块。

  3. 脚本仅在启动/登录时运行。无后台刷新（除非您设置了计划任务）。

  4. 如果您必须调用传统的 Windows 命令实用程序（net.exe、schtasks.exe），调用命令可能会很棘手，而让其屏幕输出与 PowerShell 的输出完美匹配则更加“棘手”。您可能有一个命令失败了，而您却不知道。

关于脚本（PowerShell 或其他）与 GPO 的一些其他一般评论：

  1. 脚本基本上就是编程项目。代码将要随着时间的推移，它会变得越来越复杂。如果你不把它当作一个“真正的”编程项目，有注释、版本历史、子程序等，它将要它会发展成难以维持的混乱局面，而你的继任者最终会因为不理解它而将其废弃。

  2. 系统管理员（通常）不是程序员。他们不懂正确的编程规则（参见第 1 点）。即使是结构良好的代码，对于没有编程背景的管理员来说，也可能令人望而生畏且难以理解。请注意您当前和未来员工的技能。

  3. 脚本的优势在于可以将其签入版本控制并进行差异化。使用 GPO 则比较难做到这一点。

  4. 脚本更容易复制到 USB 密钥上并随身携带。您的承包商可能就是这种情况。他可能有一些以前项目的现有脚本，他可以将其用于您的项目。在我的环境中，我有两个气隙网络（不要问），但配置相似，因此我们尽可能使用 PowerShell 脚本，以便我们可以在两个网络之间重新循环代码。

  5. GPO 的优势在于，你可以使用以下工具放射科协会获取应用于特定工作站/用户的所有设置的报告。这对于审计和故障排除非常重要。

  6. GPO 更“容易被发现”。我可以进入一个陌生的环境，并很快了解所应用的策略和设置。使用脚本，我必须开始研究代码，并希望它有很好的注释。

  7. PowerShell 远程处理对于您想要在一堆系统上运行的一次性命令来说，它真的很方便，而且您不希望它成为“永久”策略（例如，每个人都删除这一个临时文件）。

无论你使用哪种方法，都要确保事情有据可查。你应该在微-level（“为所有会计工作站实施设置 x，以解决应用程序 y 的问题”），以及宏-level（“我们所有的工作站设置都存储在名为 x 的 GPO 中”）。

后续编辑： PowerShell 4 添加了一项新功能，称为期望状态配置。这看起来可以用来实现组策略首选项的一些功能。它可能会改变游戏规则。还没有用过，但它看起来真的很酷。

后续编辑2： 我意识到的一件事是，我没有正确区分组策略政策对比优先。首选项与 PowerShell 脚本非常相似。策略稍微“严格”一些，在脚本中实现起来比较棘手。为此，您必须让脚本填充 HKLM\Software\Policies，但您必须注意与 GPO 的冲突。在这种情况下，请执行其中一个，而不是同时执行两个。

答案2

显然，微软相信（并且大多数人都同意）组策略是处理大多数客户端配置的最佳方式。界面简单明了，对于大多数设置，您甚至不需要触摸键盘。它甚至具有内置报告功能。

我认为人们独自使用 PowerShell 登录脚本的唯一原因是某种自定义报告或 GP 无法处理的专有功能。

此外，安装 Windows 时，默认情况下会禁用 PowerShell 脚本。但不用担心，有一个组策略选项可以更改此设置。

答案3

对于整体配置，组策略就是为此而设计的。

对于软件安装，我 100% 会选择 PowerShell。有人告诉我，通过 GPO 发布/分配软件包是一种不好的做法，而且我不太喜欢执行登录/注销脚本。有一个 PowerShell 脚本，可以由用户从内部网位置启动，或者您可以自己使用 PSRemoting 启动安装。PSRemoting 允许您调用命令（Invoke-Command 或 icm），然后将命令发送到域中的一台、多台或所有计算机。

对于维护，我会使用 PowerShell 脚本，但是，我不确定您所说的维护是什么意思。

使用 PowerShell 进行部署是因为如果您以前做过并且有脚本模板，那么部署会更容易。您可以直接使用它，而不必为需要设置的每个用户/计算机/角色/功能都通过 GUI 进行操作。

答案4

从咨询行业双方以往的经验来看，我认为 PowerShell 脚本更容易让您的顾问进行推广。将 PS 脚本从一个客户站点带到另一个客户站点并修改细节比导出/导入 GPO 更容易，因为要考虑到现有的各种 OU 定位。

如果您正在谈论维护 Win7 工作站，您还应该考虑专用的系统管理实用程序，例如 Microsoft System Center、Kace 等。以下内容听起来可能与您的情况有些相似：

如何（稳健地）远程执行域中 Windows 工作站上的任务？

你可以使用 PowerShell/GPO 做你想做的一切（我真的您可能对探索新的 PS 4 所需状态配置感兴趣，但专用系统往往可以节省时间/金钱。

相关内容