Question
SVS Integration with Notification Server - Part 7: Custom Inventory

Answer
In Part 6 of this article series the basic concept of Inventory Solution and how Software Virtualization Solution fits in with the current version was covered. Part 7 now takes the concept into practice, showing how Custom Inventory can be setup to capture the state of the layer, and how the audit data can be used to join the data and show a complete picture of what layers are activated on the target computers. The best part is that both the SVS stand-alone agent and the SVS Solution integration are supported.

Introduction

This article will cover what audit data is captured that is relevant to determining if the .exe is part of a Layer and walk through a Custom Inventory for capturing the data necessary to tell if the Layer is active or not. With the two, we determine what layers are active, and you can even use the audit data to show what layers are not active. This article will focus on configuring Inventory to capture the necessary information.

Inventory Audit

The software audit captures all header information and data from the file properties, including the file path. It’s the file path that clues us into whether an .exe is contained within an layer or not. The default file path will contain C:\fslrdr. Note that this location can be changed by using a command-line when importing the layer.

Configuring the Audit

By default, Software Inventory will capture executables used by SVS, with two exceptions. First, the default Audit scan runs in Package mode, which means we may not capture all individual files for an application. To keep it simple, we’ll recommend switching to File Mode so this will not be a factor. The second potential problem occurs if the application files do not conform to a standard Windows application. The following walks through a simple process of how to add file types and set the Audit scan to File Mode.

1. On the Notification Server browse to install path\Program Files\Altiris\Notification Server\NSCap\Bin\Win32\X86\Inventory Solution.
2. Open the following files. We will make the same change to each file:
   • AeXInvSolnAdm2.ini
   • AeXInvSolnAdm2.ini
3. Under the line that calls AeXAuditpls.exe, add a /file command line switch, as shown:

   aexauditpls.exe /hidden /file…

4. Save the files. Within 24 hours most clients should have the updated mode.
5. Browse back to the X86 folder (one folder up from Inventory Solution) and launch AeXAPEdit.exe.
6. Go to File > Open and browse to the auditpls.ini file location within the Inventory Solution folder. (The default open will point to the X86; you do not want the auditpls.ini located in that location.)
7. Under the File Masks tab, include filenames and extensions you want captured.
8. Under the Include Unknown, check all options that apply to the files you want (if you’re unsure, try checking all of them and then work your way back if the result set is too large).
9. Save the file. As with step 4, the changes will take time to propagate out to the managed clients.

SVS Identifiers

What data in the audit scan signifies an SVS layer? The obvious one has been covered. The file path will not contain the typical Program Files designation, but will be either the default folder C:\fslrdr or another folder designated during the install. The data will be contained in the File Path column of the AeX SW Audit Software data class. The following examples show how the file path will look:

• C:\fslrdr\1\[_b_]programfiles[_e_]\mozilla firefox
• C:\fslrdr\3\[_b_]mssharedtools[_e_]\Office11

The organization or file structure works by placing two numbered folders for each layer. The SVS Agent will sequentially populate the folders as layers are imported. The subsequent folder contains a beginning and ending tag, including the text of the corresponding system folder the files are normally found at. After that the folders and files are mirror the actual installed files of the application. Another unexpected signature of a layer is the Directory Time and File Modification Time. These will contain the values when the layer was captured, and not when the layer was activated or imported. The above data can be used to identify files that belong to layers, and where the file would normally reside if the application was installed normally.

Custom Inventory

The registry contains the necessary information to complete the picture on active or inactive SVS layers. It also provides a snapshot of where the files for the layers are kept.

Required SVS Data

The Registry location where we capture SVS data is HKEY_LOCAL_MACHINE | System | Altiris | FSL. Under this folder we have numbered folders that coincide directly with the folders located at C:\fslrdr\. Within these folders are the registry settings for the specified layer. In the example Custom Inventory provided in this article, the following values are captured:

1. Registry key the two following values are stored. We capture the number of the registry key, which coincides with the containing folder for the application files.
2. Name. The name of the VSA (Virtual Software Archive) is included here.
3. Active. This lets us know if a layer is active or not. A 1 represents active, while a 0 represents inactive.

Registry Capture

To capture data from the registry, we configure a file in XML format. The following walkthrough demonstrates how a default template is changed to capture the previously indicated registry data on SVS. The key components required in the file are

• Data Class Name. This will signify the name of the data class and thus the name of the underlining table in SQL.
• Attributes. This is the data structure to be used for creating the columns (when Custom Inventory is sent for the first time) or populate existing columns of the same data types. Simply put, this is the SQL schema.
• Data Source. This is the source of where the data will be pulled from. For registry items like this one, it is a registry key. Further, there are pointers to exactly what data to pull from the main data source location, such as values from a registry key. The values are named, and their associated data captured.

The rest of the code presents the data in a way Custom Inventory recognizes, allowing the specified data to be collected.

SVS Custom Inventory Walkthrough

The following steps show how this particular Custom Inventory came into being. There’s no need to write the entire XML code as a few basic templates supply most of the required XML structure. See kb: https://kb.altiris.com/article.asp?article=4237&p=1 for a repository of sample files are provided for Custom Inventory. For this walkthrough, the file reg_recurse.xml was downloaded from https://kb.altiris.com/article.asp?article=4237&p=1. The file appears as such:

Reference the following picture in reference to the steps below:

1. Open the file reg_recurse.xml in Crimson Editor (www.crimsoneditor.com) or another true XML editor.
2. Change.
3. Change the description=’ to description=’Reg Entries for SVS’
4. Change the mifClass=’ to mifClass=’Altiris|SVSLayers|1.0’
5. Under the first AttributeType, change rs:name=” to rs:name=’KeyName’
6. Delete the text along the same line labeled: rs:basecolumn=”Pkg Name”
7. Change rs:keycolumn=”false” to rs:keycolumn=”true”
8. Change mifAttrId=’5’ to mifAttrId=’1’
9. On the next line, under the second AttributeType, change rs:name=” to rs:name=”Name”
10. Delete the text labeled: rs:basecolumn=”Country Code”
11. Change mifAttrId=’5’ to mifAttrId=’2’
12. On the next line, under the second AttributeType, change rs:name=” to rs:name=”Active”
13. Delete the text labeled: rs:basecolumn=”Pkg Directory”
14. Change mifAttrId=’5’ to mifAttrId=’3’
15. Delete all other AttributeTypes, as shown in the screenshot. The two tags to delete between are and (do not delete these tags, but everything between them. The first tag is the closing tag of the third AttributeType)
16. Change RegPath3=” to RegPath3=”HKEY_LOCAL_MACHINE\System\altiris\fsl”
17. Change <%set sCheckType= to <%set sCheckProperty=
18. On the same line as above, change reg:%sCheckPath%\type”%>to reg:%sCheckPath%\active”%>
19. Change <%if %sCheckType to <%if %sCheckProperty
20. On the C1 row change Description to name
21. On the C2 row change installedby to active
22. Delete the rows for c3 and c4.
23. The file edits are complete. The completed file should look like this:
    
24. Save the file with the name svs.xml (this name can be different and should be properly referenced in the below steps).
25. Copy the file to the following location: install path\Program Files\Altiris\Notification Server\NSCap\Bin\Win32\X86\Inventory Solution\.
26. Edit the four inventory INI files to add a line to call AeXCustInv.exe to capture this information. The three files are
    • AeXINVSolnAdm1.ini
    • AeXINVSolnAdm2.ini
    • AeXINVSolnAdm3.ini
    • AeXINVSolnUsr1.ini
27. The line should be added after the existing call to AeXCustInv.exe, as shown in this example in the AeXINVSolnAdm2.ini:
    • aexauditpls.exe /hidden /output xml
    • aexmachinv.exe
    • aexcustinv.exe /in .\AeXCustInvStd.cit /out AeXCustInvStd.nsi
    • aexcustinv.exe /in .\svs.xml /out svs.nsi
    • aexsnplus.exe /output xml
    • aexnsinvcollector.exe /hidden /nsctransport /v default /useguid
28. Update each file in the same manner.
29. The Notification Server will update the Distribution Points in time, but this operation can be done manually by pulling up the details of the Inventory Package and clicking the ‘Update Distribution Points’ button. Inventory will now be collected!

Conclusion

Inventory and Custom Inventory is now configured to capture the necessary data to report what computers have active SVS layers employed. The next part of this article series (part 8) will cover creating useful reports on the captured data. The files provided in this article are provided “As is”, and contain no guarantees in your environment. It is highly recommended to test the implementation before rolling out any custom inventory captures in production environments.