SCOM 2007 R2 and McAfee - Workflow Initialization Failed to start a workflow that runs a process or script

I've been working on a new SCOM 2007 R2 implementation this week for a large customer in Dublin that are using McAfee VirusScan Enterprise + AntiSpyware Enterprise 8.8 as their anti-virus solution and ran into an annoying problem / bug that needed attention to allow SCOM to work the way it should.
The issue started appearing shortly after I had added an additional SCOM Management Server (MS) to work alongside the SCOM Root Management Server (RMS). I hadn't got to the stage of deploying any agents to any other servers within the environment at this point as I wanted to concentrate on patching, dashboard customisation and custom configuration first.

The customer is using the McAfee EPO to auto push out their policies to all new servers and clients within the network and it was when the McAfee VirusScan Enterprise + AntiSpyware Enterprise 8.8 client went onto each of the two SCOM servers, that I started to see the error below:

Workflow Initialization: Failed to start a workflow that runs a process or script

Data was found in the output, but has been dropped because the Event Policy for the process started at 14:20:31 has detected errors.
The 'ExitCode' policy expression:
[^0]+
matched the following output:
-1073741819

Command executed: "C:\Windows\system32\cscript.exe" /nologo "MemoryUtilization.vbs" 2.5 SCOM-RMS.contoso.com 5841.
Working Directory: C:\Program Files\System Center Operations Manager 2007\Health Service State\Monitoring Host Temporary Files 15\2564\

One or more workflows were affected by this.

Workflow name: Microsoft.Windows.Server.2008.OperatingSystem.MemoryAvailableMBytes

Instance name: Microsoft Windows Server 2008 R2 Datacenter

This was one of many similar errors all referencing different workflows and indicating that any scripts that SCOM attempted to run were being blocked by the Anti-Virus client (McAfee in this case).

A quick check on the McAfee configuration indicated that the client was using both the 'On Access Scanner' and the 'Access Protection' scanner too.

The difference between these two components is that the 'On Access Scanner' is similar to all standard types of A/V on-access scanners and subject to the same exclusion lists and configurations (screenshot below)

But the 'Access Protection' scanner is more designed to block 'Anti-Spyware' applications, mass mailing worms, IRC etc. (See screenshots below)

Initially we thought that it was the 'Access Protection Anti Spyware Maximum Protection' setting that was blocking the scripts from running as it has an option of 'Prevent execution of scripts from the temp folder' and this was enabled, so we disabled this particular feature for the SCOM servers and waited to see if the errors would return (restart the SCOM health service on any of the servers to kick off the scripts again). Within 5 minutes however, the script errors came back and we needed to dig deeper!

I found a few pointers on the internet that were of similar issue but generally these just recommended turing off the 'Access Protection' option altogether for SCOM servers which isn't really an option in a high security environment!!

I came across a post on the McAfee forum that indicated this was a known issue with McAfee and in particular with version 8.8 of the engine. A quick check to confirm the customers McAfee engine again and it was indeed version 8.8!! (see below)

Most posters on the forum had to call McAfee to get the issue resolved and this resolution came around in the form of a custom SDAT file that isn't readily available on the internet but one poster who had the issue managed to resolve the problem by unregistering a DLL file that was related to a feature called 'ScriptScan' within the A/V client.

The 'ScriptScan' feature (it's part of the 'On Access Scanner') was one of the first things I had initially checked for this problem as it would be the most obvious but had found that it was disabled and the customer had never enabled this through the EPO policies so I had presumed it wasn't the cause.

The bug however lies in the fact that although the 'ScriptScan' feature may appear to be disabled on the clients, it still has it's DLL file registered and this is what was causing the problem.

Once I ran the command to unregister the DLL file on each SCOM server and rebooted the SCOM health service on each one, the error didn't come back at all!

The issue now is going to be that this DLL will have to be unregistered from each server that will have the SCOM agent installed for monitoring to allow it to work properly.

Here's the command to manually unregister the DLL on each server:

cd "C:\Program Files\Common Files\McAfee\SystemCore"

regsvr32.exe /u SCRIPTSN.dll

I've also created a really basic .bat file that you could run on a large number of servers through group policy that should automatically unregister this DLL file for you, here's the link to the file on my SkyDrive:

http://sdrv.ms/10QfLJ8

Once this DLL has been unregistered, restart the SCOM health service (if you've already installed the SCOM agent on the server) and the errors should disappear forever!!

As a reference, here are some links for some more information on SCOM Anti Virus Exclusions and recommendations although none of them are official and some quite old:

http://blogs.technet.com/b/kevinholman/archive/2007/12/12/antivirus-exclusions-for-mom-and-opsmgr.aspx

http://blogs.msdn.com/b/nickmac/archive/2008/07/18/antivirus-exclusions-for-operations-manager-2007.aspx

McAfee's Stance on SCOM Exclusions!

https://kc.mcafee.com/corporate/index?page=content&id=KB59944&cat=INTEROPERABILITY&actp=LIST