Please create a field and store the free disk as a percentage of the volume size that can be used as a collection query. This will be helpful when trying to find systems that are at risk. With so many types of computer and so many sizes of hard drives, a static amount of disk space available isn't always as telling as a percent can sometimes be.

The main reason for the ask is we're considering peer cache and want a way to "disable" peer cache if the percent of disk space falls below "x" percent and there doesn't seem to be a way to calculate this value on the fly using WQL.

So we're starting to get a ton of functionality around making REST calls into ConfigMgr to do things, but I would love the ability for ConfigMgr to make a REST call into another system to populate a collection.

For example, grab all systems with the "VIP" attribute in ServiceNow and place them in a collection. Though this can be achieved today by pushing the data from ServiceNow into ConfigMgr or writing scripts around it, it would be much simpler if it was built in and supported to do these types of pulls. I envision it working just like a query rule today, allowing for collection to dynamically update as things change on the external system.

Correct behavior of the "Add Resources" button (SCCM all versions).
When you use the "add resources" (to collection) button it uses the RBAC_InstancePermissions and does not take into account the limiting collection.
This is a problem in an environment where people take up different roles. For instance when you have different geographical units (each with limiting collections) and people have an additional read-only role for example for everything.

In this case the code behind a "direct membership" rule has the correct behavior, while the code behind the "add resources" button allows to add any resource.
Since the "add resources" button is applied on a collection it should take into account the limiting collection as well. Actually it doesn't.

Query behind "add resources"
select all SMSRSystem.ItemKey,SMSRSystem.ResourceDomainORWorkgr0,SMSRSystem.ItemKey,SMSRSystem.Name0 from vSMSRSystem AS SMSRSystem where (SMSRSystem.ItemKey in (select all SMSDirFullCollMem.ResourceID from vSMSDirFullCollMem AS SMSDirFullCollMem where SMSDirFullCollMem.CollectionID in (select all SUIP0.ObjectKey from RBACInstancePermissions AS SUIP0 where (SUIP0.AdminID in (16777222,0) AND ((GrantedOperations&1) = 1 AND SUIP0.ObjectTypeID in (1))))) AND ((SMSRSystem.Obsolete0 is null OR SMSRSystem.Obsolete0 = 0) AND SMSRSystem.Name0 like N'%%%')) order by SMSRSystem.Name0

Thanks for taking this into consideration.
Kind regards.

Presently, we have to have separate maintenance windows for each node of a cluster to prevent them from rebooting at the same time. I got excited when I noticed the Server Groups feature and thought we might finally be able to ditch the separate maintenance windows, but it turns out Server Groups only apply to Software Updates only.

If I were to move away from using separate maintenance windows and implement Server Groups instead (which I really want to), there would be nothing stopping someone from creating an app deployment or a program which reboots both nodes of a cluster at the same time.

I can't even work around this problem by creating a separate maintenance window that only applies to software distribution because it's not an option - you can make maintenance windows that apply to OSD and software updates only, but not software distribution only.

Please make server groups apply to all deployments by default, or at least give us the option of selecting what kinds of deployments they apply to.

I'd like a possibility to exclude some date from the maintenance windows schedule, or add an "effective end date" after wich the MW would stop.
my scenario
windows every two week on Thursday, I'm asked to skip the next one due to exams or other reason (school environment.) several time a year.
right now I change the effective start date for after those event, but I can't do it too much in advance, or there won't be any maintenance until this new effective date.
and if I do it too late, then the computers may not receive the new settings in time.

An exclusion date that I could set up in advance would be of a great value for me, and it should have the priority over any maintenance windows.