Up to Something

You have to give Microsoft credit. They were 66% correct. That’s about 150% better than normal. Seriously. Todays fun is imported from the land of broken-wmi-crap.

The Bug

After the super-exciting side affect of an asshat package manager, a Microsoft standard-issue-busted-software problem has cropped up:

Event Type: Error
Event Source: MSExchangeSA
Event Category: Monitoring
Event ID: 9097
Description:
The MAD Monitoring thread was unable to connect to 
WMI, error '0x8004100e'.

The Microsoft Article purported to fix this is 33% wrong. They list the major components, and the MSExchangeSA error does indeed subside. Side-note: I found that I had to re-do the steps listed in the TID - AFTER a reboot. ???

The Tragedy

However, I discovered a new pain after my joy: the Message Tracking Center returns WBEM error 0x80041010. Translate this, “missing wmi class”. I did a number of searches (lots of hits from mis-informed TID-spouting ‘do-holes) and finally located this article in Google Groups. He walks through re-creating WMI, and other neat things. I skipped ahead, as I had done all of this before.

I followed his testing advice - I couldn’t get the remote testing to work - local testing showed that root\microsoftExchangeV2 only had 73 out of 74 classes. Frustrated I briefly considered a by-hand comparison with a functioning server. I chose to plow ahead, based on this guys informative nature and clear expertise - and it paid off:

The Missing Command

mofcomp.exe -n:root\cimv2\applications\exchange “c:\winnt\system32\wbem\msgtrk.mof”

In my case the command was actually:

mofcomp.exe -n:root\cimv2\applications\exchange msgtrk.mof

The Apathy

This worked when Microsoft Failed. I feel semi-indifferent. I think this is Microsofts chief tactic for dealing with “haters who want stuff that works”. Entropy from the titanic marketing efforts makes the efforts get them to change them almost worthless.

As a side note, I did submit feedback at the support site. Maybe someone will see it?