Friday, June 17, 2011

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 NLC-SCOM-RMS.nlchq.ad 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:


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:



McAfee's Stance on SCOM Exclusions!



15 comments:

  1. working on a large office 2010 rollout (8000+ machines) worldwide
    we have seen installation failures due to the same mcafee issue.

    mcafee indeed provides an sdat in those cases.

    wouter@goderis.com

    ReplyDelete
  2. Thanks,

    Best Regards

    ReplyDelete
  3. The way we went about this was to not install the ScriptScan feature at all. On VS8.7 we use the flag "REMOVE=ScriptScan" when running the installer from the command line.

    Has this changed on 8.8?

    ReplyDelete
  4. Hi JHBoricua,

    I'm not too sure if there is a difference from 8.7 to 8.8

    To be honest, I stopped using McAfee a long time back and now prefer FEP or Sophos!

    Kevin.

    ReplyDelete
    Replies
    1. I couldn't agree more. My own personal testing of the supposed top 10 enterprise AV products proved Sophos to be far and away the best. It's only drawback is that it's among the top resource hogs, but with the power of today's systems, that's pretty much of a non-item. I take the security any day.

      Delete
  5. If you are running McAfee 8.8 and getting the error, just install patch 1 and this will stop the error from appearing anymore.

    ReplyDelete
  6. Thanks! Had the exact same issue, brilliant article.

    ReplyDelete
  7. You're welcome and thanks for the great comment!

    Kevin

    ReplyDelete
  8. On one system I did not have the scriptsn.dll but something similair: ScriptSn.20120227123133.dll

    I unregistered this file and the errors disappeared, but I am wondering why this name has been changed? Does anyone know that?

    ReplyDelete
  9. Do you have to install the patch and also the the unreg of the DLL?

    Alex Graham

    ReplyDelete
  10. If you are seeing this issue and are running McAfee virus scanner + Antispyware 8.8 install Patch 1 and your issues will be resolved. I was able to do this but I am also running SCOM 2012 so I do not know for sure if this resolves any issues with 2007 R2.

    ReplyDelete
  11. Hi there! Someone in my Myspace group shared this website with us so I came to give it a look. I'm definitely loving the information. I'm bookmarking and will be tweeting this to my followers! Wonderful blog and superb design and style.
    Great blog! Do you have any helpful hints for aspiring writers? I'm planning to start my own blog soon but I'm a little lost on everything. Would you propose starting with a free platform like Wordpress or go for a paid option? There are so many options out there that I'm totally overwhelmed .. Any tips? Kudos!

    klädbutiker
    Kläder på nätet

    ReplyDelete
  12. Great Thanks!
    The same problem exists with Avira Server too.

    ReplyDelete
  13. This comment has been removed by a blog administrator.

    ReplyDelete