none
Best way to have test patches then roll out??

    Pregunta

  • I have seen different flavors of this question asked and answered but none of them seem to quite fit what I am looking to accomplish.  I manage a network of approximately 700 windows xp point of sale machines.  They all point to a WSUS 3.0 server.  I currently have updates being installed across these 700 machines on various nights of the week in hopes of avoiding a nightmare situation where patches break our application and then we would not be able to sell any product.  I have the WSUS server configured to automatically install anything critical and security.  Also, each POS is configured via group policy.   

    About a month or so ago we had this sort of situation happen.  Long story short, a microsoft patch was released (2661254) that broke one of our applications because of certificate length.  As a result, I was ordered to disable the windows update server until we had a better method to test prior to deployment of patches.

    So my question is - is this possible with WSUS only??  For example, it makes sense to me to have a test bed of locations,  maybe 25 endpoints that patches could be deployed to, maybe the days after each patch tuesday.  Once we were sure that none of these updates were going to harm our application, we could then deploy the the rest of our organization.  

    At first look, I thought of looking at the GPO settings for configure automatic updates - but I don't see how  I can configure to install, for example, every 15 days.  I then noticed that I cannot make the detection frequency more than 22 hours.  

    How should I accomplish this?  What are the best practices?  Should I start looking at other products??

    Thanks

    sb

    lunes, 28 de enero de 2013 18:00

Respuestas

  • So my question is - is this possible with WSUS only??

    Absolutely! In fact, not only is it possible, it's critical -- as you found out the hard way.

    For example, it makes sense to me to have a test bed of locations, maybe 25 endpoints that patches could be deployed to, maybe the days after each patch tuesday. Once we were sure that none of these updates were going to harm our application, we could then deploy the the rest of our organization.

    That's one approach, a particularly common approach where a testing lab is not practical.

    However, in your case if you have 700 identical Point of Sale terminals, I'd suggest that you only need ONE Point of Sale TEST terminal in a lab. Deploy patches to that TEST system, and if nothing breaks, then the next phase would be a 'pilot' rollout to some small percentage of your production systems. (I suggest the PoS terminals close to your office in case somebody needs to do some field work to remediate a glitch in the pilot rollout.)

    At first look, I thought of looking at the GPO settings for configure automatic updates - but I don't see how I can configure to install, for example, every 15 days.

    Here's what you need:

    • A WSUS Target Group just for your pilot systems.
    • A GPO just for your pilot systems configured to do updates on ANY day with a four-hour detection interval. If you're using client-side targeting, assign this GPO to the WSUS Target Group for the pilot systems.
    • A Security Group just for the pilot systems.
    • Apply the GPO to the pilot systems using GPO Security Filtering, and deny the other GPOs to this Security Group.
    • Approve the update(s) for the PILOT Target Group, after your ONE test PoS is patched successfully. They should install overnight. Check the next day to see if they're still working.


    Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
    SolarWinds Head Geek
    Microsoft MVP - Software Distribution (2005-2013)
    My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin
    The views expressed on this post are mine and do not necessarily reflect the views of SolarWinds.

    • Propuesto como respuesta antwesor viernes, 01 de febrero de 2013 22:03
    • Marcado como respuesta Clarence ZhangModerator miércoles, 06 de febrero de 2013 8:07
    jueves, 31 de enero de 2013 18:45

Todas las respuestas

  • So my question is - is this possible with WSUS only??

    Absolutely! In fact, not only is it possible, it's critical -- as you found out the hard way.

    For example, it makes sense to me to have a test bed of locations, maybe 25 endpoints that patches could be deployed to, maybe the days after each patch tuesday. Once we were sure that none of these updates were going to harm our application, we could then deploy the the rest of our organization.

    That's one approach, a particularly common approach where a testing lab is not practical.

    However, in your case if you have 700 identical Point of Sale terminals, I'd suggest that you only need ONE Point of Sale TEST terminal in a lab. Deploy patches to that TEST system, and if nothing breaks, then the next phase would be a 'pilot' rollout to some small percentage of your production systems. (I suggest the PoS terminals close to your office in case somebody needs to do some field work to remediate a glitch in the pilot rollout.)

    At first look, I thought of looking at the GPO settings for configure automatic updates - but I don't see how I can configure to install, for example, every 15 days.

    Here's what you need:

    • A WSUS Target Group just for your pilot systems.
    • A GPO just for your pilot systems configured to do updates on ANY day with a four-hour detection interval. If you're using client-side targeting, assign this GPO to the WSUS Target Group for the pilot systems.
    • A Security Group just for the pilot systems.
    • Apply the GPO to the pilot systems using GPO Security Filtering, and deny the other GPOs to this Security Group.
    • Approve the update(s) for the PILOT Target Group, after your ONE test PoS is patched successfully. They should install overnight. Check the next day to see if they're still working.


    Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
    SolarWinds Head Geek
    Microsoft MVP - Software Distribution (2005-2013)
    My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin
    The views expressed on this post are mine and do not necessarily reflect the views of SolarWinds.

    • Propuesto como respuesta antwesor viernes, 01 de febrero de 2013 22:03
    • Marcado como respuesta Clarence ZhangModerator miércoles, 06 de febrero de 2013 8:07
    jueves, 31 de enero de 2013 18:45
  • Thank you for this reply. I do however, have a couple of questions: I just went through and set up my pilot group. It contains 2 of each type of POS terminal that we have in the field, none of the 2 types exist at the same physical retail location. I set up my GPO and scoped it to my pilot group. I now need to go to my WSUS server and modify my auto approval role (which was - all computers, security and critical updates) to be critical and security to just my pilot group. I modified this rule and saved it - then I went back into the rules and ran the rule now. Will this go out an unapprove everything that was previously approved by my previous rule? If this is not the case, how to I go through and undo the automatic approval for any update that is not currently installed? I created a new group on my WSUS server for the pilot. I am anticipating that when I re-enable the NIC on my WSUS server, this GPO will take effect and my pilot POS systems will be placed in this target group. As far as the "A GPO just for your pilot systems configured to do updates on ANY day with a four-hour detection interval. If you're using client-side targeting, assign this GPO to the WSUS Target Group for the pilot systems." is concerned - if I set them up for any day, 4 hour - this pilot group is live in a store. I want to avoid as many support calls as I can where "my pos rebooted because of a windows update??". I am lost on this one: "Approve the update(s) for the PILOT Target Group, after your ONE test PoS is patched successfully. They should install overnight. Check the next day to see if they're still working." So I have my auto approve policy for my pilot group. How can I tell which updates were most recently installed so that if I know this system is working correctly, I can roll these out to my other (non-pilot) locations?? Thanks again for your response. sb
    jueves, 07 de febrero de 2013 19:56
  • I modified this rule and saved it - then I went back into the rules and ran the rule now. Will this go out an unapprove everything that was previously approved by my previous rule?

    It will not. You will need to explicitly remove the approvals for the "All Computers" group, but this is actually fairly simple. Set the Approval filter to "Approved", select all updates, click on Approve, and set the "All Computers" group back to Not Approved. The approvals you have already explicitly set for your Pilot group will be left in place.

    I am anticipating that when I re-enable the NIC on my WSUS server, this GPO will take effect and my pilot POS systems will be placed in this target group.

    Well, actually, that's already happened, because the group assignment doesn't happen at the WSUS server -- it happens at the client. Of course, with no WSUS server to talk to, the impact of that change is zilch.

    I want to avoid as many support calls as I can where "my pos rebooted because of a windows update??".

    Please do not confuse the Detection Frequency with the Scheduled Installation Time. The Detection Frequency is merely how often the client checks with the WSUS server to see if there are any approved updates that are available to download. The Scheduled Installation Time is when the installation of those updates, and thus the reboot, happens (3am by default).

    The reason you schedule the short detection frequency is to ensure the Pilot group systems get that update the same night that you approved it -- and not a couple of days later. With a four-hour detection, you have a reasonable guarantee that every client in the Pilot group is downloading updates within four hours of the time you approve them. Assuming you approve them before the end of the day (5pm), then we can reasonably assume the clients are all downloading by 9pm, and almost certainly done by midnight -- making a 3am installation a piece of cake even on the busiest of nights.

    So I have my auto approve policy for my pilot group.

    Yeah, this is a bit different than I suggested. I suggested that you have ONE machine that you OWN that is not in production and not actually involved in the sales process. That machine should be patched immediately, on the afternoon of Patch Tuesday (via an automatic-approve rule, a 2-hour detection, and a 4pm installation event -- or maybe even invoked interactively via the WUApp), so that you can see if there are any immediate show stoppers from the available updates.

    If there are no show-stoppers, then you can extend those approvals (manually! before 5pm) to the Pilot Group, and the Pilot Group will get its updates overnight Tuesday-Wednesday, and install (by default) at 3am Wednesday morning.

    How can I tell which updates were most recently installed so that if I know this system is working correctly, I can roll these out to my other (non-pilot) locations??

    The preferred approach would be to know what those updates are that are supposed to be installed before the client ever has the chance to install them. This, though, is a challenge with using auto-approval rules for a pilot group -- you've given up all control over which updates those are. Which brings us back to having one TEST machine, and a second tier of machines, which you've properly identified as your PILOT group. Only if the TEST machine does not blow up are the updates approved for the PILOT group. Any update(s) that blow up the TEST machine do not get approved for the PILOT group.

    However, a Custom Update View can be defined so that you can see the updates that have been approved for your Pilot Group. Then simply sort that list by Release Date. Those updates with a Release Date == Patch Tuesday would be the updates of immediate interest.


    Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
    SolarWinds Head Geek
    Microsoft MVP - Software Distribution (2005-2013)
    My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin
    The views expressed on this post are mine and do not necessarily reflect the views of SolarWinds.

    viernes, 08 de febrero de 2013 0:52