Burn Reboot Notification: As far as I know Burn will show a reboot prompt after installation if any of the embedded MSI files schedule a reboot (that can be done by scheduling the standard actions ScheduleReboot or ForceReboot - and Windows Installer will schedule a reboot by itself if a file can not be replaced during installation).
I believe the Burn bundle will handle suppressing the reboot until the installation is done - by virtue of the command line they use to invoke each MSI, but I am not 100% sure. There could be special concerns for ForceReboot. Just use ScheduleReboot, and condition it well - as explained here.
Moreover the whole bundle seems to refuse to uninstall if a reboot is pending. Not sure what happens when the bundle runs in silent mode, it seemed to kick off a failed reboot. Haven't tested too thoroughly.
Pending some testing. Need to do something else first.
Rant: I wrote a whole reboot-rant, just for you below :-). The gist of it: just do not reboot unexpectedly or spontaneously.
Unfortunately Windows Installer itself will spontaneously reboot when
run in silent mode, unless you specify REBOOT=ReallySuppress on
the command line - if a reboot is indeed pending.
Don't: Causing a spontaneous, unannounced reboot is actually technically easy (custom action, or an MSI run in silent mode that sets ForceReboot - or even ScheduleReboot without setting REBOOT=ReallySuppress on the command line - described here - in detail - or you can hard-code the REBOOT property to "Force" in the property table - this will also trigger a reboot without warning). Rebooting like this is logically and pragmatically unsound. Extremely so in fact.
Ethics for Rebooting: Rebooting a knowledge worker's PC is very serious, I have seen people sent out the door for less. This is nothing to be nonchalant about: Dozens of Visual Studio windows, heaps of half-written emails, notes in notepad, and the plague itself: missed chat messages and web pages without state management, etc... Beyond losing data (which still happens, though most apps save before closing), people lose context (obvious, but still) - it is as if someone took your physical desktop and swiped it clean with documents ending up on the floor and in the trash can (now politically correctly referred to as the "recycle bin").
There is more:
- What if you reboot and there are many users logged on?
- Someone could be careless enough to install on a server that needs careful management of reboots (for example: multiple servers need to be booted in a specific order for auditing and various purposes - yes, it happens and the air will be full of not so good words).
- God forbid you reboot a terminal server out of the blue with the whole company logged on (not even sure it is possible).
- The list could be made very technical - the strangest things happen. System administrators could for example make a batch file for
"semi-automatic installation". In other words they kick of the batch file - it runs the MSI in silent mode with a few prepared settings and the box reboots without warning. Not sure what features have appeared in Windows to deal with this on server OSs.
- What if you force an immediate and spontaneous reboot via a custom action and the MSI is one of many being run in sequence in a Burn bundle? Not sure what Burn does to handle this? It might have features to handle it.
The bottom line is this: your software could be thrown out of whole
companies for "behavior" such as this. Haphazard rebooting. It really can. As in "...if they do this, what else do they do that we can't live with".
Civilized Reboot: I am not sure of all the aspects here, but I would recommended something like this for software that can not work without a reboot:
- Premonition: Announce before the installation starts that a reboot REALLY
is necessary after installation. Allow early exit. Helps everyone.
- ReallySuppress: Do not ever disrespect an MSI file's command line set to REBOOT=ReallySuppress in order to suppress all reboots (this is a built in feature of
msiexec.exe - Windows Installer engine - you can suppress all reboots scheduled by an MSI, theoretically - there are still hacks).
- We need this working in the business and to eliminate the freebasing approach of doing whatever whenever in terms of rebooting.
- The poor system administrators who have to deal with freebasing packages resort to desperate measures to prevent spontaneous reboots: Is there a really-really-really-don't-reboot parameter for msiexec?
- Admins really go to these extremes to prevent reboots (
removing system privileges for reboot to control what is going on). I don't recommend they do this since this can cause other, unexpected problems - technical hacks always do. Always side-effects. The right approach is to eliminate reboot hacking in packages. Isn't it? Or an update to Windows that really suppresses unexpected stuff like this.
- Standard Approach: After installation Windows Installer itself will show a dialog to reboot. Allow this standard approach to be used. And as stated: respect reboot suppression for a silent install. Note that Windows Installer will show a reboot dialog - if files need to be replaced - even if you did not add an explicit ScheduleReboot command in your MSI file. Automagic.
- No Soup For You: You can make your application refuse to launch before a reboot is done. Many ways to do so, maybe just scan for a file that needs to be replaced for example before you allow to launch. Opens up for potential launch bugs, so keep it simple. The EXE might not even get off the ground if there are necessary prerequisites requiring a reboot.
I wish we could hide shortcuts added until reboot is complete (if reboot is really, really needed). Or a modal dialog that can't be dismissed without kicking off reboot? Loaded gun that. I prefer to not add any buttons to kick off a reboot in the application, I just state a reboot is needed and exit - if this is indeed necessary. Less to test for the QA guys?
