What kind of Layer Management can you achieve via the Notification Server CMDB? This article explores the usage of the accumulated data from SVS Packages, Programs, Execution statuses, and Tasks in order to better manage the layers in use within the environment. The information in this article will be utilized in both the Reporting and Collection sections of this series, as well as those sections that cover integration with other Notification Server based solutions. The secondary focus is to explore the database schema and how the information is stored within the CMDB.

Introduction

The primary use for the Software Virtualization Solution for Notification Server is to deploy and manage layers in a distributed environment from a secure, remote location. In deploying and managing layers data is captured into the Altiris CMDB that can be utilized for multiple purposes, from reporting, collection building, and troubleshooting. As the database structure and processes are revealed, more possibilities open up not only with SVS, but with other Notification Server products as well.

Database Structure

SVS primarily uses the Software Delivery database tables for management of Packages and Tasks. Understanding this structure and how it interacts with all SVS Tasks can enable tighter deployments and maintenance of these tasks. It will also assist in troubleshooting issues that arise with either the Notification Server Infrastructure or Software Virtualization Solution.

Database Schema

There are three main tables used for the management of the elements used to deploy and manage VSPs to client systems. The tables are listed here with the general description of how they apply:

• SWDAdvertisement -- This table contains the details of all Software Virtualization Tasks. The columns correspond to the options available when configuring a SV Task. The primary dependency is the ProgramId that ties a package and program to the Task.
• SWDProgram -- This table contains the details found under the Programs tab when configuring a VSP (Virtualization Software Package). The Program Guid is tied to a Package Guid.
• SWDPackage -- This table contains the information for the Package save for the Program tab.

The following table provides descriptions and the schema of the above tables for use in deploying and managing VSP and Tasks:

Table Interdependency

The three tables detailed before are connected by a series of Guid references. These tables contain most of the data used by the Notification Server, Altiris Agent, and Software Virtualization Agent. The main Notification Server table for any object (whether Task, Package, Program, Computer, Collection, etc...) is the Item table. The primary Guid in each of the tables SWDAdvertisement, SWDProgram, and SWDPackage (AdvertisementId, ProgramId, and PackageId respectively) have entries in the Item table that contains additional information about the object. The Program Guid is also referenced by both the Package and Task tables.

The following diagram details the basics of this concept:

Click to view.

The above graph does not include the ItemReference (Table) entries used to further reference each required item. For example the Task contains an ItemReference entry to point to the Collection being used, as shown below. The 'Hint' column shows what type of reference it is:

Query:

 SELECT * FROM ItemReference 
WHERE ParentItemGuid = '648B87E0-43E0-49E7-9822-3003301C89E2'

Result:

648B87E0-43E0-49E7-9822-3003301C89E2 | A87BB5BA-0BA5-4FE2-9315-0D85BAE71A04 | policyappliestocollection | 0 | 2007-02-01 16:03:10.140 | 2007-02-01 16:03:10.140

Collections

Another important component of the Notification Server (and thus SVS) database structure is Collections. Collections can either be a static list of systems (reference by their Guid) or a dynamic SQL query that returns a list of systems by their Guids. By populating a collection with computers using a query, the parameters, filters, and criteria can be widely controlled. This part of the articles series does not cover how to use the data in the database for Collections as this will be covered in an article devoted to Collection management.

Layer Management

How management is achieved via Notification Server at its basic level is covered in this section. Collections, Reports, and Inventory Solution can be used to greatly enhance management and are covered in subsequent articles in this series.

Virtual Package delivery

When everything is properly configured, the VSP needs to be delivered to the target systems. This is accomplished through the basic Software Delivery model used by virtually all Notification Server Solutions. There are some distinct differences in the visual representation of these items, but they are the same as other solutions. The particulars are covered here:

• When selecting a VSP, the browse is looking for a file. That file, and everything in the same directory on down, becomes a 'Package'.
• The execution references the path \Program Files\Altiris\Software Virtualization Agent\SVSCMD.exe. Normally there is a 'Working directory' option, but with SVS it is always the Agent folder.
• The SVS Agent is strictly accessed via the command-line. It's the location and command line that make a Software Virtualization Task perform SVS operations. Thus in the command line all specific identifiers and actions are defined, including:
  • SVS Agent Call
  • Guid of VSP for which Layer is to be acted upon
  • Actions via Command-line parameters
  • Other parameters as necessary
• Download and Execution events are received from the Altiris Agent as with any Package and Program. This allows for reporting and can be utilized for maintenance or layer remediation tasks.

Process of Delivery and Execution

The basic flow is as follows with their corresponding tables:

1. A Package is created that contains a location where a VSP resides [SWDPackage].
2. Via the Program tab the various actions available for the VSP are stored, which is connected to a Package via the PackageId [SWDProgram].
3. A Task is created that provides a schedule for executing one of the Program actions, thus it pinpoints a specific Program via the ProgramId [SWDAdvertisement].
4. A Collection is selected that lists the computers to receive the Task, pinpoints the Program action, and connects to a package.[vCollection].
5. The target computers use the above interdependencies to:
   1. Download the Package (VSP)
   2. Receive the Execution environment including the command line (Program)
   3. Receive the Schedule details for the execution (Task)

Layer Repository

The VSP files are downloaded to the cache folder within the Altiris Agent directory tree. This location is the standard for all downloaded files for any Solution via the Altiris Agent. For example:

C:\Program Files\Altiris\Altiris Agent\Software Delivery\{018852CA-1C1E-47E9-945B-0179ED6B8747}\cache

• The cache folder is the root of the Package. If there are additional folders in the package they will originate in this directory.
• The Guid is the PackageId for the VSP file selected.
• This means that the actual VSP file repository resides in this format. The difficulty is identifying which GUID folders are VSP and which ones are used by other Altiris Solutions.

Conclusion

The database schema gains complexity if the entire reference items are fully mapped. This article strives to present only the most relevant data for elementary use of SVS in the Notification Server framework (CMDB). Hopefully this provides enough of a picture to begin troubleshooting or using the data in the Altiris CMDB for SVS management.