4 Replies Latest reply on May 2, 2017 9:15 AM by tao

    Update Process on Patches

    jwood.mls

      I've never been completely comfortable with the update process to various components, because it seems that they never happened enough that I got comfortable. 

       

      Recently, with patches coming out more frequently and being required due to updates in Windows 10, for example, I've done a bit more.  What I do is in my update task, uncheck that all components are being updated in ePO, then I check in the patch and force update on a number of systems prior to re-checking the all components update and allowing the rest of the systems to update as a task.

       

      While I think that this is a valid way to do things (support is the one who I got this from), I'm curious about the "testing" phase of the patches.  I have 900+ systems, for example.  I'd like to know with those of you with more experience what the "incubation period" should be before wide release.  Or how many systems to I need to test on before wide release?  I realize it is probably somewhat subjective, but I don't have enough experience to know how likely it would be that a VSE patch would cause any kind of issue.  I'd like to get my processes a little more streamlined.

       

      Thanks!

        • 1. Re: Update Process on Patches
          tao

          Quick write-up on the releasing of DATS, Updates/Hotfixes, Patches or New Versions in an environment:

          DAT Release: 24 hrs from the time McAfee released

          Update/Hotfix: 2 - 4 Months from the time McAfee released

          Patches: 2 - 4 Months from the time McAfee released

          New Version: 3 - 6 Months from the time McAfee released

           

          Couple of areas to consider: 

          1) If any of the above remediates a current issue then the testing/release time would be within 1 - 24 hrs; otherwise, to be on the bleeding edge of technology sometimes means you will bleed when you apply the latest greatest.  If that's acceptable within the culture environment then release as soon as McAfee releases.  If not, figure out a middle ground and test away.

          2) Test group should include servers/workstations that are actually being used in the production environment; spinning up a virtual and then doing nothing with it will provide a false sense that the update/hotfix, patch or new versions works in the production environment.

          3) Granted, all this is govern by resources available (staff/time/systems/funds), regulatory or business requirements, policies and/or your culture environment.

          1 of 1 people found this helpful
          • 2. Re: Update Process on Patches
            johnmoe

            Another way to manage this would be to create a separate agent policy for the testing systems, and have them use the Evaluation branch for updates, while leaving the bulk of your systems on Current.  Then, check the new packages to be tested into Evaluation, and when you're comfortable with it, put it into Current as well.

             

            Then it's just a matter of assigning the policy, such as by System Tree group or tagging and policy assignment rules.

            • 3. Re: Update Process on Patches
              jwood.mls

              @tao

               

              Interesting, so even patches that are required for creator's update, for instance, you wait 2-4 months? 

              • 4. Re: Update Process on Patches
                tao

                Couple of areas to consider:

                1) If any of the above remediates a current issue then the testing/release time would be within 1 - 24 hrs;