Managing a Collection Hierarchy

  • Article

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 SMS Administrator Console. Although it is permissable not to include a collection in the hierarchy, it is not advised — this 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, where 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 an example, see Creating a Collection.

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.
  • 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

Note that 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 (all associated instances of B are deleted in SMS_CollectToSubCollect).