Client Management Suite

This article covers how to manage your Software Components in relation to Inventory Solution, Software Management, and Asset and License Management. Managing what software you have in your environment is essential when facing license audits, reconciliation, reclamation, and deployment. By using the Software Catalog you tap into a powerful system where all points can be managed from a single location.

Tables of Contents

Software Components
     Component Views
     Elements
Creation/Inventory Methods
     Inventory Solution
     Data Provider
     Manual
     Targeted Software Inventory
Managing Software Components
     Merging Components
     Locating Legacy Components
Software Product Management
Database Schema
     LEGEND
     Table Translation
     Data Size
Conclusion

Software Components

Software Components are objects in the Symantec Management Platform that consists of metadata, Product, Version, Packages, Command Lines, Detection and Applicability Rules, Associations, File Inventory, and Software Publishing user data. A component is also known as a Software Resource. Typically this entails the data concerning a specific application or application suite. Common examples include Adobe Reader, Citrix VPN Client, Microsoft Office 2010.

Component Views

To view what components you have, there are two locations. In the Symantec Management Console, browse under Manage > All Resources > and browse in the tree under Default > All Resources > and select Software Component. This list will include all Software Resources that have been created or discovered in the environment. The second location is under Manage > Software > and select the Software Catalog. Additionally there are subsequent views in the tree that limits what types of Software Components you can use.

• Software Catalog - This view includes all Software Resources (much like the Software Components Resource view, or the 1^stoption mentioned), whether they were discovered via Inventory, brought it via the data provider, or created manually.
• Deliverable Software - This view includes any Software Component that has a Package or Command-line defined for it. See this screenshot for an example:

  

• Releases - Deliverable Software that is considered a typical Application release.
• Updates and Service Packs - It is as the name implies.
  NOTE: The types are used for Associations and categorization; there isn’t a functional difference for delivering software whether it defined as a Release or Update, etc.

Elements

Each element of a Software Component is utilized by different functions inside the Symantec Management Platform. The following descriptions provide details and uses of each element. Also included is what intersects and uses each component.

• Company - Company Resources can be managed for Asset or Inventory purposes. Consider this a categorical reporting tool to see what is installed in the environment by Company.
• Software Product - The Software Product takes an important role for License management where multiple versions are involved. For example Adobe Acrobat may require a license count based on multiple versions of Acrobat that may be in your environment.
  • Uses: Tie multiple versions of software into a single Product for reporting purposes.
• Version - Version information is for tracking purposes, and is important when properly tracking the version of an application you have installed on target workstations.
  • Uses: Accurately track what versions of Software you have installed and are delivering to your environment. This also forces all elements in the Resource to be updated upon save.
• Packages - The Package within a Software Resource is a collection of physical files and folders (if you can really call a digital file "physical"). The most basic explanation is a Package is a folder and all files and subfolders/files therein.
  • Uses: Packages are used for delivering files to target PCs. Most Solutions use Packages as part of their agent or plug-in rollouts or the delivery of utilities. This enables a Component or Resource to be "Deliverable".
• Command lines - Consider the Command Line as the action against a package. When the execution occurs, it runs as configured in the selected command-line.
  • Uses: Command Lines are used for the installing, uninstalling, repairing, or executing of applications on target PCs. For self-created command lines, they are used via Quick Delivery Tasks, Package Delivery (legacy) Tasks, and Managed Software Delivery Policies.
• Detection Rules - Detection Rules dictate if the specific software is installed or not. When a Detection Rule is marked FALSE, the remediation execution occurs. When it is marked TRUE, the target system is considered to be in compliance.
  • Uses: Besides pre-canned items such as Patch Management, these Rules are used by Managed Software Delivery Policies and Targeted Inventory Polices. If configured correctly, these rules will let the Policy know if the target computer has the Software Component installed. Also you can associate computers as having the Software Component by creating a Targeted Software Inventory Policy.
• Applicability Rules - Applicability Rules use the same rule types as Detection Rules, except in this case a TRUE statement means the Policy applies. This means the standard Policy will only run on a system that is found as TRUE for applicability. A FALSE reading indicates that this Policy is not applicable and it will not continue.
  • Uses: Barring the built-in items including Patch, these Rules are exclusively used by Managed Software Delivery Policies.
• Associations - Associations allow the linking or associating of Software Components in different ways. The following Uses are described.
  • Conflicts with - Using this Rule you can avoid installing Software that has known compatibility issues with existing Software. This will help Administrators know what Software should not be installed together on a target computer.
  • Contains - To help manage what updates or resources contain multiple items that may already exist as stand-alone, use the Contains Association to track these.
  • Depends on - This Rule can automate the running of Prerequisites for the Software Resource. For example if a particular application requires the JRE (Java Runtime Environment) you can create a Software Resource that deploys JRE. That JRE resource will be referenced as a Depends on association to the primary Software Resource.
  • Software Channel Targets Software Release - I could not find a use-case or documentation on this Association.
  • Supersedes - This is particularly applicable for roll-up hotfixes or updates. You can select all updates that are contained in the rollup by using this Association Type.
  • Updates (Service Packs) - You can add Resources that add a Service Pack to the editing Software Resource. With these associations you can automatically update your install base. The Managed Software Delivery Policies referencing the Resource can have the Service Packs added.
  • Updates (Software Updates) - This is the same type of Rule as Service Packs for individual Updates to the Software Resource.
• File Inventory - This tracks what program files are part of the Software once installed. This data can be manually added. Also, when a Software Discovery runs as part of Inventory Solution Policies, what files are presented and scanned from the Windows API for installed software is added to this tab.
  • Uses: Application Metering uses this to track or block the usage of the listed Program Files when the Software Resource is made part of a Metering Policy.
• Software Publishing - If you wish the Software Resource to be made available via the Software Portal, this tab will do so. For our purposes for this article we will not cover the Software Portal.

Creation/Inventory Methods

There are different methods for bringing Software into the Software Catalog. By default there are hundreds of pre-defined Software provided upon installation of the Symantec Management Platform. Other methods include:

• Inventory Solution - Specifically, Inventory Solution runs a process from the Software Management Framework called Software Discovery.
• Data Provider - Using a 3^rdparty software metadata source, we can import software definitions on a schedule.
• Manual - You can always create a Software Component manually, adding the details as needed. Manual work is always required when moving a Software Resource into the "Deliverable" type.

Inventory Solution

Software Discovery uses a method to fetch data from a Windows API for installed Software. Using the data, the Registry, File System, and MSI cache will be queried to collect full information about all installed software. This is the primary source of accurate data of what is installed in your environment.

To access the Framework task for this, in the Symantec Management Console browse under Settings > All Settings > browse in the left-hand tree under Software > Software Catalog and Library Settings > and select Software Discovery, as shown here:

Note that the Task is disabled by default as Inventory Solution takes responsibility for running this process. Since it is inventory-based, it made logical sense to do this. Now the option to run Software Discovery is found in Inventory Tasks or Policies. This is located in the Symantec Management Console under Manage > Policies > Discovery and Inventory > Inventory > and select an Inventory Policy. The option for Software Discovery is a checkbox labeled: Software - Windows Add/Remove Programs and UNIX/Linux/Mac software packages, as shown here:

The only configuration option for a Software Discovery is whether to run it or not.

How This Works

The following process is taken to capture what software is installed:

1. The SMFAgent initializes and queries a Windows API to get details of what is installed on the system.
   1. The files indicated by the API are scanned, the details captured as File Resources. This is what populates the File Inventory tab on a Software Resource.
   2. The registry is queried for additional data where applicable.
2. The MSI cache is queried on the system as an additional source of installed Software.
3. The details captured are written to the SoftwareCache.xml file located at C:\Program Files\Altiris\Altiris Agent\Agents\SoftwareManagement\Data\.
4. Subsequent passes of Software Discovery will do a delta check of what was already captured to see what is new and what has been removed.
5. The results are then posted to the NS through the Altiris Agent transport in NSE format.
6. At the Notification Server, the hashes generated by each Data Class data set is compared against what is held in the ResourceUpdateSummary. If the hash matches, the data is not inserted into the database as the hash indicates it is already there. For Software Discovery it is not typical to have the hashes match.
7. Data is inserted to the database. Note the following:
   1. File Resources are created for those Files that the NS doesn't already know about.
   2. Software Components are created for those Components unknown to the NS.
   3. The File Resources and Software Components are linked to the computer that sent the Inventory in. It is this link that shows this application as installed on these computers.
   4. For software that has been found as removed by the Software Discovery, the link between that software and the computer will be removed.

Data Provider

I will be careful how I treat this source of data. The Data Provider holds mountains of data on known software applications. When run, the list of Software Resource/Components will multiply. While this can be very useful, in the current implementation we've discovered that the potential for duplicates is increased when used.

How this words (high level):

1. The data provider pulls in a large selection of common known Software into its database per the schedule.
2. That data is then used to see what matches are found with Software already reported through the Software Discovery process.
3. Any matches are imported to provide more data. This often includes different versions of software found in the environment.

NOTE: There is no real configuration of this piece beyond enabling and scheduling it. Before Inventory Solution 7.0 SP2 MR1, this was enabled by default. New installs subsequent to this version will have it disabled while our implementation is reviewed to find a way to better use the data.

If you are having issues with duplicates from the data provider, it is recommended to disable the Software Catalog Data Provider Inventory:

1. In the Symantec Management Console, browse under Settings > All Settings > in the left-hand tree browse under Software > Data Provider > and select Software Catalog Data Provider Inventory.
2. Uncheck the box labeled: Automatically import the software resource data for detected software. The data is imported from the Software Catalog Data Provider into the Software Catalog.
3. Delete the Schedule shown as pending, as shown:

   

4. Click Save changes to complete the modifications.

Manual

Software Components can be manually created. Primarily this is used to create a Deliverable Software Resource. Another reason might be the configuration of Rules to properly detect software that might not otherwise be returned by Software Discovery. The details around creating a Software Resource are captured in the Software Management 7.0 Best Practices both in the Altiris Knowledgebase and on Symantec Connect.

Considerations when creating a Software Resource:

1. If you are creating for the purpose of delivering software, it is best to use the Import Option located at Deliverable Software (Manage > Software > Software Catalog...).
2. The Version is important when handling manually-created Software Components and the subsequent Software Discovery data that will be provided after rollout.
3. Detection Rules can be used in multiple places. As a rule can contain multiple elements, find those items that properly and authoritatively show that the software is successfully installed. This can include registry keys and local existents of file. See the subsequent section Targeted Software Inventory for more information.
4. The File Inventory tab is not used by default for File Inventory data outside of the Software Resource. Inventory Solution conducts an Audit scan that captures all program files by default.

One very important element in handling manually created Resources is to monitor and merge any entries that are duplicated due to differences in how the manually created resource was defined versus what Software Discovery (or the Data Provider) returns. See the subsequent Merging Components section.

Targeted Software Inventory

This Task captures Software Installations not otherwise captured through a Software Discovery. If the Windows API for installed software doesn't catch a specific application, you can configure the Detection Rules of a Software Resource to capture instances of that software out in the environment. Essentially you are creating your own rules to determine if software is installed.

How this works:

1. In a Software Resource (edit mode) click on the Rules tab.
2. Create a new Rule by clicking on the New button, or edit the existing rule choice by clicking on the pencil icon.
3. Create the Expressions that represent the Software. A rule configuration is shown here as an example:

   

4. Once you've saved changes for the Software Resource, browse in the Symantec Management Console under Manage > Policies > Discovery and Inventory > Targeted Software Inventory. You can create a new one by right-clicking on the Targeted Software Inventory folder and choosing New > Targeted Software Inventory.
5. NOTE: You can add multiple resources to a Policy, so essentially you can have one policy that runs detection rules for all Software that require it.
6. Provide a name for the policy.
7. Click the Select Software button.
8. Choose one or more Software Resource you have configured Detection Rules for.
9. Use the Scheduling and Apply to sections to set when the inventory occurs. By default it will point to all computers that have the Inventory Plug-in installed.

Managing Software Components

While it would be nice to have all Software Components automatically merge and purge themselves, this process, by necessity, must be done manually. It would be difficult to make programmatic decisions on what to merge and what not to merge. The good news is that once two resources have been merged, they will stay merged and the two different data sources that reported them will only update the new merged record.

Merging Components

The process to merge components is very easy. The difficult part, or the part that should be approached with caution, is deciding what resources to merge and when to merge them.
NOTE: You must have Asset Management installed to merge Software Resources

The process to merge is as follows:

1. In the Symantec Management Console, browse under Managed > Software > browse in the tree under Software Catalog > and highlight the Installed Software node.
2. Use the Search Filter to narrow down your results. The following screenshot demonstrates how use this:

   

3. Using Ctrl for multi-select, select two or more resources. In the above example I have chosen Microsoft .NET Framework 3.5. SP1 that is duplicated, as shown above.
4. Right-click with both resources and select Merged Resources. (If this option is not present, Asset Management Solution is not installed)
5. In the following dialog, choose which resource to make the primary. The information and details in the chosen resource will remain, while the secondary resource not checked will become an association only to the primary resource. This means that any instance of the secondary resource provided by Inventory or the Data Provider will automatically be associated with the primary resource. See this screenshot for an example:

   

6. Click Save changes to complete the Merge.
7. You'll receive a dialog pop-up indicating the Resources successfully merged.
8. The Merge window will remain. Simply close it to return to the main console.
   NOTE: You'll need to refresh the results to show the new list with the two now appearing as one entry.

Note in the above example in the first screenshot that there is another resource with the same name, but without a version. This resource can also be merged, but be sure to select the resource with the version intact as that is one of the key fields for a Software Resource.

Once you've merged two records, any instances of either record will update the primary resource chosen during the merge process. This means it is a one-time merge. If you find other duplicates appearing, they do not match either resource that was previously merged. Through experience I found that some software were more problematic than others, and required multiple merges before duplicates stopped appearing.

Locating Legacy Components

When all computers have had their association to a specific Software Component removed (meaning Inventory has found that the Software Product has been removed from the system and reported such to the CMDB) the Software Component will still be available. This is not, in and of itself, a problem. Consider it metadata for that specific Software that doesn't have any associations to actual installs out in the environment.

Most of the reports available for Installed Software will not return results for Software that is no longer associated to a computer. As Computer is one of the parameters required for the reports, software that is no longer installed in the environment will not show up.

If you have a Software Component you have uninstalled, upgraded, or suspect is no longer out in the environment, you can use the following method to check for where it is installed.

1. In the Symantec Management Console, browse under Managed > Software > browse in the tree under Software Catalog > and highlight the Installed Software node.
2. Locate the Software in question using the Search field.
3. Right-click on the desired component and choose Actions > Installed Software Report.
4. The resulting window will provide a list of computers that have the designated software installed.

Factors when analyzing the results from an Installed Software Report, consider the following:

• If no results are returned, no computers report having the software installed in the environment.
• Machines that may have been taken off the network may still have an association to the designated Software Component.
• If you wish to delete a Software Component, the links to machines that have reported it will be removed. This means even if the target system still has the software installed, it will no longer report that software using the Installed Software details.

Software Product Management

For Asset Management and Licensing tracking and reclamation purposes, Software Components should be grouped or categorized by Software Product. This allows a full count of the install base, regardless of the sub-versions installed. For example if you want all versions of Microsoft Office 2007 Professional to add to the count of the Product "Microsoft Office 2007 Professional", you’ll need to set the Product on each Software Resource.

Use this process to associate Software Resource to a Product.

1. In the Symantec Management Console, browse under Managed > Software > browse in the tree under Software Catalog > and highlight the Installed Software node.
2. Locate the Software desired using the Search field. In this example I used office enterprise to find what office I have listed as installed:

   

3. Click the pencil edit icon along the task bar.
4. Under the Properties tab, use the multi-function search field next to Software Product to locate the desired product if not already associated.
5. If it exists, select it and click Save changes and you are done. If not, continue.
6. Click the New link next to the Software Product section.
7. Provide an appropriate Name and Description.
8. Select the Company and Category. See this screenshot for an example:

   

9. Click OK to save and associate the New Product.
10. Click Save changes to complete the process.
11. Repeat steps 1-5 for any other entries that require association to this Software Resource.

Another example of the above situation is Adobe Acrobat, where sub versions may show up as different resources. In this case an administrator may want to track each version, but be able to report on how many installs of the major version is available.

Database Schema

The schema for handling Software is complex. Many Resource types are involved in the schema, including File, Computer, Package, and Software Component types. The following diagram has been simplified somewhat, not showing all auxiliary tables or associations:

SOFTWARE RESOURCE MODEL

LEGEND:

• Dark Blue Box: Primary Resource Types
• Blue Box: Resource Types
• Orange box: Inventory or extended data classes
• Arrows: Association link between resources or inventory data classes

Table Translation

As a general rule, the tables are formatted as follows. Primary Resource and Resource tables use RM_Resource<Name>, for example RM_ResourceSoftware_Component, or RM_ResourceSoftware_Type. For Inventory or extended data classes, the format is similar, using Inv_<Name>, for example Inv_InstalledSoftware, or Inv_File_Details. See the following list for specifics:

Primary Resource Types

• Software Component: RM_ResourceSoftware_Component
• File: RM_ResourceFile
• Computer: RM_ResourceComputer
• Package: RM_ResourcePackage

Resource Types

• Software Product: RM_ResourceSoftware_Product
• Company: RM_ResourceCompany
• Software Type: RM_ResourceSoftware_Type
• Software Release: RM_ResourceSoftware_Release
• Service Pack: RM_ResourceService_Pack
• Software Update: RM_Resource_Software_Update
• Software Program: RM_ResourceSoftware_Command_Line
• Software Package: RM_ResourceSoftware_Package
• Software Installation File: MULTIPLE, format: RM_Resource<TYPE>_Software_Installation_File
• Inventory Rule: RM_ResourceInventory_Rule

Inventory Data Classes

• Installed Software: Inv_InstalledSoftware
• Add Remove Programs: Inv_AddRemoveProgram
• Installed File Details: Inv_Installed_File_Details
• Windows File: Inv_Windows_File
• File Details: Inv_File_Details

Data Size

How much Software data is system consumes in the Symantec database is contingent upon a large number of factors. The two main points of data are Installed Software (typically thought of those applications in Programs and Features/Add Remove Programs), and the number of EXE files discovered on the system. For Installed Software the data is uniform based on what is installed. However for the file scan the configuration can have a significant impact on the size of the inventory data. Factors include:

1. Amount of Files typically residing on Workstations
2. Mapped Drives to file stores (it is recommended to exclude file shares from the Inventory configuration)
3. External drives
4. Configured extensions beyond EXE to capture
5. Servers typically have more program files than workstations

For a reference, here are the results from a random sampling:
Installed Software

• Barebones Windows XP installation: 349kb
• Typical Windows XP Installation: 727kb
• Typical Windows 2003 application server Installation: 1667kb
• Hyper-V host Windows 2008 installation: 34kb

File Details:

• Barebones Windows XP installation: 440kb
• Typical Windows XP Installation: 503kb
• Typical Windows 2003 application server Installation: 656kb
• Hyper-V host Windows 2008 installation: 484kb

...To a grand total of Software Inventory data:

• Barebones Windows XP installation: 789kb
• Typical Windows XP Installation: 1230kb
• Typical Windows 2003 application server Installation: 2323kb
• Hyper-V host Windows 2008 installation: 518kb

NOTE: These are samples only and may not be typical of what is in your specific environment.

Conclusion

Managing Software Resources is essential to understand what applications are installed in your environment, for both license compliance and for tracking blacklisted or other software. I hope this article provides useful information for making the process successful and enabling users to get accurate information concerning what is installed in the environment.