0 Replies Latest reply on Mar 6, 2012 11:20 AM by dmease729

    SuperDAT rollbacks not working - Still a known issue?

    dmease729

      Environment:

      ePO 4.6.1
      McAfee Agent 4.6.0.1694 and VirusScan Enterprise 8.8.0.849 running on Win2k8R2 Standard

       

      Hi,

       

      Just wondering if I could seek clarification on if it is definitely *not* possible to rollback DATs if you use a 2.5.0 SDAT.  I am in the situation where disconnected networks will be using an SDAT file (via the SDAT for ePO zip file) to update there DATs once a month.  I have successfully tested this in a VM environment where the managed endpoint was running with DAT version 6602, and has now been updated to 6640. 

       

      I noted on the SuperDAT Manager Utility Version 2.5.0 Release Notes (ftp://ftp.mcafee.com/virusdefs/4.x/readme.txt) the following: "After VirusScan Enterprise is updated using a SuperDAT package, an attempt to rollback DATs fails.", under the 'known issues' section.  Just out of curiosity I tested both methods of rolling back ie:

       

      1) From VirusScan console, Tools -> Rollback DATs (which gives me the attached result)
      2) Removing the 6640 SuperDAT from the current branch, moving the 6602 SuperDAT from the previous to the current branch, running DAT update client task again (In this case, the update task finished, but the DAT version still shows as 6640 in 'About'

       

      Interestingly enough, the Agent Monitor shows:

       

      Updater 3/6/2012 4:15:56PM Update succeeded to version 20120206071036
      Updater 3/6/2012 4:15:56PM Product(s) running the latest SuperDAT
      Updater 3/6/2012 4:15:12PM Starting SuperDAT update

       

      The version number above is interesting, as it is the version number of the 6602 DAT.  Either the DATs have been rolled back successfully, and we have an aesthetic issue in 'About...' or they have not, and we have an aesthetic issue in the logging.  Just to confirm, in the agent policy settings, 'Enable DAT file downgrades...' is selected.

       

      So... questions:

       

      1) Is this still a known issue, and if so, are there any workarounds for the above scenario, in case of a required rollback?  Could we just take a manual copy of "C:\Program Files(x86)\Common Files\McAfee\Engine" and paste back if required (obviously temporarily disabling the relevant access protection rules)?
      2) If this still is a known issue, is this actively being looked into?
      3) If this has been fixed, could anybody advise if there are any constraints (note that there is a difference of 38 between the DAT versions I have just tested with today!)

       

      As a side note, I have seen kb58626, which advises on how to manually roll back the *engine* - but I cannot locate the 'Old Engine' folder.  A full search locates 2 mcscan32.dll files, one in the standard engine folder, and one in "C:\Program Files (x86)\McAfee\VirusScan Enterprise\RepairCache\Engine\ , but from the avvscan.dat file in their, that looks to be for a repair of the initial install?  There does exist, however, an 'OldDATs' folder - the AVVSCAN.DAT file in there is larger than the current AVVSCAN.DAT file by over 5M.

       

      cheers,