Product not installed when using msiexec /forcerestart

[jsmith]

Hello. I'm having problems silently installing an MSI created by the Group Policy Wizard when I attempt to use the /forcerestart option. If I leave out /forcerestart, it works fine and my product is installed correctly. But when I include /forcerestart, the computer is restarted before my produce is actually installed. Here is the command I am using to install:

Code: Select all

msiexec.exe /quiet /forcerestart /L*v C:\setup.log /i MyInstaller.msi

If I watch the task manager when this is running, I see two instances of msiexec.exe running, then I see a GUID-named application run for a short while, then the computer reboots. After the reboot, my application is not installed. This is in contradiction to what is reported in the setup.log file as well as in the Application Event Log: "Product: My Product -- Installation completed successfully."

It is worth noting that when I leave off the /forcerestart option, after the GUID-named application runs I then see MyInstaller.exe (the IA-based installer that's wrapped up inside the GP MSI) run for a while. Once MyInstaller.exe completes, my product is installed. In the scenario where I provide the /forcerestart option, I never see MyInstaller.exe run. The computer reboots after the GUID-named application runs for a short while and after the reboot nothing is installed.

Am I doing something wrong?

[MichaelNesmith]

What's happening is that the GP generated wrapper MSI is rebooting your computer right after spawning the actual setup (and the actual MSI containing your payload). Therefore, the computer restarts before your actual setup has had a chance to complete.

You should instead script a forced reboot inside your setup package, possibly based on a script based evaluation of your environmental conditions (such as command line parameters contained in the CMDLINE pre-defined script variable). You could, for example, force reboots in your script only when the GP generated MSI wrapper is being used by testing for the equivalence of the GPOPATH pre-defined script variable to non-null).

[jsmith]

What's happening is that the GP generated wrapper MSI is rebooting your computer right after spawning the actual setup (and the actual MSI containing your payload). Therefore, the computer restarts before your actual setup has had a chance to complete.

Am I understanding correctly, then, that the standard msiexec functionality (the "forcerestart" option) does not work correctly with GP-generated MSI files?

You should instead script a forced reboot inside your setup package, possibly based on a script based evaluation of your environmental conditions (such as command line parameters contained in the CMDLINE pre-defined script variable).

I can see how that would work, by having the user force a reboot by running a command such as:

Code: Select all

msiexec.exe /quiet /i MyInstaller.msi CMDLINE='REBOOTCOMPUTER=TRUE'

However, doing so would wipe out the values that the Group Policy Wizard added to the CMDLINE property, as spelled out in this thread. Please let me know if there is no way to make "msiexec /forcerestart" work correctly, as I will then schedule development time to work around this. Thanks.

[MichaelNesmith]

The MSI created by the Group Policy Wizard is intended for use with Group Policy deployment. If you are distributing these MSI's stand alone, a lot of MSI command line switches will have no effect and confuse end-users because they will be applied to the external wrapper MSI only, and not the actual MSI containing your setup payload which actually installs your application. As I've already written, the correct place to customize your setup is inside your MSIcode script. The correct place to specify setup command line parameters is not msiexec.exe but your own setup.exe.

[jsmith]

The MSI created by the Group Policy Wizard is intended for use with Group Policy deployment. If you are distributing these MSI's stand alone, a lot of MSI command line switches will have no effect and confuse end-users...

My understanding is that it used to be true in older versions of IA that the GP MSI was only for GP deployment, but this no longer the case. In fact, according to the InstallAware 7 Reviewer's Guide:

The Group Policy Wizard also permits customizing the command line passed to the embedded InstallAware setup, either by hard-coding a command line in the wizard itself, or by setting the public CMDLINE property of the outer MSI at deployment time on end-user systems. Therefore a single MSI file can be made available for use by both end-users and in corporate deployment scenarios using the Group Policy Wizard.

It is also discussed in this forum thread, with the end result being that you can use the MSI for both types of deployment as of IA8. I'm using IA9. The reviewer's guide is for v7. Is it no longer true that the a single MSI file can be made available for use by end-users?

I can alter my MSIcode script to watch for flags from the CMDLINE to signify a forced reboot as you are suggesting, but doing so would work well only with the .exe installer and not with the .msi installer because of the issue mentioned here. Our business need is to have one installer file for all of our end users to use, regardless of how they deploy. Therefore, we need to provide the .msi version so it can be deployed through Group Policy, can be installed manually, using the GUI, or by running msiexec.

[MichaelNesmith]

You certainly can use the GP MSI for everything - but like I said, your users might be confused at some of its behavior if they don't understand the internal MSI payload.