1

我有一个使用 WiX 工具集（3.10）在 64b 机器上开发的 32b MSI 安装程序。它已经在具有不同 Windows（7、8.1、10）的 32b 和 64b 平台上进行了测试，并且可以正常工作。

当我尝试通过Microsoft Intune安装我的 MSI 时，问题就开始了安装我的 MSI 时，问题就开始了。（与其他大规模部署工具配合使用效果很好） 执行全新安装时，会提示用户插入 MSI 文件（选择后，安装顺利，但这不是大规模部署的目的）。

我观察到，当我从使用 heat 工具收集的 MSI 文件中删除时，问题没有发生。命令是（通过 Visual Studio 传递）：

"$(WIX)\bin\heat.exe" dir "C:\SOURCE_PATH" -ke -scom -frag -srd -ag 
  -var var.Resources -cg ResourcesGroupId -dr INSTALLDIR_RES 
  -out "$(ProjectDir)Source\Fragments\HarvestedResources.wxs"

该组件组被添加到包含所有其他组件的主要功能中。

目标目录创建为：

<DirectoryRef Id='INSTALLDIR_RES'>
  <Component Id='cmp_ResDiR' Guid='{SOME_GUID}'>
    <CreateFolder />
    <RemoveFolder Id='INSTALLDIR_RES' On='uninstall' />
  </Component>
</DirectoryRef>

INSTALLDIR_RES 是位于 INSTALLDIR 下的同级路径。日志显示 ComponentRegistry 使用退出代码 1（成功）完成。

安装范围是每台机器，启用提升安装。安装期间使用的所有属性都标记为：

secure="yes" admin="yes"

并且在AdminProperties和SecureCustomProperties下可见（通过Orca检查）。不过，我不使用任何CustomAction来部署这些资源。

Intune如何影响我的 MSI？我错过了什么？

4

1 回答 1

1

该问题仅与 MS Intune 部分相关，heat.exe与文件收集完全无关。结果发现有两个问题：

  1. MSI 是使用 MS Intune 部署的，但没有向用户提供原始 MSI。在安装过程中，MSI 已复制到临时目录并在安装应用程序后删除。没关系，尽管在自我修复的情况下访问原始 MSI 很有帮助，这会导致第二个问题：
  2. 在某些机器上，在初始运行期间，MSI 正在启动自我修复程序。由于原始 MSI 在硬盘上不可用，因此提示用户手动选择 MSI，如第一篇文章中所述。感谢Stein Åsmul 对 MSI 中自我修复问题的精彩描述，我能够检测到根本原因（在用户特定路径中使用 regEntry 的主要可执行文件的广告快捷方式）并修复它。

作为总结：MS Intune 不会影响部署由heat.exe.

于 2017-08-22T10:22:23.470 回答