locked
SCCM 202 R2 - Automatic Deployment Rules RRS feed

  • Question

  • Hi all,

    just got a question about the way in which the Automatic Deployment Rules work in SCCM 2012 R2. I've got a number of patching collections configured with different types of machines in (Pilot Group, Desktops, Test Servers, Prod Servers etc...) and was hoping to set up a corresponding ADR for each of these collections.

    Having had a quick test of the ADR, it seems to work well. When the Evaluation Schedule deadline hits, I see the updates are downloaded (watching RuleEngine.log) and then a new Software Update Group is created and is deployed to the machines in the collection.

    My question is, what's the best way to set up the ADRs to patch these collections? Does each patching collection need it's own ADR? If so, does this mean I will end up downloading the same updates multiple times since most of the ADRs will have the same Products/Classifications selected?

    Realise this is probably a fairly simple question but can't quite get my head round it so any help/info would be much appreciated!

    Cheers

    Monday, February 23, 2015 3:33 PM

Answers

  • No, it doesn't. I have two ADRs - one for desktops to my Test desktop/laptops collection, another for servers to my Test Servers collection (some people just use one ADR - equally valid).

    I rename the SUG the next day so that it makes sense.

    When I'm happy everything is OK I deploy the two SUGs to production. This takes minimal effort each month.



    Gerry Hampson | Blog: www.gerryhampsoncm.blogspot.ie | LinkedIn: Gerry Hampson | Twitter: @gerryhampson




    Monday, February 23, 2015 3:54 PM
  • That's correct. Updates won't be downloaded to a single update package more than once (I don't like calling them deployment packages even though that's what the console calls them because they have nothing to do with deployments).

    Jason | http://blog.configmgrftw.com | @jasonsandys

    • Marked as answer by Robot Archive Monday, February 23, 2015 4:18 PM
    Monday, February 23, 2015 4:15 PM

All replies

  • No, it doesn't. I have two ADRs - one for desktops to my Test desktop/laptops collection, another for servers to my Test Servers collection (some people just use one ADR - equally valid).

    I rename the SUG the next day so that it makes sense.

    When I'm happy everything is OK I deploy the two SUGs to production. This takes minimal effort each month.



    Gerry Hampson | Blog: www.gerryhampsoncm.blogspot.ie | LinkedIn: Gerry Hampson | Twitter: @gerryhampson




    Monday, February 23, 2015 3:54 PM
  • Hi Gerry,

    thanks for the swift reply. So in your case, do both ADRs share the same Deployment Package (to avoid duplicating downloads)?

    I've got 10 collections I need to patch so was hoping to automate the process as fully as possible. If I set 10 ADRs (all of which run at different times in the month but share the same Deployment Package), am I right in assuming that because they all share the same package, if the first ADR downloads all the updates I need for the month when the other ADRs run they will look in the communal deployment package and say "ah, I can see all the updates I need are already downloaded so I'll just create my SUG from there". By doing this, would I be able to have my 10 SUGs created and avoid downloading the same updates 10 times?

    Thanks

    Monday, February 23, 2015 4:11 PM
  • That's correct. Updates won't be downloaded to a single update package more than once (I don't like calling them deployment packages even though that's what the console calls them because they have nothing to do with deployments).

    Jason | http://blog.configmgrftw.com | @jasonsandys

    • Marked as answer by Robot Archive Monday, February 23, 2015 4:18 PM
    Monday, February 23, 2015 4:15 PM
  • Great, that's what I was hoping! Seemed logical enough but always good to hear it from the experts. Thanks for the help to both of you
    Monday, February 23, 2015 4:18 PM
  • I don't see why you would need 10 ADRs


    Gerry Hampson | Blog: www.gerryhampsoncm.blogspot.ie | LinkedIn: Gerry Hampson | Twitter: @gerryhampson

    Monday, February 23, 2015 4:19 PM
  • Well I figured this was the only way have 10 SUGS created automatically each month. Is there a way I can set 1 ADR to automatically create 10 SUGs every month? If so, I'd certainly rather do that. The more automation the better!
    Monday, February 23, 2015 4:29 PM
  • No you can't. Perhaps a better question is - why do you need 10 SUGs each month? What is wrong with Desktops March & Servers March (or even just a single Updates March)?


    Gerry Hampson | Blog: www.gerryhampsoncm.blogspot.ie | LinkedIn: Gerry Hampson | Twitter: @gerryhampson


    Monday, February 23, 2015 4:30 PM
  • There's nothing wrong with having a more simple patching schedule - unfortunately for me, our server/desktop hierarchy is fairly complicated and I'm bound by certain restrictions in terms of how and when I can patch things. Still, good to know I can automate it with ADRS. Thanks again for all the advice!
    Tuesday, February 24, 2015 8:44 AM
  • There really are three possible strategies here:

    - Use an ADR for each collection. This will of course cause duplicate update groups but will be fully automated.

    - Use a single ADR for each OS type; e.g., one for workstations and one for servers. Then manually add deployments to the appropriate ADR for each collection. This requires a bit of manual intervention but its not much and offers a QA checkpoint.

    - Use a single ADR targeting a master collection and then use maintenance windows to control deployment times to "sub-collections". This is fully automated as well but does require some manipulation of the maintenance windows on a month to month basis.

    I often do a combination of the above depending upon the exact needs of the environment.


    Jason | http://blog.configmgrftw.com | @jasonsandys


    Wednesday, February 25, 2015 3:16 PM