许多企业依靠 SCCM(Microsoft Configuration Manager)向其 Windows 设备交付应用,无论这些设备位于本地还是远程。不过,SCCM 应用部署的可靠性取决于其背后的部署套件和规则。
如果静默安装参数不正确、检测规则与应用不匹配,或者返回代码未映射,那么成功安装也可能被报告为失败(反之亦然)。这一点如今尤为重要,因为 Microsoft 已发布 Configuration Manager version 2609,这是改为每年一次发布节奏后的首个版本。继续使用 SCCM 的团队需要能够借助其现有功能可靠运行的应用交付方式。
考虑到这一点,我们来看看 SCCM 应用程序打包、如何准备和部署应用程序,以及检测方法和返回代码如何决定 SCCM 报告的内容。
什么是 SCCM 中的应用程序打包?
应用程序打包是指在 SCCM 介入之前,为应用程序所做的准备工作。这包括设置安装和卸载命令、启用静默安装、添加配置,以及确定如何验证安装。如需更全面的概述,请参阅什么是应用程序打包。
然后,SCCM 会部署已准备好的应用程序。它会将其存储为一个包含一种或多种部署类型的应用程序,将内容复制到分发点,并根据您提供的文件和规则告知客户端何时以及如何安装。
请记住,SCCM 只能强制执行您赋予它的内容。因此,提前根据需要的规则和设置正确准备应用程序非常重要,因为安装的可靠性很大程度上在“创建应用程序”向导打开之前就已经决定了。
SCCM 中的应用程序 vs 程序包和程序
这些术语满天飞,难免让人有点混淆:当我们提到 applications、packages 和 programs 时,具体指的到底是什么?我们可以这样拆解它们之间的区别:
属性 | 应用程序 | 包和程序 |
知道应用是否已安装 | 是,通过一种检测方法 | 无检测方法 |
多种安装 方法 | 是,根据要求选择一种或多种部署类型 | 每个程序一行命令行 |
依赖项和取代关系 | 支持 | 先运行另一个程序 |
适用场景 | 安装、更新并保持合规的软件 | 管理工具、一次性脚本、定期运行的脚本 |
鉴于这些差异,Microsoft 建议将包和程序用于不安装应用的工具、一次性脚本以及重复运行的脚本。对于需要安装并保持最新的软件,应用程序是更合适的选择。如果您有较旧的包,Package Conversion Manager 可以将其转换为应用程序。
如何为 SCCM 打包应用程序
在为 SCCM 打包应用程序时,有几个关键步骤需要遵循。包含正确安装所需的所有命令、包装器和规则,有助于确保顺利部署;但如果遗漏某一步,可能会导致安装或报告问题。
确定安装程序类型:这可能是 MSI、安装程序 EXE,或者封装 MSI 的 EXE;无论是哪一种,都会影响后续的所有步骤。我们的MSI 与 EXE 安装程序指南说明了如何区分它们。
查找静默安装和卸载命令:查找这些命令的方式因安装程序类型而异。每个 MSI 使用的开关都相同,而 EXE 开关取决于用于构建安装程序的工具。请参阅我们的msiexec 静默安装指南和EXE 静 默安装指南。
决定是否进行封装:如果安装程序有需要,可使用 PowerShell App Deployment Toolkit(PSADT)封装器来添加关闭应用提示、延期选项以及一致的日志记录。我们的PSADT 指南介绍了该工具包的工作原理。
建立一个干净的源文件夹:创建基于 MSI 的应用程序时,SCCM 会导入该文件夹中的每个文件并将其发送到分发点,因此请确保文件夹中只包含安装所需的内容。Microsoft 对 SCCM 的测试支持每个应用程序最多 20,000 个文件。
记录可证明应用已安装的内容:需要有某种信号表明应用已安装,例如 MSI 产品代码、带版本的文件或注册表值。这将成为用于验证各终端安装情况的检测方法。
在干净的机器上以 SYSTEM 身份测试该命令:在跨设备部署之前测试安装和卸载,对于提前发现问题、防止其演变成更大麻烦至关重要。请记住,应用如果能在系统上下文中使用给定的命令行进行安装,通常也可以通过 SCCM 安装。
SCCM 应用程序部署分步指南
为 SCCM 打包应用程序是第一步,但随后还需要进行部署。部署应用也需要几个步骤,但一旦熟悉之后,流程就会变得很直接:
创建应用程序:可前往 Software Library,然后依次进入 Application Management → Applications,并选择 Create Application。对于 MSI,可以让 SCCM 读取该文件。另一方面,对于 setup EXE 或 PSADT wrapper,则需要选择 Script Installer 并手动输入详细信息。
设置部署类型内容: 在此步骤中,需要输入安装和卸载命令;如果应用支持,还需输入修复命令。请确保将 内容位置指向干净的源文件夹。
添加检测方法:检测方法可以包括基于规则的检测或脚本检测,用于查找能够表明应用已成功安装的特定指示项。应使用哪种具体检测方法会因应用而异。
设置用户体验:这包括多种设置,例如是为系统还是用户安装、登录要求、程序可见性(静默安装时建议使用“隐藏”)以及最长运行时间。
添加要求和依赖项:要求决定哪些设备获得哪种部署类型,而依赖链最多支持五个层级。
分发内容:将所有内容发送到分发点或分发点组,以便传送到目标设备。
部署到集合:选择“安装”,然后选择“可用”(这样用户就可以从 Software Center 安装)或“必需”(系统会在截止时间前自动安装)。别忘了设置可用时间和截止时间,以确保在预期时间范围内部署完成。
在全面推出前先测试:在部署应用之前,先在试点组中运行模拟部署,以测试检测、要求和依赖关系,而无需实际安装。如果一切检查无误,就可以使用分阶段部署,按照成功标准分批推出。
密切关注部署情况:前往“监控 → 部署”监控 rollout,并检查结果,确保一切都按预期运行,然后再部署到更大范围的设备组。
请注意,SCCM 会自动将卸载部署设为“必需”,而且无法更改。对于在截止时间时处于关机状态的设备,您可以选择通过宽限期延迟强制执行,宽限期可设置为 1 到 120 小时;该设置需在客户端设置中配置,然后为每个部署启用。
SCCM 检测方法的工作原理
检测是 SCCM 确认某个应用程序是否已安装的方式。SCCM 客户端会在安装任何内容之前先检查应用是否存在的标志,这样就不会重新安装已经存在的应用,并在安装后再次检查以确认安装是否成功。检测方法有两种形式:
基于规则的检测
在基于规则的检测中,SCCM 客户端会检查文件系统(文件或文件夹)、注册表(键或值)或 Windows Installer 产品代码。如果满足规则,SCCM 就会认为该应用已安装。
可以用“And”或“Or”组合多个子句,并将它们分组,以实现更复杂的逻辑。无论使用哪一种,都要让规则查找每个版本都会变化的内容,例如产品代码或文件版本,这样旧版本安装才不会被报告为当前版本。
脚本检测
脚本检测允许使用 PowerShell、VBScript 或 JScript(最多 32 KB)编写检查逻辑。SCCM 会同时读取脚本的退出代码及其输出:只有当脚本以 0 退出并向 STDOUT 写入内容时,应用才会被视为已安装。退出代码为 0 但没有输出表示未安装,任何非零退出代码都会使状态保持未知。在实践中,仅在找到应用时才写入输出,并始终以 0 退出。
退出代码 | STDOUT | STDERR | 检测状态 |
0 | 有输出 | 任意 | 已安装 |
0 | 空 | 空 | 未安装 |
0 | 空 | 有输出 | 未知 |
非零 | 任意 | 任意 | 未知 |
检测运行时
SCCM 会在安装应用程序前检查检测规则,然后在安装完成后立即再次检查。如果安装后未找到该应用,SCCM 会报告错误 0x87D00324,即使软件其实已经在设备上。下方的故障排除部分介绍了如何修复这个问题。
SCCM 返回码和重启行为
安装程序完成后会返回一个退出代码,SCCM 则使用部署类型的返回代码列表来判断安装是成功、需要重启,还是应当重试。了解这些代码也有助于 IT 团队解读结果并进行故障排除。
这些代码可能表示:
成功(无需重启):应用程序已成功安装,且无需重启。
失败(无需重启):应用程序安装失败。
硬重启:应用程序已安装,但设备需要重启才能完成安装。重启完成之前,其他任何内容都不会安装。
软重启:应用程序已安装,设备需要重启。与此同时,其他安装可以继续进行。
快速重试:当前有另一个安装正在进行,因此此安装必须等待其完成。客户端将每两小时重试一次,最多重试 10 次
创建部署类型时,SCCM 会添加这些默认返回代码:
错误代码 | Windows Installer (MSI) | 脚本安装程序 |
0 | 成功 | 成功 |
1707 | 成功 | 未添加 |
3010 | 软重启 | 软重启 |
1641 | 硬重启 | 硬重启 |
1618 | 快速重试 | 快速重试 |
除非手动添加,否则任何其他非零代码都会被视为失败。例如,如果安装程序在成功时返回的是 1 而不是 0,请将 1 添加为“成功(无需重启)”,这样 SCCM 才能正确识别。
封装的安装程序也需要映射其代码。当用户推迟 PSADT 安装时,工具包会返回其延期代码,默认为 1602。将其更改为 1618,或将 1602 添加为 Fast Retry 代码,这样 SCCM 就会再次尝试,而不是记录为失败。我们的 PSADT 指南 更详细地介绍了延期功能。
别忘了:部署类型的安装后行为设置决定了是由 SCCM 重启设备、由安装程序重启设备,还是 完全不重启。
如何排查 SCCM 应用程序部署失败的问题
如果 SCCM 应用部署失败,也无需惊慌。只需进行一些故障排查,就能快速识别并缓解常见问题。
"安装完成后未检测到应用程序" (0x87D00324)
此错误表示安装已运行,但检测方法未找到该应用程序。在这种情况下,请检查 AppDiscovery.log 和 CIAgent.log,然后将检测规则与安装程序实际写入的内容进行比较。
"卸载完成后仍检测到应用程序" (0x87D00325)
此错误表示卸载已完成,但检测仍然发现该应用程序。检查 AppEnforce.log 以确认运行了哪个卸载命令,然后检查 AppDiscovery.log 以查看检测仍发现了什么,并将其与检测规则进行比较。
仅通过 SCCM 安装会失败
如果通过 SCCM 安装失败,请尝试在测试机器上以 SYSTEM 身份运行完全相同的命令,看看是否能在那里正常运行。还要检查静默开关,因为在无人提供输入的情况下,安装程序可能正在等待用户输入。
某些设备上始终无法启动部署
如果部署类型允许的最长运行时间长于设备的维护时段,部署将不会启动。为解决此问题,请缩短运行时间或延长维护窗口。
2026 年 SCCM 应用程序部署的发展现状
这让我们回到如今 SCCM 的现状。自 2026 年 10 月 26 日起,2609 版本 已向所有客户开放,适用于运行 2503 或更高版本的站点。这也是新发布节奏下的首个版本:Microsoft 现在每年只发布一次 SCCM 更新,重点关注安全性和稳定性,并表示新的创新将发生在 Intune 中。
许多团队还通过共同管理同时运行 SCCM 和 Intune。当客户端应用工作负载迁移到 Intune 后,从 Intune 部署的应用会显示在 Company Portal 中,而从 SCCM 部署的应用仍保留在 Software Center 中。
如果将应用迁移到 Intune,之前为 SCCM 所做的打包工作依然有价值。干净的静默安装、可靠的检测逻辑以及已映射的返回代码,都是 Intune Win32 应用所需的相同输入,不过您需要在 Intune 中重新进行设置,因为那里的工作方式略有不同(例如,每条手动检测规则都必须匹配)。我们的Intune Win32 Content Prep Tool 指南介绍了这部分内容。
Splashtop Agentic Packr 如何加快 SCCM 应用程序打包速度
正确打包应用程序至关重要,但这也可能是一项重复、耗时的手动任务。好在,如果有像 Splashtop Agentic Packr 这样的工具,就不必如此。
Agentic Packr 是一款由 AI 驱动的工具,可自动完成应用打包。它会读取安装程序,找出静默安装参数,编写检测规则和要求规则,并构建部署套件,无需手动编写脚本或具备打包专业知识。软件包基于 PSADT 构建,因此管理员可以根据需要打开、查看并调整它们。每个软件包都会在干净的虚拟机上完成验证、扫描和测试,并附带一份 QA 评分卡和执行日志,供 IT 管理员在部署应用程序前查看并批准。
一旦 Splashtop Agentic Packr 完成应用程序打包,就可以将其安装、更新和卸载操作打包在一起,通过 SCCM 部署,或在任何 Windows 机器上手动运行。此外,每当应用发布新版本时,Agentic Packr 都可以检测到并自动构建更新后的软件包,因此 IT 团队无需手动重新打包每个新版本。
一次打包应用,在 SCCM 中放心部署
SCCM 应用程序部署始于经过测试的软件包、准确的检测,以及清晰映射的返回代码。具备这些条件后,应用和更新就能送达需要它们的设备,而 SCCM 会报告实际发生了什么。
Splashtop Agentic Packr 可以承担大量前期准备工作,从查找静默安装开关到编写检测规则并测试每次构建,让 IT 团队减少打包时间,把更多精力放在管理实际部署上。
想了解 Splashtop Agentic Packr 如何高效且安全地帮助进行应用程序打包吗?立即全面了解。






