1

我们有一个安装在客户位置的应用程序。此应用程序由作为 Windows 服务运行的自承载 WCF 服务器以及与此问题无关的客户端应用程序组成。

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

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

问题是，在几乎呼叫客户的站点上，这个自动化过程失败了，尽管与所有事情一样，它在我们所在地的测试和生产中都有效。有时它会在卸载过程中失败，但通常是在安装过程中。错误代码 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 ===
4

2 回答 2

1

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

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

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

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

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

于 2013-03-08T18:59:39.210 回答
0

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

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

于 2013-04-08T08:26:11.473 回答