kcardenas
asked on
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
strCommand1 = "msiexec /qb! /liweu+ \\cluster\volume\logs\zenl
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.
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
strCommand1 = "msiexec /qb! /liweu+ \\cluster\volume\logs\zenl
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.
ShineOn
If it's an .MSI install, why are you running a vbscript? Zen 3.2 can do .MSI installs.
ASKER
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?
I'm fully aware that Zen 3.2 can do *.msi installs.
Again,
Has anyone seen this issue?
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.
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.
ASKER
Ok,
How about this, is there any way we could make a registry change to elevate rights and have the ZFDAgent.msi install?
How about this, is there any way we could make a registry change to elevate rights and have the ZFDAgent.msi install?
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.
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.
ASKER
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.
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.
ASKER
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...)?
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...)?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
ShineOn's answer really isn't for the original question, but that's fine since I've been helped by ShineOn in the past.
ASKER
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\ZENwo
The following log is created once this debug value is in the registry:
C:\Program Files\Novell\Zenworks\Debu
There are "debug" registry entries that must be on the workstation:
HKLM\Software\Novell\ZENwo
The following log is created once this debug value is in the registry:
C:\Program Files\Novell\Zenworks\Debu