从服务运行时，Windows 安装程序总是失败并出现错误 1601 或 1603答案

【问题标题】：Windows Installer always fails with error 1601 or 1603 when run from a service从服务运行时，Windows 安装程序总是失败并出现错误 1601 或 1603
【发布时间】：2013-03-08 16:20:27
【问题描述】：

我们有一个安装在客户位置的应用程序。此应用程序包含一个作为 Windows 服务运行的自托管 WCF 服务器，以及一个与此问题无关的客户端应用程序。

我们通过让服务在后台下载我们由 WiX 生成的 .msi 文件来向客户发布更新，然后在客户选择安装它时进行安装。安装过程如下：

服务器将引导程序应用程序复制到临时路径并运行它，将路径传递给要安装的 MSI 文件
引导程序使用 MSI 文件中的升级代码卸载以前的版本，然后安装新版本。它使用与 MSI 相关的各种 P/Invoke 调用来调用安装程序，例如 MsiInstallProduct。
引导程序重新启动服务

问题在于，在几乎呼叫客户的站点上，这个自动化过程失败了，尽管与所有事情一样，它在我们所在地的测试和生产中都有效。有时它在卸载过程中会失败，但通常是在安装过程中。错误代码 1601 (InstallServiceFailure) 和 1603 (InstallFailure) 很常见，因为它们完全无助于确定问题所在。

我们有一个备份程序，用户可以通过在 Windows 中运行引导程序来手动调用安装程序（当然，需要以管理员身份运行）。此过程不会失败，并且它使用与失败的自动化过程完全相同的安装逻辑。

所有服务都作为帐户运行，至少在服务器上具有管理权限。

我可以从哪里开始尝试查找有关导致错误的原因的更多信息，或者更好地从一开始就阻止它们？

编辑以下是安装失败的详细日志文件的一个示例：

=== Verbose logging started: 3/29/2013  8:23:30  Build type: SHIP UNICODE 5.00.7600.00  Calling process: <<PATH TO MSI>> ===
MSI (c) (00:7C) [08:23:30:194]: Resetting cached policy values
MSI (c) (00:7C) [08:23:30:262]: Machine policy value 'Debug' is 0
MSI (c) (00:7C) [08:23:30:418]: ******* RunEngine:
           ******* Product: <<PATH TO MSI>>
           ******* Action: 
           ******* CommandLine: **********
MSI (c) (00:7C) [08:23:30:491]: Client-side and UI is none or basic: Running entire install on the server.
MSI (c) (00:7C) [08:23:30:520]: Grabbed execution mutex.
MSI (c) (00:7C) [08:23:30:562]: Failed to connect to server. Error: 0x800703FA

MSI (c) (00:7C) [08:23:30:605]: Failed to connect to server.
MSI (c) (00:7C) [08:23:30:637]: MainEngineThread is returning 1601
=== Verbose logging stopped: 3/29/2013  8:23:30 ===

【问题讨论】：

检查详细日志文件。有很多关于 Windows Installer 在服务下无法正常运行的报告，但具体情况各不相同。
@RobMensching：谢谢。为了清楚起见，该服务启动了第二个运行安装程序进程的可执行文件。因此，当它在服务的会话中运行时，它不在同一个进程中运行。
我看到的大多数安装都失败了，因为 SYSTEM 是由于 IS12 之前 InstallShield 的 DCOM 故障。还有一些细微的区别，例如 USERDNSDOMAIN 等环境变量不是 SYSTEM 配置文件的一部分。您确实需要记录安装程序才能知道失败的原因。
@Adam Robinson，我明白，但你会得到不同的用户资料和各种东西。日志文件应该有一些更具体的信息。
@ChristopherPainter：此服务始终作为域或本地帐户运行，而不是作为 SYSTEM。根据 Rob 和您的好建议，我将尝试启用详细日志记录。

标签： wix windows-installer

【解决方案1】：

这个问题太宽泛了，无法回答，但这是我为其他客户设计的：

1) 提升的服务将 MSI 下载到本地目录并使用命令 msiexec /jm foo.msi “广告”（祝福）MSI

2) 非提升客户端组件然后使用命令 msiexec /I foo.msi 安装 MSI

MSI 必须设计合理且符合 UAC。从 Install UI 到 Install Execute 的转换将在没有 UAC 提示的情况下发生。只有正确安排（延迟而不模拟）自定义操作才会提升。

解决所有问题后，客户对他们的自动更新模式非常满意。

【讨论】：

谢谢，我意识到这个问题非常广泛，我正在推出一个更新（呵呵），它将引入详细的日志记录。不幸的是，客户端组件正在另一台机器上运行，并通过 WCF 连接到服务器。服务器计算机打算完全无需干预，因此直接在服务器计算机上运行需要用户干预的操作与设计背道而驰。
客户端是为了让用户可以得到升级正在进行的反馈。您不应该将提升的进程暴露给非提升的桌面 UI。
顺便说一句，我想你误解了我的意思。我没有提到在服务器计算机上运行手动步骤。
当我看到“客户端”时，我以为你的意思是面向用户的。
给我发一封电子邮件，如果您愿意，我们会详细讨论。

【解决方案2】：

也许你需要看看另一个角落：

当我过去遇到奇怪的安装问题时，它们通常是由行为分析工具导致的，这些工具意外地阻止了他们不应该拥有的东西。如果某些此类工具（可能是病毒扫描程序套件的一部分或诸如 ThreatFire 等独立应用程序的一部分）安装在相关计算机上，请确保您的更新过程所需的任何部件均未在任何地方列为“已阻止”。如果您的更新执行导致行为分析组件自动处理的操作，请确保将它们可靠地列入白名单。

【讨论】：