We need a quick way to quickly populate or empty collections. Targets should be imported as rules without triggering other processes in the background (eval/re-built). The same also applies to removal rules.

Please implement something like an cmdlet “Add-CollectionMemberRules” / “Remove-CollectionMemberRules” with fast adding rules method, without delays, without rebuilding the complete collection sets in the background. The cmdlet should support especially adding rules like "DirectMembers".

Note:
This will help to control and steer application (ramp-up / ramp-down) rollouts, depending on device target lists, created by internal IT or delivered by business partner. The lists could based on different information like department code/name, cost center, contacts etc. Based on such a target lists, the deployment phases are planned and controlled.

We are using PowerShell as a frontend for creating applications. As default we create multiple deployment type, each of them intented to run in certain environemts. These environemts are defined in some custom global conditions.

When creating the deployment type we can very easily identify which global contitions shold be set as requirement. But we miss a Powershell cmdlet to automize this task. Instead we rely on the application creator to remember to add these conditions.

So far I have found a PS-script that can add one of the build-in conditions, but it fails when trying to add a custom made condition.

My idea is to have the scenario described below supported.

When running Save-CMSoftwareUpdate command on a CMSite-PSDrive that connects to a ConfigMgr site in a different domain (used Get-Credential to pass credentials in New-PSDrive call) than the user account the PowerShell window is running as, I get error 'The RPC server is unavailable'.

I can successfully change location to the PS drive, and run other ConfigMgr PS cmdlets.

Commands:
New-PSDrive -Name <sitecode> -PSProvider 'CMSite' -Root <siteserverFQDN> -Credential (Get-Credential)
Set-Location <sitecode>:
Save-CMSoftwareUpdate -SoftwareUpdateName <name> -DeploymentPackageName <name> -Verbose

Verbose output from Save-CMSoftwareUpdate call:

VERBOSE: Start: Execution of WQL query: Select * from SMS_SoftwareUpdatesPackage where Name='Office 2016'
VERBOSE: Finish: Execution of WQL query: Select * from SMS_SoftwareUpdatesPackage where Name='Office 2016'. Processed 1 results in 00:00:00.0533413.
VERBOSE: Performing the operation "Save" on target "SoftwareUpdate: Name="Office 2016"".
VERBOSE: Start: Execution of WQL query: SELECT * FROM SMS_SoftwareUpdate WHERE LocalizedDisplayName IN ( 'Update for Microsoft Office 2016 (KB4018322) 64-Bit Edition' )
VERBOSE: Finish: Execution of WQL query: SELECT * FROM SMS_SoftwareUpdate WHERE LocalizedDisplayName IN ( 'Update for Microsoft Office 2016 (KB4018322) 64-Bit Edition' ). Processed 1 results in 00:00:00.0858704.
VERBOSE: Start: Execution of WQL query: select distinct cic.ContentID from SMS_CIToContent cic where cic.CI_ID=16796196 and cic.ContentID not in (select pc.ContentID from SMS_PackageToContent pc where pc.PackageID='ECN0006C') and (cic.ContentLocales='Locale:0' or cic.ContentLocales = 'Locale:9')
VERBOSE: Finish: Execution of WQL query: select distinct cic.ContentID from SMS_CIToContent cic where cic.CI_ID=16796196 and cic.ContentID not in (select pc.ContentID from SMS_PackageToContent pc where pc.PackageID='ECN0006C') and (cic.ContentLocales='Locale:0' or cic.ContentLocales = 'Locale:9'). Processed 1 results in 00:00:00.0000256.
VERBOSE: Start: Execution of WQL query: select * from SMS_PackageToContent where ContentID=16790019 and PackageID='ECN0006C'
VERBOSE: Finish: Execution of WQL query: select * from SMS_PackageToContent where ContentID=16790019 and PackageID='ECN0006C'. Processed 0 results in 00:00:00.
VERBOSE: (SMS_PackageToContent.ContentID=16790019,PackageID='ECN0006C') does not exist or its IsContentValid returns false. We will (re)download this content.
VERBOSE: Using 64-bit content downloader
VERBOSE: Downloading update content CI_ID='16790019' Content Source Path='\\ecn-badcm\updatePackages\Office 2016' Download Location='' Provider='ecn-badcm.BoilerAD.Purdue.edu' Second Chance='False'
VERBOSE: Result: 1722 (0x000006ba)
Save-CMSoftwareUpdate : The RPC server is unavailable
At line:1 char:1
+ Save-CMSoftwareUpdate -SoftwareUpdateName "Update for Microsoft Offic ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidResult: (Microsoft.Confi...reUpdateCommand:SaveSoftwareUpdateCommand) [Save-CMSoftwareUpdate], Win32Exception
+ FullyQualifiedErrorId : DownloadContentError,Microsoft.ConfigurationManagement.Cmdlets.Sum.Commands.SaveSoftwareUpdateCommand

Save-CMSoftwareUpdate : The following updates failed to successfully download: Update for Microsoft Office 2016 (KB4018322) 64-Bit Edition
At line:1 char:1
+ Save-CMSoftwareUpdate -SoftwareUpdateName "Update for Microsoft Offic ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidOperation: (Microsoft.Confi...reUpdateCommand:SaveSoftwareUpdateCommand) [Save-CMSoftwareUpdate], InvalidOperationException
+ FullyQualifiedErrorId : DownloadUpdateFailed,Microsoft.ConfigurationManagement.Cmdlets.Sum.Commands.SaveSoftwareUpdateCommand

today when using powershell cmdlet the action is performed direct against the server, as example, if you want to create an application, add couple of deployment types and perform other small changes, you end up with lots of revisions (easily, 10). when you have lots of revisions, this start to impact the performance.

it would be nice if we can have the cmdlets transactional, in this case, you create the object and the changes does not apply to the database, you need to "save" the change.

on the application example, you could create the application, create the dt's, changes, etc. and at the end, user a "save" cmdlet and the data is written to the database, ending up with only 1 revision.