[wpkg-users] Global max execution time hardcoded?

[Rainer Meier]

Hi Klaas,

On 22.03.2013 09:34, le dahut wrote:
> Maybe another solution : Can WPKG-GP let users login / present login screen
> before it has finished its work ?
> Is there such an option to define ?

This is not a WPKG core functionality. WPKG itself just executes installations 
sequentially. It does not block anything. Perhaps you're referring to the logon 
delay feature of WPKG Client which displays a message and delays login until 
WPKG finished its task. This anyway currently does not work on Windows 
Vista/7/8. WPKG-GP also offers delay functionality.

It therefore depends on the type of integration into Windows on how the delay 
(if any) is achieved. Whether one of these ways offer a possibility to abort is 
out of scope of wpkg.js.

Personally I am using WPKG client to run the service in background (even with 
delayed startup). So all package deployment will run in background on system 
reboot without even blocking anything.
The risk of doing so is that users might launch applications which are pending 
to be upgraded. As a result some upgrades might fail. For some applications this 
is not an issue since the installation even completes if the application is 
running and file renames/upgrades are scheduled for next reboot (e.g. Mozilla 
applications). For others the upgrade simply fails and WPKG re-tries on next 
boot. Even others (worst-case) display an interactive message during upgrade 
whether to close the running application.
If WPKG is then run in background as a service (e.g. via WPKG client) then this 
message will not be shown to the user and therefore WPKG will wait indefinitely 
(1h max per command) for somebody clicking the dialog buttons. If you're running 
Win Pro, then you might enable the Interactive Services Detection service. This 
allows you to detect such issues and even see the dialog boxes popping up in 
background.


Again, this is application-specific behavior and the way you execute WPKG is up 
to you (WPKG client, WPKG-GP, Task scheduler, script...) It's your decision 
whether to block the user from doing anything else during WPKG run or if you run 
upgrades in parallel with slightly higher risk of failure.
WPKG itself usually is pretty resilient to such failures as it will just re-try 
the failed upgrades on next run.


> This way, administrators could open a session and see what is blocking.

If there is really something blocking (e.g. dialog box in background if run as 
service) then also timeout won't help much since the installation/upgrade will 
still fail on timeout. You need to make sure all installers run entirely silent 
in order to run WPKG smoothly.


br,
Rainer