We are facing updating the ZCM agent on 3000+ workstations spread over 26 sites, each with their own ZCM satellite server. They currently run the 11.3.x agent and we recently updated ZCM to 11.4.2.
The administrators want to deploy the updated ZCM agent via a ZCM bundle, to eliminate swamping the network with the agent download at a site, since some sites are on 100M switches and already have a lot of traffic.
The proposed agent update bundle would notify users that they can deploy the update at their convenience (since a reboot is required and the agent update can take quite some time) until a specific date. On that date, the ZCM bundle for the agent update will be set to force run.
This technique (notify, then force) has worked in the past when large applications needed to be deployed to everyone.
Multiple attempts to create a ZCM bundle to do this agent upgrade failed when the agent hit about 94% completion. Having the current ZCM agent running the agent update causes a bit of a dilemma. How does the agent update continue when the update agent shuts down the current ZCM agent and the current agent is running the update? How can the update continue?
While deployment tasks may end up being the way to go, being able to deploy the update via a ZCM bundle would be wonderful.
by: Carol Ann C. | over a year ago | System Update
Comments
Agreed - we're a 24/7 enterprise, so a lights-out deployment doesn't really work for us, nor does micro-managing the deployment tasks for small groups. Allowing users to perform the upgrade on their schedule for a specified period would be far less disruptive to our operations, and increase the chances of catching any issues early on.
What we did was create workstation groups with the 11.4.2 system update assigned to run "Now". Then, our technicians at each site can drop in the devices to the group and upgrade them at their will. At some future date, we will assign the update to all devices.
We don't HAVE technicians at each site, and certainly not on a 24/7 basis, nor do we have the staff to micromanage adding machines to deployment groups. A forced deployment may disrupt users in the middle of something critical, like accessing medical records to treat a patient. That why we usually allow them to install things like this on their own schedule for a while before forcing it.
I agree, it would be great to have the full installer be able to perform an upgrade so we can manage a bundle. The big reason for us is due to when it executes. If we get a machine that hasnt been online in a month, it will boot up and take other updates (windows updates and other bundles), then just start the System Update and we have MSI conflict errors.
I believe this is supposed to be the solution for that;
https://www.novell.com/documentation/zenworks114/zen11_sys_updates/data/b18h06hw.html
However, the two times I have tried, it hasn't work for us. In the most recent 11.4.2 version, there is a known bug which they provide a fix for, but we haven't tried it yet.
https://www.novell.com/support/kb/doc.php?id=7017984
There are some known issues building the Stand-Alone Updater on Windows Servers, but Support can assist you if do not have a Linux Primary. Many Customers use the Stand-Alone Updater via a Bundle for this very purpose.
I would use the normal procedure using System Updates, but selecting a limited # of workstations each time to spread the load.
Also, 94% sounds awfully familiar. Did you realise that the agent update of 11.x always takes a long time to pregress beyond 94%? It might appear to be frozen, but it isnt. Just wait it out and see :P
Rene, we waited HOURS past 94%. The failing at 94% has been confirmed in the logs and as an issue with Support. It seems to be a failure of dynamic administrator impersonation, presumably because the old agent is no longer available to manage that.
The main issue with using System Updates isn't a need to "spread the load", it's not disrupting users in the middle of critical work (like updating medical records while seeing a patient) in order to upgrade the workstation.
Micro Focus provided a wrapper as a workaround so we can notify users of the upgrade/progress while running as System, but we would prefer to be able to install upgrades at a user-determined time via a bundle with administrator impersonation that allows the user to monitor the upgrade status effectively.
Ah, that changes things. Needing users to be able to pick a best time is indeed incompatible with using System Updates :-). I never heard of the 94% issue though, we never experienced this. We just had wait times up to like 30 minutes.
94% was when the system update, runs setup.exe to update the small amount of ESM that is in the Agent, and would take ~5mins to run
In our environment, the update would not progress beyond 94% on some devices as the agent did not appear to have the rights to the ESM folder to update the contents - this also seemed to correspond with the ZESService not listed as a service on these machines.