Currently there is no option to add a psk to an L2TP VPN when deploying a VPN Profile from Config Manager VPN Profile Wizard. This would be good to have so that it is a one-stop solution, rather than having to continue using CMAK or (as our client wants to do) forcing a powershell script to work. This missing option is the only thing stopping us using the built in tools.

In the new condition "Valid operating system build" added to Windows 10 (w/o CM) compliance policies it would be very useful to have a drop down with build version numbers translated to meaningful names. Otherwise we have to go external and find a version list. Even better if it could be pulled from the CM DB for existing versions in the same way you can with collection queries.

I cant find the documentation on how to configure UE-V, Config item and Baselines with Windows 10 and SCCM. It all seems a bit fragmented. most of it relates to Windows 7.

1607-1 has the EU-V client build in and some templates on the clients but how do I set this up without using any group policies to set the template paths, and how do Baselines work.

When writing scripts for compliance/remediation rules, the font size is tiny, with no way to adjust it. This makes finding critical marks such as closed quotes, very difficult. I realize copy and paste is available, but for quick one or two line powershell scripts, I really should be able to see what I am doing-- or at least have an option to resize the font.

Need a possibility to manage Proxy Settings via config man.

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.

Currently Compliance Baseline can only run in System Context but it can't run in user context. Can we please have this feature in Configuration Baseline?

There should be an option to select existing packages/application other then PS,VBS & JS scripts for Compliance remediation. most orgs just miss out some pcs and compliance is mainly used by many company's to get the software installed to the missing ones.

We can create a collection for non compliant systems and deploy app/package to them manually, but giving an option in remediation option will make it easy/simple and user-friendly.

on the software update dashboard I want to monitor and pursue the non-compliant machines - I cannot see a way, as in other pie charts and other graphs in the various dashboards around the console, of drilling into the list of devices

When a user wants to know if their PC is 'compliant' then the Software Center 'compliance' tab confusingly doesn't relate to their actual compliance with software updates, its for an unused conditional access feature (or am I wrong and the only one confused by this.) users go to the compliance tab and think they are up to date. how can users know if they are patch 'compliant/?

While creating the Configuration Item with Wizard that is based on the File Version using the “Browse” option if the actual file version ends in zeros, the zeros are omitted in the “Value” field, leaving only the digits between 1-9. This causes the CI and later DCM to be invalid, or Non-Compliant. For example, if the actual file version is 2.20.0.0, in CI the File Version value would be populated as 2.2.

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

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.

If we have AllSigned selected as a powershell execution policy either as a global gpo or via the client, any script blocks that are written for detection methods on applications or discovery/remediation for config items will fail since they "aren't signed". Organizations where execution policies are scoped as such aren't able to use these features when the configmgr client downloads the scripts to the staging area and scrambles the script name.