At the moment when cmtrace is opened, it extracts the appropriate architecture version to AppData\Local\Temp<temporary file name>.tmp and executes it. Customers often put cmtrace in the system32 directory of computers to aid with troubleshooting.

With recent randsomware attacks, companies are starting to look at blocking programs from executing from AppData with AppLocker and Device Guard.

A workaround so far has been to copy the tmp file and rename it to cmtrace.exe and placing it in approved directory for executing applications, but this sort of extra effort could easily be solved by providing an update to the tool that simply includes the x86 and x64 versions of the application natively.

This goes for all new Add/Set-CM*DeploymentType but for my example, I'll refer to Add-CMScriptDeployment.

An example below is my generic Script Deployment Type.

Add-CMScriptDeploymentType `

    -ApplicationName "$PublicName" `

    -DeploymentTypeName "$AppName Client" `

    -ContentLocation "$AppLocation" `

    -InstallCommand "$InstallStr" `

    -UninstallCommand "msiexec /x $MSICode /qn" `

    -MaximumRuntimeMins 720 `

    -LogonRequirementType WhereOrNotUserLoggedOn `

    -UserInteractionMode Hidden `

    -ProductCode

    -ScriptLanguage PowerShell `

    -ScriptText $scriptDetect

When this is run, the DT is created with the Installation Behaviour set to the default value of "Install for system if resource is device; otherwise install for user"

The previous version of this cmdlet - Add-CMDeploymentType had the parameter available to configure this option, but it seems to have been removed from the parameters available in the new cmdlet.

My Current workaround is to call the now deprecated "Set-CMDeploymentType" like the below command shows.

Set-CMDeploymentType -DeploymentTypeName "$AppName Client" -ApplicationName "$PublicName" -MsiOrScriptInstaller -InstallationBehaviorType InstallForSystem

Can we please get the "InstallationBehaviourType" parameter added back to the new Add-DeploymentType cmdlets.

I use a LOT of PowerShell ... and the PowerShell modules in SCCM are ... well... bad.

Issue 1: I should not have to set my running location to a site to run a cmdlet. No one uses a set-location to make sure they are in the AD domain root before running a get-ADUser (unless they have a multi-domain environment and need to call something specifically), yet SCCM requires this to be true. It makes scripting needlessly complex.

Issue 2: there are a pointlessly large number of cmdlets. Do I really need a Get-CMDeviceCollection and a separate Get-CMUserCollection? Why can't I simply use "Get-CMCollection" with a -type switch that defaults to device? Once again: needless complexity when it comes to scripting because of this.

Issue 3: we need more cmdlets in general. There are good number cmdlets that have a "Get" without a corresponding "Set". That should just be a big NO NO, and I should reasonably expect to be able to set anything I get.

Configuration Manager Current Branch (1602) Supports SQL Always On Availability Groups, however it only in a Synchronous-commit replicas.

From TechNet:
Asynchronous-commit mode. This availability mode is a disaster-recovery solution that works well when the availability replicas are distributed over considerable distances.

Synchronous-commit mode. This availability mode emphasizes high availability and data protection over performance, at the cost of increased transaction latency. A given availability group can support up to three synchronous-commit availability replicas, including the current primary replica.

This means that Configuration Manager can only support 3 secondary replicas in a SQL AO AG and they need to be in the same datacenter. Without the ability to support Asynchronous-commit replicas we cannot have replica groups that are Geo redundant and offer a more complete disaster-recovery solution. For many customers who use a different datacenter for the disaster recovery model the Synchronous-commit does not offer any improvement in recovery as a database would still need to be restored and a ConfigMgr Site Recovery still done. Having the option for an Asynchronous-commit can help to reduce the recovery time of Configuration Manager in the event of a disaster.

Another option would be to support Distributed Availability Groups for SQL 2016.

Today we use an automated process to populate our device collections with machines from a fore-front configuration system.

After we had exceeded 250000 machines in some collections adding new machines to these large collections has become a real pain. Meanwhile it takes from 40s to 7 minutes to a add a single machine. The SCCM console cannot be used anymore for large collections. It crashes with OOM when the collection is opened or a new computer is added using right click.

Interestingly execution times don't really differ in terms of the number of machines added in one call of the respective API.
Since a machine is usually member in about 60 collections it can take up to 7 x 60 = 4 hours to add a new computer to all the necessary collections!

For this we already have taken optimzations to do some things in parallel already but this should make it clear:

A single new machine may stresses our SCCM for hours.

To add a machine to a collection we use the API as described in http://www.moyerteam.com/2013/12/adding-user-accounts-collection-addmembershiprules-method/ to add devices to collections.

We have already done several optimizations suggested by product support as allocating more memory to the WMI provider and running it in a dedicated process and even on a dedicated server. Nothing helps unfortunately.

There seem to exist architectural limitations imposed by WMI itself or the implementation of the method addMembershipRules preventing a speed up but i am not technical enough to prove that.

Wouldn't there be another way to speed this up? When we trace the activities in SQL server we see that adding a machine to a device collections just adds a row in table CollectionMembers.
I understand that SCCM does some more checks but should these really take 40s?

If the performance of AddMembershipRules really can't be improved we would like to have an interface to SCCM bypassing WMI, e.g. based on Stored Procedures or a REST API.