Re: [wpkg-users] Basic behaviour of WPKG

[Rainer Meier]

Hi Simon,

simplesi wrote:
> > I've been thinking about WPKGs default behaviour (following from earlier
> > discussions) and I'd like to start a genuine discussion on changing its
> > current behaviour.

OK, let's try to get a common understanding of the ideas first.


> > Currently, WPKG will attempt to remove an existing package from the local
> > compuer wpkg.xml file if it decides that an existing package is no longer
> > referenced for that computer, regardless of the lack on any remove cmd in
> > the package.

That's true. If a package was assigned to a host before (the only way they go to
wpkg.xml) and then removed by administrator then WPKG assumes the package should
be removed from the host. The definition in profiles.xml (package assignment)
defines the supposed state of the client and wpkg.xml represents the
current/actual state of the client. Comparing them allows us and WPKG to find
out what has to be modified to reach the state supposed.


> > I believe that it would be better if it didn't and that it should only
> > remove a package from wpkg,xml if it decides that the package no longer
> > applies and there is a remove cmd in the package.

OK, let's first be sure that I understand this correctly. The first part means
that WPKG should remove the entry from wpkg.xml (as it is now) but only when the
special condition "at least one remove command is defined" is true.

This means that in case you do not specify any remove commands the package would
remain win wpkg.xml even if the administrator removed it from hosts.xml.


This has a couple of other effects too. Let's summarize some of them I could
imagine:
A positive effect would probably be that an administrator could see from
wpkg.xml that the package has been assigned once on the system. However by
keeping profile.xml histories this would be possible too.

A negative effect would be that after a while there might be pretty much
packages in wpkg.xml where no remove command is specified and where there is no
corresponding package on server side. Currently this would lead to a couple of
errors because of the "zombie" state of this package. Zombie state means that
the administrator does not have any control over this package any more (removed
from packages.xml).

Another drawback in most installations would be that wpkg.xml files are not
comparable easily any more between systems. Some of them might have additional
packages which have been applied once and then removed before applying to all
nodes - so they remain in wpkg.xml on some nodes and not in others.

It could also become an issue in terms of WPKG execution-performance. Remember
that WPKG will have to verify all packages locally installed. This means it
would have to verify all these on each synchronization too just to find out that
they should be removed and due to this special rule (no remove commands) its
removal is skipped.

This way of handling packages also introduces some question what would happen in
case a package with no removal commands is broken. For example if Office was
applied to a system without remove commands and then the package is deleted from
the server. It remains on the client and the checks are executed on each
synchronization. As long as it's installed it might be fine - but what if the
checks fail (somebody uninstalled office)?
Either it can be ignored (since removed by admin anyway) leaving orphaned
entries in wpkg.xml which are completely ignored. Or it could be re-installed
(which might fail if Office is removed from the server share). Or it could
remove wpkg.xml entry then but this renders the only advantage (keeping history
of installed packages) useless.



> > Also, the current default behaviour of attempting and upgrade before
> > attempting a removal doesn't feel to me to be the best way of dealing with a
> > faulty remove cmd as I think it is not a logical action to take.

Well in theory it's a bit "special" but for me and many others it seem to work
properly and was helpful in many cases. The administrator only needs to take
care that the latest package version is perfectly in shape and removes properly.
So an admin does not have to worry about what would happen when he removes the
package from a profile because he has in mind that some old versions he forgot
about the remove commands and if a PC was not updated for a while the removal
would fail on next run.

In addition you're free to switch off the upgrade-before-remove behavior - but
surely you know because it has been implemented on your request.



> > I can understand that it allows for multiple attempts to get the removal
> > right but I think that if a removal has gone wrong, it would be better to
> > write a new "hunter-seeker" :) package to correct the error.

These "multiple attempts" should be done on test systems. But there might be
cases machines in production behave differently - so fixes to the package might
be required sometimes (not only fixes to the deployed software).

I think in m

Re: [wpkg-users] patches for minor typos, status message suggestion

[Rainer Meier]

Hi Malte,

Malte Starostik wrote:
> there are a few occurrences of "chained" misspelt as "chaned" both in 
> comments 
> and a log message (found while trying to write a log parser). wpkg-typos.diff 
> fixes this.

Thanks for reporting. I just checked in the fixes (and found some others).




> when using the sendStatus option, the status message during installation is 
> "Install: verifying package ...".  This maybe somewhat confusing to users if 
> the "verification" takes some time.  a suggestion to improve this situation 
> at 
> the expense of losing the processed/total package counter during installation 
> is attached as wpkg-status.diff

Well your suggestion was to insert a line like:
Installing ''...

This could be quite confusing since there might be upgrades done when a package
is removed (upgrade-before-remove feature).
So the output might show

Remove: Checking status of '' (2/10)
Installing ''...


To prevent this I've actually changed it slightly:
Performing operation () on '' ()

So it might look as follows:
Remove: Checking status of '' (2/10)
Performing operation (upgrade) on '' ()


It also gives some more information during package installation. The lines shown
might include install, upgrade or downgrade within the braces.
The line is omitted completely if the package is correctly installed already -
but this is no change to your proposal.

I think this should not be too much of a problem for a parser capturing the
sendStatus output. It might look as follows
Install: Verifying package 'package 2' (2/10)
Install: Verifying package 'package 3' (2/10)
Performing operation (install) on 'package 3' (package3)
Install: Verifying package 'package 4' (4/10)
Performing operation (upgrade) on 'package 4' (package4)
Install: Verifying package 'package 5' (5/10)
Install: Verifying package 'package 6' (6/10)

This is not difficult to parse because the "Performing operation" line will just
appear if there is some external command to be executed. An application parsing
the (x/y) string to display a progress bar can just ignore it - or use them to
display additional information without updating the bar.

You might try the latest version downloaded from here:


br,
Rainer
-
wpkg-users mailing list archives >> http://lists.wpkg.org/pipermail/wpkg-users/
___
wpkg-users mailing list
wpkg-users@lists.wpkg.org
http://lists.wpkg.org/mailman/listinfo/wpkg-users

Re: [wpkg-users] ZigGenius 6.1 Update successfull but wpkg.xml not updated

[Rainer Meier]

Hi Johannes,

johannes.b...@evidian.com wrote:
> here is the package definition
> 
> 
> 
> NEW build:
> ==
> 
>id="zipgenius" 
>   name="ZIP-Genius" 
>   revision="610" 
>   reboot="false" 
>   priority="1">
>   
>   
>  
>   
>cmd='\\%WPKG-Master%\wpkg\zipgenius\uninstall-zipgenius.cmd' />
>   
>  
>   
>/>
> 


It looks OK to me. No matter if you specify reboot=true or reboot=false WPKG
should update wpkg.xml unless the "ZipGenius 6 (6.1.0.1000)" uninstall entry
does not exist after installation.
Somehow I have the feeling that this package definition does not correspond to
what you used on the hosts on error. What makes me believe this is taht in your
first mail you quoted:
Command 'cmd /C taskkill /F /IM zipgenius.exe' returned exit code [128].
This exit code is not an error.

First of all this line only exists in your "old" package definition as you
referred to.

The "code is not an error" message is printed only in case you specify an "" within the taskkill command node which I cannot see in any of your
definitions. More over WPKG cleaims to execute "cmd /C taskkill /F /IM
zipgenius.exe" which does not exist in any of your quoted package definitions.

Sure WPKG does not "invent" commands. So you might check if you have multiple
XML files defining the "zipgenius" package and WPKG uses another definition than
you might actually think.
Remember that each package id can exist only once. So if you copied the XML file
within packages/ then you need to remove the old file to prevent duplicates.

br,
Rainer
-
wpkg-users mailing list archives >> http://lists.wpkg.org/pipermail/wpkg-users/
___
wpkg-users mailing list
wpkg-users@lists.wpkg.org
http://lists.wpkg.org/mailman/listinfo/wpkg-users

Re: [wpkg-users] ZigGenius 6.1 Update successfull but wpkg.xml not updated

[Johannes . Brix]

Hello,

here is the package definition



NEW build:
==


  
  
 
  
  
  
 
  
  



OLD build:
=
















---
Johannes





Rainer Meier 
10.07.2009 15:56

 
To: johannes.b...@evidian.com
cc: Pendl Stefan , 
"wpkg-users@lists.wpkg.org" 

Subject:Re: [wpkg-users] ZigGenius 6.1 Update successfull but 
wpkg.xml not updated


Hi Johannes,

johannes.b...@evidian.com wrote:
> So, the problem is, how can I change a package, e.g. flags so that it 
will
> be taken into account
> by a client.

Increase the package revision.

Please note that this will make WPKG to re-execute the update commands.

Probably your checks are inappropriate to detect if ZipGenius is installed
properly. Could you post the XML package definition you use?

br,
Rainer


-
wpkg-users mailing list archives >> http://lists.wpkg.org/pipermail/wpkg-users/
___
wpkg-users mailing list
wpkg-users@lists.wpkg.org
http://lists.wpkg.org/mailman/listinfo/wpkg-users

Re: [wpkg-users] ZigGenius 6.1 Update successfull but wpkg.xml not updated

[Rainer Meier]

Hi Johannes,

johannes.b...@evidian.com wrote:
> So, the problem is, how can I change a package, e.g. flags so that it will 
> be taken into account
> by a client.

Increase the package revision.

Please note that this will make WPKG to re-execute the update commands.

Probably your checks are inappropriate to detect if ZipGenius is installed
properly. Could you post the XML package definition you use?

br,
Rainer
-
wpkg-users mailing list archives >> http://lists.wpkg.org/pipermail/wpkg-users/
___
wpkg-users mailing list
wpkg-users@lists.wpkg.org
http://lists.wpkg.org/mailman/listinfo/wpkg-users

Re: [wpkg-users] ZigGenius 6.1 Update successfull but wpkg.xml not updated

[Johannes . Brix]

Hello,

I changed the flag
   reboot="false" 
to
   reboot="true" 
to take into account that ZipGenius needs a reboot after deinstallation 
before an update is possible.

Changing back to the original value, the update of wpkg.xml worked fine.
This explaines why it worked on some PCs, because wpkg was running before 
I cnaged the flag.

So, the problem is, how can I change a package, e.g. flags so that it will 
be taken into account
by a client.

---
Johannes






Pendl Stefan 
10.07.2009 12:45

 
To: "johannes.b...@evidian.com" , 
"wpkg-users@lists.wpkg.org" 
cc: 
Subject:AW: [wpkg-users] ZigGenius 6.1 Update successfull but 
wpkg.xml not updated


Johannes.Brix wrote:
Hello,

yesterday, I integrated ZipGenius 6.1.
On some PCs, the update works as expected.

But on some the Update was successfull but wpkg.xml not updated.
---
Command 'cmd /C taskkill /F /IM zipgenius.exe' returned exit code [128].
This exit code is not an error.
Command in installation of ZIP-Genius returned exit code [128]. This exit
code indicates success.
Command '\\%WPKG-Master%\wpkg\zipgenius\zg6.1.0.1000std.exe /VERYSILENT
/NORESTART /NOICONS' returned exit code [0]. This exit code is not an
error.
Command in installation of ZIP-Genius returned exit code [0]. This exit
code indicates success.
Installation of ZIP-Genius successful, system rebooting.
System reboot was initiated but overridden.
---

ZipGenius is properly installed and works fine, but the local wpkg.xml is
not updated.
Next run of the update script tries to install again ...

Any hints?

Thank you and kind regards,
Johannes

---
Hi Johannes,
there was a reboot and this reboot occurred directly after ZIPgenius was 
installed.
What is the reboot attribute set for this package?

You may consider setting it differently, check the packages.xml page at 
the WPKG site, which was updated yesterday to include a better description 
of what value causes which behavior.

---
Stefan



-
wpkg-users mailing list archives >> http://lists.wpkg.org/pipermail/wpkg-users/
___
wpkg-users mailing list
wpkg-users@lists.wpkg.org
http://lists.wpkg.org/mailman/listinfo/wpkg-users

Re: [wpkg-users] Basic behaviour of WPKG

[Chris Wilcox]

> 
> 
> I've been thinking about WPKGs default behaviour (following from earlier
> discussions) and I'd like to start a genuine discussion on changing its
> current behaviour.
> 
> Currently, WPKG will attempt to remove an existing package from the local
> compuer wpkg.xml file if it decides that an existing package is no longer
> referenced for that computer, regardless of the lack on any remove cmd in
> the package.
> 
> I believe that it would be better if it didn't and that it should only
> remove a package from wpkg,xml if it decides that the package no longer
> applies and there is a remove cmd in the package.
> 
> Also, the current default behaviour of attempting and upgrade before
> attempting a removal doesn't feel to me to be the best way of dealing with a
> faulty remove cmd as I think it is not a logical action to take.
> 
> I can understand that it allows for multiple attempts to get the removal
> right but I think that if a removal has gone wrong, it would be better to
> write a new "hunter-seeker" :) package to correct the error.
> 
> I don't think having lots of different flags is the way forward and it would
> be better to reach consensus :)
> 
> regards
> 
> Simon


The only thing I would perhaps view as a missing feature is the ability to 
alter the package xml file contents without having to increment the version 
number and therefore force an upgrade.  I can see why the current method is in 
place though I've not used it myself.  I don't even use upgrade commands, I 
tend to remove an existing app and create a new xml file for the new version.

 

Writing a package just to remove a faulty package is a bit long winded and 
slightly illogical to me, but maybe I'm missing something!

_
With Windows Live, you can organise, edit, and share your photos.
http://clk.atdmt.com/UKM/go/134665338/direct/01/-
wpkg-users mailing list archives >> http://lists.wpkg.org/pipermail/wpkg-users/
___
wpkg-users mailing list
wpkg-users@lists.wpkg.org
http://lists.wpkg.org/mailman/listinfo/wpkg-users

Re: [wpkg-users] locale' is undefined Error number: 800a1391

[Simon Kelsall]

Quoting Rainer Meier :


Which version of WPKG are you  using (not


var WPKG_VERSION = "1.1.1";


Please attach a full debug log.



"HKCU\Control Panel\International\Locale".


Value is 0809



Maybe a cscript error. On which systems/OS are you running wpkg.js?


Windowsm XP Pro with service pack 2


Could you try running "cscript wpkg.js ..." on the shell manually?


cscript wpkg.js /synchronize /quiet /debug in a shell worked !


--
Simon Kelsall
Network Administrator
St James the Great R.C Primary & Nursery School
http://www.stjamesthegreat.org/



This message was sent using IMP, the Internet Messaging Program.

2009-07-10 12:38:04, DEBUG   : Initialized temporary local log file: 
C:\WINDOWS\TEMP\wpkg-logInit.log
2009-07-10 12:38:04, DEBUG   : Initializing new log file: 
C:\WINDOWS\TEMP\wpkg-st-5ca63603bdf5.log
2009-07-10 12:38:04, DEBUG   : Reboot-Cmd is standard.
2009-07-10 12:38:04, DEBUG   : WPKG 1.1.1 starting...
2009-07-10 12:38:04, DEBUG   : Base directory is 
'\\kaitain.stjamesthegreat.org\WPKG'.
2009-07-10 12:38:04, DEBUG   : Log level is 255
2009-07-10 12:38:04, DEBUG   : Trying to read XML file: 
\\kaitain.stjamesthegreat.org\WPKG\profiles.xml
2009-07-10 12:38:04, DEBUG   : Successfully loaded XML file: 
\\kaitain.stjamesthegreat.org\WPKG\profiles.xml
2009-07-10 12:38:04, DEBUG   : Trying to read XML files from directory: 
\\kaitain.stjamesthegreat.org\WPKG\profiles
2009-07-10 12:38:04, DEBUG   : Specified XML directory does not exist: 
\\kaitain.stjamesthegreat.org\WPKG\profiles
2009-07-10 12:38:04, DEBUG   : Trying to read XML file: 
\\kaitain.stjamesthegreat.org\WPKG\hosts.xml
2009-07-10 12:38:04, DEBUG   : Successfully loaded XML file: 
\\kaitain.stjamesthegreat.org\WPKG\hosts.xml
2009-07-10 12:38:04, DEBUG   : Trying to read XML files from directory: 
\\kaitain.stjamesthegreat.org\WPKG\hosts
2009-07-10 12:38:04, DEBUG   : Specified XML directory does not exist: 
\\kaitain.stjamesthegreat.org\WPKG\hosts
2009-07-10 12:38:04, DEBUG   : Trying to read XML file: 
\\kaitain.stjamesthegreat.org\WPKG\packages.xml
2009-07-10 12:38:04, DEBUG   : Successfully loaded XML file: 
\\kaitain.stjamesthegreat.org\WPKG\packages.xml
2009-07-10 12:38:04, DEBUG   : Trying to read XML files from directory: 
\\kaitain.stjamesthegreat.org\WPKG\packages
2009-07-10 12:38:04, DEBUG   : Specified XML directory does not exist: 
\\kaitain.stjamesthegreat.org\WPKG\packages
2009-07-10 12:38:04, DEBUG   : Profiles applying to the current host:|Test|
2009-07-10 12:38:04, DEBUG   : Reading settings file: 
C:\WINDOWS\system32\wpkg.xml
2009-07-10 12:38:04, DEBUG   : Trying to read XML file: 
C:\WINDOWS\system32\wpkg.xml
2009-07-10 12:38:04, DEBUG   : Successfully loaded XML file: 
C:\WINDOWS\system32\wpkg.xml
2009-07-10 12:38:04, DEBUG   : Hosts file contains 35 
hosts:|st-d1a79ab65b72|st-53466d9ad209|st-215dbe69b8e6|st-1f18fd905a87|st-aad587b97576|st-05f53582830f|st-b44edc765273|st-0af5a273c680|st-6bd7477526d3|st-63822aa2f00a|st-c1341f0c7c74|st-e74d3abf76e4|st-943922e070ae|st-c878c4c87605|st-50c0ab685ef9|st-a61722b749a5|st-f4490d87e663|st-bea326b61097|st-7fae8a503e53|st-709f03cdeaba|st-10a8d0cd626c|st-327a8697d6cd|st-4125195a0d54|st-287176c5fc07|st-5ca63603bdf5|st-955bcd976abe|st-fe7b29007972|st-fa0a7dd819ea|st-cc75b7afddf9|st-33f81af89473|st-46bca25e2344|st-227b8650328a|st-c743434ab617|st-ff510c25af70|ST-CEF9AF5D1B8E
2009-07-10 12:38:04, DEBUG   : Settings file contains 0 packages:
2009-07-10 12:38:04, DEBUG   : Packages file contains 2 packages:|dia|scratch
2009-07-10 12:38:04, DEBUG   : Profile file contains 2 
profiles:|Test|ICTSHUTTLES
2009-07-10 12:38:04, DEBUG   : Using profile(s):|Test|
2009-07-10 12:38:04, DEBUG   : Getting profiles which apply to this node.
2009-07-10 12:38:04, DEBUG   : Applying profile: Test
2009-07-10 12:38:04, DEBUG   : Adding package with ID 'dia' to profile packages.
2009-07-10 12:38:04, DEBUG   : Found package node 'Dia Diagram Editor' (dia) in 
package database
2009-07-10 12:38:04, DEBUG   : Synchronizing: Number of packages referenced by 
profile: 1
2009-07-10 12:38:04, DEBUG   : Number of packages to remove: 0
2009-07-10 12:38:04, DEBUG   : Going to install package 'Dia Diagram Editor' 
(dia), Revision 1, (execute flag is '', notify flag is 'true').
2009-07-10 12:38:04, DEBUG   : Package 'Dia Diagram Editor' (dia): Not yet 
processed during this session.
2009-07-10 12:38:04, DEBUG   : Package 'Dia Diagram Editor' (dia): Not in local 
package database.
2009-07-10 12:38:04, DEBUG   : Checking existence of package: Dia Diagram Editor
2009-07-10 12:38:04, INFO: Package 'Dia Diagram Editor' (dia): Not 
installed (checks failed). Preparing installation.
2009-07-10 12:38:04, ERROR   : Message:  'locale' is undefined|Description: 
 'locale' is undefined|Error number: 800a1391|Stack:undefined|Line: 
undefined|
2009-07-10 12:38:04, DEBUG   : Found language definition node for language ID 
409
2009-07-10

Re: [wpkg-users] locale' is undefined Error number: 800a1391

[Rainer Meier]

Hi Simon,

Simon Kelsall wrote:
> I'm trying to set up WPKG for the first time. Everything seems to work
> fine until I hit this error: 'locale' is undefined Error number: 800a1391
> followed by: Script execution: failure. Exit code: 2

Looks like an error thrown by wpkg.js. Which version of WPKG are you using (not
the GUI, version of wpkg.js, if in doubt check the header of the file). You
should run 1.1.1 or newer.

Please attach a full debug log.
Locale could be related to the locale reading code when reading the locale from
"HKCU\Control Panel\International\Locale". However I could not yet locate the
part where WPKG dumps out with such an error. the getLocale() method is supposed
to catch all possible problems.

Maybe a cscript error. On which systems/OS are you running wpkg.js? Could you
try running "cscript wpkg.js ..." on the shell manually?

br,
Rainer
-
wpkg-users mailing list archives >> http://lists.wpkg.org/pipermail/wpkg-users/
___
wpkg-users mailing list
wpkg-users@lists.wpkg.org
http://lists.wpkg.org/mailman/listinfo/wpkg-users

[wpkg-users] locale' is undefined Error number: 800a1391

[Simon Kelsall]

Hi,

I'm trying to set up WPKG for the first time. Everything seems to work  
fine until I hit this error: 'locale' is undefined Error number:  
800a1391

followed by: Script execution: failure. Exit code: 2

This seems to happen whenever I try and install a package. If I just  
use a simply command like  everything runs ok.


I'm useing the WPKG Client 1.2.1 on Windows XP (SP2) machines  
executing the command by hand works ok.


--
Simon Kelsall
Network Administrator
St James the Great R.C Primary & Nursery School
http://www.stjamesthegreat.org/



This message was sent using IMP, the Internet Messaging Program.


-
wpkg-users mailing list archives >> http://lists.wpkg.org/pipermail/wpkg-users/
___
wpkg-users mailing list
wpkg-users@lists.wpkg.org
http://lists.wpkg.org/mailman/listinfo/wpkg-users

Re: [wpkg-users] ZigGenius 6.1 Update successfull but wpkg.xml not updated

[Pendl Stefan]

Johannes.Brix wrote:
Hello,

yesterday, I integrated ZipGenius 6.1.
On some PCs, the update works as expected.

But on some the Update was successfull but wpkg.xml not updated.
---
Command 'cmd /C taskkill /F /IM zipgenius.exe' returned exit code [128].
This exit code is not an error.
Command in installation of ZIP-Genius returned exit code [128]. This exit
code indicates success.
Command '\\%WPKG-Master%\wpkg\zipgenius\zg6.1.0.1000std.exe /VERYSILENT
/NORESTART /NOICONS' returned exit code [0]. This exit code is not an
error.
Command in installation of ZIP-Genius returned exit code [0]. This exit
code indicates success.
Installation of ZIP-Genius successful, system rebooting.
System reboot was initiated but overridden.
---

ZipGenius is properly installed and works fine, but the local wpkg.xml is
not updated.
Next run of the update script tries to install again ...

Any hints?

Thank you and kind regards,
Johannes

---
Hi Johannes,
there was a reboot and this reboot occurred directly after ZIPgenius was 
installed.
What is the reboot attribute set for this package?

You may consider setting it differently, check the packages.xml page at the 
WPKG site, which was updated yesterday to include a better description of what 
value causes which behavior.

---
Stefan

-
wpkg-users mailing list archives >> http://lists.wpkg.org/pipermail/wpkg-users/
___
wpkg-users mailing list
wpkg-users@lists.wpkg.org
http://lists.wpkg.org/mailman/listinfo/wpkg-users

[wpkg-users] Basic behaviour of WPKG

[simplesi]

I've been thinking about WPKGs default behaviour (following from earlier
discussions) and I'd like to start a genuine discussion on changing its
current behaviour.

Currently, WPKG will attempt to remove an existing package from the local
compuer wpkg.xml file if it decides that an existing package is no longer
referenced for that computer, regardless of the lack on any remove cmd in
the package.

I believe that it would be better if it didn't and that it should only
remove a package from wpkg,xml if it decides that the package no longer
applies and there is a remove cmd in the package.

Also, the current default behaviour of attempting and upgrade before
attempting a removal doesn't feel to me to be the best way of dealing with a
faulty remove cmd as I think it is not a logical action to take.

I can understand that it allows for multiple attempts to get the removal
right but I think that if a removal has gone wrong, it would be better to
write a new "hunter-seeker" :) package to correct the error.

I don't think having lots of different flags is the way forward and it would
be better to reach consensus :)

regards

Simon

-- 
View this message in context: 
http://www.nabble.com/Basic-behaviour-of-WPKG-tp24424306p24424306.html
Sent from the WPKG - Users mailing list archive at Nabble.com.

-
wpkg-users mailing list archives >> http://lists.wpkg.org/pipermail/wpkg-users/
___
wpkg-users mailing list
wpkg-users@lists.wpkg.org
http://lists.wpkg.org/mailman/listinfo/wpkg-users

[wpkg-users] ZigGenius 6.1 Update successfull but wpkg.xml not updated

[Johannes . Brix]

Hello,

yesterday, I integrated ZipGenius 6.1.
On some PCs, the update works as expected.

But on some the Update was successfull but wpkg.xml not updated.
---
Command 'cmd /C taskkill /F /IM zipgenius.exe' returned exit code [128]. 
This exit code is not an error.
Command in installation of ZIP-Genius returned exit code [128]. This exit 
code indicates success.
Command '\\%WPKG-Master%\wpkg\zipgenius\zg6.1.0.1000std.exe /VERYSILENT 
/NORESTART /NOICONS' returned exit code [0]. This exit code is not an 
error.
Command in installation of ZIP-Genius returned exit code [0]. This exit 
code indicates success.
Installation of ZIP-Genius successful, system rebooting.
System reboot was initiated but overridden. 
---

ZipGenius is properly installed and works fine, but the local wpkg.xml is 
not updated.
Next run of the update script tries to install again ...

Any hints?

Thank you and kind regards,
Johannes

---
Johannes Brix, CISSP, CISA   Phone:++49 (0)2 20 33 05 15 
32
Senior Support Engineer  Mobile:   ++49 (0)  17 35 88 76 
48
Evidian Customer Care Köln   Web: support.evidian.com
 www.evidian.com
---

-
wpkg-users mailing list archives >> http://lists.wpkg.org/pipermail/wpkg-users/
___
wpkg-users mailing list
wpkg-users@lists.wpkg.org
http://lists.wpkg.org/mailman/listinfo/wpkg-users