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.
Especially in the azure managementpack. Currently alerts are useless since you cannot map them to ci's in your cmdb.
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.
- 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
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.
Sami Koskivaara commented
Agree, this would be a very good addition.