19 votesFausto Nascimento commented
Well this removed my formatting, so the collection structure I meant below is this:
--All Company Devices (basically excludes unknown computers)
------All Windows 7
------All Windows 10
--------All Windows 10 1703
--------All Windows 10 1709
------All Windows Server 2012 R2
------All Windows Server 2016Fausto Nascimento commented
@Paul Actually the problem is much bigger than what is described here (last I had a look at it at least).
Incremental updates works by keeping track of the resource types that have changed since the last incremental update cycle ran (there's 4 resource types I know of: device, user, group and unknown device).
When it runs the first thing is does is determine, out of all collections marked for incremental updates, which *should* based on the known resource types that were changed and the types of queries in collections marked with incremental updates.
Once it's done that, it evaluates those collections and if those collections had any changes, it does the same for its children.
There's a massive bug here in the sense that if you create a new user in AD and it gets picked up by SCCM, it will say that a resource of type user has changed since last incremental evaluation cycle. When that cycle next runs, it will check which collections need to potentially be evaluated. It will mark "All Users and User Groups" as needing to be evaluated (since it has a user resource query) and also "All Users" (for the same reason) but it will *not* evaluate "All User Groups" because that collection contains no user resource queries, just group resource queries.
So far so good. However... when it evaluates "All Users and User Groups" the collection membership will change because a new user got added and as part of that it will force an evaluation on all child collections (including "All User Groups", even though it had already been marked as not requiring an update).
Yes limiting all group resource related queries to "All Groups" will minimise the extent of the problem somewhat. But that's false security.
If I have 5 OSs on my organisation (Windows 7, Windows 10 1703, Windows 10 1709, Windows Server 2012 R2 and Windows Server 2016) it makes sense to create the following collection structure to begin with:
All Company Devices (basically excludes unknown computers)
All Windows 7
All Windows 10
All Windows 10 1703
All Windows 10 1709
All Windows Server 2012 R2
All Windows Server 2016
(as oppose to a flat structure with everything limited to All Systems)
But here's what the trade-in is:
With a completely flat structure (no All Company Devices, All Workstations, All Windows 10 and All Server collections) if All Systems detects a change, 5 collections will be evaluated - always.
With the layered structure as above, if All Systems detects a change then in a best case scenario 1 collection is evaluated. In a worst case scenario 9 collections will be evaluated (All Systems detects a change, marks its children as needing to be evaluated. All Company Devices detects a change, marks its children as needing to be evaluated. All Workstations detects a change and marks its children as needing to be evaluated and the same for All Servers.
In this particular case it's definitely worth to have the layered approach despite a worst case scenario. But the choice is not always that simple...
So the problems mentioned above are just the tip of the iceberg really...Fausto Nascimento supported this idea ·