Video Screencast Help

Software Component Management Best Practices – SWM 7.0

Created: 09 Sep 2010 • Updated: 04 Nov 2010 | 15 comments
Language Translations
Joel Smith's picture
+11 11 Votes
Login to vote

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
Creation/Inventory Methods
     Inventory Solution
     Data Provider
     Targeted Software Inventory
Managing Software Components
     Merging Components
     Locating Legacy Components
Software Product Management
Database Schema
     Table Translation
     Data Size

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


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


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:



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


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.

Comments 15 CommentsJump to latest comment

hmassie's picture


You've posted a number of documents on best practices for Software Management and they are v helpful - is there somewhere or a single doc that brings all these together though?


Login to vote
cnpalmer75's picture

Excellent article, I have the stand-alone word doc before it was posted here/made public.

What are the best practices for updating a catalog entry when an update/patch is relased?

For example, Adobe releases Adobe Reader 9. So a catalog entry is built using this information and the software library/package source uses version 9 as its base.

Now 2 patches are relased, which brings the version from 9 to...

Patch 1 = version 9.2.0, Patch 2 = 9.3.0

What is the best practice for entering these into the catalog? Should they be applied to the package source aka slipstreamed in and have the original package version updated or should these be new netries in the catalog and dependencies created for the base package?

Login to vote
Pascal KOTTE's picture

Hello, the best practice will be to use the "Patch Management Solution" from Altiris for this.

But for upgrading the Reader 9 to the version 10, yes, I would like also sharing your point of view/usage ;-)

~Pascal @ Do you speak French? Et utilisez Altiris: venez nous rejoindre sur le GUASF

Login to vote
chris.vanderlinden's picture


If I have a software library install for Microsoft Office 2007 and I also have a update (service pack) setup in the library as well for MS office 2007, what is the best method to make sure that MS Office 2007, when installed gets the update automatically?

(ignoring the fact that I can put it in the updates folder in the actual office 2007 install files).

IE, if I do a quick delivery of the MS office 2007 package, will it also automatically install anything listed as updates for it (in the software library associations metadata).


Login to vote
Pascal KOTTE's picture

Hi, Just think "Patch Solution" if needing to update Any Microsoft or Adobe.

The Editor list of "patch" solution is really tiny: 4 editor (adding suze & redhat)... It will be a pitty not using the 2 above, to avoid any package/update/policy building. Just "stage" & "create a patch policy" !

~Pascal @ Do you speak French? Et utilisez Altiris: venez nous rejoindre sur le GUASF

Login to vote
chris.vanderlinden's picture

Patch solution doesn't seem to update the MS Office products.  (Ditto with the Viewers).

My question on that is in another thread though.

Login to vote
Wallo's picture

More info like this please!!!!

Login to vote
hmassie's picture

The question of how one is supposed to use the data provider and catalogue together to deliver packages and subsequent patches could do with some more clarification.

Taking adobe 9 as an example. Is one supposed to import from the data provider the adobe 9 main record and subsequent patch package records (which one would assume would bring in the detection rules and a number of obvious associations and mean you don't have to create these) and then associate the appropriate package files to each to deliver them? Or is one supposed to create new entries for each, and then when they get recognised via an appropriate discovery mechanism merge the resultant records together, assuming you can actually find and notice two records that are supposed to be one?

And if one has decided to use the Adobe patch management capability what happens then? Do the records from the data provider, discovery and patch management all tie up?

finally you mention using a windows API to fetch installed software - what is this API and what does it actually return? Is it just what's in add/remove programs or more?

Login to vote
Pascal KOTTE's picture

I don't think any problem conflicting if a "soft managed policy" vs a "patch policy"

Should just avoid a "checking schedule" in conflicting "soft manage" + "patch" in the schedule time, but if this was the case, the 2 will run one after the other... I suggest patch 1st (12h15 daily no reboot), soft manage (12h30 daily)...

Of course the 2nd running will probably deliver a MSI error 16xx or 30xx (dont' remember which one), meaning "already installed". But if the "soft manage" correctly "detect rule" in place, and running in 2nd position, should just report "compliant" status" and stop !

If workstations WOL compliants, can plan WOL at night for patch & shutdown (I suggest a task with a scripted Patch agent force running).

~Pascal @ Do you speak French? Et utilisez Altiris: venez nous rejoindre sur le GUASF

Login to vote
andykn101's picture

I too was confused by "Software Channel Targets Software Release". I think it's something to do with Linux. From the Altiris™ Patch Management Solution for Linux from Symantec User Guide:

"Select software channels for import: Lets you choose the operating systems for which
you want to import updates catalog..."

Authorised Symantec Consultant (ASC) with Endpoint Management Limited, an Authorised Symantec Delivery Provider based in the UK.

Connect Etiquette: Please "Mark as Solution" posts that fix your problem.

Login to vote
Pascal KOTTE's picture

That is a very nice sharing, I will add link from my own post regarding an overview of the new

"Software managed" philosophy

~Pascal @ Do you speak French? Et utilisez Altiris: venez nous rejoindre sur le GUASF

Login to vote
reto.zuerrer's picture

In the SoftwareCache.xml on the Client you can find different "Source's" how the Software was detected on the Client...

a few codes:

2 - Inventory Rule / Detection Rule
8 - AddRemove
9 - MSI Cache
10 - Combination of AddRemove and MSI Cache
64 - Server (Based on File Inventory, Data Provider)

Reto Zürrer | FYRE Consulting |

Login to vote
Rhys Paterson's picture

Sometimes I need to quickly go to the source of our imported software packages.

As you probably know, these are stored in a folder with a 32 character GUID for its name.

For me, the quickest way to find out what folder a resource lives in is to run this query:

 USE Symantec_CMDB

SELECT  rsp.[Guid],


rsp.[CreatedBy] AS 'Created By',

rsp.[CreatedDate] AS 'Created Date',

rsp.[ModifiedBy] AS 'Modified By',

rsp.[ModifiedDate] AS 'Modified Date'

FROM RM_ResourceSoftware_Package rsp

WHERE rsp.[Name] = 'Microsoft Visual C++ 2005 Redistributable'

-- Or, use a GUID to reverse it.

-- WHERE rsp.[Guid] = '0ebe06a2-f517-421c-8732-2898d89e62ab'

ORDER BY rsp.[Name] 

If anyone can figure out how to add the 'default' installation command it would be appreciated. I've looked at the ..

RM_Resource[XXX]_Software_Installation_File; and

.. tables, however they only give the default filename and not the full command.

Anywho, hope someone finds it useful.



Login to vote
ianatkin's picture

A nice write-up of much needed info as always Joel.

Ian Atkin, IT Services, Oxford University, UK

Connect Etiquette: "Mark as Solution" those posts which assist you most in resolving your problem, and give a thumbs up to useful articles and downloads

Login to vote
noodleNT's picture

How do I joing RM_ResourceSoftware_Type? I want to show the type category for software in a report.

Login to vote