Video Screencast Help

SEPM scheduled report using incorrect query dates

Created: 04 Jan 2010 • Updated: 09 Jul 2010 | 6 comments

One of our SEPM admin console users has a weekly report that used to run fine.  It is a scheduled report for "Infected and At Risk Computers" with filter for "Past Week" and all other filter fields with * for all/any.  It continues to show December 2 to December 3 as the dates queried and returns no data.  If she runs the live report with the same filter, it works as expected.

We have deleted the report and started from scratch.  We have deleted and rereated her account.  We have deleted and recreated the filter.  If I run the scheduled report with a similar filter, it works fine.  Her other reports work fine.  It is just this "ONE" that is stuck somehow.  We have upgraded and downgraded JAVA.  We have cleared the temp files in the Internet and Java temp folders...  We've even uninstalled/reinstalled the SEPM console.

Any new suggestions?   This all started early December, immediately after we upgraded the SEPM to RU5. 


Comments 6 CommentsJump to latest comment

mk_sep_admin's picture

Other users and myself... yes they work fine. 

Hers?  She reports that all of hers do the same thing.  Wrong query dates.  They run and email on schedule, but query the incorrect dates.  Always Dec 2 thru Dec 3.  Literally the same day we upgraded to RU5 on the mgmt console.  I have a sneaking suspicion that it is something relating to leftover files or java but don't have any evidence to support that claim.

This isn't for notifications - just scheduled reports.  Live on-demand reports work fine using the same filters she's using for the scheduled reports.  It is truly JUST the scheduled reports.


Scuba Steve's picture

I believe you may need to call into support for this one. I have found a bug in the code that the report function uses to query the specific data. It isn't exactly as you stated, but none the less it is related. Basically my issue was the time stamp used was different per query. If you are using SQL, you can run SQL profiler and test this theory to see if the query we send to the database is the same for the live on-demand report versus the scheduled report. If they are different, then you will need to call in so that we can pass this issue to our developers.

Rafeeq's picture

hello scuba,
are u referring to the date format change which might have caused the issue?

are you talking about this , i think so

French localized Symantec Endpoint Protection Manager cannot create scheduled reports due to incorrect date format
Fix ID:
Symptom: On French localized Symantec Endpoint Protection Managers, scheduled reports cannot be created due to an incorrect date format.
Solution: Specified the date format before saving the scheduled report to the database

mk_sep_admin's picture

I logged in on the management server itself, ran the SEPM on the server with the admin credentials having the reporting trouble.   Report schedules/filters/etc were modified and resaved on the server.  The reports ran again, on an hourly schedule for testing and the query dates FINALLY changed on the report.

I don't know why, but it  appears to have fixed the issuse.  We will know more tomorrow when the regularly scheduled report runs.   We may have just changed the "stuck" date on the query from Dec 2/3 to Jan 4/5 but I am hoping for the best.

I'll update the thread tomorrow.  Strange that it is/was only affecting this one account and PC.  Other admins reports are all working fine, including mine - which have way more information.

mk_sep_admin's picture

After checking the reports for the last couple of days, all I did was bump the "stuck" query date to Jan 4/5.  All of this admin's scheduled (only scheduled) reports stay stuck on the "date" the report was most recently modified (or so it seems.)

I guess I'll be opening a case for this next week after the 12/31/09 def. fiasco dies down.

Any more thoughts?  Remember - live/on-demand reports run and query the correct dates.  It is JUST the scheduled reports that keep the wrong date.