ZCM10 System Updates Deployment Tip

It’s ZCM month here at youLinuxGuy.com / yourZcmGuy.com …!

I got a question the other day from a customer, basically asking, “…what is the best way to deploy ZCM agent System Updates in a large, spread-out environment?

First, an aside.  I think ZCM 10 is the best version of ZENworks to date.  Sure, it hit some rough spots as it was revised from the original release, but now it is a stable, flexible, scalable, and mature product.

Since the release of ZCM 10.0.0 just a couple years ago as a complete re-write of the original NetWare-based ZENworks product, I have been working regularly with the product as an on-going consultant, installer and administrator.  I have worked with customers through design and deployment of the original version, through each of the subsequent updates and all the correlating changes and challenges.

Previous to ZCM10, I have years of experience with ZENworks for Desktops; having deployed (or consulted on existing deployments) all the way back to version 3.  But more recently I have designed ZCM systems for a handful of customers, from small companies to two medium-sized, name-recognizable Michigan-based companies.  I have also acted as a ZCM subject matter expert on behalf of other local companies.

So I’m glad to see that it has arrived to what it is today.  The integration with Patch Management, the single web-based console, the scalable multi-primary and tiered satellite design, and so on.  It’s almost all good.  By the way, if you need help with your ZCM environment, all the way from the smallest tip to the biggest deployment plan, feel free to drop me a line!  Okay, enough of the aside, on to the point…

As each patch or updates is released for ZCM, you (as an admin) are faced with the notion of pushing those updates out to the clients across your enterprise.  You hope they go out smoothly, you hope they run correctly, you hope they reboot normally, and you hope they return to service.  Now, do you want 100 of them doing that at once?  1,000 of them?  No.

The customer that asked me the question at the top of this post had just deployed the ZCM 10sp2 update out to all his PCs, and spent the next 3 days figuring out why the deployment hadn’t “baselined”.  He had not previously used “Staged” deployments for the updates, but with a little help, he will from now on.

With “Staged” deployments of updates, you can choose the Devices (or groups of Devices) to which each “Stage” will apply.  This is one reason why I always set up rules for automatic containment placement *AND* group memberships for initial agent deployments, since the Device group is perfect for this type of use.  You can also set the configuration so that each stage will fully complete before advancing to the next, either manually, automatically, and/or with notification (via email!).

Stages are set up by doing the following in the ZMC administration page:

  • Go to Configuration -> System Updates
  • Under Deployment Stages, click Action and choose Add Stage

I like to break the entire organization into a standard set of initial stages, then the later stages are dictated by the size/scope/layout of the company.  For instance, here is my list of stages for a generic multi-site company:

  1. zcmServers
  2. mainSiteTestbed
  3. remoteSite1
  4. remoteSite2
  5. mainSite

Of course, you could argue that the “main” site should be number 3, but over time I have preferred to do the biggest site *last*.  To each his/her own, I suppose.

Also, while in the “Action” item as described above, you’ll see the options for modifying the default behaviors of advancing through the stages.  This is a good idea!  Personally, I like to set it to manually advance.  I want to be able to have things move along at the pace I dictate, even if an advancement means that a stage is sucessful.  I guess I just like that level of control…

I hope that helps you….

🙂

7 Comments

  1. Pingback: Your ZCM Guy .com » Blog Archive » ZCM Event-based Email Notifications

  2. hko

    A very good story. But i was wandering, how will satelitte servers be updated ?
    Will they be automaticaly updated, like the workstations?
    Or must you do something ‘by hand’ installation ?

    HKO

  3. Jeremy Pavlov

    @ hko

    That is up to you, actually. Since “satellite servers” are really just regular workstations that have a special purpose, you can treat them either way.

    You might do one of three things: 1.) Add them to the “zcmServers” stage one, 2.) create a special stage for them, or 3.) just let them receive their updates based on their location. And if you do nothing special at all when building your stages (just doing it by site), you will be applying choice #3.

    Any one of these methods is fine, depending on many different local factors like time constraints, bandwidth constraints, etc.

    🙂

  4. Robert Core

    When you are configuring your stages – is there a way that you can perform your server upgrades and then not push the changes to all the managed WS? I have a server that is at 10.2 and my next update is 10.3.0a and then 10.3.1. I would prefer to just install the 10.3.1 on the managed WS instead of installing 10.0.3.a – rebooting etc..

    Thanks Rob C

  5. Jeremy Pavlov

    @ Robert

    Hmm. I have to admit, I’ve never stopped a deployment like that, but it should be possible. Just make stages for the things you *want* to deploy, advance manually through the stage(s), then maybe delete the update (if it will let you)…? Or you can mass-ignore the remaining machines at that time, and the update will end that way too…

    – Jeremy

  6. Robert Core

    Thanks for the update – I found a snip in the manual that states the following “Any managed devices that are not part of a stage are automatically updated after the last deployment stage has been processed. I guess the question becomes can you delete an update that has not passed all the stages? And will update come back when you refresh?

    Thanks Rob C

  7. Jeremy Pavlov

    @ Robert

    Yep, that’s the question. And now that I think about it, I think you cannot delete an update that has not completed… At least something in the back of my mind is telling me that, but I won’t be able to test that (easily at least) until the next update comes out. But, like I mentioned, you can *stop it* before a stage where the rest of the machines exist, and then do a mass “ignore” of all the remaining machines. Kinda’ seems like a big pain, but if you must do it, then you have no choice it seems.

    Oh, and to the question if it will come back, the answer is yes, it will always re-appear as “available” when deleted, but it won’t re-download itself or re-deploy itself in any way.

    🙂

Leave a Comment

Your email address will not be published. Required fields are marked *