When you create a configuration item you can select "Supported Platforms" but why not also allow the use of "Global Conditions" so we can further restrict how the rule would be appeared?

An example, I need to test for a hotfix being present on Windows 7 x86 & x64 machines but only need the update on laptops.

Currently you cannot define custom OMA-URI settings for Windows 10 clients with ConfigMgr client. You can only define quite limited set of settings. Unfortunately, there are some important OMA-URI settings that should be set on all Windows 10 clients (DataProtection/AllowDirectMemoryAccess), which are not part of limited available settings.

This is now one example, but there will be other examples in the future.

Currently, there is not good way to deploy the setting easily to all clients in the environment.

Is it possible already to create and deploy Wi-Fi profiles with a password option? Without a password it seems not logical to me? Many customers are requesting this functionality for Windows 10 devices (during and after OS deployment)

/Henk

Now that CM caches boundary groups it would be good to be able to define some compliance settings / policy settings against a boundary group and to be able to apply these just as the cached boundary group data is updated.

currently you can only add individual updates

Provide an easy mechanism to manage configuration items for Mac OSX without the need to create shell scripts for user or system preferences. Such as the ability to configure settings for device encryption, disabling USB, setting background images, browser home page, etc. etc. etc.

Automate the Device Guard policy controls using SCCM as the management platform for Device Guard security policies. Integrate the Device Guard policy provisioning during the application build process to reduce the manual efforts.

Bring the SCCM whitelist management on par with competitor security products such as McAfee and Bit9.

Integrate the ability to natively enforce SCAP policy enforcement via SCCM. Provide the capability automatically download SCAP policies from sources such as DISA and other SCAP content providers.

Integrate the application of the SCAP policies into the OS provisioning processes as an option for out of the box compliance at OS deployment before the OS touches the network.

It would be useful, if a compliancesetting scripttype would be able to check the compliance based on the return value rather than all the Output of Stdout.
Now the only way for me is, piping cmds to Out-Null, to ensure that a item can get compliant:

p = some.exe |out-null
if ($p.ExitCode -eq 0){Write-Host "SUCCESS"}
else{Write-Host "FAILURE"}

But for developing/troubleshouting purposes it would be nice, if i havent to catch all stdout output, especially for longer scripts, or tools, which i cannot modify ( 3rd Party vendor )

Today you have to ability to run JScript, Windows PowerShell or VBscript scripts to remediate condition on Clients in ConfigMgr. But sometimes runing a program from a package would also be a very useful. Example, run a reboot program like the Cortech Shutdown tool if computer/server is non-compliant.

We use folders to organize Configuration Items (Applications, Task Sequences, etc.) however there is no place to view all the CIs in a category. You have to click on each individual folder to view those CIs. For example, it would be nice to select Applications and see all of your Apps listed there instead of having to select each folder to view Status or check for duplicates. Each folder should do the same for its sub-folders. Having a column that shows which folder/sub-folder the CI is in would be helpful as well.

You should be able to create a conditional access rule that only the computers with the latest Windows 10 build can access corporate resources.

The latest version is required because it might introduce new security features or some other functionality.

SCCM should be able to leverage STIGs and benchmarks to automate the compliance. SCM appears to have ended support, although it can still be found. It was ok, but to use for SCCM required numerous steps and not all items would transfer.

When creating the Configuration Item (Create Configuration Item Wizard, Settings step) and choosing Registry setting type for the Create Setting window, there are some bizarre registry types mentioned in Data type drop-down box: String, Integer, Date and Time, Floating Point, Version and String Array. Most of these data types are all REG_SZ type. But where is REG_MULTI_SZ? REG_EXPAND_SZ? REG_DWORD? REG_QWORD? REG_BINARY?
There is also possibility to set/check compliance for those registry settings with script, but why the Registry Configuration Item in first place?
These actual registry data types need to be implemented instead of/additionally to currently existing ones.

When creating Configuration Items, it would be nice if we could combine different detection and remediation types. For example, combining a Registry detection rule that would remediate with a PowerShell script.

on the compliance item, add deployments tab with the capability of creating collection from the compliance item. You can do it on the compliance baseline but that is not sufficient as a baseline may have more than 1 CI so your target collection *MAY* have a mix of issues. *OR* just make it where you can deploy a CI in addition to baseline with same capabilities