[wpkg-users] Global max execution time hardcoded?

[le dahut]

Damned, you're right, I'm on the wrong mailing list.


I cannot let WPKG run in background because icon folders (Desktop, Start 
Menu, Programs and Startup) are redirected onto a network drive.

As WPKG is running under BUILTIN/SYSTEM, it cannot access user's network 
drives, thus installers crash with error message "R:\ no such file or 
directory" or "R: invalid drive" (R: is the network drive where are 
redirected Desktop and Start Menu icons).



22/03/2013 10:06, Rainer Meier wrote :
> 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
>