I have created an update to a previously distributed package. There are no file changes in this case but there is the addition of two custom tables and a custom action.
My issue is that I had to remove two components from a feature and as such I am required to change the product code (according to the MS SDK). The details are below:
1) Changed GUID in Summary Info Stream
2) Changed Product Code GUID
3) Added DLL in binary table and relevant custom action entries
4) Removed two components and file table entries required for fix.
5) Incremented Product Version from 1.0.0 to 1.1.0 (tried 2.0.0 also)
6) Added upgrade table and correct entries.
As an MSI the package utilises the Upgrade table and the changes are implemented and everything works fine. I am aware that this causes issues due to the how the Installer tracks components in the Registry.
When an MSP is generated (using the 1.2 SDK) the following problems exist:
When the patch is applied to a local install –
The patch applies but when the application is run the install is broken.
When the patch is applied to an admin install –
The patch applies but when an install is run “The System Administrator has set policies to prevent this installation” appears and the install exits.
I have checked about 19 policy settings regarding the MSI environment in Windows 2000 and have been unable to find one that may affect this.
We currently have: AllowLockdownPatch and AlwaysInstallElevated set to 1.
Another thing I have noticed with Patching in general is that if the application is installed elevated (as all ours do) and the above settings are set you can run:
MSIEXEC /P <MSP> and the minor patch will apply
However users are unable to run: MSIEXEC /I <Patched Admin MSI> REINSTALL=ALL REINSTALLMODE=vomus due to the policy restriction error. Which appears to be a much better method.
Thanks in Advance for any feed back. It’s greatly appreciated!
Adam