We help IT Professionals succeed at work.

We've partnered with Certified Experts, Carl Webster and Richard Faulkner, to bring you two Citrix podcasts. Learn about 2020 trends and get answers to your biggest Citrix questions!Listen Now

x

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

kcardenas
kcardenas asked
on
Medium Priority
922 Views
Last Modified: 2011-10-03
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.
Comment
Watch Question

CERTIFIED EXPERT

Commented:
If it's an .MSI install, why are you running a vbscript?  Zen 3.2 can do .MSI installs.

Author

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?
CERTIFIED EXPERT

Commented:
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.

Author

Commented:
Ok,
How about this, is there any way we could make a registry change to elevate rights and have the ZFDAgent.msi install?
CERTIFIED EXPERT

Commented:
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.

Author

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.

Author

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...)?
CERTIFIED EXPERT
Commented:
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

Not the solution you were looking for? Getting a personalized solution is easy.

Ask the Experts

Author

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.

Author

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
Access more of Experts Exchange with a free account
Thanks for using Experts Exchange.

Create a free account to continue.

Limited access with a free account allows you to:

  • View three pieces of content (articles, solutions, posts, and videos)
  • Ask the experts questions (counted toward content limit)
  • Customize your dashboard and profile

*This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

OR

Please enter a first name

Please enter a last name

8+ characters (letters, numbers, and a symbol)

By clicking, you agree to the Terms of Use and Privacy Policy.