Configuration Manager Collection Hierarchy

Applies To: System Center Configuration Manager 2007, System Center Configuration Manager 2007 R2, System Center Configuration Manager 2007 R3, System Center Configuration Manager 2007 SP1, System Center Configuration Manager 2007 SP2

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

Concepts

About Configuration Manager Collections
Configuration Manager Collection Classes
How to Create a Subcollection
How to Create a Static Collection
How to Create a Dynamic Collection