|
|
< Day Day Up > |
|
Somehow, SMS administrators and users often misunderstand or mislabel the package distribution process. It’s important to remember that SMS 2003 is fundamentally a package delivery tool. Basically, SMS is designed to make a package that you create available to a specified target or targets. The key here is that you are responsible for creating the package. You’re also responsible for ensuring that the package will execute as intended when it reaches its target. SMS will get it there for you, but SMS won’t “error-correct” it for you—nor should you expect it to.
Look at it this way. Suppose you’re sending a bicycle to your nephew. You box up the parts carefully, including instructions on how to assemble it, go to your nearest package delivery service office, fill out the appropriate forms, pay the appropriate fees, and hand over the box. The responsibility of the package delivery service now is to get the box containing the bicycle to your nephew’s house within the time frame you specified and paid for. When the package arrives at your nephew’s house, he opens the package, reads the instructions, and assembles the bicycle. The extent to which your nephew is successful depends on how accurate and easy to understand the instructions were.
SMS works in much the same way. You, the SMS administrator, are responsible for creating the package and ensuring that all the appropriate pieces are assembled: source files, scripts, executables, command switches, and so on. You identify where the package must go and who should receive it. SMS carries out your instructions and even “opens” the package when it arrives at the target. However, the package’s ability to execute—or the user’s ability to use the application, for that matter—isn’t SMS’s responsibility.
This description of the basic package distribution process uses some terms that you’re probably familiar with. Let’s take a moment here to review these terms in more detail.
An SMS package generally represents a software application that needs to be installed on an SMS client computer. However, a package might also contain update programs or software patches, single files such as a virus update file, or no files at all—just a command to execute a program already resident on the client. You need to identify to SMS exactly what the package consists of.
Every package must contain at least one program. An SMS program identifies what should occur on the client when the package is received. Perhaps a setup routine is executed, or a virus scan is performed, or a file is copied to a particular directory. Perhaps the user needs to supply information such as the program directory, or perhaps no user intervention is required at all. A package may have several programs associated with it, allowing the application to be run in a variety of ways on different clients. Consider a Microsoft Office XP installation. You can choose to perform one of several types of software installation, including Typical, Custom, or Laptop installation. If this software were an SMS package—and it could be—you would have to include a program for each of these installation methods if you intended to use them. Once again, you must define the program to SMS and include any and all appropriate references to script files or command switches. The program also defines the platform and environment within which the package can run. For instance, can the package run on any platform or only on Microsoft Windows XP computers with Service Pack 1 installed? Can the program be executed by any user or can it run only in an administrator context?
Some applications include predefined scripts called package definition files that can be used with SMS. Package definition files contain all the package and program information required for SMS to successfully distribute the package and, usually, to deploy it. Package definition files often come with the application’s source file, or they can be obtained from the developer. You can also create package definition files using various tools and utilities from Microsoft. We’ll return to package definition files later in this chapter in the section “Creating a Package from a Definition File.”
An advertisement makes the program and package available to a specified collection. Recall from Chapter 11, “Collections,” that collections can contain not only SMS client computers but also Windows users and groups. This means that a program can be advertised to clients as well as to users and groups. So before you create the advertisement, you’ll need to have created the appropriate collections.
Advertisements are often used to schedule when a program runs and to specify whether the user can reschedule the program. Advertisements can also be configured to recur—that is, to make a program available on a recurring basis. For example, if you distribute virus update files on a monthly basis, you might create a virus update package and program and then an advertisement that makes the virus update file available on a monthly basis.
The Advertised Programs Client Agent (also sometimes referred to as the Advertised Programs Agent) is installed and started on the SMS client. As with other client agents, this agent is optional and the SMS administrator must configure and enable it. The Advertised Programs Client Agent’s job is to monitor the client access point (CAP) for available advertised programs that target the client or the user at the client. When an advertisement is found and the program is ready to be run, the agent connects to an available distribution point—as defined in the package details—to execute the program. If the program runs an existing file on the client, the agent executes the program appropriately.
Three SMS site systems, in addition to the site server, are involved in the package distribution process: CAPs, management points, and distribution points. The CAP is always the point of interchange between the site server and the SMS Legacy Clients, and the management point performs the same function for the SMS Advanced Clients. In this exchange, package detail information and advertisements are copied to the CAP for access by the Advertised Programs Client Agent on the Legacy Client and to the management point for access by the Software Distribution Client Agent on the Advanced Client. To simplify this discussion, I’ll refer to both agents as the client agent and make any distinctions in functionality as they’re necessary. The actual source files that constitute the package are copied to distribution points. Before you can distribute any packages, you need to have assigned CAPs, management points, and distribution points. Remember that the site server becomes a CAP and a distribution point by default when you install SMS 2003. Remember, too, that you can have only one management point defined per site. (The role of site systems and how they’re assigned is discussed in Chapter 3, “Configuring Site Server Properties and Site Systems.”)
As you can see from the previous section, many components are involved in package distribution. Before we continue our discussion of package distribution, let’s outline the actions required for the distribution process:
Define your CAPs, management points, and distribution points for the package
Create appropriate collections
Gather all source files, setup routines, scripts, and so on needed for the package
Create the SMS package
Define at least one program for the package
Distribute the package to the distribution points
Execute the advertised program on the client
After reviewing these elements of the distribution process, you’ll have a solid foundation to build on. The following sections of this chapter will cover how to configure various components for package distribution.
|
|
< Day Day Up > |
|