Last month we began a three-part series on Getting Started with Software License Management (SWLM) where we discussed contracts and software licenses. As I mentioned in that blog, SWLM is really about knowing what you’ve installed, what you’ve paid for, and eliminating any differences between the two. This month I’d like to focus on figuring out what you’ve installed. For Remedy Asset Management, this information is established in Software Configuration Items (CIs).
What is a Software CI?
If you’re at all familiar with Remedy Asset Management or the Configuration Management Database (CMDB), you know that the assets in your environment are stored in their corresponding classes. For example, a laptop asset would be stored in the Computer System class, represented in Asset Management by the AST:ComputerSystem form whereas a piece of equipment would be stored in the Equipment class, represented by the AST:Equipment form. In previous versions, SWLM only considered the “Product” class when discovering Software CIs and calculating compliancy. Starting in version 8.0, SWLM now considers six different classes:
|Operating System||AST:OperatingSystem||System Component||Software that controls the operation of a computer and directs the processing of programs|
|Package||AST:Package||System Component||A computer program or a collection of related software, for example, Microsoft Works|
|Patch||AST:Patch||System Component||Also called a service patch, a fix to a program defect|
|Product||AST:Product||System Component||Something that is produced, such as a software program or a hardware component. For example, Microsoft Word would be categorized under Product.|
|Software Server||AST:SoftwareServer||System||A server on which your software applications reside|
|System Software||AST:SystemSoftware||System Component||Refers to the operating system and all utility programs that manage computer resources at a low level|
So as an example, if you have 20 installed instances of Microsoft Word in your environment, you would want to create 20 separate Product CIs in order to represent them in Asset Management. If you license and track your Operating Systems you would want to create an Operating System CI for each instance as well.
The key is that each install must be its own CI. For example, you cannot represent multiple Microsoft Word installations by creating one Word Product CI and relating that CI to every Computer System CI where Word is installed. This simply will not work. You will need a Product CI for each installed instance. Luckily, identifying and creating the CIs in the CMDB is the responsibility of a good discovery product. This is one area where automated discovery is a must – your results are only as good as your data is current and you would not want to rely on a manual process of collecting the data. One such discovery tool is BMC Atrium Discovery and Dependency Mapping, which we will discuss later in the blog. As far as how to populate the Software CI, the rule of thumb is if your discovery tool populates it, then that is the data you should go with.
What else will I need in the CMDB?
In order for SWLM to accurately calculate compliancy, you will need more than just Software CIs in your CMDB. What other CIs you need really depends on the “License Type” of your License Certificate. Each License Type requires a “Component” or a “Hosted System Component” relationship between the Software CI and a Computer System CI (“Hosted System Component” is typically populated by your discovery tool). The “Per Instance” license type will also consider Mainframe and Printer CIs in addition to Computer System.
The “Per Copy” license type requires a “Used by” relationship between a person and the Computer System the Software CI is installed on. This is a relationship that is built through Asset Management by accessing the “People” tab of the desired Computer System, clicking “Add”, and following the corresponding prompts. When this relationship is created a “Dependency” relationship will automatically be created in the CMDB. The “Per Core” and “Per CPU” license types require a “Component” or a “Hosted System Component” relationship between a Processor CI and the Computer System CI the Software CI is related to. To help clear some of these requirements up, please see the table below:
|License Type||Software->Computer System?||Person->Computer System?||Processor->Computer System?|
|AR System fixed and floating||Yes|
|Per Copy Per Device||Yes|
|Per Instance||Yes (or Mainframe or Printer)|
|Per Core Constant Based||Yes||Yes|
|Per Core Multiplier Based||Yes||Yes|
|Per Core Sum Based||Yes||Yes|
|Per CPU Constant Based||Yes||Yes|
|Per CPU Multiplier Based||Yes||Yes|
|Per CPU Sum Based||Yes||Yes|
Software CIs and Product Catalog
As with creating License Contracts, you’ll need to configure your Product Catalog appropriately. The most important aspect of this, particularly in relationship to SWLM, is creating your Model/Version and Patch entries that accompany your Product Catalog entry for Software CIs. The goal is to define which product versions you have licenses for, ensure they are defined in the product catalog, and that Atrium Normalization jobs normalize the discovered data against the versions in the product catalog which you track for SWLM. There’s already some great documentation that goes into further detail on this topic that I highly recommend you read before implementing your Product Catalog. They can be found both here and here.
There are two things I would specifically like to call out: First, you must have the “Requires Contract” field set to “Yes” when configuring the Model/Version. The compliancy jobs will only consider Product Catalog entries with this setting. Second, in addition to “Requires Contract” you should set the “Market Version” field as well. This field allows you to bind several different minor versions of software (i.e. 7.0, 7.03) under one major version (i.e 7). SWLM jobs use Market Version field, not the Version field representing minor versions, when calculating software license compliancy.
Once you’ve created the necessary Product Catalog entries, it is vital to actually use these categories, particularly Product Name and Model/Version, when creating your Software CIs. Leaving these fields blank will leave them virtually invisible to the SWLM jobs and those CIs will not be counted toward compliancy. Again, using an automated discovery solution that reliably discovers these values is key to getting value out of SWLM.
How do I create my CIs?
Although building your CIs and the appropriate relationships through the Asset Management UI is certainly possible, it is not practical if you have dozens, hundreds, or even thousands (and beyond!) of CIs to load into your environment. Nor is it a good way to ensure you have the most up-to-date information stored about your Software in the CMDB. There are a number of methods to loading CIs into your environment in bulk. Ideally you would have a discovery tool that automatically populates your CMDB with your computer systems, their software, and components. BMC Atrium Discovery and Dependency Mapping is one such tool and is specifically designed to work with BMC Atrium CMDB. More documentation can be found here, with documentation specifically on syncing with the CMDB here.
If you are missing a discovery tool in your environment, you will be at a severe disadvantage for effectively capturing an accurate picture of the installed software in your environment. If you need to make a “one-time” load, however you can load CIs with the Data Management Tool (DMT). As with many of these topics there is already great documentation covering the use of the DMT, which can be accessed here. One thing I would like to point out however is to load CIs you will want to use the Transaction_CI.xlsx spreadsheet. There are tabs available for loading Computer System (AST_ComputerSystem), Product (AST_Product), Operating System (AST_OperatingSystem), and Processor (AST_Processor) CIs. To load relationships you will want to use the Transactional_Asset.xlsx spreadsheet.
Additionally you can use Atrium Integrator, either in conjunction with your Discovery tool, with DMT or on its own, to load CIs into your CMDB. Integrator allows you to pull data from many different data sources, transform it to your requirements, and push the into whichever form or class you desire. For instance if your discovery tool does not have an inherent ability to populate the CMDB on its own, you could build a job in Integrator that will pull that data in and then configure it in the DMT to run on a regular schedule. More information regarding Integrator can be found here.
Hopefully this information will get you thinking about how you will need to represent your Software in Asset Management and the CMDB and to get yourself prepared to identify where you have too many installations or too many certificates. The next step will be to run SWLM jobs to identify this compliancy data, which will be next month’s topic of discussion. As always, if you’ve come across any additional tips or stories of your own setting up contracts and certificates, I encourage you to leave a note in the comments section below. Have a great November and Happy Thanksgiving!