Video Screencast Help

SEP Scheduled Scan Does Not Run

Created: 22 Jul 2009 | 14 comments

I have recently set up two new servers, two HP ProLiant DL380’s, identically with Windows Server 2008 Standard, SP2.

On one server, the Database server, I installed SQL Server 2008 and on the other, the Search server, I installed Apache Tomcat, v6.0.

I installed Symantec Endpoint Protection, version 11.0.1000.1375 on both servers and was able to run manual scans. I set up scheduled full scans on both servers to run at 5:00 p.m. every Saturday. Both servers are set up as unmanaged clients.

On the Database server the scheduled scan ran as expected, no issues. But on the Search server, the scheduled scan did not run. I created a test scan to run during the day and when it came time to run that scan I had the SEP main window open at the “Scan for threats” option. The Last Scan date for this test scan showed as “Never”, and the Next Scheduled Scan date showed as, let’s say, “2:00 p.m. on July 21st”.

When 2:00 p.m. arrived, I was watching the SEP screen. It momentarily flickered, the Last Scan date still showed as “Never”, but the Next Scheduled Scan date was updated to show as a week later, i.e. “2:00 p.m. on July 28th”.

In effect, it seems as if the scan started and finished in a split second. There is no entry in any of the logs for this scan but, if I run the same scan job manually, it runs in about 40 minutes, scans 655,000 files, and creates an entry in the log file.

FYI, when I first installed SEP on these two servers, I got the error message, "Because of an error in data encryption, this session will end”. I was able to determine that this was because of the IPv4 Large Send Offload setting on the network adapter being set to “Enable”. I removed SEP, changed the setting to “Disable”, reinstalled SEP, and I no longer got that error message. I don’t believe this issue is linked to that but, if you can prove otherwise, I’ll be only too happy to listen.

Any help anyone can provide as to why this scheduled scan doesn’t run would be gratefully accepted.

Thanks,
Peter J. Bray

Comments 14 CommentsJump to latest comment

Thomas K's picture

You need to upgrade off the first SEP build. There are tons of issues that have been resolved since that first release.
You will need to upgrade to MR4 first, then upgrade to the latest MR4 MP2 ( 11.0.4202.75 ).

Thomas

PGA_CR's picture

Things to know to ensure a successful migration
The following is a list of critical information that you need to know in order for your migration to succeed.
Before you upgrade, you should back up the database. Please read "Best Practices for Disaster Recovery with Symantec Endpoint Protection" at:
http://service1.symantec.com/SUPPORT/ent-security....
If your site uses replication, you must disable replication before upgrading Symantec Endpoint Protection Manager. You must disable replication at each site that replicates.

http://service1.symantec.com/support/ent-security.nsf/854fa02b4f5013678825731a007d06af/2bec0308fcd83d2f882575220071b968?OpenDocument

As Thomas say You need to upgrade your sep manager and clients.

Regards
Pablo Garcia

Peter Bray's picture

Thanks Thomas & Pablo,

We are not using the Manager portion of SEP at present; all clients are running in unmanaged mode - at least for now.  Once I get the MR4 and MR4 MP2 updates I'll apply them and let you know how it went.

Peter B.

Peter Bray's picture

Sorry it's taken me so long to get back to my original post; I didn't realize it would take THAT long to locate the serial number to allow me to download the latest version of SEP!

So that's what I did; downloaded version 11.0.4202.75 and installed it on the server in question.  No problems with  the install but, when the scheduled date & time arrived for the scan to run... nothing.  It updated the date and time of the NEXT scan correctly, but did not run the current scan.

I thought it might be because the scheduled job had been created under the older version of SEP, so I created a new job under the new version.  But, again, it didn't run, although the date and time of the next scan was updated correctly.

So, back to square one - any more suggestions?

Peter B.

Peter Bray's picture

I recently downloaded the latest version of SEP (11.0.5002.333).  I completely removed the previous version (11.0.4202.75) from the server, rebooted, installed the latest version, and rebooted again.  I recreated the scan, but it still will not run as scheduled; I can run it manually, with no problems, but the scheduled scan does not fire up.  After the time has passed for the scheduled job to run, the date and time for the next scan ARE updated correctly (e.g. after the 5:00 p.m. scan on November 14th, the next scan time & date are updated to 5:00 p.m. on November 21st.

Does anyone have any suggestions as to what the problem might be?  I don't have this problem on any other servers (or any desktops, for that matter) which are running a mixture of versions 11.0.1000.1375, 11.0.4202.75 and 11.0.5002.333.

Thanks,
Peter B.

Thomas K's picture

Peter,

Are you running any other security or encryption software on these systems? You might consider opening a case with support to help get this issue resolved.

Best,
Thomas

Peter Bray's picture

Thanks, Thomas

The server in question is running nothing special - basic plain vanilla MS Server 2008, and running Apache Tomcat, Cocoon & Solr.  It doesn't even run MS SQL Server or IIS; these are both hadled by other servers.

Peter B.

Peter Bray's picture

In case this may help, I also created a "DoScan.exe" command file, and scheduled this to run a "/SCANALLDRIVES" job via the Windows Task Scheduler.  I got no errors when it ran but, as with the SEP scheduled scans, no files were scanned, the job starting and ending in 1 second.

I guess I may have to open a case with Support as suggested earlier.

Peter B.

teiva-boy's picture

 I've seen where a GPO applied to systems to prevent the shutting down of the AV processes, didnt' allow for scheduled scans to run.

Are you aware of any GPO's being applied to those machines?

There is an online portal, save yourself the long hold times. Create ticket online, then call in with ticket # in hand :-) http://mysupport.symantec.com "We backup data to restore, we don't backup data just to back it up."

Peter Bray's picture

We haven't applied any GPO's to this server; we tried to keep the system as generic as possible.

Peter B.

Peter Bray's picture

I have recently discovered that I can get a scheduled scan to run, but only under very specific circumstances.

If I log on to the server (remotely, using RDP, logging in as Administrator), open the main Symantec Endpoint Protection window, create a scheduled scan (full or custom), and then leave everything running, when it gets to the scheduled time for the scan it starts as expected and runs to completion.  An entry is created in the log file, and the date and time of the last scan/next scan are updated accordingly.

These are the ONLY circumstances under which I can get a scan to run; if I close the SEP main window, the scan does not run; if I leave the main window open but disconnect from the RDP session, the scan does not run.

This "solution" resolves nothing for me; I still have to run the scan manually every week, but I would prefer, obviously, to have the scan run automatically as it does on the other 5 servers.

If this sequence of events triggers anything in someone's memory, please let me know.  I'm becoming more convinced that it's a conflict between SEP and some software I have installed on the server (as mentioned earlier, MS Server 2008, Apache Tomcat, Cocoon & Solr).

Peter B.

EddieFernn's picture

I thought I was having the same issue. Scans would not show up in the client scan logs.

However when checking the systems application logs, all the scan information was reflected as working just fine. Scan started on machine, and an hour and a half later the scan was complete.

Now my only problem is making the SEP client software understand that it happened.

DBoggs's picture

Peter,

I am curious, did you ever solve this issue.

I am having a similar issue wih UNMANAGED clients.

MotorMuis's picture

I am also having the same issue with UNMANAGED clients.