用于安装、配置、维护的 powershell 与 GPO

Question

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

这是情况：

由于累积的公司混乱的喜剧，我们突然发现自己必须在很短的通知和交付时间表内设计、配置和部署完整的 Windows Server 2008R2 和 Windows 7 专业版/企业版。当然，我无论如何都不是 Windows 专家，而且我们人手不足，以至于我们的流行语宾果游戏包括“自动”和“一键式”以及“它需要正常工作”。（FWIW，我从 DEC 开始，然后是 solaris 和 cisco，然后是各种风格的 linux，现在有一些 BSD。我使用 Windows 发送电子邮件和填写表格）。

所以我们决定引进一个承包商来为我们做这件事。他们赶上了最后期限。该系统已启动并且大部分可用，这很好。我们将无法做到这一点。但现在被证明是 PIMA 的“主要”部分，无论如何我都必须学习微软的东西，直到/如果我们能与这些人签订新合同以进行持续运营。

这是我的问题。承包商几乎专门使用 powershell 进行部署、配置和更新。我上周的精读使我认为部署、配置和更新微软东西的普遍接受的做法使用 GPO 和 ADMX 模板的元素，以及一些第三方的东西，如 PolicyPak。

是否有充分的理由我还没有发现 powershell 脚本比 GPO 方法更受欢迎？

当他休假回来时，我将与承包商负责人讨论这个问题，他会直接和我在一起（我认为他们也不会安排我们）。但我也可以看到这可能是一个宗教问题，所以我仍然想了解一些背景知识。

想法？或网页链接？

谢谢！

Answer 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 变量。大约需要 1/10 的时间。

您还可以采用混合方法，将 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 框架或使用第三方模块。

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

4. 如果您必须调用旧的 Window 命令实用程序（net.exe、schtasks.exe），则调用该命令可能会很棘手，而要使其屏幕输出与 PowerShell 的输出很好地配合使用则更加“棘手”。您可能有一个失败的命令并且您不知道它。

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

1. 脚本几乎是编程项目。随着时间的推移，代码会增长并变得更加复杂。如果你不把它当作一个“真正的”编程项目，带有注释、版本历史、子例程等，它就会变成一个无法维护的混乱，你的继任者最终会因为他不理解而报废。

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

3. 脚本的优势在于它们可以被签入版本控制并进行差异化。对于 GPO，这有点难做到。

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

5. GPO 的优势在于您可以使用RSoP 之类的工具来获取应用于特定工作站/用户的所有设置的报告。这对于审计和故障排除很重要。

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

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

无论您使用哪种方法，请确保将事情记录在案。您应该在微观层面（“为所有会计工作站实施设置 x 以解决应用程序 y 的问题”）和宏观层面（“我们所有的工作站设置都存储在名为 x 的 GPO 中”）进行记录）。

后续编辑： PowerShell 4 添加了一项名为Desired State Configuration的新功能。这看起来可用于实现组策略首选项的某些功能。它可能会改变游戏规则。还没有使用它，但它看起来真的很酷。

后续编辑 2： 我意识到的一件事是我没有正确区分Group Policy Policies与Preferences。首选项非常类似于 PowerShell 脚本。策略更“严格”，并且在脚本中实现起来更棘手。为此，您必须让脚本填充 HKLM\Software\Policies，但必须注意与 GPO 的冲突。在这种情况下，做一个或另一个，而不是两个。