The user will not receive any deployments until their kerberos ticket has the AD Security Group membership update reflected.Most commonly this only happens during a lock / unlock or logoff / logon.
That’s bad for several reasons, one, you can’t use Role Based Administration properly with this, second, you will get problems with you collection updates. Furthermore via Hardware Inventory we know that it’s a Workstation.
The following pretty picture (powered by MSPaint) is supposed to show you an easy collection design. If I say ‘Update Membership’ on ‘All Systems’ then the collection evaluation (Coll Eval) process will kick in and check for any new members in All Systems. Coll Eval will now check ALL the collections that are limited by All Systems if these collections are going to be affected by this new member.
This is a topic I haven’t seen much covered around but is quite important, especially if you’re managing an environment with a lot of clients, regular changes and a lot of collections.
According to Technet ( Collections in System Center 2012 Configuration Manager provide a method of managing groups of computers, mobile devices, users, and other resources in your organization.
Once the resource is located you can choose to create a new collection and set the limiting collection to “All Users and User Groups”.
All updates (full and incremental) can be removed to avoid any type of load. Change the default search for Resource class and Attribute name to User Group Resource and User Group Name.
Roger Zander wrote a brilliant article on Collections in Configuration Manager and some knowledge that aids in designing collection structure to reduce the workload of the Config Mgr hierarchy.
One thing that I remember evaluating a few years back was to leverage direct memberships to a Active Directory Security Groups to reduce the total evaluation time for collections.
This has to do with limiting and limited collections.
Are you maybe a bit lazy and limit ever collection by ‘All Systems’?
It’s not doing a full update, which means that it usually has less performance impact on your SQL box. It all depends on your use case and your environment. They had 900 collections configured for incremental updates. Looking at their gave me the following rough numbers: Cool :-) And after 5 minutes the component tried to run the next incremental update, where it wasn’t nearly finished with the first run, then after another 5 minutes the third and so on…I ended up creating a script which would turn the incremental updates off on those collections.