服务器 Gind.cn
  1. 服务器 Gind.cn
  3. powershell与GPO进行安装，configuration和维护
Intereting Posts
JRUN吃100％的CPU 启用S​​SL时，Apache HTTP不工作 Smtp服务器外部到外部 正向查找区域从SBS2003 SP2中丢失 validation没有访问根域的子域的证书 Crontab的大小限制？ AD帐户必须能够创build/重置/启用帐户，而无需login到域控制器的权限 如何在访问Windows Server 2008 R2 for Windows家庭版用户上的共享文件夹时禁用用户名和密码请求？ Ubuntu – 使用Small Live CD进行无人值守自定义安装 我怎样才能让Openfire 3.7.1“记住”它的configuration？ 什么是DNS TXTlogging“mailru-verification”？ networking服务器机柜 – 通风是如何工作的？ 木偶忽略ENC类 用Zenoss监控局域网 为什么Windows Server 2012上的IIS不能访问系统环境variables？

powershell与GPO进行安装，configuration和维护

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

情况如下：

由于喜剧累积的企业碰撞，我们突然发现自己必须在很短的时间内和交付时间表上devise，configuration和部署完整的Windows Server 2008 R2和Windows 7 Pro / Enterprise。 当然，我不是一个Windows专家，我们人手不够，我们的stream行词宾果包括“自动化”和“一键”和“它需要正常工作”。 （FWIW，我从DEC开始，然后到solaris和cisco，然后是现在各种风格的linux，只有一些BSD，我用Windows来填写表格）。

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

这是我的问题。 承包商几乎专门用于部署，configuration和更新。 上周我的精读内容让我认为部署，configuration和更新微软公司的普遍接受的做法使用了GPO和ADMX模板的元素，以及一些第三方的东西，比如PolicyPak。

有没有坚实的理由，我还没有发现，PowerShell脚本将优于GPO方法？

当他回来休假的时候，我会和承包商的负责人讨论这个问题，他会直接和我一起（我也不认为他们是这样做的）。 但是我也可以看到这可能是一个宗教问题，所以我仍然想要一些背景。

思考？ 或网站链接？

谢谢！

这里没有“正确的”答案。 我的个人偏好是使用组策略设置/策略，但是对于应用程序部署，使用PowerShell（甚至是传统的WSH脚本或batch file），假设您有一个没有复杂信任问题的域。 但是，有权衡。 在PowerShell中做所有事情肯定是合法的。

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

使用基于GPO的软件部署，您仅限于MSI软件包。 这可能是非MSI分发的产品烦恼（如setup.exe）。 在这种情况下，你必须把它打包成一个MSI。 享受Adobe Reader的MSI + MSP发行版（必须创buildAIP）。 如果您需要自定义安装，则需要混淆MSI转换。 脚本中的某一行可以成为一个复杂的多步骤过程。

当你正在部署的所有东西都可以作为MSI使用，并且可以在没有特殊定制的情况下进行安装时，GPO部署非常顺利。 您可以使用WMI定位function，并自动卸载超出策略的内容。 但是一旦你走出这个盒子的界限，情况会变得更加复杂。 另外，当出现错误时，可能很难弄清事件查看器发生了什么。

有了脚本，你可以安装或卸载任何东西，MSI，EXE等等。 如果您在安装之前需要做一些清理工作（例如，从以前的版本中清除旧的registry项，而不是干净的卸载），您可以这样做。 如果出现问题，您可以根据需要添加尽可能多的debugging/重试/解决方法代码，并且可以在启用日志logging的情况下运行msixec。

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

我们从应用程序部署的GPO切换到了PowerShell，使事情变得更加简单。 当新版本出来时，我们需要做的是将新的安装程序文件放入我们的AppDeployment共享中，并更新脚本中的$ expected_versionvariables。 如十分之一的时间。

你也可以做一个混合的方法，你使用GPO的微星的东西和脚本的一切。 我不是这个迷，因为我喜欢有一个地方去看看是什么安装。

请注意，使用组策略，应用程序部署在重新启动之前不会发生。 如果您正在使用启动脚本，则也是如此。 但是，如果您使用PowerShell远程处理或计划任务，则可以在不重新引导的情况下将其closures（尽pipe可能会变得麻烦）。

设置和configuration（GPO vs脚本）：

组策略首选项使用起来非常简单，可以用来创buildregistry值，映射networking驱动器，创build快捷方式等等。组策略具有后台刷新的事实很光滑，因为您可以应用设置而不强制用户重新启动。 项目级别定位为您提供了很大的灵活性（除了GPO级别的WMI和安全筛选之外）。

但是，组策略偏好远非完美。 我的一些小偷：

  1. 有太多方法来pipe理Internet Explorer，其中一些不推荐使用，有些不适用于最新的IE。 我总是直接pipe理registry设置。

  2. 事件查看器中的错误是愚蠢的。 例如：我创build了一个项目来删除一个计划任务。 太好了，我所有的工作站都没有了。 现在事件查看器开始填充错误“我不能删除任务，因为它不存在”。 咄！

  3. 申请一次，不重新申请会在你的职业生涯中至less搞砸你一次 。

  4. 更新与replace 。 注意，因为你可能会选错了。

  5. 物品等级定向有什么限制。 如果您需要for（）循环或string操作（修剪字符，resize写），您将返回到脚本。

  6. GPP文件操作总是会发生，即使文件没有被改变。 即使他们不需要，您的工作站也会一遍又一遍地将相同的文件从服务器上复制下来。 这可能会意外地锤击您的服务器和networking。 物品级别定位可以帮助缓解这一点，但请注意是否选中了“如果未应用删除”选项。

  7. 事件查看器中的许多GPP错误都不包含实际解决问题的有用信息。 你必须打开跟踪 。

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

  1. 使用PowerShellpipe理registry设置变得麻烦（至less在本机registry提供程序中）。 在我看来，微软搞砸了，他们使registry值“属性”，而不是实际项目。 它使事情变得比需要的复杂。 您需要一堆条件逻辑来testingregistry项并在创build值之前创build它们。 组策略在这方面要简单得多。

  2. 有很多“基本的”系统pipe理员任务，你不能在PowerShell中本地执行（例如创build一个快捷方式，pipe理一个计划任务）。 您必须调用Wsh，.Net框架或使用第三方模块。

  3. 脚本仅在启动/login时运行。 没有后台刷新（除非你设置一个计划任务）。

  4. 如果您必须调用传统的Window命令实用程序（net.exe，schtasks.exe），则调用该命令可能会非常棘手，而更难以使其屏幕输出与PowerShell的输出良好地配合使用。 你可能有一个失败的命令，你不知道。

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

  1. 脚本几乎是编程项目。 随着时间的推移，代码将会变得越来越复杂。 如果你不把它看作是一个“真正的”编程项目，包括注释，版本历史，子程序等等，它将会变成一个难以维系的混乱，你的继任者将因为不了解而终结报废。

  2. 系统pipe理员（通常）不是程序员。 他们不知道正确的编程规则（见第1点）。 即使结构良好的代码对于没有编程背景的pipe理员来说也是令人恐惧和难以理解的。 注意你现在和将来的工作人员的技能。

  3. 脚本有一个优势，就是它们可以被检查到版本控制和差异。 有了GPO，这有点难。

  4. 脚本更容易复制到USB密钥并带走。 你的承包商可能是这样的情况。 他可能有以前的项目的一些现有的脚本，他能够为您的项目回收。 在我的环境中，我有两个空隙（不问）的networking，但是具有相似的configuration，所以我们尽可能使用PowerShell脚本，这样我们就可以在两个networking之间重新循环代码。

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

  6. GPO更“可发现”。 我可以进入一个陌生的环境，很快就能够加速应用哪些策略和设置。 用脚本，我必须开始学习代码，并希望它很好的评论。

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

无论使用什么方法，都要确保事情有详细的logging。 您应该logging微观层次上的事情（“为所有会计工作站实施设置x以解决应用程序y的问题”）以及macros级别（“我们所有的工作站设置都存储在GPO中，称为x” ）。

后续编辑： PowerShell 4添加了一个名为Desired State Configuration的新function。 这看起来好像可以用来实现一些组策略首选项。 这可能是一个游戏改变者。 还没有使用它，但它看起来非常酷。

后续编辑2：我意识到的一件事是，我没有正确区分组策略策略与首选项 。 首选项与PowerShell脚本非常类似。 政策稍微“僵化”一些，而且在脚本中执行起来更为棘手。 要做到这一点，您必须让脚本填充HKLM \ Software \ Policies，但是您必须注意与GPO的冲突。 在这种情况下，做一个或另一个，而不是两个。

微软相信（和大多数人都同意）组策略是处理大多数客户端configuration的最好方法。 界面很简单，对于大多数设置，您甚至不需要触摸键盘。 它甚至具有内置的报告function。

我可以看到有人独自出击并使用PowerShelllogin脚本的唯一原因是某种自定义报告或GP无法处理的专有function。

另外，安装Windows时，PowerShell脚本默认是禁用的。 但是不用担心，有一个组策略选项可以改变它。

对于整体configuration，组策略，这就是为什么devise的。

对于软件安装，我会selectPowerShell 100％。 我被告知，通过GPO发布/分配软件包是一个不好的做法，我不喜欢做login/注销脚本。 有一个PowerShell脚本，可以由用户从Intranet位置启动，也可以通过PSRemoting自行启动安装。 PSRemoting允许您调用命令（Invoke-Command或icm），然后将命令发送到域中的一台，多台或所有计算机。

对于维护，我会使用PowerShell脚本，但是，我不确定你的意思是维护。

使用PowerShell进行部署的原因是，如果您之前已经完成了此任务，并且拥有脚本的模板，则会更容易。 您可以使用它，而不是通过GUI为每个需要设置的用户/计算机/angular色/function进行欺骗。

从以前的咨询围栏的经验来看，我怀疑PowerShell脚本对您的咨询师来说更容易推广。 将PS脚本从一个客户端站点转移到另一个客户端比修改详细信息更容易，而不是导出/导入GPO，并考虑到其中的各种OU目标。

如果你正在谈论维护Win7工作站，你还应该考虑一个专用的系统pipe理工具，比如微软系统中心，Kace等等。下面的这些听起来可能与你的情况有一些相似之处：

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

你可以用PowerShell / GPO来做所有你想要的东西（我真的很想探索新的PS 4期望状态configuration），但是通常专用系统会节省时间/金钱。