The Windows Server 2008 and 2008 R2 Hyper-V management packs for OpsMgr (aka SCOM) have a bug in them where they discover Windows Server 2012 boxes with the Hyper-V role installed. Hyper-V has a few logs which have changed between the two versions and when the 2008 MP tries to query the server, it fails because the logs no longer exist. This generates the alert you see in the title of this post.
There are several monitors that can cause this behavior and numerous other blogs have covered how you can override the MP and exclude your 2012 servers. This does work most of the time. However, I had one stubborn server where I simply could not find the object that needed to be overridden.
Finally, it dawned on me. The only problem is that the MP can’t find the log. Why not just create the log and forget about overriding these stupid management packs?
It turns out that it’s actually pretty simple to do this, but the documentation is not the best, especially if you are not a developer, as it’s all buried in MSDN.
The log it’s looking for is one of the new Event Tracing for Windows logs that appear under Applications and Service Logs in Event Viewer. You can’t create these as easily as it was to create event sources for the application log. Fortunately, once you figure it out, it’s not too bad. You need to create a manifest file. This defines how logging is done for your application (in our case, a non-existent application). All we need to do is create a “channel” that has the same name as the old Hyper-V logs. There’s a program that comes with the Windows SDK called ECManGen.exe that does all the heavy lifting. That’s a big download, though, so if you don’t have it, just use my manifest below.
Once you create the manifest file that defines the target log, use wevtutil.exe (which comes with Windows, thankfully) to import the manifest. That’s it. The log is created. We don’t actually need to populate the log, we just need it to exist. So this is sufficient.
Here is the manifest file. For organizational purposes, so that these dummy logs don’t show up under the Microsoft\Windows section (we don’t want to confuse them with the real Hyper-V logs), I place them under a section titled “CompatibilityWithOpsMgrMP.” Feel free to change this. It’s just a logical name and doesn’t affect how this works.
xml version="1.0"?>
<instrumentationManifest xsi:schemaLocation="http://schemas.microsoft.com/win/2004/08/events eventman.xsd" xmlns="http://schemas.microsoft.com/win/2004/08/events" xmlns:win="http://manifests.microsoft.com/win/2004/08/windows/events" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:trace="http://schemas.microsoft.com/win/2004/08/events/trace">
<instrumentation>
<events>
<provider name="Microsoft-CompatibilityWithOpsMgrMP-Hyper-V-Network" guid="{7103BFE7-D8FC-42B2-A82B-331A24ED2C93}" symbol="Microsoft_Windows_Hyper_V_Network">
<channels>
<channel name="Microsoft-Windows-Hyper-V-Network-Admin" chid="Admin" symbol="Admin" type="Admin" enabled="true">
channel>
channels>
provider>
<provider name="Microsoft-CompatibilityWithOpsMgrMP-Hyper-V-Image-Management-Service" guid="{E7748442-4EA4-40EB-9A4D-ED4D1AAFF5FC}" symbol="Microsoft_Windows_Hyper_V_Image_Management_Service">
<channels>
<channel name="Microsoft-Windows-Hyper-V-Image-Management-Service-Admin" chid="Admin" symbol="Admin" type="Admin" enabled="true">
channel>
channels>
provider>
events>
instrumentation>
instrumentationManifest>
Save the above to a file called hyperv.man then type the following at the command prompt: wevtutil im hyperv.man
To uninstall it later, type: wevtutil um hyperv.man
Note: you need the manifest to uninstall it, so don’t delete that file.
After this, reset the status on the alerts, recalculate health, and you are done!