I suggest you ...

Alert object should always contain source server FQDN

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.

208 votes
Vote
Sign in
(thinking…)
Sign in with: Facebook Google
Signed in as (Sign out)
You have left! (?) (thinking…)
Stefan Roth shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →

4 comments

Sign in
(thinking…)
Sign in with: Facebook Google
Signed in as (Sign out)
Submitting...
  • Ronald commented  ·   ·  Flag as inappropriate

    Especially in the azure managementpack. Currently alerts are useless since you cannot map them to ci's in your cmdb.

  • rob1974 commented  ·   ·  Flag as inappropriate

    I know this is not always possible (or even desirable when doing application monitoring), but loads of very basic management packs of microsoft need improving.

    e.g.
    - network monitoring has a primary key of the MAC address, which is the only way to find network devices in performance views. No one knows this...
    - *Nix monitoring shows the OS version without the "servername" as object.

    This is not really a SCOM product change, but more a more careful MP design, which also should be addressed.

  • Will Prather commented  ·   ·  Flag as inappropriate

    I like this idea. Currently, I have Orchestrator looking at three different fields just to find the hostname.

    I realize from a technical perspective, a Health Service Watcher does not reside on the agent, but from a user perspective, telling me that the alert is coming from the management server is misleading as that is not where the problem is.

Feedback and Knowledge Base