Health Service Modules Event ID 21405
While working with a customer recently we found an odd issue I thought I would share with my readers. My customer created a new monitor targeted at the Windows Server Operating System class. The monitor was supposed to run a PowerShell script to collect some registry information and alert if there was anything miss-configured. The problem they were having is that the script did not seem to be running.
I began to look at the problem, and added code to the script to write an even to the SCOM event log when the script began execution using the MOMAPI COM object. Sure enough, nothing got logged. Things got stranger, when I looked at the health explorer for the Computer object in question, as the Operating System rollup monitor and all its underlying aggregate and unit monitors were marked as empty circles. Essentially, the Operating System, the hardware, and almost everything on the server was not being monitored.
I first suspected it might be some sort of override gone wild. We searched through the list of overrides in the Authoring workspace of the SCOM console, but came up empty: no interesting suspects here.
I then had my customer flush the agent cache manually, by stopping the Microsoft Monitoring Agent Service, deleting the contents of the Agents Health Service State folder, and re-starting the service. I felt the normal wave of relief when Event ID 1201 showed up in the Operations Manager event log, indicating we were successfully communicating with the Management Group. But my relief soon turned to dread when a sea of warning events began to flood the event log. The events looked like this:
Log Name: Operations Manager
Source: Health Service Modules
Date: 9/6/2017 2:57:05 PM
Event ID: 21405
Task Category: None
Level: Warning
Keywords: Classic
User: N/A
Computer: SERVERNAME.DOMAINNAME.COM
Description:
The process started at 2:57:05 PM failed to create System.Discovery.Data, no errors detected in the output. The process exited with 1
Command executed: "C:\Windows\system32\cscript.exe" /nologo "PopulateAdvisorWindowsServerProperties.vbs" {DE47446F-B2E9-AFFC-D672-CD274318C360} {116028CA-EEA1-074A-3425-70EEC8705455}
Working Directory: C:\Program Files\Microsoft Monitoring Agent\Agent\Health Service State\Monitoring Host Temporary Files 4\2185\
One or more workflows were affected by this.
The name of the script changed from event occurrence to event occurrence, but it looked like pretty much every .VBS script and .js script was failing to execute on the server. As a result, the Windows Operating System instance for the server was not being successfully discovered, nor any of the object instances derived or dependent on that class. My customer’s new custom monitor was simply a victim of the problem here.
One of my strategies when SCOM scripts fail to execute, is to try to run them myself, manually from a command prompt. Why not? We have the path to the script, and even the parameters it takes, right from the event log description:
Path: C:\Program Files\Microsoft Monitoring Agent\Agent\Health Service State\Monitoring Host Temporary Files 4\2185\
Syntax: cscript.exe /nologo PopulateAdvisorWindowsServerProperties.vbs {DE47446F-B2E9-AFFC-D672-CD274318C360} {116028CA-EEA1-074A-3425-70EEC8705455}
(Keep in mind the GUIDs in the command or switches in your instance may be different.)
When we tried to run the script we got an error:
Input Error: There is no script engine for file extension ".vbs".
A similar error occurred when trying to execute a .JS script.
Fortunately the solution is simple, and quick. All you have to do is re-register the script file types so the Operating System knows how to execute them. This can be done with the commands:
assoc .vbs=VBSFile
and
assoc .js=JSFile
After we ran these two commands, we gave the SCOM Agent another manual flush, and when we re-started the Microsoft Monitoring Agent service, we were no longer inundated with event ID 21405. The scripts ran exactly as they were supposed to, the Operating System and its underlying objects were successfully discovered, and my customer’s custom PowerShell script monitor ran exactly as designed.