Now we can delve into the package distribution process in more detail, beginning with package creation itself. In this section, we will explore the package creation process, including identifying distribution points and creating programs.
If your package involves the accessing of source files, such as performing a software installation, you must define a location for the source files. The location can be a shared folder on the site server or on a remote server, including a CD-ROM drive. The most important characteristic of the source file location is that it must be accessible to the SMS Service account. If your program involves using a script file or files, be sure to include them as part of your source files as well or the program will fail.
As in all things SMS, you will begin in the SMS Administrator Console. A package can be created either from scratch—one for which you provide all the configuration details—or from a package definition file that already contains all the package details. In this section, we'll look at the former technique.
To create a package from the ground up, follow these steps:
Figure 12-1. The Package Properties window.
Figure 12-2. The Data Source tab.
Figure 12-3. The Set Source Directory dialog box.
Figure 12-4. The Data Access tab.
Figure 12-5. The Distribution Settings tab.
Figure 12-6. The Reporting tab.
We haven't quite finished creating this package. If you expand the new package entry you just created in the SMS Administrator Console, as in the example shown in Figure 12-7, you'll see that three areas of configuration remain. The first area, defining access accounts, allows you to further secure who has access to the distribution source files. The other two areas are absolutely essential to the successful distribution of the package: defining distribution points, without which the client has no access to the source files, and defining programs, which specifies how to install or run the source files. Let's configure the access account first.
Figure 12-7. A sample expanded package entry.
By default, when SMS creates the SMSPKGx$ share, it grants Read access to the local Users and Guests groups, and Full Control to the Administrators group. The default Users, Guests, and Administrators entries map to the local Users, Guests, and Administrators groups for Windows NT distribution points. On NetWare distribution points, Users and Guests map to the Everyone group, and Administrators maps to the Supervisor account. The Administrators, Users, and Guests accounts are known as generic accounts.
Since the default share is a hidden share, the only way a client should know that a package is available to it is through the package distribution process. In other words, the client agent will see an advertisement for that package that targets a collection the client is a member of. Bear in mind that users will be users, and it is possible that they will find the hidden share, navigate to a package folder, and execute any programs they find there. This could also happen if you create your own shares.
There are a couple of ways to deal with this little breach of security. One would be for you to evaluate the share (or NTFS) security for the SMS shares or for the package folders within the share. This is a time-consuming and potentially destructive process if you happen to lock out SMS from accessing the share. The other solution is to define access accounts for the package through the SMS Administrator Console. When you define an access account, you also define the level of access or permission for the specified user or group. This is very much like creating access control lists (ACLs) in Windows NT.
To define an access account, follow these steps:
Select the appropriate option to display the Access Account Properties window, shown in Figure 12-8.
Figure 12-8. The Access Account Properties window.
Figure 12-9. The Windows NT Account dialog box.
Figure 12-10. The NetWare NDS Account dialog box.
Figure 12-11. The NetWare Bindery Account dialog box.
Figure 12-12. The Generic Account dialog box.
Figure 12-13. The Permissions list on the General tab of the Access Account Properties window.
An essential configuration detail for any package is identifying the distribution points on which the package can be found. You should have already assigned the distribution point role to one or more site systems in your SMS site, as well as at any child sites. You now need to tell SMS which of those distribution points will host the package.
NOTE
If you are distributing the package to a child site, even if the SMS administrator for that site will ultimately distribute the package to its clients, you still must identify at least one distribution point at that child site when you create the package.
To define distribution points, follow these steps:
Figure 12-14. The New Distribution Points Wizard welcome screen.
Figure 12-15. The Copy Package screen.
Figure 12-16. The Browse Distribution Point Group dialog box.
Once you have added a distribution point to the package, that distribution point will no longer appear in the list of available distribution points if you run the New Distribution Points Wizard again—the wizard displays only distribution points that are available. If you need to remove a distribution point from the package, select it, right-click on it, and choose Delete from the context menu. When you delete a distribution point, you will also delete the package source directory on that distribution point.
It is often desirable to group distribution points so that packages can be distributed to them as a block rather than having to name the distribution points individually. Distribution point groups are defined through the site settings of your site—in the same place that you assign the distribution point role.
To define a distribution point group, follow these steps:
Figure 12-17. The Distribution Point tab of the Site System Properties window.
Figure 12-18. The Distribution Point Group Properties window.
Figure 12-19. The updated Group Membership list on the Distribution Point tab.
Figure 12-20. The updated Distribution Point Group Properties window.
If you need to remove a site system from a distribution point group, simply repeat step 5 of this procedure, but clear the Include This Site System In This Distribution Point Group check box. If you need to remove a distribution point group altogether, select any site system, open its Site Systems Properties window, and click on the Distribution Point tab. Select the distribution point group in the Group Membership list and click the Delete button (the black "X").
Finally, it is necessary to create at least one program for each package. This program specifies how the package is to be executed at the client. Many packages can have more than one program associated with them. For example, a package might have different installation methods such as Custom, Typical, and Compact. This is where you really have to know your package. The command-line information you provide here will either make or break the package when it is run on the client.
To create a program, follow these steps:
Figure 12-21. The Program Properties window.
Figure 12-22. The Requirements tab.
Figure 12-23. The Environment tab.
Figure 12-24. The Advanced tab.
If you later decide to delete a program, you would do so by right-clicking on the program in the SMS Administrator Console and choosing Delete from the context menu to activate the Delete Program Wizard. This wizard walks you through the process and helps you decide whether to delete the program. Deleting a program does produce a ripple effect for other SMS components. Any advertisements of the program will also be deleted and will no longer be made available to the client. If you selected the Remove Software When It Is No Longer Advertised option on the Advanced tab, you could end up removing the application from the client computers. The wizard displays all the affected advertisements and prompts you once more to confirm the deletion.
In Chapter 11, we examined the advantages of using collections whose membership rules are query-based when advertising programs. When a new member joins the collection, it automatically receives any advertisements made to that collection. In general, you should leave programs advertised until they are no longer needed or until they should be retired.
We've seen what's involved in creating a package from the ground up. Now let's see how much simpler the process becomes when you're creating a package from a package definition file.
To create a package from a predefined definition file, follow these steps:
Figure 12-25. The Create Package From Definition Wizard welcome screen.
Figure 12-26. The Package Definition screen.
Figure 12-27. The Source Files screen.
Figure 12-28. The Source Directory screen.
Figure 12-29. The Completing The Create Package From Definition Wizard screen.
Right-clicking on the package you just created in the SMS Administrator Console will display the Package Properties window. The end result will be the creation of a package with the essential package details filled in and the appropriate programs created with their essential details filled in on the General, Data Source, and Reporting tabs of the Package Properties window. The Data Access and Distribution Settings tabs are left with the default values. Figures 12-30 through 12-37 will give you an idea of the type of information generated by the package definition file provided with SMS 2.0 for distributing Microsoft Windows 2000 Professional. Of course, while SMS 2.0 or any other application developer provides the package definition file itself, you will still need to obtain a copy of the source files for the application.
The General tab of the Package Properties window, shown in Figure 12-30, contains the package detail information.
The settings on the Data Source tab, shown in Figure 12-31, are based on the parameters you defined using the Create Package From Definition Wizard.
Figure 12-30. The General tab of the Package Properties window.
Figure 12-31. The Data Source tab of the Package Properties window.
Package definition files do not always provide status MIF information for the Reporting tab. However, the package definition file for Windows 2000 Professional provided with SMS 2.0 does fill in some information, as shown in Figure 12-32. You need to enter the MIF filename that should be used.
Figure 12-32. The Reporting tab of the Package Properties window.
The package definition file is designed to generate all appropriate programs for the application package. The package definition file for Windows 2000 Professional creates four programs, as shown in Figure 12-33.
Figure 12-33. The SMS Administrator Console showing programs generated for Windows 2000 Professional.
Right-clicking on the automated upgrade for the x86 platforms entry will display the General tab of the Automated Upgrade Program Properties window, shown in Figure 12-34, which provides the appropriate command-line executable and switches.
Figure 12-34. The General tab of the Automated Upgrade Program Properties window.
The Requirements tab, shown in Figure 12-35, displays the estimated disk space and estimated run-time settings—all provided by the package definition file.
Figure 12-35. The Requirements tab of the Automated Upgrade Program Properties window.
Because the upgrade to Windows 2000 Professional requires administrative level access at the client, the program definition file specifies that option on the Environment tab, as shown in Figure 12-36.
Figure 12-36. The Environment tab of the Automated Upgrade Program Properties window.
As for the Advanced tab, shown in Figure 12-37, the package definition file doesn't provide any property settings for you. Again, it's up to you to decide whether to run another program first, remove the program when it is no longer available, or temporarily disable the advertisement.
In general, the package definition file will provide package details for the General and Data Source tabs of the Package Properties window, which should make sense. Distribution settings, for example, define how a package is sent from one site to another, and only the SMS administrator for each site can modify those settings. On the other hand, most of the property settings in the Automated Upgrade Program Properties window usually will be provided by the package definition file. The exceptions are the options on the Advanced tab, where you'll need to set the options that apply to your package on your own.
Figure 12-37. The Advanced tab of the Automated Upgrade Program Properties window.
The process behind the creation and distribution of a package, illustrated in Figure 12-38, is fairly straightforward. We begin, as always, with the SMS administrator defining the package, distribution points, and programs. This information is written to the SMS database by the SMS Provider. This action triggers SQL Monitor to write a package notification wake-up file to Distribution Manager's inbox (\SMS\Inboxes\Distmgr.box). The wake-up file takes the form of a site code and package ID as the filename with a .PKN extension. For example, a package notification file for site A01 might be named A0100003.pkn.
The Distribution Manager component wakes up and processes the package based on the package details you provided. Distribution Manager performs the following general tasks:
Figure 12-38. The package distribution process flow.
If you specified that a compressed version of the files should be used, Distribution Manager will compress the files and store them either in the location specified when the Software Distribution component was configured (this process is discussed in the next section) or by default in the SMSPKG folder created on the drive on which SMS was installed on the site server, with the same filename and the extension .PKG.
Distribution Manager then copies the source file directory to the SMSPKGx$ folder created on each specified distribution point within the site. If the package files were compressed, Distribution Manager uncompresses them first.
Distribution Manager generates three files and writes them to the SMS\Inboxes\Pkginfo.box folder on the site server. These files (with filenames as described earlier) are:
The Inbox Manager component, as it is wont to do, copies these files to the Pkginfo.box folder on each CAP. These files serve as instruction files for the client after it receives an advertisement. At this point, the process stops unless the package needs to be sent to a child site.
If the package does need to be sent to a child site, Distribution Manager writes a package replication file (.RPT) to Replication Manager's inbox (SMS\Inboxes\Replmgr.box\Outbound). If a compressed copy of the package source directory does not already exist, Distribution Manager also compresses the source directory into a temporary directory on the site server and then moves the file to the SMSPKG folder (on the SMS installation drive on the site server or the drive you specified when configuring the Software Distribution component).
Now Replication Manager takes over and begins the sending process. This process is discussed in detail in Chapter 4, so we'll look at only the highlights here. Replication Manager creates a minijob for the Scheduler and places it in the Scheduler's inbox (SMS\Inboxes\Schedule.box). The Scheduler creates the package and instruction files needed for sending the data in question, as well as a send request file for the sender. The package and instruction files are placed in the SMS\Inboxes\Schedule.box\Tosend directory. The send request file is written to the preferred sender's outbox (SMS\Inboxes\Schedule.box\Outboxes\sender, where sender is the sender folder, such as LAN, RASAsynch, RASISDN, and so on). Recall that both the sending priority and the preferred sender are identified in the Package Properties window.
When the send request file is written, the sender wakes up and reads the file. It also examines whether the address properties have placed any restrictions on when requests of this priority can be sent and whether there are any bandwidth limits. It then changes the extension of the send request file to .SRS and writes status information to it.
The sender connects to the target site's SMS_SITE share—the SMS\Inboxes\Despoolr.box\Receive directory—where the Despooler component on the target site will complete processing of the information at the target site. When the data has been completely transferred, the send request file is updated to a status of "completed," and the file is then deleted. Distribution Manager on the target site will carry out any necessary tasks. For example, if you identified distribution points at the target site, the Despooler will decompress the package and pass it to Distribution Manager, which will process the package for those distribution points.