(installation instructions at bottom)
There are a number of cool scripts that I’ve collected, borrowed, and written in my travels as a SCOM field engineer and PowerShell enthusiast. I decided to put them all together into one module for easier maintenance and use. Enjoy.
SCOMHelper Module Functions:
First and foremost my pride and joy is this brilliant work of art. I’m pretty sure I just tweaked my own arm patting myself on the back but you know what, I am really proud of this. This is a first of its kind tool (that I know of) for generating a graphical representation of a SCOM class. It will create a graphical structure (.png) that represents SCOM class taxonomy, all properties, hosting and discovery relationships for a SCOM class. This function relies on a few other brilliant modules but don’t worry, this function will automate the other module installations for you. (This is assuming you have connectivity to the interwebs. Yes, interwebs. Otherwise you will have to obtain the dependencies manually.) This tool will prove to be priceless for any SCOM admins, enthusiasts, and most importantly, MP authors, both new and seasoned.
Note: This function requires PowerShell v5 or greater due to some other module dependencies. Tested with SCOM 2016, 2012 R2.
Feed this function one or more of the following: a class object, class Name, class Display Name, or class ID, and it will do the rest. There are a few neat parameters to control caching of graphics files, include/exclude related class discovery workflows, and displaying the new graph file.
Below is an example of class: Microsoft.SQL.Server.2014.DBEngine. The legend is shown on the top right of the graphic to help you understand the relationships between boxes.
The orange boxes represent classes that are HOSTing those connected below it.
The blue boxes represent discoveries which are capable of discovering those classes which are connected (along with the properties listed in blue).
The green boxes are hosted classes, which means they hosted by the orange class box connected above it. (see ‘orange’ definition above).
The gray boxes represent ordinary abstract classes. Note: other colored boxes may also be abstract.
The remaining boxes and arrows represent ordinary class lineage (parent –> child) relationships.
Awesome. I know.
( References: Relationships, Understanding Classes and Objects, SCOM Fundamentals )
2) This is a much fancier way to accomplish the same thing as Example 1, above, but with the help of GridView to select the class. This command will get all SCOM classes in the management group and select Name, DisplayName, and ManagementPackName to be presented in GridView for easy browsing and selection by the user. Select one or more classes from the Grid View, click OK. In the example below I’ve filtered on keyword “SQL” and selected a single line item. This selected class name gets piped into the function: New-SCOMClassGraph. The resulting graph (.png file) is shown above in Example 1.
The graph file opens with your default ‘.png’ application. Your default viewer might be Internet Explorer, it might be Picture Viewer. You decide. Just be sure to associate .png file type to a default viewer.
You can optionally use the -ShowGraph:$false parameter to prevent the opening of the .png file. You might leverage this feature if you simply wanted to cache all of the files on disk without opening them. I did this in my lab and it took 45 minutes to generate 1688 graphs for a total of 276MB.
2) This is an example of piping a class object into the cmdlet:
This one’s pretty obvious. Will clear the agent cache and restart the HealthService (Microsoft Monitoring Agent) on the local machine.
As you may know, collecting events with SCOM is mostly useless and often times results in performance problems and data bloat in the DBs. This will disable all event collection rules for the designated sealed management pack(s).
Feed this function one or more sealed management pack objects and it will create a corresponding unsealed pack for each in which it will store overrides which disable any/all event collection rules that are currently enabled. The resulting overrides will target the workflow class target.
Note: This will heavily tax your management server and Operations database during creation of the overrides. However, once the override files are created, they can be exported and imported wherever they are needed. You might consider running this in your Test environment first, then exporting the override packs to import into your production environment.
Example from my lab machine. The CPU was pegged for a while.
The functionality is documented here (though I changed the function name slightly in this module).
Will recursively find contained instances of an object (or group of objects) and output the effective monitoring configurations/settings to individual output files. Then it will merge all resulting files into one .csv file, delimited by pipes ‘|’, then output all data to Grid View. In the output directory you will be left with individual configuration files for each object as well as the master merged file containing all object configurations.
This is a quick way to dump events from the Operations Manager event log to a CSV file.
This is pretty well documented here.
This script will get all rule and monitor knowledge article content (with hyperlinks) and output the information to separate files (Rules.html and Monitors.html) in the output folder path specified.
Will display statistics about the total number of SCOM class instances and the management packs from which they originate.
1) Statistics by class…
2) Statistics by management pack…
This will generate an awesome HTML report including many of the popular Health report contents and SQL queries that we all know and love. This was originally written by Tim Culham and then rebooted by MBullwinkle in 2014. It made sense to include it in this module.
Feed this function a folder path and it will list version and file path information for all management pack files (*.mp, *.mpb, *.xml) in all subdirectories.
If you’re environment is anything like mine, you probably have a spaghetti mess of folders upon folders stuffed with all kinds of management packs that you collected over the years for testing. It’s not always convenient or easy to keep all management packs organized in version-labeled folders. In fact, it’s a huge pain in the neck seeing as how there’s no easy way to determine versioning of MPs based on file properties. This is a friendly tool which will display all of the basic MP info for you.
1) Feed this function the path to the ‘ManagementPacks’ folder from my SCOM installation media:
Note: -Passthru is already enabled on the GridView to allow the user to select one or more MP items so they can be piped to another cmdlet that accepts management pack Name, DisplayName, or ID as piped input.
2) This is a super simple way to pick from a list of MPs to import.
Feed this an account SSID and it will return the friendly name of a RunAs account.
When a RunAs account problem occurs the resulting errors will appear in Operations Manager event logs containing the account SSID instead of the friendly ‘Display Name’ which makes it difficult to determine which account is involved. This function will reveal the friendly name of the SSID.
This isn’t really specific to SCOM but I found it useful in the past so I included it in this module. Feed it an ordinary string (or any object) and it will generate a unique hash value.
This also isn’t really specific to SCOM but I found it useful in my own (SCOM) lab environment so I included it in this module. In my lab environment I have to ping my network devices occasionally to refresh the forwarding table on my cheap 1Gb switch so that they can be reached without first establishing a path. (I hope I’m explaining that clearly). Otherwise, my first connection attempt to my lab servers fails and I have to wait for it to timeout. Upon my second connection attempt, I can successfully connect. I will often let this continue to run in the background to keep those paths fresh. Mmmmmm, fresh paths!
This will ping all hosts a total of 999 times while pausing for 3 seconds between attempts.
This function will remove obsolete aliases from unsealed management pack .xml files, offline. This will not alter the original file but rather will output modified versions to the designated output folder.
This will modify a single .xml file:
This will retrieve all .xml files and pipe them into the function:
This will standardize all of the aliases in one or more unsealed (.xml) management pack files.
Occasionally (unfortunately) it is necessary to move elements from one unsealed pack to another unsealed pack by cutting/pasting. When unsealed MPs are created by activities within the Console, the references/aliases that get created are randomly named/assigned and often times are ambiguous and usually inconsistent between unsealed packs. This makes it very difficult to cut from one file and place into another file because the aliases won’t match (this is assuming that the same/necessary references exist in both files).
This function will inventory all of the MP reference IDs that can be found in the single file (or set of .XML files) specified by the InputPath parameter. It will create a customized set of condensed alias acronyms to be standardized across all of the unsealed management packs. It will then replace the aliases in the Manifest section of the file(s) as well as throughout the file in elements where the aliases are used.
Note: This will modify the unsealed MPs located in the designated ‘InputPath’ location. However, the functionality of the MPs will not be affected.
This is an example of what your updated unsealed MP file will look like.
Will display all known modules contained in all sealed management packs as well as basic schema information. Based on an original script found here: http://sc.scomurr.com/scom-2012-r2-mp-authoring-getting-modules-and-their-configurations/
This can prove to be useful when authoring or debugging.
I’m a big fan of Out-Gridview.
This will test any number of TCP ports on any number of hosts. It will accept piped Computers/IPs or Ports and then test those ports on the targets for connectivity.
There are plenty of examples of how to unseal MP files but this version will Will unseal .MP and .MPB files along with any additional resources contained therein and place into version-coded folders.
1) This will unseal all of your Microsoft sealed packs (which normally get extracted/installed to the default SCOM MP folder location).
Here’s an example from my lab:
Additionally you can view more info at the PSGallery.
Code snippets highlighted by hilite.me