This is just a partial idea I hope someone can build on to;
You could turn on auditing through object designer for the fields you want to track so that any change made to the fields creates and audit entry in the tps_audit_trail_value log.
Once you have the system doing audits you would use your reporting tool to extract the data out of the tps_audit_trail_value table. As I understand the Web client can't view full audit history, if using Console though you should be able to see details without the report below.
As an example here is our SQL query we are using to get the audit info on Incidents for the response level field which we have auditing turned on. In Web Access you can see who made a change and the date, but the values are not visible so we had to develope an external report, then create an action which open the report for the user to see the details.
The problem we have is the tps_original_value and tps_value are stored in GUID format "<Ref Name="Lifecycle.ResponseLevel"><Att Name="Guid"><Value>337047e0-dbab-454e-9a58-655c744c92d2</Value></Att></Ref>" since this is a drop down list in LANDESK. So we will have to add case statements to convert each GUID to it's named value in our query below.
I've not had enough experience with LANDESK to know how the IP address would behave, if the source is a drop down field I would expect the same behavior but if it's a character field maybe it just stores the values in the tps_original_value and tps_value fields so you won't have to parse anything out of a string or use a case statement to convert it.
tps_title AS field_audited,
LEFT OUTER JOIN tps_audit_trail_value ON tps_audit_trail.tps_guid = tps_audit_trail_value.tps_audit_trail_item_guid
tps_class_type_id = '7BFD587A-1E80-4AA6-AC18-2FE1C49DCDB5'
AND tps_audit_trail_value.tps_original_value IS NOT NULL
select md_title,* from md_class_type
where md_title = 'incident'
-- md_module_guid = 7BFD587A-1E80-4AA6-AC18-2FE1C49DCDB5
Hi, following on from the info just provided, it would be good to know why you specifically want alerts on the items you mention.
IP address changes can happen quite frequently and therefore cause many alerts to be generated. What is the business reason for wanting to know about the change? What does the knowledge allow you to do?
The name of the device is much less frequent and as you have mentioned you are using it in grouping then I can see where that might come in handy.
What sort of grouping are you attempting here and why? Perhaps there is a way that the grouping can be done more dynamically?
Also, you say you are using Management Suite but you have posted this in the Service Desk/Asset Central area so you have responses covering both sides. Are you attempting to use data in Service Desk that you imported from Management Suite?
MarXtar Ltd/MarXtar Corporation
LANDESK One Development Partner
Try MarXtar State Management for LANDESK to Better Understand and Manage your Assets
Just to add that if in fact it is ServiceDesk CMDB data (imported from LDMS) then enabling versioning in the CI type (some caution here in design though as enablement is generally one-way!) would potentially also give you auditability when certain monitored attributes change value (report on the "...version" objects) either via data change (automatic versioning) or under process control (Managed Versioning).