Friday, June 19, 2015

Event Viewer vs. PowerShell Created HTML Reports

Issue
No. I don’t miss Windows Server 2003x at all. Or perhaps I do. One ‘small’ thing which has grown into a major nuisance in the later versions of Windows Server. It’s the Event Viewer. In WS 2003x it just worked. And it was even fast AND stable.

How much has changed in the later versions of Windows Server… No matter how beefed that server is, the Event Viewer takes a LONG time to load and when it’s loaded, it’s not very stable either. Especially when you’ve opened the Event Logs of multiple servers and are cycling through them in order to gain a broader picture of a certain issue you’re troubleshooting. Changes are the MMC will simply stall or crash…

So I can’t say I am a fan of the MMC Smile.

PowerShell?
However, sometimes I need to troubleshoot a certain SCOM issue. All those times the starting point is the Operations Manager event log in order to gain a better insight of the underlying causes.

And at moments like those, I’ve got to use the Event Viewer, with all it’s quirks and ‘hidden features’. As long as I open the Operations Manager event log for only one server, all is fine. But when I open the Operations Manager event log of multiple servers and apply heavy filtering as well, things start to get nasty.

So it was time for a new approach in which the usage of the Event Viewer is limited as much as possible and the rest is handled by PowerShell…

Say what? PowerShell as an Event Viewer alternative?
Yes and no. I use PowerShell in order to tap into the related servers and their Operations Manager event logs, dig through them, collect the required Event ID’s and pipe the output to nicely formatted HTML files, one HTML file per server and per collected Event ID. Every time PowerShell has created such an HTML file, it’s automatically opened by the default internet browser of the system running that PowerShell script.

So now my work flow – compared to using the MMC only – is like this:

  1. Using the Event Viewer in order to see what nasty and unwanted Event ID’s are logged in the Operations Manager event log on what servers;
  2. Write those Event ID’s and server names down;
  3. Run the PS script in order to get those nicely formatted (I like CSS!) HTML files.

Compare this:
image

To this:
image
Here every tab represents a certain server with a certain Event ID.

I know for myself what I prefer Smile.

Making it even easier
The first generation of the PS script required a bit more care. Simply because the server names and Event ID’s were hard coded in that script. So every time another set of servers was to be queried AND/OR other Event ID’s needed to be collected, the PS script had to be modified.

And every time a modification was made to the PS script, changes were the script was wrecked because someone deleted too much or modified parts which shouldn’t be touched at all.

In order to elevate that issue, the next generation of the PS script uses two text files instead ('C:\Server Management\Events.txt' & 'C:\Server Management\Servers.txt'), containing the required information (Event ID’s and server names).

The names of these text files are self explanatory I hope Smile. But just in case here is some basic explanation:

  1. C:\Server Management\Events.txt
    Contains the Event ID’s to be collected from the Operations Manager event log, like this:
    image

  2. C:\Server Management\Servers.txt
    Contains the server names to be queried, like this:
    image

These files need to be created with the exact names and in the correct folders. Of course, you’re free to modify the PS script as required.

The PS file will check for the presence of BOTH files. When one or both files are missing the script will notify the user about it and end the script:
image

Good looks are EVERYTHING!
Even though PowerShell can quite easily direct it’s output to HTML, the basic formatting isn’t that nice to look at:
image

With some basic CSS the same HTML output looks like this:
image

Therefore a basic CSS file is required (C:\Server Management\HTML Reports\Format.css). The same PS script checks for the presence of the related folder AND file. And when either of them is missing, they’re created by the same PS script Smile.

Talking about making live easy uh?

!!!Warning!!!
Google Chrome doesn’t like the basic CSS file since it totally ignores it. Instead it shows a lot of garbage on your screen. So open these files with IE.

And an additional tip about CSS:
When you want to sent these HTML files to your colleagues, it’s better to safe them to web archive files from IE since that way the formatting will be integrated. Otherwise – when your colleagues don’t have the CSS file on their systems – they’ll look at the ‘plane Jane’ HTML output of PowerShell which isn’t that nice at all to look at.

The PS script itself
To be found on my OneDrive.

1 comment:

runt said...

I have created an HTML powershell module to help generate HTML reports from script. If your interested there are examples here and code is loaded into github.

http://www.azurefieldnotes.com/2016/08/04/powershellhtmlreportingpart1/