Client Management Suite

 View Only

Software Component Management Best Practices – 7.5, 7.6 

Jun 10, 2015 03:48 PM

Introduction

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

To start, I will cover Software components as it is important to understand how components work before I cover Software Products. Software Products take component management to the next level, making it much easier to manage the multitude of components that will be created within the platform.

 

Software Components are resources 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, Java Plug-in, Microsoft Office, or any other named and versioned application.

 

Software Component Views

To view all components with no filtering attached, you must look outside the Enhanced Console Views. There are two locations. The first is found by looking 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 Settings > Console > Views > browse under 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 1st option mentioned), whether they were discovered via Inventory, created off of deployed software, or created manually. The following screenshot shows this view. Note that if you click the Plus you will get the other views covered in the subsequent bullet points.
    p1.png
  • Deliverable Software - This view includes any Software Component that has a Package or Command-line defined for it.
  • 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.

 

The last view is contained within the Enhanced Console Views. This section is accessed by either using the Software blade link, or by browsing under Managed > Software. In 7.5 this section is different than in 7.6. In 7.6 the view has been improved into a tree format that allows better customization and provides more views that will show you most software resources. In 7.5 this section was heavily filtered so at times you had to use the previously covered views in order to find certain software resources.

 

Here is the side-by-side view of the 7.5 and 7.6 versions:

p2.png

Note that in 7.6 you have an All Software Components View.

 

Component 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 are one of 3 primary identifiers for Software Components, and are used as filter criteria for Software Products. This can also be used for reporting purposes. If you are creating your own when creating a resource, make sure it is accurate. It is recommended to use the lowest common denominator. For example: Microsoft, instead of Microsoft Co., Microsoft Corp., or Microsoft Corporation. This will simplify reporting and filtering of Company Resources.
  • Version - Version information is the second of 3 primary identifiers for Software Components, and is used as filter criteria for Software Products. This can also be used for reporting purposes. For Software Components, each version should be exact to the version that it represents. More major versions will tie in minor versions using Software Products.
    • 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. In these versions you can select an individual file to be the package instead of a folder.
    • 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, or if Metering is enabled inside of a Software Product.
  • 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 3rd party software metadata source, we can import software definitions on a schedule.
  • Targeted Software Inventory - This uses Detection checks to link software to computers that have it out in the environment.
  • 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 several methods to fetch data from a Windows API for installed Software, or from the MSI Cache, or from the uninstall registry key. 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:

p3.png

Note that the Task is disabled by default as Inventory Solution takes responsibility for running this process. This is the recommended way to do it. Since it is inventory-based, it made logical. This recommended 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:

p4.png

 

The only configuration option for a Software Discovery is whether to run it or not. Delta Inventory will change if changes or full Software Inventory is sent.

 

How This Works

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

  1. The SMFAgent initializes and queries the Windows Add Remove Programs (Programs and Features) API, which looks in the registry for details (Uninstall key).
  2. The MSI cache is queried on the system as an additional source of installed Software. During this process the MSI cache provides file details for those files associated with the 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 are compared against what is held in the ResourceUpdateSummary data class. 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.
      1. Inv_InstalledSoftware - Computer to Software Component link
      2. Inv_Installed_File_Details - Computer to File Resource link
    4. For software that has been found as removed by the Software Discovery, the link between that software and the computer will be removed (rows removed from the above mentioned tables).

 

Data Provider

Do not use.

There is a built-in data provider that is turned off by default. It is not recommended to turn this one on. A third-party data provider can be used if it is coded for use within The SMP. This is not a common scenario. For reference, here are some details on how the Provider works:

 

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.

 

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:
    p5.jpg
  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.5 Best Practices both in the Symantec 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. The version must match the version being rolled out.
  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.

 

Note that if you create software manually you may have duplicates due to differences in how the manually created resource was defined versus what Software Discovery returns. Merging can take place, or you can reply on Products to handle any duplicates.

 

Targeted Software Inventory

This Policy captures Software Installations not otherwise captured through a Software Discovery. If the Windows API or MSI cache 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:
    p6.jpg
  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

Merging Software Components used to be a way to manage duplicate or close duplicate Software Components. As of 7.1 when Software Products was introduced, this is no longer a necessity. Merging components is no longer an option, so Products should be used to handle any duplicates or close duplicates.

 

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 > All Software > and select All Software Components.
  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. The Software Component will be created again the next time a computer reports that software, probably via a full inventory.

 

Software Product Management

The real point of management for Software components, as eluded to earlier, is the Software Product. The emphasis on Software Components in 7.0 created some logistical or management nightmares when it came to tracking what software was out in the environment. By taking a step back to the Product level, most of these issues have been resolved. Software Components, whether captured during Inventory or created manually by an administrator, will now by manually or dynamically assigned to a Product. This removes any need to reconcile duplicate resources as the Product rules will automatically assign them to the correct Product.

 

Reviewing known Products

You can view Products under the Resources screens. The following provides the full steps of how to review Software Products:

 

  1. To view what Products are available, in the Symantec Management Console browse under Manage > All Resources > and select the "Default" node. The following steps will add the category if it is not already available in the tree list.
  2. In the right pane click the Filter... button.
  3. In the list, find the entry for Software Product and ensure it is checked, as shown in this screenshot:

p7.png

  1. Click OK to add the category.
  2. In the resulting left-hand tree, browse under Default > All Resources > and select Software Product.
  3. You can now search through what Software Products are available.

 

Note that you cannot edit Products from this location. You can open Resource Manager, which will give you additional information than what is displayed in the grid. Products can be created and managed through Asset Management, or through the Software Catalog. Since not everyone will necessarily have Asset, I will focus on the Software Catalog.

 

To access the Software Catalog, in the Symantec Management Console browse under Manage > and select the Software Catalog. This will load the Catalog interface as a pop up window. Note that all active Products will be shown in the upper right pane, as shown in this screenshot:

p8.png

From here you can assign, create, or edit Software Products using a simple UI provided by the Software Management Framework. However in 7.1 SP1 this field has been removed, which pushes you to use the Silverlight Catalog area for assigning, editing, and creating Software Products. This ensures the correct method and details are used/provided.

 

First, you can search for existing Software Products using the search field.

 

You will notice that not all Software Products are shown in this list. Only manageable Software Products will show. For a Product to be managed it needs to be associated with a Software Component.

 

Creating Software Products \ Identify Inventory

The Identify Inventory section provides you the filtering and parameters of what software will be included in the product. Each field will limit what is shown, so you must work through the values reported by inventory to find the optimized parameters. For example by putting 10.5, you will not include versions 10.4 or 10.6, only 10.5. If you want all 10 versions to be in the filter, only put version 10 in. The same goes for the Name and Company, so as you go through the steps below, be aware of the limiting function of any values put into the fields.

To create a Software Product, follow these steps. These steps can also be observed when editing a Software Product.

  1. In the Symantec Management Console browse under Manage > and select Software Catalog.
  2. When the Manage Software Catalog window appears, click on the Add Product button.
  3. The top section of the dialog is for labeling and identification purposes. It will not be used when calculating or auto-assigning Software Components to the Product. Provide your Product's details, as shown for an example in this screenshot:

p9.png

  1. Provide one or more values in the provided three fields. This will automatically search for Software Components that match the criteria, as shown in this example:

p10.png

  1. Note that it found one match based off the criteria I provided.
  2. Check the box "Include components associated with other products" to ensure you are not missing components based on previous associations (whether made manually or automatically).
  3. You should fine-tune the values so it includes, and excludes, the software resources you want. Review these examples:
    1. In the above example, if I only wanted the ActiveX components and not the actual flash player, I could change the Software name to: Adobe Flash Player 10 ActiveX.
    2. If I only wanted the 10.2 versions of the ActiveX to be associated here, I would change the Version value to 10.2, thus excluding any other 10.x versions.
    3. If Adobe had a release of this software that had a misspelling in the Company name (i.e. Addobe) I could remove the Company designation altogether, if I trust the other two criteria/values.
  4. Click OK to make the change.
  5. Note that the associations will be made immediately for the software that shows up in the lower list. When new software comes in that matches the criteria, the association is made during the following Scheduled Task:
    1. NS.Nightly schedule to associate Software components to software product...
  6. Done!

 

Additional information on using the Identify Inventory filter fields:

Quotation marks limit your search to an exact match.

  • "Adobe Acrobat" =  EXACTMATCHAdobe Acrobat.

 

Omitting quotation marks allows for matching search text anywhere in a string.

  • Adobe Acrobat = LIKE Adobe Acrobat anywhere in the name.

 

You can use the following search operators to express various arguments:

 

OR

Use the Pipe ( | ) sign

This operator does not require leading spaces.

Adobe|Microsoft= software manufacturer LIKE Adobe ORLIKE Microsoft


AND

 Use the Plus ( + ) sign

This operator requires a leading space.

Adobe+Microsoft= software manufacturer LIKE Adobe AND Microsoft


NOT

Use the Minus ( - ) sign

This operator requires a leading space.

-Adobe -Microsoft = software manufacturer NOT LIKE Adobe and NOT LIKE Microsoft

 

Once you have made the associations you are done as far as assigning Products go.

 

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

p11.png

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.

Statistics
0 Favorited
6 Views
1 Files
0 Shares
5 Downloads
Attachment(s)
docx file
Software Component Management 7.5-7.6 Best Practices.docx   1.11 MB   1 version
Uploaded - Feb 25, 2020

Tags and Keywords

Comments

Jul 20, 2015 06:53 AM

At last documentation that describes how the software works under the bonnet, the architecture and why functions exist in the way they do. 

Over the past few years there's been quite a bit of what I call 'disney documentation' - i.e. documents that go through, using simplified examples, you do this, then press this and then magic happens, and little documentation like this.

Unfortunately the real world is somewhat more complex and magic doesn't happen, so we've often been left wondering quite what to do when confronted with it!  This will be a great help when faced with needing to develop software management processes that work for all the many different real world situations. 

So many thanks for this!

P.S. are there any plans for for multiple inventory rules for products?

 

Related Entries and Links

No Related Resource entered.