"The system administrator has set policies that prevent this installation." -- nested

[Peter_Kosenko]

"The system administrator has set policies that prevent this installation." -- nested Major Upgrade

Okay, I hate to admit this, but our developers are always asking for installer workarounds for things they don't fix. Quite a few Help topics in our application .HLP files use volatile index strings rather than fixed IDs. That means that help often needs to be updated to reflect the volatile strings. That was okay when the updates were internal to a .HLP file. However, to support Vista, Help is being converted to to HTML, and FILE NAMES are being based on the volatile index strings. That means that between one version of help and another, a good number of .HTML file may end up defunct and replaced by newer file names. Not good, of course. It means that HTML help is NOT STABLE.

To try to accomodate this, I attempted the now deprecated use of a nested HTMLHelp.msi that would remove and reinstall HTML help for every update of the major installer in which it is included. The first installation works, but the Major Upgrade configured into the nested HTML help installer gives the error:

"The system administrator has set policies that prevent this
installation." (running the nested .MSI in Major Upgrade mode)

I have seen this message all over the community site for earlier versions of InstallShield, but nothing for InstallShield 2008.

I have not seen an adequate explantation of why the error should occur during Major Upgrade of a nested install but not during the original installation of the nested installation.

Some people suggest that the installation is not actually uninstalling the encrypted ProductCode and PackageCode.

But why should a NESTED installation (complete package in itself) have that problem? Shouldn't it run as its own install and simply return when finished?

[Stefan_Krueger]

So your main setup would launch a nested install action for the new HTML files which in turn should launch the old HTML file setup for uninstall as Major Upgrade? This may just be one level too much of nesting. Also I'm not sure if you can actually uninstall a apckage that was installed as nested install custom action without uninstalling its parent.

I would try to avoid nested install custom actions.

One clean solution would be a Major Upgrade of the whole package.

Aonther option would be adding the new HTML files as new components, leaving in the setup the old HTML component (files replaced with 1 byte dummies) with a component condition of 0 and "re-evaluate condition" set to true. This should work as Minor Update.

[Peter_Kosenko]

I have thought about that, too. Just keep adding big fat components with all the HTML file so that our sixth upgrade has six sets of HTML help files times the four .HLP file that are being converted to HTML, for each update of the help. It's a possibility. Big fat installers have been known to exist.

I'm suffering from the flu. I was out yesterday writhing in bed. The problem with the installation of the nested installer seems to be that I didn't change the ProductID when I instituted major upgrade for the HTMLHelp subinstaller.

I have a method of sending REMOVE=[REMOVE] on the command line that removes the HTML help when REMOVE="ALL".

Stefan Krueger wrote:
So your main setup would launch a nested install action for the new HTML files which in turn should launch the old HTML file setup for uninstall as Major Upgrade? This may just be one level too much of nesting. Also I'm not sure if you can actually uninstall a apckage that was installed as nested install custom action without uninstalling its parent.

I would try to avoid nested install custom actions.

One clean solution would be a Major Upgrade of the whole package.

Aonther option would be adding the new HTML files as new components, leaving in the setup the old HTML component (files replaced with 1 byte dummies) with a component condition of 0 and "re-evaluate condition" set to true. This should work as Minor Update.

[Stefan_Krueger]

Just keep adding big fat components with all the HTML file so that our sixth upgrade has six sets of HTML help files

No, you would just have one set of HTML files (the latest version) and replace the old versions with 0 byte (or 1 byte) dummies.

[Peter_Kosenko]

It seems that when you set a nested installer to major upgrade, the enclosing installer also wants to be set to major upgrade. Don't know why, but when I tried doing minor upgrade with a major upgrade nested HTML help subinstaller, the IDE complained that I needed to set the main installer to Major Upgrade. But that was what I was trying to avoid in the first place.

So back to the drawing board. Something closer to your suggestion, or maybe your suggestion itself, seems to be the only way to go.

I thought of starting with one component with all of the first fresh files, then adding a new component with any new files for upgrade, then scheduling any outdated files (there won't be a lot, I am TOLD) to be deleted using the RemoveFiles table during upgrade. But I won't be sure if that will work until I test it.