Unfortunately I don't understand much of that preamble. If you're getting failures during upgrades, perhaps explain how reboots are involved, if that's what you're looking at. I've only heard the term "hardening" in the sense of "making a system more resistant to cyber attack" (look it up!) so maybe you mean "more reliable", and if so the answer to that is a good install design that follows best practices. Perhaps you could explain why doing a reboot in the worst case is a good thing, because it's usually not. I've never seen anyone successfully outwit Windows in dealing with reboots during an installation because it knows much more than you do about what's going on, and by "dealing with" I mean minimizing to reduce the impact to the customer.
The docs are clear about MsiSystemRebootPending. Use it in a launch condition, and especially when a previous install has finished that needs to be really complete, with files updated instead of pending a change. It's nothing to do with your install - it's about the state of the system. ReplacedInUseFiles is set when your install has replaced in use files, obviously, but if a reboot is required Windows will do it anyway, and you don't need to schedule a reboot because ReplacedInUseFiles is set. There are no cases AT ALL that I know of where YOU need to schedule a reboot. Windows will do the right thing if you let it. Again, if you had issues associated with reboots you could tell us what they were. I have known people who've built installs that were so honked up with things like custom actions and badly written services and other processes that refused to shut down when told, and rather than fix those they forced a reboot on the customers - hopefully that's not your situation. Look at the msiexec exit codes. If you are running bat files or the equivalent and you have anyone that can code, write something that calls the Win32 API MsiInstallProduct. When it returns 3010 it means a reboot was required but it was suppressed by (usually) a command line that said suppress reboots (see REBOOT property), same with the msiexec exit code. http://msdn.microsoft.com/en-us/library/aa376931(v=vs.85).aspx --------------- Phil Wilson On Fri, Mar 28, 2014 at 11:40 AM, Suryadeep Biswal <surya6...@hotmail.com> wrote: > Hi, > > > > We use MSI Major Upgrade to update our products on servers. In > the light of some recent failures during upgrade, we have been working towards > hardening our installation package so that a reboot can be scheduled in the > worst case. I have been looking at various Installer properties/actions on > msdn > related to REBOOT. One thing I am still unsure is the cases where the > Installer > would initiate a reboot vs where the package itself needs to do so. It would > be > great if I can get the following questions answered - > > > > 1. > Initially, if MsiSystemRebootPending > property is set to true, Is it recommended that the installer package > schedules > a reboot? Which Installer action (ForceReboot or ScheduleReboot) > is recommended here? > > 2. > I read on msdn that in case of installation over > in-use files, ReplacedInUseFiles is set to true and Installer > schedules a reboot. I believe in such cases, no action is needed from the > installation packages. Is my understanding correct? Also, Is there a way to > easily reproduce this scenario? I have tried with processes having handles > open > to files being replaced but have never seen the property being set to true by > the installer (I have not seen a reboot either). > > 3. > Are there any other error cases that need to be > handled by an Installer package and a reboot needs to be scheduled? > > 4. > We run "msiexec" command from a batch file. Do > we need to check for some special exit codes from msiexec.exe and take reboot > actions > accordingly? > > > > Regards, > > Surya > ------------------------------------------------------------------------------ > _______________________________________________ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users ------------------------------------------------------------------------------ _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
