Out of curiosity, which process hols your file handle? As Phil said, if it's a badly written service etc, it would be better to fix the broken process than to force the installer to perform actions that aren't needed in order to "hide" faulty programming. It's been my experience that the MSI Installer can detect if a file is in use and warn the user that a reboot is pending.
As an example, download any of the SQL Server Installers. Somewhere in the Install Sequence is a screen with a listbox and a progress bar that scans running processes and forces the user to shut down a listed task via task manager before installing the SQL Server Product, thus minimizing the chance of a reboot. Having used the installer multiple times, I can state that I've never had to perform a reboot after installing SQL Server, because the Services are stopped and started in such a way that a reboot isn't needed. Carter Quoting Suryadeep Biswal <surya6...@hotmail.com>: > 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 > > ------------------------------------------------------------------------------ _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
