Collections represent resources within
ConfigMgr; they consist of computers, users, or groups. You use
collections to target ConfigMgr functions such as defining maintenance
windows and performing software distributions, and you can define them
as static or dynamic. ConfigMgr includes a set of predefined
collections, providing a solid set of collections to use for targeting
and presenting good templates for developing additional custom
collections that you can build on. Figure 1 displays a set of predefined collections in ConfigMgr in the Configuration Manager console.
Tip: Identifying Predefined Collections
If
you are in the habit of using the same naming convention for your
collections as those supplied by Microsoft (such as All Windows 2003
Server Systems), it can become difficult to determine whether a
particular collection was predefined or custom built.
To identify predefined collections, look at the Collection ID field. ConfigMgr’s predefined collections start with SMS or SMSDM (for example, SMS Device Management). ConfigMgr creates custom collections using the site name, as you can see in Figure 1, where the collection ID for Static Collection Test starts with CEN (the three-letter code for the central site in the SCCMUnleashed environment).
1. Static Collections
Static
collections are the easiest type of collection to create, and they are
useful when you want to define a limited number of systems or users in
a collection when the collection membership does not change frequently.
Creating a Static Collection
To
understand how static collections work, you will create a static
collection for a single computer system, which is one of the most
common static collections. Perform the following steps:
1. | Collections
are defined in the ConfigMgr console. Navigate to Site Database ->
Computer Management -> Collections. Right-click and choose New
Collection to start the New Collection Wizard.
|
2. | On the General screen (shown in Figure 2),
define the name of the new collection and a description that is stored
in the Comment field. A good approach to naming the collection is to
use names similar to collections that already exist. For example, you
would name a new collection containing Windows 2008 servers “All
Windows 2008 Server Systems,” and a new collection with Windows servers
in the Dallas site might be “All Windows Server Systems in Dallas.”
This example creates a sample collection named Static Collection Test, used temporarily for this environment.
|
3. | There
are no members in the collection by default. To add a static member to
this collection, click the computer icon (circled in Figure 3) to open the Create Direct Membership Rule Wizard.
Alternatively, clicking the query icon (next to the computer icon)
opens the Query Rule Properties dialog box.
|
4. | After
the Welcome screen of the Create Direct Membership Rule Wizard, the
wizard proceeds to the Search for Resources step, asking you how to
find resources to add to the collection. The Search for Resources
screen in Figure 4 defines the following fields:
- Resource class—
Provides the list of available resource classes, including Unknown
Computer, User Group Resource, User Resource (default), System Resource,
and IP Network. This example will use System Resource to identify the
name of the computer that will be a member of the static collection.
- Attribute name— The attributes available vary depending on the resource class previously chosen. Figure 4 shows the Netbios Name selected, as a means to identify the name of the computer that will be a member of the collection.
- Value—
This field defines the potential values for this area. Wildcards are
available as needed; as an example, the use of % in this field will
identify all available NetBIOS names in the environment. The example
shown in Figure 5 specifies the Bluebonnet server.
|
5. | You
can limit collections to contain only members that exist in another
collection. As an example, if a collection is restricted to all Windows
2003 systems, any systems without Windows 2003 installed are not
included as a potential member in the collection. Because the potential
membership for this collection is already limited by using the value
Bluebonnet (previously defined on the Search for Resources screen in Figure 4), Figure 5
leaves the Search in this collection field blank. Limiting the
membership is also required when you are using the ConfigMgr console
and do not have full rights to ConfigMgr resource database; this lets
you limit your scope to the collection that your account has access to.
|
6. | The
previous pages in this wizard defined the potential membership for the
collection as a specific resource—Bluebonnet (shown in Figure 6).
If multiple resources match those restrictions already specified, they
would now appear on the Select Resources page to select the resource(s)
for the collection. As an example, if the collection was restricted to
all Windows 2003 systems matching the value of SRV%, the Select
Resources page would list all the Windows 2003 servers starting with a
name containing SRV (SRVAD01, SRVEXCH02, and so on).
|
7. | The
Membership Rules screen shows the resources in the new collection. This
example creates a new collection containing a single server named
Bluebonnet. After moving to the Finished page, the wizard returns to
the New Collection Wizard with a direct membership rule created for the
Bluebonnet server, displayed in Figure 7.
The
Membership Rules screen also provides the capability to schedule when
(or if) to update the collection. Notice the checked box for Update
this collection on a schedule, which is the default configuration. Also
notice that the collection is scheduled to update each day at the same
time it was created.
Collections will automatically update
their contents on a scheduled basis, keeping the contents of the
collection current with existing resources. You can also update a
collection at any time by right-clicking the collection and choosing
the option Update Collection Membership. (However, there is rarely a
requirement to update a static membership collection manually.)
|
8. | Next
is the Advertisements screen, which shows a list of advertisements
currently defined for this collection. Because you did not create any
advertisements for this collection, this screen is empty, as displayed
in Figure 8.
|
9. | The Security screen (shown in Figure 9)
provides a list of the class and instance security rights that exist
for this collection (who has access to do what to this collection). The
default rights provided with this wizard are specified in the Site
Database -> Security Rights section of the Configuration Manager
console. You can add, edit, or delete security rights using the buttons
to the right, above the listed permissions.
|
10. | The
remaining screens of the New Collection Wizard display the progress as
ConfigMgr creates the collection and a confirmation that the collection
has been created.
|
Static
collections have a place, particularly if you are creating test
environments where you want to limit the systems involved in the tests.
This differs from dynamic collections, which have the potential to add
more resources to the collection based on those resources matching the
criteria for the collection. For this example, a static collection
provides a simple way to provide a target to use for deploying software.
Using Static Collections with Dynamic Additions
Sometimes
static collections are not only static. You can interact with static
collections (and dynamic collections) to add and remove members even
outside of the ConfigMgr console. Consider the following example.
Let’s
say there is a dynamic collection used to test packaging; the
collection was created with a dynamic membership based on name (where
Name equals %lab%). There is a single system called lab01, which you
want to receive the test packages you are sending to the collection.
However, your organization adds a new set of computers, located in the
new laboratory conference room, that have names of laboratory01 through
laboratory05. Based on the definition of the dynamic collection, these
new systems would receive the test packages!
By
defining a static collection with the exact name of the system you want
the collection to contain, you limit the risk of deploying packages to
systems that you do not want to receive them.
|
During
the Systems Management Server (SMS) 2003 timeframe, a consulting
organization was using SMS 2003 with the Operating System Deployment
(OSD) feature pack to deploy operating systems. This organization also
packaged a significant number of applications to deploy during the OSD
process. Although most of these functioned as expected, a small subset
of the software packages would freeze during the installation process,
which caused the operating system deployment to freeze as well.
To
address this situation, they created a collection (PostOSDInstall) that
had a list of all the workstations deployed with OSD. As OSD completed
the installation of each workstation, they added a task to run a script
that added the workstation name to the PostOSDInstall collection. The
collection was configured to update membership very frequently; once
the workstation was added to the PostOSDInstall collection, the
software packages advertised to the collection would begin to deploy
shortly after the OSD process completed. Using this technique provided
a way to deploy software that was failing within the OSD process
through ConfigMgr—by approaching it from a different perspective.
Although
this is a relatively in-depth example, it is included to show the type
of functionality available through static collections that are added to
dynamically.