我有一个由Office 2007自定义工具生成的.msp文件。
如果我创build.msp文件并将其应用于其工作的机器。 但是，如果我再次修改该机器的办公室安装，然后再次尝试运行.msp文件对该计算机再次它不会安装.msp文件（它运行，但没有任何更改）。
如果我回到OCT工具并再次重新保存.msp文件，然后在计算机上重新运行它，然后再次运行。
所以我的猜测是某种序列号或类似的，但有什么办法可以简单地强制.msp文件来改变现有的安装，无论序列号或任何阻止它的工作？
当看到msiexec详细日志logging时，我得到了“预期的产品ID ###，但发现产品ID ###”，这使我相信它正在sorting的东西。
重新创build问题的步骤：
步骤8-9是重新创build实际问题的最简单的方法…如果您问“为什么要这样做”，这是因为其他补丁，如WSUS安全补丁程序等最终也使得newpatch.msp变得毫无价值，因为它们碰撞新序列＃超过newpatch.msp时间/date戳记序列号。
在与微软就此问题合作之后，唯一合适的解决scheme如下：
Pranav，来自我们的安装团队，告诉我他已经能够找出问题了。 他向我解释说，在修改“InfoPath”下的“.NET可编程性支持”function时，您将无法安装msp，删除office，然后使用相同的msp重新安装。
显然这个问题可以通过创build一个与原始msp相同的新的msp来解决。
这似乎是解决其他Office更新导致.msp文件失败的问题的唯一解决方法。
所以，我们决定做以下事情：
这很糟糕，但它必须做的。 我们将更新我们的基本计算机图像的未来，所以我们不必再处理这个。