Endpoint Protection

We have a rather strange problem that we have been unable to resolve at this point. Since upgrading from RU4 to RU5, SEP clients do not update some of their data in the SEPM. We do know the following:

Clients are able to contact the SEPM and check in. Check-in times are being updated.
Clients are able to move between SEPMs when one becomes unavailable.
Clients are receiving definition updates from the SEPMs. The SEPMs are providing the current definitions.
We are unable to see the proper definition in the SEPM that the client currently has. Affected SEP clients still show in the SEPM console as having definitions dated the day before the upgrade was performed.
Clients last scan times are not being updated in the SEPM

For all intents, the clients appear to be functioning properly, and when they are moved to a test SEPM they are picked up immediately and the data is updated in that SEPM. 

We have tried repair installations of SEPMs with no success.

We have uninstalled and reinstalled a SEPM with no success.

It is our feeling that the client data is never making into the /data/inbox/agentinfo location. We see errors in the exsecars.log indicating the disk is full but there is over 20GB of space available

We've tried a ton of things related to rights/permissions, IIS config, nothing seems to be helping. 

Is the date in question Dec 31? Because there's been a bug where the SEPM won't accept definitions dated Jan 1, 2010 or later? (Bunch of threads about that around here.) If it's any other date, this isn't going to apply.

If you could elaborate the following :-

Since upgrading from RU4 to RU5, SEP clients do not update some of their data in the SEPM.

What's the data that's not reflecting or updating in SEPM

 This is not the issue with the defintions dated 12/31. This began 12/10/09. Clients have the most recent defs but the SEPM shows them to have defs dated 12/9/09. Check-in date/time is always current. So we know some data from the client is being processed when it checks in or receives new defs, but not all of it. 

 Client definition date is not being updated in the SEPM, even though the client has current defs and is receiving them from the SEPM.

Is it feasible to paste a screenshot of the same.

 Not at this time. I don't see how that would help much anyway given that I have described what is happening. A screenshot won't really add much. If you have a specific question about what I'm seeing in the environment I'll answer it as best as I can. As I indicated, client check-in times are updating. Clients show online in the SEPM client listing (they have a green ball) but the definition date indicated by the SEPM is not what is actually on the clients. The clients have the current policy for the group they are in, as well.

Some of the data in the SEPM from clients is taken from actual direct communication with the clients, some of the information is processed from log files that are placed in the database.

Take a look for log files piling up in the inbox of the SEPM.

C:\program files\symantec\symanted endpoint protection manager\data\inbox

 The only place we have an accumlation of files under inbox is in the legacy folder, as there are SAV10 parents that are pushing reporting info to the SEPM. This process has now become painfully slow to process legacy client data compared to before RU5 and we see .err files in there as well. It is my understanding that the agentinfo folder is where the SEP data should be getting dropped but nothing ever moves through that folder.

Bump.

Any more thoughts on this?

Clients are checking in and have current definitions but SEPM console says the virus definitions are month old dates. 
Anyone figure this out?  did the Y2K +10 bug fix cause this?

It is unlikely the bug fix caused this as we had this problem start back in December when we upgraded SEPMs to RU5. We are working Symantec and developers are currently looking at code to see if the problem lies there. The primary error we still continue to see is in the exsecars.log file. It repeatedly logs an error saying that the disk is out of space, though we have 50+GB available. A diagnostic showed we were seeing a value of -2GB of free space. We suspect that for this reason, the data coming from the clients is not being dropped in the proper place to be processed by the SEPM so the data never gets pushed to the database.

I am only seeing the problem on a subset of the clients.  I will live for a while with this problem but it makes it tough to identify clients with actual problems.

BUMP

Is there a resolution for this??

What is the problem? Is there a fix?

Our problem appears to have been cause by improper permissions at the root of the C: drive on the SEPMs. Symantec assumes certain permissions to be set by default in the OS. For whatever reason, there were default permissions missing at the root of C:. Once we restored default permissions there, client data started being written to the drive and processed by the SEPM. We do not know why these permissions had disappeared and they had only disappeared on the SEPM servers. Symantec insists the upgrade process would not modify any file permissions in any way.

 What would those permissions be?

What permissions should we check for?

While I don't have the exact permissions in front of me, all I did was look at a freshly installed Windows 2003 server and duplicate the C:\ root permissions from there on to the SEPMs. From what I recall, there were several permissions granted to the Users group that were missing. I'll find the list and post here one I get an opportunity.

If you are seeing errors in the exsecars.log indicating the disk is full, then the issue is likely permissions related.

Can you please provide exact permissions do we need to check for?