I never imagined as a young engineer at NetIQ that I would, some 20 years later, have built a career on SCOM and the System Center suite. I’ve been fortunate to ride the System Center dream (and occasional nightmare) at Microsoft partners, as a Senior Premier Field Engineer at Microsoft and as a customer at a significant financial institution in the UK. But at a time when I am more and more involved with Azure and Cloud monitoring, I thought it would be a good idea to go back over some of authoring I have done and share some thoughts and ideas on how I have gone about using SCOM for both infrastructure and application monitoring.
But the bottom line is that unless individuals look at the results of your monitoring, then all your development work isn’t going to reap the rewards it should. So I’ll pay particular attention on building monitoring in such a way that it can be easily displayed on dashboards across your enterprise. And to design the monitoring so that you, or your internal customers, can decide on how health roll up will work and which monitored objects will go red. For example; if you have separate infrastructure and application teams then you want to ensure that the right objects display the right status for the right teams.
This authoring series won’t be a full tutorial – for that you cannot beat the great work of Brian Wren on the MVA training. I also won’t be duplicating the official documentation. Instead, I’ll be looking to supplement both of those sources of information with examples of different ways of authoring management packs depending on what it is you are looking to achieve.