msiexec /p（用于修补）- 另一次更改后不会更新

Question

我有一个由 Office 2007 自定义工具制作的 .msp 文件。

如果我创建 .msp 文件并将其应用到计算机，它就可以正常工作。但是，如果我再次修改该计算机的 office 安装，然后尝试再次在该计算机上运行 .msp 文件，它不会安装 .msp 文件（它运行但没有任何变化）。

如果我返回 OCT 工具并再次保存 .msp 文件并在计算机上重新运行它，它就会再次运行。

所以我的猜测是某种序列号或类似的东西，但有什么方法可以简单地强制 .msp 文件更改现有安装，而不管序列号或任何阻止它工作的东西？

当查看 msiexec 详细日志时，我看到诸如“预期产品 ID ### 但发现产品 ID ###”之类的内容，这让我相信它正在对某些东西进行排序。

重现问题的步骤：

1. 使用 OCT 工具创建自定义 Office 2k7 安装 (setup.exe /admin)
2. 将自定义 Office 2k7 安装部署到没有其他任何程序的 XP sp2 计算机上 (setup.exe /adminfile custom.msp)
3. 现在...Infopath 设置中有一个 .NET 可编程性支持部分，但它无法安装，因为它要求台式计算机上有 .NET 2.0 或更高版本。
4. 在客户端上安装 .NET 2.0 或更高版本
5. 仅为 .NET 可编程性支持 (setup.exe /admin) 创建新的“维护补丁”。
6. 在客户端计算机上运行新补丁（msiexec /p newpatch.msp）
7. 在添加/删除程序、Office 2007 中验证 Infopath 子菜单现在是否显示 .NET 可编程性支持（应该显示）。
8. 在添加/删除程序中修改 Office 安装...删除 .NET 可编程性支持选项并继续...这将再次删除该功能。
9. 尝试重新运行“msiexec /mp newpatch.msp”...它就像运行一样，但实际上并没有安装任何东西。

步骤 8-9 是重现实际问题的最简单方法......如果您问“为什么这样做”，那是因为其他补丁（如 WSUS 安全补丁等）最终也会使 newpatch.msp 变得毫无价值，因为它们将新的序列号推过了 newpatch.msp 时间/日期戳序列号。

Answer 1

在与 Microsoft 合作解决这个问题后，唯一可行的解​​决方案如下：

我们的安装团队的 Pranav 告诉我，他能够解决这个问题。他向我解释说，在修改“InfoPath”下的“.NET 可编程性支持”功能时，您将无法使用 msp 安装、删除 office，然后使用相同的 msp 重新安装。
显然，可以通过创建与原始 msp 具有相同设置的新 msp 来解决此问题。

这似乎是解决其他 Office 更新导致 .msp 文件失败问题的唯一方法。

因此，我们决定采取以下措施：

1. 创建 .msp 修补程序并通过计算机启动脚本进行部署
2. 部署期间每天“重新保存”一次 .msp 修补程序，持续 2 周，以确保其在客户端计算机上生效
3. 在脚本中，客户端计算机将向中央日志文件“报告”（附加）其计算机名称和是/否响应。
4. 两周后，我们将根据收到的“否”答复手动去检查这些机器并进行修复。

这很糟糕，但必须这样做。我们将更新基础计算机映像，以便将来不再需要处理此问题。