有许多软件部署工具可将软件和更新交付到你的终端设备，但选择很多并不意味着一定会让人感到困惑。你可以选择使用一种软件部署工具来完成所有工作，也可以根据你的需求选择多种自动化的软件部署工具。没有任何一种软件部署工具能够对每家公司都提供“放之四海而皆准”的解决方案。因此在这份简要指南中，我们将帮助你了解一些最受欢迎的软件部署工具，并就应使用哪些方法来部署软件以及 3rd 方补丁提供建议。
以下是在表 1 中概述我们将在本论文中探讨的内容。
| Pros | Cons |
|---|---|---|
|
SCCM Software Deployment / Other On-Prem Software Deployment |
|
|
|
Intune Software Deployment / Other MDM Software Deployment or RMM Software Deployment Tools |
|
|
|
PolicyPak Remote Work Delivery Manager |
|
|
|
PolicyPak Scripts Manager |
|
|
表 1：软件部署工具对比。
精选五选的相关内容：
软件部署清单
如果你已经对自己的软件部署工具感到满意，那很好。但如果你没有办法部署软件，或手头的工具并不让你满意，你应该看看这份指南。我们先从了解你可能已经拥有的本地（on-prem）和基于云的软件下载/部署工具开始。
大型的本地（on-prem）管理软件部署工具，例如 MEMCM、LANDesk、KACE、SpiceWorks、Chef、BMC 等。
MEMCM、LANDesk、KACE、SpiceWorks、Chef、BMC 以及其他产品通常会集成到大型网络中。通常，这些系统都有各自的工程师，专门负责管理系统；并且使用这些系统将软件部署到所有计算机上。
尽管这种组织架构本身没有问题，但运行 MEMCM（或类似系统）的团队可能与负责 Windows 10 的安全、管理或自动化的人员并不相同。因此，你可能会发现，通过 PolicyPak Remote Work Delivery Manager 以替代方式执行部分软件安装会更有帮助。
此外，向 MEMCM 添加额外软件以专门帮助更轻松地管理rd 方（第三方）非微软的更新也非常常见。在图 1 中，你可以看到 MEMCM 能够连接rd 方付费目录的位置。
图 1：如何将第三方付费目录连接到 MEMCM。
如果你还没有购买类似的产品并将其集成到 MEMCM 中，我们建议你查看本文后面提到的软件部署替代方案。如果你已经是 PolicyPak 客户，PolicyPak Remote Work Delivery Manager 可能正是你在持续的软件安装需求方面所需要的。
大型云端管理系统，例如 Microsoft Intune、VMware Workspace One、Citrix Endpoint Manager，以及任何面向 MSP、用于部署软件的系统
这些在云端诞生的大型系统正试图在大型本地（on-prem）系统的能力范围之外接手。事实上，你现在可以将本地 MEMCM 与云端 Intune 联动，用于部署软件。
话虽如此，即使是 Intune 这类系统也有不少限制。首先，它没有任何简单的方法来部署应用程序的 .MSI，然后自动保持其为最新版本。相反，你需要在每次更新和打补丁时都引入下一版本。
不过更重要的是，Intune 没有提供直接部署 .EXE 应用程序（也称为 Win32 应用程序、用于执行软件安装）的方式。相反，你首先需要使用 Intune Win32 App Packaging & Prep Tool（可在以下位置找到 这里 ）将它们打包成 Intune 能够处理的格式。这个手动流程会像图 2 所示那样，把你的 .EXE 包装成一个 .INTUNEWIN 文件。
图 2：使用 Intune Win32 App Packaging 工具对 Win32/.EXE 应用进行重新打包。
只有在这之后，软件才会被预处理并准备好通过 Intune 进行部署。每次你想部署软件，或为现有软件部署补丁（或提高版本号）时，都需要再次执行以下步骤：
- 下载应用程序的新版本
- 将应用程序打包成 .INTUNEWIN 文件
- 将该包上传到 Intune
- 将应用程序部署到你的 Windows 10 设备
使用这种方法，要让这些计算机始终使用最新的应用程序补丁进行更新，可能会是一项真正费力的工作。例如，如果你想部署 Firefox 的最新版本，就必须执行上面提到的所有步骤，以按照图 3 所示的方式将其部署到 Intune。
图 3：部署（或重新部署）重新打包的 .INTUNEWIN 应用。
话虽如此，像 Intune 这样的 MDM 系统确实对结果提供了良好的报告。因此，使用 Intune 来部署更重要但相对静态的包可能是值得的。不过，你也可能会发现，通过 PolicyPak Remote Work Delivery Manager 以替代方式执行一些软件安装和自动更新会更有帮助。
PDQ Deploy（来自我们朋友 PDQ）
PDQ Deploy 是一款出色的本地（on-prem）系统，可让你部署软件并报告安装结果。PDQ Deploy 提供两个版本：Free 和 Enterprise。Free 工具表现出色，在许多情况下，完全可以替代像 MEMCM 或 LANDesk 这样的“大型本地工具”。此外，由于它同时提供免费版本和非常具成本效益的付费 Enterprise 版本，因此价格也大幅更低。
可以在此处找到两个版本的不同功能列表。
如果您没有大型的本地（on-prem）软件部署工具，我们 PolicyPak 建议您使用 PDQ deploy 来完成以下关键任务：
- PolicyPak 客户端扩展的初始安装以及后续额外更新
- 部署复杂的程序包，例如 Office、Java，或“嵌套（nested）”式安装
- 当您需要保证的成功/失败报告时
- 无论何时你都想进行定时或计划发布
当设备加入了域，并且软件包的来源位于 SMB（标准的 Windows 共享）上时，PDQ 的效果最好。你也可以在知道目标设备的本地密码时使用 PDQ（作为替代方案）。你还可以通过 VPN 执行软件投递，但由于终端会通过 SMB 下载软件，最终仍会消耗 VPN 带宽。
PQD Deploy Enterprise 版本附带针对现有软件包的预配置建议。这样一来，你可以更快速地部署，并且更轻松地维护一些更棘手的软件包。有时供应商的安装包并不像预期那样容易安装和部署，但 PDQ Deploy Enterprise 版本可以将一个难处理的包快速安装起来。你可以在图 4 中看到 PDQ Package Library 的示例。
图 4：浏览 PDQ Deploy Enterprise 目录。
我们在 PolicyPak 会经常向那些不想为了把软件交付到其本地（on-prem）以及通过 VPN 连接的机器上，而只为此就推出大型软件部署工具（例如 MEMCM）的组织推荐 PDQ Deploy。PDQ Deploy 非常轻量，并且按管理员计费；成千上万的满意管理员正在成功使用该工具。
PolicyPak 和 PDQ 在许多方面配合得非常好。您应该看看我们的“更好搭档”视频 在这里。
使用 PolicyPak 进行文件与软件交付，并支持脚本执行
PolicyPak 的“超能力”会为您已在使用的本地或云系统带来全新功能。在本节中，我们将说明 PolicyPak 如何自动化更多的软件交付工作，并让您的 Windows 10 设备保持最新。您可以将这些 PolicyPak 功能与您现有的方案搭配使用，也可以单独使用。
PolicyPak 远程办公交付管理器
PolicyPak 远程办公交付管理器的目标是从本地或 Web 共享中复制文件，并在下载这些文件之后安装软件。PolicyPak 远程办公交付管理器集成在 PolicyPak 的所有版本中：Group Policy Edition、MDM Edition 和 Cloud Edition（见图 5）。不过，PolicyPak 远程办公交付管理器的工作方式与上述工具不同，它面向的是不同的工作负载。
图 5：用于组策略和 MDM 的 PolicyPak 远程办公交付管理器。
如图 6 所示，PolicyPak Remote Work Delivery Manager 可从 SMB（标准 Windows 共享）或基于 Web 的共享（例如 Amazon S3、Dropbox、Azure Blob 存储等）复制任何文件（包括 .MSI、.EXE 和其他文件）。
图 6：将 SMB 或基于 Web 的共享用作文件安装源。
PolicyPak Remote Work Delivery Manager 的主要使用场景之一，是通过互联网将新软件部署到未加入域的计算机上。这旨在满足居家办公或远程工作团队的需求；当 PolicyPak 客户如图 7 所示将其与 PolicyPak Cloud 配合使用时，它非常适合。
图 7：与 PolicyPak Cloud 一起使用的 PolicyPak Remote Work Delivery Manager。
当用户处于远程环境并使用 PolicyPak Cloud Edition 或 PolicyPak MDM Edition（甚至在本地环境中，或通过 PolicyPak Group Policy Edition 通过 VPN）时，软件和其他文件会使用 Windows 10 的（近乎魔法般的）Background Intelligent Transfer Service (BITS) 协议进行下载。以下内容摘自 BITS 文档 此处。
Background Intelligent Transfer Service (BITS) 由程序员和系统管理员用于从 HTTP Web 服务器下载文件或向其上传文件，以及向 SMB 文件共享上传文件或从中下载文件。BITS 会考虑传输的“成本”以及网络使用情况，以便尽可能减少对用户前台工作的影响。BITS 还可以处理网络中断：暂停并在需要时自动恢复传输，即使在重新启动之后也同样如此。
由于 PolicyPak 利用 BITS，即使因为关闭桌面电脑、合上笔记本电脑的盖子，或将网络从本地（on-prem）切换到家用网络等原因导致大文件下载中断，BITS 也会从中断处继续后续下载。 这意味着你可以放心地下载非常大的文件，然后在下载完全完成并存储到目标机器之后对其进行一些工作。
PolicyPak Remote Work Delivery Manager 可以从本地（on-prem）SMB 共享（通过以太网、Wi‑Fi 或 VPN）下载这些文件，也可以从 Web 共享下载（Amazon S3、Dropbox 或 Azure Blob 存储）。PolicyPak Remote Work Delivery Manager 会从该源点发起下载，并通常会绕开任何对 VPN 带宽的使用。因此，它非常适合在无法保证 VPN 连接的居家办公（work-from-home）以及其他远程办公场景中使用，同时当你不想使用 VPN 带宽来下载软件时也同样适用。
PolicyPak Remote Work Delivery Manager 并非旨在在所有情况下都必然取代 MEMCM、Intune 或 PDQ deploy 等软件。但如果你的需求只是适度地部署软件，并保持其自动更新，那么 PolicyPak Remote Work Delivery Manager 可以在许多情况下使用 SMB 或基于 Web 的共享来提供这类能力。
例如，首次部署 7Zip 时，请将源指向你希望作为起点使用的任意版本。在这个案例中，我已将 7Zip 版本 16 的安装程序重命名为 7z.msi，如图 8 所示。
图 8：使用 PolicyPak Remote Work Delivery Manager 策略部署 7Zip 的初始版本。
接着，7Zip 16 会如预期一样安装到终端设备上，如图 9 所示。
图 9：从 PolicyPak Remote Work Delivery Manager 策略安装 7Zip；通过从 SMB 或基于 Web 的共享下载软件。
接下来，要在底层共享上将 7Zip 16 更新并打补丁到 19，只需用最新版本（17、18、19 等）替换底层的 7z.msi。PolicyPak 会自动连接到源，发现存在新版本后，拉取已更新的补丁并自动完成更新。不需要额外的时间，也不需要重新部署到任何控制台。通过在 PolicyPak Remote Work Delivery Manager 中执行这些步骤，更新就会“神奇”地发生。在将 7z.msi 版本 16 交换为 19 之后的最终结果如图 10 所示。
图 10：PolicyPak Remote Work Delivery Manager 无需重新部署或用户交互，即可自动更新软件。
除了复制文件并运行进程以完成安装之外，PolicyPak Remote Work Delivery Manager 还解决了本文其他软件未尝试解决的几个额外挑战。例如，PolicyPak Remote Work Delivery Manager 具有一种特殊功能，与广受欢迎的 Windows 10 工具 Robocopy 非常相似。也就是说，它让你能够指定以下内容：源位置以及要复制的文件、目录深度（包括递归目录）以及无数种筛选条件（大小、日期、上次修改时间等）。我们前面提到的其他工具都没有在尝试处理这些问题。
PolicyPak Remote Work Delivery Manager 还允许管理员指定一个归档文件（.ZIP 文件）。该 .ZIP 文件可自动下载并为终端用户解压。如果源 .ZIP 文件内容已更新，PolicyPak Remote Work Delivery Manager 会自动保持目标文件的最新状态；无需额外的策略或交互。
PolicyPak Remote Work Delivery Manager 是 PolicyPak 客户一次性部署文件和软件，并在企业网络内外的 Windows 10 设备上保持其持续更新的最有效方式。
PolicyPak Scripts Manager
PolicyPak Scripts Manager 是使用 PolicyPak 部署软件的另一种方式。PolicyPak Scripts Manager 将运行您选择的脚本。该脚本可能是复制文件的操作，或从任意来源下载某些内容。然后在文件复制完成后，您可以运行安装流程或脚本，这与 PolicyPak Remote Work Delivery Manager 在下载任务完成后运行安装流程或脚本的方式类似。
您可以在图 11 中简要了解我们如何做到这一点。
图 11：从供应商的下载源执行 Evergreen 脚本化安装。
话虽如此，PolicyPak Scripts Manager 不具备 PolicyPak Remote Work Delivery Manager 的内置能力。PolicyPak Scripts Manager 不会使用 BITS 来智能传输大文件，也不具备复杂的筛选器，或执行复杂的、递归的、经过筛选的、类似“Robocopy”的操作的能力。
但是，如果您想运行脚本，从互联网上已存在的分发源安装软件，那么 PolicyPak Scripts Manager 可能正是您需要的。我们最喜欢使用 PolicyPak Scripts Manager 的方式之一，是编写脚本来安装来自 Chocolaty.org 的预先创建好的软件包。另一个使用 PolicyPak Scripts Manager 部署软件的方法，是通过 Evergreen 脚本来实现：这些脚本会直接指向软件供应商的源并直接执行安装。对于较短的下载这种情况，这种方式很合适，但当安装程序较大，或计算机存在中途停止并重新开始传输的风险时，可能并不理想。（这正是 PolicyPak Remote Work Delivery Manager 能提供帮助的地方，因为它使用 BITS 协议。）
软件交付情况报告
PolicyPak Remote Work Delivery Manager 和 PolicyPak Scripts Manager 可与您已在使用的报告引擎集成，用于确定您的设置是否已落地生效。
- 对于 PolicyPak Group Policy Edition，您可以使用 Group Policy Management 控制台的组策略结果报告，或使用 PolicyPak 的（免费）PolicyPak Group Policy Compliance Reporter。
- 对于 PolicyPak MDM Edition，您可以利用 MDM 的报告。
- 对于 PolicyPak Cloud Edition，您可以利用 PolicyPak Cloud 报告系统。
话虽如此，上述任何一份报告都只能告诉你：用于交付软件（或保持其为最新版本）的策略是否已被处理。报告系统无法得知任何特定软件的实际安装状态（成功或失败）。如果你关心的是包含返回结果代码的深度报告，那么你可能需要本列表中的其他工具，例如 PDQ Deploy。
下一步
没有一款工具能够满足所有公司所有的软件部署需求。在本概览中，我们希望分享每种工具适用的场景，以确保没有任何软件被遗漏而无法部署，并且所有需求都能得到满足。PolicyPak Scripts Manager 和 PolicyPak Remote Work Delivery Manager 随 PolicyPak 的所有版本提供。我们认为你可以在很大程度上使用它们来满足软件部署需求，或在你已有的方案基础上进行增强。
分享到
了解更多
关于作者
Jeremy Moskowitz
产品管理副总裁（端点产品）
Jeremy Moskowitz 是计算机与网络安全领域备受认可的专家。作为 PolicyPak Software 的联合创始人兼 CTO（现已成为 Netwrix 的一部分），他同时还是微软在组策略、企业移动性与 MDM 领域的前 20x MVP。Jeremy 撰写了多本畅销书，包括《Group Policy: Fundamentals, Security, and the Managed Desktop》和《MDM: Fundamentals, Security, and the Modern Desktop》。此外，他还是桌面设置管理等主题备受追捧的演讲嘉宾，并且是 MDMandGPanswers.com 的创办人。