A lot of customers close alerts generated by monitors. Although they got very good instructions, they don't reset the monitors. PowerShell and Greenmaschine, don't do a very good job in resetting monitors. there should be a way to automatically reset monitors when an alert is closed and/or an option to reset all monitors to a green state.

Maintenance Mode can only be startet via console.

We have a lot of server administrators and automatic scripts which initiate sometimes a reboot.

It would be great when a machine can be switched to Maintenance Mode by the agent, for example with a Powershell CMDlet.

Implementation of dynamic application discovery like former BlueStripe software and building the corresponding distributed application with all it's dependencies.

The subscriptions are very limited in setting criterias. A more granular targeting and options would help deliver more accurate notifications. E.g. there is no way to exclude.

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.

The alert object does not always contain the source FQDN of the generating server. This property should be able to get by PowerShell. This would help building connectors using PowerShell / SMA etc.

Better Multi Tenancy support. As an hoster with both datacenter and on-premise customers we need better support for customers integration and general setup in the console.

The group functonality is not good. You should be able to use active directory groups to target MP:s/views and so on.

Make a bool setting on each Management Server object to check mark, that this MS cannot be accidentally put into Maintenenance Mode. This would avoid a lot of Problems for customers who put servers into Maintenance Mode.

On the current SCOM console, only the display name of the monitoring class is visible. Would be nice if the actual monitoring class name, and the monitoring object ID can be displayed in the console (i.e. in the state views). This would help MP developers and SCOM users looking up objects when writing MPs, dashboards and scripts.

There is no easy way to figure out where the SCOM Group is located. A column in the GUI Authoring/Groups with the MP Name where the SCOM Group is stored.

I can change the SCOM operational database grooming settings from within the SCOM console. If I wanted to change SCOM Datawarehouse grooming settings, I have to download the dwdatarp utility from a blog post, get access to the DB and then set the groom settings. This is a request to add Datawarehouse groom settings to the Administration pane.

PowerShell Cmdlet to populate "Explicit Membership" groups. Should accept pipeline input or as string. Option to specify class. Here is an Example: Get-SCOMGroup _Displayname *Windows|Get-SCOMClassInstance | Add-SCOMGroup -GroupName 'Custom Windows Computers'

Another Example $list = Get-Content 'C:\servers.txt'
$list |Add-scomgroup -ClassDisplayName 'Windows Computer'

Do any of you have a requirement to use gMSA accounts in your SCOM environment? If you do, please upvote this suggestion and kindly add the scenario you hope to use it for and how it would help you.

Provide access to enable scoped users leverage the functions offered in the Maintenance Schedule wizard, without imposing the requirement that the user must als0 be delegated access to the administration workspace

Just wanted to point out that there is no event collection storm suspension, i had 28million events collected from a server in a short period of time, which flooded the OPSDB, so it would be a good idea to have the ability to suspend the event collection if there is a storm

Currently forced to use external command channels for creating HTML templates for notifications, which can lead to issues with the crossing the asynchronous process limit in the case of an event storm.