SEPM incorrectly reporting def dates

Our SEPM is reporting the latest Symantec and server versions correctly on the home page.  The issue is where it shows how many clients have the different versions.  All of those are showing days behind.  For example, if the latest version was May 13 rev. 20 on our server, I would have 20 or so clients on our network running those def files.  SEPM would not show any as having that version, though.  That is where the problem is.  It will continue to show the same numbers from two or three days previous if I do not reboot the server.

Hi,

       The definition date would be a day behind thats normal however in the SEPM console depending on the number of the clients and the type of network the definitions would be distributed and then reflected back again in the manager console. Also check the schedule as to when the SEPM is scheduled to take these updates. You can also upgrade the endpoint to the latest version..11.0.4014 in case you are running an old version. You can download it from https://fileconnect.symantec.com/licenselogin.jsp?...

Thanks for the update, sandip.  That, however, is not my problem.  The virus defs are updating properly on clients.  The issue is, the reporting on the home page is incorrect.  It shows the correct current Symantec and server versions.  The issue is with the client dates above that.  If the current Symantec version, for example, shows May 13 rev. 20, the list above that for clients shows them all at least two days behind.  That is not true, however, as the clients have the most recent version available on the server.  I have verified that on several clients by checking them.  Once I reboot the server, the reporting is correct.

As you can see on this, the latest versions are showing correctly.  Above that, however, the clients are all showing as being at least 3 days behind.  When I check Endpoint on an actual client, it shows it has the most recent available def file.  If I reboot the server, the client information will be correct.

Hi,

      OK.. so as you mentioned the client have the latest definitions we also need to check as to how the clients are configured...whether they are configured to take the updates only from the manager or they can take it from the internet as well...because if they are then they will take the updates from the internet instead of the SEPM console and the dates will defer.

We have a policy in place that all clients can ONLY download from the management server.  We do not allow them to download updates through the internet.  Even if they were, that still would not be the issue.  We have them all configured in Group-Push method to check in every 8 hours.  Even if they were getting the updates from the internet, they would report their current def files every 8 hours to SEPM.  As the screen shot I attached shows, they are all at least 3 days behind according to this report.

I called Symantec support, after trying two different approaches, the one that works is to remove the MS-SQL client from each SEPM and re-create the SQL connection using the configuration wizard.

Now all my test clients are showing today's definition 2009-05-13 rev. 040

We should start troubleshooting this issue by having you look in this folder. By default it will be located at
C:\Program Files\Symantec\Symantec Endpoint Protection Manager\data\inbox\agent information

What we are doing is trying to determine if your clients are actually sending over log information in a timely manner to the SEPM, to say "I Have My Current Definitions". You are going to look around in this foler and subfolders for alpha numeric .dat files. These files should be moving into the SEPM in a timely manner (10-15 min). If this .dat files are backed up to three or four days we will need to look into other options of why this is happening. Obviously you are looking for the timestamps of these files to determine this. So if you could look into this for me and post back that would be great.

Thanks,
Grant

Also this is the manual way of doing this. Support has a tool to automate this process, so if you would like to call in for help I would recommend it. This is only a step to narrow down the problem, not solve it.