Review each of the following sections and take notes as instructed. This information will help you to configure your software packages and their components.
You can distribute software packages containing files and applications for servers, as well as software packages containing end-user applications for further distribution in ZENworks for Desktops (ZfD) to workstations. For information on configuring a Desktop Application Distribution, see the Novell Documentation Web site, and under Administration, click Application Management.
If you have ZfD 4.0.1 installed, you can also distribute desktop applications using TED, instead of including them in software packages. For more information, see Desktop Application Distribution.
You can include a file or application in more than one software package. For instance, a word processor application could be included in a software package designed for a secretarial group and one designed for a financial group.
Where applicable, organize the files and applications into logical groups for inclusion in software packages.
Follow the steps under Creating a Server Software Package and Creating the Software Package Components and note the information you will need to know for creating the software package and its components.
You can have one or more components in a software package. For example, if you create a software package for installing virus protection software, you might want one component to be the original virus protection program, and another component a current virus pattern update file.
Components in a software package can each have the same or different installation requirements. If you give the components different requirements, they might not all be installed together. You can save time and minimize error by giving all of the components the same requirements.
IMPORTANT: Files and applications that are dependent on each other should be included in the same component. This will prevent problems running the files or applications if a critical component is not installed. If you need to split an application's files into multiple components, make sure that you make each component's requirements the same, so that they will all install or not install together.
Follow the steps under Configuring the Software Package Components and note the information you will need to know for configuring the package components.
Minimum requirements establish whether a software package will be allowed to install on the target machine. If these requirements are all met, the software package can be installed on that server.
However, requirements can be established for the software package as a whole, as well as for each package component. Therefore, if the package's requirements were all met, but some component requirements were not met, only part of the package would be installed.
Follow the steps under Configuring the Server Software Package and note the information you will need to know for configuring the software package.
The following sections explain where to store Server Software Package files, and how to manage them:
There are three file types associated with software packages:
Configuration File (.SPK): When you create a Server Software Package, you will initially create a configuration file (.SPK) for it. This file's configuration is created in the properties of the software package object in the Server Software Packages namespace in ConsoleOne.
.SPK files are generally small (around 100 KB). Therefore, they can generally be stored on the workstation running the instance of ConsoleOne that you are using to create and manage software packages.
Compiled File (.CPK): When you compile a software package, a .CPK file is created from the .SPK file's configuration information. This provides the content of the software package, such as files or functions. The .CPK file is used to install the software package's content on a server.
You should generally store .CPK files on a server where there is sufficient free disk space, because compiled software packages may contain many files. However, small .CPK files that only contain functions can be stored on a workstation.
Preferences File (.SER): The preferences file (SNAPINPREFS.SER) is automatically created on the workstation being used to create a software package. It contains pointers to the .SPK files for the software packages.
This preferences file allows you to see the software packages in the namespace in ConsoleOne. In other words, software packages will be displayed in the Server Software Packages namespace for an instance of ConsoleOne only if the .SPK file's path is listed in the preferences file located on the workstation running that instance of ConsoleOne.
When you create a new software package, you will specify the local path for the .SPK file. When you compile a software package, you will specify the server's path for the .CPK file. After you exit ConsoleOne, any time you have created, deleted, or compiled a software package, the .SPK file paths are logged to the SNAPINPREFS.SER file.
The path to the .CPK file is also logged to the SNAPINPREFS.SER file. Therefore, the next time you compile the software package, the wizard will be able to display the .CPK file's previous location so that you do not have to remember it each time you compile the package. However, you will need to note where you store the .CPK files for when you want to distribute them using TED, because the .CPK files' locations are not stored in the software package's properties.
You have two options for managing software packages:
If you will be using only one specific workstation for viewing, creating, and managing all of your software package files, then you can store the .SPK files on that workstation.
It is possible to manage your software packages from multiple workstations. This requires that you centralize your .SPK file storage to a network server. This method will also require the use of a master SNAPINPREFS.SER file so that you can view all of your software packages from any workstation.
The next sections explain these two options.
If you will use only one workstation for viewing, creating, and managing your software packages, you can store the .SPK files on the workstation and the .CPK files on a server.
Whether you are running ConsoleOne from the workstation where it is installed or from a workstation that uses an installation of ConsoleOne on a network server, the SNAPINPREFS.SER file is updated on the workstation being used to run ConsoleOne.
If you want to use multiple workstations for viewing, creating, and managing the same set of software packages, you will need to store all .SPK files on a network server so that they can be accessed by each workstation.
You may also want to use different workstations for managing different sets of software packages. Any workstation used to create .SPK files will have a software package preferences file of its own created on the workstation used to manage the software packages.
You can manage all of your software packages from multiple workstations if you use a master copy method for the SNAPINPREFS.SER file.
When you create a Server Software Package object in ConsoleOne, a software package preferences file (SNAPINPREFS.SER) is created in the following location on the workstation running ConsoleOne:
C:\Documents and Settings\user_ID\.consoleone (Windows 2000)
or
C:\Winnt\Profiles\user_ID\.consoleone (Windows NT)
where user_ID is the user directory associated with how you are logged on, such as Administrator.
The full path and filename for a software package is drive-dependent. The SNAPINPREFS.SER file contains the drive letter, path, and package name for each .SPK created by the workstation.
The SNAPINPREFS.SER file is unique for each workstation. It is the preferences file that is updated whenever you add or remove .SPK files using that workstation. Therefore, if you use three different workstations to create .SPK files, you will have three different SNAPINPREFS.SER files, each on its own workstation.
When you start ConsoleOne, it checks to see if a SNAPINPREFS.SER file was created for that workstation by the instance of ConsoleOne being run on the workstation, and whether ConsoleOne is installed on that workstation or is being run on that workstation from an instance installed on a server. If the file does not exist, a SNAPINPREFS.SER file is created when you exit ConsoleOne. If it exists, the SNAPINPREFS.SER file is updated with the full paths to any new .SPK files.
You can copy a SNAPINPREFS.SER file from one workstation to another. However, after replacing a SNAPINPREFS.SER file with a copy from another workstation, you will need to restart ConsoleOne to see any change.
A software package can become unusable if you change drive mappings after creating the package, because the SNAPINPREFS.SER file's location to the package will then be different. However, if you use a UNC path, this is not an issue as long as the workstation has access to that UNC path.
If you replace the SNAPINPREFS.SER file on a workstation, you will need to manually insert any software packages missing from the newly copied SNAPINPREFS.SER file. Otherwise, the software packages listed in the SNAPINPREFS.SER file that was replaced would be inaccessible on the workstation.
Even if a workstation has never been used to create a software package, you can copy a SNAPINPREFS.SER file from another workstation to the appropriate location (C:\....\.CONSOLEONE). Then when you start ConsoleOne, you will see all of the software packages listed in the SNAPINPREFS.SER file that was copied.
For more information, see Example in Using a Master SNAPINPREFS.SER File.
If you will be using multiple workstations for creating, deleting, and compiling the same set of software package files, you should do the following:
This will allow you to see all software packages from the workstation where you started ConsoleOne.
This will create a new master copy of the .SER file containing the workstation's latest software package additions.
Using a master copy for the SNAPINPREFS.SER file will work only if you exit ConsoleOne on one workstation, then start it on another workstation. This sequential method will not work for concurrently running instances of ConsoleOne where each instance is updating its local SNAPINPREFS.SER file. The instance of ConsoleOne that is exited last will overwrite the master copy with its local .SER file.
IMPORTANT: Creating, deleting, or compiling software packages in ConsoleOne are the only functions that cause logging to the SNAPINPREFS.SER file. Therefore, you can use ConsoleOne to manage software packages, such as viewing and editing properties, without starting ConsoleOne from the batch file. Just make sure that you do not add, delete, or compile any .SPK files in ConsoleOne if you do not start ConsoleOne with the batch file.
To manage software packages using this master copy/single server/multiple workstation method, observe the following general rules:
You need to do this because the batch file will always overwrite the master copy on the software package storage server when ConsoleOne is exited (if ConsoleOne was started by the batch file). You could inadvertently overwrite the master SNAPINPREFS.SER file and lose links to newly created software packages.
For example, on Workstation_A you run the batch file to start ConsoleOne, do administrative work other than software packages, for some reason go to Workstation_B where you decide to create a new software package (so you use the batch file again), exit ConsoleOne on Workstation_B, then later exit ConsoleOne on Workstation_A. Your new software packages created on Workstation_B no longer have links to them in the master SNAPINPREFS.SER file.
The best scenario is that you have one administrator who can use multiple workstations to manage your software packages. Otherwise, if you have multiple administrators, they need to be coordinated so that they don't overwrite each other's latest software package additions and deletions in the master SNAPINPREFS.SER file.
For more information, see Example in Using a Master SNAPINPREFS.SER File.
Keeping the master copy on the server properly updated is a matter of timing. For example, in the following scenario, the first SNAPINPREFS.SER file was initially created on Workstation A, then copied down to the network server to be the master SNAPINPREFS.SER file. Both workstations are using Windows 2000.
A batch file is used to start ConsoleOne for the purpose of controlling events before and after using ConsoleOne.
This is the same version of SNAPINPREFS.SER that Administrator A had copied up to Workstation A, except that it hasn't been updated yet with Administrator A's addition of SSP1.SPK.
This updated master SNAPINPREFS.SER file now contains the location of SSP2.SPK.
This updated master SNAPINPREFS.SER file now contains the location of SSP1.SPK. However, the location for SSP2.SPK has been lost, because Workstation B's update of the master SNAPINPREFS.SER file was overwritten by Workstation A's later update.
This scenario would cause Administrator B to lose access to SSP2.SPK, because the master SNAPINPREFS.SER file will no longer contain a record of SSP2.SPK's location. It was replaced with Administrator A's SNAPINPREFS.SER file containing only SSP1.SPK's location. However, SSP2.SPK can be manually inserted into ConsoleOne (using the Insert Software Package option), so that it will be listed in the SNAPINPREFS.SER file along with SSP1.SPK.
For this multiple-workstation management method to work, you must ensure that the master SNAPINPREFS.SER file you keep on the network server is only used by one workstation at a time for creating, deleting, or compiling .SPK files. However, you can use multiple workstations to simultaneously view or edit a Server Software Package object's properties, because the viewing and editing functions do not cause updates to a SNAPINPREFS.SER file.
WARNING: You can perform edits to the properties of the Server Software Package object without affecting the SNAPINPREFS.SER file. However, because Server Software Package objects are not in eDirectoryTM, but only in a name space, the .SPK files might not have file-locking protection, unless the server's operating system provides this functionality. Therefore, you should devise management controls to protect against overwriting .SPK files when using multiple workstations to manage software packages.