No, it isn't, and actually the Microsoft updates don't do this either.
What you're likely observing with Microsoft updates (and some third party updates do this as well), is that files being replaced by an update are locked, so those file transfers get queued for copy-on-startup. The WUA launches the reboot when the "installation" of the update is complete (except it's not really complete because some or all of the files are still in a transient state), and the *system* performs those file transfers that are queued before the relevant portions of the operating system startup.
A reboot involving the Windows Update Agent is effectively a terminal event as far as the Windows Update Agent is concerned.
Thanks for the answer. I've dealed with it by using a Inno Setup Wrapper, source code for an examle is attached. The example was created because our Adobe Flash installation got corrupted and we had to remove the player, reboot and after this reinstall it again. The script does
- install the needed files (2 install_flash_player_16_VERSION.msi and the uninstall_flash_player.exe helper from adobe) into the application directory,
- kill the current browser processes,
- calls uninstall_flash_player.exe to remove anything,
- inserts it's own uninstaller into the scheduled tasks.
After the restart the scheduled task kicks in and calls the uninstaller. This does
- install both MSI versions of flash,
- removes the scheduled task (the "do it once" flag "/Z" does not work from commandline) and
- finally removes the temporally needed files from the application directory.