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