4 Replies Latest reply on Oct 6, 2014 10:21 PM by kjabney

    agent upgrades on a large scale with bandwidth issues

    becke

      how are you handling product upgrades on a large scale where bandwidth is important

       

      for example - say I have ~ 25,000 machines in ePO and I see that the delegated people in various divisions have not been updating the agents in their sections and now at a global level we wish to enforce that since a) they've had enough time to test it and b) vulnerabilities and other issues

       

      so we have about 10,000 various flavors of 4.6 and about 4,000 older versions of 4.8

      bandwidth is an issue - if I just set everything to upgrade instantly it would make a visible impact on the network -

       

       

      what I have been doing is

        create a query to find machines to upgrade, limited to 3,000 results, and sorted by last communication date desc

        apply a tag to those: "ugprade agent"

        apply a client task at the root of the system tree to do an agent deployment to current branch for machines with that task, 1x day starting at midnight randomized for 24 hours

       

        every couple of days I run a query to find machines that have been upgraded and still have the tag - and remove the that tag.

        and then rerun the original query to make sure and tag another 3000 or so.

       

      this is a rather manual process though, and also at the end there are things like laptops and other devices which for various reasons have not connected for say a few months (maybe have been left off) that are hard to catch and tag.

       

      I'm wondering if there is a better way or what other people are doing in such scenarios.

        • 1. Re: agent upgrades on a large scale with bandwidth issues
          fitchsoccer342

          This is where SADR's can greatly help out. Do you have any SADR's setup?

           

          I am managing around 10k systems; we have 3 SADRs setup with agents going to them for product installs/updates based on subnet distance. This way when you do large scale deployments, tons of machines won't be hitting the same server.. you are doing the client task right with enabling randomization, but I've never done randomization at 24 hours.

          • 2. Re: agent upgrades on a large scale with bandwidth issues
            becke

            yes - we have multiple SADRs (looks like about 20) but at the same time our network is spread across a very large geographic area with *many* sites and some of the connections are very thin indeed.

             

            the way I'm currently doing it works... it's just kind of manual in that I have to run queries then apply and remove tags.

            • 3. Re: agent upgrades on a large scale with bandwidth issues
              becke

              since there are no other suggestions I'm going to stick with this methodology for now.

               

              the only addition is that I'm adding some server tasks that will run the queries and add/remove the tags for me.

               

              since the query used to apply the upgrade tag has a max results limitation it should deploy slowly enough and I will just schedule the server tasks to run them 1x day.

              • 4. Re: agent upgrades on a large scale with bandwidth issues
                kjabney

                Adding the server tasks was the only additional suggestion I was going to make. Without knowing your environment and setup it makes it a little difficult to assess. For example, do you have different groups in your System Tree? You could add the Assignment Path to the filter on the query and work through in sections. Anything common about the host/system names so that you could pattern a filter there (i.e., Starts with "SALES")? If your System Tree structure is relatively flat, you can create a sub-group in one or more sections so it inherits the policies from the parent group and then move the systems with old agents into it. Once the agent is installed, you could have a query based server task move them back. You could create a tag for different days of the week (e.g., Mon, Tue, etc.) and have multiple queries/server tasks so you could pre-stage multiple groups of systems so you don't have to tag systems every day.

                 

                May not have given you a specific solution but hopefully some ideas to help you create/improve your current process.