安装我公司软件包的客户在以管理员帐户运行时以静默方式安装软件包没有问题。软件和服务都正确安装并在安装后启动。但是 - 他们需要将此应用程序推送到特定组中的所有计算机。
他们使用的是 SCCM（我不知道版本），软件包是 InstallShield .exe 打包的 .msi。
当他们尝试使用 NT Authority\System 用户将软件包推送到他们的测试设备时，在包含的第 3 方软件包完成后，安装很快就会失败。错误日志显示这是一个 SDDL 错误 1943。知道为什么这会发生在 NTA\System 帐户上而不是给定机器的本地管理员帐户上吗？
我们使用的静默安装字符串是 setup.exe /s /v" /qn AgreeToLicense=Yes SetupType=Typical"
我不是开发人员，因此我无法直接访问软件中的任何代码，只是与客户合作的第 3 层技术支持。
听起来您的 MSI 正在使用 MsiLockPermissionsEx 表在其安装或配置的某些资源（文件、目录、服务或注册表项）上指定 SDDL 字符串。SDDL 字符串配置错误（不太可能在一个帐户而不是另一个帐户上工作）或目标目录/服务/注册表项上的 ACL 已损坏，这并非完全闻所未闻。
您可以尝试让客户将域帐户作为本地管理员部署到计算机，然后设置 SCCM 以使用此帐户运行程序包。我不建议这样做，因为它本身就有固有的安全风险。
恐怕这可能是您的开发人员（或创建 MSI 的人）需要与客户一起找出哪些资源有问题并进行诊断的问题。
抱歉，我无法提供进一步的帮助。
我想我找到了问题所在。在安装过程中，.msi 将文件写入桌面，以便读取正在安装的服务的配置设置。当我尝试调用系统用户进行安装时，我已经将文件（我相信客户也这样做了）写入了桌面。这似乎是一个 ACL 问题，涉及系统用户对本地用户桌面的读/写。当文件被删除时，我收到错误 1406，它无法写入键的值。在桌面上看，该文件也从未写入本地桌面。当文件已经存在时（例如以前的安装），我在原始帖子中收到错误。在这一点上，我正在将其作为 ACL 错误进行测试，并将我的发现通知开发人员。