It would be nice to have the option to add some query based parameters for script (WQL or SQL). So values for parameters could be dynamic based on a query and scope of the user who trigger the script.

i.e. We could have hiding deployments (without any notifications to the end users), then the admin user could select application or updates from the list to enforce deployment.

Adding the ability to run powershell scripts on a SCCM site server when called from a Task Sequence or Compliance item.

Some scripts need special rights or modules that are not available to Users or client devices. (ActiveDirectory, ConfigManager actions)

Being able to add these scripts in the SCCM console and have them ran from a call back from the client or Task Sequence would save running multiple Web Services on the server.

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

Could we have a get-cmdetectionclause command? I'd like to be able to get an existing detection clause for a deployment which would be useful for not only managing existing detection clauses but being able to explore and re-using them for other applications.

As it is right now I use get-cmapplication | get-cmdeploymenttype | select SDMPackageXML in order to view the detection method as XML.

Additional context can be found:
https://www.reddit.com/r/SCCM/comments/a0lgdt/powershell_system_discovery_container_account/

The current 1806 implementation of CMPivot is using the cmdlet GEt-Eventlog read event log entries. The PowerShell command is:
$events = get-eventlog -LogName $logName -Newest 50 -ErrorAction Stop

This limits the logs to be read from to logs like Application, Security, System and only some others. On my client (Get-EventLog -List).Count has only 12 logs.

The better command would be Get-WinEvent. Where I can access all logs. The command (Get-WinEvent -ListLog *).Count returns 463 logs.

If we could get this functionality it would go a long way in automating collection management.

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