Windows Updates - Advise on pre-prod / testing

[Rumpole]

Hi people,

 

I'm going through the process of setting up monthly windows updates in a new environment & I want to ensure that we have the capability to deploy updates to test collections before distributing to the production systems (both client OS's & server OS's). For background info, AnyWeb's step-by-step monthly updates guide has been followed (for the most part) for the configuration of the ADR's.

 

Essentially I want to be able to use ADR's to deploy updates to my 'test' collections, then allow a week or so for testing, then when I'm happy they haven't caused any issues, deploy them to the production machine collections.

 

I've given it some thought and have come up with 3 approaches. I've listed these below:

 

Option 1) Create 2 x ADR's for each product. Both ADR's will run once a month at more-or-less the same time. One ADR will target the 'test' collection and will have the deployment schedule availability set to 'ASAP'. The second ADR will target production, and will have the deployment schedule availability set to 7 days. Both will have deadlines of 14 days... This should allow me 7 days to test the updates with members of the test collection. If I don't like any of them for any reason, I can remove the production deployment or edit the updates in the group to remove any bad ones.

 

Option 2) Just use a single ADR for each product. The deployment will be targeted at production machines and the installation deadline will be 14 days. For this option to work, I would need to ensure full testing is done before the 14day auto-install kicks in. Any bad updates would have to be determined and removed before the 14days were up. It would also rely on users not being 'proactive' & going into the software centre & installing the updates themselves in advance of the deadline.

 

Option 3) Just use a single ADR for each product. The deployment will be targeted at a test machine collection and the installation deadline will be 14 days. I would then test the updates and ensure they all worked, removing any bad ones from the update group if they are found. Once happy with the testing, I would then manually change the target collection of the software update group that was created by the ADR to the production machine collection.

 

Thoughts anyone ? I'm hoping some people here can share what has worked for them in their production environments.

 

Cheers!

Rumpole

[pembertj]

We do something similar where I work. We have an alpha collection (50 computers), beta collection (200 computers), all computers (all computers at location). We have one adr for each collection - they deploy at the same time but the amount of time until "required" increases for each group. This has allowed us to catch almost all problem updates while in "alpha" with a few making it until "beta"

[Rumpole]

Thanks pembertj,

I've read a number of other posts on the topic & the key thing I've learned is that there can be more than one perfectly valid solution & that it really depends on the specific needs/wants of the business..

For us, we will do a variation of what I listed as 'option 3'. I will combine that with maintenance windows set on specific collections to control when the updates get installed.

[wilbywilson]

You're right. There's more than 1 way to skin a cat. I think the optimal solution is dependent on the size of your environment, and how involved your (change) management team is.

 

I used to a work in a large environment, and we were not allowed to use ADRs to deploy Windows patches (we had ADRs for Endpoint definitions, but not for full-on Windows patches.) You might think putting together a package each month is extra work, but having the control over exactly which patches you select is worth it. Microsoft will inevitably stick in some patches you probably don't need/want, if you're not careful.

 

We would target the patches to a test collection, for at least 5 business days. We'd actually run some reports on that test collection, showing that X percentage of that collection received the patches, and review the HelpDesk tickets to make sure there were no common/widespread problems. If all was well, we'd then create a *new* deployment, targeting the remaining machines. (Actually, 1 deployment for servers and another for workstations, with the difference being the enforcement deadline.) But splitting them into separate deployments is key, because if management every comes back to you when there is an unexpected problem, you'll be able to show them your test deployment statistics, with the associated SCCM reports you already have in hand. If you just re-use the existing deployment and re-target it, your numbers/reports will be skewed. So I always created new advertisements when moving to production.

 

Best to cover your bases, before an ADR distributes something while you're on vacation, and blows something up

 

Thanks pembertj,

I've read a number of other posts on the topic & the key thing I've learned is that there can be more than one perfectly valid solution & that it really depends on the specific needs/wants of the business..

For us, we will do a variation of what I listed as 'option 3'. I will combine that with maintenance windows set on specific collections to control when the updates get installed.

[Garrett804]

You can do one ADR since your criteria is the same even if you did more than one. Then just do separate deployments with different available and deadline times.

 

Makes less groups to manage and packages as well.

 

For instance I deploy immediately when the ADR runs for my monthly workstation patches with a deadline of 3 days for my pre-production group. That is one deployment.

I then have another deployment that goes off at the same time but is set to make available 1 month from the time the ADR runs (patch Tuesday) and a 7 day deadline after its made available. This goes to my production which is all systems.