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.
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.
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:
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):
- On the Start Menu, Open Local Security Policy, found under Administrative Tools
- Expand Local Policies and select Audit Policy
- Select "Audit object access"
- Right-click and Properties
- 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.