1 2 Previous Next 14 Replies Latest reply on Sep 23, 2010 10:31 AM by HupSkiDup

    ePO v4.5 - AVVDAT-nnnn.ZIP DAT Cleanup

    runcmd

      On my ePO server there are a lot of old DATs (several gigs worth) named "AVVDAT-nnnn.ZIP" in the following folder:

       

      C:\Program Files\McAfee\ePolicy Orchestrator\DB\RepoCache\Current\VSCANDAT1000\DAT\0000\

       

      They appear to go back as far as when I brought up the new v4.5 ePO.  Two questions:

       

      1.  Can these be cleaned up (old ones deleted)?
      2.  Assuming "yes" to question #1, can the cleanup process be automated inside of the ePO?

       

      I'm wondering if there is a setting I'm missing to automatically purge DATs older than x number of days?  The only thing I could find in the manual on this subject was on p.192, "Deleting DAT or engine packages from the master repository", and that doesn't seem to be what I'm looking for.

       

      Thanks!

        • 1. Re: ePO v4.5 - AVVDAT-nnnn.ZIP DAT Cleanup
          GWIRT

          This is an issue that will be resolved with ePO 4.5 Patch 1 (due out at the end of this month). In the mean time, you can delete the files from this directory manually to keep it under control.

          • 2. Re: ePO v4.5 - AVVDAT-nnnn.ZIP DAT Cleanup
            runcmd

            Thanks for the response!  Do you happen to know if there's a KB article associated with this issue?

            • 3. Re: ePO v4.5 - AVVDAT-nnnn.ZIP DAT Cleanup
              GWIRT

              This is covered in KB67585. I believe it is in the process of being published and should be available within the next day or so.

              • 4. Re: ePO v4.5 - AVVDAT-nnnn.ZIP DAT Cleanup
                runcmd

                If anyone is interested, I've written a batch file that will purge all but the most recent five versions (based upon file date) of the following file types:  *.upd; *.gem; avvdat-*.zip; dat-*.zip

                I then scheduled it to run as a weekly task on my ePO to clean up the excessive accumulation of DATs.  The batch file can be called whatever you want but it should have a ".cmd" extension.

                 

                WARNING & NOTICE:  This batch file worked fine for me but I do not guarantee desired results on your own system.  Because this batch file automatically deletes files, there is a level of risk associated with using it...  USE AT YOUR OWN RISK!

                 

                 

                @echo off
                set FilePath=C:\Program Files\McAfee\ePolicy Orchestrator\DB\RepoCache\Current\VSCANDAT1000\DAT\0000
                for %%a in (#.upd #.gem avvdat-#.zip dat-#.zip) do call :SubRoutine %%a
                set FilePath=
                goto end

                 

                :SubRoutine
                if "%1"=="" goto end
                set FilePattern=%1
                set FilePattern=%FilePattern:#=*%
                dir /o-d /b "%FilePath%\%FilePattern%"|find /v "">%temp%\~DATPurgeList.tmp
                for /f "tokens=1 delims=* skip=5" %%a in (%temp%\~DATPurgeList.tmp) do if exist "%FilePath%\%%a" del "%FilePath%\%%a"
                if exist %temp%\~DATPurgeList.tmp del %temp%\~DATPurgeList.tmp
                set FilePattern=

                 

                :end

                • 5. Re: ePO v4.5 - AVVDAT-nnnn.ZIP DAT Cleanup

                  I have noticed this problem as well but only on my DFS (Distributed File System) repository. On my non-DFS repositories, it only has the most current.

                   

                  Guess I will wait for SP1 then....

                   

                  thanks! 

                  • 6. Re: ePO v4.5 - AVVDAT-nnnn.ZIP DAT Cleanup
                    runcmd
                    I have noticed this problem as well but only on my DFS (Distributed File System) repository. On my non-DFS repositories, it only has the most current.

                     

                    When you refer to DFS, are you indicating that you are using a file share off of a server for the distribution of updates (UNC share repository)?  Our distributed repository is a SuperAgent--we do not have any UNC based distributed repositories.  I did check our SuperAgent repository and there does not appear to be an accumulation of DATs there.  In my environment, the problem appears to be limited to the ePO (master repository).

                    • 7. Re: ePO v4.5 - AVVDAT-nnnn.ZIP DAT Cleanup

                      runcmd,

                       

                       

                      We use Microsoft's DFS (http://en.wikipedia.org/wiki/Distributed_File_System_(Microsoft)) for redudancy in our environment. So for example, a unc name of \\org\mcafee\dats is used as a single entry in ePO for my DAT repository but when clients in office locations hit that, they are accessing a file server local to them.

                       

                      I have another non-DFS location in ePO (for example, \\servername\mcafee\dats) and it does not have all the extra AVVDAT-nnnn.zip files.

                       

                      Hope this makes sense.

                       

                      Also, thanks for the batch file; that is very helpful.

                      • 8. Re: ePO v4.5 - AVVDAT-nnnn.ZIP DAT Cleanup
                        runcmd

                        Thanks for the Wikipedia article.  I actually did look at that prior to my last post but was confused after discussing it with a co-worker.  I haven't done anything with DFS. (I guess that's obvious.)  It sounds almost like the problem you are experience is in the replication, since you indicated that a non-DFS configuration works properly.  Regardless, is there an advantage to using DFS instead of an ePO managed SuperAgent at each site for the distributed repository? -- Unless the client systems at "Site B" don't have direct access to the master repository at "Site A", so a SuperAgent distributed repository at "Site B" would be unable to communicate with the ePO and, therefore, not update.

                         

                        Thanks!

                         

                        P.S.
                        I hope it's okay I'm sidelining the thread a bit with a discussion about DFS and repositories--you peaked my curiosity.

                         

                        Reference:

                        Additional DFS Info I Found...
                        http://technet.microsoft.com/en-us/library/cc787066(WS.10).aspx

                        • 9. Re: ePO v4.5 - AVVDAT-nnnn.ZIP DAT Cleanup

                          runcmd,

                           

                          Not a problem at all. We implemented DFS for all of our global file/print servers so I am just leveraging that; it was not put in place just for ePO.

                           

                          We are in the process of moving from ePO 3.5 to 4.5 (probably the last place on earth to be still running that... : ) ) so when I was designing the ePO 4.5 layout it made sense to have one ePO repository instead of managing tons of them; I do have a couple of normal repositories for non-DFS shares but this will limit WAN traffic for clients quite a bit. Obviously some exposure if DFS goes down but DAT files would be the least of our problems.... : )

                          1 2 Previous Next