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