6 Replies Latest reply on Jun 15, 2010 3:24 PM by andymease

    DAT update job not occurring within scheduled time properly



      For sake of argument, imagine a single site with a single epo 4.0 management server in it.

      We have created folders under the system tree for our different server types and assigned differing policies for scanning to each folder.


      At the top level there is a job created for all systems which transcends the system tree called "DAT Update Job".

      The job is configured to start at 7AM, run until 8PM and trigger every hour in between, so a total of 14 update triggers per day.


      This is mostly because our environment is air-gapped and at some point during the day someone will manually check in an sdat/xdat file into the master repository.

      We've relaxed the UI a little so that on our managed servers we can see the DAT Update Job mentioned, as well as the default job added when VS8.7i installs.


      The Agent on the installed/managed servers is set to policy enforce every 5 minutes, and is set to contact the epo 4.0 management server every hour for policy updates.


      Now, I checked in a new xdat at 08:30 this morning.

      It is now 15:00 and out of the 38 servers in our development estate, 4 of them have reported back an update to 6007, the rest of the machines have been sat on 6006 all day in the console.

      The DAT Update Job reports that it has run on a few machines that have not received the update but the DAT version has not updated.

      Some servers are reporting that they are sat at version 6007 when I log on locally, but still show as 6006 in the console


      We've woken the agents on all servers a couple of times to see if this would help.


      I am more than a little concerned that after an entire day in a clean Dev environment half the machines have not received the update (around 20) and of the half that have only 4 have been able to report it back to the console/management server/database within a 7.5 hour period and appear within a report.


      Can anyone offer an explanation for this other than the product being below par?