I have this problem with a few people, some were kicking in a second scan that was left over from old SAV install. I have 2 users that have still another thing that triggeres it and have yet to find a cure other than run clean wipe.

I  have this VBS code to remove the old scans from SAV

const HKEY_LOCAL_MACHINE = &H80000002

strComputer = "."
strKeyPath = "SOFTWARE\Symantec\Symantec Endpoint Protection\AV\LocalScans\ClientServerScheduledScan_1"

Set objReg = GetObject("winmgmts:\\" & _
    strComputer & "\root\default:StdRegProv")

DeleteSubkey strKeypath
wscript.quit

Sub DeleteSubkey(strKeyPath)
   
    'Get a string array of subkeys
    objReg.EnumKey HKEY_LOCAL_MACHINE, strKeyPath, arrSubkeys

    If IsArray(arrSubkeys) Then
      'Iterate through each SubKey
            For Each strSubkey In arrSubkeys
                        'Delete any Subkeys that are in the current subkey
                        DeleteSubkey strKeyPath & "\" & strSubkey
            Next
    End If
 
    objReg.DeleteKey HKEY_LOCAL_MACHINE, strKeyPath

End Sub

There is a policy that defines if a scan is failed to finish troughly completed, it schadules the task to redo again in future.
So that, (maybe) when you apply a full scan, it takes long time and this cause a postpone of the other task (or vice versa).

Check this out maybe this is the cause.

Hi Toko :

http://service1.symantec.com/SUPPORT/ent-security.nsf/docid/2008070711521548

In my case , I upgrade SAV10.X to SEP11 , it maybe happen , you can call Symantec support to request the "SymRmvScan" Utility .  Wish it help !!

Jerry

It is true most of these machines are being upgraded from a previous version, but I don't see any leftovers in the registry that would indicate a conflicting  or duplicate scan schedule. 

What I do see is separate policies that are being used for Location Based Policies that are using the same scan schedule.

I'm wondering if during the scan there is a timeout or something that would cause the policy to flip in the middle of the scan.  

I'm thinking this might look like two scheduled scans for the same time frame and since two scans can't run at the same time it waits for the first to finish before it begins the second.

So then I'm wondering if you use Location Based Policies for different types of connections, what would be the proper method of dealing with this?

Do I use the same AV (shared policy) across locations?

Does Symantec keep track of sucessful scans and credit them to all policies?

I can see the logic on why I would see multiple scans, but how does Symantec deal with this condition when using Location Based Policies?

I might be shooting myself in the foot, but I need to make sure the scans get done.

What is the right way? 

Never two scans happen simultaneously!
The scans get into queue and event in order. In parallel, with a setting you can define if a scheduled or eventual scan (such as scans that happen immediately after updating definition) does not finish completed (like the user shutdowns the system before the completion) the scan starts again in future.
Therefore, if you have defined a manual scan, such a full system or memory scan will be postpone into queue and is triggered right after the manual scan which results: TWO SYSTEM SCAN ONE BY ONE!
This is a guess maybe true or maybe not! But check it out in your Symantec Manager and see if it is true.

I had a machine that started repeating a scheduled scan.
We initially thought it was a scan queued, but after leaving it to finish several, it just kept going.

Pretty much all our machines are set up the same - IE, all have one weekly scan scheduled.
This machine had been working fine for weeks, SEP just suddenly decided to repeat the scan.

Tried a few things, but eventually just re-installed SEP on that machine and all was well again.

If you aren't talking about too many machines, have you tried a re-install?

Nick

If the client starts to scan without any order for, the reason is a setting that defines for the clients to make a full or partial scan whenever it receives a new definition.

This is not the same as the above mentioned issue, which is a double scan right after each.

Thanks jenny for the info.
I contacted support and received the file today.
Wont know if it works until next week.

http://service1.symantec.com/SUPPORT/ent-security....

Defwatch scans have been shut off since day one.  Truscan is on.  We have Administrator Scheduled Scans and there is a location based policy that says if the laptop loses connection with the management server that it can try to contact Symantec for a LiveUpdate.

On the machines with double scans it looks like the policies are flipping between the default (management server) and the "no management server".

Two different policies, both have Administrator scans listed.

Could this be cause the Double Scans?  If so, what is the correct way to setup Location Based Policies?

I have 6 clients I'm tracking.  I used the SymRmvScan utility on them.  I still have 2 that did double scans.  One on Schedule the other 10 or more hours later on the same day.

I just got a new ticket for another agent.  When I look at the scan history, it had 4 scans on the same day but has been behaving for the last 2 weeks.

I do have a ticket open already.  We'll see where it leads.

We still struggle to control the time and frequency of scans.  We have tried tools, etc, etc.

The multiple scans just aren't really predictable.  We don't seem to see as many, but they are not consistently the same machines.

So now I wonder...How does SEP track a completed scan?

If I change locations, but use a shared AV policy, how does SEP know that the completed scan I just did using Policy A should be credited to the next policy I change to.

Example:  I have Location Policy A,  Wednesday early morning scan runs.   My machine changes polcies Wednesday afternoon to Location Policy B with a the same shared AV policy as Location Policy A,  when the policy changes a scheduled scan titled "Wednesday Morning Scan" begins.   I look in the logs for this machine and it shows the completed morning scan and the new scan that is running.

I know there is a 1 day retry interval and I've seen scans startup for machines that were offline and started up outside the 1 day retry interval.  Say my machine was off all day Wednesday and Thursday and I turn it on Friday.  The Wednesday scheduled scan will start.

I'm not sure if I can duplicate this if I try.

Let me try to summarize

1) Unexpected scans - where a scheduled scan finishes and then another, unscheduled one, begins.   It may be right away or it may be later in the day.  Either way, this one is unexpected and cleaning out the registry with the tools mentioned above or uninstalling, cleaning the registry, and reinstalling has fixed this issue for me on the machines that were experiencing it.  I also believe this to have been fixed in the latest release according to the notes I read.

2) Laptops changing locations.  For my laptops, I have two locations (in office and out of office).  For each, I have a scan to happen on Tuesday night at 2am.  If the laptop is off, the scan is forced when the laptop is turned on.

Now, if the user has the laptop away from the office and it's on, this scan runs.  So, on Wednesday morning (the next morning) they come into the office and the plug their laptop into the network.  A scan starts up right away.  I beleve this to be the "in office" scan.

To sum up, my experience is that SEP doesn't make a distinction between the different location scans.  Each location scan has it's marching orders and insists on performing them.  I've tested this pretty well and am suprised to see that SEP doesn't put off the "on location" scan since the "off location" scan ran, but it doesn't. 

3) The administrator moves a computer from one group to another.  Even if the two groups use the same shared policy, *sometimes* the computer will scan again when changing groups!

The *sometimes* is important - we have been unable to reliably recreate any of these scenarios 100% of the time.

If there are mutliple users on the PC there may be timed scans defined under each user profile. This may cause multiple scans to run. I had this on my laptop (which is unmanaged) because it was set up off domain (in cluding AV setup) and then added to the domain and the scan set up there as well. This led to two scans running consistently and it took me a while to figure out what was going on.

Just another thought.

Changing locations causes previously completed location based scans to be run again. This is fixed in MR4.

http://service1.symantec.com/SUPPORT/ent-security....

I don't think that can be true in all circumstances (fixed that is).

I have seen this behaviour post MR4.

Scenario:

Different AV policies applied to 2 separate groups, with differing scan schedules.

Policy 1
Scheduled scan Tuesday 10AM
Retry missed scans within 3 days.

Policy 2
Scheduled scan Wednesday 10 AM
Retry missed scans within 3 days

On Thursday afternoon, a machine from Policy 1 is moved to Policy 2

The 'supposedly missed'  Wednesday scan of Policy 2 starts within minutes of moving the machine, despite having been scanned succesfully on Tuesday and not being subject to Policy 2 at the time of the Wednesday scan.

Whilst all machines that were subject to Policy 2 at the time of the scan and actually did miss the scan should be forced to scan, IMO historic missed scans should NOT be retrospetively applied to newly added machines - If I wanted to scan a machine when it is added to a group, I would do it manually.

Nick

@Nickf: "historic missed scans should NOT be retrospetively applied to newly added machines" - maybe SEP didn't plan on having machines move around. It assumes that machines added to the group are new machines and thus enforce all rules. Maybe they should add a feature for a rule that if it was scanned between a time range prior to the scheduled scan that it will be skipped that time.

We've been running MR4 for months, and it isn't fixed.

We have even seen the problem when the same (shared) policy is applied for different groups.

I'll try and replicate NickF's scenario and see what happens, none of our clients complain at the moment - maybe because they're used to it or for some other reasons. I think I also made a wrong statement back there about adding machines to the group and how the policies in the server applies to them. We're in the process of adding new machines and assigning them to groups. I'll try and keep you posted. :D

So we have these unexpected scans.  Had a ticket opened, ran all kinds of tools.  Created new images with not legacy installations.

I find the silence from Symantec deafening.

Since I'm obviously not alone... I would expect one of two responses

1.  Yes, we are aware of this condition and are working to resolve it.

2.  This is expected behavior based on .......

The most frustrating part of all of this is not knowing exactly what makes the scan schedule tick and how it is applied.  Lots of assumptions are made with expectations on what should happen.

Maybe a shared AV policy is not really shared, but a copy and there are separate policies?

Maybe a scan from one policy doesn't count towards other scan policies on  the same machine?

Maybe the retry interval doesn't work at all?  Or doesn't work as I expected.

I've seen a laptop move from one group to the other, using a shared AV policy.  Scans are Saturdays and Tuesdays at 2:00 A.M. with a 1 day retry interval.

This laptop was moved on a Thursday, and after it was moved it started a full scan and the title of the scan was Scheduled Tuesday scan.

Where is the logic that makes this thing run?  If we knew the logic then we would know what to expect and maybe how to deal with it.

Or......

If it is being addressed there could be some optimism that these issues will be resolved in the near future.

Something, please......

toko

@ toko,

Can you please PM me your Symantec case number. I will check in and see what is going on with the case.

Thanks,
Thomas

Hi, I did try to replicate the moving of a PC from one group to another.
The groups are set to scan on different days.
When the policy was implemented, the later policy took effect and the other scan schedule was discarded. So, I guess this is a job for support.

I think this Symantec Must be aware and investigate on this, we are hoping that this issue is resolve in the latest MR.

I just checked on toko's case. The Tech assigned to the case is gathering data and still troubleshooting the issue. We will update here once a resolution is found.

Regards,
Thomas

I just checked in on the case. Support is still working with the customer and is awaiting further test results from the user.

Thomas

Hello,

I have the same problem with one of the computers on my network. I dont know if this can be replicated on other systems but when i change the time(say 4pm to 3pm) on my computer symantec seems to kicking in a new scan.

Computers on my network are scheduled to scan at 1AM every night. SEP kicks in a new scan based on the system time changes why?

Hope this helps with the trouble shooting steps.

Thanks
Vasu

This appears to be fixed for me with the latest SEP version, V 11.0.5002.333

Still gathering information and sending it in.

It is still rather random.  Can impact 10 to 15 percent of the workstations in our environment.  Not always the same machines each week.

The 2:00 A.M. scan generally kicks off on time and there on some machines later in the day a second scan will kick off.  Even fewer have a third scan run.

We are still on MR4.   I have not heard that any of the later releases will resolve this issue.  (But I was hoping)

We went round and round with support on this, running a bunch of tools, collecting lots of logs etc...

We ended up using up too much time and resources with no return.

We are now several revs behind and have decided to wait until we are upgraded to continue with this case.

This looks to be a really long wait..Hope RU6a fixes all..

Multiple scan are not deleted. I can find still on registry same scan for more times. if i manualy delete this registy files, after reboot they recreate.

Vladimir,

Upgrade to RU6 MP1, this should take care of it. Latest version is 11.0.6100.645

Had same issue and upgrading to this version resolved it.

rats.  we're in the midst of upgrading to 6a.  Somehow missed the announcement of MR1.  :(  Will have to try moving to MR1 asap...

You still have to go through with your 6a. Refer to this discussion:

https://www-secure.symantec.com/connect/forums/upgrade-1104-1106-older-version-cannot-be-removed