I'd add to the Process Explorer/Process Monitor suggestion - run FileMon and RegMon from Sysinternals too. You can filter/save a log of the msiexec and related processes, export to a csv and have a complete list of actions to the file system and registry. Compare/contrast with what has been written to the Windows Installer log, too.
You can also have a look at what Scott Willeke's Less Msiérables (LessMSI) can do for you ...
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:
Create the .msp patch and deploy it via a computer startup script
"Re-save" the .msp patch once a day for 2 weeks while deploying to make sure it takes affect on the client computers
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.
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.
Best Answer
http://technet.microsoft.com/en-us/library/cc759262%28WS.10%29.aspx