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.

199 votes
Vote
Sign in
Check!
(thinking…)
Reset
or sign in with
  • facebook
  • google
    Password icon
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    Stefan Roth shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →

    3 comments

    Sign in
    Check!
    (thinking…)
    Reset
    or sign in with
    • facebook
    • google
      Password icon
      Signed in as (Sign out)
      Submitting...
      • 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