SVS Integration with Notification Server - Part 6: Inventory Solution

SVS Integration with Notification Server - Part 6: Inventory Solution
Joel Smith's picture

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 SVS in Notification Server, there are pre-canned reports that provide good information.

However, how accurate is this data? And will SVS 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 questions.

Introduction

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 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 Solution 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 is not 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. 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 (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:

  • Recreate 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 e-mail 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 NS
    • http://<servername>/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 Recreate Full Inventory or Software Inventory
  3. Inventory Agent Package Downloaded to client machine
    • 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 a *.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://<servername>/altiris/ns/agent/postevent.asp (https if SSL is implemented)
  8. The NS 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 NS and Inventory, 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: 1.5.0.1
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 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.

Conclusion

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 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.

4.076925
Average: 4.1 (39 votes)

Why to use inventory solution?

Why to use inventory solution for SVS inventory?

SVS in itself includes NS agent that communicates to NS what SVS layers are imported to workstations, which one are activated and/or deactivated and when these events have happened.
Only quirk is that it does not report correctly layer delete events.

This functionality does not have anything to do with Inventory with Windows. And with that you don't need to have custom inventory for reporting which layers are active which not.

Personally I would not use Inventory for Windows to collect any SVS related data unless exe file data is needed for the Asset Management / License Management.

----
Masi

SVS Solution versus SVS Stand-alone - Inventory captures it all

Joel Smith's picture

Not all SVS implementations are Solution-based. Stand-alone agents and self-imported layers are not reported to the SVS Solution, even if the Altiris Agent (NS agent) is present.

Not only that, but the data reported to SVS in Notification Server only provides you information captured during a Task for SVS. In other words if you deactivate a layer without using a NS Task to do it, the NS will not have the correct status in the CMDB. Only actions executed by the Solution will change the data in the Inv_Software_Virtualization_Status table to reflect the current status. This is true for any action you take against a layer.

SVS Solution at this point does not have an actual "Inventory" mechanism to scan and look for active or non-active layers. To truly have up-to-date information on what layers are available and what is currently active, Inventory Solution must be used or another method that correctly "inventories" for the data.

Hope this helps clarify the reason for this article.

One last note: In version 7 of NS, Inventory, and SWD layers will be properly deployed and inventoried without the need for customization.

Regards,

Joel Smith
Altiris Support
Principle Support Engineer

I agree there is difference

I agree there is difference with stand-alone SVS installation and SVS installations to managed computers (that has Altiris Agent).

Also true that SVS does not have inventory mechanism. But it does integrate to NS little bit differently than what you point out.

I still don't see point to use Inventory Solution on managed workstations and here is some reasoning for my opinion:

SVS installation includes 'Altiris NS Support' feature that is sub-agent for NS Agent. As long as it is installed on the workstation that has NS Agent all activate / deactivate / import / delete events are reported to SVS Solution on NS.

It does not matter if the action is executed by SWD task or by user on SVS admin or on command line. All these actions are reported back to NS.

To see SVS layers that exists on specific computer(s) and the state of layers (active / deactive) is shown on SVS Solutions out-of-box reports.

SVS NS agent reports those events to CMDB after those are executed, quite a much real time if there is connection to NS.

Inventory Solution's reporting is based on Inventory run schedule which is usually set to be run from once a week to once a month.

So with SVS sub-agent we have up to date information what layers exists on which workstation and the state of these layers. Usually this is good enough, not always.

To know what .exe files are included to some specific SVS layer Inventory Solution can be used, but I would not recommended it.
Wise Package Studio 7 includes tools for building software repository. With WPS Software Manager tool you can import virtual packages to Wise Software Repository and have reporting which files, registry keys etc. are included to virtual package, including .exe files.

With custom reports these informations can be mapped to together and have nice reporting.
Also it can be mapped against Application metering data to have nice usage reporting.

Why not Inventory Solution?
Inventory Solution can only inventory once one .exe file on workstation, second file is "skipped". (Actually second file is found but it will not e reported to CMDB).
This is not usually big problem, but with SVS it can be. File redirection area is by default c:\flsrdr, but if the redirection area is definded to be d:\fslrdr there is possiblity that .exe file is first found on c:\Program files\software\ folder if the layer is active. In this kind of case Inventory Solution would not make any record of this .exe file existing also on d:\fslrdr\ folder.

Of course Inventory Solution process should be added to ProgramIgnoreList which would prevent this to happen.

Not managed workstations with standalone SVS installation are different story.
----
Masi

It can be configured

Joel Smith's picture

Masi,

Thank you for raising this point. It's not one I thought about when writing this article. Fortunately there are ways to have Inventory report all instances of a file.

Two quick items on how Inventory can properly report all instances of a file:

First, in the files:
AeXInvSolnAdm2.ini
AeXInvSolnAdm3.ini

Add a /file switch to the line that calls the audit scan (AeXAuditPls.exe). The command line should look something like this:

aexauditpls.exe /hidden /file /output xml

This will put the audit into all file mode.

Second, there is a limitation due to our File Path value not being a key value. This can be worked around using the following KB Articles:

https://kb.altiris.com/article.asp?article=35400&p...
https://kb.altiris.com/article.asp?article=21466&p...

This should address any concerns raised by Masi.

Joel Smith
Altiris Support
Principle Support Engineer

Syndicate content