Environment
Zenworks Configuration Management 11.3.1
Zenworks Configuration Management 11.3.2
Sles 11 SP3
Zenworks Appliance
Situation
THIS TID IS SPECIFIC to versions in environment only!
Attempting to update Main Primary Linux Server to ZENworks Configuration Management 11.3.2, ZCC shows Server as Pending Status even after ZAC REF on server.
/var/opt/novell/log/zenworks/Pre-Global-Actions.log shows last entries as
[DEBUG] [03/03/2015 13:12:34.73] [3119] [NativeLauncher] [35455] [zenworks] [SystemUpdate] [] [Running command: (env, /opt/novell/zenworks/bin/run_preglobal_update, -Dsystemupdateguid=5011030200fc50000000002014121014, -DstageBehavior=POSTPONE_STAGING, -DstageScheduleFile=5011030200fc50000000002014121014-schedule, -DrebootControl=PromptUserReboot)] [] [] [] [SystemUpdate]
[DEBUG] [03/03/2015 13:12:34.87] [3119] [PreGlobalHandler] [35455] [zenworks] [SystemUpdate] [] [Successfully Launched external process for Schema Update] [] [] [] [SystemUpdate]
Resolution
Go To
/opt/novell/zenworks/bin/
Check file run_preglobal_update, it should have ownership zenworks: zenworks.
If it does not, then run
chown zenworks:zenworks run-preglobal_update
(Normally the permissions.sh in the bin folder will set ownerships to zenworks:zenworks but if not you will have to do the chown command above)
Then manually run the last command from the pre-global-actions.log , removing the ',' comma's
IE
./run_preglobal_update -Dsystemupdateguid=5011030200fc50000000002014121014 -DstageBehavior=POSTPONE_STAGING -DstageScheduleFile=5011030200fc50000000002014121014-schedule -DrebootControl=PromptUserReboot
Let that run to completion. Cancel the deployment, and redeploy to server
zac ref bypasscache
For server to pick up the new deployment
View the progress of update by tailf zmd-messages.log
and after that caches the update, note in the /var/opt/novell/log/zenworks/system-update folder a new folder with the system-update GUID name IE for System Update 11.3.2 it starts with 50110302... SU=50 11 03 02. Watch the progress of the update with tailf of the system-update.log in that folder.
Cause
Either the run_preglobal_update was root:root and not running, or the command was get stuck from the update itself
manually running allowed it to complete