The Software Catalog provides functionality and dynamic abilities in managing Software. As there have been many questions and confusion on how the Software Library interacts with the Software Catalog, this Frequently Asked Questions has been created to provide information and help you administer and successfully use the Software Library as part of the Software Catalog. This FAQ was written against version 7.6 of the Software Management Framework, but the details still apply to all 7.5 versions.
Questions contained in this FAQ:
The Software Library is a package source type that was added to the 7.0 release of Software Management. The Software Library allows for an Administrator to maintain all deliverable software packages within a single securable location, so that the packages are not spread out over various unsecured network shares or local hard drive locations. Essentially this creates a repository for the files associated to Software Resources.
In short, no, it is not required. There are some benefits for using the Library, covered in the subsequent section. It's important to understand what is gained and what is not, as some use cases may lend to a non-Software Library package source. All functionality that Software Management uses, including all Solutions who plug into the Framework (for example Patch Management, Asset Management, Inventory Solution, etc), is available regardless of the package source type.
There are various benefits to using the Software Library as the package source, and the primary benefits are outlined below:
- The Administrator is able to secure the Software Library so that only the Altiris Service is able to access it, and that only authorized administrators can perform actions that interact with the packages within the Software Library. This way unauthorized users cannot modify the package contents. While this can be completed manually with other Package Sources, using the Software Library simplifies the process.
- The Software Library allows Administrators to setup a single location that all of the delivery packages can be stored. This way the Administrator does not have to keep track of where the package exists (what network share or what folder on the local hard drive). This is especially important when access rights change or accounts are decommissioned, potentially severing the Notification Server's ability to reach the Package Source.
- By having all of the packages within one managed location it allows for the Software Library to be migrated to a new location in the event that the share needs to change. For example if the file server being used for the Library needs to be replaced, using the Library greatly simplifies the move process. During a migration the actual file contents would be moved from the current location to the new location, and the actual package source locations would also be updated within the Notification Server. This is all done by changing the location, found in the Symantec Management Console under Settings > All Settings > Software > Software Catalog and Software Library Settings > and select Software Library Configuration. When you change the location, you'll receive this prompt:
- Also, the ability to create software packages based upon files that are from various locations is introduced. When importing a package into the Software Library the user is able to select individual files or folders that can then be used in creating a new deliverable software package. For instance, the Administrator may want to include an MSI from one location and a MST from another location to create a single deliverable software package, and this can be accomplished by using the using the "Software Library" package source type when importing a package via the "Import Software" dialog or via the "Add or Edit Package" dialog.
With all the above benefits for using the Software Library, why would another package source method ever be used? The short answer is performance. The Software Library source-type includes a hash generation for all files within the Package. There used to be time out issues with the library, but for the most part these have been resolved. For very large files, or packages with a large amount of files, timeouts can still occur. If this is the case, using a different method than the software library will increase the change to avoid a timeout as the hashes are not created.
The reason the import process can take a long time is the MD4 hash created for each file within the Package. The duration of this process grows with many or larger files.
There are various misconceptions as to what the Software Library is and how the Software Library works. The following items below will hopefully clarify some of these.
- Is the Software Library and the "Software Catalog" the same? No, the catalog contains all Software Resources and Software Products. By housing these resources, it also has connection to the entire Software Resource model. The Catalog is comprehensive and contains a large amount of data on Software, including policies, tasks, metering info, licensing info, inventory, packages, command-lines, inventory rules (detection and applicability checks) Associations, file references, and Portal publishing information.
- Does the software package resource that is associated with the software resource need to be within the Software Library if the software resource is within the Software Catalog? No, the Software Catalog shows all software resources independent upon the associated software packages source type.
- Can I use the "Import Software" dialog to create a software resource that is not created within the Software Library, and still have the necessary metadata read from the installation file? Yes. While this functionality has been available via the Software Library, some improvements were added in Service Pack releases. This allows for any type of package source to be used to create a software resource so that the appropriate metadata is also created (software command lines, company resource, etc).
- Does having the package within the Software Library impact how the package is delivered to a client? In one aspect, yes. Instead of the NS providing the Package to Package Servers from the library, it must provide the access to the location the files were added to the NS from (local folder, or UNC provided when importing the package). Otherwise the process is exactly the same.
- Does the Software Library prevent package contents from being changed outside of the UI? No, not exactly. The concept of the Software Library allows for the Software Library location to be locked down so that only the Altiris Service can access the package contents directly, but the Software Library does not prevent anyone with access to this directory to modify the contents of the packages. It has no mechanism to monitor the source location. Instead, this information is stored for the next time the Package, in the UI, is updated to include more files, modified files, etc. This is where the hashes are used generated during the Software Library Import.
- Is the file hashing that is used by Software Library used in delivering the package contents? No. The hashing of the files that are located within the Software Library is used to maintain what files are needed to be uploaded to the server when a package is modified via the Package UI. This is under consideration for added security in our Package delivery process.
There are currently three different ways that a user can create a package within the Software Library, and each of these methods is outlined below.
- Import Software Dialog - The "Import Software" dialog allows for a software resource to be created based upon the software installation file that is selected within the initial screen of the dialog. If the package source is set to "Software Library" then the "package contents" that are defined within the dialog will be moved to the "Software Library" location. If the package source is not set to "Software Library" then the package contents will remain at the location that was specified, and the installation file that is specified will be parsed to gather any software meta data that can be gathered (software command lines, company resource, etc). This is the only method that will parse the provided files to automatically create the Rules, Associations, Company resources, etc). The import is launched under any of the Software views shown under Manage > Software > Software Catalog > right-click in the empty space and select Import Software. This screenshot illustrates where this can be accomplished:
- Add or Edit Package Dialog - The "Add or Edit Package Dialog" allows for a software package resource to be created, and allows for the user to specify any software installations files that they would like to define. These files can then be used within the "Add or Edit Command Line" dialog to create command lines based upon the installation file type. This is the traditional location for creating or editing Packages or Command-lines, and is found if you edit a Software Resource under the Package tab.
- Import Package action - The "Import Package" action can be taken on any software package that is currently not located within the Software Library. When this action is taken it moves the contents of the software package to the Software Library. For instance, if a package source is currently set to "UNC" then the contents of the package at the UNC location will be moved to the Software Library, and then the package will be a managed package.
Conclusion
The information presented in this FAQ is, as far as the author knows, is accurate at the time of publication. Changes to the underlining technology in subsequent releases from Software Management Framework 7.6 may render some of these details obsolete. Current investigations include adding additional security to the download of files.