Installing Zenworks 6.5sp2 as an Unsecure System User renders an incomplete install on some registered workstations

Hello All,
This is a bit complicated because this problem falls between an *.msi file and Zenworks 3.2 delivery.
We are currently deploying Zenworks 6.5 sp2 to the environment via a NAL object as an Unsecure System User.
Workstations that are registered have been receiving the application object.
The application object is actually running a *.vbs script that points to the ZFDagent.msi with the following switches:

strPath = "\\cluster\volume\aotfiles\zenagent"
strCommand1 = "msiexec /qb! /liweu+ \\cluster\volume\logs\zenlog.txt /i " & strPath & "\ZfDAgent.msi ADDLOCAL=ALL NAL_SINGLE_TREE=1 ZENWORKS_TREE=Our Tree REINSTALL=ALL REINSTALLMODE=vamus REBOOT=ReallySuppress"

This is fine.  The msiexec /qb! /liweu+ switches were added to point a log file because Zenworks recorded a successful install (which I know can read as a false-positive since its really recording that the *.vbs file was successfully run), but the workstations were not registering.
Upon further investigation we found the following 1705 errors for these users:

"User SYSTEM has previously initiated an installation for product ZENworks Desktop Management Agent.  That user will need to run that installation again before using that product.  Your current installation will now continue.
Error 1705.A previous installation for this product is in progress.  You must undo the changes made by that installation to continue.  Do you want to undo those changes?
MSI (s) (F8:10): Product: ZENworks Desktop Management Agent -- Error 1705.A previous installation for this product is in progress.  You must undo the changes made by that installation to continue.  Do you want to undo those changes?"

I believe some users may stop the install because it may take too long and they'd rather not install it at that time (they maybe going to their task manager and killing the msiexec.exe process)

Notice how it prompts the user at the end: "...do you want to undo those changes"?
Do we manually have to go to each workstation and uninstall this partial install?
Out of 3000 users, we have this issue with about 10%
Has anyone see this issue?

Any feedback would be helpful.
kcardenasAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

ShineOnCommented:
If it's an .MSI install, why are you running a vbscript?  Zen 3.2 can do .MSI installs.
0
kcardenasAuthor Commented:
Let me preface this with..."I did not create this deployment, I did not make the decisions, I am just support".
I'm fully aware that Zen 3.2 can do *.msi installs.
Again,
Has anyone seen this issue?
0
ShineOnCommented:
I haven't.  I let ZEN handle it.  Too bad you can't do it that way - ZEN wouldn't log a successful deployment if it were in control, and I doubt it would let an aborted install go "unhealed."

I don't know what to tell you, other than to a) have the user uninstall the partial install or b) have the deployment creator and/or decision maker create an uninstall VBS using the msiexec uninstall switch.
0
Cloud Class® Course: Ruby Fundamentals

This course will introduce you to Ruby, as well as teach you about classes, methods, variables, data structures, loops, enumerable methods, and finishing touches.

kcardenasAuthor Commented:
Ok,
How about this, is there any way we could make a registry change to elevate rights and have the ZFDAgent.msi install?
0
ShineOnCommented:
Elevate rights?  You mean the user is a non-Administrator and this whole mess is 'cause they can't install in the first place?

I wrote a WinBatch executable once that makes the logged-in user a member of the local Administrators group.  Prolly not what you want...

I don't know about elevating rights through a reg tweak.  You could probably do it with a Group Policy setting - the one for "always install with elevated privileges."  Turn that on until the updates are done, and disable it afterwards...

There's a thing you can do using MSIEXEC to register an MSI as "administrator approved" by using the /ju or /jm switch, I think.  Maybe a system user ZEN app can be pushed that does that pre-approval.  MSI's that run after that pre-approval are supposed to elevate themselves automatically as needed.  Don't know if system user is sufficient, or if you actually have to be logged in as Administrator to do the registration.
0
kcardenasAuthor Commented:
ShineOn,
That's correct.
All of our workstations are on a domain that has group policies (what they are, vary by department).
In any event, the install has been working for the most part as an Unsecure System User.
After the *.VB script is launched, all it does is call the *.msi with a host of switches, but a few users have been hitting us in the stomach with "cannot install due to admin rights".
To remedy this we have been logging in locally as an administrator and the user logs into the Netware and runs the NAL object from explorer.  Which works for the most part, but we can't do this with upwards of 300+ workstations.
I am open to any script or winbatch executable that will elevate the rights temporarily to administrator to run and install the ZFDagent.msi for these users.
0
kcardenasAuthor Commented:
Remember in previous versions of Zenworks you had the wsreg32.log file that basically told you if you were registered, or if you had problems to register, it would write to this file?
I'm trying to find information for Zenworks 6.5sp2...like does this file still exist, or is it renamed (e.g. wsreg32.exe is now zwsreg.exe..etc...)?
0
ShineOnCommented:
It's renamed starting with ZFD 4.  Exactly to what you said - zwsreg.exe.  I don't know if that's what it is in 6.5 or not.

Troubleshooting isn't quite the same as it used to be.  I'd look at a few TIDs like http://support.novell.com/cgi-bin/search/searchtid.cgi?10056752.htm and http://support.novell.com/cgi-bin/search/searchtid.cgi?10096535.htm

0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
kcardenasAuthor Commented:
ShineOn's answer really isn't for the original question, but that's fine since I've been helped by ShineOn in the past.
0
kcardenasAuthor Commented:
Just an FYI, wsreg32.log is no longer created by default.
There are "debug" registry entries that must be on the workstation:
HKLM\Software\Novell\ZENworks\Debug.  Value Name: ZENWSREG  Value Type: DWORD  Data: 3.  
The following log is created once this debug value is in the registry:
C:\Program Files\Novell\Zenworks\DebugLogs\zenwsreg.log
0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Novell Netware

From novice to tech pro — start learning today.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.