3. About Packages, Programs, Collections, Distribution Points, and Advertisements
Having
discussed software packaging in ConfigMgr, compared it with software
packaging outside ConfigMgr, and compared ConfigMgr software
distribution with GPO-based software distribution, it is now time to
begin delving into how ConfigMgr works. Let’s start with discussing
some of the key terms and how these capabilities interact with each
other. The next sections discuss packages, programs, collections,
distribution points, and advertisements.
Packages
A software package
consists of general information about the software to deploy, including
the name, version, manufacturer, language, and where source files for
the package are located (if that package has source files). Packages
are created either from a package definition file or manually. Software packages within ConfigMgr are not
actually a repackaging of the software packaged by a vendor. ConfigMgr
will have the same source files used to install the software, but uses
MSI files to auto-populate many of the questions required when creating
packages and programs within ConfigMgr. You can also create software
packages without using package definition files. ConfigMgr provides the
ability to deploy executables, batch files, VBScript, JavaScript, and
command files, among others. If you can execute it, you can design a
package to deploy it!
A package optionally
includes programs, which provide the specifics of how the software
runs. The package also contains information about who can access it
(security) and where it is distributed (distribution points).
ConfigMgr uses packages to distribute software, as well as to deploy changes to client configurations, such as Registry changes.
Programs
A package contains programs.
These are commands specifying what should occur on a client when the
package is received. A program can do just about anything—it can
install software, distribute data, run antivirus software, or update
the client configuration.
Each package
must contain at least one program if the package will perform any
action other than to provide a pointer to the source files. Most MSI
files provide six default programs when used for software distribution,
each allowing the package to run in different ways:
Per-system attended—
This installation causes a program to install, expects user
interaction, and is run once for the system on which it is targeted to
install.
Per-system unattended—
This installation causes a program to install that expects to run
without user interaction and is run once for the system on which it is
targeted to install.
Per-system uninstall—
This installation performs an uninstallation of the program, and is run
once for the system on which it is targeted to uninstall.
Per-user attended—
This installation causes a program to install and expects user
interaction, and is run once for the user for whom it is targeted to
install.
Per-user unattended—
This installation causes a program to install without user interaction,
and runs once for the user for whom it is targeted to install.
Per-user uninstall— This installation performs an uninstallation of the program, and is run once for the user for whom it is targeted to uninstall.
Each
program specifies the command-line used to run the program in the
method described. As an example, a per-system unattended installation
will include a switch to run the program without user intervention.
Collections
A collection
represents resources within ConfigMgr. A collection is a logical
grouping and can consist of computers, users, or security groups.
Collections provide a target for ConfigMgr functions such as software
distribution . Collections can be either static (defined to specific resources) or dynamic
(either built on a query you define or an existing query that comes
prebuilt with ConfigMgr). The next two sections discuss these
collection types.
Static Collections
You
define static collections by manually adding a resource to a
collection. An example of a static collection is a group of test
workstations used to test software package deployments. As an example,
the Test Workstations collection has TestWS1, TestWS2, and TestWS3
manually added to it. Static collections are useful when you need to
define a limited number of systems or users to a collection and the
membership in the collection does not change frequently. Membership is
fixed (static) without manual changes.
Dynamic Collections
You
define dynamic collections by using a query-based membership in the
collection. You can achieve the same result as with the Test
Workstations static collection (see the previous section) by defining a
rule to add any workstations to the collection using names starting
with TestWS. This assumes that only
test workstations are named with the test workstation naming convention
(such as TestWS4). The benefit to a dynamic collection is it does not
require manual changes to add resources to the collection. Let’s say
you define a Test Workstations dynamic collection that adds all
workstations starting with the name TestWS. If additional test
workstations are created later, those new workstations will
automatically become part of the Test Workstations collection.
Distribution Points
A distribution point
(DP) is a ConfigMgr server role where packages are stored for later
distribution, making it similar in nature to a file share containing
software used for installations. The location of distribution points
can be significant in terms of network impact.
As
an example, if you create a package to install Microsoft Office (which
is a very large software package), you would not want it to install the
software from a distribution point across a wide area network (WAN)
link, due to the effect on network traffic across that link. Generally,
you would prefer to use a local distribution point with access to the
software you want to install. To help with WAN link utilization,
ConfigMgr can use BITS to transfer large amounts of data across networks, including WAN links. However, it is best to provide a local distribution
point for any location where multiple clients will access software
packages. BITS is only available for communication between the
distribution point to the client. Branch distribution points only use
SMB; they do not use BITS to communicate to the client.
You
can arrange DPs in a manner to help simplify their management—an
example of this is gathering all distribution points in the United
States into a single group and those in Europe into another group. This
capability gives ConfigMgr administrators the ability to group
distribution points geographically or by department, or use any other
method that enables easily adding or removing packages from large
numbers of DPs in a timely manner.
You can configure distribution points to support various functions. One example is a protected distribution point,
which allows ConfigMgr administrators to restrict which clients can
connect to the DP from specified AD sites or subnets. Using protected
distribution points ensures clients do not access content on a
distribution point over a slow link.
Advertisements
An advertisement
ties these concepts together. An advertisement says to take a specific
program within a package and make it available to a collection
previously defined, and it specifies the distribution point(s) to use
when deploying the program. Advertisements are either voluntary (they
show as available for the user to install) or mandatory.
How These Combine
Consider
a package containing multiple programs. That package is sent to a
distribution point and advertised to a collection. Although this looks
like a relatively complex way to distribute software, it is also a very
powerful approach. Let’s break this down into a simple example of how
these concepts work together.
You need to distribute an application called MyApp to the HR department this week. Perform the following steps:
1. | Create
a package for the application and then create an unattended
installation and (optionally, but recommended) an uninstallation
program within the package.
|
2. | Define a collection of the workstations used by the HR department personnel.
The users of the HR application are all located in the corporate
office, which has a single distribution point used when distributing
software from Configuration Manager.
|
3. | Create an advertisement that ties this all together. Figure 1
displays the advertisement. The advertisement ties the package and the
program (MyApp unattended installation) to the collection (the HR
workstations) and the distribution point used for installing the
software (corporate distribution point).
|
Knowing how these concepts combine is critical for understanding how Configuration Manager deploys software.
