System Center Configuration Manager 2007 : Distributing Packages - Creating Collections (part 4) - Dependent Subcollections

12/28/2013 2:52:19 AM

3. Subcollections

In Configuration Manager, you can use subcollections to associate one collection with another collection. There are two different types of subcollections:

Linked subcollections
Dependent subcollections

The next two sections discuss these types.

3.1 Linked Subcollections

Use a linked collection to tie a collection to an existing ConfigMgr collection. To create a linked subcollection, highlight the collection you want to link and then choose the New -> Link to collection option. Note that linked subcollections can exist in multiple locations in the collection structure. As an example, you could link the All Windows XP and Vista systems collection .

Linked collections do not draw their membership from the collection they are linked under. This means you could create a collection called My Static Collection (with two hard-coded systems defined as members) and then link the All Desktops and Servers collection to it. The membership of the All Desktops and Servers collection is not limited to the two members of the top-level collection My Static Collection, but rather shows the full list of members that exist in the All Desktops and Servers collection.

3.2 Dependent Subcollections

You create a dependent subcollection when you highlight an existing collection and define a new collection under the original collection.

Why would you want to use dependent subcollections? A common usage is for software distribution targeting. Create a top-level collection for all systems that need the software package deployed, with subcollections for the different types of programs that will run on the systems. As an example, create the collections used to deploy the Operations Manager (OpsMgr) client, which will vary depending on whether the system is amd64, i386, or ia64. Perform the following steps:

1.	Begin by creating a top-level collection called All Client Systems, based on the existing All Client Systems query. The next collection you define (step 2) will use this collection and limit the members to those systems that are ConfigMgr clients.
2.	Create another top-level collection, named OpsMgr Client Deployment. Define this collection to contain all Windows Server operating systems that have ConfigMgr agents deployed to them.
3.	To define a different time to update this collection, select the Schedule button in Figure 18 to open the Custom Schedule dialog box displayed in Figure 19. Figure 18. Setting the schedule for updates to the OpsMgr Client Deployment collection Figure 19. Defining a custom schedule for the collection This dialog box is used with dynamic collections only; static collections do not have scheduled update times, because they will not change unless the membership is changed manually. The Custom Schedule dialog box contains several fields: Time Start— This is a two-part field specifying the date and time the collection updates, which defaults to the date and time you created the collection. Recurrence pattern— Options include None, Weekly, Monthly, and Custom Interval. Recur every— The value for this field varies depending on the recurrence pattern chosen: If you choose None, there are no options for this field. If you choose Weekly, the number of weeks can be defined (defaults to 1) and you can specify the day of the week to update the collection. If you choose Monthly, the number of months can be defined (defaults to 1) and you can specify the day of the month as a number (default of 1) or the last day of the month. You can also specify a fixed day (such as the first Tuesday of the month). In this case, the recurrence pattern is set to update daily. Click OK to return to the Membership Rules screen and then clear the option Update this collection on a schedule.
4.	Now that you have a top-level collection for the OpsMgr software deployment, the next step is to create the dependent subcollections. Highlight the OpsMgr Client Deployment collection, right-click, and choose New -> Collection. Name the first subcollection OpsMgr AMD64. Create it as a dynamic collection and specify the membership such that the criterion matches a simple value for Computer System – System Type, where it is equal to x64-based PC, as shown in Figure 20. As a reference, the OpsMgr agent has three folders for the different hardware types: AMD64— Equals “x64-based PC” for the collection membership I386— Equals “x86-based PC” for the collection membership IA64— Equals “IA64-based PC” for the collection membership Figure 20. Limiting a collection based on the computer system type

Tip: Identifying Criteria for Collections

With all the information ConfigMgr gathers from hardware and software inventory, it can be difficult to identify which criteria to use to restrict collection membership. Although the Criterion Properties dialog box provides a list of values available for the various categories, it is often helpful to see the fields and values in a different format to find what you are looking for.

Using the Resource Explorer provides hardware and software inventory information in a format that is easy to browse. Highlight a system you know will have the value, right-click, and choose Start -> Resource Explorer.

Although this approach does not provide all available information that may be used in a collection, it does present a large quantity of information you can utilize for collection criteria.

Note: How Subcollections Become Linked Collections

The page at http://technet.microsoft.com/en-us/library/bb680976.aspx provides the following information regarding dependent subcollections:

“Dependent subcollections are created as a new collection under an existing collection. When you create a subcollection, it is dependent on the collection under which it was created, as long as you do not link other collections to it. If the subcollection is linked to other collections, the subcollection becomes a linked collection while attached to more than one collection. When you delete a collection, any dependent subcollections of that collection are also deleted. Any advertisements, queries, or collection membership rules that are dependent on the subcollection are affected by its deletion. Because of this, it is strongly recommended that you use the Delete Collection Wizard to delete any collections that may contain dependent subcollections.”

Subcollections are very useful for logically gathering groups of collections, and can be nested multiple levels deep (as an example, collection1 can have subcollection1, which contains subcollection2, which contains subcollection3, and so on). Although subcollections can be to almost any depth, you should use fewer than 10 levels to minimize the complexity.