Still no resolution to this issue. I see several others are having similar problems though the details vary a bit. (OS, etc) If I run the SuperDAT all is well, then the next time a manual or auto update runs it downloads the dat, ini and gem file(s) then generic script error. If I try again it just grabs the .dat then fails with the same error. It is indeed downloading (I can see that and see the UpdateDir folder being created) but it won't process unless I use the manual super or xdat file. I'd really like to avoid blowing away a perfectly good OS to attempt to work around this because it's already on 2 machines and reimaging every time this happens really isn't a solution. There is nothing blocking the file coming in and no other apps were added to this PC that do not exist on other systems that are working fine.
Can anyone tell me the actual folders/paths that are in use during a manual/scheduled update on a 64bit (Win7) OS? I have verified the files are indeed downloading and disk space is available so somehow maybe it's a permissions issue where it's putting the file or where it's trying to move it to? I disabled UAC to ensure that wasn't it and it had no effect.Message was edited by: ohioit on 3/27/12 2:53:34 PM CDT
I haven't had the chance to enable detailed reporting, but the past 2 weeks I have several XP SP3 IE 8 systems running VSE 8.7i Patch 5 with Agent 4.5 Patch 3 that are failing to update their dats. I've downloaded the DAT/SDAT and manually updated, but the next day the auotupdate fail again. The computers affected are running stand-alone without an ePO server.
You ought to work with Support to take a closer look; providing MER data from the 2 troubled systems.
Enabling verbose logging for the Agent and McScript engine beforehand would be advisable.
We've seen some curious causes for update issues over the years. The most recent and prevalent ones to date are described in this article: KB75051
Some solutions forthcoming with 8.8 Patch 2; other preventative solutions shown for 8.7i.
Your specific scenario could be different, new, old and just not properly identified. Support can help.
I was trying to avoid that due to the frustration I experienced with previous issues and hoops to jump through via support but I believe I have no other recourse. I went as far as uninstalling the app, all McAfee software, manually removing all folders left behind as well as removing all registry entries with the word McAfee (aside of the legacy devices), the services themselves then rebooted, reinstalled clean for a local install (no epo) and without patch 1 I get the same generic script error. Patch 1 applied, same error. Everything else on this system works fine but the auto update of McAfee which says successful but never updates the dat until I download an xdat or superdat file. Plenty of free space, plenty of permissions (existing user and newly created user for testing are both local admins) Ugh.
Please refer to the following: https://kc.mcafee.com/corporate/index?page=content&id=KB73652
We had the Generic Script Error with ePO 4.5 and removing the AMCore content package resolved it for us.
Unfortunately that wasn't it. I really wish the logging was more verbose. All I can see is it gets the DAT file ok then bam, generic script error. Thankfully it's still only 2 stations (knock on wood) but not having a fix is a serious concern both in the short term to update and in the longer term if this continues to happen.
Another KB article to refer to
It is possible to change the level of logging of the Agent as well
Do you do anything exotic with your computer/network setup? Network hosted user profile folders, redirected temporary folders, locked down user profiles?
From what i've read the error occuring at that point would suggest a failure of the update process to access the downloaded files, such as an access permissions issue or a disk space issue.
Just an idea.........
As a test try excluding McAfee Program folders from the scan processes
e.g c:\program files (x86)\McAfee & c:\users\all users\Mcafee & c:\temp & c:\windows\temp
May be use a custom policy for these two machines so as not to comprimise the security of your other computers. It's possible that these files are being scanned by another process and therefore locking the files and preventing the update process accessing them.
Thank you. I actually saw the first article a while back and deleted that folder without success. (Although if memory serves me correctly it was in the c:\Windows\Temp location and not c:\Temp) I even tried creating a c:\Temp since there was none (without luck). The odd thing is if I initiate the update from within the console on the machine it reports it as successful though I can see the script error, the dat versions and dates never change so clearly it's not successful. Also tried your suggestion of excluding about every folder I could think of to no avail and set Windows Defender to disabled instead of manual (even though it was disabled upon install) just to be safe. Very frustrating.