There have been several recent discussions regarding how to turn auditing on for Asset forms, and it's a question we hear in Customer Support, so I thought a good topic for this month's blog post would be auditing assets.
Simply put, auditing is a function of the underlying AR System that allows you to track changes to records in a form: who made the changes, when they made them, and what did they change. Each change is stored as a record in an ARS form you designate. There are two types of auditing available: "Log" and "Copy." You can read more about these types here; but in a nutshell "log" will create a record only noting those items that have changed while "copy" creates a snapshot of the modified record. For this discussion, we will focus on log-style auditing.
You might notice that many OOTB forms in Remedy ITSM (Help Desk and Infrastructure Change are two good examples) already have auditing enabled. You might also notice that this is not the case for the Asset forms. On install, these forms have auditing disabled. So how do you turn them on?
In versions 7.6.04 and prior you would enable auditing for assets using the CMDB Class Manager. With 8.0 and beyond, you’ll need to enable auditing on the AST:Attributes form as well if you want to audit fields which are considered "lifecycle" fields (AssetLifecycleStatus, financial data, etc.). Starting with 8.0, each Asset form is actually a join of two forms; AST:Attributes, which holds information specific to the lifecycle of the asset, and its CMDB Class form, which holds the asset’s configuration information. For example, AST:ComputerSystem is a join of AST:Attributes and BMC.CORE:BMC_ComputerSystem. To enable auditing for your assets, you’ll need to enable auditing in both places.
Enabling CMDB Auditing
There’s already some great documentation on this topic that goes into more detail than what I’m going to touch on here, but below are the steps necessary for enabling auditing in the CMDB:
- Go to the Class Manager in your Atrium Console
- Select a class for editing. Please note that enabling auditing for any field must be completed at the top of the class hierarchy. For instance, if you are trying to enable auditing for the “Name” field, you must edit BMC_BaseElement. If you are targeting “TotalPhysicalMemory” however, you would need to make that change in the BMC_ComputerSystem class.
- In the “General” tab, under “Auditing,” select “Log.” You’ll notice that the Audit Log Form automatically populates with CMDB:DefaultAuditLog.
- In the "Attributes" tab, expand the class folder
- Select an attribute and click "Edit"
- In the "General" tab, under "Audit Option" select "Audit"
- Click OK
- Repeat steps 5-7 for each attribute you wish to audit
- Click OK on the CI Class - Edit form and then confirm your changes
Enabling Lifecycle Auditing
Now lets enable auditing for the AST:Attributes form:
- Open BMC Remedy Developer Studio in “Best Practices” mode
- Search for “AST:Attributes” listed in the Forms objects
- Create an Overlay of this form
- In the Definitions tab, under Other Definitions, set the Overlay Type to “Overwrite”
- Under Audit, set the Audit State to Enabled
- Save your changes
This will enable auditing for the form, but you must also enable auditing for each field you wish to audit. To do this:
- Go to the Default Administration View tab
- Double-click the field of your choice. This will bring up the field’s properties
- At the top of the Properties box, set the Overlay Type to “Overwrite”
- In Attributes, set Audit Option to “Audit”
- Save your changes
You can repeat these steps for each field you wish to audit, saving step 5 for last, for when all your changes have been made.
Where Does Auditing Store Data?
As I mentioned earlier, auditing stores change data as records in an ARS form. The default form for AST:Attributes is AST:AuditLogAttributes, whereas the default form for CMDB classes is CMDB:DefaultAuditLog. Unless you have a very compelling reason to do so, I would highly recommend leaving the default settings as these forms are referenced by OOTB workflow.
Both of these forms act like regular ARS forms in that you can access them and pull information out of them for reporting.
How Do Users Access this Data?
Most users will not want to access these forms directly as they can be cumbersome to access through the object list and can be difficult to search without advanced knowledge of the Remedy system. Most users instead will want to use the options provided on the Asset form. These are listed under the Functions menu on the left side of the form, listed as “Lifecycle Audits” and “CMDB Audits”
The “Lifecycle Audits” will display changes made to attributes in the AST:Attributes form while “CMDB Audits” will display changes made to CMDB Attributes.
A conservative approach would be the best policy when considering which attributes require auditing, as auditing can generate a large number of records very quickly the more fields you enable. For example, if an asset has 20 updates over its lifetime and each asset has three datasets, each asset could easily generate 60 audit records in its life. This means for every 1,000 assets in your CMDB you would have over 60,000 audit records between the two audit forms. The fewer fields you enable, the more manageable this number will be.
In addition to being cautious about which fields you select, you can also add restrictions in the Qualification field for both AST:Attributes and CMDB auditing. One common restriction would be limiting auditing to only one dataset, such as BMC.ASSET.
Also note that deleting assets from your system does not delete its audit records automatically. You may wish to put an archiving plan in place for these records that would also match your business requirements.
I hope this blog will be a good reference for those needing to track changes to their assets in a systematic way. Have you tried this? Do you have any other tips or tricks on auditing that would be helpful to other users? I challenge you to add a comment below!
Have a great September everyone!