At the moment it is not easy to add requirements to an application deploymenttype with PowerShell. I think many of us would benefit if this would be simplified.

Since version 1707 it's now possible to run Powershell scripts for a collection, but these scripts cannot be scheduled. It would be of real value if these Powershell scripts could be scheduled.

New-CMDuplicateHardwareIdentifier
Set-CMDuplicateHardwareIdentifier
Remove-CMDuplicateHardwareIdentifier

Please create cmdlets to add/edit/remove duplicate hardware identifiers. We have a large organization and those pesky Lenovo Yoga's get a USB to Ethernet dongle with each one. We have over 500 dongles currently, and I don't see a way to automate importing those MAC addresses. Thanks!

add a powershell possibility to add repair command to a deploymenttype of an application

Phased Deployment Powershell Cmdlets

Allow the Invoke-CMScript to pass script parameters. This could be done with a ScriptParameter hashtable similar to how Invoke-CMReport functions.

It would be nice to be able to make folders and apply security to each folder for the new scripts feature.

Actually, it is possible to create a collection with a cmdlet. But we cannot create it in a specific location. We need moving it after creating the collection. Why not just add a parameter to the New-CMDeviceCollection cmdlet?

Currently the script seem to sort by 'Type' or 'Approval State' and I have to choose 'Name' every time I go in to scripts.

In release (1810) an option was added to the "User Experience" tab for APPX deployments.

With the available cmdlets you can automate your deployments, but there is no option to set this outside of the UI.

Please add a "Provision this application for all users on the device" parameter to the "Add-CMWindowsAppxDeploymentType" cmdlet.

When using the PoSh Cmdlet Start-CMApplicationDeployment with Parameter -UpdateSupersedence et to $true the DeadlineDateTime Parameter it ignored if the Application is deployed as Available - I actually states it in a Warning as well.
But with UpdateSupersedence set to true we need the Deadline Parameter again, to not enforce the updates immediately.

PowerShell PackageManagement is a unified interface to package management systems and aims to make Software Discovery, Installation and Inventory (SDII) work via a common set of cmdlets (and eventually a set of APIs). Regardless of the installation technology underneath, users can use these common cmdlets to install/uninstall packages, add/remove/query package repositories, and query a system for the software installed.

Providing a dashboard/portal with the ability to manage the NuGet repository underlying the packagemanagement solution would make SCCM more attractive over phasing it out to go towards Chocolatey Enterprise.

We need the ability to deploy application groups with PowerShell.

Similar to Set-CMApplicationDeployment - but for groups.

I'd like the ability to add a description for the Script I'm adding into "Run Scripts". Right now I try to make the names descriptive, but would like to go into further details about what parameters they can use, what's going to happen, etc.

Add a vendor parameter to Get-CMSoftwareUpdate

This will help identify updates from specific vendors that have been provided through Third-party Software Update Catalogues.

Provide ability to rename scripts. We'd like ability to differentiate between test and production scripts or rename if the functionality changes. Or, just have the ability to fix typos without recreating the script/approvals.

SCCM PowerShell scripts running in a corporate environment are hobbled due to the NT AUTHORITY\SYSTEM context. I have multiple cases where I could create an Application that just runs a PowerShell script but the script needs to run as a domain admin to do what it has to. The new Scripts feature also needs run-as functionality for fire & forget type tasks. Including a run-as facility in SCCM would significantly extend the product's flexibility.