Improve addMembershipRules implementation for large direct membership collection or provide Stored Procedure to do the same
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.
Performance for editing direct mem collections is greatly improved now.
Im still searching and working on a solution for it. We are attempting to add multiple Query rules to the query rule array to add 5000 machines for example. Because trying to add 5000 machine in a direct membership rule 1 by 1 in code is performance intensive as this person points out. If their is a solution, it should be added as example code in the addMembershipRules method documentation and other places where it is referenced -- https://docs.microsoft.com/en-us/mem/configmgr/develop/reference/core/clients/collections/addmembershiprules-method-in-class-sms_collection
Hi djam, which version is greatly improved? Does this apply for the next CB?
We have 1806 and have been using 'active directory system group discovery' as a cumbersome workaround for many years. I would like to test if the performance of the 'direct member' approach is now worth a try.
We have migrated the collection memberships from our legacy client managements system using automated tasks and thus didn't feel the pain to do this in add computers to collections in the SCCM console (which also likely would not have worked due to what i wrote above)
Since we have one collection for each of our 1500 applications the times added up. To reach a deterministic time span until a computer is finally added to a collection we switched to query based collections now. This works pretty well so far and this is also what i recommend. I wish we had read this somewhere before in an official documentation ...