Windows – msiexec /p (for patching) – won’t update after another change

microsoft-officemsiwindows

I have a .msp file that is made by the Office 2007 Customization tool.

If I create the .msp file and apply it to a machine it works. But if I modify that machine's office install again and then try and run the .msp file against that computer again it doesn't install the .msp file (it runs but nothing changes).

If I go back into the OCT tool and resave the .msp file again and rerun it on the computer it then runs again.

So my guess is some kind of sequencing number or similar, but is there any way I can simply force the .msp file to change the existing install regardless of the sequence number or whatever is preventing it from working?

When looking at the msiexec verbose logging I get things like "expected product ID ### but found product ID ###" which leads me to believe it is sequencing something.

Steps to recreate issue:

  1. USE OCT tool to create custom Office 2k7 install (setup.exe /admin)
  2. Deploy custom Office 2k7 install to an XP sp2 machine with nothing else on it (setup.exe /adminfile custom.msp)
  3. NOW…there is a .NET Programmability support part of the Infopath setup that won't get installed because it requires .NET 2.0 or higher on the desktop computer.
  4. Install .NET 2.0 or higher on client
  5. Create new "maintenance patch" for .NET Programmability support (setup.exe /admin) only.
  6. Run new patch on client computer (msiexec /p newpatch.msp)
  7. Verify in Add/remove programs, Office 2007, that Infopath sub-menu now shows .NET Programmability support (which it should).
  8. Modify the Office install in add/remove programs…remove the .NET programmability support choice and continue…this will remove the feature AGAIN.
  9. Try and re-run the "msiexec /mp newpatch.msp"…it acts like it runs but doesn't actually install anything.

Steps 8-9 are the easiest way to recreate the actual problem…if you are asking "why are you doing this" it's because other patches like WSUS security patches, etc. also end up making the newpatch.msp worthless because they bump the new sequence # past the newpatch.msp time/date stamp sequence number.

Best Answer

After working with Microsoft on this issue the only decent solution was the following:

Pranav, from our Install team, informed me that he was able to figure out the issue. He explained to me that you wouldn’t be able to install with an msp, remove office, and then reinstall with the same msp when modifying the ‘.NET programmability support’ feature under ‘InfoPath’.
Apparently the issue can be resolved by creating a new msp with the same settings as your original msp.

This appears to be the only workaround for the issue of other Office updates causing the .msp file to fail as well.

So, we decided to do the following:

  1. Create the .msp patch and deploy it via a computer startup script
  2. "Re-save" the .msp patch once a day for 2 weeks while deploying to make sure it takes affect on the client computers
  3. In the script the client computers will "report back" to a central log file (append it) with their computer name and a yes/no response.
  4. After 2 weeks we'll use the "no" responses we get back to go manually hit those machines and fix them.

It's sucky, but it'll have to do. We'll update our base computer image for the future so we don't have to deal with this again.

Related Topic