Installation NT授权\系统和；SDDL错误

安装my Companys软件包的客户在以管理员帐户运行时，以静默方式安装软件包没有问题。软件和服务均已正确安装并在安装后启动。但是，他们需要将此应用程序推送到特定组中的所有计算机

他们使用的是SCCM（我不知道版本），软件包是InstallShield.exe打包的.msi

当他们试图使用NT Authority\System用户将软件包推送到他们的测试设备时，安装会在包含的第三方软件包完成后不久失败。错误日志显示它是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错误进行测试，并将我的发现通知开发人员。

没问题，我将把此信息传递给开发人员，希望他们愿意与客户合作解决此问题。另一方面，我使用NT Authority\System帐户在我的个人测试机器上强制执行相同的错误。这会提供更多的见解吗。在这里，似乎客户ACL不应该受到责备，不知何故SDDL字符串是错误的。此外，安装程序正在将服务安装到处理通信的目标机器上。