Both the iResultObject from Get-CMConfigurationItem and the SMS_ConfigurationItemLatest object returned from a WMI query have a null value as the objectpath property.

Current workaround is to make recursive queries on SMS_ObjectContainerNode to get the ObjectPath of these objects.

Could we please have a common alias for the file path parameters in the various import/export cmdlets?

For example, currently we have:
1. Export-CMBaseline uses -Path to set output path, and
2. Export-CMTaskSequence uses -ExportFilePath.

Then we have:
1. Import-CMBaseline using -FileName to determine location of exported files
2. Import-CMApplication using -FilePath,
3. Import-CMTasksequence using -Path.

A common alias like "Path" or "FilePath" for all these parameters will be very handy in reducing complexity of scripts calling your Cmdlets.

The New-CMSoftwareUpdateAutoDeploymentRuleDeployment command is missing the -RequirePostRebootFullScan option. This should be added similar to the New-CMSoftwareUpdateDeployment command.

The SCCM scripts feature is new and so far works very well, however there is no feedback on systems offline or failed. The lower pie graph shows the numbers offline/failed but you cannot view them. The results tab only shows return codes of systems that actually executed scripts.

The scripts feature provides a powerful feature to provide real time information on an enterprise, that hardware inventory may not provide. It would be very helpful if you could create a collection based on the results of Script, or add the machines to an existing collection natively through the CM Console.

I want to run a powershell script with the new Run Script, with the ability to see the collection id, collection variables, collection members that script is being ran against. The script runs on the local system as SYSTEM so it can't reach back to SCCM to obtain this information. I know you can add credentials to allow this, but a simple GET-CMRunScriptCollectionName or GET-CMRunScriptCollectionVariables would be nice.

There is currently no cmdlet to delete or disable a deployment of Client Settings. You can create a deployment by using the Start-CMClientSettingDeployment cmdlet but there is absolutely no way of stopping, deleting, or disabling the deployment. If you run a Get-CMDeployment against a collection, it only returns all deployments except a Client Setting.

After running a script on a collection or set of machines have the ability to automatically create a collection on machines that failed the script or machines that could not be connected to. So that after the machine is online the script can be run against it.

Explicitly being able to select the option of using PowerShell 6.x in scripts/compliance rules/task sequences would be a good future thinking feature to adopt as soon as possible.

Ideally a version option built in to SCCM like that for x32/64 OS, but for PS 5.1/6.x would make this interesting.

Add the ability to add and edit Install Behavior for Application Deployment types with PowerShell cmdlets

the New-CMConfigurationItem and Set-CMConfigurationItem should be able to set the supported platforms. today this is not possible to easily perform this task

add-CMCollectionToDashboard and Remove-CMCollectionFromDashboard would be great addition to the existing powershell so the UpdateVisibilityInEPDashBoard WMI method would not be required anymore

add option to manage express updates via Set-CMClientSettingSoftwareUpdate (Enable/Disable and Port used)

the Set-CMClientPushInstallation should have an option to set the Allow connection fallback to ntlm

add a new Set-CMClientSetting to customise software center. today the only way is to use the props SettingsXml for SMS_SCI_ClientComp (SoftwareCenter) WMI and create a xml to configure it.

Please enable the deadlinedatetime parameter in the CMDLet for available Packages, so that we can autoupdate available software again without needing the user to take Action.

Script status should provide details on who executed a particular script.

The "run script" feature is fantastic, but somewhat clunky when multiple lower level admins are adding scripts, as they can't be tested before approval.

It would be great if we could designate a "development" collection for running scripts that have not been approved yet.