More on the mofo track.
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.
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. ???
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
try this at home kids.
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
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 effort required to get them to change them almost worthless.
As a side note, I did submit feedback at the support site. Maybe someone will see it?