Thank you the detailed explanation, I really appreciate it.
One issue that we encountered during an upgrade was that a process was holding onto an exclusive handle to one of the files being replaced during upgrade. This process ignores Ctrl+C controls and is managed by a parent process which immediately restarts it after detecting a shutdown. we use MSIRMSHUTDOWN=1, which causes RM to terminate this process but it immediately comes back up and as a result copying of that binary fails leading to an upgrade failure. we were thinking if we can schedule a reboot in such a case causing the file replacement to happen by Session Manager after the reboot (and before the process starting). Regards, Surya > Date: Fri, 28 Mar 2014 12:44:26 -0700 > From: phildgwil...@gmail.com > To: wix-users@lists.sourceforge.net > Subject: Re: [WiX-users] Manually scheduling a Machine Reboot during MSI > Major Upgrade > > 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 ------------------------------------------------------------------------------ _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
