SVS Integration with Notification Server—Part 6: Inventory Solution

Article:HOWTO8489  |  Created: 2008-01-15  |  Updated: 2008-01-15  |  Article URL
Article Type
How To

SVS Integration with Notification Server - Part 6: Inventory Solution

Want to know who’s utilizing the magic of SVS in your environment? Do you need to track who’s using applications requiring a license? Do you know what layers are being used in the environment, how many are being used, and on what computers? If you are using the SVS Solution in Notification Server, there are pre-canned reports that provide good information. However, how accurate is this, and will SVS Solution know if a user has deleted, removed, or added a new layer outside of the Solution infrastructure? Even if a user is utilizing the stand-alone version of SVS, there is a way. Inventory Solution has the ability to inventory SVS layers, providing all the data you need to answer these question.


Inventory Solution for Windows, as of version 6.1.1058 (SP2), has the ability to inventory SVS layers, whether they are managed by the Notification Server Infrastructure through SVS Solution or Software Delivery or if they are managed by the stand-alone SVS Agent. This ability not only allows you to identify all applications being utilized on a system, it also allows you to have updated data on how SVS is being used in the environment.

Note: This article should be used in conjunction with article: SVS Integration with Notification Server - Part 7: Custom Inventory. The two articles will allow reports to be built showing what computers are running what active layers. Consider the following use cases for using Inventory Solution for SVS Inventory:

  1. Find out if layers have been deactivated or removed from managed systems.
  2. Discover layers that are not managed and have been added by users.
  3. Get an accurate count of how many instances of each virtualized software application is utilized in your environment.
  4. Get accurate audit information.
  5. Discover layers containing unapproved applications to avoid misuse of virtualized applications.

Inventory Solutions basics

Inventory Solution requires the Notification Server infrastructure to be actively managed. Inventory Solution does have the ability of stand-alone inventory where the Altiris Agent isn’t required. Only the very basics will be covered here. For more information, see the Inventory Solution reference guide. The agent responsible for the software audit is the Altiris Audit Plus Agent (Auditpls). Unlike a standard DLL agent that plugs into the Altiris Agent, the Auditpls agent is simply wrapped in an executable (AeXAuditPls.exe). The .exe references an .ini file for the settings of how it conducts the scans by command-line. By default the .ini file used is auditpls.ini, but custom files can be used. For SVS layers, no additional configuration needs to be set as the Auditpls agent scans the layers natively. This allows for easy integration with SVS Solution. Note that no matter how the auditpls.ini file is configured, the audit scan will scan all files unless an exclusion for a specific file or drive has been defined. By default all SVS layers are included in the scan, and all files within the layer will be properly inventoried.

Inventory Solution—Managed

The following items are required for Inventory Solution to function in a managed environment:
  1. Notification Server 6.0 SP3 R4+ with Inventory Solution for Windows installed (must be version 6.1.1058, which is SP2, or later)
  2. Altiris Agent
  3. Inventory Agent Package
Software Inventory contains the audit agent which can detect and inventory SVS layers. Not all default Inventory Tasks run the audit scan. A custom scan can be created, or the following Tasks can be utilized that already include a full audit scan. Only these tasks run the Software audit agent at time of execution:
  • Re-create Full Inventory: This is a full Inventory where all Inventory will be sent regardless if it has been sent previously.
  • Software Inventory: This will only send a delta inventory—typically the Software Inventory will be sent every time even with a Delta Inventory.

Inventory Solution—Stand-alone

Stand-alone Inventory still requires a delivery mechanism to get the audit agent to the system, but this can be anything from a flash drive, CD, to an email containing the package as an attachment, or a link to the stand-alone agent URL. The Inventory Web Package is a self-contained .exe with all applicable Inventory Agents and configuration file. It is located at: Install path\Altiris\Notification Server\NSCap\Bin\Win32\X86\AeXWebInvPkg.exe. This Web Package is configured similarly to the files to be used by the Altiris Agent. By default Software Inventory is captured by this package and no editing is required. However, if you want to edit the package, you can use the Package editor located at install path\Altiris\Notification Server\NSCap\Bin\Win32\X86\AeXPkgEditor.exe. The following screenshot shows the editor:

If you are only interested in Software Inventory, you can remove the other lines representing the agent. (Note: The last line AeXNSInvCollector.exe… is required if you want automatic HTTP post-back to the Notification Server.) You can also remove the files using the Files tab for those components you don’t want to execute. If an HTTP connection is not available when inventory is collected, the command-line should be edited to include a location the inventory NSE can be sent to be collected and sent manually to the Notification Server.

Inventory Type

How does Inventory Solution Inventory software on a system? The audit agent scans each file on a system and collects data on .exe files (by default) that is sent back to the Notification Server, including much if the header information. To illustrate, see the following diagram:

  1. Clients request updated configuration from the Notification Server.
    • http:///altiris/ns/agent/getclientpolicies.aspx
    • Check the agent by bringing up the Agent UI and checking the Last Configuration Request date.
  2. The client receives the client config XML file containing the Tasks.
    • Servername.xml > C:\Program Files\Altiris\Altiris Agent\Client Policies
    • Does the Inventory Task exist in this file? Search for "Inventory" and ensure it’s either Re-create Full Inventory or Software Inventory.
  3. Inventory Agent Package Downloaded to client computer.
    • C:\Program Files\Altiris\Altiris Agent\Software Delivery\{01B54EB5-3679-4C73-9E10-E169D5A5EC59}\cache
  4. Task executes the command-line of the associated Program, including an .ini file reference:
    • AeXInvSoln.exe /cleanbeforerun /hidden /s AeXInvSolnAdm2.ini
  5. Associated command lines in the .ini file are run under the umbrella of the AeXInvSoln.exe launcher, including the software for SVS included here:
    • aexauditpls.exe /hidden /output xml
    • No /ini switch defaults to auditpls.ini
  6. The Inventory Collector parses through the collected files and compiles the data into an .nse file, handing it over to the Altiris Agent Transport mechanism via the last command-line in the .ini file:
    • aexnsinvcollector.exe /hidden /nsctransport /v default /useguid
  7. The Altiris Agent posts Inventory to the URL:
    • http:///altiris/ns/agent/postevent.asp (HTTPS if SSL is implemented)
  8. The Notification Server Event Router takes the Inventory NSE and places it in a queue:
    • Typically Program Files\Altiris\Notification Server\NScap\Evtqueue
  9. The Data Loader loads the Inventory into the associated data classes.
    • Note: Data is loaded "per resource," meaning that if a data class receives data, it will remove that resource’s rows from the database before inserting the updated inventory (rows).
  10. Data is now available in the database for SVS Layers.

Inventory and SVS Layers

Inventory Solution uses the standard audit agent to capture SVS data. In version 6 of Notification Server and Inventory Solution, SVS is not inherently "supported" in the sense that we can tell what applications are virtual and which ones are not. The standard audit data applies when capturing SVS files, but the nature of how SVS lays them down allows us to determine if a certain .exe is virtualized or not. The registry can then be used to determine if the layer is active or not. By default, the file location that the layer files are stored is C:\fslrdr\. This location provides the structure for the files to be used within the layers. Inventory doesn’t distinguish based off of location but will scan for configured files as normal within the layer structure. As such, we already have the capability to pick up what applications are potentially active SVS layers. We can’t tell which ones are active or not based on the file data alone, which is why Custom Inventory is required. File Data for SVS Layer captured by Inventory:
  • Manufacturer: Mozilla
  • Product Name: Firefox
  • Product Version:
  • Language: Language Neutral
  • File Name: firefox.exe
  • File Size: 7166053
  • Directory File Time: 3/3/2006 11:21:44 PM
  • Executable Type: WIN32
  • Internal Name: Firefox
  • KnownAs: Firefox
  • File Description: Firefox
  • File Path: c:\fslrdr\1\[_b_]programfiles[_e_]\mozilla firefox
  • File Extension: EXE
  • File Modification Time: 3/3/2006 11:21:44 PM

This information is from the File Properties or the File Header data respectively. Files other than .exe and .dll can be captured if desired. The audit scan has the ability to capture any file type, but, by default, Inventory Solution only captures applications with an .exe extension. Note the File Path in the above table. This shows the default fslrdr location to signify that this program is an SVS Layer. After capturing certain registry entries, we can verify an active layer by joining the captured file data and the registry entries.


The data is available and the basics for determining what the layer is laid out but stay tuned for the next part of this article series where we give real examples of how to configure Inventory Solution to capture if the layer is active or not. With a Custom Inventory we can capture the registry data that signifies if a layer is active or not, and correlate the folder and registry locations and/or name to link the data in a custom report.

Legacy ID


Article URL

Terms of use for this information are found in Legal Notices