ADR Removes updates from existing Software Update Group RRS feed

  • Question

  • I'm working on using SCCM for Software Updates, was previously only using WSUS. I think I've got everything configured and I can deploy updates successfully. So now I'm working on automating things with some ADRs. The problem I'm running into is that I'm trying to set the ADR to add updates to an existing group. Office 2007 updates in this example.  I have the search criteria in the ADR set to look for Office 2007 updates released in the last 30 days and it is set to run once a month.  So in my mind, each month it will run and add the necessary updates to the existing group, and the group will become a cumulative list.  The problem I'm having is that every time the rule runs, it seems to remove all the existing updates from that group and only add in the updates that were returned for that run.  For example, I can set the rule to search for updates released in the last 60 days and will see 15 updates in the group.  If I change the rule to search for updates released in the last 30 days and run it again, the group will only have 10 updates in it.  Or if I manually add updates to the group and then run the rule again, the updates I manually added are removed.  None of these are expired or superseded.  Any ideas?
    Tuesday, April 7, 2015 5:49 PM


All replies

  • Even though it's not ideal behavior and doesn't match exactly with the explanation in the ADR configuration, it's default behavior. For more details you can look at the ruleengine.log.

    My Blog: http://www.petervanderwoude.nl/
    Follow me on twitter: pvanderwoude

    Tuesday, April 7, 2015 6:04 PM
  • I don't necessarily agree that this is not ideal behavior; however, that reality doesn't matter as it is by design. The first thing that an ADR does when it runs is to remove all updates from the referenced update group. If you are going to use the same update group for an ADR and want to include older updates, you need to expand your criteria to include them.

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

    Tuesday, April 7, 2015 6:37 PM
  • Okay, so it seems like I should just remove the release date criteria and each time the rule runs, have it add all the updates for Office 2007 to that group.  Is that bad idea for any reason?  With the (relatively) low number of Office updates it just seems like a single group would be less admin overhead, compared to the baseline and monthly update group approach that most guides seem to point to for the OS updates.  That's basically what started me on this road.

    Tuesday, April 7, 2015 7:00 PM
  • With just Office 2007 updates that should not be a problem.

    My Blog: http://www.petervanderwoude.nl/
    Follow me on twitter: pvanderwoude

    Tuesday, April 7, 2015 7:17 PM
  • Even with a larger set of updates, there's no issue. Adding updates to a group is pretty trivial and any updates previously in the group already had their content downloaded so there's really nothing to worry about here.

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

    Wednesday, April 8, 2015 3:00 PM

    Hi Jason,

    I'm sure this is all environment dependent, but there are recommendations to not do that.  This article is one that I've been working off to plan this whole thing: http://blogs.technet.com/b/server-cloud/archive/2012/02/20/managing-software-updates-in-configuration-manager-2012.aspx  You really want to avoid frequently modifying deployed update-groups by adding/removing updates to them, as this causes a lot of overhead client-side with policy processing, and server-side with SQL processing.

    Wednesday, April 8, 2015 3:18 PM
  • The spirit of the statement is more or less correct, but as it applies to this scenario it is not. To the clients, nothing has changed. The update is part of the update group before and after. Thus, the client only knows about the newly added updates thus there really is no client side processing churn except for the newly added updates. As for the SQL processing, that's what SQL does well -- that's the whole point of using a enterprise class RDBMS. Tip-toeing around SQL, particularly for a process that only happens once a month, is (sorry) silly. Now, if you were to do this everyday, then yes, that's bad. Once a month, it's trivial. Do of course make sure you have a good SQL maintenance plan in place that includes re-indexing and rebuilding statistics (not the built-in maintenance task). 

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

    Wednesday, April 8, 2015 3:40 PM
  • That's kind of what I figured.  So I'll do it this way for small update groups and not worry about it.  My basic OS plan is still going to be to have a  baseline package of all past updates since that results in a lot of them (~600 for 32 and 64 bit versions of Win7) and then create a new group each month for everything new.  So I think I've got a plan here, thanks for the sidebar.
    Wednesday, April 8, 2015 3:49 PM