In my last post http://wp.me/p38JpH-W8b, I posted on how PowerShell can be used in the background of our SCOM Servers to collect performance data on multiple classes and bring it into one simplified view. In this post I am going to show you my first full-fledged management pack designed to monitor a monitoring system aka What’s Up Gold. In my enterprise I am the sole admin to both of these monitoring solutions. While I could take the time to describe some frustrations I have with either, I would rather describe the intent behind this management pack.
First one of the things I needed to do most was to track where a particular device existed in terms of which instance of my distributed WUG setup. I have 19 servers with one being a central system. I most certainly didn’t want to create a SQL query for each one and pull it back together to do so. So before I made this management pack I created a complex SQL query on the central system to get the local systems and the remote systems from several tables and “Union All” them together. I then setup a job every 10 minutes to spit that data back to a csv locally on the SQL server. From there I made a PowerShell script to read all that data, as well as all the maintenance mode text files my system generates to build a simple HTML page for our helpdesk or anyone else for that matter to view what’s going on in WUG. Lots of effort to put together, but well worth the time spent.
Since I had just this last December completed a SCOM Advanced Authoring Course by Infront Consulting, I wanted to test my skills and build something from scratch. I loaded Visual Studio 2013 community edition and got to work. Since my WUG setup is rather simple, my MP is going to be a bit simple (at the moment). In this MP you will find four classes, two aggregate monitors, one dependency monitor, a few WUG services monitors, as well as the most important monitor “WUG Monitor Object Monitor”.
This monitor is run every 5 minutes against the SQL server containing the WUG Database. It uses PowerShell to query the DB for monitors and a hash for filtering down to the right individual monitor, and a three state monitor that mimics the default WUG health of Red, Yellow, and Green. If you have additional monitor states in WUG the MP will not pick those up. If you have configured the “State Time” field in WUG to something else, this will still see those changes as they don’t change the Status ID field in SQL. I have about 1,000 unique monitors in my central WUG specifically and the cookdown every 5 minutes does not negatively affect SQL even with the additional SQL job for my scripts still running. These monitor objects rollup to the device object. This link from monitor to device is done via SHA1 hash of the DeviceID and the WUG server name. This hash is also FIPS compliant so if that’s turned on it won’t be a problem.
I am including pictures of the two views (as of now) with important information removed.
The first view is an overview of the whole system, and the second is the view that your want to scope to your help desk/watch desk teams for looking at what’s up and what’s down. These are my own icons thanks to MS Paint (I am not a graphic designer).
There is not a whole lot to this MP, but it is certainly a starting point for me as a MP writer. Hopefully you find this useful and if you have questions, comments, or feedback on what I can do with this in the next iteration let me know.
I am going to be working on some tasks to restart WUG services, and include a task to the WUG SQL servers to rediscover the devices and monitors, maybe down the road some performance information on the WUG/SQL side. I would also like to build seamless integration of the Maintenance Mode events from SCOM to WUG as well. Right now my system is doing that via a script and a SQL script that emulates the WUG actions being passed to SQL from the Website/Admin Console. And I still need to bring the WUG notes/comments in to the device properties.