Clients stored in a (temporarily) collection by a direct rule remain there until someone takes care if this is still needed. In my case this is done for packages which fix some issues and need to run only once on each defined client. Yes, this can be done by compliance settings or a query but it is easier for support staff picking a client and place it into a collection that fixes something a user is complaining about in a service ticket.
So the wish is, that the collection clears (not deletes) itself after a specified time.

You may have some Packages which do some magic on your clients during

SCCM Version Number and CU level
SCCM 1610
Customer has SQL 2012 with SQL Compatibility mode 2012.

Observed behavior:

The behavior is like this:

• We have a collection A (BCS026B0)that contains 80.000 objects (or 100.000). It is big.
• If we create a new collection B that is limited to A, once the update cycle for the collection B the SQL query will run with the ;WITH LimitedBaseTable as
• This will generate a blocking and will never end.
The above behavior is not always reproducible with all big collections.

What we think would be useful is to add query timeout for this kind of scenarios (Big Limiting collections )

We figured out that if you create a time consuming/complex query for a collection which runs very long, the whole SQL server is crashing after a few hours.
The query can be designed within SCCM console, but seems to be too complex for the system.
The result is that the collection evaluation takes too long and is not terminating after some time.
All other collections evals will wait for this to complete. DUe to the fact that this takes too long, all others will get queued in tempdb.
The result ist that the tempdb grows and grows until the whole disk space is used.
The result is that the server crashes.

The only solution ist to restart SQL server which will cleanup tempdb and the disk space used.
After collection eval is running again it is fine until those blocking collection gets affected.
Then you will have the same situation as before.

In our opinion we are talking about a not acceptable situation/bug, because a simple query can crash the whole system. In the end no software assignment or OSD will work.

Collections are part of global data. As such, all settings on collections are replicated from any Primary to the Central Administration Site and then down to the other Primaries again.
This includes the membership queries, the way collection membership is evaluated (incremental, full) and when this evaluation is scheduled.

My customer's IT is arranged into different Business Division, each with a high autonomy on how to manage local workstations.
For reasons too long to explain, some of the business divisions need a high number of collections with incremental membership evaluation. They accept that their incremental evaluation cycle lasts +25 minutes instead of the default 5 minutes.

However, as incremental evaluation is part of global data, this means that those same collections are also incrementally evaluated for membership in the other Primaries. Those collections are of no use to the other business divisions.

In this setup, each business division's incremental membership evaluations are negatively impacting the Site Server performance at other business divisions for no reason at all.

They would like to be able to define membership evaluation settings on collections on a per site basis.
Another option would be the ability to choose - on a collection per collection basis - if the collection needs to be part of global data or not.

We have a 5-minute, non-recurring maintenance window starting 1/1/1970 1:00 AM configured on several critical device collections to prevent reboots due to accidentally-configured deployments - and this worked as of SCCM 1511. In 1606 though, when I try to edit that maintenance window, I receive an un-handled ArgumentOutOfRangeException (Value should be between 'MinDate' and 'MaxDate').

Creating a new maintenance window starting 1/1/1971 1:00 AM (the UI won't even allow you to set 1970, it'll just flip it back to the previous value) and deleting the older one works, but this is certainly a bug. I don't know yet if other DateTime pickers in SCCM 1606 are affected too.

Thanks