Common customer question: “Can Service Manager audit changes to things?” Usually when people ask about this they are looking for a historical view of
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.
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:
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.
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. :)
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):
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.
Our users are also interested in the ActionLog for reporting off of the DWDataMart. Did you ever manage to post a blog on adding a new dimension in a mgmt pack?
I would like to see the logs for change requests, incidents and service requests added to the data warehouse as well.
In Service Request module the action log and history is displayed for the end user in the portal. This is very confusing for the end user. Since we have found no possibilty to send e-mails from an activity we would like to communicate with the end user in the portal.
Any way to separate the action log and history in the portal?