Action Log, History, and Auditing in Service Manager

Action Log, History, and Auditing in Service Manager

  • Comments 20
  • Likes

Common customer question:  “Can Service Manager audit changes to things?”  Usually when people ask about this they are looking for a historical view of

  • what changed on an object?
  • who changed it?
  • when did it change?

There are really three related things in this area that I want to discuss in a single post to point out the different purposes of each of these things.

Action Log

The Action Log is found at the bottom of the incident and problem work item forms.  This is where analysts can enter notes about what they have done on the incident or problem work item.  This is important when an incident or problem work item is being handed off from one shift to another or being routed/escalated to someone else to that the person taking over the incident or problem work item knows what has happened previously.  Some of the more important events in the lifecycle of an event are automatically added to the action log such as when an incident is assigned/reassigned, closed, or when console tasks such as Ping Computer are run the results can be automatically or on demand added to the action log with a click of a button.

Notice in the screenshot below how we capture the major events in the incident/problem lifecycle like:

  • Created: The original title of the incident is added to the action log at the time of creation.  The creator of the incident is also the Created By person for this action log entry and you can see the date/time the incident was created.
  • Assigned: We capture who assigned the incident to whom each time the incident is reassigned.
  • Analyst comments: Analysts can put any comment they like into the incident and can optionally choose to mark the comment ‘Private’ meaning that the end user can’t see that comment on the self-service portal.
  • Console tasks: when analysts run tasks like Ping Computer, Remote Desktop, or any other console tasks that produce output the output can be automatically logged to the action log.
  • Escalation: When an incident is escalated from one tier to another the information about which support group the incident is escalated to and a required comment from the analyst are recorded in the action log.
  • Resolution: When the incident is resolve the analyst must provide a resolution comment which is added to the action log.
  • Closure: When the incident is closed the analyst must provide a closure comment which is added to the action log.

Note: please ignore that the person in the created by column is always Administrator in this screenshot.  The reason is because I’m too lazy to actually log off and back on as different users to simulate real world usage.  The created by column is always populated by the user that makes the change.

image

 

History

For every object in the system we keep track of every property change and relationship add/remove, who made the changes, and when they were made.  You can see this information on the form of pretty much every object in the History tab.

image

This level of detail is useful for things like:

1) Find out who set the Impact to Low on the incident that caused the CEO to lose all the data on his hard drive. :)

2) Trying to figure out what configuration changes have happened (and when) for a particular computer changed as part of investigating an incident.

History is also what drives the subscription infrastructure but that is different set of blog posts for a different day. :)

 

Auditing

The action log and history will meet most customers requirements for an “audit trail”, but if you want to meet the true definition of auditing in a way that gets you respect from a Compliance Auditor, you’ll want to enable Auditing.  Some government, industry, and corporate regulations/policies require that access to systems be logged in such a way that is “tamper proof”.  There really isn’t a way for someone to delete or change the history information in the database unless they have access to the database, but in some cases you need to log auditable data in a place that even the database admins can’t touch it.  That’s where auditing comes in.

When you turn on auditing on the Data Access Service, every call to every API on the Data Access Service is logged – which API, who, when – into the Windows security event log.  You can then use System Center Operations Manager Audit Collection Service to collect all of those security events into the highly secure Audit Collection Service Database.  That will make your auditors happy!

This is an example event:

image

Since this feature is something not every customer is going to actually use, we don’t turn it on by default out of the box.  To turn it on, follow these instructions on each management server in your deployment (including the data warehouse management server):

  1. On the Start Menu, Open Local Security Policy, found under Administrative Tools
  2. Expand Local Policies and select Audit Policy
  3. Select "Audit object access"
  4. Right-click and Properties
  5. Enable "Success" and/or "Failure", depending on what you want to audit

A couple more notes on the auditing feature:

For users submitting tasks which run on the management server (including Windows Workflow Foundation workflow tasks), we audit: JobId, TaskId, TargetObjectId, whether the task requires encryption, every override and value applied (if any) and username and domain if an alternate account was provided for execution.

For ManagementPack change failures, including imports, updates and deletes, for security related failures we audit which management failed to be changedand what element triggered the failure. This can occur for users in an Author or Advanced Operator profile that try to perform management pack operations outside their class scope.

Finally, we audit additional information for user role related changes.

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment
  • Hi,

    In what tables are the data stored for the history tab for incidents?

    I'm specifically looking for the user that made the changes.

    greetings

  • Look in the _Log table for the class you are interested in.  For example:

    MT_System$WorkItem$Incident_Log

  • Thanks. Exactly what I was looking for :-)

    Now I'm trying to figure out how to get it as a dimension to DWDataMart, and afterwards make a fact table for it.

    I tried with AnalystCommentLog, but this one has an existing relationship in the Class Model.

    What steps should I take, or classes should I make, to get where I'm trying to go?

    Greetings,

    Peter

  • When you create a task there is a check box to "log to the action log". Where is this action log and how to you view it?

  • @Ken -

    The action log exists for certain kinds of work items for now - incident and problem.  It may expand to other work items like service request, release record, and change request in the future.

    You can see an example of the action log in the post above.

    If the checkbox is checked when you create the task, the output of the task will be added as an entry in the action log of the item that the task was launched from.

  • Hi,

    I am trying to report on action logs for an incident.  The MT_System$WorkItem$Incident_Log table shows 0 records.  Even the MT_System$WorkItem$Incident table has no data.  In fact, most MT* tables are almost empty.  Are these tables from

    DWStagingAndConfig database?

    Regards,

  • @Young -

    The action logs are not brought over to the DW by default.  You would need to define a new dimension in a management pack and import it.  I think we will have a blog post on this soon.

  • In this case, which database and table should I use to retrieve the data?

    <<<<<<

    The action logs are not brought over to the DW by default.  You would need to define a new dimension in a management pack and import it.  I think we will have a blog post on this soon.

  • Travis,  how soon will you have a blog posted?  We have a team here that is not happy that they can't get to the Actions logged by their staff in closed incidents.  I needs this ASAP.

    Thanks

    Denise

  • Hi Travis

    I am also very interested in the blog you intend to have on getting log data into the DWDataMart. We implemented SCSM several months ago and now management wants to start gathering metrics from the log data.

    I'm having a difficult time finding the information I need to build Report Models for Reporting data. Other than this blog can you suggest other sources of information for SCSM. ERD, schema navigation, table/view descriptions etc. Thanks.  

  • Hi guys,

    I have been tearing my hair out trying to find a schema for SCSM that details all the dimension tables and how they inter-relate.  The Action table is one i'm looking for but can't seem to find!

    Help!

    Chris

  • @Chris -

    The DW schema is available in the SCSM Job Aids Package:

    blogs.technet.com/.../service-manager-data-warehouse-schema-now-available.aspx

    The action log is not currently part of the DW data mart schema.

  • Hi Travis,

    Thanks.  I've seen that schema before.  Where can i find the table that shows the action log entries? I assume it's in the ServiceManager DB.  It would be good to get a complete schema of the system.

    Chris

  • @Chris

    The data model is documented as a Visio diagram that is also included with the SM Job Aids Package.  We dont document the DB schema itself since we dont want people to interact with the DB tables directly.  They are not designed for that. Instead people should interact with the data model through the SDK and PowerShell.

  • Do you have some standard reports i can run to get visibility on the level of effort of each analyst.  I'm particilarly interested in the action log.

    Chris