Question

我们有一个应用程序安装在客户的位置。此应用程序包含作为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 ===

Answer 1

这是一个过于宽泛的问题，但这是我为其他客户设计的：

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

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

MSI必须正确设计并符合UAC标准。从安装UI到安装执行的转换将在没有UAC提示的情况下发生。只有正确安排（延迟不假冒）自定义操作才会升级。

一旦解决了所有类型，客户对他们的自动更新模式非常满意。

Answer 2

也许你需要调查另一个角落：

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

从服务运行时，Windows Installer始终失败，错误1601或1603

2 个答案: