9 Replies Latest reply on Oct 3, 2013 3:04 PM by klevitan

    Thoughts on effective patch management for scalability

    Rookie

      Today we have landesk running queries against AD OU's that are broken down by our sites and within each site is an OU called Group 1,2,3,4 etc.. We link a repair job to each group and run those during the week. The problem is we are growing larger. By next year we could have as many as 800+ computers. Patching by groups linked to AD OU's will take forever... Each group now currently has about 50 PC's. Any thoughts on how to scale for long term?

        • 1. Re: Thoughts on effective patch management for scalability
          Specialist

          Do you have the latest version of LDMS?  If so i would higly recomend using scopes to point to those OU's so you can release the patches per scope. Then in the agent settings you can set a maintenance window for the systems and how many time they are allowed to patch/reboot durign that time. I tihnk this would let you just use the auto scan and repair settings instead of having to deal with scheduled task

           

          We are surrently testing this method with our servers and it has worked well with a small group of systems. Next i will be applying this method to all servers and hopefully our workstations as well.

          • 2. Re: Thoughts on effective patch management for scalability
            Rookie

            We are using version 9.00.0.473 sp2

            • 3. Re: Thoughts on effective patch management for scalability
              Specialist

              What i did when we were on 9.0 was to use the custom groups in patch and compliance. So i would have an agent that pointed to each custom group. In the scan and repair settings for the agent you point it to the groups and then check the box for "Immediately install (repair) all applicable items" We used this for our servers and Pilot patching for workstations.

               

              In this setup when you put the vulnerabilities (or any other items) in teh directory the system will pick it up on the next vulscan.exe run. Then for servers i would just setup a reboot task and schedule a few reboots during patch weekend since we could not have them just rebooting when ever they needed it thought out the week.

              • 4. Re: Thoughts on effective patch management for scalability
                Rookie

                How many nodes where you patching with this setup?

                • 5. Re: Thoughts on effective patch management for scalability
                  Specialist

                  We have about 83 servers and around 500 laptops/desktops. Some of teh servers still have to be manually patched because of the software/clustering that is configured on them. The workstations were are not forcing reboots currently since most are laptops and get restarted on regular basis.

                  1 of 1 people found this helpful
                  • 6. Re: Thoughts on effective patch management for scalability
                    Specialist

                    If you would like to discuss more detail feel free to get my email from profile. I would be glad to help out, patching has been something i have tried allot of ways to make it more automated since i do the majority of it on my own

                    • 7. Re: Thoughts on effective patch management for scalability
                      klevitan Specialist

                      This might not fit your needs but it works for us.  We have 8000 (and growing) workstations.  We do our deployments in 3 phases (after a couple of test phases).  Phase 1 targets 10% of the population, Phase 2 40% and Phase 3 50%.  To create the groups I uses Data Translation Services to create a new field called groupnum and it just takes the last character of the Computer ID field.  This gives us a number from 0 to 9.  So my queries include groupnum = 0 for 10% of my population.  For 40% I group 4 values.

                       

                      We also use different agent configuration names for major departments (eg: School of Engineering) or special systems (eg: KIOSKS).  This allows us to target just those departments based on agent name.  We have multiple AD in our environment (University) and not everyone is joined to the domain so using AD information is not as reliable for us.

                       

                      - Kurt

                      • 8. Re: Thoughts on effective patch management for scalability
                        Rookie

                        What is Data Translation Services? What It comes down to with us is that we are going to have to spend more time patching... unless we patch more than 50 computers at once. The problem is our landesk server is sooooo under powered and the other half of our company uses it for their 2000 workstations and we are only at 400 stations. The other issue we are only allowed 2 weeks a month for patching so 1 week is used for test workstations and test servers and the othe week we go live and through out that week we deploy the patches... I am just imaging next year when we get another 400 stations....

                         

                        Now we stage the patches on the machines before we run the repair.... How many machines could we do at once?

                        • 9. Re: Thoughts on effective patch management for scalability
                          klevitan Specialist

                          DTS is part of what used to be called Managed Planet.  LANDesk now owns them.  It is a must have addon for all LANDesk admins.  It allows you do import AD info in to the inventory, normalize data, cacluate new data fields, import warranty information from vendors, etc.