>
> Strangely, if I run wpkg.js in a terminal window with /debug, it tries
to
> run the proper file (but fails due to the software variable not being
set).
> But then when I try the service it again goes back to trying to install
the
> 32 bit version.
This sounds like you're running the 32bit
This is just untested speculation.. Are you using either wpkg-client or
wpkg-gp, or just running wpkg.js from a login script? If one of the clients,
are you using the x86 or x64 versions on the x64 machines? I haven't tried
this, but if you were running the x86 client on an x64 OS, would wpkg
Am 13.12.2012 10:06, schrieb Steve Kersley:
This is just untested speculation.. Are you using either wpkg-client or
wpkg-gp, or just running wpkg.js from a login script? If one of the clients,
are you using the x86 or x64 versions on the x64 machines? I haven't tried
this, but if you were r
http://bugzilla.wpkg.org/show_bug.cgi?id=278
--- Comment #2 from Stefan Pendl ---
Hi Rainer,
yes, I have replaced the old "name" attribute with the new "hostname"
attribute, so it is all good now.
How about adding a deprecated message to the log file, if the old "name"
attribute is used?
Some
It looks like that was exactly it.
The 32 bit client was being deployed by an old, forgotten GPO overwriting
the 64 bit client, and as a result none of the architecture checks were
working.
Thank you everyone for your replies.
--
View this message in context:
http://old.nabble.com/Architecture
Hi all,
I just inherited a new client whose workstations have users logged in as
local administrators; the net result is a ton of crapware.
I considered creating wpkg packages for the crapware with only a
"remove" section to a) simplify cleanup, and b) ensure that machines
remain clean, since a h
