The default location is: c:\Documents and Settings\All Users\Application Data\Mcafee\Common Framework\
Have you checked the avaliable disk space on the client?
Run the latest superDAT to update it and see if it fails tomorrow on it's next automated update.
A very rare issue I've experienced isfaulty RAM, that causes the downloaded DAT to fail validation and therefore fail the update. MEMTEST86 can be used to check the status of the RAM.
i had a similar problem and after searching 'mcafee generic script error' found this ...
CauseThe most likely reason that the temporary folder UpdateDir cannot be created is that an identical filename (size 98kb) with no extension already exists in the same folder.
- If applicable, delete the file updatedir from c:\Documents and Settings\All Users\Application Data\Mcafee\Common Framework\.
- From a working computer, copy the following files into the folder specified in step 1:
- Click Start, Run, type services.msc, then click OK.
- Right-click on the McAfee Framework service and select Restart.
- To test the issue is resolved, from the Windows system tray click the McAfee icon and select Update Now. When the update completes, verify that the system is running the latest DATs.
Message was edited by: anderson337 on 14/03/12 23:03:39 CDT
Are there any other solutions to this issue? I've tried the above, tried uninstalling and reinstalling and we still have 2 stations with this issue. SuperDAT manual updates work fine. If I run the update from the station it says Downloading DAT, the Generic Script error and finishes the process. If I check, it says it completed successfully but the actual date/dat info never changes other than when I manually download a superDAT file. The UpdateDir creates during the process (I can see it) and removes itself after... very frustrating.
Another update... I went as far as to create new profiles on this machine (with the proper privileges) and it experiences the same issue. SuperDAT updates without error, all others (auto update or manual) fail after downing the dat with the dreaded generic script error. Files copied from working Win7 x64 systems at same patch levels (this is a Win7 x64 system), no effect. Uninstalled and reinstalled, no effect. Does anyone have any other suggestions? Right now I am able to handle these 2 systems manually but if this happens on more machines it won't be manageable. Any help is VERY much appreciated.
This to me sounds like a networking problem.
Correct me if I am wrong: You are able to manually download the sdat executable. However, I suspect the browser may be penetrating some kind of proxy.
If a proxy is set up within your network, you may need to configure VSE update jobs, to know about the proxy.
I have seen problems with scripts and other odd behaviors if some of IE has been damaged. Some .dll files may need to be re-registered.
McAfee has a tool http://download.mcafee.com/products/licensed/cust_support_patches/IERegFix.bat which should return IE to normal state. This could help.
Also, check to see if there exists odd proxy settings within IE which you did not intend. Compare the settings from a working computer to that of a failing one.
I hope this is helpful.
Appreciate the suggestion but I am able to download the DAT during the normal update process (from within the app itself, not using IE). It shows it downloading, then creates the the temporary update directory but I am met with the generic script error line and it doesn't process the update, just finishes. This error doesn't appear if I download the superdat and run it. (It finishes without issue other than telling me my engine is already current) Clearly something is different in the superdat that allows it to process vs the normal files it grabs during the scheduled update, I just can't figure out what/why.
Yes, even when using the app itself, IE is in use. So, the settings within IE affect 'the app itself.'
If the scripts are not running, WHS is probably not fully working. The purpose of the McAfee IERegFix.bat file is to re-enable common routines used by IE and other applications. IERegFix calls RegSvr32.exe. IERegFix lists these common routines and uses RegSvr32 to register these common routines like WHS and others used by IE. Scripting is part of the needed IE apps. Enabling this .dll may allow the normal update job to process.
The SDatxxxx.exe is a self-contained app which does not need the additional apps that the normal VSE update process uses. SDatxxxx.exe runs this 'script' without the need for additional apps.
So, try the IERegFix.Bat file and let me know how the normal update process goes.
Now I gotcha. I wasn't aware IE settings would affect the scheduled update (kinda odd since I don't even use IE but I still get what you mean). I'm going to run a full backup (just in case) and will try the update bat, reboot and give it a shot and let you know. I really appreciate the help.
Sadly, no luck. I had to edit a couple %'s in the bat to get it to run in Win7's cmd screen (ran as admin, rebooted, no luck then ran as user, rebooted, still no luck). If I didn't edit the %'s it errored out with a unexpected 2 which is the lack of a double %. I did get a could not fine registry entry error but the dll's reregistered. One thing I nontice is if I update manually it downloads the dat then generic the generic script error message. If I apply the superdat, then wait a day for a new def, it does the .DAT, the .ini and one more I can't recall THEN generates the generic script error (in both cases it fails to update unless I run the superDAT). *sigh*