locked
Limit to collection - how does it work with incremental collection updates RRS feed

  • Question

  • Seeing as in SCCM 2012 all collections must be limited to another collection, and the way limiting collections work is by returning a subset of what is on the limiting collection at the time of evaluation (in other words, if CollB is limited to CollA, when CollB is evaluated, it will return a subset of what's currently in CollA and what is currently in CollA might be currently out of date), how does limit to collection work with incremental collection updates?

    Example:

    If I have two collections, CollA and CollB, CollB limited to CollA, and both collections are set to have periodic evaluation of 60m, CollB will be updated every 60m using the resources currently in CollA, where the data might be up to 60m old (59m if you want to get picky), meaning it might take up to two refreshes of CollB for a resource to be discovered in CollB.

    That's all well and fine with periodic evaluation, but how does it work with incremental updates?

    In incremental updates, the partial update (for resources changed since last incremental update) runs (by default) every 10 minutes, but limit to collections still applies, so if the incremental update of CollB occurs before the incremental update of CollA, the incremental update of CollB finds nothing new, as CollA hasn't been updated yet, then the incremental update of CollA kicks in, discovering the new resource, but by then CollB has already been evaluated and the incremental update will not be re-started for the same resource, meaning at this point either the resource is 'lost' or it requires a full collection update (aka periodic update) to discover the resource.

    Is this something that is already taken care of internally? Does it first update collections without a parent, then the ones that are limited to the parent it just updated, etc etc to ensure they are always updated in a proper order?

    In short, how does limit to collection work with incremental updates?



    • Edited by JohnUbuntu Thursday, July 31, 2014 2:56 PM
    Thursday, July 31, 2014 11:26 AM

Answers

  • Anytime a parent collection gets updated (by full or incremental) it will trigger an update on all child (limiting) collections below it. So if CollA gets updated, it should trigger an update of CollB.

    You didn't state what release of ConfigMgr 2012 and this behavior has changed a bit in SP1 from RTM. So if RTM (why are you still there :-), then it is not as efficient, but SP1 and later is great at it.


    Wally Mead

    Thursday, July 31, 2014 3:54 PM

All replies

  • They are not triggered by a resource change. It's a time schedule.

    When you enable incremental updates for a collection, Configuration Manager periodically scans for new or changed resources from the previous collection evaluation and updates a collections membership with these resources, independently of a full collection evaluation. By default, when you enable incremental collection updates, it runs every 10 minutes and helps keep your collection data up-to-date without the overhead of a full collection evaluation.


    John Marcum | Microsoft MVP - Enterprise Client Management
    My blog: System Center Admin | Twitter: @SCCM_Marcum | Linkedin: John Marcum

    Thursday, July 31, 2014 2:17 PM
  • They are not triggered by a resource change. It's a time schedule.

    When you enable incremental updates for a collection, Configuration Manager periodically scans for new or changed resources from the previous collection evaluation and updates a collections membership with these resources, independently of a full collection evaluation. By default, when you enable incremental collection updates, it runs every 10 minutes and helps keep your collection data up-to-date without the overhead of a full collection evaluation.


    John Marcum | Microsoft MVP - Enterprise Client Management
    My blog: System Center Admin | Twitter: @SCCM_Marcum | Linkedin: John Marcum

    Correct, mistake when writing it down, I'll correct it.

    Still, my question stands as you haven't touched on it.


    Thursday, July 31, 2014 2:54 PM
  • Maybe this excellent post from David O'Brien will help you out - http://www.david-obrien.net/2014/05/10/configmgr-collection-updates/

    You can also check through your colleval.log to help you figure out exactly what is going on. I haven't studied this fully but it seems to work from top down hence your 'child' collection will be up to date. Colleval.log should tell you what is going on though.

    Thursday, July 31, 2014 3:42 PM
  • Anytime a parent collection gets updated (by full or incremental) it will trigger an update on all child (limiting) collections below it. So if CollA gets updated, it should trigger an update of CollB.

    You didn't state what release of ConfigMgr 2012 and this behavior has changed a bit in SP1 from RTM. So if RTM (why are you still there :-), then it is not as efficient, but SP1 and later is great at it.


    Wally Mead

    Thursday, July 31, 2014 3:54 PM
  • Hi Wally thank you for the reply and the explanation.

    It's actually ConfigMgr 2012 SP1 CU4 so assuming no more changes in R2  it should be as you described :)

    That's sort of what I expected, I just didn't expect the the parent to trigger an update on all child limiting collections.

    One thing I noticed though, I was going through the collEval.log and noticed that a full evaluation takes as long to run as an incremental update. I tested this by checking the logs for how long it took to run the express evaluation on SMS00001 and then doing a manual update of that same collection. Both incremental and full updates show 2.5~ seconds.

    The environment is currently in non-prod so as more systems are added we could very quickly start seeing the times it takes on a incremental vs full update change, but atm it's a bit puzzling.

    Thursday, July 31, 2014 4:11 PM
  • If you were running R2, there is a new tool in the ConfigMgr 2012 R2 toolkit, CEViewer, that can help with this identification of collection updates and times. But it only works on R2, so for now, you'll have to go with manual observation using logs.

    I have never paid much attention to the timing of them in the logs to know if it is just a coincidence given the size that they are the same. I assume it is, and as you get larger environments, you will see differences between incremental and full.

    Oh, and by the way, I am pretty sure that incremental runs every 5 minutes by default, not 10. You can see it in the logs, and the default configuration is 5 in Site Configuration, sitecode, Configure Site Components, and Collection Membership Evaluation.


    Wally Mead

    Thursday, July 31, 2014 4:25 PM
  • So, another quick question, you said that when a parent collection gets updated, be it a full or incremental update, the collections that are limited to that collection also get updated.

    Is this the case even if a 'child collection' doesn't have incremental updates enabled?

    So if I have CollA with incremental updates enabled and CollB which is limited to CollA but without incremental updates, when CollA updates via incremental updates, does that also trigger an update on CollB even though incremental updates are not enabled on CollB?

    Thursday, July 31, 2014 5:52 PM
  • I believe that is still the case. We need to ensure that dependent collections are up to date when the parent collection is updated. Should be easy to test and validate :-)

    Wally Mead

    Thursday, July 31, 2014 5:55 PM
  • So but if that is the case, then effectively all collections are already set to perform incremental updates, as in one way or another, they'll all be limited to a system collection that has incremental updates switched on.

    Then I don't see the logic behind allowing incremental updates to be switched on on other collections.

    Thursday, July 31, 2014 6:10 PM
  • Only if the parent collection is updated, then it will trigger an update. But consider the following:

    CollA is top level collection

    CollB is limited to CollA

    CollC is limited to CollA

    CollD is limited to CollB

    CollE is limited to CollC

    Now if an update is performed on CollA, but only affects collections in the CollB 'tree', then only CollB and CollD are updated, CollC and CollD are not.


    Wally Mead

    Thursday, July 31, 2014 6:52 PM
  • Completely agree with that logic.

    But...

    Let's agree that the parent collection always has incremental updates on, as it's a system collection and they all have incremental updates enabled (with the exception of one, still not sure why just one doesn't have it).

    Because all collections must be limited to other collections, unless the parent collection has incremental updates enabled, then none of the child collections discover anything new, as its results will be limited to what is currently displayed on the limiting collection.

    In other words, if the following were to occur:

    'All Systems' is top level collection, incremental updates disabled

    'All Workstations' is limited to 'All Systems', incremental updates enabled

    'All Servers' is limited to 'All Systems', incremental updates disabled

    'All Windows 7 Workstations' is limited to 'All Workstations', incremental updates enabled


    Let's say a brand new computer, completely unknown to SCCM before this, is imaged with Windows 7.

    The next time incremental updates kicks in, it evaluates 'All Workstations', which is aware of the new resource, but cannot add it to the collection since it is limited to 'All Systems' and it doesn't exist in the 'All Systems' collection, as incremental updates is switched off. The same happens with collection 'All Windows 7 Workstations'.

    So, the parent collection always has to have incremental updates enabled in order for it to work for child collections (correct me if my logic has gone wrong somewhere).

    Now, if when a parent collection is updated (regardless of whether it's full or incremental update), all relevant child collections are also updated, then surely just having the top level collection with incremental updates on should suffice to ensure all relevant child collections are also updated when the parent one is.

    In other words, the following two scenarios should produce "exactly" the same results (quotes on exactly because one will put bigger strain in the system and might actually update the collections slightly more often, but only with a couple of seconds in between):

    Scenario A:

    'All Systems' top level collection, incremental updates enabled

    'All Workstations', limited to 'All Systems', incremental updates disabled

    'All Servers', limited to 'All Systems', incremental updates disabled

    'All Windows 7 Workstations', limited to 'All Workstations', incremental updates disabled


    Scenario B:

    'All Systems' top level collection, incremental updates enabled

    'All Workstations', limited to 'All Systems', incremental updates enabled

    'All Servers', limited to 'All Systems', incremental updates enabled

    'All Windows 7 Workstations', limited to 'All Workstations', incremental updates enabled


    So, if an unknown computer is re-imaged with Windows 7, when incremental updates starts evaluating, it will add it to 'All Systems'. Because 'All Systems' was modified, it checks to see whether any child collections need updating as well. It knows it's a workstation, so the child 'All Workstations' collection gets updated as well, and it checks if any collection that has 'All Workstations' as a parent requires updating as well, which in this case, knowing the OS is Windows 7, refreshes the collection 'All Windows 7 Workstations' as well.

    This should be true for both scenarios if I understood what you said properly.

    • Edited by JohnUbuntu Thursday, July 31, 2014 7:35 PM
    Thursday, July 31, 2014 7:31 PM
  • Sorry, the formatting now has gotten in the way (indented too much now to read effectively :-(

    From what I understand, you do not need to have incremental updates enabled on the parent for this to work, it should work on a full collection evaluation also.

    I've provided what I think I know, from here, you'll need someone else, or your own testing to confirm.


    Wally Mead

    Thursday, July 31, 2014 7:39 PM
  • Ok, thank you.

    One last question (promise!):

    Do you know exactly how the back end of incremental updates works?

    So I imagine there's some sort of an int somewhere that gets incremented every time there is a change to a resource (through a DDR).

    I imagine you use that to determine which resources have changed since last the last incremental update, by checking any resources that are higher than X, where X is the number of the highest change that occurred on the last incremental update.

    So far, this is all exactly the same stuff you do for AD Delta Discovery.

    However, where it gets slightly more complicated is that for each collection that had incremental updates enabled, you now need to determine whether each of the resources you know changed belongs should belong in the collection you are evaluating.

    And because each collection has a unique query of its own, the only way I can think of of finding this out is by running the query from each collection, probably with a "WHERE ResourceID = xxx" added to the end in order to reduce number of entries returned.

    Do you know if this is the case or can you explain how it works if I'm completely off?

    Thursday, July 31, 2014 9:36 PM