Microsoft Endpoint Configuration Manager Feedback

Suggestion box powered by UserVoice - Update: Microsoft will be moving away from UserVoice sites on a product-by-product basis throughout the 2021 calendar year. We will leverage 1st party solutions for customer feedback. Learn more

Fausto Nascimento

My feedback

  1. 187 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)
    5 comments  ·  Ideas » Collections  ·  Flag idea as inappropriate…  ·  Admin →
    An error occurred while saving the comment
    Fausto Nascimento commented  · 

    Well this removed my formatting, so the collection structure I meant below is this:

    All Systems
    --All Company Devices (basically excludes unknown computers)
    ----All Workstations
    ------All Windows 7
    ------All Windows 10
    --------All Windows 10 1703
    --------All Windows 10 1709
    ----All Servers
    ------All Windows Server 2012 R2
    ------All Windows Server 2016

    An error occurred while saving the comment
    Fausto 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 Systems
    All Company Devices (basically excludes unknown computers)
    All Workstations
    All Windows 7
    All Windows 10
    All Windows 10 1703
    All Windows 10 1709
    All Servers
    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  · 

Feedback and Knowledge Base