I've posted this in the packaging area as well, but I think this would have been the right place for it ..so here it goes..

I am trying to deploy the full HP suite (drivers+software: HP Solution Center) of the model HP OfficeJet 8500 via SCCM 2007.
I've created a VB wrapper which calls hpzsetup.exe -s -f autorun_usb.inf.
If my VBS if is ran manually from the local admin account it works flawlessly (same thing if I ran only the above command in an admin cmd window)
The problem is, if I ran my VBS (or just that cmd line) using SCCM (system context) the installation fails with: ERROR_INSTALL_USEREXIT, 1602, (I googled a bit this code and it seems it equals: The user cancels installation.)
Now this is just strange ..as I do not interfere and I really don't know what triggers this behaviour..

I even opened a cmd prompt using SCCM, so that cmdprompt has SCCM system context and pulled the original setup.exe in there ( which is not unattended) ..the same thing happens ..it never gets to a step where you can click next ..it fails directly with that error.

Any ideas?
0 Comments   [ - ] Hide Comments


Please log in to comment

Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.
Answer this question or Comment on this question for clarity



Try directly adding the commandline instead of using the .vbs file in the program..
Answered 02/17/2011 by: shweta_kar
Blue Belt

Please log in to comment
Thanks for your replay
I've already tried that and the same thing, more than that I have used the original parent Setup.exe (which calls in the background: hpzsetup.exe -s -f autorun_usb.inf) within SCCM context (via a cmd prompt started by SCCM) and usually by doing that on an admin account I should get to the screens where you have to have to accept EULA or signature agreement ..but it fails instantly at the very first checks, where you don't have the chance to interact yet with the installer.

Is there any difference between SCCM system context and an administrator account, I mean is there anything that system context lacks in favor of an admin account?

Appreciate all your comments, Thanks!
Answered 02/17/2011 by: dryce
Senior Yellow Belt

Please log in to comment
I found what was the problem ..maybe some1 in the future will need this
So at the very first checks, the installer it seems that if he 'sees' that the user is the system ..it calls an exe called: blocksysuserinstall.exe .. (the bastard)
SO I have replaced that exe file with some 'dummy.exe' (which doesnt do anything) and changed the name to blocksysuserinstall.exe
Now it seems it goes further.

ps. great man the guy who written that ProcMon tool [:)]
Answered 02/18/2011 by: dryce
Senior Yellow Belt

Please log in to comment