Auditing changes in SCOM
I have no way to know who made what changes in the SCOM environment. There are multiple admins and they change settings such as Install MPs/ Remove MPs/ Change Overrides/ Author new rules/ Change Admin settings/ Create new users/etc. There is never a way to know who did what.
This is a feature request to Audit all major changes to the SCOM environment.
Thanks for your votes. We are doing it in phases. First phase will include Install/Remove MPs, change overrides and the next phase will include Admin settings. Please fill this survey if you would like try your hands on the feature earlier than others and share your feedback.
It would also be helpful if we could include the ability to audit against a set of defined standards. For example, a list of management packs and overrides would be the source and the audit process would check the system to determine if the management packs were installed and that the overrides were present. SCOM administrators in large environments with disconnected subordinate management groups are looking for a way to manage the configuration of these management groups to guarantee consistent monitoring across the enterprise and as a way to counter the unapproved actions of regional administrators
Alaguraj Palaniappan commented
We really required this feature to trace all monitoring operations performed using Operations Console and PowerShell Module since we had recently faced an issue where 1800+ UNIX/Linux monitored servers were removed from monitoring but no clue so far on account / user who did that.
Henrik Nørgaard Hansen commented
Adding a Windows event log entry for changes in the setup of monitoring in SCOM isn't a workable solution IMNSHO.
Would the events be logged on each and every Management Server? Or only on the workstation where the changes were performed? If the event is only logged locally on the workstation how can I ensure that it is collected for reporting without having an agent on each and every workstation?
I suggest logging these changes to the SCOM database(s). I suggest a new data table with containing these entries. Of course only the most recent would be available in the OperationsManager database but all data would be stored in the data warehouse. Perhaps in a manner quite similar to how events are being handled already?
Reporting could consist of a simple report allowing a choice of period, the nature of the change (add/rename/delete), the kind of object involved (monitor, rule, discovery etc.), the account that performed the change, etc.
Thanks all for your votes. We are evaluating this feature and the scope for now is to audit MP changes. Any changes to Rules, Monitors, Object discoveries, Groups, MP import/create/delete will be logged in the event viewer. If you want to create reports then we will provide a way to send these event logs to log analytics for easy reporting. Please share your comments/thoughts on this.
Please allow for more than Azure Log analytics as a audit source. Some environments are in a isolated network where this option is not possible at all.
Please add auditing. Leaders often compare this to ScienceLogic's EM7 where they audit every single action and click. Audits should be track what you clicked on, and what action or tasks was trigger and where that tasks went and end results of that tasks.
This would be a welcome addition to SCOM as we service multiple environments.
The points from Sergey Mukhin are indeed the kind of information we as SCOM administrators would like to see for auditing the actions our customer teams perform.
Ramu Chittiprolu commented
+1. Audit feature for rules/monitors and overrides is must.
Please add this feature. This is helpful in an environment where everyone needs to have access to everything. In the current security focus world, the lack of auditing makes SCOM look very outdated.
I agree, auditing on SCOM is a must, with multiple hands on a single SCOM solution it is impossible to see who made what changes.
It is strange that you can not audit Admin's work on a system as it can have detrimental effects on the clients environments
I would give this 100+ votes. It is really important to know who actually closed or changed the status of an alert. I know SCOM has covered this issue partially, but there is a special case where a user resets a monitor status, hence related alert(s) appears to be closed by "System". If this alert is "Failed to Connect to Computer", the monitor will never run again.
Ideally this should be written to log in which we could our log aggregation and analytics tool (our is Splunk) to ingest and store this data so we have it for trending, history, security, etc.
Can we have another column in every view, table, or list that indicates who made changes and when?
+1 , now we have only overrides report..
There should be a log of every changes made by who, when, where, before and after changes.
I agree, not only see what changes have been made but also have the function to delete the "change" and have the settings restored.
Sergey Mukhin commented
e) access rights to views
f) group members
g) resource pool members
h) User roles
i) discovery rules for network devices
j) approved agents
f) switched instance(s) to maintenance mode?