Configuration Manager 2007 collections are organized in hierarchies. The organization of the hierarchy is maintained by instances of SMS_CollectToSubCollect. By default, the root collection is identified as COLLROOT and only collections that are descendants (related to COLLROOT through SMS_CollectToSubCollect instances) of the COLLROOT collection are visible in the Configuration Manager console. Although it is permissible not to include a collection in the hierarchy, you should — not including a collection can lead to confusion and should be avoided.
Creating a Subcollection
A collection can be a descendant of COLLROOT, another collection, or both. The term subcollection is simply used to define a parent-child relationship (the child collection) between collections. To create a subcollection, you create an instance of the SMS_CollectToSubCollect association class, in which a parent-child relationship is defined. You can also use the SMS_CollectToSubCollect_a class to define the parent-child relationship between collections. The only difference between the two is the data that they contain. SMS_CollectToSubCollect_a contains object paths, and SMS_CollectToSubCollect contains collection identifiers.
When you use SMS_CollectToSubCollect to define the parent-child relationship, the SMS Provider populates the SMS_CollectToSubCollect_a class with the correct object paths. Similarly, if you use SMS_CollectToSubCollect_a to define the relationship, the SMS Provider populates the SMS_CollectToSubCollect class with the correct resource identifiers.
For more information, see How to Create a Subcollection.
Moving a Collection
When you move a node in the collection hierarchy (SMS_CollectToSubCollect), the nodes below the given node move with it. For example, given the following hierarchy:
COLLROOT->B->C->E
COLLROOT->D
Moving the parent relationship of C, from B to D, results in the following hierarchy:
COLLROOT->B
COLLROOT->D->C->E
To move a child collection, create an instance of SMS_CollectToSubCollect with the new relationship and delete the old instance of SMS_CollectToSubCollect.
Deleting a Collection
When you delete a relationship in the collection hierarchy (SMS_CollectToSubCollect), the child and its descendants form a new relationship with the root collection. For example, given the following hierarchy:
COLLROOT->B->C->E
COLLROOT->D
If you delete the B->C relationship, the change results in the following hierarchy:
COLLROOT->B
COLLROOT->D
COLLROOT->C->E
You cannot delete a COLLROOT-child relationship unless the child collection exists in another relationship. Using the previous hierarchy as an example, you cannot delete COLLROOT->B, unless B exists in another relationship such as:
COLLROOT->B
COLLROOT->D
COLLROOT->C->E->B
There is a difference between deleting instances of SMS_Collection and instances of SMS_CollectToSubCollect. If you delete the B SMS_Collection instance in the first example, the C and E collections are orphaned (that is, all associated instances of B are deleted in SMS_CollectToSubCollect).
See Also
Send comments about this topic to Microsoft.