Client data in SEPM not updating even though clients are up to daye definition wise

We have a problem where a number of our clients are not updating their status in the SEPM. For example, the definition dates in the SEPM show as being out of date or in some cases as not having a definition at all. If we look at the client then it is fully up to date and is showing the symantec shield with a green dot in it.

In some cases we can get up-to-date information form the client by telling it to update content in the SEPM client commands however this does not always work.

Can anyone tell me what is happening here and how to fix it? We are running SEP 11.0.6200

Please check if you have a lot of .DAT/.TMP/.ERR files into SEPM\data\inbox subfolders (especially Agentinfo). If yes, it means clients are reporting their logs to the SEPM, but the manager is not able to process them.

.ERR are log files sent by clients to report their status and that SEPM was not able to process. Therefore, correct information about real client status (definition up-to-date, etc.) might be inside these files and explain why you have out-of-date information in the console.

You can open ERR files with notepad and try to identify which machine it is coming from. There might be some errors in SEPM logs as well that describe what's wrong with such files (you would need to open a ticket with the Support for such troubleshooting).

This can usually appear if you have an older version of SEP client managed by a newer SEPM release.

Try to update the client and see if it helps.

Please remember to mark the proper comment as SOLUTION:
- to identify threads that do not require further assistance
- to let other visitors know how to fix such issue

Also, what folder should i be looking at for the errors? Does each folder relate to anything specific? most of my errors are in the AVMan folder however theres no computer information within the files. Just random numbers it would seem.

Is this a SQL database setup or embedded database? I've seen this before where a buildup of dat files caused poor reporting. One of the things to check in that case if the version of BCP.EXE, making sure the version matches up with the version of SQL you are using.