Would this work? You do know the process name correct? http://wixtoolset.org/documentation/manual/v3/xsd/util/closeapplication.html
Carter Quoting Suryadeep Biswal <surya6...@hotmail.com>: > This is an external process and we do not have any control over it. > we are in talks with the process owners to see why it opens a handle > in exclusive mode but I would like to know if there is something > that we can do to avoid upgrade failures in such cases (such as > scheduling file copying after a reboot). Please note that Restart > Manager successfully terminates the process, but it is immediately > restarted by it's parent process so we run into issues during file > copying. > Also, our upgrade is silent (msiexec /q) and no user interaction is involved. > -Surya >> Date: Fri, 28 Mar 2014 15:48:53 -0500 >> From: ecyo...@grandecom.net >> To: wix-users@lists.sourceforge.net >> Subject: Re: [WiX-users] Manually scheduling a Machine Reboot >> during MSI Major Upgrade >> >> 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 > > ------------------------------------------------------------------------------ > _______________________________________________ > 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
