This website uses cookies. By clicking Accept, you consent to the use of cookies. Click Here to learn more about how we use cookies.
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
- Revenera Community
- :
- InstallShield
- :
- InstallShield Forum
- :
- IS_PREREQ Property
Subscribe
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Subscribe
- Mute
- Printer Friendly Page
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Nov 05, 2008
12:26 PM
IS_PREREQ Property
What is this property...
Everytime I try to update my installation (minor upgrade)... it seems like this property is set to reboot -- and I don't know if that is correct -- especially considering that none of the prereqs are even getting run on the installation.
Everytime I try to update my installation (minor upgrade)... it seems like this property is set to reboot -- and I don't know if that is correct -- especially considering that none of the prereqs are even getting run on the installation.
(5) Replies
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Nov 06, 2008
01:02 PM
The IS_PREREQ property should be set to Reboot only upon restarting an installation after a feature prerequisite required a reboot; it's set in the registry, related to the RunOnce hookup, but can run if you are just re-running a setup that asked for a reboot and exited (even without an actual reboot). The property is used in the MSI to resume at a reasonable dialog.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Apr 19, 2010
08:44 PM
Hi Michael,
I'm resurrecting this ancient thread because I seem to be running into the same issue.
We have a product that installs 2 services (as well as other files). We found we were getting a reboot dialogue at the end of a minor upgrade.
After some early research, we saw we were encountering a files in use issue related to InstallValidate determining our services were in use even though they would later be stopped in StopServices. (As per http://community.flexerasoftware.com/showthread.php?p=452274.)
We implemented a heavy-handed approach to take this variable out of the equation, and added a custom action before InstallValidate that stops our services.
But still we got the reboot dialogue.
So we confirmed the following again:
- checked Control NT Services in IS for our services to make sure they were scheduled to be stopped during Install and Uninstall
- checked ScheduleReboot in our Install Execute sequence to make sure it was set to something sensible (it was set to ISSCHEDULEREBOOT)
- restarted the testbed to clear any previously scheduled reboots
- checked the Run and RunOnce keys (the testbed is XP 32 bit)
Ran the installer, and definitely got MsiRebootActionScheduled property set to 1 during ScheduleReboot.
Definitely saw IS_PREREQ = "Reboot" in our install log.
And, of course, definitely got the restart dialogue.
If we remove the ScheduleReboot action entirely from Install Execute (in addition to stopping our services early), we do not get the restart dialogue.
Any hints what could drive the IS_PREREQ value to be set (or ISSCHEDULEREBOOT to be true)? They are not exceptionally well-documented... 😞
Thanks!
I'm resurrecting this ancient thread because I seem to be running into the same issue.
We have a product that installs 2 services (as well as other files). We found we were getting a reboot dialogue at the end of a minor upgrade.
After some early research, we saw we were encountering a files in use issue related to InstallValidate determining our services were in use even though they would later be stopped in StopServices. (As per http://community.flexerasoftware.com/showthread.php?p=452274.)
We implemented a heavy-handed approach to take this variable out of the equation, and added a custom action before InstallValidate that stops our services.
But still we got the reboot dialogue.
So we confirmed the following again:
- checked Control NT Services in IS for our services to make sure they were scheduled to be stopped during Install and Uninstall
- checked ScheduleReboot in our Install Execute sequence to make sure it was set to something sensible (it was set to ISSCHEDULEREBOOT)
- restarted the testbed to clear any previously scheduled reboots
- checked the Run and RunOnce keys (the testbed is XP 32 bit)
Ran the installer, and definitely got MsiRebootActionScheduled property set to 1 during ScheduleReboot.
Definitely saw IS_PREREQ = "Reboot" in our install log.
And, of course, definitely got the restart dialogue.
If we remove the ScheduleReboot action entirely from Install Execute (in addition to stopping our services early), we do not get the restart dialogue.
Any hints what could drive the IS_PREREQ value to be set (or ISSCHEDULEREBOOT to be true)? They are not exceptionally well-documented... 😞
Thanks!
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Apr 20, 2010
10:37 AM
I'd look in the log for whatever set ISSCHEDULEREBOOT, then try to walk that back. IS_PREREQ=Reboot is only used for re-entering the Install UI Sequence's dialogs at a reasonable point, as this value indicates a reboot has already occurred. It does not cause any further reboots.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Apr 20, 2010
07:58 PM
Hi Michael,
Thank you for the clarification on IS_PREREQ. I had misunderstood what it meant to see this being set to "Reboot".
So I will concentrate on the mystery of why the ISSCHEDULEREBOOT condition is evaluated as true during our upgrade.
I have searched through our install log, and this property does not appear explicitly anywhere in the log.
I have also searched our ISM file and greped through our source tree, and as far as I can tell this property is not being set explicitly by us.
The reason for restart given in the install log is '0', which I believe maps to msirbRebootUndeterminedReason.
For now, we have removed the ScheduleReboot action completely from our Install Execute sequence, but I am worried that this will cause us to miss legitimate reasons why IS and/or Windows Installer might detect a requirement to reboot. How great a risk do you perceive in this?
Are there Windows Installer properties that implicitly cause ISSCHEDULEREBOOT to be set by IS? (e.g. MsiSystemRebootPending, which is not the offender in our test case, but is one property I can imagine being taken into account implicitly by IS)
We do not set a default value for ISSCHEDULEREBOOT (e.g. in the IS Property Manager). Are we missing something silly, like are we supposed to default the property explicityly to false/0?
I would definitely appreciate any further advice on this issue. 🙂
Thank you for all your help so far.
Thank you for the clarification on IS_PREREQ. I had misunderstood what it meant to see this being set to "Reboot".
So I will concentrate on the mystery of why the ISSCHEDULEREBOOT condition is evaluated as true during our upgrade.
I have searched through our install log, and this property does not appear explicitly anywhere in the log.
I have also searched our ISM file and greped through our source tree, and as far as I can tell this property is not being set explicitly by us.
The reason for restart given in the install log is '0', which I believe maps to msirbRebootUndeterminedReason.
For now, we have removed the ScheduleReboot action completely from our Install Execute sequence, but I am worried that this will cause us to miss legitimate reasons why IS and/or Windows Installer might detect a requirement to reboot. How great a risk do you perceive in this?
Are there Windows Installer properties that implicitly cause ISSCHEDULEREBOOT to be set by IS? (e.g. MsiSystemRebootPending, which is not the offender in our test case, but is one property I can imagine being taken into account implicitly by IS)
We do not set a default value for ISSCHEDULEREBOOT (e.g. in the IS Property Manager). Are we missing something silly, like are we supposed to default the property explicityly to false/0?
I would definitely appreciate any further advice on this issue. 🙂
Thank you for all your help so far.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Apr 20, 2010
08:08 PM
Hi Michael,
I have attached an install log for your entertainment. Please note that the restart type in this log is given as '2' (msirbRebootDeferred), as I declined the reboot dialogue at the end of the installation.
This log is generated during a minor upgrade of our product. Services are stopped early (before InstallValidate) using a CA to avoid the files in use issue. ScheduleReboot is present near the end of our Install Execute sequence, with the condition ISSCHEDULEREBOOT. I cannot figure out why the ScheduleReboot action is firing, as I would expect the condition to evaluate to false/0 (since we do not set the property explicitly and do not see evidence in the logs of it being set implicitly).
Thanks and regards.
[EDIT: attached log removed after a reasonable period of time in case of any potential privacy concerns]
I have attached an install log for your entertainment. Please note that the restart type in this log is given as '2' (msirbRebootDeferred), as I declined the reboot dialogue at the end of the installation.
This log is generated during a minor upgrade of our product. Services are stopped early (before InstallValidate) using a CA to avoid the files in use issue. ScheduleReboot is present near the end of our Install Execute sequence, with the condition ISSCHEDULEREBOOT. I cannot figure out why the ScheduleReboot action is firing, as I would expect the condition to evaluate to false/0 (since we do not set the property explicitly and do not see evidence in the logs of it being set implicitly).
Thanks and regards.
[EDIT: attached log removed after a reasonable period of time in case of any potential privacy concerns]
![](/skins/images/3B39CE851FDD5528C393F146EB70A2D0/responsive_peak/images/icon_anonymous_message.png)