cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1666
Views
0
Helpful
3
Replies

How To Track Changes to Scripts Made via UCCE AWS

fredlocks
Level 1
Level 1

Hi there

Does anyone know how to produce an audit trail/sql query which would display who had made changes to scripts or config, via the aw??

I have a customer who has had unauthourised modifications made to some scripts which have caused operational difficulties and we need to find out how made these changes pronto.

many thanks

2 Accepted Solutions

Accepted Solutions

Gergely Szabo
VIP Alumni
VIP Alumni

Hi,

yes, there's a database table named Config_Message_Log. It contains all the information that might be useful in such cases: the date and time, the user's login name and what information (more precisely: which database table) has been changed. It must be noted, however, that the "what has been changed" is not stored in a human readable form, you need to extract it using the Log viewer functionality of icmdba tool (which is a friendly GUI alternative/wrapper to the dumpcfg command line tool).

Issue the icmdba command on the command line of your AW machine. Expand Servers > [the server where a Logger resides]. Click [instancename]_sideA (or [instancename]_sideB). From the menu bar, select View > Log. A new window appears. Set the from and to dates to a desired value, then click View. It might take some time while a new window appears, containing the list of changes.

Example output:

[ 610672580481.0, Add, Nov 1 2011  7:49AM ]

PID:                4172

MachineName:        AWSA

UserDomain:         IPCC

UserName:           administrator

ProcessName:        conicrList(upcc)

SQLServerUserName:  DBO

[ 610672580482.0, Delete, t_Agent_Team_Member, Nov 1 2011  7:49AM ]

[1 of 3]

AgentTeamID:        5000

SkillTargetID:      5138

ChangeStamp:        171

[2 of 3]

AgentTeamID:        5014

SkillTargetID:      5385

ChangeStamp:        83

[3 of 3]

AgentTeamID:        5020

SkillTargetID:      5066

ChangeStamp:        86

This means on 1st November 2011 at 7:49 somebody with the IPCC\administrator login on the AWSA machine removed three agents (with SkillTargetID 5138, 5385 and 5066) from the Agent Team with AgentTeamID 5000.

Script changes are not so easy to explain, however, since each save generates a new version of a script, you'll see a new record in the t_Script table. Feel free to post the output here, I might be able to help you or at least show you the right direction.

It must be noted, however, that the Config_Message_Log table can be truncated (erased) with the icmdba tool too. So if the customer knows this, they might just perform an unauthorized change and then destroy all traces, unfortunately.

G.

P.S.: you can also use the dumpcfg tool from the command line, it's faster - just make sure you read the instructions (do dumpcfg /?) and redirect the output to a text file.


View solution in original post

geoff
Level 10
Level 10

The Master_Script table holds the ID of the script, and the Script table has a row for each version of the table, using the MasterScriptID as a foreign key into the Master_Script table. Script_Data has a binary version of the script.

Assuming you are holding a suitable number of versions (set in System Information) you will have a row for each version with the DateTime and the Author. If you are allowing users to log in as the Administrator then the author won't distinguish editors, but if script writers have to log in under their own account on the ICM AD, you will have the author. If your policy is that authors MUST add an entry to the Description when making a change (something I try to enforce), you will have a description of the change. But adding to the Description is optional (I'd love it if the Script Editor enforced this) and many don't bother.

Check the Script table.

Regards,

Geoff

View solution in original post

3 Replies 3

Gergely Szabo
VIP Alumni
VIP Alumni

Hi,

yes, there's a database table named Config_Message_Log. It contains all the information that might be useful in such cases: the date and time, the user's login name and what information (more precisely: which database table) has been changed. It must be noted, however, that the "what has been changed" is not stored in a human readable form, you need to extract it using the Log viewer functionality of icmdba tool (which is a friendly GUI alternative/wrapper to the dumpcfg command line tool).

Issue the icmdba command on the command line of your AW machine. Expand Servers > [the server where a Logger resides]. Click [instancename]_sideA (or [instancename]_sideB). From the menu bar, select View > Log. A new window appears. Set the from and to dates to a desired value, then click View. It might take some time while a new window appears, containing the list of changes.

Example output:

[ 610672580481.0, Add, Nov 1 2011  7:49AM ]

PID:                4172

MachineName:        AWSA

UserDomain:         IPCC

UserName:           administrator

ProcessName:        conicrList(upcc)

SQLServerUserName:  DBO

[ 610672580482.0, Delete, t_Agent_Team_Member, Nov 1 2011  7:49AM ]

[1 of 3]

AgentTeamID:        5000

SkillTargetID:      5138

ChangeStamp:        171

[2 of 3]

AgentTeamID:        5014

SkillTargetID:      5385

ChangeStamp:        83

[3 of 3]

AgentTeamID:        5020

SkillTargetID:      5066

ChangeStamp:        86

This means on 1st November 2011 at 7:49 somebody with the IPCC\administrator login on the AWSA machine removed three agents (with SkillTargetID 5138, 5385 and 5066) from the Agent Team with AgentTeamID 5000.

Script changes are not so easy to explain, however, since each save generates a new version of a script, you'll see a new record in the t_Script table. Feel free to post the output here, I might be able to help you or at least show you the right direction.

It must be noted, however, that the Config_Message_Log table can be truncated (erased) with the icmdba tool too. So if the customer knows this, they might just perform an unauthorized change and then destroy all traces, unfortunately.

G.

P.S.: you can also use the dumpcfg tool from the command line, it's faster - just make sure you read the instructions (do dumpcfg /?) and redirect the output to a text file.


geoff
Level 10
Level 10

The Master_Script table holds the ID of the script, and the Script table has a row for each version of the table, using the MasterScriptID as a foreign key into the Master_Script table. Script_Data has a binary version of the script.

Assuming you are holding a suitable number of versions (set in System Information) you will have a row for each version with the DateTime and the Author. If you are allowing users to log in as the Administrator then the author won't distinguish editors, but if script writers have to log in under their own account on the ICM AD, you will have the author. If your policy is that authors MUST add an entry to the Description when making a change (something I try to enforce), you will have a description of the change. But adding to the Description is optional (I'd love it if the Script Editor enforced this) and many don't bother.

Check the Script table.

Regards,

Geoff

fredlocks
Level 1
Level 1

Thanks for your response guys, both suggestions worked like a charm.

We have identified the culprit and they are now suitably embarrased.

Regards

Freddie

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: