It would be handy to De-Activate a MP instead of deleting it. Or set a MP in maintenance.

It would be handy to De-Activate a MP instead of deleting it. Or set a MP in maintenance.

With SCOM Always On sql architecture. Whenever a maintenance schedule is created it is not replicated to secondary DB. This requires manual effort with DB permissions to replicate the SQL agent job. The schedule is not effective until its replicated which eliminates the self service feature for end users. Not every one has DB permissions.

Change permissions on Dashboards and Views takes forever to save, currently +/- 40 min. This seems to be related to the number of classes, relations and views in the database.

This must be changed. It's not a workable situation that it would take 40 minutes to change just 1 view permission in 1 role.

I wish there was more of a user friendly way of creating queries for SCOM group, I been working on a group of non prod SQL server DB engine from 2005 -02017. using regular expression it is so messy. wish there was a better way to build the query.

Multi-homed Gateways would allow to...
a) reduce the number of servers if you have a small number of agents within the same DMZ reporting to 2 separate Management Groups.
b) allow failover of agents from a production to a DR management group.
c) accommodate agent failover for Red Forest security scenarios.

Prior to SCOM 2012, AD Integration workflows could be run on a Management Server or on gateway in a remote domain. Beginning in 2012, the AD Publishing Pool owner performed any publishing, which removed the ability to publish SCOM containers in non trusted domains.

SCOM 2016 has a issue that becomes evident over enough time where unused space on Performance and Event Tables grows and eats up the space in the SCOM SQL Database to the point that SCOM can not perform its nightly maintenance and then a Group job across the 62 partitions needs ran to clear out this unused space. The maintenance to clear out this space should already be included to accommodate the issue where SQL 2016 changed its bulk insert.

Currently, the Maintenance Mode scheduler makes use of SQL Server Agent jobs to schedule the maintenance windows. This creates issues in highly available environments and an unnecessary dependency. Scheduled maintenance should be handled by a rule like other tasks.

With 1801+ the "Updates and Recommendations" node also includes 3rd Party MP's

However, I may not want these MPs to be installed (Ie Costs, etc). So when it comes to updating MPS that are already installed, I need to do them one at a time

Can we have the ability to decline MPS that we don't want to update or install?

Would like to have the ability to apply a rollup to the environment without visiting each server and without creating custom scripts. Simply pull down the rollup and apply to selected servers from the console.

Can we please have the ability to select more than one alert in the Web Console?

At present (v1801), you can only select one update at a time

This makes changing the likes of the Resolution State time consuming if there are a few of them..

Best way to explain is an exemple.

I put a logical drive in Maintenance Mode for 60 Min.

If my collegue put the windows Computer in maintenance WITH Child Iems for 15 min during my maintenance, My logical disk will be out of maintenance a the end on the Computer Maintenance.

Normaly i expect the maintenance on my Logical disk should be end at his scheduled end time MINIMUM never Before.

Thanks

Certain customers have a global command center that acts on alerts and health states changes. As such we would like to have a more granularity level in User Role permissions. It would be nice to restrict access to maintenance mode from operators.

There should be an option to turn on/off auditing on each of the user role types. We have a need to delegate override privileges to our users and would like to have some insight as to what they are changing and ensure the correct management packs are used for the storage of the overrides.

When upgrading agents in 1801 form the console, in the administration pane, after selecting agents there is no OK button to deploy the upgrade to selected agents. Pressing enter works and the upgrade process begins.

The ability to produce dashboards using native MS products rather than having to buy a £rd Party solution to get them.

It would be great if we could directly record all changes to SCOM (including the management packs) to a version control system, like Git